Moving toward self-assembly machine automation systems

Evolving PLC and PAC platforms, networking, and programming methods are leading to self-assembled machine automation systems, reducing risk and user integration efforts.

By Keith McNab June 30, 2020

Learning Objectives

PLC- and PAC-based automation is moving towards self-assembled machine automation system applications, allowing modular subsystems to be integrated into an overall system.
Module type packages (MTP) and machine-as-an-object (MaaO) elevate raw data and basic functionality into contextualized information and capabilities.

Automated factories and processes are often created by integrating many smaller machines or equipment subsystems, requiring significant system integration effort and customization. For years, users have desired a better approach to simplify this integration work, to save money and reduce risk. Automation self-assembly is increasing and hardware, communications, and software advances are streamlining system integration and decreasing time from engineering to productivity.

Although machine automation products and practices have improved over time, roadblocks to achieving integration still exist. Many times the hardware, communications protocols, and software programming have relied on incompatible technology, hampering system integration efforts. In the most difficult cases, achieving interoperability among various equipment became an extremely complex, expensive and time-consuming project.

Fortunately, the situation has improved. Even for mission-specific hardware like programmable logic controllers (PLCs) and programmable automation controllers (PACs), efforts to modularize programming have gained traction. Networking methods and protocols have advanced to provide comprehensible information exchange. Building on these developments, PLC- and PAC-based automation technology is moving towards self-assembled machine automation system applications, allowing modular subsystems to be easily integrated into the overall system.

What is automation self-assembly?

Manufacturing facilities of all types commonly incorporate various automated subsystems. A typical beverage producer may have:

Bulk raw product storage tanks
Blending and processing skids
Bottle fillers
Material handling conveyors
Packaging equipment
Water filtration systems
Steam and compressed air utilities.

Other industries might use a mix of equipment, but generally there are many specialized suppliers for any production facility. End users are often more focused on the equipment mechanical interoperability and performance. They may find it impractical or impossible mandating some level of uniformity among associated PLC and PAC control platforms. Therefore the packaged equipment suppliers will end up delivering a variety of automation systems, each programmed using different practices. Some of those elements may even be secured and untouchable for intellectual property or operational performance reasons.

Each of these packaged equipment “islands” will feature its own and often unique controller, input/output (I/O), instrumentation, and human-machine interface (HMI) elements (Figure 1). These will likely need to interact with some combination of upstream equipment, downstream equipment, peer systems, and a supervisory system.

In fact, many end users prefer subsystem PLCs and PACs to be supervised and perhaps even orchestrated by a larger overall control platform. System integration is the effort of coordinating these interactions. It’s no surprise integrating the disparate systems into a cohesive whole is quite difficult.

However, if each subsystem could define the available data and functionality, and then expose these attributes to other systems, it would make system integration efforts more efficient. This ability can be referred to as self-assembly, which leads to simpler, less costly and quicker implementations.

Automation system integration evolution

Basic self-assembly may require an export of the subsystem PLC or PAC configuration, which is manually imported into the supervisory control platform. In more advanced situations, the subsystem could self-announce (or publish) its capabilities to a supervisory system capable of responding in kind. This could even occur dynamically through change event notifications.

Self-assembly relies on several fundamental features. PLC and PAC platforms and practices have improved along an evolutionary path for many years and have gained many of the necessary abilities including:

PLC, PAC, and networking hardware acquired sufficient power to allow for programming and data modularity, reusability, and communications.
Networking protocols added models so data could be transmitted in context.
System-level modular configurations concepts leveraged the previous developments to make self-assembly possible.

The following sections explore how each of these stages progressively support the goal of achieving industrial automation self-assembly.

PLC, PAC and edge control building blocks improve system integration

PLCs were the original mass produced digital industrial automation platform. The earliest models used rudimentary ladder logic and were proprietary from vendor to vendor. Programming each new project required at best copying and pasting or rewriting at worst. Some PLCs eventually gained the ability to encapsulate frequently used routines.

