Programmable automation controllers (PACs) play the primary role in IIoT systems. Also referred to as machine controllers, PACs provide a centralized architecture; they act as the central programmable logic controller (PLC) as well as motion, vision, pneumatic, hydraulic controller, and even embedded human-machine interface (HMI) or visualization (Figure 1). The benefit of the PAC approach is that the program does not need to share tags between devices due to components being part of the same device and using the same logic. This facilitates IIoT capabilities and reduces programming time. This is critical to IIoT as it allows the flow of accurate, actionable data to easily transfer within the machine and out to the user or server to make critical decisions with that data.
Consider a common and basic inquiry a user might have: monitoring position error. In a PAC device, the motion controller, PLC, and HMI are all part of a single component, meaning no tag sharing or bus-based communication is required among those devices. Since many PAC manufacturers now offer embedded Web-based capabilities, the position error alert can be sent to both the local operator as well as the plant manager via email or text message, all in a single device. This is preferable to a traditional approach that would have required programming up to four separate devices in addition to configuring and ensuring proper bus communication among those devices. PACs eliminate complex data transmission between devices when the logic is written on a single programming software that is downloaded to one hardware device. The tight integration allows the ability to get information easily and anywhere.
When developing a machine for IIoT, it is critical that the developer reach out to all stakeholders of the machine at the factory — not just who is operating the machine. Those on the “carpet” may have just as much need for information from the machine as those on the factory floor. Having a PAC with an embedded HMI and Web server allows all of these users to get the data they need, but only if the machine builder does the proper due diligence and outreach to all the stakeholders to provide this value.
Easy information flow between machines is as important as information flow within the machine. The IEC 61131-3 standard for programming ensures that machines developed by different manufacturers speak the same language, which benefits integrators who need to make two different machine systems talk to each other, which is necessary for IIoT. Organizations such as OMAC (Organization for Machine Automation and Control) PackML take IEC 61131-3 to the next level by developing standard state machine and tag labeling that machines should make available to other machines on the network in addition to recommending how systems are programmed.
Integration Impacts Data Quality and Flow
Take the example of a motor overheating. Traditionally, the temperature within a motor was not even monitored, so a motor overheating would not be detected until there was a critical over-current failure. If the amplifier was connected to a motion controller over a bus network, it may be able to communicate the type of failure back to the drive. If it wasn’t connected to the bus, which is still common, the motion controller may interpret the error simply as a “position error.” The motion controller, usually connected to the PLC over a different type of communication bus, may then be able to communicate some type of error to the PLC but may be restricted to only communicating a bit that represents “error.” The PLC passes the error out to the HMI, potentially over another bus type with its own constraints, to finally display “machine error” on the user’s screen.
Perhaps a better scenario may specify where in the machine the failure is occurring such as “conveyor not starting.” Even though the data is presented to the operator, it’s the maintenance person who needs to repair the machine. The maintenance personnel are only notified when called; thus, the operator may try to repair the machine or may incorrectly describe the maintenance issue, worsening the problem and increasing down time. A lengthy game of data-telephone is an all too common occurrence on the factory floor. If traced back, the data is available — it’s just not easily accessible to the right audience.
Now, compare the same motor heating issue with a machine using the PAC — an all-in-one motion control, PLC, and embedded HMI. Since the PAC is controlling and commanding the drives, it can directly query the temperature information. The PAC is also responsible for the PLC logic, and thus can be programmed to check that the temperature data is within normal operating limits. If the temperature goes out of this range, the HMI — which uses the same PLC logic — not only can notify the operator but because it is a Web server, it can send an alert to the maintenance person of the exact issue, which axis is being affected, and even the current temperature. That is the definition of complete ease of data flow and is only achievable if the machine is controlled through a single device.
Turning data from low-level devices, such as valves and sensors, into useful information can be a challenge. One approach is to process the data at each device and then send results over a high-performing control bus or directly to the cloud. It can be an expensive approach and it won’t help in gathering or centralizing data. There has been significant growth in IO-Link, a serial-based protocol that collects basic data from sensors, solenoids, valve manifolds, and other devices, eliminating the expensive overhead.
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.
This article was written by Marissa Tucker, Product Marketing Manager for Controls and HMI at Parker Hannifin, Cleveland, OH. For more information, visit here.