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.

______________________

Comments

Comment viewing options

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

SCTP,

Anonymous's picture

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

-http://people.cs.uchicago.edu/~piggy/sctp_refcode/

-http://www.sctp.de

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix