PLCs are at the first level of the automation pyramid. This means that using them to get data means working very close to the hardware, with a low level of abstraction. This brings the following problems:

• The PLCs, and the PLCs that act as data concentrators, manage, either directly or indirectly, several thousand input and output signals plus their internal data, calculations, and statuses generated by their control logic. In the context of the I-IoT, all of these are tags, some of which come from physical instruments and others from internal calculation and intermediate logic steps. These often appear unstructured, or structured in a very basic way. They are rarely linked to a comprehensive data model, even though this should be one of the outcomes of a well-integrated I-IoT platform. In any case, selecting the PLC as a data source means we have to deal with this complexity due to the low level of abstraction.
• Naming conventions are another obstacle to overcome, since the name of tags might be different in different areas of the same plant. This might depend on the PLC vendor or the integrator that develops the control logic running on the PLC. Often, the naming conventions also reflect the naming of the physical instruments that are provided by the manufacturer of a specific plant area.
• We cannot simply connect a PLC to a device, such as the edge, that is exposed to the internet. This is not recommended by the Integrated Control System (ICS) security standards and, in any case, is not something that the field engineer would allow. We will be exploring how we can get around these security constraints further in Chapter 5, Applying Cybersecurity, but it is not always possible to do this for the following reasons:
  • The PLCs may be old and would therefore not be resilient to storm attacks on their Ethernet port.
  • There may be other old devices on the same local network that are potentially at risk.
  • There may be customer security policies to keep the control network as isolated as possible, due the variety of the industrial devices that are linked to it and their vulnerability to cyberattacks.
  • The mentality of the team may also be a barrier; an automation engineer with a lot of experience in the field may be unwilling to accept the idea of connecting a PLC to the internet.

• Connecting directly to a PLC implies that we are able to talk to it according to its protocol. Although PLCs have become much more standardized due to the adoption of the fieldbus standard over the past few years, we would still need to develop, maintain, and keep updated the connectors for several protocols, including EtherNet/IP, PROFINET IO, DeviceNet, PROFIBUS DP, and MODBUS. This requires quite a lot of effort, especially if you consider that each of these protocols is liable to require enhancements and fixing, meaning you have to deal with the compatibility and the backward-compatibility of the developed connectors. Another option for using PLCs as a data source for the I-IoT data flow is to connect to them through the OPC server. OPC-UA, if available, is without a doubt the preferred choice compared to OPC Classic. OPC Classic, however, is preferred to a direct connection through the fieldbus protocol used by the PLC. If your choice is OPC Classic, try to run your OPC DA client on the same Windows box as the OPC DA server to avoid the DCOM issues discussed in the previous section.