CloudRail - Knowledge is power for industrial retrofitting

Whether you call it Industry 4.0, IIoT or Smart Manufacturing, the objective behind these trendy buzzwords is the same - to “connect all the things”. Whether you're responsible for a segment of critical national infrastructure, production lines in a thingamabob factory or a small family run farm; instrumenting and collecting data from your production environment can transform your business in terms of efficiency, cost savings and profitability. As Sir Francis Bacon (among others) observed “scientia potential est” or “knowledge is power”.

The data collected from properly instrumented machinery can be analysed to reveal hidden information, patterns, and trends, allowing operators to optimise the running of their environments, reducing costs and minimising downtime.

If you’re fortunate enough to be working in a modern facility, built within the last few years, there’s a good chance your production equipment already has telemetry collection and monitoring built in. Whether it’s a complex, country spanning SCADA system featuring multiple layers of RTUs, PLCs and HMIs, or a simple, network-connected, temperature sensor or a loadcell in a weighbridge, the data generated by these connected devices can provide invaluable insights into the health and performance of the equipment they monitor.

But what about older sites – of which there are literally millions – still running equipment that is many years or even decades old? How do these so called “brownfield” facilities tap into the wealth of data hidden inside their plant and machinery?

The answer is “industrial retrofitting” or “secondary sensing” as its sometimes called. This is the practice of equipping legacy equipment with additional sensors to gather data for IIoT applications like condition monitoring or predictive maintenance. Such sensors are exclusively used for the IIoT use case and as such, are completely separated from the actual production environment. This means they are unable to interfere with machines or PLCs being monitored and therefore pose less of a security risk than natively-integrated telemetry systems.

In addition to the reduced security risk, retrofitting brings other advantages:

• Faster realization – No fundamental changes needed to the production environment as no PLC programming is required.
• Reduced costs – Little to no machinery downtime, and reduced workload for automation engineers.
• Richer data quality – Generic sensors can be custom-configured, unlike pre-programmed OEM solutions. The sensor network can easily scale with the IIoT use-case.

The Outlook Is Cloudy

Adding sensors to machines is only part of the story. You also need to be able to analyze the data they collect and transform it into actionable information. This, of course, needs the right software solution. Now you could procure or even write your own analysis and reporting system. But why “reinvent the wheel” when all of the major cloud providers (AWS, Azure, Google, SAP, IBM, etc) provide IoT platforms that are specifically designed to ingest data from connected devices and crunch that data in to useful dashboards, reports and feeds into other systems?

This is where CloudRAIL fits in. Their enterprise-grade IIoT solution connects industrial sensors from various manufacturers (Turck, IFM, Pepperl & Fuchs, SICK, Balluf) easily and securely to all the main IoT/IIoT platforms.

The technology consists of two components: the CloudRAIL.Box edge gateway and the cloud platform, CloudRAIL.DMC, that enables provisioning and management of devices.

The CloudRAIL.Box device connects to a separate IO-Module into which up to eight sensors are connected. If you need more sensors, then additional Modules can simply be daisy-chained together using standard ethernet cables.

The IO-Module provides four or eight (depending on the model) industry standard M12 IO-Link interfaces (IEC61131-9). This means that any IO-Link compatible device can be connected to the CloudRAIL.Box, and there are quite a few of them. Over 12,000 to be precise – temperature sensors, vibration sensors, RFID readers, 4-20mA adapters...the list goes on. All the major automation vendors produce IO-Link based devices, so there is almost certain to be one that meets your requirements.

Once the CloudRAIL.Box has internet access, the rest of the setup is simple:

• Connect a sensor to the CloudRAIL IO-Module.
• Plug the IO-Module into the CloudRAIL.Box.
• Login to your CloudRAIL account.
• Add the new Box by simply entering its serial number.

That’s all there is to it. No programming skills or in-depth IIoT knowledge is required for the hardware installation. The IO-Module(s) and any connected sensors are automatically detected, and data collection starts.

Next, you just need to add your new data source to your CloudRAIL Management platform. This is a cloud-based tool that provides a centralized administration point for all of your deployed devices. It allows configuration changes, firmware updates and edge functions (code running directly on the CloudRAIL.Box and comprising AWS IoT Greengrass, or Azure IoT Edge functions, or even custom written JavaScript code), to be deployed across your entire estate.

Adding a .Box is very simple. Just add the device serial number and any connected IO-Modules and associated sensors will be automatically enrolled into the management tool.

As well as receiving data from the CloudRAIL secondary sensing devices, deployed on “Brownfield” sites, the management system can also ingest and route data collected from OPC UA data sources running on “Greenfield” sites.

To register your device at its final destination and route data directly from the edge device to this service, simply click “New Connection”, select from Brownfield, or Greenfield, as appropriate, and select the source (sensor) for the data you want to forward. You can also configure if you want the data sent on an interval, or when a value change is detected.

Finally, choose a service to receive the data.

All the mainstream IoT cloud service providers are supported. There are also generic MQTT and Webhook destinations for those that want to ingest the sensor data into their own environments.

Endpoint configuration will vary by destination but is usually as simple as providing a source identifier and configuring the relevant destination instance details and credentials. The sensor’s data gets automatically normalized and is sent in a readable JSON format (e.g. temperature in °C, double type value).

The PRTG Bit

With all this talk of cloudy data processing, you’re probably wondering where PRTG fits in? There are several choices here, depending on the endpoints you’re working with. If your data is heading for one of the cloud platforms, you could use a PRTG REST Custom Sensor to retrieve raw or processed data from the relevant platform’s API. Or, if you’ve deployed your own onsite MQTT broker, PRTG’s native MQTT Subscribe Custom Sensor can retrieve data directly from the broker. Finally, the Webhook endpoint could be used to send data to your PRTG server where it will be processed using an HTTP IoT Push Data Advanced Sensor, which will parse the JSON return from the Webhook and “map” the data values to PRTG sensor channels.

Regardless of the source, once the data is in PRTG, it can have limits assigned that can be used to trigger alerts if user-defined thresholds are exceeded.

Of course, the sensors can also be added to maps (dashboards) that provide a clear graphical insight into the health and performance of the devices being monitored.

 The CloudRAIL solution provides a cost effective, flexible, and easily-implemented way to gather, process and analyze health and performance data from legacy plant and machinery. Its cloud-based backend enables it to scale as needed – from a couple of sensors in a single building, to enterprise deployments across the globe. The system’s support for Webhooks, MQTT and REST protocols enables PRTG to also receive data from the deployed IIoT sensors. As with traditional IT monitoring data, PRTG can then assign thresholds to the received values, trigger alerts when those limits are exceeded and incorporate the physical sensor data into maps that give operational teams a great insight into what’s happening in their environment.