As these automation platforms gained more features, suppliers began to designate them as PACs. PACs included better provisions for creating user-defined and original equipment manufacturer (OEM)-specific library-based objects, which could be configured to protect intellectual property and help guarantee performance.

Edge controllers have become available the last few years. They merge PAC capabilities with PC-like computing functionality, combining operations technology (OT) deterministic control with more information technology (IT)-friendly processing and networking.

Shared database concepts made it easier for multiple control elements like PLCs, PACs, edge controllers, HMIs, and motion control systems to interact. Automation systems also became easier to use and more capable and have gained some concepts similar to the object-oriented programming (OOP) found in commercial systems for promoting creation, use, improvement, and reusing code. However, progress of logical and data handling has remained largely focused at the machine automation level.

Using Ethernet for industrial automation

For connecting PLCs, PACs, edge controllers, HMIs, and other machine automation elements, Ethernet has become the medium of choice. Of course there are still some use cases, such as motion control or hazardous locations, where a more specialized industrial fieldbus offers a performance advantage. For most in-plant situations, though, Ethernet has delivered the fundamental networking performance needed to transition from basic data transfer to comprehensive information interchange.

Many protocols are available for industrial Ethernet applications. Some of them transfer raw data and require extensive user planning for the sending and receiving systems to handle scaling, descaling, tag grouping, and poll rates.

More advanced protocols — such as OPC UA — include reference, variable, object and data types, which allow end users to formulate information models with semantics. Semantics enhance the raw data with context, including descriptive and scaling information, enabling the creation of object-oriented information that can be comprehended by system components. The information model also has the capability to notify receivers of the information (clients) about its existence and whether changes to the structure or semantics have occurred.

For instance, when a pump type is instantiated in a PLC program, discovery services can notify client systems a new pump object exists and where to find it. The pump object could include data tags for running status, speed command, and inlet/outlet temperatures and pressures (Figure 2). If a bearing temperature tag is later added to the pump, the data structure could be updated, and client systems notified.

Using semantics, receiving systems can automatically interpret data from originating systems. The machine automation systems can effectively talk to each other using the same language.

Machine-as-an-object benefits for suppliers, manufacturers

The preceding advancements for logic, data, and encapsulation have been necessary precursors for achieving an overarching machine-as-an-object (MaaO) concept. When a supplier configures their equipment using MaaO practices, they are encapsulating the machine automation system so it can announce itself and be self-assembled into other systems.

Industry standards such as NAMUR module type packages (MTP) have been instrumental in elevating the concept of modularized and encapsulated systems (Figure 3). MTP identifies certain aspects of automation and indicates how they are exposed for interactions with outside or supervisory systems. When MTP-based automated equipment is attached to a supervisory system, the system can understand the equipment as a functional machine object.

MTP provides a way for developers to identify and define the available equipment functionality, and how to invoke it. All the necessary data tags are exposed in context for commanding, monitoring, alarming, and diagnosing the subsystem. Even the HMI displays can be developed by the subsystem supplier and imported into the supervisory system.

A machine configured using MTP may contain significant logic and data tags for internal use. However, a supervisory system can access just what is needed for high-level operation. For instance, a packaged PLC-controlled mixing tank subsystem could be integrated with a supervisory system using MTP. The supervisory system could call for fill, mix, and drain cycles. The machine’s automation system would then handle the details of timing, opening and closing valves, operating the mixer, and generating status and alarm tags.

The path toward self-assembly machine automation

The evolution of industrial automation has been leading toward systems which are more integrated, and concepts like MTP and MaaO elevate raw data and basic functionality into contextualized information and capabilities. Forward-looking companies are ensuring their PLCs, PACs, edge controllers, software, and networking platforms are ready for self-assembly, providing end users with the ability to assemble and reconfigure production plants using modular subsystems.

Keith McNab is technical product manager, Emerson. Edited by Chris Vavra, associate editor, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.