At the core of any automated system is the basic closed-loop paradigm: sense, decide, act. This model reverberates from the lowest machine component all the way to the business enterprise, starting with sensors, logical algorithms, and end effectors.
Sensors
Contact or noncontact, sensors are made up of a mechanical component, which at the very least supports and positions the sensor, and a means of communicating the presence, absence, or intensity of the measured phenomena. Each can be designed as an island of sensing encapsulating everything needed for its function and providing an interface for mechanical, electrical, and information integration into the larger system. Object-oriented control code is uniquely suited to reside on these islands.
Controllers
Controllers range from simple bare-metal processors with embedded control algorithms to complex multicore controllers parsing the logic, motion, visualization, communication, safety, and measurement functions. At the lowest level, modular code allows encapsulation of the limited functionality of these controllers, while at the higher levels this same modularity permits rapid integration and configuration of complex state machines.
Effectors (actuators)
The action portion completes the automation triad and can be as varied as the applications, including servomotors, fluid power, and laser energy to implement action.
Mechanics evolves into informatics
The history of packaging machine technology illustrates the evolution from mechanical to information-based automation. Originally, there were complex, internal mechanical cams and gear arrays energized through central driveshaft timing and driven by a prime mover. These machines are now sleek, compact designs based on distributed servomotor technology facilitated by the availability of software-based cam and gearing profiles and high-speed closed-loop communication protocols. This "extraction" of mechanical complexity has contributed greatly to the increasing accuracy, speed, and reliability.
A similar metamorphosis is occurring in all segments of industrial automation as the mechanical-to-informatics ratio has nearly inverted over the past two decades in diverse industries including assembly, energy distribution, and batch processing. It permeates all levels of automation design, as evidenced by the degree to which informatics-based automated response to production-level data is driving supervisory and even corporate behavior.
Everything gets smarter
Early in controller-based automation, all the intelligence was concentrated at the decision-making level of the triad. Today, with modular software design, this capability is much more distributed. At the sensor level, we see photo eyes that can manage their own dwell times, sensitivity, and internal diagnostics. Actuator components such as a servo drive simply need to receive a position command from the central controller and can locally calculate velocity and acceleration and deceleration loop closure. This local encapsulation of intelligence greatly eases the integration of these components into an automation solution. This efficiency is only fully realized using a modular reusable code architecture like that of the IEC 61131-3 Programmable Controllers - Part 3: Programming Languages standard.
Architecture of modern automation systems with sensors, actuators, and controllers
Object-oriented programming
Object-oriented programming to the rescue
When you recognize the self-contained, component nature of the mechatronic architecture, it becomes desirable to create an informatics domain that maps directly to it. This is where object-oriented programming excels.
Modular programming architecture
Object-oriented programming begins by defining specific program organizational units, each with key structural advantages. Programs, function blocks, and functions are used to accomplish different goals: programs are intended to be more organizational and coordinative, while functions are a means of encoding basic operations that require few parameters. The real stars of the show are function blocks encapsulating functionality that can be reused over and over and modified on the fly through a parameter interface.
Generic control through interface definition
The fullest implementation of object-oriented programming takes these function blocks and subdivides them even further into a method (what the function block does) and an interface (the data the function block needs to accomplish its method). The key advantage is the interface can be defined without needing to know how the method will accomplish its objective. It is a bit like being able to drive any car, whether it is gas, diesel, hybrid, or electric. Once you know how to "interface" with the car, you have little interest in how it accomplishes its method of getting you from point A to point B. Two examples will illustrate this concept:
- A "generic" sensor interface can be defined with an "enable" signal input, sensitivity and hysteresis parameters, and a presence/absence output. Once this interface is defined, the method written for the function block controlling the sensor can be different depending on whether the application uses a photo eye, a capacitive sensor, or a contact probe.
- You can use the same interface to integrate a servomotor or a fluid power for axis motion, even though they are different motion hardware.
Communication creates distributed intelligence
After designing a component-oriented mechatronic architecture with mapped object-oriented code, the only remaining requirement for efficient integration is a standardized communication structure.
Communication protocol
As was the case with the "working" sense-decide-act components of the automation system, first standardize the hardware and software of the communication system that will integrate these components. Several Ethernet-based industrial communication networks exist to manage the various domains of automation, including EtherCAT, Powerlink, EtherNet/IP, Sercos III, Profinet, and others that leverage commercial-off-the-shelf Ethernet to standardize this aspect of the mechatronic structure.
Communication data structures
The structure and syntax of interdevice communication is greatly facilitated by the introduction of OPC UA. OPC UA is a scalable and portable technology that describes and transports information securely, reliably, and flexibly. It is a perfect fit for smart manufacturing, allowing machine-to-machine communication and integration from the plant floor to the management suite. The PLCopen organization (www.PLCopen.org) has simplified the application of OPC UA with the definition of 24 OPC UA function blocks within the IEC 61131-3 framework for programming controllers, coordinating control, and interacting with enterprise IT, cloud, and Internet of Things applications (e.g., cloud solutions, big data collection, data analytical tools). These communication standards reflect the modular, standards-based solutions occupying the modern mechatronics and general automation landscape.
Modular architecture has automation advantages
Now that we have examined some of the available solutions for providing standards-based, modular architecture, what are the advantages and why apply them to applications?
Flexibility: Mechatronic components mapped directly to object-oriented code create a "Lego" toolkit that can be assembled into a vast array of end devices. Once the mechatronic components are matched with their encapsulated method and provided with standardized communication interfaces and a network protocol, smart sensors can be coupled to smart actuators with little or no need for additional supervisory control.
The more "granular" the description of the objects becomes, the more flexibility is created. Just like Legos: the more foundational the individual component objects, the less modification is needed to integrate them into a solution. Think of the utility of a Lego block with only one "interface bump"; it can be part of almost any design. Similarly, the more fundamental the mechatronic object, the broader the scope of potential applications.
Reusability: Create it once-use it over and over-across projects and time. Once a class object is created, each copy in the application simply requires a new instance of the object. For example, once you create code to describe a photo eye, each additional photo eye in the application simply uses a copy (instance) of the original. Because the method and interface has been written to handle all functionality of the sensor within that function block, all that remains is to map the interface to the application and provide the needed parameters to each unique instance.
Objects created for one application can easily be maintained in an object library for use in future applications, because they are reusable in any project. The more foundational an object, the greater the likelihood it has an application in other projects. Recognize that many of these library objects are hardware independent and can thus be reused across development tools and controllers.
Transportability: Code is usable across industries. Mechatronic components and their mapped code modules created for discrete applications may be applied to process automation. Similarly, an object created for factory automation may have applications in mobile environments.
Adaptability: The use of methods and interfaces allows the application to be "agnostic" regarding the underlying method used to accomplish a given application goal. Once an interface is defined, the underlying method can change to fit the mechatronic component being used in each specific application. This is another example of allowing "best solution" design, because in one environment servomotors may be appropriate and in another a fluid power solution may be more effective.
Scalability: This advantage has two aspects. The first is less obvious but is grounded in the ability to expand the use of IEC 61131-3 to encode nonhardware-based application functionality, such as communication and visualization. Each of these can be realized using function blocks authored in IEC code. In another respect, the granular nature of IEC 61131-3 code allows it to be scaled from the lowest-level embedded device to the highest-level multicore industrial process controller.
Validation: This is one of the most under-appreciated advantages of modular code architecture. Once the code within an IEC 61131-3 object is validated, the object (function block) can be locked and traced using an electronic signature. Reusing the object does not require repetition of the expensive, time-consuming validation process. As increasing regulatory pressure affects the manufacturing of medical devices, food, and pharmaceutical, personal care, and other products, this advantage takes on considerable significance.
IEC 61131-3 code supports all these architectural advantages
Program organizational units are designed to match mechatronics components with modular code.
- Program-level code can match machine subunits and behaviorally discreet functionality.
- Function blocks can encapsulate specific behavior and map it to specific mechatronic components.
- Functions can encode generic operations executed across a broad array of components.
Language options: IEC 61131-3 defines the syntax for Sequential Function Chart, Function Block Diagram, Ladder Diagram, and Structured Text, providing engineers a toolbox to select the best-of-class language for the application. Sequential Function Chart is an ideal means to define top-down state machines. Continuous Function Chart is ideal for visualization and tracing logic pathways. Structured Text is a compact, powerful text-based language for coding complex automated behavior in a dense format.
Normalization of programming syntax makes training efficient and durable. Perhaps one of the most important achievements of the standard is the normalization of programming languages that have a rigid syntax. There is little ambiguity about how each one is used to accomplish a given automation goal. Once the languages are learned, they are applicable across a broad array of compliant controllers from participating companies. This makes it easier to move between application development environments from multiple vendors. In addition, third parties can provide hardware-independent solutions that further expand the range of development and control options.
Once they have been trained in the use of one IEC 61131-3 compliant development and control environment, the migration threshold to new environments is minimized. Engineers, technicians, and operators can be more effective over a broad range of applications.
Library-based reusability is at the foundation of the IEC 61131-3 automation software standard. Every module created with the IEC 61131-3 software model can be saved for reuse, increasing productivity. Emerging global object libraries have reliable and tested solutions to use instead of reinventing new functions.
Figure 1. Ladder Diagram programming
Figure 2. Two-axis camming function block
Figure 3. Structured text programming
Standards-based products and solutions enhance market value
In a competitive and innovative environment, the life cycle of existing products is abbreviated, and time to market for new products is accelerated. Standardization of the software technologies and tools helps shorten development time relative to that of complicated, maintenance-intensive proprietary software tools. In addition, users benefit from access to multiple qualified suppliers, standardized development and maintenance tools, reduced training investments, and increasing independence from single-supplier solutions.
Vendor conformity to the IEC 61131-3 standard leverages previous resource investments. Once engineers gain qualification in a standard like IEC 61131-3, they also gain the flexibility to work with different brands of software development and maintenance tools that are compliant to that standard. This allows users to expand their supplier options, pick the most suitable system for specific tasks, and reduce overall automation costs.
Engineers wishing to leverage their intellectual property by coding with program code or function blocks that are reusable on different systems, increasingly specify standards-compliant hardware and software in the design phase of a new machine, process, or plant for enhanced supplier independence. This desire for transportability is also true across different development environments. The PLCopen organization has specified the PLCopen XML format, which allows applications developed in one tool to be reusable in another environment.
Technicians trained in the IEC 61131-3 software standard can easily learn new applications as automation expands in factory and machine environments. For example, a qualified engineering technician comfortable using IEC 61131-3 to program and maintain packaging machines can easily program a different type of machine or a completely different application, such as off-road vehicle automation, building automation, or even "smart-grid" electrical distribution automation. This provides opportunities for diversification in human resource management, as well as career migration opportunities for individuals.
Considering some of the advanced features of standards, we notice that retooling and process improvement are accelerated in standards-based environments. Manufacturers' innovation of programming tools based on standards provides user-friendly features and increased application development efficiency. Examples include integration of source code management, static code analysis, automatic test features, profiler functionality, refactoring, and even integration of C-code in an IEC application. Having such features completely integrated into a development environment adds value and accelerates adoption of the standard.
The increased performance and lower cost of hardware reduces the number of controllers in one installation. Today's applications might require a programmable logic controller (PLC), motion controller, safety controller, and display. Modern system architecture allows a central, multicored control system to cover these requirements. The PLCopen organization has defined sets of function blocks for motion control and safety, so a conforming control system can take over these tasks. Modern programming environments will allow the engineer to develop the PLC code, motion code, safety application, and communication setup all in a single tool, even using a single application.
Standardized application specification, development, and maintenance
Automation solutions are much easier to manage when all parties communicate from a standards-based platform. In many projects, several engineers are involved in the specifications, design, and maintenance with tasks divided in different teams. For the largest systems, it is not unusual to involve third parties as outsourced engineering or integrators. The standardization dramatically eases communication between teams and their understanding of the code. Standardized code modularity eases validation, performance acceptance testing, and life-cycle maintenance.
Enhanced mechatronic interoperability
The interoperability of hardware in a standards-compliant, component-based architecture offers options for the selection of best-in-class mechatronics solutions. Upgrading an automation system is easy when standards create predictable component interfaces. When the application scope needs to be extended, the standards-based mechatronic architecture can be easily integrated into the software ecosystem with coding extensions and configuration over standard communication protocols. Machines become modular when the mechanics and automation components are mirrored in a modular application-code architecture.
Industrial automation is advancing inexorably in the direction of flexible, component-oriented design and implementation. Standards-based, modular architecture has significant advantages for industrial automation, and the IEC 61131-3 fully supports this approach.
A component-oriented automation approach is financially beneficial for users thanks to the expansion of compatible suppliers, the flexibility of component selection, and the reduction of overhead in the design, integration, and maintenance phases of the system life cycle.
It is no surprise that standards fit comfortably into the nimble architecture of the emerging mechatronic era. Smart manufacturing is here, and innovators, suppliers, and users alike prefer automation platforms based on standard technologies like IEC 61131-3, supporting PLCopen, OPC-UA, TSN, and real-time operating system environments. Stakeholders at every level benefit from such standardization.
A version of this article also was published at InTech magazine.
