Networking Considerations for Electric Actuation

Several criteria must be evaluated separately and holistically to make a truly informed decision about networking. These include:

• Networking protocol type
• Network latency (throughput) and realistic capability
• Network reliability
• Network security

To focus discussion on selection criterion, this article will touch on the protocols currently most popular in the electric actuator market as well as how these protocols rank with respect to each other based on the selection criteria. These protocols include:

• Modbus-RTU/ASCII (referred to as Modbus Serial)
• DeviceNet
• Foundation Fieldbus H1 (referred to as FF-H1)
• Profibus-DP
• Profibus-PA

Also, to provide “food for thought,” this article discusses several protocols at a high level so the topic of network security can be addressed and considered. These protocols include some of the more popular Ethernet-based protocols of:

• Modbus-TCP
• Ethernet-IP
• Foundation Fieldbus High Speed Ethernet (FF-HSE)
• ProfiNet

Networking Protocol Type

The first step in evaluating which networking technology to use for interface to intelligent electric actuators is to determine what type of communications protocol to use. The more popular classifications for protocol are proprietary and open. The selection process for the type of communications protocol to use is relatively simple today because most of the widely available ones today are industry open protocols. However, whether the overall networking solution involves an industry open protocol or a proprietary protocol, some things to consider before making the final selection are:

• Technical support for the protocol may be the most important criteria to consider. If the protocol is not well supported through human interaction, protocol documentation, standards committees or other means, the possibility for successful implementation is dramatically affected.
• Longevity of protocol must be considered during evaluation. Because protocols are typically “parented” by a company or a development organization/committee, the overall longevity of protocol is affected by the size of the supporting entity, the overall install base for the protocol and the present life-cycle status for the protocol (i.e., whether a replacement protocol has been endorsed).
• Overall ease of design and implementation are important topics to consider. Some protocols may require relatively little “overhead equipment” when implementing the overall network. Other protocols may require several networking appliances to support proper implementation (e.g., media converters, networking gateways, etc.). There are also differences in the level of understanding the various protocols required to support the different phases of the installation lifecycle (e.g. – procurement, design, installation, startup & commisiong, and maintenance).

Although all of the major electric actuator manufacturers offer a proprietary network solution in one form or another, designers must be prepared to select the final solution based on what is best for the design application. In most cases, using open protocols—such as Modbus, DeviceNet, FF-H1, Profibus-PA and Profibus-DP—will reduce the overall number of components required to implement the network, will provide more technical sources for network support and will improve the characteristics associated with other networking design principles (as discussed below).

Network Latency – Realistic Capabilities

All networking protocols and physical layer designs are capable of supporting particular baud rates (network speeds). However, depending on the protocol, there are typically different levels of performance expected based not only on the baud rate, but also the design (efficiency) of the protocol itself. Thus, to make a truly informed decision about a networking strategy, some of the “nuts and bolts” must be considered with respect to network latency. These include:

• Data throughput analysis must start by first evaluating how much data must pass between an intelligent electric actuator and the associated upstream automation system. Evaluating the variety of offerings from the major electric actuator companies reveals that it is not unreasonable to expect approximately 480 bits (60 bytes) of data to be exchanged between the read and write cycles (per actuator). About 60% of this data is used in the read cycle (from the automation system to the intelligent electric actuator), and 40% is used in the write cycle.
• Network implementation baud rate must be evaluated so that a basis for design/performance may be developed. This is critical in supporting the overall expected and required responsiveness of the network (process control) interface. For the industry open protocols, the baud rates typically range from 19.2 kbps to 12 Mbps. These rates depend upon physical layer implementation (whether fiber optic or copper-based cable is used), as well as what is supported by the equipment manufacturer.
• Overall protocol message sizing must also be evaluated. To accurately determine how long it will take to move the data to and from the actuator, the “frame size” must be known. For instance, the frame size for a DeviceNet message is comprised of 47 bits (~6 bytes) of information. However, the allowable data size for a DeviceNet message is only 64 bits (8 bytes). Thus, the overall read/write cycle for DeviceNet would be 111 bits (~14 bytes) per electric actuator.
• Actual network performance relative to process control requirements must be evaluated using the information discussed above. To illustrate, if a DeviceNet network would be used for control/interface of 30 intelligent electric actuators, would this support proper process control at 500 milliseconds execution? To answer this question, we can evaluate it as follows:
  • DeviceNet can operate at a maximum baud rate of 500 kbps with up to 64 nodes using copper-based “thick cable.”
  • As stated earlier, about 480 bits (60 bytes) of read/write data is typical for intelligent electric actuators.
  • DeviceNet requires 94 bits of framing for a complete read/write cycle (47 bits per read or write message).
  • Recall that approximately 60% of the total actuator data is transferred on the read cycle (from the actuator to the automation system) and 40% of the actuator data is transferred on the write cycle (from the automation system to the actuator).
  • To fully transfer all the available actuator data to the automation system, the number of read cycles per actuator would be 5 (480 bits x 0.60 = 288 bits; 288 bits/64 (bits/cycle) = 4.5 cycles; round up to the next whole cycle = 5 cycles).
  • If all write data were provided to the actuator from the automation system, the number of write cycles per actuator would be 3 (480 bits x 0.40 = 192 bits; 192 bits/64 (bits/cycle) = 3 cycles).
  • Thus, five overall cycles are required for communications between each actuator to completely interface all data to and from the automation system (as a worst case). This equates to:
    • Read data: [4 cycles x (47 bits of framing + 64 bits of data)] + [1 cycle x (47 bits of framing + 32 bits of data)] = 444 bits + 79 bits = 523 bits.
    • Write data: [3 cycles x (47 bits of framing + 64 bits of data)] + [2 cycles x (47 bits of framing + 0 bits of data)] = 333 bits + 94 bits = 427 bits.
    • Overall read/write cycle = 523 bits + 427 bits = 950 bits. This equates to 28500 bits for 30 actuators.
    • At 500 kbps, the interface time for one complete data exchange for a network including 30 actuators would be: 28,500 bits/500,000 (bits/second) = 0.057 seconds (57 milliseconds).
    • Assuming an approximate time of response for each actuator to be 15 milliseconds or less, the total response time that could be expected for each actuator would be 75 ms (15 ms/cycle x 5 cycles = 75ms). With 30 actuators on the network, the total response time accumulated for the network could be 2.25 seconds.
    • Assuming this DeviceNet network includes no other points of interface, we can expect 30 actuators to require approximately 2.31 seconds for one full read/write data exchange. Thus, it is easy to determine that this would not support a 500 millisecond task execution time in a reliable manner.

