The short answer
You can get data from an installed sensor into IT without touching the PLC by adding an IP data path beside the control system. A Single Pair Ethernet adapter connects to a 4-20 mA, 0-10 V or digital signal and publishes the value over MQTT and REST as its own network device. If the PLC depends on the signal, an in-line loop monitor reads the loop in passing and sends a copy to IT, while the PLC keeps its measurement.
How sensor data reaches IT today
The usual architecture sends every reading through the control system first. A transmitter is wired to a PLC input, the value is mapped into the program, and a server or gateway in the cabinet makes it available to IT, typically over OPC UA.
That made sense when the control network was designed. Its job is to run the machine reliably, and it does that well. Data for the rest of the company came later, collected from wherever the PLC happened to hold it.
Many installed sensors were never wired to a PLC at all. They feed a local display or a chart recorder, and their readings never leave the machine.
Where it gets difficult
Each new data point becomes a change to the control system. Even a value the PLC will never act on needs an input, a mapping, a test and a sign-off from the people responsible for the machine.
In a plant with machines from different builders and different controllers, that work repeats on every line, often with a different integrator each time. So requests wait, and the plant keeps measuring things nobody outside the cabinet can see.
Control data and information data are different
Some values belong to the control system: anything the PLC needs to run the machine, or anything that depends on deterministic timing. Others are only needed by maintenance, energy management, quality or analytics. Control data has a control architecture. Information data does not have to inherit it.
A quick way to compare the options is to ask where the first IP address sits. Every route ends in an IP network somewhere. Where that address sits shows where protocol translation happens, how much depends on the control system, and what has to change when you add the next data point. Several routes publish over MQTT, so the protocol alone does not tell them apart. The location of the address does.
Scroll sideways for all columns.
| Route | Where the first IP address sits | What changes in the PLC | What you add | Best fit |
|---|---|---|---|---|
| Through the PLC (analogue input, OPC UA) | At the PLC | Program change and revalidation | Nothing new | Values the control program needs |
| Gateway reading the PLC or fieldbus | At the gateway in the cabinet | The value must already be in the PLC or fieldbus | A gateway | Protocol conversion for data already in the controller |
| IO-Link master (with an analogue converter for 4-20 mA) | At the master | None, if the master publishes to IT directly1 | A converter per sensor and a master | New lines with IO-Link sensors specified |
| Remote I/O station with MQTT or REST | At the I/O station | None2 | An I/O station with sensors wired to it | Many signals concentrated at one point |
| Adding a new networked sensor | In the new sensor | None | A new sensor | Values nobody measures yet, such as counts, vibration or temperature |
| Single Pair Ethernet adapter or in-line loop monitor | At the adapter or monitor beside the sensor | None | An adapter or monitor per sensor, plus a field switch or media converter | Installed sensors, mixed fleets, monitoring data |
The “Best fit” column is editorial judgement, not a sourced claim.
Sources
- IO-Link masters publishing to IT directly: ifm IO-Link master with IoT core and MQTT interface; Balluff BNI00 IO-Link masters. Analogue to IO-Link: ifm analogue-to-IO-Link converters.
- Remote I/O with MQTT and REST: Murrelektronik MVK Pro and IMPACT67 Pro.
Which route fits which sensor
- The PLC needs the value to run the machine. Keep it in the PLC. If IT needs it too, put periSNOOP in the 4-20 mA loop: the loop keeps controlling, and the value goes to IT.
- A 4-20 mA sensor used only for monitoring. Connect it to periNODE 4-20mA.
- A 0-10 V sensor used only for monitoring. Use periNODE 0-10V.
- Machine states, counts or stack lights for OEE. Use periNODE GPIO.
- Modbus RTU devices. Use periNODE Modbus.
- A new line with IO-Link sensors already specified. Use the IO-Link master.
- Long runs, process areas or hazardous areas. 100BASE-T1 covers machine and building distances, and Perinet has measured up to 180 m on installed Cat 5e cable. For kilometre runs or process plants, look at 10BASE-T1L; for hazardous areas, Ethernet-APL. Perinet devices are not ATEX-rated and are not Ethernet-APL devices.
periSNOOPThe PLC needs the 4-20 mA signal
periNODE 4-20mA4-20 mA, monitoring only
periNODE 0-10V0-10 V, monitoring only
periNODE GPIOMachine states and counts for OEE
periNODE ModbusModbus RTU devices
Not sure which route fits your machine?
Tell us which sensors you have and what the PLC depends on. An engineer will suggest the simplest route.
The last few metres
What gets installed is small. The adapter or loop monitor sits next to the sensor and connects over one hybrid Single Pair Ethernet cable (periLINE), which carries 100BASE-T1 data and 24 V DC. The cable runs to a periSWITCH field switch, or to a periSTART media converter on a standard Ethernet port.
Each device announces itself on the network under its own hostname, is configured in a browser, and publishes its values over MQTT or REST. The sensor, the PLC and its program stay as they are.
Two things to plan for. The devices use link-local IPv6 addresses, so the MQTT broker sits on the same network segment, or a periMICA edge computer on that segment forwards the data to a broker elsewhere. And the devices support mutual TLS: if you enable it, the broker needs to accept client certificates.
Where this is used
OEE monitoring on packaging linesMachine states and counts from existing lines feed live OEE data, with no change to the control system.Read the use case
Compressed-air monitoringPressure and flow from transmitters already on the line give continuous visibility of use and leakage, without manual audits.Read the use case
Where Perinet fits
Perinet makes the devices for the last route in the comparison table: periNODE adapters and the periSNOOP loop monitor, connected over periLINE to periSWITCH or periSTART. They suit installed sensors that you can't or don't want to rewire through the PLC. If the PLC needs the value, or a new line already specifies IO-Link, one of the other routes may suit you better.
Frequently asked questions
Leave the sensor as it is and add a device that reads its signal and publishes it on the network. A Single Pair Ethernet adapter such as periNODE 4-20mA powers and reads the transmitter and sends the value over MQTT or REST. If the PLC also uses the signal, an in-line monitor such as periSNOOP reads the loop in passing and sends a copy, while the PLC keeps its measurement.
Read the signals OEE needs, such as running, stopped, fault and part counts, at the machine and send them to the OEE software over a separate data path. A digital adapter such as periNODE GPIO picks up these states from existing signals and publishes them over MQTT, so the PLC program and the control network stay as they are.
IO-Link masters and remote I/O stations publish to IT from a central point that the sensors are wired to. The alternative is to put the network interface beside each sensor. A Single Pair Ethernet adapter or loop monitor provides the IP address and publishes over MQTT and REST itself, with no master or I/O station in between. Which fits depends on whether the sensors are new or installed, and how spread out they are.
For machines and buildings, 100BASE-T1 is usually enough. Perinet has measured up to 180 m on installed Cat 5e cable, and most sensors sit within tens of metres of a cabinet. 10BASE-T1L is designed for runs of up to about a kilometre in process plants, at 10 Mbit/s, and Ethernet-APL builds on it for hazardous areas.
No. The approach is built on published standards: IEEE 802.3bw for the link, IEC 63171-6 for the connector, IPv6 and TLS for transport, and MQTT and REST for data. Any broker, historian or cloud platform that speaks MQTT or REST can receive the values, with no proprietary driver or middleware on the IT side.
Perinet products are available worldwide through DigiKey and in Europe through Farnell. ZentinelMDS is Perinet's integration and sales partner for Spain, Portugal and Latin America. For project quantities and engineering support, contact Perinet in Berlin directly. The partner page lists all current distribution and integration partners.