Profibus PA Technical DescriptionTechnical overview of Profibus
Profibus as a family of protocols
Profibus is a family of protocols designed by Siemens to provide communications from real world sensors and actuators to area controllers. Profibus as a family of protocols was designed to provide a communications hierarchy for a PLC system, primarily in discrete manufacturing and building automation. Profibus has historically been used in the process industry for peripheral processes such as packaging lines, and for control of prime movers such as motor and pumps in a motor control center. Extensions to the Profibus architecture in recent years are intended to extend the market of Profibus to process automation. Since Profibus was originally designed for factory automation, process automation solutions using Profibus will always be sub-optimum.
To accomplish the wide variety of applications envisioned, Profibus is actually four separate protocols grouped under the common umbrella name of Profibus. The protocols are named Profibus FMS, Profibus DP, Profibus PA, and Profibus PAE. In addition, there are a number of totally proprietary protocols used by Siemens that the user must contend with when commissioning a system. This technical description will give an overview of the Profibus communications architecture and intended applications. Then this technical description will go into depth on one of the Profibus protocols, Profibus PA.
The Profibus communications architecture
Profibus is an communications architecture intended to support communications between sensors/actuators and an area controller. For higher level communications Profibus connects to an Ethernet backbone in the plant. A functional diagram of the levels of Profibus is given below.
Hardware Topology
Figure 1 Hardware Topology
In the above diagram, the hierarchy of Profibus protocols can clearly be seen. At the top of the hierarchy is an Ethernet backbone. This will not be covered in this discussion. Instead we will cover the various levels of Profibus offerings.
The highest level in the Profibus hierarchy is Profibus FMS. Profibus FMS is essentially a backbone communications link for cell level control. Attached to Profibus FMS are operator interfaces, and control equipment ranging from CNC machine control systems to PLC and DCSD systems. Profibus FMS is the backbone of the Siemens PLC system. Technical information on the protocol is available so other equipment manufacturers can develop products that interface to the Profibus FMS hi-way.
The next level down in the Profibus hierarchy is Profibus DP. Profibus DP is a protocol designed to connect discrete devices such as motor starters, or on-off valves, limit switches, and dedicated push button operator panels. Note that Profibus DP does not communicate directly with Profibus FMS. Some type of interface box is required to communicate between the two protocols.
The next level down is Profibus PA. Profibus PA uses a set of extensions to Profibus DP called DPV1.1 to make the protocol compatible with some operational requirements of process plants. Again there is a communications interface between the Profibus PA network and the Profibus DP network. The simplest low cost card costs ~$700. Note that Profibus PA cannot connect directly with controllers or user interfaces in this architecture. It must communicate over the Profibus DP bus.
Application and “Standards” Topology
The software topology of Profibus consists of a number of different pieces presented under the umbrella of a EuroNorm. The standard is EN50170. Based on this umbrella, the PNO (Profibus users organization) and Siemens uses the PNO to portray Profibus as a single standard. In reality it is a set of different protocols grouped under a common umbrella. Note that since there are at least 3 different protocols covered under the EN 50170 EuroNorm, there is in effect no single standard. The different Profibus protocols and their applications and relations to the EuroNorm are shown below.
Figure 2 Application and “standards” Topology
As can be seen in the above figure, there are three different Profibus protocols covered under the same EuroNorm. . Other protocols such as FIP from France and P-Net from Denmark are also Euronorms. These protocols have different intended uses, use different physical layers to communicate, and have different intended industries and applications. This shows clearly that EN 50170 is not a standard, but is in effect a collection of proprietary application and country specific protocols under a common umbrella.
Communications stack Topology
Below is a communications stack model for the three Profibus protocols. The intention of this diagram is not to make the reader communications stack experts. Rather it is to help the reader understand that these are three different protocols, and even within the EuroNorm, many parts of the communications stack are proprietary.
Figure 3 Communications stack Topology
Lets start from the bottom, the physical layer. There are several different physical layers here. They include Fiber Optic, RS-485, and the IEC 1158-2 fieldbus physical layer standard. These different physical layers are interconnected only through gateways or interface modules. This means that every Profibus PA segment must have an interface card or gateway to connect it to Profibus DP. This interface increases the cost, and reduces the performance and reliability of Profibus PA compared to Foundation fieldbus. Also, existing Profibus DP installations must be upgraded to use Profibus PA. This requires a minimum of a plant shutdown.
The next layer is the Data Link layer. Profibus DP is a real time master-slave protocol. It does not support peer to peer communications. This means that devices cannot talk to each other, just to the master. Profibus PA is an extension to Profibus DP, and it cannot support devices communicating with each other. It also supports only one master. Profibus FMS supports real time peer to peer communications. Devices on a Profibus FMS bus include controllers, operator interface devices, machine control devices, etc. No field devices are currently supported at this level. The net result of this structure is that communications on a specific bus is deterministic, but communications between the busses through the couplers or links, and control execution is not deterministic. The result is a loss of deterministic real time control. In addition, the data is not time-stamped until it’s processed in the controller. This means the real time nature of the information is lost.
The next layer with any content is layer 7, the application layer. Only Profibus FMS has an application layer. The application layer has the features needed to support functions such as Peer to Peer communications. This indicates that Profibus PA will not support Foundation fieldbus functions such as peer to peer communications as needed for effective field based control.
The next layer is the user layer. The user layer has one basic function. It is to provide the standard profile for Profibus devices. The profile allows the user interface to understand the information it receives from the bus.
Profibus applications
The reason for the lack of critical services may reflect the origin of the Profibus family of protocols. Profibus is designed to support applications such as discrete parts manufacturing and building automation. These applications do not generally require real time, peer to peer communications, or true multi-master support. The extensions provided for Profibus PA map into existing services, and therefore, don’t provide these critical functions needed for process control.
Profibus PA introduction
Profibus PA is the extension to the Profibus family intended to support the process industries. One of the differences between Profibus PA and Profibus DP is in the physical layer. Profibus DP is RS-485 and fiber optic, and can run at a variety of speeds from 12 MBPS down to ~40 KBPS. The range of speed reflects different physical layers (fiber optic vs. wire), and the types of equipment attached to the bus. Another difference is in the profiles of the devices attached to the bus. The significance of these differences will be covered later.
Profibus PA uses the IEC 1158-2 specification for fieldbus physical layer. This means that Profibus PA had the same rules for wiring as FOUNDATION Fieldbus H1. These include intrinsic safety, power over the bus, and the types of topologies associated with FOUNDATION Fieldbus.
Profibus PA topology
Figure 5 Profibus PA topology
Figure 5 above shows Profibus PA. Profibus PA attaches to a host system using Profibus DP. A gateway is used between the PA and the DP busses as they use different physical and link layers. The use of this gateway means that Profibus PA has more hardware pieces, and more failure points than Foundation fieldbus. A comparison of the differences is shown below.
Figure 6 Profibus PA VS Foundation fieldbus topology
Note that the field device topology is identical between Profibus PA and Foundation fieldbus. Since they use the same physical layer this is expected. A brief review of the Profibus PA physical layer topology and components is given below.
Figure 7 Profibus PA wiring rules and components
The physical layer of Profibus PA uses twisted shielded pair wiring with the same total length (1900 meters) and spur length limits (90 meters) of Foundation fieldbus. It uses the same 31.25K communications speed. It also uses the same terminators at both ends of the wire. The same tree and branch with spurs topology is supported for both Profibus PA and Foundation fieldbus. Power for the bus is identical. Profibus does claim an advantage of lower power consumption per device for Profibus PA vs. Foundation fieldbus. This claim is made based on Profibus PA as a simpler protocol, and therefore devices are assumed to use less power. This claim is not necessarily true.
The system topology in the Profibus environment includes extra bus couplers, and an extra bus, Profibus DP. There are a number of critical performance and reliability issues associated with the system topology of the Profibus system. Many of these issues are associated with the bus couplers beyond the extra cost of the hardware. They are described below.
Bus couplers and bus links
The bus couplers on a Profibus system can’t be made redundant at this time. It is not known if this is a current implementation problem, or a long-term structural problem due to the Profibus DP bus. There is no mention of DP redundancy in Profibus literature reviewed. This implies a long-term structural problem.
The couplers dramatically slow down the Profibus DP bus. Profibus claims communications speeds up to 12 MHz for Profibus DP. When there is a Profibus PA gateway attached to the DP bus, the maximum bus speed is less than 100 KBPS. If Siemens couplers are used, the maximum speed is less than 50 KBPS. This implies that you don’t mix Profibus DP devices and Profibus PA links on the same Profibus DP bus. It also means that there is no more than 3 Profibus PA busses attached to one Profibus DP bus. Where Siemens couplers are used, the limit for performance reasons should be no more than 1 PA bus per DP bus. With typical Profibus PA loading limits of 8 to 10 devices per segment, the total device loading per Profibus DP link is 10 to 30 devices. This dramatically increases the cost of DP and PA solution.
If couplers are used, the physical layer for the Profibus DP section is limited to wire.
Customer reports show that with more than 10 PA devices on a bus coupler, performance becomes unacceptably slow. This limits practical PA bus loading to 10 devices per segment, and practical DP bus loading to 20 devices on 2 segments. Installations documented by the PNO show 3 to 8 devices on a PA segment. Profibus DP loading in these installations show less than 16 PA devices communicating through couplers on a single DP bus.
There is a second way to connect Profibus PA busses to a Profibus DP bus. That is to use a device called a bus link. Installations showing more than 16 PA devices attached to a single DP bus use the PS to DP link instead of bus couplers. The figure below shows the differences between a bus coupler and a bus link.
Figure 8 Bus couplers and bus links
A key difference is that with the bus coupler, the host talks to the devices through the coupler. In a link-based system, the host talks to the LINK PLC. The host sees only the link PLC. The link PLC then talks to the individual devices. This means Profibus PA requires many more configuration operations, as the devices must be fully configured, then link must be fully configured, and then the host PLC must be fully configured. Any changes must be done in all three locations. If there are errors, at a minimum individual devices will not work. In one installation where detailed information is available, a Texas Instruments PLC is used as the DP/PA link. Again no provision for redundancy is shown. Redundancy of the DP/PA link does not appear to be available.
When a DP/PA link is used, the Profibus DP bus can have any physical layer and communications speed available on Profibus DP.
The basics of defining Profibus, defining Profibus applications, and defining hardware and topography are basically complete. Next the functionality of Profibus PA will be shown, and specific weaknesses of Profibus PA vs. Foundation fieldbus will be covered.
Profibus PA functionality
Profibus PA is built on the technology of Profibus DP. It lacks many features considered critical for its’ stated purpose of process control. Understanding the technology will help the reader understand features that are missing or improperly implemented for the intended purpose of process control. Apology is offered in advance for the level of supporting detail used to show the problems with Profibus PA.
Functionality for process control
The stated purpose of Profibus PA is to extend Profibus to mission critical process control. The minimum requirements for process control are for safe end effective control. In addition, economic pressures require that a process control architecture increase availability, and reduce variability within the process. Finally, requirements are continually tightening. This means that the ability to continuously improve plant automation is also required. Profibus PA will be viewed with these factors in mind.
Safe process control
Safe process control implies reliability and performance sufficient to maintain control. The lack of redundancy available in DP to PA couplers and links, DP busses, and the PLC based controller used means that Profibus PA should only be used on processes that can tolerate failures. A working control loop requires the following components in a Profibus system:
1. Working transmitter
2. Working PA power supply
3. Wire integrity
4. A working PA to DP coupler
5. A working power supply for the PA to DP coupler
6. A working DP bus
7. A working DP interface card to the PLC
8. A working PLC controller card
9. A working PLC power supply
10. A working valve
Added components may be required, depending on the topology of the system. Contrast this to the components required for controlling the same loop using Foundation fieldbus:
1. A working transmitter
2. A working FF power supply
3. Wire integrity
4. A working valve
The above list reflects the substantially reduced number of components needed for control in a Foundation fieldbus environment. Also note that the components eliminated are mostly active electronics. Clearly a Foundation fieldbus implementation is much more reliable from a hardware MTBF standpoint. The diagram below shows the differences.
Figure 9 minimum hardware for a FF loop and Profibus PA loop
The Profibus users organization claims that Profibus supports control in the field. They also claim that they are working on function blocks that will do control in field devices. Current Profibus specifications and design documents do not include these functions.
Another factor for safe and effective control is a communications architecture that eliminates the effects of jitter and aliasing. Jitter causes increased variability. It is caused by not having the process control executed on an accurately repeating schedule. This causes the control to sometimes “over-react,” and sometimes “under-react.” Aliasing causes control action to be taken on the wrong process “signal.” It’s caused by not reading the process information on a correct schedule, or failing to properly condition the process information. This can cause “noise” to mask the true process signal. Both can reduce the quality of process control, or even create an unsafe operating condition. Foundation fieldbus is designed to eliminate these effects while Profibus PA is not.
The way to reduce jitter is to execute the control schedule on an exact time schedule. Foundation fieldbus does this. Each device has a common sense of time. Control is executed on time to within a few milliseconds. This effectively eliminates jitter. Profibus devices and the Profibus PA network have no sense of time. In addition, the control information must go through several gateways to get from the field to the controller. The delays are not constant from cycle to cycle. This causes jitter. Jitter can be addressed by either synchronizing reading the process tightly to control execution, or by taking several process readings (3 minimum) and calculating the value to use from these several readings. This is called over-sampling. Foundation fieldbus synchronizes reading the process variable and performing the control function. This means the PV must be read once each time control executes. Since Profibus cannot do this, they must over-sample. This means a Profibus device must have the process variable read at least 3 times for every time control executes. This increases the communications load on the bus. The reason for the Profibus device limit is more clear.
Function blocks
Both Profibus PA and Foundation fieldbus have function blocks. The types of blocks offered, and the functionality within the blocks is very different. This reflects inherent differences in the design and functionality of the protocols. Profibus PA is a very limited master slave protocol. A field device is a slave device and can only respond to a command from a master. For example, if a Foundation fieldbus device is experiencing a problem, it can send an alarm. If a Profibus PA device is experiencing a problem, it cannot report it unless the host specifically asks. It’s designed literally to replace 4-20 mA. Control continues to reside only in a host. Therefore the protocol is designed to provide process variables and basic status information, and receive control outputs to position a valve. As such, its’ blocks are very simple, and limited to basic input and output functions.
Foundation fieldbus is designed to run control on the bus. Therefore devices talk to each other. And devices are intelligent. They can initiate communications. Control can be completely run on the bus in the field devices. Therefore there is a very rich function block set including all the block types needed for basic and advanced regulatory control.
There is a huge impact of master-slave communications and over-sampling on the message load in the bus. For example, to execute a control loop on Foundation fieldbus using control in the field devices, one communication must take place each time the loop executes. This is the message sending the process variable from the AI block in a transmitter to the PID in the valve. Since the AO is also in the valve, no external communication is used. In Profibus PA the situation is quite different with 10 messages best case and 16 worst case needed to execute the same loop. Here is how it works:
Figure 10 messages for executing a Profibus PA loop
Profibus is master slave, so the host tells the transmitter to send the PV, and the transmitter does. Two messages. Then because Profibus must over-sample to avoid aliasing, it repeats this process two more times. Total so far is six messages. Next the host asks for device alarm messages, and a response is given. Two more messages. Finally the host gives the valve a new value and receives a response. Two more messages. The total is 10 messages. Profibus has no standard for system services. This means that the host implementation may require the host to pole the alarms, and the valve every time it poles the transmitter, even if there is nothing for them to say. This brings the total to 16 messages. This is critically important because of the 31.25k speed of the segment. Profibus PA will soon run out of bandwidth on the segment.
Profibus PA in the project environment
The Profibus users organization claims large project savings using Profibus technology in the project environment. It is important to understand where Profibus PA and Foundation fieldbus have exactly the same project impact, where Profibus claims to have advantages over Foundation fieldbus in the project environment, and where Foundation fieldbus is superior. A sample of Profibus project savings claims is given below:
Figure 12 claimed installation savings for Profibus PA VS 4-20 mA
The diagram above shows claimed project savings for Profibus PA. These savings will look just like the savings for Foundation fieldbus. In fact, the savings are identical. Here is why. The engineering savings are for drawings. Since Profibus PA and Foundation fieldbus use the same physical layer, the hardware for the bus and the bus topology is identical. So are the savings. The assembly saving is for the labor needed to wire and connect devices. Again, since the physical layer is identical, so is the labor needed to assemble the solution. Finally, the hardware is the price for devices, junction boxes, cables, etc. This is for everything up to BUT NOT INCLUDING the system interface. Again, Profibus PA and Foundation fieldbus use essentially the same hardware. So they would have the same hardware savings. The net-net is that designing, assembling, and purchasing hardware are nearly identical for Profibus PA and Foundation fieldbus if you have the same number of devices per segment. With the message loading problems shown above, Foundation fieldbus may have wiring project savings due to more devices on a segment.. Benefit claims for Profibus PA usually stress these features.
The project savings in the Foundation fieldbus environment are in the areas of configuration, checkout, and commissioning of the system. In this environment Foundation fieldbus is clearly superior to Profibus PA, and the Fisher-Rosemount PlantWeb solution is clearly superior to other Foundation fieldbus implementations. Many of the advantages of Foundation fieldbus are the result of features in the protocol, and Profibus PA would require major structural changes to implement the features. Some of these features fall in the area of system management, and have a large impact on project cost.
System management
System management is an area that does not have an international standard. There are standards committees working on the issue, but no standard exists to date. Many of these features may seem small, but each can mean minutes or hours of time on each device or segment implementing and debugging the installation, or many hour of configuration. Add up the time for a large number of devices on a project, and the direct labor is large, and project delays expensive.
Address assignment
In Profibus PA, addresses must be entered up to three times. In devices addresses are set for devices using DIP switches or user entered software addresses. These method provides lots of opportunity for error. Wrong addresses can be set, and multiple devices with the same address are possible on a segment. In addition, the addresses must be configured in the host. If the host address for the device and the device internal address do not match, the device does not operate. If a new device needs to be added to the segment, the segment must be shut down, and the device address and other configuration parameters must be configured in the host. Then the segment is restarted. The net-net is the Profibus PA method of addressing requires the user to configure the device, the host, and then debug differences manually. And adding a new device requires that the segment be shut down, reconfigured, and restarted. Even when a segment is configured and operational, failed devices have caused bus faults the have caused controller restarts. The bus, and therefore sometimes the controller, cannot be restarted without repairing the failed device. This means device additions and sometimes device failures result in plant shutdowns and lost production.
With Foundation fieldbus, when a device is added to the bus the host automatically recognizes the device. The address can be automatically assigned with all reserved and used addresses protected, thus protecting the user from error. New devices can be added without shutting down the segment. The host recognizes new devices, even on a running segment. Devices can be added, commissioned, and used while the rest of the segment remains in operation.
Device tags and tag search
Foundation fieldbus supports tags in the field devices. Profibus PA only allows tags in the host. This means that any Foundation fieldbus device can be located by asking for a tag. With Profibus PA, the tag database must be manually entered into the host. It also means that configurations for foundation fieldbus devices can be compared with the host database based on tag. With Profibus devices can only be accessed by address, so verifying the correct device is difficult. Configuration errors can sometimes only be found by attempting to start up the segment. Fixing the errors requires shutting down the segment, fixing in several places, and then attempting to restart the segment. This can be a VERY time consuming iterative process.
Interoperability
Interoperability defined
Interoperability is defined as the ability to combine fieldbus devices from multiple vendors without loss of device functionality or degree of integration with the control system or host. Interoperability allows the user to select the right device from the right vendor for the application regardless of the host. There are several ways to achieve interoperability. One way is too narrowly defined allowed functionality. It’s sort of the one-size fits all approach. Another way is to provide a mechanism for devices or devices and hosts to understand each other even if new functionality is involved. Profibus has elected to limit functionality. Foundation fieldbus has elected to provide ways to understand new functionality.
Profibus PA interoperability limitations
Profibus PA does not actually talk to a host. Profibus PA talks to Profibus DP, and Profibus DP talks to the host. This means that Profibus PA has to fit within the structure of Profibus DP. The method used to fit Profibus PA into Profibus DP is profiles. The profile defines how Profibus PA maps into Profibus DP. This is significant because Profibus DP was originally designed to support devices in a manufacturing or building automation applications. It was later extended to support discrete devices in peripheral process applications such as packaging or motor control. The types of equipment supported by Profibus PA are quite limited as shown below:
Transmitters:
Temperature, Pressure, Level, Flow
Actuators:
Valve, digital I/O
Controllers:
None
A Profibus profile has two parts. The first part has basic information on the tag, process variable, status, basic limits, alarms, and other variable setup information. Remember, the profile exists in the host, not the device. This is the part of the profile that is “interoperable.” That is, the host knows what the information is and how to use it. Each profile may have manufacturer specific parameters. These parameters may or may not be interoperable and understood by the host. The contents of the profile are shown below:
Figure 13 Profibus PA profile and vendor specific parameters
The device has two information components. The first is the PA profile, and the second is manufacturer specific information.
How Profibus interoperates with hosts
There are two kinds of hosts in the Profibus PA world. The first host is usually a controller. It can understand only the basic profile information. The second type is a configuration station. This type of host may understand both the basic and manufacturer specific parameters for a specific manufacturers’ devices. It may not understand manufacturer specific commands from another manufacturer. The types of hosts and the degree of interoperability are shown below:
Figure 14 Profibus PA device to host interoperability problems
In the above diagram, we see equipment from several vendors. The controller is provided by one vendor, and the two field devices are provided by two other vendors. The configuration tool shown is provided by one of the device vendors. The basic profile can be used by the controller and configured by the configuration host. The vendor-specific information in the field device CANNOT be used by the controller. This means that if a device offers functionality above that in the standard profile, the control host cannot use that functionality. In addition, the configuration host can only work with the vendor specific parameters from that vendor’s devices. This means that a customer may have a large number of configuration tools, potentially one for every device type in the plant. This problem is so severe that some vendors are providing special ports on their field devices so that custom made devices specific configuration tools can be connected to the device without using the Profibus DP and Profibus PA links.
Configuration restrictions for couplers and links
The technology of the Profibus system imposes restrictions on where you can configure devices. As mentioned earlier, the host talks through a coupler to a device. This means that a configuration host can talk through a coupler to configure a device. The host does NOT talk through a link to a device. The link box is basically a database mapping box. The host talks to the link box, and the link box talks to the devices. It does this by the data map. The consequence is that a configuration host cannot configure a device through a link box. The configuration tool must be linked to the Profibus PA link directly, or through a special port on the link box.
Conclusions on Profibus PA technology
Profibus PA has a physical layer that is appropriate for process applications. The rest of the Profibus PA communications stack, user layer, and implementation techniques reflect a history unrelated to the process industry. Profibus PA lacks the features needed for reducing variability and increasing the profitability of process control. It also lacks the features needed to take broad advantage of innovation and new product features. The implementation is hardware intensive and user-unfriendly. Finally, performance can be poor. Profibus PA can probably be used in a satisfactory way in static, slow moving, monitoring applications. It is adequate to replace 4-20 mA analog in those types of applications. But it is not a technology that will support continuous improvement or competitive advantage for the user. In the future, processes based on Profibus PA technology will fall behind processes automated using more competent protocols such as Foundation fieldbus.
