Improving Network-Based Industrial Automation Data Protocols

TCP/IP breaks into industrial automation, but not without some problems.

By security, I'm referring to casual validation that the data sent and received belongs to the data protocol. A header that includes a unique magic key allows a receiver to detect if the message is known. This header may also include a data length to allow TCP packet segregation and possibly even a simple checksum to validate the encapsulated data.

If there are concerns that sensitive automation data is being sniffed, a sockets encryption layer may also be provided. This will add additional overhead to the packet processing. As embedded processors become more powerful, it's likely that this will become a standard feature.

Binary Data

The rapid parsing requirement of many data protocols calls for the use of binary data. Binary data is excellent if the automation device and the host system share common data formats; namely 2s complement integers and IEEE-754 floating-point standards. There is one catch: endian or byte ordering. Bytes are ordered differently on different processor architectures. Endian is described as little or big endian. While a protocol may be created based about an endian order, it would be convenient if not advantageous to supply a method to have the endian order changed or available on another IP port. Clients may be heavily penalized attempting to reorder bytes.

Also, although rare, an architecture may not implement compatible data formats or its development language may not be tolerant or supportive of binary data streams and their conversions.


Automation protocols over IP and Ethernet are making positive headway. Their rapid evolution has created a few shortcomings and minor headaches. Existing data protocols can be improved in time, however, to overcome these issues and increase their reliability and usefulness.

Several elements, namely the Device/Service Locator, also could be implemented industry-wide. Doing so would allow customers common access to these new automation devices in a standard format.

Bryce Nakatani is an engineer at Opto 22, a manufacturer of automation components in Temecula, California. He specializes in real-time controls, software design, analog and digital design, network architecture and instrumentation.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Anonymous's picture

I must say, I cant wait for SCTP[RFC 2960] to get in the main kernel.