The implementation of Industry 4.0 projects has many hurdles. However, one problem has been clearly solved: There is a possibility to establish equipment connectivity for every starting and target situation. Capturing data in an equipment or triggering it from a controller is now easily possible. Here is an orientation in a confusing field of factory automation.
A few years ago it was only possible with great effort to read out simple signals such as the units produced from an equipment. Machines were closed systems and external communication was often not provided or was so prohibitively expensive that the operator refrained from it. However, with the advent of Industry 4.0 and the realization that the concept is intensely data-centric, the situation has fundamentally changed.
There are now hardware and software solutions for old and new equipment that cover the entire range of use cases. The solution landscape remains confusing, however, since it is unfortunately impossible to sort the connectivity concepts without overlapping. Hence the attempt is a simplified description of archetypes, knowing that the actual variety of solutions is greater – and that a precise consideration of the initial situation and the desired target state is required in order to design a long-term, suitable solution.
Four archetypes of equipment connectivity
The following table shows four archetypes of connectivity, which will be examined in detail in the following:
| Archetyp | Description | Equipment age and requirements | Possible Use Case Complexity |
|---|---|---|---|
| Plug-& -Play Retrofit | Supplement of e.g. quantity or vibration sensors | No requirements | Low to medium |
| Integrated Retrofit | Supplement to an industrial PC or a “connector box” | PLC must be available | Medium to high |
| Software layer | Use of a “data layer” via Industrial Service Bus | PLC must be available | Medium to very high |
| Control native | Availability of a new generation of controls with OPC UA or REST API | Only new equipment | Low to very high |
Plug-&-Play Retrofit – the quick solution
We call the lightest form of connectivity “Plug-&-Play Retrofit”. Additional sensors are introduced into the equipment, which act autonomously without further equipment integration. For example, quantities can be counted directly or derived from vibrations – the vibration itself can also be a relevant signal. These sensors are available with or without a wired power supply and usually send their data – directly or via a mesh architecture, for example – for further processing in the cloud. Use cases with low to medium complexity can thus be implemented. An example of a simple case is the identification of whether an equipment is being operated or not. This can be achieved with a networked vibration sensor.
However, this form of connectivity is not suitable for all types of equipment. While vibrations can be easily counted with clear quantities, this technology reaches its limits in the production of meters, for example, or continuous equipment operation. On the side of the advantages, however, this form of integration has its simplicity in that it eliminates the need to intervene in the equipment control and sometimes even waives a power supply of the sensor.
Integrated Retrofit – the flexible solution
The next archetype is described as “Integrated Retrofit”. Windows or Linux computer hardware is connected to the equipment’s PLC via software connectors. The connector maps the data from the PLC to the software running on the computer, from where the connectivity is established, e.g. to the cloud. The communication standard depends on the app used. MQTT, for example, is common here. Since there is a direct connection with the equipment control, a large number of signals can be read out.
Software layer – the ambitious solution
A further variant of the equipment connectivity is a software data layer above the controls, which, depending on the provider, is e.g. referred to as an industrial or manufacturing service bus. This is a further development of what was previously referred to as “middleware”. In this variant, the equipment’s PLCs are connected to the data layer and deliver their information there. Use cases can now be mapped directly on this level – e.g. real-time connectivity between different equipment – or it can be used as a jump-off point to cloud services. With this infrastructure, demanding and complex use cases can be mapped.
Control native – for new equipment
The last variant of connectivity is again hardware-bound and is referred to as “control native”. These are new generations of controls that have built-in connectivity directly, as native. Examples of this are the OPC UA or REST API technology that are implemented in the equipment.
Hybrids blur the order
What makes understanding equipment connectivity difficult is that the above archetypes are not always found in their pure form, but that there are many hybrids. For example, an OPC UA controller can be connected to any industrial service bus, or there is a variant where a controller from a specific manufacturer is available with its own data layer.
And with Retrofits, too, it is important to have the application in mind: Vibrations are not sufficient information for all applications, while not every product can be discreetly counted.
Summary
What can be said in summary: The possibilities of reading data – even in real time – from equipment are diverse. The prices are not prohibitively high, but surprisingly low. As an equipment operator you usually have heterogeneous equipment in terms of manufacturer, technology and age, you should have the target use cases in mind before deciding on one of the technologies. After all, it is an infrastructure decision that you don’t want to reverse anytime soon.
Connectivity to oee.ai
oee.ai must be supplied with equipment data as a manufacturing intelligence platform. The incoming information is usually an MQTT message or a REST API call, depending on the data. And these messages or calls can be easily generated using all four connectivity variants. This means that oee.ai is connectivity-agnostic. For the discrete, quantity-related, use case, oee.ai even provides the hardware as a package for a proof-of-value to test the functionalities. We have experience with all connectivity variants. Do not hesitate to contact us.