Equipment Connectivity is Solved

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:

ArchetypDescriptionEquipment age and requirementsPossible Use Case Complexity
Plug-& -Play RetrofitSupplement of e.g. quantity or vibration sensorsNo requirementsLow to medium
Integrated RetrofitSupplement to an industrial PC or a “connector box”PLC must be availableMedium to high
Software layerUse of a “data layer” via Industrial Service BusPLC must be availableMedium to very high
Control nativeAvailability of a new generation of controls with OPC UA or REST APIOnly new equipmentLow to very high
Table: Four Archetype of Equipment Connectivity

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.


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 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 is connectivity-agnostic. For the discrete, quantity-related, use case, 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.