Standardizing control system programming with IEC 61131-3

For the first time in the history of industrial controls, industrial control system (ICS) programming—regardless of the controller type—can be implemented with the same standard, and the programs created with that standard easily can be transported from one compliant control system to another.
By Gary Pratt March 2, 2017

Figure 1: The IEC 61131-3-compliant integrated development environment (IDE) for the Bedrock universal control system can be used to implement programmable logic controller (PLC), supervisory control and data acquisition (SCADA), remote terminal unit (RTUWith the PLCopen IEC 61131-3 standard, ICS users are free to choose the optimum hardware to use with their applications and are no longer locked into single-vendor proprietary hardware because of their investment in software written to closed proprietary standards.

The latest version of the IEC 61131-3 international industrial control programming standard provides low-level languages for detailed programmable logic controller (PLC) and programmable automation controller (PAC) programming as well as object-oriented language features for creating and configuring high-level distributed control system (DCS) and industrial PC (IPC) objects. From low-level discrete PLC programming to high-level continuous process DCS/S88 programming-built in the same environment with the same programming language standard-IEC 61131-3 and modern development environments allow ICS programmers to fully simulate their program and human-machine interface (HMI) screens to ensure systems will be valid on deployment.

Control engineers face a daunting variety of choices in tools and techniques for programming industrial controllers. Tools have evolved along different trajectories partially due to the task they were called to accomplish, but mostly due to the limitations of early hardware, evolution of tools within application silos, proprietary features of each automation supplier, and a lack of international standards. Fortunately, modern hardware and modern standards including IEC 61131-3, PLCopen, and OPC-UA have made it possible to develop ICS applications from PLC, through PAC, safety, remote terminal unit (RTU), motion, IPC, DCS, and all the way to S88/S95 in the same environment under the same standard (see Figure 1). It’s no longer necessary to learn and use different tools for varying industrial control needs.

Likewise, with these modern standards, it is no longer necessary to be locked into a single proprietary hardware vendor and associated proprietary software. ICS application programs developed with the IEC 61131-3 and PLCopen standards can be transported from one compliant integrated development environment (IDE) to another. At last count, the IEC 61131-3/PLCopen-compliant platform is being used by more than 350 OEMs. Parallels can be drawn to the 1980s when early PC vendors provided their own operating systems until consolidating on Microsoft and Apple, or the 1990s when early smartphone vendors provided their own operating systems until consolidating around Android and iOS. A similar consolidation in the ICS application programming world is underway now that unifying standards and methodologies are available. 

Figure 2: IEC 61131-3 provides traditional relay ladder logic (LD) and flat memory space to ease the transition for programmers moving from older tools. Courtesy: Bedrock AutomationIEC 61131-3 tools

IEC 61131-3 provides traditional relay ladder logic (LD) and flat memory space to ease the transition for programmers moving from older tools. But IEC 61131-3 also includes structured and object-oriented programming tools for creating higher-level applications, much to the relief of the new generation of engineers entering the industry who often bristle at the thought of programming in their great-grandparents’ language. These tools include three new programming languages, language-neutral hierarchical function blocks, symbolic hierarchical addressing, pointers, methods, inheritance, and interfaces.

In addition to the traditional LD, the new IEC 61131-3 languages include structured text (ST), sequential function chart (SFC), and continuous function chart (CFC). Ladder remains a good tool for what it was originally invented for nearly a century ago: simple discrete logic that could be implemented in relays and timers. SFC is a great language for sequential or state-based operations (anywhere the next action depends on history and inputs). CFC is a new graphical language and is an excellent high-level tool for placing and interconnecting pre-built or custom-built blocks. CFC serves the same purpose, but is a vastly superior alternative to placing library blocks or add-on instructions in ladder logic. And ST is good for all other programming (loops, conditionals, complex math, bit manipulation, etc.). 

Feature flexibility

The powerful features of IEC 61131-3 allow the same language to create programs as small as a PLC motor controller, or as large as a DCS process plant. For example, a motor controller can be implemented in ladder as shown in Figure 2. Or, because its behavior depends on its history, it may make more sense to implement in SFC. The SFC implementation can use an optimum mix of languages with the states being implemented in SFC, the transitions in LD, and the actions in ST (see Figure 3).

Figure 3: The language-agnostic nature of IEC 61131-3 allows a motor controller to be implemented in the best language for the purpose: sequential function chart (SFC) steps with ladder logic (LD) transitions and structured text (ST) actions. Courtesy: Be

Lower-level models, such as the motor controller, can be assembled to make higher-level models. These building blocks can be custom-made models or objects from a process library. Figure 4 shows how an entire DCS process plant can be built from mix tank models that are built from input sensor, control, PD pump, and pump objects, which themselves are built from lower-level objects. The control object also is built from lower-level objects, which includes an SFC to manage flushing and filling, as well as control blocks to manage the PD pump and pump control loops. Those control blocks are made of a custom block implemented in ST, which subtracts the difference between integration of the input flow value and the accumulation of the PD pump pulses. The output of that block drives a low-pass filter from the free Open Source Community for Automation Technology (OSCAT) open-source controls library, which then drives an OSCAT proportional-integral-derivative (PID) block.

Figure 4: The plant view, and control and equipment views provide easy to understand structures that intuitively match the hierarchical design from pretested library blocks simplifies design and maintenance of complex distributed control systems (DCSs). C

Not only do IEC 61131-3 hierarchical design techniques make plant controls easy to design, they also result in designs that are very useful for plant maintenance. Consider a plant technician being called to deal with an issue with a silica PD pump motor in mix tank 2 in process area 3. The technician can begin at the top and double-click on each block as shown in Figure 4 until reaching the silica PD pump on the control and equipment view, or go directly there via the device view. 

When there, the technician examines the inputs to the PD pump to verify the motor is being commanded to run. If so, the technician would drill down into the PD pump  and into its motor model to see why the motor is not running. If the motor is not commanded to run, then the technician would drill down into the upstream control block to determine why the sequence is stuck in the state prior to running the motor. Because the control code mirrors the plant hierarchy, navigating to the applicable area of the control code is intuitive. And, because all the physical input/output (I/O) is located in the equipment models, finding and fixing issues also is intuitive. There would be no need to train plant technicians on complex procedures for troubleshooting complex control code.

Going a step further, inheritance and pointers can be used to implement S88 and S95 modeling techniques directly in IEC 61131-3, which will become increasingly important as different control platforms are deployed in batch and enterprise wide integration schemes involving connected assets (see Figure 5). The left side shows how an equipment base class containing I/O and functionality common to all equipment can be inherited by multiple unit classes-which define the I/O and phases for the class-and themselves can be inherited by multiple equipment types-which also define the unique operation for that type. Phases, which are built with a similar class structure, define the operations, which are possible on an equipment unit class. These phases are then instantiated into the equipment unit classes for which they are valid. Operations, procedures, modules, and process cells similarly are structured to make up a complete S88 system.

Figure 5: IEC 61131-3 object-oriented programming (OOP) features including inheritance, interfaces, and pointers provide a simple implementation of S88 batch processes. Courtesy: Bedrock Automation 

The right side of Figure 5 shows how objects of this class hierarchy are instantiated in the project. The base class gathers information about the equipment, along with its associated phases, and records this information in a registry. This registry is then made available to a batch server via OPC-UA, which uses this information to determine where and how to implement batch processes.

Based on the selected recipe and idle equipment, the batch server then sends selections back to the main program via OPC-UA, which then uses the pointers stored in the registry to execute the desired phases on the desired equipment. Thanks to inheritance, the complexity of the base class operations is hidden from the programmer. All the programmer needs to do is assemble library blocks that differentiates the equipment types. Or, using dynamic objects, the structure could be configured from the batch server as well. 

Figure 6: IEC 61131-3 object-oriented features and built-in full-function simulators promote control, and human-machine interface (HMI) validation and verification before the project is deployed. Courtesy: Bedrock AutomationProof is in the testing

Of course, no ICS design is complete until it can be tested and proved correct. Fortunately, the features in IEC 61131-3 and its implementations provide the tools to make this step very easy. Figure 6 shows how plant simulation blocks can be assembled to create a complete plant simulation model, which can be connected into the control code interchangeably with the physical I/O.

The control and simulation code then can be executed on a PC-based runtime simulator so the control applications of a complete system can be proven to be error-free before any hardware is purchased. Using the PC-runtime’s OPC-UA server also allows the HMI screens to be designed and tested. This results in the confidence that the ICS design is complete and correct before installation or commissioning begins.

Gary Pratt is the applications engineering manager for Bedrock Automation. Edited by Jack Smith, content manager, CFE Media, Control Engineering,


Key concepts 

  • The latest version of the IEC 61131-3 control programming standard provides languages for programmable logic controllers (PLCs), programmable automation controllers (PACs), distributed control systems (DCSs), and industrial PCs (IPCs) objects.
  • IEC 61131-3 languages include traditional relay ladder logic (LD), structured text (ST), and sequential function chart (SFC).
  • IEC 61131-3 hierarchical design techniques make plant controls easy to design, and result in designs that are very useful for plant maintenance.

Consider this

Think about what it would be like to implement industrial control system (ICS) programming—regardless of the controller type—that can be transported among control systems.

ONLINE extra

See related articles below, offering more information about IEC 61131-3 and object-oriented programming (OOP).