Why is the connection piece so hard?
Increased usage of digital technologies by the manufacturing industry is inevitable but, while the shift is gradual, the pressure to go faster is great
When Hewlett-Packard Enterprise (HPE) and the Industry of Things World Conference conducted a survey to find out how successful industrial IoT (IIoT) projects have been in the last 12 months, the responses uncovered that only 53% of respondents thought their IIoT projects had met or exceeded goals. The remaining 47% said their goals had not been reached.
IIoT isn’t about companies buying a technology and suddenly they’re digital. It’s an entire architecture which encompasses an ecosystem with careful communication across various touchpoints within an organisation, all of which requires common standards as well as new technology architectures to create convergence of information technology (IT) and operational technology (OT).
One critical and common chokepoint is a lack of understanding about device connection. Even if devices are connected, there are often no simple tools to manage the devices in order to extract and transmit the data out of one language into another; for example the transmission and translation of programmable logic controller (PLC) data into enterprise resource planning (ERP) systems.
Let’s look at the top five things to consider about the connection puzzle and how to weave them into your overall plan.
1. Getting things connected is easier said than done
During the discovery phase, many IIoT vendors gloss over this. Once manufacturers decide to take the plunge, they suddenly realise that connecting to all these different devices – legacy and modern, proprietary and open source – is really difficult, and results in significant delays which blow up the original projected timeframe.
If you’ve ever engineered systems on the plant floor, you know there are those things down on the plant floor that are a nightmare to connect to and integrate with a variety of other applications. A simple data collection task can end up taking weeks of custom coding.
2. Embrace complexity
There is no single standard way of connecting everything together. Over time, the industrial plant floor has evolved as technology has changed. For better or for worse, this advancement also means more complexity and it is not going away; in fact, it will increase.
As a result, plant floors have a mixture of device brands, different protocols, and different proprietary data sets. Embracing complexity means we accept there are a lot of moving parts in IIoT solutions that we need to link together for success and that requires a level of expertise which is better addressed as a holistic solution versus a complicated system of patch work.
3. Prepare for latency
One piece that addresses complexity is open platform communications (OPC). OPC was designed to provide industrial automation with a standard networking protocol that requires polling to receive data from devices. Polling is where the system must ask the device for data at a preset rate, such as once every second or once every half hour.
OPC requires multiple steps to send data; it is not point A to point B. A typical path looks like this: PLC to OPC server to OPC client. Then, the OPC client sends it to the on-premise server or cloud network to be utilised and processed.
To further add to the multi-level process, PLCs must have separate connections to every other thing or software application. Connections must be written from PLC 1 to thing 1, PLC 1 to thing 2 and do on, repeated for PLC 2 and its connection to each thing.
Then add the transmission of the PLC data into ERP software: code is needed for the connection from PLC 1 to ERP software 1, ERP software 2, and so on. Add polling to all those layers, and it’s a recipe for tremendous latency.
4. Data isn’t always accurate
OPC offers no feature to guarantee data accuracy. One company with a pharmaceutical plant in Florida, was up against this challenge. OPC was used to poll devices, which often received 3,000 data packets for each production run. It had no way to verify which packet was the correct match to the finished product lot. To answer this, the company’s engineering team wrote a lot of complex, custom code to run double-checks on the data sources and the receiving ends to ensure the data matched. That’s a lot of work to create and maintain for engineers who should be focused on the conversion of chemical and biological materials into valuable pharmaceuticals and pharmaceutical therapies.
5. Legacy devices can talk with modern equipment
Message queue telemetry transport (MQTT) is quickly becoming one of the top protocols for IIoT, and modern devices are coming built with MQTT. However, the only way to take advantage of MQTT is to buy MQTT-enabled devices. No one wants to rip and replace legacy devices they’ve already amortised for 20 or 30 years just to get all new MQTT devices.
When you want to add new equipment at some point, such as the latest sensor that’s the hottest item on the market, it will most likely be designed with MQTT in mind. The downside is that you’re going to have to do extra work to make MQTT devices work with your legacy devices. To the thousands of devices you might have in a plant, you may have ten devices equipped with MQTT. Migration of all devices to MQTT will be slow and doesn’t solve today’s problem of connecting legacy and modern devices, it just means more custom coding.
Solution: Avoid custom code Use a data-centric IIoT software to map devices directly to applications (or other devices)
This seems pretty straightforward, but as you’ve probably realised things just don’t plug-and-play like you’d expect.
Many IIoT platforms focus on analytics, but they are data-poor due to their inability to quickly onboard devices. You might call these analyticsfocused IIoT platforms. So, with inaccurate data, the analytics delivered by the platform is virtually useless.
To solve this, you need to map devices, like PLCs, directly to applications. A data-centric IIoT software platform is designed to do just that. It merges legacy and modern devices regardless of communication protocol, and provides a central data pipeline to all devices and applications on the network, giving you complete control over how, when, and where your data is used.
Native drivers – Go beyond APIs, OPC and MQTT
Don’t be lured into the idea that application programme interfaces (APIs) and standard protocols will give you flexibility. APIs, OPC and MQTT are just an advertisement that you’ll need to do custom programming.
Every IIoT platform has standard tools for APIs, OPC and MQTT, but they often don’t have many native drivers. A data-centric platform will have a broad array of native drivers which avoids signing on your engineers to write custom code. This makes all the difference in getting your devices on-boarded in days, instead of months.
>>VISIT : info.telit.com