Improving Network-Based Industrial Automation Data Protocols

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

Security

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.

Conclusion

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.