Embedded systems in a connected world
Developing embedded systems in an Ethernet connected world adds complexity to an already complex task. We are a long way from the days when the primary problem in an embedded system was to determine which inputs forced which outputs in a ladder logic diagram, what timers were needed, and what safety interlocks were needed. Today, embedded system developers often follow software engineering principles. They are using object-based designs based on formal unified modeling language (UML) state models and sequence diagrams. Each physical device in the system is represented as a device object (a control module) with a distinct behavior, command inputs, and status or data outputs. The device objects are aggregated into larger objects (equipment modules) with their own controlling sequences, behaviors, inputs, and outputs.
Defining a network interface was often a secondary consideration when an embedded system design was focused only on inputs and outputs without a formal structure. If an interface was provided at all, it was usually a simple listing of PLC addresses that could be used to modify the behavior or provide limited visibility. Today, with end users specifying standard connections through Ethernet and TCP/IP, the old approach no longer works. End users in a connected world need interfaces in their embedded systems for data collection, configuration, maintenance troubleshooting, and coordination control with other embedded systems. End users also want standard interfaces, so that integrating embedded systems into their overall production environments are not custom projects.
Several incompatible standards exist for interfaces, including PackML that defines a set of standard tag names for machine automation and control, MTConnect that defines a standard read-only interface for machine tools and equivalent systems, OPC-UA that defines a web-based interface for industrial control, EtherNet/IP that defines tag an object network interface, and Profinet that provides Profibus-like access across Ethernet networks. The best choice today is to pick a standard that is well accepted in your industry and to not develop your own proprietary interface. All of the above standard interfaces are based on object models, and all are based on some form of Ethernet TCP/IP network because of the cost and support benefits from using commonly available networking equipment.
8 embedded requirements
No matter which standard you chose for your embedded system interfaces, consider adding the following requirements:
1) Support the Ethernet TCP/IP communication standard protocols. TCP/IP will be around for a long time and will continue to be the standard protocol for the foreseeable future. Even when the embedded system has reached its end of life, you still should be able to effectively communicate with it in the TCP/IP protocol.
2) Support the IPv6 Ethernet standard. This is the new standard for Ethernet addressing, replacing the original IPv4 standard that has run out of Ethernet addresses. Embedded systems have lifetimes of dozens of years, so supporting the IPv6 will enable your system to continue to communicate as networks grow in complexity and become more pervasive.
3) Put the embedded device behind a firewall or within its own protected network. Security will always be an issue, and it is important to protect the embedded device from directed attacks and incidental disruption due to nondirected cyber attacks.
4) Support a wireless interface with WPA or WPA2 security. Equipment is often moved around during its lifetime, and many times the cost and time of running additional network cables through a production environment is large. Providing a wireless interface simplifies production rearrangements without requiring IT to come in and run more cables. New wireless standards have sufficient throughput and redundancy for most industrial applications and should be an option for our embedded systems.
5) Ensure that all unused Ethernet ports on the embedded system are closed. This will eliminate at least one security risk. It is also important to test port access in your acceptance tests. Use a simple port scanning tool to identify which ports are open on the device, and use the results to configure firewalls and switches to block any unused but open ports.
6) Expose the top-level control objects through the interface for data collection, control, and configuration. A good design will have interface objects that should be used for normal control and data acquisition and an interface to other objects for maintenance and troubleshooting.
7) Do not allow remote configuration unless there is a physical key or switch that can be used to lock out access. Any remote access provides a route for a cyber attack. You can reduce this risk by requiring physical access to the device before it can be reconfigured.
8) Provide the device documentation through an embedded web page or PDF file. While many companies are diligent about keeping support manuals available, the documents may still be hard to find and can delay troubleshooting and repairs. Providing the support documents on-line, within the embedded system, will be an invaluable help after a vendor has made the system obsolete or is no longer in business.
In today’s world, to paraphrase John Donne’s 1624 famous prose, “no embedded system is an island entire to itself.” Embedded systems are often mechanically connected to other systems, and planning for network connectivity will allow them to also be electronically connected. It is important to ensure that your embedded systems will work with your entire production system and manufacturing IT infrastructure for as long as needed.
– Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at firstname.lastname@example.org. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, email@example.com.