Data communications networks usually exist within an environment that is designed to accommodate people, with consequently little variation in temperature or humidity. Industrial control systems may be required to operate in conditions where extremes of temperature and humidity are common, or there is frequent or severe electrical interference. In addition to being more rugged, therefore, industrial networks need technology to be applied in a different way. Whilst a delay of a few minutes for a data communications network while backup and recovery systems kick in may be acceptable, for industrial networks this kind of delay is unacceptable. For most industries, the cost-per-minute of downtime may be thousands of pounds, and downtime avoidance is a major factor in the design of manufacturing systems, with single points of failure seen as something to be avoided at all costs.
Star topologies that by their very nature introduce a single point of failure into a networking system are still being used in industrial networks. It is now becoming standard practice, however, to deploy PLCs in such a fashion that each PLC provides localised control of processes or applications rather than having everything controlled from a central location. This also makes it easier for individual controllers to be taken off line while a section of the plant undergoes maintenance, rather having to close down the entire plant, or significantly large areas of it. Furthermore, the failure of a controller in one section will only affect that particular section.
Most modern industrial networks are designed around the concept of distributed control. A backbone of small Ethernet switches can be built up using optical fibre, inherently immune to electrical noise and having a high bandwidth. Comparatively short UTP connections (since UTP is susceptible to noise) are used between the switches and PLCs or other devices. Single points of failure in the fibre links can be reduced by a careful choice of topology. It is fairly common practice to have several cable trays running around an installation factory to segregate data, low voltage power, medium voltage power and so on. Because the data tray is typically well-populated and frequently disturbed, and because fibre is not susceptible to electrical interference, it is becoming common to find fibre alongside medium voltage power, which is usually kept out of harm's way and employs the kind of large radius bends preferred for fibre.
Yes, there are still single points of failure. The risk can be minimised, however, using a variety of redundancy mechanisms. One such mechanism, designed by Hirschmann, is called HIPER ring, and has since become a de facto standard in industrial networks, endorsed by players such as Siemens, Asea Brown Boveri (ABB) and Rockwell, while many competing products have taken their inspiration from it. The basic concept of HIPER ring is to wire all of the small Ethernet switches together in a ring. While the idea of a ring topology is inherently at odds with the way Ethernet works, it can be successfully deployed provided one of the links is inactive, thereby eliminating the possibility of a broadcast storm occurring.
The de-activated link is continuously monitored, however, to ensure that it can function if required to do so. Thus, if one of the other data links in the ring fails, this redundant link can be activated to restore connectivity between all of the switches in the network. The expected time delay between active link failure and the activation of the redundant link is 200 to 300 milliseconds fast enough for most (though not all) industrial applications. Hirschmann are working on reducing the delay to 50 milliseconds. Obviously, because the failover is transparent to the users of the system, a notification of the link failure is also required to ensure that the failed link receives attention immediately.
The idea is not entirely new, and owes much to the Spanning Tree Algorithm (STA) used first in bridges, and later switches in local area networks. The STA was fine for LANS, but only works for a limited number of bridges or switching devices, and involves a relatively long delay (in the order of thirty seconds) in order to reconfigure the network. While the Rapid Spanning Tree (RST) has now evolved, with a response delay of less than one second, the limitation on the number of devices remains an issue, and the reconfiguration itself is not stable for several seconds, during which time loops may occur.
An alternative is simply to provide a number of redundant links. A significant amount of redundancy is often desirable, and does allow for cables linking the same two points to be routed along different paths to preclude the possibility of both links becoming unavailable due to the same physical event. Further redundancy an be designed into the system in the form of redundant network devices such as switches, and even redundant control devices such as PLCs. In the final analysis, the more redundancy you design into the system, the more reliable it will be, but the initial costs will also be higher. It is really a case of weighing the cost of potential down-time or damage against the cost of implementing an appropriate level of redundancy to prevent such events from occurring.
This article was first published on the TechnologyUK.net website in January 2009.
ControlNet is a real-time, open communications protocol used in industrial automation applications, and like DeviceNet is an implementation of CIP. The ControlNet specification was maintained and managed by ControlNet International, an association of vendors, distributors and users of ControlNet technology, until 2008. This role has now been transferred to ODVA. ControlNet uses Concurrent Time Domain Media Access (CTDMA) in its data link layer for bus access. The diagram below shows the relationship between CIP, ControlNet and the OSI reference model.
The ControlNet physical layer is implemented using RG-6 coaxial cable (up to 1000 metres maximum segment length) and BNC connections, with support for redundant cabling. Fibre-optic cabling may also be used to extend the maximum segment length (up to 30 kilometres, depending on the type of fibre used). The signalling scheme used is Manchester encoding, and the data rate is 5 Mbps. The chosen method of medium access (CTDMA) means that all data traffic on a ControlNet network is strictly scheduled and highly deterministic
ControlNet supports various topologies, including trunk-line/drop-line, tree, and ring. In its simplest form, ControlNet employs a trunk-line, to which nodes are connected via a one-metre drop-line and a tap. Repeaters are used to connect a number of network segments together. Some of the commonly-used network topologies are illustrated below.
Time on the ControlNet network is allocated in fixed time intervals. Each time interval, or Network Update Time (NUT), is sub-divided into a scheduled service time, an unscheduled service time, and a network maintenance service time.
The diagram below illustrates the function of the scheduled service. Every node from the lowest up to the highest scheduled network address (SMAX) participating in the scheduled service has an opportunity to send a message within the scheduled service interval. If a node has no data, it will still transmit a short frame to indicate that it is still alive. If any node fails to send a frame, the node with the next highest node number may transmit after a short fixed waiting time, ensuring the failure of one node does not interrupt the NUT cycle.
The diagram below illustrates the function of the unscheduled service. This service is used for low-priority messages, so only one node is actually guaranteed to get access to the bus during the unscheduled service time. If there is any time left, nodes with higher node numbers will also get an opportunity to transmit. As for the scheduled service time, if any node fails to send a frame, the node with the next highest node number may transmit after a fixed waiting time. In each successive NUT, the number of the node that is allowed to transmit first within the unscheduled service time is incremented by one, guaranteeing network access to all nodes.
The two services between them engender deterministic network access, while at the same time providing the flexibility to accommodate the transmission of unscheduled messages (to upload configuration data to a node, for example). Frames (called M-packets) transmitted by a particular node may contain a number of messages (called L-packets). This allows small amounts of data to be sent to different groups of consumers without too much protocol overhead. Because ControlNet is both much faster and capable of delivering a larger maximum data frame size than DeviceNet, it requires more powerful processors than DeviceNet. Since such processors are typically capable of accessing a larger address space, many of the limitations inherent in DeviceNet networks do not apply to ControlNet networks. As a consequence, ControlNet can support four different classes of device:
ControlNet is effectively a complete implementation of the Common Industrial Protocol (CIP) and provides more efficient transfer of data between devices than other networks running at higher data rates. In addition to the standard objects defined for CIP, three additional objects are required for ControlNet:
The network update time is configured by the user, but cannot be less than two milliseconds. High-priority data is sent during the scheduled part of the network interval, while non-critical data (such as configuration data) is sent during the unscheduled part of the network interval. The delivery of time-critical control data is thus highly deterministic. A non-critical data item is guaranteed to be delivered at some point, although the latency it experiences will be entirely dependent on the overall volume of non-critical data waiting to be transmitted, and its position in the queue. Devices may be connected to or disconnected from a ControlNet network without disrupting network operation. ControlNet is often used as a backbone, to interconnect multiple distributed DeviceNet networks, and is suited to applications requiring high speed digital I/O or remote analogue I/O such as vehicle assembly lines, food processing and baggage handling.
This article was first published on the TechnologyUK.net website in January 2009.
DeviceNet is an open communications protocol used in industrial automation to interconnect I/O and control devices. DeviceNet was originally developed by Allen Bradley (now owned by Rockwell Automation), and was the first public implementation of CIP. The DeviceNet specification is now maintained and managed by the Open DeviceNet Vendors Association (ODVA), which oversees technical developments and provides conformance testing for vendors of DeviceNet equipment. DeviceNet uses CAN in its data link layer. The diagram below shows the relationship between CIP, DeviceNet and the OSI reference model.
DeviceNet uses only a subset of the CAN protocol (it uses only the standard 11-bit Message ID, and does not implement data request frames). The physical layer is an extension of the physical layer definition described in the ISO 11898 CAN specification. The extension specifies support for up to 64 nodes per network, and the provision of overvoltage and miswiring protection. Data rates for DeviceNet networks are defined as 125, 250, and 500 kbps, for maximum network lengths of 500, 250 and 100 metres respectively. In order to utilise the CAN protocols, message data length is generally restricted to eight bytes (if required, longer messages may be sent as a series of message fragments), and the introduction of a master/slave communication profile to improve scalability. These features allow the use of small, inexpensive microcontrollers, which is important for small applications such as photo-detectors and proximity sensors, where costs must be kept low. These specialisations allow DeviceNet to reside in small microchips with limited memory.
The devices on the network are linked together using a 4-wire DeviceNet cable, which allows separate connections for data (CAN-high and CAN-low) and power (Vcc and Ground). Network nodes with limited power requirements may thus be powered directly from the network (the trunk-line current rating is 8 amps). Shielding is provided to give a degree of noise immunity. The topology employed in DeviceNet networks is essentially a bus topology referred to in the specification as a trunk-line/drop-line topology that provides separate twisted-pair buses for signal and power distribution. The illustration below shows how a DeviceNet network topology might be configured.
A DeviceNet network requires a 0.25W 120Ω terminating resistor at each end of the trunk-line, between the CAN-H and CAN-L signals. DeviceNet devices attached to the network that have their own power supply should be electrically isolated. A DeviceNet network may have up to 64 nodes, with MAC IDs ranging from 0-63. The type of cable used for trunk-lines or drop-lines will determine the maximum total network length and data rates that can be achieved. The table below shows the permutations possible for cable types, cable lengths, and data rates.
| Data rates | |||
|---|---|---|---|
| Cable Types | 125 kbps | 250 kbps | 500 kbps |
| Round thick trunk cable | 500m | 250m | 100m |
| Round thin trunk cable | 100m | 100m | 100m |
| Flat trunk cable | 380m | 200m | 75m |
| Maximum drop length | 6m | 6m | 6m |
| Maximum cumulative drop length | 156m | 78m | 39m |
When the network is powered on, each device on the network sends out a Duplicate MacID Request Message. The message includes the DeviceNet Vendor ID (assigned by the ODVA) and the device serial number. The combination of Vendor ID and serial number is guaranteed to be unique for every DeviceNet device. If two or more devices attempt to access the network at the same instant, the device with the lowest Vendor ID/serial number combination will be given priority. The procedure involves the transmission of two consecutive Duplicate MacID Request Messages, with a delay of one second between them. During this delay, any online device with the same MAC ID as the device requesting access to the network must issue a Duplicate MacID Response Message. If the device requesting access to the network receives such a response, it transitions to the offline state. If not, the device will transition to the online state. If a device wishes to leave the network, it can broadcast a Device Shutdown Message, which signals to the other devices on the network that it is transitioning to the offline state.
Explicit messages are routed via the explicit message router inside each DeviceNet device. If the explicit message contains an invalid class, the router will reject the message and return an error code to the requester, otherwise it will pass the message to the target object for processing. The response from the target object is returned to the requester, again via the router.
The 11-bit CAN identifier is used to define the Connection ID. DeviceNet divides the CAN identifier into four groups. The first three groups each contain two fields. Each group has a 6-bit MAC ID field, group 1 has a 4-bit Message ID field, while groups 2 and 3 both have a 3-bit Message ID field. The combination of MAC ID and Message ID forms the Connection ID. Nodes in a DeviceNet system are responsible for managing their own identifiers. The diagram below shows the DeviceNet allocations within the 11-bit CAN Identifier. Note that the start bits for each group are such that a group 1 message will always have a higher priority than a group 2 message, while a group 2 message will always have a higher priority than a group 3 message, and so on. Group 4 messages are reserved for offline communications.
The devices (or nodes) on a DeviceNet network are configured either as master devices, slave devices, or peer devices (in some cases, a device may engender all three modes of operation simultaneously). Master devices (sometimes referred to as scanners or client devices) are usually either programmable logic controllers (PLCs) or personal computers (PCs). Master devices "own" any number of slave devices, but a slave device can only be "owned" by one master at any one time. A master device receives input information from slave devices and sends output information to slave devices. In order to establish ownership of a slave device, a master device must undertake an allocation process involving a set of handshaking messages. These messages are collectively referred to as the Predefined Master Slave Connection Set, and allow the master device to request control of the slave device and configure it to transmit a particular set of data at a data rate specified by the master device.
A slave may deny an allocation request from a master if it is already allocated to another master, or if the master requests an unsupported connection type. If the allocation request is accepted, the master will configure the I/O connection. The most important attributes of the I/O connection are the Expected Packet Rate and the Produced and Consumed connection paths. The Expected Packet Rate specifies the rate at which the master intends to scan the slave device (if the master subsequently fails to maintain this scan rate, the slave enters a timed-out state, and must be explicitly re-activated by the master). The Produced and Consumed connection paths are the paths to the application objects where data is generated or stored, respectively (usually one of the assemblies supported by the slave device). Scanning can start once the slave device has been configured. During scanning, the master device produces data for the slave?s output assembly (identified by the Consumed Connection path) and consumes data generated from the slave?s input assembly (identified by the Produced Connection path). The triggers for slave device output include network polling, change-of-state events, and timer events.
Slave devices, sometimes called adaptors or servers, receive and transmit application specific data to and from a master device. Slave devices by definition implement the Predefined Master Slave Connection Set, and must support at least one or more of the following I/O Message transport types:
Slave devices that support change-of-state operation use the device heartbeat message to let the master device know they are still operational. If no change-of-state message containing new data is produced within a specified interval (the heartbeat interval), the slave will send a device heartbeat message.
A master device (typically a PLC) implicitly informs a slave device of its current operating mode with each I/O scan. If the scan message includes at least one byte of I/O data, the slave device can assume that the master device is in run mode. If the Master device is in idle mode, it sends an I/O message with zero bytes of data (known as an idle mode message). In response, the slave device implements whatever functionality is required of it when its master device is not in run mode. The DeviceNet specification does not define any specific behaviour for a slave device in such a situation.
DeviceNet devices may be configured in hardware (e.g. using DIP switches) or using software configuration tools that access the internal configuration of the device over the DeviceNet network, or via a separate communication port. A software configuration tool acting as a master device will seek to allocate a target device as a slave in order to configure the device. It will request an explicit message connection in order to send configuration data to the device, after which it will release the connection. If the device is currently allocated by another master device, that device can effectively act as a proxy for the slave by relaying messages from the configuration tool to the slave, and responses from the slave to the configuration tool.
DeviceNet devices can assume any of the following states:
Input data is transmitted (or produced) by a slave device and received (or consumed) by a master device. Output data is transmitted by a master device and received by a slave device. I/O data in a device is held in one or more assemblies, and all I/O messages carry an I/O assembly between a master and a slave device. The input assembly object identifies the data produced by the device, while the output assembly object identifies the data consumed by the device. A device can have multiple input and output assemblies.
This article was first published on the TechnologyUK.net website in January 2009.
In the past, automation fieldbus protocols have tended to be application-specific, making them very efficient at what they do but limiting the roles for which they can be used, and making interoperability between the protocols used in different application areas difficult to achieve. The Common Industrial Protocol (CIP) forms the basis for a family of related technologies, and has numerous benefits for both device manufacturers and the users of industrial automation systems. The first of the CIP-based technologies, DeviceNet emerged in 1994, and is an implementation of CIP over CAN, which provides the data link layer for DeviceNet. The next major implementation was ControlNet, introduced in 1997, which runs over a high-speed coax or fibre physical layer, and uses Concurrent Time Domain Multiple Access (CTDMA) as its medium access layer, making it highly deterministic while extending the range of the bus (up to several kilometres, with repeaters) for more demanding applications. The most recent edition to the CIP family of technologies is EtherNet/IP (Ethernet/Industrial Protocol). The CIP protocol is also used in Rockwell Automation's ControlLogix product range. The diagram below shows the relationship between the layers of the various CIP family protocol stacks and the OSI reference model.
CIP was designed to suit the requirements of the automation industry. The specification (which is maintained by the Open Devicenet Vendors Association - ODVA) describes the following features:
CIP uses an object-oriented approach to modelling the nodes and communication services on a CIP network. Each node is modelled as a collection of objects. An object represents a particular element or component within a node. Each object belongs to a class of objects that share the same set of attributes, and implement the same behaviours. An object is an instance of that class, with its own unique set of attribute values. A node may contain more than one object of the same class. Nodes and the objects from which they are made up employ a standard addressing scheme comprising the following elements:
A CIP connection provides a path between multiple applications. When a connection is established, it is assigned a Connection ID. If the connection involves a bi-directional exchange of data, two Connection IDs are assigned. The relationship between Application Objects, Connection Objects and Connection IDs is illustrated below.
The format of the connection ID is network dependent. In DeviceNet networks, for example, it is based on the CAN Message ID. Most messaging on a CIP network relies on connections, and a process has been defined to establish connections between devices that do not have an established connection. The Unconnected Message Manager (UCMM) is responsible for connection establishment. Connections in a CIP network are either I/O connections or explicit messaging connections. I/O connections provide dedicated paths for application-specific I/O data between a producer application and one or more consumer applications. Explicit messaging connections provide generic communication paths between two devices for request-response oriented communication, and are often referred to simply as messaging connections.
CIP communication objects are used for the exchange of messages. Every communication object has a link producer part or a link consumer part or both. I/O connections may be producing only, consuming only or both. Explicit messaging connections are always producing and consuming.
The attribute values of a connection object describe the parameters of the connection. They specify its type, i.e. whether it is an I/O connection or an explicit messaging connection, the maximum size of message that can be exchanged across the connection, and the source and destination for the message. There will also be attributes that define the current state of the connection, the type of event that may trigger a message being sent (e.g. a change in the state of a device, or the elapse of a predetermined time interval), and any time-out value that applies to the connection.
The CIP family of protocols contains a large collection of commonly defined objects, which can be subdivided into the following three types:
General use objects:
Application Specific Objects:
Network Specific Objects:
A typical device will only implement a subset of the available objects, but will always have at least one Connection Object, an Identity Object, one or more network link related objects (depending on the type of network), and a Message Router Object. The other objects present in the model will depend on the functionality of the device being represented. Developers typically uses publicly defined objects (see table above), although there is scope for the creation of vendor-specific objects if necessary. The table below lists the attributes associated with the Identity Object. Typical devices do not change their identity, so all attributes (except the Heartbeat Interval attribute) are read-only.
| Mandatory | Optional |
|---|---|
| Vendor ID | State |
| Device Type | Configuration Consistency Value |
| Product Code | Heartbeat Interval |
| Revision | Languages Supported |
| Status | |
| Serial Number | |
| Product Name |
Similar products could have quite different internal structures and exhibit different behaviours. To make the application of CIP devices easier, devices with similar functionality are grouped into device types, each with an associated device profile. The profile contains a full description of the object?s structure and behaviour. The following device types and their associated profiles have been defined:
CIP Device Types:
Every profile consists of a set of objects (some mandatory, some optional), and a behaviour that is associated with the particular type of device. Most profiles also define one or more I/O data formats.
CIP allows a number of methods to be used for device configuration:
Service codes define the action to be taken when an object or parts of an object receive a message. Apart from basic read and write functions, a set of CIP Common Services has been defined that are supported by most objects. There are also a number of object-specific service codes that may have different meanings for different objects. It is also possible for vendors to define their own vendor-specific service codes, although such codes may not be universally understood.
The CIP Specification describes addressing models for CIP entities, and the data structures of the entities themselves. Addresses are referred to as segments and fall into two categories - logical segments and data types. The first byte of a CIP segment determines whether it is a logical segment (0x20-0x3F) or a data type (0xA0-0xDF). Logical segments are addressing segments that can be used to address objects and their attributes within a device, and are typically structured as shown below.
[Class ID] [Instance ID] [Attribute ID (if required)]
Each element of the structure may take up one, two or four bytes. This type of addressing is commonly used to point to assemblies, parameters, and other addressable attributes within a device. It is used extensively in electronic data sheets, and for unconnected messages. Data types can be either structured or elementary. Structured data types may be arrays of elementary data types, or any assembly of arrays or elementary data types. Elementary data types are used within electronic data sheets to specify the data types of parameters and other entities.
CIP provides a common object-oriented language for describing the nodes and services on a CIP network, whether the network is implemented using DeviceNet, ControlNet, EtherNet/IP, or any other compatible technology. This makes existing knowledge and expertise transferable, facilitating the replacement or upgrading of existing systems, and reducing the cost of training development and support personnel. It also means that firmware or software written in a high-level language can be re-used with little or no re-coding necessary. The interconnection of systems that employ diverse CIP-based technologies is relatively easy to implement, since these systems already speak the same language and device profiles are identical from one system to another. CIP is highly scaleable, and the producer-consumer mechanisms and open object architecture used in the CIP family of protocols make efficient use of the bandwidth available on the underlying network.
This article was first published on the TechnologyUK.net website in January 2009.
Controller Area Network (CAN) started life in 1983 at Robert Bosch GmbH as a serial data bus standard for the interconnection of microcontrollers in vehicles. Although originally designed specifically for automotive applications, it is now also used in other applications. The protocol was officially released in 1986, and the first CAN controller chips, produced by Intel and Phillips, were available commercially in 1987. The CAN 2.0 specification was published by Bosch in 1991. The data link and physical layers of CAN for data rates of up to 125 kbps (described as "low-speed serial data communication" were defined in part two of the original ISO standard published in 1994 (ISO 11519). Part 1 of a later ISO standard published in 2003 (ISO 11898) covers the data link and physical layers of CAN, but for data rates of up to 1 Mbps. There are also a number of other related standards. The higher layer protocols used with CAN depend on the application. A number of microcontrollers (for example, Microchip Technology's PIC Microcontrollers) now have CAN support built-in.
A modern car will typically have in the order of fifty (and sometimes a lot more) electronic control units (ECUs) controlling various automotive sub-systems. The largest microprocessor unit in a car is usually the engine control unit (also, confusingly, commonly abbreviated to ECU). Other microprocessors control elements ranging from the transmission system and braking system, right down to cosmetic elements such in-car audio systems, and driving mirror adjustment. Some of these subsystems operate independently, but others need to communicate with each other and process and respond to data received from sensors. The CAN bus in a vehicle control system will typically connect the engine control unit with the transmission control system, for example. It is also highly suited to use as a fieldbus in general automation environments, and has become widely used for such applications, in part because of the low cost, small size and availability of many CAN controllers and processors. In automotive systems, they are an ideal alternative to expensive, cumbersome and unreliable wiring looms and connectors.
A CAN network interconnects control devices, sensors and actuators (collectively referred to here as nodes). Every node attached to a CAN bus can send and receive data, but not at the same time. A message consists primarily of an identifier that identifies the type and sender of the message, and up to eight bytes of actual data. The physical medium in a CAN network is a differential two-wire bus (usually either unshielded or shielded twisted pair), and the signaling scheme used is Non-Return to Zero (NRZ) with bit stuffing. Because CAN is essentially a broadcast network, messages will be received by all nodes. The messages do not reach the devices directly, but via each node?s host-processor and CAN Controller. These elements sit between the node itself and the data bus. Any node may transmit a message providing the bus is free. If two or more nodes transmit at the same time, the system of arbitration is simply to give priority based on message ID number. The message with the higher priority ID will overwrite all other messages, and any nodes responsible for the lower priority messages will back off and wait before retransmitting.
Each node will have a host-processor that interprets incoming messages and determines when it needs to send outgoing messages, sensors, actuators and control devices, which can be connected to the host-processor as required, and a CAN Controller which is implemented in hardware and has a synchronous clock. The CAN controller buffers incoming messages until they can be retrieved by the host-processor, generating an interrupt to let the host processor know that a message is waiting. The CAN Controller is also the buffer for outgoing messages, which it receives from the host-processor and then transmits via the bus. A transceiver handles message processing, and is usually integrated into the CAN Controller. The data rates possible are dependent on the length of the bus. Data rates of up to 1 Mbps are possible at network lengths below 40 metres. Decreasing the data rate to 125 kbps would allow a network length of up to 500 metres.
Transmission of messages in a CAN is based on the producer-consumer (broadcast) principle. A message transmitted by one node (the producer) is received by all other nodes (the consumers). Messages do not have a destination address, but a Message ID. Messages in the standard format have an 11-bit Message ID, enabling 2,048 different messages to be defined for any one system - more than sufficient for most applications. For applications that require a larger number of messages, an extended message format with a 29-bit Message ID may be used, allowing over five hundred million different messages to be defined. Only certain messages will apply to each node on the network, so a node receiving a message must apply acceptance filtering (usually implemented in hardware, and based on the Message ID). If the message received by a node is relevant to it, it will be processed, otherwise it will be ignored. CAN networks may be expanded without modification to existing hardware or software if the devices to be added are purely receivers, and if they only require messages that are already generated by the network.
The standard form of arbitration in a CAN network is Carrier Sense Multiple Access/Bitwise Arbitration (CSMA/BA). If two or more nodes start transmitting at the same time, arbitration is based on the priority level of the message ID, and allows the message whose ID has the highest priority to be delivered immediately, without delay. This makes CAN ideal for real-time, priority-based systems. Each node, when it starts to transmit its Message ID, will monitor the bus state and compare each bit received from the bus with the bit transmitted. If a dominant bit (0) is received when a recessive bit (1) has been transmitted, the node stops transmitting because another node has established priority. The concept is illustrated by the diagram below
Arbitration is performed as the identifier field is transmitted, and is non-destructive. Each node transmits its 11-bit Message ID, starting with the highest-order bit (bit 10). Binary zero (0) is a dominant bit, and binary one (1) is a recessive bit. Because a dominant bit will overwrite a recessive bit on the bus, the state of the bus will always reflect the state of the message ID with the highest priority (i.e. the lowest number). As soon as a node sees a bit comparison that is unfavourable to itself, it will cease to participate in the arbitration process and wait until the bus is free again before attempting to retransmit its message. The message with the highest priority will thus continue to be transmitted without delay, and unimpeded. In the above illustration, Node 2 transmits bit 5 as a recessive bit (1), while the bus level read is dominant (0), so Node 2 will back off. Similarly, Node 1 will back off after transmitting bit 2 as a recessive bit, whereas the bus level remains dominant. Node 3 is then free to complete transmission of its message.
The Message ID for each system element is assigned by the system designer, and the arbitration method used ensures that the highest-priority messages will always be transmitted ahead of another message, should simultaneous transmissions occur. The bus is thus allocated on the basis of need. The only limiting factor is therefore the capacity of the bus itself. Outstanding transmission requests are dealt with in their order of priority, with minimum delay and maximum utilisation of the available bus capacity. In any system, some parameters will change more rapidly than others. In a motor vehicle, for example, the rpm of the engine will change far more rapidly than the temperature of the engine coolant. The more rapidly changing parameters are probably going to need more frequent monitoring, and for this reason will probably be given a higher priority.
The general format of a CAN message frame is shown below.
Data is transmitted using Message Frames. The standard CAN protocol (version 2.0A), also known as Base Frame Format, uses an 11-bit Message ID. The extended CAN protocol (version 2.0B), also now known as Extended Frame Format, supports both 11-bit and 29-bit Message IDs. Most version 2.0A controllers are tolerant of extended format messages, but essentially ignore them. Version 2.0B controllers can send and receive messages in both formats.
The start of a message frame is signaled by a dominant start-of-frame bit, followed by the 11-bit Message ID and the Remote Transmission Request (RTR) bit, which is only set if the message is a data request frame (as opposed to a data frame). It should probably be noted here that, although nodes on a CAN network generally send data without being polled, a node may request the transmission of a specific message by another node in the system. The first two bits (r0 and r1) of the 6-bit control field specify the transmission format (i.e. standard or extended), while the last four bits form the Data Length Code (DLC), which indicates the number of bytes of data transmitted. The data field can contain from zero to eight bytes of data, and is followed by the 16-bit CRC field, containing a 15-bit cyclic redundancy check code which is used by the receiving node to detect errors, and a recessive delimiter bit.
The ACKnowledge field has two bits. The first is the ACK Slot which is transmitted as a recessive bit, but will be overwritten with a dominant bit by any node that successfully receives the transmitted message. The second bit is a recessive delimiter bit. The end-of-frame field consists of seven recessive bits, and signals that error-free transmission of the message has been completed. The end-of-frame field is followed by the intermission field consisting of three recessive bits, after which the bus may be considered to be free for use. Idle time on the bus may be of any length, including zero.
At a data rate of 1 Mbps, it is possible to send in the order of ten thousand standard format messages per second over a CAN network, assuming an average data length of four bytes. The number of messages that could be sent would come down to around seven thousand if all the messages contained the full eight bytes of data allowed. One of the major benefits of CAN is that, if several controllers require the same data from the same device, only one sensor is required rather than each controller being connected to a separate sensor. As mentioned previously, the data rate that can be achieved is dependent on the length of the bus, since the bit time interval is adjusted upwards to compensate for any increase in the time required for signals to propagate along the bus, which is proportional to the length of the bus. Bus length and bit rate are thus inversely proportional.
Nodes that transmit messages on a CAN network will monitor the bus level to detect transmission errors, which will be globally effective. In addition, nodes receiving messages will monitor them to ensure that they have the correct format throughout, as well as recalculating the CRC to detect any transmission errors that have not previously been detected (i.e. locally effective errors). The CAN protocol also has a mechanism for detecting and shutting down defective network nodes, ensuring that they cannot continually disrupt message transmission.
When errors are detected, either by the transmitting node or a receiving node, the node that detects the error signals an error condition to all other nodes on the network by transmitting an error message frame containing a series of six consecutive bits of the dominant polarity. This triggers an error, because the bit-stuffing used by the signalling scheme means that messages should never have more than five consecutive bits with the same polarity (when bit-stuffing is employed, the transmitter inserts a bit of opposite polarity after five consecutive bits of the same polarity. The additional bits are subsequently removed by the receiver, a process known as de-stuffing). All network nodes will detect the error message and discard the offending message (or parts thereof, if the whole message has not yet been received). If the transmitting node generates or receives an error message, it will immediately thereafter attempt to retransmit the message.
This article was first published on the TechnologyUK.net website in January 2009.
Traditional industrial networking technologies such as Profibus and Modbus use a source-destination model of networking in which data is sent separately to each device on the network that needs it. The more devices there are on the network requiring the same data, the more times that data must be transmitted. This represents an inherently inefficient use of bandwidth, which becomes more of a problem as the demands on the network increase. Another problem arises if the data is time sensitive. The need to transmit the same data multiple times to different destination devices means that each device will receive the information at a different time, making synchronisation problematical and compromising the accuracy of the data. The network?s determinism is also degraded, since the length of time required to deliver each message will depend on the number of devices it must be sent to.
The throughput of a network is essentially measured in terms of the amount of data it can deliver in a given amount of time, and must equal or exceed the requirements of the applications supported by the network when demand is at its heaviest. The throughput achievable will depend on the available bandwidth (data rate), the efficiency of the network protocol used (i.e. the amount of protocol overhead required per unit of data), and perhaps most importantly the networking model in use. Improving the efficiency of the network protocol can achieve only marginal gains in terms of throughput. Increasing the bandwidth of the network provides a temporary solution but does not address the underlying problem, which is inefficient use of bandwidth. The approach being taken by more recently developed industrial networking technologies, including DeviceNet and ControlNet, is to abandon the source-destination model of networking in favour of a producer-consumer model.
The producer-consumer model allows all nodes on a network (the consumers) to simultaneously access data generated by a single source node (the producer), eliminating the need to transmit the same data multiple times, and allowing much more efficient use of bandwidth. Moreover, because the data is received at the same time by every node, the accuracy of time-sensitive information is far greater. Rather than identifying a destination address for the data, the data is given a unique message identifier that allows nodes on the network to either consume it or ignore it, depending on whether or not it has meaning for them. Each device on the network can be configured to listen for and consume only messages with a specific message identifier. All other messages will be ignored by the device. The determinacy of the network is greatly improved, since the length of time required to deliver a message is no longer dependent upon the number of devices that it must be sent to.
The producer-consumer model also eliminates the need for the traditional polling of devices in many cases. Polling usually involves a control device sending a message to an input device (such as a sensor) to request updated input data. The input device will respond immediately with the requested data. Polling is a two-way process involving two separate messages, and often occurs frequently to minimise latency in delivering new input data to a controller. This is very wasteful of bandwidth if the input data changes only infrequently. The producer-consumer model allows the use of more efficient I/O trigger mechanisms that eliminate the need for polling and significantly reduce the number of messages sent across the network. The first of these trigger mechanisms is referred to as change-of-state or event-triggered. Input data is generated by a device only when an input value (or the status of the device itself) changes. To allow for situations where new input data is generated only infrequently, a short heartbeat message is transmitted periodically to let a controller know that the device is still functioning. The second trigger mechanism is cyclic or time-based, and requires input data to be generated at a pre-set time interval, the length of which is determined when the device is configured.
The increased efficiency engendered by the producer-consumer model means that the same network can be used for both explicit messaging and I/O messaging. Explicit messaging is typically used to upload configuration data to a device, and tends to involve the transmission of larger amounts of data and involve more protocol overhead. I/O messaging is typically cyclic or event-triggered, involves relatively small amounts of data, and has negligible protocol overhead. Because I/O messages invariably carry real-time application data, they must be given a higher-priority than explicit messages. Prioritisation is achieved by using different identifiers for explicit messages and I/O messages. Explicit messages are given a lower priority, and are restricted to using the network only when there are no high-priority I/O messages on the network.
This article was first published on the TechnologyUK.net website in January 2009.
MODBUS is an open, de-facto application layer communications protocol used for the supervision and control of automation equipment. MODBUS was originally developed in the late 1970s by Modicon for use with its Programmable Logic Controllers (PLCs). Today, standards are maintained by MODBUS-IDA, a group of independent users and suppliers of automation equipment. The core element of a MODBUS system is an application-layer messaging protocol that provides client-server communication between devices via serial links, over an Ethernet network, or over other networks that support TCP/IP. MODBUS is typically used to connect a supervisory computer with a remote terminal unit (RTU) in a SCADA system.
Most MODBUS devices communicate over a serial link physical layer, initially RS-232 but more commonly RS-485. Two variations of the standard could be used with serial links. MODBUS RTU represents the data in a compact binary format and employs a cyclic redundancy check (CRC) for error detection purposes, while MODBUS ASCII represents the data in human-readable format and uses a longitudinal redundancy check (LRC). The data itself consist of a series of hexadecimal digits (only the characters 0...9 and A...F are used). The ASCII representation encodes each hexadecimal digit using eight bits (one byte), enabling the data to be read as plain text. The binary representation encodes each hexadecimal digit using only four bits, so a byte actually contains two hexadecimal digits. Communication between a node configured for the RTU variant and one configured for the ASCII variant is not possible. For communication over a network that supports TCP/IP (usually Ethernet), the more recent MODBUS/TCP variant can be used. The data model and the function calls used are identical across all three variants. An extended proprietary version (MODBUS Plus) also exists, but is not discussed here.
A MODBUS system typically consists of a number of slave devices controlled by a much smaller number of master devices (often only one). Communication between devices involves the exchange of messages, the format of which is independent of the MODBUS variant used. The exchange is always initiated by a single master device sending a query message to a slave device. The slave device then returns a response message (on TCP/IP networks, any device may initiate the process, although it is usually a single master device). Each MODBUS device has a unique address, and each message contains the address of the intended recipient in its header. While a number of nodes on a MODBUS network may receive the same message, only the node to whom the message is addressed will read the message. The structure of a MODBUS message is shown in the table below.
| Field | Description |
|---|---|
| Device address | Address of recipient device |
| Function code | A code that defines the message type |
| Data | In a query message, this field provides the slave with any additional information required for it to complete the action specified by the function code (e.g. register addresses, count values etc.). In a response message, if no error occurs, the data field of a response from a slave will return the requested data. Otherwise, it will return an exception code that the master?s application software uses to determine what action to take. |
| Error check | Error detection code (CRC or LRC) |
The maximum number of devices on a single RS-232 or RS-485 data link is restricted to two hundred and forty-seven. A device address is expressed as two hexadecimal digits, and must be within the range 0-247 (00h-F7h). The addresses 01h-F7h can be assigned to individual MODBUS devices, while the address 00h is used as a broadcast address. Messages containing the broadcast address as the device address will be read by all slave devices. The message carrying the response from a slave device will use its own address as the device address, allowing the master to identify the origin of any response it receives.
The function code is also a hexadecimal value, in the range 01h-F7h, and defines the action the slave is required to perform. As with the device address, the function code specified in the query message is used in any response generated by a slave device. If an error has occurred, however, the highest-order bit of the function code (normally zero) will be set to one to notify the master device that a problem has occurred. Some of the more frequently used function codes are described in the table below.
| Code | Description |
|---|---|
| 01 | Read coil status |
| 02 | Read input status |
| 03 | Read holding registers |
| 04 | Read input registers |
| 05 | Force single coil |
| 06 | Preset single register |
| 07 | Read exception status |
| 15 | Force multiple coils |
| 16 | Preset multiple registers |
| 17 | Report slave ID |
MODBUS function 01 (read coil status) is used to request the status of one or more coils on a single device (the term coil in this case refers to a discrete output value). This is done by specifying an output range in the data field of the message, as shown below. Note that MODBUS slave device coil (output) addresses range from 1 ? 10,000 (decimal), although the actual number of outputs available is device-dependent.
| Byte | Value | Description |
|---|---|---|
| 1 | 01h-F7h | Slave device address |
| 2 | 01h | Function code |
| 3 | 00h-FFh | Start address (high byte) |
| 4 | 00h-FFh | Start address (low byte) |
| 5 | 00h-FFh | Number of coils (high byte) |
| 6 | 00h-FFh | Number of coils (low byte) |
| 7/7 - 8 | LRC/CRC | Error detection code |
The length of the response message can vary between 0 and 255 bytes, depending on how many values have been requested (the number of bytes of data returned is specified in the first byte of the Data field). The general format of a function 01 response message is shown below.
| Byte | Value | Description |
|---|---|---|
| 1 | 01h-F7h | Slave device address |
| 2 | 01h | Function code |
| 3 | 00h-FFh | Number of bytes of data (n) |
| 4 to n+3 | 00h-FFh | Data |
| n+4/n+4 to n+5 | LRC/CRC | Error detection code |
MODBUS function 02 (read input status) messages have a very similar format to the function 01 messages. The main difference is that the second byte of the query message and response message (the function code) will have a value of 02h. MODBUS slave device input addresses range from 10,001 ? 20,000 (decimal), although that the actual number of inputs available is device-dependent. The starting address specified in a function 02 message is an offset from the base address (0000h = 10,001 decimal). The format of a function 02 request message is shown below.
| Byte | Value | Description |
|---|---|---|
| 1 | 01h-F7h | Slave device address |
| 2 | 02h | Function code |
| 3 | 00h-FFh | Start address (high byte) |
| 4 | 00h-FFh | Start address (low byte) |
| 5 | 00h-FFh | Number of inputs (high byte) |
| 6 | 00h-FFh | Number of inputs (low byte) |
| 7/7 - 8 | LRC/CRC | Error detection code |
Once again, the length of the response message can vary between 0 and 255 bytes, depending on how many values have been requested (the number of bytes of data returned is specified in the first byte of the Data field). The general format of a function 02 response message is shown below.
| Byte | Value | Description |
|---|---|---|
| 1 | 01h-F7h | Slave device address |
| 2 | 02h | Function code |
| 3 | 00h-FFh | Number of bytes of data (n*) |
| 4 to n+3 | 00h-FFh | Data |
| n+4/n+4 to n+5 | LRC/CRC | Error detection code |
*n = number of inputs requested
MODBUS function 03 (read holding registers) requests the return of one or more internal values stored in the 16-bit holding registers of the slave device. These general-purpose registers hold data such as configuration parameters, or measured values (e.g. temperature readings). MODBUS slave device holding register addresses range from 40,001 ? 50,000 (decimal), and the starting address specified in a function 03 message is an offset from the base address (0000h = 40,001 decimal). The format of a function 03 request message is shown below.
| Byte | Value | Description |
|---|---|---|
| 1 | 01h-F7h | Slave device address |
| 2 | 03h | Function code |
| 3 | 00h-FFh | Start address (high byte) |
| 4 | 00h-FFh | Start address (low byte) |
| 5 | 00h-FFh | Number of registers (high byte) |
| 6 | 00h-FFh | Number of registers (low byte) |
| 7/7 to 8 | LRC/CRC | Error detection code |
The length of the response message depends on the number of registers requested. Due to the size of the registers (16 bits), each register value must be encoded as two bytes (the high byte, followed by the low byte). The general format of a function 03 response message is shown below.
| Byte | Value | Description |
|---|---|---|
| 1 | 01h-F7h | Slave device address |
| 2 | 03h | Function code |
| 3 | 00h-FEh | Number of bytes of data (nx2)* |
| 4 to 2n+3 | 00h-FFh | Data |
| 2n+4/2n+4 to 2n+5 | LRC/CRC | Error detection code |
*n = number of registers requested
MODBUS messages on serial connections are framed to enable message recipients to detect the beginning and end of each frame. The start of a MODBUS ASCII frame is signalled by a colon (:), and the end of the frame is signalled using the carriage-return/linefeed combination (CR/LF). Intervals between transmitted bytes of up to one second are allowed. A MODBUS ASCII message frame is illustrated below.
For MODBUS RTU, each frame must be preceded by an interval with a minimum duration equivalent to the time required to transmit 3.5 characters, during which time the connection must be quiet. A second quiet interval of at least the same length signals the end of a frame. For MODBUS RTU, the message must be transmitted as a continuous stream. If a quiet interval greater in duration than the time required to transmit 1.5 characters occurs before the frame is complete, the receiving device flushes the incomplete message from its receive buffer and awaits the start of a new frame. If a new message begins before the minimum time interval (3.5 character times) following a previously received message, the receiving device assumes it to be a continuation of the previous message. This will generate an error condition, because the value in the final CRC field will not be valid for the combined messages. A MODBUS RTU message frame is illustrated below.
This article was first published on the TechnologyUK.net website in January 2009.
SCADA generally refers to an industrial control system - a computer system monitoring and controlling a process. The processes can be industrial (e.g. manufacturing or power generation), infrastructure (e.g. water and sewage treatment, or electrical power transmission and distribution), or facility (e.g. environmental control in a building or on a ship). A SCADA system usually includes the following sub-systems:
The term SCADA is usually used to describe systems in which the monitoring and control of a large industrial campus is centralised. Most control functions are performed automatically by RTUs or PLCs, with central control functions being restricted to supervisory level intervention. A PLC may control the flow of coolant for an industrial process, for example, but an operator may be able to override flow controls or initiate emergency action.
Data acquisition starts with the RTU or PLC, and includes sensor readings and equipment status data that are transmitted to the SCADA supervisory system. The data thus acquired is put into human-readable format so that an operator can use it to make a decision whether or not to intervene or adjust control parameters. In the longer term, historical data can be collected and used for auditing and process performance analysis.
SCADA systems typically implement a distributed database that stores the input and output data recorded by the system (or calculated values derived indirectly from them). Each value is recorded in the database together with a time-stamp indicating precisely when the data was recorded (or derived), and the ID of the device or controller from which it was received. The system's HMI is usually linked to the database via diagnostic software that provides the operator with both real-time and historical graphical information about a process, as well as management information that can include device and system schematics, maintenance schedules, and troubleshooting guides. The system will also be able to trigger an alarm when normal operational parameters have been exceeded to allow an operator to take appropriate action.
SCADA was developed before computer networks as such existed, and the first generation of SCADA systems were never interconnected with other systems. Communication protocols were proprietary, and designed to be compact. In most cases an RTU only sent information when polled by the master station. Typical legacy protocols, which are all vendor-specific but widely-used, include Modbus RTU and Profibus. Standard protocols recognised by all major SCADA vendors include IEC 60870-5-101 or 104, IEC 61850 and DNP3. Many of these protocols now contain extensions to allow them to operate over TCP/IP. With the advent of the local area network, processing could be distributed across multiple stations, which shared information in real time, although the networking protocols used were still mostly proprietary. The current generation of SCADA systems use open protocols and standards, allowing functionality to be distributed across a WAN using Internet protocols, and facilitating interoperability with peripheral devices such as printers. The ability to interconnect SCADA systems with other networks via the Internet has, inevitably, raised concerns about security.
SCADA systems are now based on standard network technologies. Ethernet and TCP/IP based communications protocols are replacing the older proprietary ones. Next-generation SCADA protocols look set to adopt web technologies, allowing them to be accessed via a wide range of end-user devices, including mobile and hand held devices. Some vendors have even begun to offer application-specific SCADA services hosted on Internet servers, eliminating the need to install systems at the end-user’s premises, although there are again some concerns about security, latency, and the reliability of Internet connections. The security of SCADA systems connected to public networks, or to other systems via public networks, is an important issue, since any breach of security could have serious consequences. Vulnerabilities in a power distribution system, for example, could result in widespread power failures that could involve businesses in financial losses or have serious consequences for safety. Vendors of SCADA systems have now begun to address these risks for TCP/IP-based SCADA networks.
This article was first published on the TechnologyUK.net website in January 2009.
Industrial control system (ICS) is a general term for several types of control system, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCSs) and other, less sophisticated system configurations such as skid-mounted Programmable Logic Controllers (PLCs). Such systems are typically used to control the distribution of utilities such as power, gas and water, with control devices (often referred to as field devices) being widely distributed in various remote stations. These field devices control local operations such as the opening and closing of valves and circuit breakers, and collect data from sensors and monitoring systems.
A distributed control system (DCS) is typically used to control processes such as the generation of electrical power, oil and gas refining, water and sewage treatment, and the production of chemicals, food, and motor vehicles. They provide an integrated control architecture that facilitates a supervisory level of control for multiple control sub-systems, each of which is responsible for providing localised process control. Key data about the process is fed back to the controller from sensors, and appropriate control data is fed forward from the controller to the process equipment to ensure that the process continues within set parameters. A DCS fulfills the need for large scale data acquisition and control on a large industrial campus in real time, using high bandwidth and low latency network connections.
Programmable Logic Controllers provide the necessary control logic, timing, and in some instances continuous control within known tolerances to control industrial equipment and processes. They are the control system components used by SCADA and DCS systems, and may be the primary components in smaller systems that control discrete processes such as vehicle assembly lines. PLCs are used extensively in virtually all industrial processes. The PLC evolved because of the perceived need to replace racks of ladder relays, which were time-consuming and difficult to rewire, and not particularly reliable or easy to diagnose when faults occurred.
Supervisory control and data acquisition (SCADA) systems are associated with distribution applications, such as power, gas, and water pipelines, and grew from out of a need to gather remote data through potentially unreliable, low bandwidth and high latency channels. Sites tend to be geographically widely separated, relying on remote telemetry units (RTUs) to send data back to a control center. Some of these remote units had a limited capacity for localised control functions in cases where communication with a control centre was lost. Most modern RTUs have far more autonomy in terms of handling control functions locally.
The differences between these system definitions are blurring as time passes and various technical constraints are overcome. Modern PLC systems can in some cases replace a DCS, while an improved telecommunications infrastructure has enabled SCADA systems to manage closed loop control over long distances. Improvements in processor technology have allowed many DCS products to incorporate subsystems that incorporate the functionality of a PLC. The convergence of the three concepts has led to a new concept – the Process Automation Controller (PAC). Market forces, and time, will determine what impact this has on bringing about a more standardised approach to industrial control.
This article was first published on the TechnologyUK.net website in January 2009.