Industrial control systems (ICSs) manage everything from food-processing plants to automotive production lines that bring humans and robots into close proximity. Industrial automation spans a wide range of control systems from simple programmable-logic controllers (PLCs) to supervisory control and data-acquisition (SCADA) systems and distributed control systems (DCSs).
Related Articles
- Ethernet Dominates Industrial Environments
- Ethernet Rules Networking--And It's Still Growing
- Caught In The Ethernet
Automation systems often control multiple devices in a synchronized fashion. PLCs generally are end nodes for more complex control systems. They are simple to program, frequently using a rule-based “ladder-logic” system. These days, PLCs are microcontroller-based systems that may have a procedural programming interface. In any case, a typical PLC will offer rugged I/O and real-time synchronization. Today’s PLCs may have network connectivity as well. A network does not affect the I/O side, but timing and synchronization will be an issue.
This file type includes high resolution graphics and schematics when applicable.
Timing’s Role
Timing and synchronization are never absolute, but consistent results for an application are possible once timing parameters are known. Clock capabilities and synchronization between clocks will dictate whether an application is even possible. For example, marine chronometers that allowed celestial navigation to determine longitude revolutionized ocean navigation. Determining latitude does not require a timing component. The resolution of the clock did not have to be high, but clock timing drift was a problem.
Major projects like cellular telephone networks, the Large Hadron Collider (LHC), and the Global Positioning System (GPS) require high-precision timing. They need clocks with high resolution as well as low drift and jitter. Electronic clocks can meet these needs. Many of the latest microcontrollers incorporate very accurate on-chip clocks. Off-chip clocks are available with even better performance.
Network timing and synchronization are important. The Network Time Protocol (NTP) was developed to keep clocks in sync across the network. NTP is not bad when trying to sync logs with a timing resolution of a second. It can handle industrial processes that do not require high resolution or very low jitter. More demanding applications may require the IEEE 1588 Precision Time Protocol (PTP) standard.
Like NTP, IEEE 1588 can operate over a range of networks, but Ethernet tends to be the most common. The EtherNet/IP (Ethernet Industrial Protocol) industrial automation protocol runs on top of standard Ethernet hardware and protocol stacks. Applications can use it plus NTP and IEEE 1588 synchronized clocks. However, Ethernet is carrier sense multiple access (CSMA) with collision detection (CD). Packets can get lost due to collisions, which is not necessarily a good thing for ICSs.
Fieldbus systems like Profibus (Process Field Bus), Modbus, and CANopen provide better timing and synchronization support. They have more limited bandwidth, though, typically 1 Mbit/s, and limited connectivity on the order of 25 m. Ethernet is faster and designed for longer distances. Increased integration has put Ethernet on many microcontrollers and it is standard, versus most fieldbus systems that were more proprietary.
Ethernet Powerlink (EPL) uses standard Ethernet hardware. It employs its own protocol for better timing and packet delivery support. It also can use standard Ethernet hubs and switches. The use of special Ethernet hardware and software protocols can be found with EtherCAT, Sercos-III, and Profinet v.3.
Keeping The World In Sync
NTP is designed to keep remote computer clocks in sync with Coordinated Universal Time (UTC) within a few milliseconds. NTP was developed by David Mills of the University of Delaware, where it is still maintained. It uses a simple packet protocol between peers to exchange timestamp information (Fig. 1). The NTP algorithm processes the accumulated timestamps to adjust the clocks and compute the amount of jitter associated with the system.
The system is designed to work with any transport mechanism. The timing resolution and jitter will depend upon the overall system and network connections involved. NTP is available for use with every major operating system (OS) including Linux and Windows. The system can operate in a tiered hierarchy with a highly accurate clock at the root.
The IEEE 1588 PTP is more ambitious than NTP in terms of timing. It is designed to provide synchronization in the sub-microsecond range, but it only operates at the local-area network (LAN) level. It can be implemented in software on a standard Ethernet stack. Stack implementations provide more accurate synchronization, though, while hardware implementations are even better. All utilize the same protocol, yet it comes down to how quickly and accurately the timestamps can be exchanged. Synchronization on the order of 50 ns is common.
In an IEEE 1588 system, there is a master clock and slave clocks. Hubs and switches may be involved in the system as well. Normally, they will be IEEE 1588-enabled devices. In that case, they would have a transparent clock, also known as a boundary clock. Essentially, this clock is a slave to the master higher up in the hierarchy and a master to their subnet (Fig. 2). The use of a boundary clock eliminates the issues delay through hubs and especially switches that have an internal queue.
Hardware-based IEEE 1588 systems incorporate a timestamp unit (TSU) that works at the Media Access Control (MAC) level with a hardware real-time clock for very accurate timestamping of packets. Software-based timestamping is possible, but it reduces system accuracy. It may be sufficient, though, depending upon the overall timing requirements for the environment.
There is a big difference between unlocking a door within a minute on a daily basis versus firing off a signal every 100 ns with a cycle time of a millisecond. Choosing the correct timing mechanism will depend upon those requirements.
Industrial Automation Protocols
Timing is just the basis for industrial automation. Communication between devices is also critical. Customized protocols and controls are the bane of developers trying to build systems using standards-based platforms. Industrial automation protocols simplify this job.
Many of these protocols started as proprietary fieldbus implementations such as Profibus and Modbus. Profibus was developed in 1989 in Germany and is now managed by Profibus International. Modicon, now known as Schneider Electric, originally published Modbus in 1979. The Modbus Organization trade association took control of Modbus in 2004, providing an open and royalty-free industrial automation environment.
There are myriad other implementations. Many are still in use today with wide third-party support. Ethernet-based solutions may offer more performance, longer distances, and other features that fieldbus systems lack, but that matters little if the application does not require these features. Reliability, availability, and cost often trump new features.
Industrial-automation protocols provide an application-programming interface (API) defined around the communication protocol for monitoring and controlling devices. Most are implemented using a master/slave architecture. Many protocols extend into Ethernet implementations such as Modbus/Transmission Control Protocol (TCP). There can be upward compatibility issues such as limits that were imposed by fieldbus architectures like Modbus’ restriction of 247 devices per data link or the inability to determine the type or range of values that can be controlled.
The DeviceNet protocol was originally built for controller-area networks (CANs). This led to the Common Industrial Protocol (CIP), which is managed by the Open DeviceNet Vendors Association (ODVA). CIP over Ethernet is known as EtherNet/IP.
Protocols can be mixed and matched within an environment using gateways between device networks. This architecture tends to be much easier to implement and manage, though, if there is some level of commonality between the control areas. Examples would include a Modbus system linked via Modbus/TCP or a DeviceNet system linked via EtherNet/IP. Still, designers of SCADA systems may have to contend with mixed environments due to legacy concerns. Profinet uses TCP/IP and runs on Ethernet.
EPL is a deterministic real-time protocol that runs on standard Ethernet. It supports CANopen device profiles. It was introduced in 2001 and is now managed by the Ethernet Powerlink Standardization Group (EPSG). The openPowerlink project is available on SourceForge under a BSD license.
EPL adjusts the standard Ethernet Data Link Layer to address packet scheduling. The schedule has an isochronous phase and an asynchronous phase. Time-critical data is transferred in the isochronous phase. A managing node (MN) sends poll request messages to grant access to devices on the network, preventing collisions. The cycle time of the system depends on the isochronous phase, any asynchronous data, and the number of nodes to be polled.
The time slots in the isochronous phase do not have to be dedicated to a particular node. The MN can multiplex the slots. For example, if six slots and three nodes are required every cycle, and six nodes require access every other cycle, then the MN will let half of the second set use three slots each cycle. Data sent by a node can target any destination.
The isonchronous phase also can operate using poll-response chaining. In this instance, a single poll packet is sent in multicast mode. The nodes then respond sequentially, with each node waiting for the message of its prior peer. This reduces overhead and is useful when small amounts of data are sent in each packet. The device drivers for all nodes on the EPL network need to support EPL so this scheduling mechanism works properly.
The challenge for developers operating at this level is that timing, feedback, and control loops span the network. The timing challenges of a microcontroller-based, closed-loop system then look trivial in comparison. The micro may be able to handle very fast cycle times with high accuracy, but most of the timing and synchronization issues are under the designer’s control. At the network level, timing issues such as whether IEEE 1588 is available come into play along with the functionality provided by the network protocol.
Hardware-Based Industrial Ethernet
Standard Ethernet hardware can handle many industrial control applications. Add IEEE 1588 support, and even more demanding applications can be addressed. At this point, hardware-based Ethernet solutions are centered around 100-Mbits/s Fast Ethernet. 10-Mbits/s Ethernet is usually supported for legacy and low-speed requirements, while 1-Gbit/s Ethernet is available in some cases. IEEE 1588 Gigabit Ethernet solutions also are available.
Sometimes IEEE 1588 support is not sufficient, so other alternatives have been developed including EtherCAT, Sercos-III, and Profinet v.3. These solutions move timing and synchronization into hardware-specific Ethernet implementations. They usually can mix conventional TCP/IP traffic with real-time traffic, with real-time traffic having priority. Standard Ethernet cabling and connectors are used, but the use of standard switches and hubs can affect overall system-timing limitations.
This functionality comes as the cost of customized hardware, but hardware integration has come a long way. Microcontrollers are readily available with Ethernet MACs, and sometimes physical layers (PHYs) are built in. FPGAs typically have logic support for these real-time Ethernet implementations as well. Supporting any of these implementations in a microcontroller is a logical step.
For example, EtherCAT support is available in select Freescale QorIQ and Texas Instruments Sitara chips. XMOS has a software peripheral solution that supports Ethernet or EtherCAT. Altera and Xilinx have EtherCAT cores available for their FPGAs.
Sercos International supports Sercos-III. A joint committee from VDW (German Machine Tool Builders’ Association) and ZVEI (German Electrical and Electronics Industry Association) developed the Sercos (serial real-time communication system) protocol in 1987. Sercos-III is the latest incarnation that requires matching hardware support.
Sercos-III has a cycle update time as low as 31.25 µs. It can support up to 511 slave devices on a subnet. It also can detect a dropped physical connection within 25 µs. This is less than one cycle update time. Hot plugging of devices and peer-to-peer communication are supported. Its own Ethernet frame type allows it to coexist with other protocols such as EtherNet/IP, TCP/IP, and User Datagram Protocol (UDP). It supports safety functions up to SIL3 according to IEC 61508 via CIP Safety for Sercos. Sercos-III employs an XML-based device and profile description language.
The Profinet v.2 soft-real-time solution uses conventional Ethernet hardware. Profinet v.3, also known as Profinet IRT (Isochronous Real-Time), requires hardware support. It can handle demanding applications like motion control with cycle times of 1 ms and jitter accuracy of less than 1 µs while handling over 150 axes. EtherCAT also is a hardware-specific Ethernet implementation. Choosing between these hardware-based solutions and even software-based real time Ethernet options will often come down to application and legacy requirements.
EtherCAT tends to be more generic, since it specifies the hardware interface and low-level protocol. Invented by Beckhoff Automation in Germany, it is now managed by the EtherCAT Technology Group (ETG). It supports 65535 nodes. EtherCAT also supports low-voltage differential signaling (LVDS) and 100Base-FX fiber connections. As with many industrial automation networks, it supports a range of topologies include line, daisy chain, star, and tree.
An EtherCAT slave incorporates a pair of Ethernet interfaces so traffic can flow in a logical ring (Fig. 3). EtherCAT packets also can contain multiple datagrams for different nodes on the network. The respective node extracts its own data as necessary. This spreads the packet overhead across the datagrams instead of having a packet for each datagram. This approach is useful since many control datagrams are very small. The slave controller also can insert data into a packet as it is passed down the ring.
For applications that require higher levels of safety and redundancy, there are configurations such as dual loops that do not require a hub or switch. The system can continue to run even if there is a single node or link failure (Fig. 4). In this case, the master has two ports. EtherCAT supports master/slave, master/master, and slave/slave communication. EtherCAT’s simple frame definition allows it to work with any range of automation protocols, including the EtherCAT Automation Protocol (EAP).
Safe And Secure Automation
Safety tends to be the primary issue addressed by industrial-automation protocols, such as openSafety, which was conceived by EPSG. Certified to IEC 61508, it meets SIL 3 requirements. IEC committees have released it as a standard as IEC 61784-3 FSCP 13. Also, openSafety can be used with most major industrial protocols including Sercos III, Profinet, Ethernet/IP, Modbus-TCP, and EPL. The openSafety standard provides interoperability between systems and has been utilized in many industrial Ethernet installations.
In the past, many networks operated in isolation. Network connectivity has been a boon for the management of industrial systems. However, widespread connectivity also opens the door to abuse. Security is not inherent in industrial-automation protocols. Many hosts and slaves within these environments run standard OSs like Windows and Linux or use standard protocols like CIP. This leaves systems unprotected unless other means are taken to lock down a network.
Securing a system means locking down the host nodes as a start. Gateways also need to be secured, and direct linkage to corporate networks or the Internet must be avoided. The use of virtual LANs (VLANs) on network switches can be used to isolate industrial automation networks as well.