One of the biggest benefits of creating a connected factory floor or building is that you remove silos of information. This is one of the headline benefits of the IOT or IIOT movements. Get the information from all the different business and automation systems into a central system and let the power of the data work for you. There are no more humans reporting the data through manual entry or emailing of spreadsheets, the “things” (a whole internet of them) can talk for themselves. That is a legitimate value proposition for a pile of businesses.
All the pieces needed to unify the data in your business are now available; it’s really just a matter of increased adoption as to when it becomes the norm. Yet as data moves from these silos like tributaries to a single IT river, controls are diverging and creating deltas.
From Central Control to the Device Level
Adding control to any product is relatively easy now. The standardization of IEC 61131-3 created a simplified universal standard for PLC control. At the same time the horsepower of processors exponentially increased as the price exponentially decreased. Adding control to nearly any embedded product can now be done for very little cost, and the features and function device level controls can add to a product is pretty sexy. It’s no longer a question of could you add control to your device, but should you.
Having an open control environment gives a product extreme flexibility. It allows highly personalized configuration and additional features to be added easily by the customer or manufacturer. Massive numbers of features and functions can be added to a product with Ethernet and an open interface for control. Anything you can implement in a PLC or older OPC solution is now available in your product. That is exciting to marketing and sales, and likely scary as hell to support!
Diverging Control Adds New Challenges
We have had a relatively simple life on the factory floor. You have a PLC and pile of devices below. While some factories have dozens to hundreds of PLCs, the relationship is the same: You do all your programming in the PLC, the PLC talks to X number of devices. Beyond some network settings and node IDs you set once, no programming in end devices needs to be maintained. Some devices are more complex and have their own configuration utilities, but those are still usually one-time configurations.
What happens when, instead of maintaining programs in a few PLCs, you are faced with the possibility of maintaining programing in tens to thousands of devices? How effectively can you push recipe changes? Even if you stay true to a single supplier, there are not adequate solutions to maintain these programs autonomously. There is no solution at all for managing the updates of a multi vendor application.
“The inability to manage device programs and updates autonomously seems like a massive hole in the automation market”
The industry is tackling the data flow problems we face in IIOT well, but the inability to manage device programs and updates autonomously seems like a massive hole in in the automation market. IT can globally manage PCs and updates but we don’t have the same tools in automation. If/when security finally becomes a forefront concern, this issue will become an even bigger one.
Moving a PC Problem to Devices
One of the biggest headaches for large manufacturers is maintaining the PCs on their factory floors. At a big automotive maker, you have hundreds of PCs dedicated to control. These are typically legacy machines that implement special features or control though OPC or some proprietary software interface on a PC. Control at the device level will eliminate most of the need for these PC controls solutions, but the root issue remains. You still have hundreds of disparate systems to maintain. You’re no longer worried about many of the PC-based security risks, or which PCs are Windows XP, but you still have no universal mechanism to manage, maintain or upgrade your system of devices. PCs, for all their other shortcomings, handle updates and system management much better than anything in automation. That is contingent on keeping your operating system up to date of course.
What’s Going to Happen?
There is no question that device-level control and the expansion of entry/micro level PLCs has made the machine builders’ work a lot easier, and allowed them to much more economically create the control for the machines they sell. Those benefits will continue to push the use and growth of device-level control. While it’s great for the machine builders, it does not solve the maintenance, upgrade and backup concerns of the large manufacturers. The movement towards device-level control likely makes their life harder.
We are eliminating silos of information as we connect to information technologies, while creating silos of control technology. I don’t see a clean solution or standard emerging anywhere in the market to tackle this problem.
What are your thoughts? Do you know of any systems that work for your organization? – I’d love your insight.
RTA is at BOOTH #1287
Did we mention there is also FREE STUFF involved?!?
Stop by to receive your special RTA branded, crazy exclusive, limited run, collectors edition stress relief putty.
The most mind blowing result from this survey is that people love stuffing. I never would have guessed. I also learned what Russian salad was after a write-in vote for it.
How do you like to learn?
Which Technologies would you like to learn more about? Please chose one or more of the following:
What is your favorite Thanksgiving side dish?
Do you have a fever, for which the only prescription is more cowbell?
1. C- Modicon
2. B – False
3. A – True
4. A – True – Registers can be combined for floating point, but they don’t natively support this.
5. B – False
6. B – False
7. A – True
8. C – 31
9. D – Unlimited
10. B – False
11. C – Cyclic Redundancy Check
12. B – False
13. D – 247
14. C –Holding Register 100
15. C – Preset Multiple Registers
16. A – 1
17. A – True
18. C – RTU is more efficient
19. C – 3.5 character times
20. A – Big Endian (High byte/Low Byte)
21. A – True
22. C – 247
23. D – Broadcast messages
24. B – False
25. B – 0-65535
Didn’t know as much as you thought? Check out Modbus, the Everyman’s Guide, by John Rinaldi, at Amazon.com.