Accessing PLC Data with Industrial Real-Time Linux Servers over EtherNet/IP

Accessing Industrial Data

Industrial data and control frameworks need to be able to utilize data from both servers and peripheral equipment, such as Programmable Logic Controllers (PLCs). To do so requires communication between devices, commonly done by communication standards such as, but not limited to, EtherNet/IP, CANopen, and Modbus.

The ADEPT Framework encapsulates common industrial communication standards into logical devices, which hide protocol complexity and provide a consistent interface for data to be shared across the framework. This data-centric architecture also allows control logic and models to be implemented and tested independent of the communication standard.

What is EtherNet/IP?

While there are many industrial communication standards, EtherNet/IP is one of the more common and was designed to use over Standard Ethernet. EtherNet/IP is based on the Common Industrial Protocol (CIP) and can support many network topologies, including the standard Ethernet star and device level rings. EtherNet/IP follows the OSI 7-layer model as an Application layer protocol and can therefore leverage equipment and networks that support enterprise IT and Internet communications. The EtherNet/IP standard is maintained by the ODVA association. See their Ethernet/IP documentation for more details.

Configuring EtherNet/IP Communication

Using EtherNet/IP in the ADEPT Framework requires the creation of pre-defined messages to be sent to and received from targeted devices (commonly PLCs). These messages are generally created and defined in ADEPT-DB and they are comprised of Ethernet/IP Logical Devices, Targets, Tags and Signals.

  • Ethernet/IP Logical Device – is the device that is setup as an Ethernet/IP interface
  • Target – is the device (often a PLC) that the message is communicated with
  • Tag – is a message that contains data (Signals) of only one type (int, float, etc.)
  • Signal – is a piece of data of a specific type that is contained in a message (Tag)

For example, to setup simple EtherNet/IP communications with a PLC that has analog to digital converters (ADC) and relays, one EtherNet/IP Logical Device and one Target need to be created, as well as separate Tags and Signals for ADC and relay values. See Figure 1 for how this is represented in ADEPT-DB.

Once the EtherNet/IP communications have been defined in ADEPT-DB, it can then generate communication message files that can be included directly in an ADEPT-DE Framework. Generated messages are associated with a logical device in ADEPT-DE as a .csv file (see Figure 2) and attached to a model as an external data dictionary. When setup like this, EtherNet/IP messages become part of the standard ADEPT models I/O and will be handled automatically by the ADEPT framework during runtime.

In the ADEPT framework I/O are connected to Model Ports. Model Ports are model variables that are global to the model and defined in the model’s data dictionary with an assigned I/O direction. Model Ports are generic and can be connected to any device or other model. ADEPT-DB allows for Model Assemblies to connect Model Ports to a Signal from a Tag. Additionally, when ADEPT-DB generates files, it will create a pair of external dictionaries, one for receiving Tags and the other for transmitting Tags. These external dictionaries are then added to the framework and provide access to the communicated data. See Figure 3 for an example.


Once the communicated data are added to the framework, they can be used for real-time schedules and triggers or manipulated through Python script. Schedules and triggers are processed in real-time, which allows highly time-deterministic interactions to be added or modified on-the-fly without the need to recompile the framework. If real-time performance is not required, then Python scripting offers a highly flexible way of interacting with the communicated data.

Real-Time Considerations

The ADEPT runtime software runs model assemblies in real-time. Due to the nature of EtherNet/IP, communication may not come at expected intervals. To handle this discrepancy, EtherNet/IP communication is run as a separate thread from the model assembly. This architecture prevents asynchronous communication behavior from interfering with the real-time performance of the assembly. The EtherNet/IP thread interacts with the assembly thread through highly efficient data dictionary shared memory values to ensure that both the communication thread and the model assembly thread always have access to the most current send and receive values.

Conclusion

The abstraction afforded by the logical device architecture allows a user model assembly to avoid the complexity of implementing communication protocol like EtherNet/IP. The message definition and organization ability of ADEPT-DB allows complex messages to be defined in a simple hierarchy that can be converted into setup files and signals used directly by the ADEPT framework. These powerful capabilities allow for the easy implementation of a model assembly that communicates with one or more Ethernet/IP Target devices.

Furthermore, once EtherNet/IP data are added to an ADEPT framework, they can be easily connected to models that perform any number of tasks, from real-time data acquisition to supervisory control to sophisticated digital twin anomaly detection utilizing the latest machine learning tools. What real-time data opportunities will you unlock when EtherNet/IP is added to your data and control framework toolbox?