In Part 4 of this series, we detailed edge computing and gateways for industrial machinery. Now consider the various protocols and communications leveraged in IIoT connectivity — for example, the SCADA, MES, and ERP architectures we already covered in Part 1 and 2 of this series. These are the most involved in IT/OT (operational technology) convergence — often involving enterprise-level tasks, gateways, and other connectivity to allow system configuration through standard web browsers … as well as operational adjustments and additional managerial actions.
Also employed in many IIoT installations is Structured Query Language (SQL) — programming that allows synchronization of data and event logs to MySQL and MS SQL database servers. The benefit here is IT personnel access that’s more simply implemented than alternatives relying on controls. That’s true whether the systems employ basic controls such as Raspberry Pis or complex PC-based IoT database interfaces (which usually necessitate additional hardware and software).
Also seeing massive adoption for how they support multi-pronged IIoT design approaches (involving software, hardware, and connectivity) are infrastructure, platform, and software as a service (IaaS, PaaS, and SaaS respectively) or cloud services. These include Alibaba Cloud, Tencent Cloud, Google Cloud, IBM Cloud, and Oracle Cloud. However, in the U.S., today’s two leading public (offsite not company or machine network) cloud service providers for machine automation are:
• Amazon Web Services Inc. with AWS cloud software and services
• Microsoft with Azure IoT Edge cloud software and services
These primarily support the use of databases (through products such as Amazon simple storage service or S3 buckets and Amazon DynamoDB managed database services), online and local applications, and on-demand computational power. Related to the latter are AWS Lambda services that allow Python, Node.js, Java, and C# programming to run on the service’s servers.
The cloud services serve other functions too. Part of what’s driving AWS and Azure adoption for IIoT is how more engineers have become comfortable with building out their own infrastructure on these platforms. After all, cloud-based data services free engineers from extra design work on underlying hardware and software — because the provider executes IT tasks. AWS and Azure also allow use of software that abstracts dataflows and communications — simplifying some design work with GUIs and other tools that shield engineers from dealing with programming minutia. The cloud services also facilitate advanced engineering with virtual machines that run operating systems and applications … over which design engineers maintain control.
What’s more, cloud services can accommodate various communication services on protocols employing publish-subscribe principles — to be the master service for them all. That eliminates the need for time-consuming addressing during system setup.
All such features can in turn facilitate rather advanced capabilities, including the use of machine-learning algorithms for categorizing and distilling data … to make predictions and prompt machine and production adjustments. No wonder industrial-component suppliers are expanding what they offer for such cloud connectivity.
“WAGO’s controllers are based on Linux — and that allows the application of new software technologies … including Docker, secure IIoT protocols for various cloud platforms, and edge-of-network agents such as AWS Greengrass and Azure IoT Edge,” explains Kurt Braun, IIoT market specialist for WAGO Corp.
A WAGO cloud service at cloud.wago.com gives engineers a simple way get started with IIoT. The service works with WAGO’s PFC100/200 controllers and Touch Panel 600 HMIs with a simple onboarding process. Once established, even nontechnical personnel can customize dashboards with trends and configure email notifications using a rule engine managed from the cloud portal. A beta feature also allows remote access to the controllers’ web-based management for software updates — and remote viewing of the controllers’ web visualization, adds Braun.
The manufacturer’s PFC200 G2 controller and Touch Panel 600 HMI are both certified for AWS GreenGrass Core. That extends the use of AWS (including AWS Lambda and Things Graph) to let connected edge devices (such as sensors and actuators) act locally on data they generate — and use the cloud for data management, storage, and analytics.
With AWS IoT Greengrass, connected devices can also run Docker containers. This containerization service from Docker Inc. comes in both free and professional versions. Recall that in the context of industrial programming, a container is a piece of executable software that holds the codes, system tools, runtimes, libraries, and settings needed for the standalone running of an application. In many machine designs, containers are designed to communicate and synchronize data to other systems or execute various predictions — even when disconnected from the internet.
According to Braun, advantages of building applications in containers include:
• Easy deployment onto devices
• Portability of software to allow its use across different platforms
• Improved security by providing a sandbox for engineers’ applications
“Docker can install on WAGO’s PFC200 and TP600 products. In fact, WAGO regularly releases numerous prebuilt containers to extend services onto its products. Examples include TosiBox Lock for Container VPN, Inductive Automation’s Ignition Edge, and Dianomic’s Open Source FogLAMP,” adds Braun.
Other manufacturers offer Docker containers for their own arrangements. “We only offer edge gateways to design engineers wanting a complete solution from us,” explains Weishaar. “But we may soon offer software containers for Docker-based edge gateways that connect our motors. We deem this most effective, as most machine builders and operators don’t want unique gateways from each component supplier. For such builds, we consider message queuing telemetry transport (MQTT) along with REST API and AMQP — another transport protocol for data communication — to be a leading communication standard above the edge.”
In fact, MQTT is also indispensable in many IoT connectivity structures. For the uninitiated: MQTT a protocol supporting scalable communications between sensors and mobile devices. Any built-in support for MQTT from a device is also useful because it’s applicable in Amazon AWS IoT services. In addition, MQTT (just like AMQP) is lean and standardized. Consider how MQTT support can be implemented via Festo’s CPX-IoT-GW gateway: This device can handle data from the field level on various cloud or onsite systems. In fact, Festo sources indicate that the supplier will soon offer more MQTT support on its products. They maintain that value-added services at the edge enable provisioning of processed data in third-party systems — which can also run on cloud services. Connectivity to these services is through corresponding modules.
One last common option is OPC unified architecture (UA) from the OPC Foundation. OPC-UA includes publish-subscribe communications in its specification definitions, so can serve as an alternative to MQTT for data transport to the cloud. Those in motion control most value the standardized communication protocol of OPC-UA complemented by time-sensitive networking (TSN) as a vendor-independent fieldbus for decentralized automation.
“As supplier of intelligent motors, we appreciate how OPC-UA with TSN renders any additional PLC unnecessary,” explains Weishaar. “After all, systems benefit from architectures primarily based on motors capable of processing commands and executing motion tasks while communicating in real time with other devices. The latter can include edge gateways that handle some process logic along with connections to upper systems such as ERP or the cloud.”
Increasingly networked operations may be prompting the most dramatic changes in the way motion systems install — and reconfigure. “Today’s plug-and-run technologies automatically identify parallel products, upstream connections, and software residents. Coding with precanned kinematics and function libraries further simplify these designs, especially when they’re as device-neutral or network-neutral as possible,” says Rusk.
Sources at Lenze Americas tout the same. They bill such systems as Plug & Produce — and put emphasis on adaptable systems that are capable of efficiently switching between modes for producing small batch sizes. Key here are changeovers with minimal manual effort. Consider one Plug & Produce production line using the system to make packaged consumer detergents: Individual modules can include infeed, pick and place, packaging, palletizer, and outfeed modules that tag into and out of the line for quick changeovers between the packaging of cream cleansers to the packaging of washing detergents.
In this and other installations, reprogramming is unnecessary; instead an uploading of configuration values prompts and links the right modules. These values primarily control manufacturing processes as well as relay information on tasks and their sequence. Necessary information might include the height of conveyor-belt transfer points; positions to which workpieces must be delivered; and the speed at which they can be processed. Once all criteria are met and with the appropriate physical interfaces, production starts.
Smart factory functions from Lenze also rely on the use of asset administration shells (AASs) as defined by the reference architectural model Industry 4.0 — RAMI 4.0. That’s a standard of the electrical and electronic manufacturers’ association called Zentralverband Elektrotechnik und Elektronikindustrie (ZVEI), a leading manufacturer association in Germany. Check out the article What are RAMI 4.0 and asset administration shells in the context of Industry 4.0? by Danielle Collins for more on this. Each AAS electronically describes a component in a standardized way. That allows exchange of component and system data between assets and higher-level production systems.
AASs employed in Plug & Produce systems can exist for individual components as well as modules and entire machines. Contained data includes that relating to the physics of assets (such as dimensions, service life, and operation values) as well as their functions — whether drive, network component, packaging module, or welding installation, for example. The sum of this data forms a digital twin to allow programming and simulation before physical implementation of a given machine.
Such open-source communication standards let a machine’s modules and its controls automatically exchange AAS data — or even execute autonomous interactions during production. This requires a unified data and information model as well as standardized semantics so data can also be correctly interpreted. The first is with AASs. For the second, Lenze uses an expansion of OPC-UA based on a PackML companion specification. ⚙️ Continue onward to Part 6 of this series: IDE and other software for connectivity and IoT design work