By keeping a simple bus, data can be collected and become useful by processing on the PAC or PLC, which must exist on every machine system. By selecting a PAC with an embedded HMI for Web publishing, users can put the information on the network wherever it needs to go (Figure 2).
In a pneumatic system with a sensor that continuously measures sound in decibels, the only data that needs to be sent to a PAC IO-Link is the current decibel level. Custom IEC 61131-3 function blocks for the PAC can be developed by the manufacturers to work on multiple controllers. The function blocks can check for a different noise pattern and identify a potential leak. It can be programmed to send a message to a maintenance-level user of the HMI before the pneumatic fails.
Fog vs. Cloud: Which Network Do You Need?
A use case should be developed for anyone considering IIoT, regardless of whether they are a machine operator, OEM machine builder, or factory owner. Factory floor managers, for example, may benefit from overall equipment effectiveness (OEE) information, which is not usually information that would be shared with a broader group — for this, it would be best to use an internal server. If the factory floor manager is often far from the machine or away from his or her desk, they would still need the OEE information. Thus, the use case informs the solution: If the machine has an embedded HMI with a Web server, the user could connect it from an Android or iOS platform, provide credentials, and view the OEE without the need for an external cloud. An in-factory network such as this is called “fog” computing.
In a different use case, a purchasing agent may need to monitor yield data for multiple factory lines in different locations, making an external server the only solution. In order to minimize the risk of exposing sensitive company data, the program could be built to publish only the total output, rather than yields. Although the solution must have a cloud server, risk is minimized when restraint is practiced in sending data to external servers. This is necessary for two reasons: the information is less secure than keeping it on an internal fog network, and most plans charge companies for sending and storing data on an external cloud.
When it comes to Industry 4.0, it is important to step back and consider how the information is to be used. The cloud may not be the necessary solution it appears to be.
Costs of Connectivity
It’s a common perception that connectivity increases costs but being connected does not necessarily have to be expensive. It becomes expensive a few years down the road when a company is ready for IoT but the devices that were specified make communication via Web server of OPC-Unified Architecture (OPC-UA) or MQ Telemetry Transport (MQTT) difficult or impossible, or if traditional, fragmented designs are chosen rather than single-machine PACs that simplify data flow. To correct this problem, a company could purchase expensive sensors that go from temperature control directly to an external cloud, bypassing other devices on the machine. From there, a custom layer or Web site would need to be programmed using different software to make the data useful.
But instead of going through all of that, smartly deploy an IIoT, making it part of the machine from day one. If building a new application, it is the perfect time to do this, even if IIoT is not something an organization is ready to implement right now. A few smart choices today can save hundreds of thousands of dollars down the road. Manufacturers are trying to make these choices clear with the marketing term “IIoT-ready.”
Select low-level devices that support buses like IO-Link in order to get data out of them affordably. Also, use standard protocols that are cost-effective and will allow data from many sources to be used. Using single programming software on a single controller simplifies programming. Be sure that the machine controller can have a client-server relationship without requiring an additional gateway. If there is a need to eventually route information to different locations, it can be done in the IEC-based program. Do not discount fog computing; if the PLC has an embedded HMI that is Web-server capable, IIoT use cases could be satisfied without using the cloud. If using the cloud is necessary, be sure to select a controller with software that will make it easy to share to an OPC-UA or MQTT server so that IT can do what IT does best.
No One Solution
There is no one solution for IIoT. Machine builders, factory managers, and business executives must work together to come up with an architecture that works for their systems and their unique needs. What gets lost in all the noise is that the cloud is not the only answer — it’s one part of the greater solution. User case stories are central to implementing a useful IIoT system as many of these users’ needs can be solved with centralized control and providing IIoT on the fog computing layer. This architecture is also future-proof and allows for growth into the cloud if needed. The trick is to prepare and plan today.