Although the sample calculation above would imply that DeviceNet is not capable of supporting 500 millisecond task execution, a realistic network implementation will likely utilize a much smaller data packet per actuator and the actual network response times will also likely be faster than the figure used to support the calculations. Thus, when evaluating the industry open protocols, we can expect only one protocol to be realistically limited with respect to network latency and satisfying a 500 millisecond execution time—FF-H1. FF-H1, according to the Fieldbus Foundation’s publication AG-181, should be limited to 6 nodes in order to support 500 millisecond execution. When satisfying 20% spare capacity for future growth/expansion, this equates to 5 nodes used and 1 node available for expansion.

Network Reliability

The next step in evaluating intelligent electric actuator network interface is to consider the overall reliability of the control interface to the automation system. The approach to consider is simple in concept—hardwired IO control interface was a viable and functional strategy for years. It is still functional so using a networking control interface should not sacrifice performance or reliability for the sake of using the latest technology. Based on this philosophy, the overall reliability of the network solution should be as good as, or better than, that of a hardwired IO interface. Because of this, elimination of single points of failure is one design principle that must be addressed. If single points of failure cannot be eliminated, the overall risk of failure and its effects must be properly mitigated.

Thus, the overall single point of failure effects for a typical hardwired IO interface system should be understood to support proper selection of networking methodology and application. Some points to consider are:

• Hardwired IO modules are typically installed as non-redundant. Failure of a single module typically results in loss of all IO signals associated with that module.
• Hardwired IO module densities vary based upon signal type. Digital IO modules typically have a density in the range of 16 to 32 points. Analog IO modules typically have a density in the 8 to 16 point range.
  • To mitigate the risk of a single master, single cable or single master/single cable network application, the overall allowable number of nodes should not exceed a reasonable “tradeoff” value with respect to hardwired IO module density. A recommendation of 16 nodes maximum (12 nodes used, 4 nodes spare) is considered good engineering practice for single master/single cable networking topologies. Using this as a basis of design can equate the risk of network failure to the same (or a similar) level of risk associated with the hardwired IO control interface model. Limiting network loading to 12 nodes used/4 spare nodes is recommended for DeviceNet. Profibus-PA should also carry this limitation when designed with single Profitbus-DP/PA link/couplers, single Power Conditioning Units (PCUs, or when installed without an Advanced Diagnostics Module (ADM); however, higher density may be considered if the only single point of failure is the cabling. The 16 node limit is also applicable to Profibus-DP and Modbus, depending on network design.

Network Security

The “last” design consideration for electric actuation network interface involves data security. Because the network interface is used for both status and control interface, security of the network interface between the automation system and the intelligent electric actuators must be considered. Thus, in the power industry, guidelines associated with cyber security have been developed and are in varying stages of application to power plants, as well as the electric grid. In other industries, cyber security may be defined or merely dictated by the company’s IT policies. Regardless of the situation, good engineering practice is to exercise caution when using protocols or networking applications that use layer 3 of the OSI 7 layer model (i.e., “routable protocols”). When considering routable networks, the most dominant networking technology encountered is Ethernet. Ethernet can be used in several different applications and can support several different protocols of communication (from industry open protocols to proprietary protocols).

Several routable protocols can be considered. There are several varieties of Fieldbus, including Modbus TCP, ProfiNet, FF-HSE, EtherCat, Ethernet-IP and more. There also are a variety of acceptable communications physical layers, including copper UTP/STP cable, IEEE 802.11 wireless, fiber optic cable, etc. And there are several methods of networking implementation/architecture as well. However, one common thread must be evaluated and addressed: How can information remain secure and how can operations remain reliable if routable protocols are subject to malicious attack? The answer lies in adding networking appliances, upgrading network appliances, adding software settings and possibly adding to existing physical security policies/procedures. The intent of this article is not to discuss all possible impacts of cyber security with respect to networking applications and economics. But one overall broad conclusion can be made: additional cost will be incurred in using routable protocols, either through adding prudently designed security measures or through lost opportunity after suffering a malicious attack.

Conclusion

Attaining more plant information, more operability and better troubleshooting capability through the use of networking control interface and intelligent electric actuators is a justifiable goal; however, progressing down the path of application without thinking through the overall design principles and end results will likely leave a sour taste in anyone’s mouth.

Brandon Parker is Plant Automation Systems Section Head, Energy Division, Black & Veatch Corporation, Overland Park, KS. Bill Breitmayer is National Sales Manager, Power Industry Products Division, AUMA – USA, Overland Park, KS.