Avoiding Negative ROI for IIoT Deployments in Manufacturing

Avoiding Vendor Lock In, Minimizing NRE and SI Billable Hours, Keeping an eye on Cycle Time and Output.

I’ve always enjoyed learning about technology and take a great amount of pride of not being just a “sales guy” pushing product. I’ve learned a few tricks over the years from engineers far smarter than myself and hope they can help you out as you scope your next project.

I’ve been fortunate enough to have a mixed bag of experience as a technical sales engineer of High Precision Measurement Process Sensors, Machine Vision Systems, Barcode Readers, Private Wireless Sensor Networks, even Full Production Systems! This is the lens i’m viewing this through as i’ve seen a few customers get burned by not thinking long term.

Below are some quick tips I would make sure to double check as you plan for long term scaling on your IIoT deployments.

Avoiding Vendor Lock-In & Minimizing NRE with SI Billable Hours

Whether it is a PLC, Robot, or even wireless sensor networks for temperature/vibration make sure your solution is able to scale and scale easily in the long term. Have your vendor of choice show you how they setup communication and if it is repeatable across all brands you will see in your manufacturing plants globally. Think to yourself, if we roll this out globally (since you are planning for success here) can you do this connection process 100’s or potentially 1000’s of times? How many hours will you pay an SI to just map your data to your smart solution? Will they need to change PLC settings or modify the PLC program? Is that feasible and do you have the required expertise in remote facilities to do this? Do they offer on premise solutions or do they force you to push it only to their proprietary cloud?

Always think a few steps ahead “if this is successful, what are we adding next?” Can your AI/ML edge solution you piloted on your Rockwell Automation PLC’s in the USA be redeployed easily with your Siemens PLC’s in Europe? What about your Mitsubishi ones over in Japan? How much NRE will you spend money on?

Does your sensor supplier offer only temperature/vibration solutions? What if you wanted to add other common process data like flow monitoring or current monitoring? Can you easily mix and match them without having to use their proprietary software suite and custom map their modbus devices? Is it worth managing multiple vendors and their proprietary gateway and their data formatting? Sometimes, yes. Most often, No.

You might want to see if there are alternative vendors that offers more sensor types or go with some IO-Blocks with an open sensor standard like IO-Link and leverage IODD files. I have never seen a manufacturer, even ones with the strictest approved components/specifications list, be able to stick to one brand as that would provide too much leverage for pricing and with the current supply chain strain you are going to want some alternatives either way.

Cycle Time & Output

Unsolicited vs Polling data is key here. Here is a way better explanation from Telit than I would be able to do and a direct quote explaining the benefits between polling & unsolicited messaging.

“The use of unsolicited messages is an excellent strategy to reduce the processing load on both the node and the PLC. Rather than constantly polling a PLC and reading a data point to determine if a condition has been met to execute a trigger, the PLC can indicate when the condition has been met and send the unsolicited message. The network traffic will be dramatically reduced. The PLC no longer has to constantly field read requests from the node, more often than not on data values that are not changing. This allows the PLC to focus on performing the functions defined in the ladder, rather than fielding data read requests. The PLC ladder logic can be modified to initiate the execution of a trigger based on criteria defined in the ladder, by sending the unsolicited message to the node. If the criteria needs to be modified, the changes are isolated to the PLC and the trigger logic is not impacted.”

Sometimes using a common standard like OPC-UA or Modbus and polling the devices, you can add significant amount of cycle time to your process. This is especially true if it is a single threaded hardware device. When I was providing sensor/hardware solution cycle time was always a concern as it adds up to be an extremely large number if you factor in annual production volumes. Keep an eye on performance of your IoT solutions and your actual output. If it takes 3 seconds to scan thousands of registers by polling your PLC each cycle, it may actually cause negative ROI.

What are your thoughts? Please feel free to comment and share any tips or tricks you have learned or feedback!