Home | OPC Servers and iFix Drivers | Universal OPC Server | Custom Work | Contact Info
:: UOS Overview
:: UOS Features
:: UOS Profile List
:: UOS Price List
What is a Profile?

A profile is a file that contains the definition of all messages used by the UOS OPC Server to communicate with a field device or group of field devices. It defines how to read and write data and how to handle error responses. Each profile is assigned a name so that it can be associated with the type of I/O hardware that it supports. You load the profile by using the profile browse button located in the UOS OPC Server user interface (called the Powertool). Loading a profile is the same as selecting hardware type in any other OPC server.
Integrators and end users can build their own profiles using the UOS Profiler (sold separately). Building a profile is the key step in creating a new OPC Server. Building a profile does not require any programming (Visual C++, C++, VB, etc.) expertise.
A profile is comprised of four object types: Command Group Objects, Command Sequence Objects, Message Objects and Communications Objects. They are also referred to as GroupObjects, SeqObjects, MsgObjects, and CommObjects respectively.
Command Group Objects (GroupObjects)
Each GroupObject defines a specific function to transfer data or to initiate a control action between the UOS OPC Server and a field device. An example of a GroupObject to transfer data would be reading the process variable (PV) and loop setpoint (SP) for a temperature controller. A second GroupObject may read the entire set of controller tuning parameters. A control action GroupObject would be one that changes the controller mode from Manual to Auto. A GroupObject is comprised of Sequence Objects and Message Objects. The tree below shows the structure for a single GroupObject.

Figure 1 - Read/Write Command Group Object (Group Object) Structure


Command Sequence Objects (SeqObject)
A GroupObject has two parts: a Read command sequence object (ReadSeqObject) and a Write command sequence object (WriteSeqObject). The purpose of the ReadSeqObject is to define the messages necessary to read data from a device. It can be used in a different way for advanced functions, but reading is the primary purpose. As you might expect, the purpose of the WriteSeqObject is to write data to a device. Figure 1 shows the ReadSeqObject and the ReadSeqObject for a command group.
Message Objects (MsgObjects)

ReadSeqObjects and WriteSeqObjects are comprised of MsgObjects. There are three types: Request, Response and Error. A simple ReadSeqObject would contain the following message objects:

  1. Request data from a device using the Request MsgObject AND…
  2. Receive a response from the device in a format defined by the Response MsgObject OR…
  3. Receive an error response from the device in a format defined by the Error MsgObject.

Each message object type is represented in the UOS Profiler by an icon as shown below. A Request MsgObject is represented by a right arrow icon to indicate that communications is going OUT of the OPC Server to the device. The Response and Error MsgObjects are represented by a left arrow icon to indicate a communications flow INTO the OPC Server.

Figure 2 shows a simple read-only GroupObject that contains a ReadSeqObject. The ReadSeqObject contains a Request, Response, and Error MsgObject. Note that the WriteSeqObject is empty. This GroupObject will not support writes to a device.

Figure 2 - Read-Only Group Object Structure


How the UOS Profiler uses GroupObjects, SeqObjects, and MsgObjects
There is one class of objects that we have not explained yet. Before we do, lets see how the UOS Profiler uses GroupObjects, SeqObjects and MsgObjects to define communications with a serial device.
The Figure below shows a snapshot of the UOS Profiler workspace used to build a profile. All GroupObject names are listed in the area labeled Command Group List. A description of the selected GroupObject is shown in the Description field. The read and write SeqObjects and their related MsgObjects are shown in the area labeled Command Group Tree. The ReadSeqObject is labeled Read and the WriteSeqObject is labeled Write.
To build a new GroupObject (Command Group), name it and use the message object buttons to add the required MsgObjects to the read and write SeqObjects. The command group highlighted (named RW_Holding) was build to read and write Modbus Holding resisters.

UOS Profiler Workspace

Figure 3 - UOS Profiler Workspace


Communication Objects (CommObjects)
As noted above, there is one more class of objects needed to define communications with a serial device. This final object class is called Communications Objects or CommObjects. CommObjects are used to define the detail content of each MsgObject. There are ten CommObjects. They are shown in the table below.

Table 1 - UOS Profiler CommObjects



[Const] Specifies a constant.
{Var} Specifies a variable. A variable can contain a single data item or an array of data items.
<Start> Specifies the Start address of a block of data
<End> Specifies the End address of a block of data
(Msg Len) Specifies the message length.
<Data Len> Specifies the number of data items to read or write
<Dev Addr> Specifies the field device address.
(Checksum) Specifies the location and type of Checksum checksum
[Parameter 1] Specifies any device protocol parameter
[Parameter 2] Specifies any device protocol parameter


The best way to understand how CommObjects are used to build a MsgObject is to look at an example. We will use Modbus RTU protocol in our example. The message structure (MsgObject) to read Holding Registers for the Modicon 984/385 is:

 Table 2 - Modbus RTU Read Request MsgObject

Device Address

Modbus Function Code

Register Start Addr

Number of Registers to read


01h 03h 0000h 0010h 4406h
<Dev Addr> [03h] <Start> <Data Len> (Checksum)


The first row in the table describes the Modbus protocol to Read a block of Holding registers. The second row contains the hex codes to read 16 (10h) holding registers starting at address 0000h from a device whose address is 01h. The third row shows how CommObjects are used to build the MsgObject. Compare this row to the Selected Command field shown in Figure 3.
All CommObjects enclosed with < > are user configurable. This means that the value for the CommObject must be entered when setting up the UOS OPC Server for communications with a device. When the profile containing this MsgObject is loaded the corresponding fields will automatically become active to allow user configuration. For this example, it gives the user the flexibility to select the device to read from and the block of holding registers to read.
CommObjects enclosed with [ ] are constants. Constants are fixed (cannot be changed by the user).
CommObjects enclosed with ( ) are protocol dependent. For example, the Modbus RTU protocol checksum is a CRC-16 calculation that depends on the values of all CommObjects from <Dev Addr> to <Data Len> inclusive.
CommObjects enclosed with { } are variables. A Variable CommObject would be used in the Read Response MsgObject (not shown here). Variables may contain a single data item or an array of data items. Variables may also be digital or analog.
The CommObjects shown in Table 1 are used to build Request, Response and Error MsgObjects.
© 2011 Dimension Software, Inc. All Rights Reserved.