The TCP/IP protocol stack has been adopted for general use in automation systems and is playing an increasingly important role in all realms of industrial control. This section will explore the impact of the IT network stack on traditional industrial control protocols.
Modbus/TCP is very similar to Modbus RTU, but transmits the protocol packets within TCP/IP data packets.
The MODBUS protocol defines a simple Protocol Data Unit (PDU) independent of the underlying communication layers. The mapping of MODBUS protocol on specific buses or networks can introduce some additional fields on the Application Data Unit (ADU).
A dedicated header is used on TCP/IP to identify the MODBUS Application Data Unit. It is called the MBAP header (MODBUS Application Protocol header).This header provides some differences compared to the MODBUS RTU application data unit used on serial line:
The MODBUS ‘slave address’ field usually used on MODBUS Serial Line is replaced by a single byte ‘Unit Identifier’ within the MBAP Header. The‘Unit Identifier’ is used to communicate via devices such as bridges, routers and gateways that use a single IP address to support multiple independent MODBUS end units.
All MODBUS requests and responses are designed in such a way that the recipient can verify that a message is finished. For function codes where the MODBUS PDU has a fixed length, the function code alone is sufficient. For function codes carrying a variable amount of data in the request or response, the data field includes a byte count.
When MODBUS is carried over TCP, additional length information is carried in the MBAP header to allow the recipient to recognize message boundaries even if the message has been split into multiple packets for transmission. The existence of explicit and implicit length rules, and use of a CRC-32 error check code (on Ethernet) results in an infinitesimal chance of undetected corruption to a request or response message.
The MODBUS MBAP header is seven bytes long and consists of the following fields:
Transaction Identifier
It is used for transaction pairing, the MODBUS server copies in the response the transaction identifier of the request.
Protocol Identifier
It is used for intra-system multiplexing. The MODBUS protocol is identified by the value 0.
Length
The length field is a byte count of the following fields, including the Unit Identifier and data fields.
Unit Identifier
This field is used for intra-system routing purpose. It is typically used to communicate to a MODBUS+ or a MODBUS serial line slave through a gateway between an Ethernet TCP-IP network and a MODBUS serial line. This field is set by the MODBUS Client in the request and must be returned with the same value in the response by the server.
All MODBUS/TCP ADU are sent via TCP to registered port 502.
A MODBUS device may provide a client and/or a server MODBUS interface. A MODBUS backend interface can be provided allowing indirectly the access to user application objects.
Four areas can compose this interface: input discrete, output discrete (coils), input registers and output registers. A pre-mapping between this interface and the user application data has to be done.
In 2000, the DNP Technical Committee defined a specification for carrying DNP3 over TCP/IP and UDP/IP. Because the WAN/LAN version is essentially the serial DNP3 encapsulated, this makes it possible to connect serial DNP3 devices to WAN/LAN DNP3 devices using terminal servers, IP packet radios, CDPD modems, and other networking technologies without requiring the access devices to have knowledge of DNP3. DNP3 is often referred to as a SCADA protocol, but was intended for use in all areas of utility communications.
Many vendors offer products that operate using TCP/IP to transport DNP3 messages. Link layer frames are embedded into TCP/IP packets. This approach has enabled DNP3 to take advantage of Internet technology and permitted economical data collection and control between widely separated devices.
OLE for Process Control (OPC), is the original name for an open standards specification developed in 1996 by an industrial automation industry task force. The OPC Foundation is an industry consortium that creates and maintains standards for open connectivity of industrial automation devices and systems. The OPC standards specify the communication of industrial process data, alarms and events, historical data and batch process data between sensors, instruments, controllers, software systems and notification devices.
The OPC Foundation started in 1994 as a task force comprised of five industrial automation vendors, with the purpose of creating a basic OLE for Process Control specification. OLE, COM, and DCOM are a technologies developed by Microsoft Corporation for the MS Windows operating system. The task force released the OPC standard in August 1996. The OPC Foundation was chartered to continue development of interoperability specifications and includes manufacturers and users of devices, instruments, controllers, software and enterprise systems. The standard specifies the communication of real-time plant data between control devices from different manufacturers. The specification defines a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability.
OPC was designed to bridge Windows based applications and process control hardware and software applications. It is an open standard that permits a consistent method of accessing field data from plant floor devices. This method remains the same regardless of the type and source of data. OPC servers provide a method for many different software packages to access data from a process control device, such as a PLC or DCS. Traditionally, any time a package needed access to data from a device, a custom interface, or driver, had to be written. The purpose of OPC is to define a common interface that is written once and then reused by any business, SCADA, HMI, or custom software packages.
Once an OPC server is written for a particular device, it can be reused by any application that is able to act as an OPC client. OPC servers use Microsoft’s OLE technology (also known as the Component Object Model, or COM) to communicate with clients. COM technology permits a standard for real-time information exchange between software applications and process hardware to be defined.
OPC Standards and Specification Groups are listed here:
OPC Data Access
This group of standards provides specifications for communicating real-time data from data acquisition devices such as PLC's to display and interface devices like Human-Machine Interfaces (HMI). The specifications focus on the continuous communication of data.
OPC Alarm and Events
Standards for communicating alarm and event data on demand, as opposed to the continuous communications in the OPC Data Access group.
OPC Batch
Standards to address the needs of batch processes.
OPC Data eXchange
This group of standards addresses server to server communications across industrial networks. The standards also address remote configuration, diagnostics, monitoring and management communications.
OPC Historical Data Access
Standards for communicating stored data.
OPC Security
Standards for controlling client access to OPC compliant devices and systems.
OPC XML-DA
Builds on the OPC Data Access specifications to communicate data in XML. Incorporates SOAP and Web services.
OPC Complex Data
Standards for specifying the communication of complex data types such as binary data and XML documents.
OPC Commands
Standards for communicating control commands to devices and systems.
OPC Unified Architecture
An entirely new set of standards that incorporates all of the functionality of the above standards (and more), but does so using cross platform web services and other modern technology. OPC Unified Architecture.
OPC Unified Architecture is the most recent OPC specification from the OPC Foundation and differs significantly from its predecessors. After 3 years of specification work and another year of prototyping the first version of Unified Architecture is now being released.
Although the original binding to COM/DCOM helped OPC to distribute well but nevertheless had several drawbacks.
frequent configuration issues with DCOM
no configurable timeouts
only available for the Windows Operating System
security not really applicable
no control over DCOM (COM/DCOM is kind of a blackbox, developers have no access to sources and therefore have to live with bugs or insufficient implementations)
A decision has been made to develop a new and independent communication stack for OPC UA which replaces COM/DCOM. The characteristics of this communication stack are:
portable ANSI C implementation.
scalability from embedded controllers up to mainframes.
the stack can be compiled for multi-threaded as well as single-threaded/single-task operation, which is necessary for porting the stack onto embedded devices.
a native security implementation, based on new standards.
configurable timeouts for each service.
chunking of big data packets.
a Service Orientated Architecture (SOA)
All of the Base Services defined by OPC are abstract method decriptions which are protocol independent and found the basis for the whole OPC UA functionality. The transport layer maps these methods into a protocol, which means it serializes/de-serializes the data and transmits it over the network. Currently there are two protocols specified for this purpose. One is a binary, towards high performance optimized TCP protocol and the second is a web service based protocol. The OPC information model isn't just a hierarchy based on folders, items and properties anymore, but a so-called Full Mesh Network based on nodes instead. These nodes can additionally transmit all varieties of meta information. The easiest comparison of a node would be an object, known thru object orientated programming (OOP). It can own attributes for read access (DA, HAD), methods which can be called (commands) and triggered events which can be transmitted (AE, DA DataChange). The nodes get used for process data as well all other types of meta data. The OPC namespace also contains the type of model used for description of all possible data types. Based on the above, other organizations are specifying their own information sources. Client software has the ability to verify which of the namespace profiles a server supports. New and important features of OPC UA are:
Redundancy support
Heartbeat for connections in both directions. That means the server as well as the client recognizes interrupts or events.
Buffering of data and acknowlegements of transmitted data. Lost connections don't lead to lost data anymore. Lost datagrams can get fetched repeatedly.
From the application programmer's point of view different URLs are passed to the base layers for binary protocol opc.tcp://servername and http://servername for web service. Otherwise OPC UA is completely transparent in the implementation of the two protocols.
OPC UA binary protocol:
Best performance with the least protocol overhead.
Takes minimum resources. No XML Parser, SOAP and HTTP required which is important for embedded devices.
Best possible interoperability. The binary protocol is explicitly specified and allows less degrees of freedom during implementation as XML does.
Only one single TCP port (4840) gets used for communication and can get tunneled or enabled through a firewall easily
OPC UA SOAP protocol:
Best supported from available tools. It can be easily used i.e. from JAVA or .Net environments.
Firewall-friendly. Port 80 (http) and 443 (https) will usually work without additional configuration.
The OPC UA specification is a multi-part specification and consisting of the following parts:
1. Concepts
2. Security Model
3. Address Space Model
4. Services
5. Information Model
6. Service Mappings
7. Profiles
8. Data Access
9. Alarms and Conditions
10. Programs
11. Historical Access
The architecture of an UA application, independent whether it is a server or client application, is structured in layers. The former COM Proxy/Stubs is provided by the OPC Foundation. A new portability layer has been introduced for porting to other target platform.
OPC UA Security consists of authentication and authorization, encryption and data integrity via signatures. For that, the OPC Foundation hasn't reinvented the wheel but adopted the web service security specifications. For web services the WS-SecureConversation is used and is therefore also compatible with .Net and other SOAP implementations. For the binary variant, the algorithms of WS-SecureConversation have been followed and also converted to a binary equivalent, renamed as UA SecureConversation.
The OPC Unified Architecture (UA) has been specified and is being tested and implemented through the OPC Foundation's early adopters program. It can be implemented with Java, Microsoft .NET, or C++, eliminating the need to use a Microsoft Windows based platform of earlier OPC versions. UA combines the functionality of the existing OPC interfaces with new technologies such as XML and Web Services to deliver higher level MES and ERP support. It looks to become the new standard for exchanging industrial data, replacing FactoryTalk, Archestra, some Modbus applications and OPC-DA.
Industrial Ethernet is the name given to the use of the Ethernet protocol in an industrial environment, for automation and control systems. Traditionally a PLC would communicate with a slave machine using one of several possible open or proprietary protocols, such as Modbus, Sinec H1, Profibus, CANopen, DeviceNet or FOUNDATION Fieldbus. However, there is now increasing interest in the use of Ethernet as the link-layer protocol, with one of the above protocols as the application-layer. It is also common to find the TCP/IP layers, or adaptations of TCP/IP included in an Industrial Ethernet protocol stack.
The main advantages are:
Increased speed, up from 9.6 kbit/s with RS232 to 1 Gbit/s with IEEE 802 over Cat5e/Cat6 cables or optical fiber
Increased overall performance
Increased distance
Ability to use standard access points, routers, switches, hubs, cables and optical fiber, which are cheaper than the equivalent serial-port devices
Ability to have more than two nodes on link, which was possible with RS485 but not with RS232
Peer-to-peer architectures may replace master-slave ones
Better interoperability
The difficulties of using industrial Ethernet are:
Migrating existing systems to a new protocol
Real-time uses may suffer for protocols using TCP (some use UDP and layer 2 protocols for this reason)
Managing a whole TCP/IP stack is more complex than just receiving serial data
Security and reliability concerns experienced in IT networks become a problem in automation networks
