The "Profile" Concept in Fieldbus Technology
By James Powell, P.Eng.
A device profile is defined by the International Electrotechnical Commission (IEC) as a "representation of a device in terms of its parameters, parameter assemblies, and state model that describes the device's data and behavior as viewed through a network. This standardizes the device from the network point of view for easier data exchange, configuration, and functionality.
A profile defines:
The data presented on the network and the format for that data
Standard functions the network can use to get and manipulate data (such as analog input block with scaling)
Standard parameters required to set up the device
Methods or procedures to communicate parameters to the device over the communication network
Before profiles, each vendor had different approaches to device configuration and data exchange.
Benefits of profiles
The big benefit is in cost savings to the user that effectively reduce the cost of ownership of a device:
Less time spent in integrating a device into a system (no special code required)
Less training required because there is less variation in devices
Reduced time for trouble shooting because the system has fewer variations
Vendors also benefit. It lowers their cost of technical support. By reducing customers' training requirements, vendors spend less time explaining how their system works. It also creates a level playing field so that competing products are judged on how they perform and not just on their compatibility with an existing system.
Profiles in fieldbus technology
The HART Communication Foundation, Profibus International, and the Fieldbus Foundation all have subcommittees working on profiles. Profibus released its third version of the standard in 1999.
The IEC released "Principles for the Development of Device Profiles" (TS 61915), which provides a technical standard for writing device profiles independent from the fieldbus. This is an extension of the current practice of having fieldbus-dependent profiles and will benefit users even more.
Example: setting up level monitors
Let's compare the work required to integrate level monitors from Vendor A and Vendor B, assuming that Profibus is the network. The tasks are:
Configure the device
Set up the communication network
Set up the master
Before configuring, you must load the two software packages. Besides having to learn both packages, you must maintain them for the lifecycle of the device.
You will need a proprietary cable and adaptor for each device to connect it and communicate with it. Finding these cables years later when you want to do an adjustment may be difficult.
As you begin to configure the device, you find that each device is programmed by a series of parameters that do basically the same thing. It's confusing, however, because the parameter names and order differ. Figure 1 shows a quick setup for Vendor A and Vendor B. As you can see, a tank is still a tank, but the names and order are different. Although these seem like minor differences, they complicate the task, require training, take extra time, and add to the installation cost.
Both devices require that you set up the communications and define the information you want passed on the network. Here again, both devices have different setup parameters and present different information. In both cases, setup is not hard, but it is different for each device.
Figure 2 shows the data presented to the master device. You must program the master to retrieve this data from the device and then add special code to change the information (scaling, format) to the required form for each vendor.
These differences complicate installation.
Figure 2: Data as presented to the master by vendor A and vendor B device
Byte 0 to 1: Status word (bit mapped as per tank, 0=OK,
1 = error)
Byte 0 to 3: Distance measure in tank 1
Byte 2 to 3: Level in tank 1 as a percentage of span multiplied by 100
Byte 4 to 5: Status for tank 1
(value of 1000 = OK)
Byte 4 to 5: Level in tank 2 as a percentage of span multiplied by 100
Byte 6 to 9: Distance measure in tank 2
Byte 10 to 11: Status for tank 2 (value of 1000 = OK)
Both devices can be configured using configuration software such as Siemens' Simatic Process Device Manager (PDM). This software is open for use by all vendors on HART or Profibus protocols.
You can choose between defining the device as a "Generic Level Profile V3.0 Class B" device or as the device itself. For simple applications, you can define both devices as a "Generic Level Profile V3.0 Class B" device.
In Figure 3, the definition of a tank is given for the profile (as defined in the Profibus profile standard). Now you have only one set of core parameters to remember.
There is just one program to load and maintain. For simple applications, you have just one set of configuration parameters. You do not need special proprietary cables; you just need access to the network.
Built into the Profile is a definition of the output and a method for scaling. Scaling is done in the device by using an analog input block. The output of this block consists of IEEE floating representation of the process variable plus a status byte. This is shown in Figure 4.
Figure 4: Data as presented to the master by Profibus profile V3.0 device
Byte 0 to Byte 3: IEEE floating point representation of the process variable
Byte 4: Status byte (status codes are defined as per Profibus profile standard)
No special code is required in the Profibus master to do scaling or to monitor status. Also, the output from vendor A's device and the output from vendor B's device will be the same.
With or without
This article shows how profiles simplify installation and configuration of field devices.
Without profiles, you have:
Two software packages
Two communication cables (to talk to device)
Two setup configurations that do not look similar
Two routines in the master to adjust the incoming data
Two routines in the master to monitor the health of the devices
Added code in the HMI to indicate error status
With profiles, you have:
One software package
No special communication cables (you talk to the device over the network)
One setup configuration
No special routines in the master for adjusting data
No special routines in the master to monitor the health of the devices
No special code in the HMI to indicate error status
James Powell, P.Eng, is Industry Consultant, Communications Systems, with Siemens Milltronics Process Instruments Inc.