The term automation can be understood in two ways. On the one hand, it refers to technical systems that process workpieces or perform building functions independently without human intervention, while on the other hand it also stands for the activity of automation. In other words, how the mechatronic components and mechanics of a system can be interrelated or orchestrated. With the invention of the PLC over 50 years ago, a specific approach was established that has had a decisive influence on automation to this day. This logic is laid down in the IEC 61131 standard.

Update for automation logic

What has developed in the world of automation since then is something of an anachronism. While technologies, computing power, bandwidths and the requirements for changeable and modular systems have developed rapidly in some cases, the clock has practically stood still when it comes to automation logic. The basic approach to automation today has hardly changed compared to the 1970s. What's more, IEC 61131 has set virtually no limits to the coupling of hardware and software. Today, when everyone is talking about IoT and end-to-end networking, the existence of these manufacturer-dependent systems almost seems to have fallen out of time. After all, the sober reality of automation has little to do with IT logic, reusable software objects or interoperability.

As early as 2005, an attempt was made to bring the basic rules of automation into the 21st century with the IEC 61499 standard. Although intended as a further development of IEC 61131, IEC 61499 essentially describes a completely different approach to automation: the focus is on manufacturer independence, IT-OT convergence and flexible architectures. However, not much has happened since then. Only now is the "pressure of suffering" among end users and machine manufacturers great enough to seriously consider a paradigm shift in terms of automation. The founding of the non-profit organization UniversalAutomation.Org, to which well-known industry giants belong, and the commitment of a major manufacturer such as Schneider Electric are evidence of this rethink. As IEC 61499 is also experiencing a revival, it is worth taking a closer look at a type of automation that is characterized by IT logics and a decoupling of hardware and software.

IEC 61131 and IEC 61499: the differences

IEC 61499 defines a standard for the software-based development and design of complex machines or systems with distributed intelligence. As a result, the logic responsible for controlling the individual system components no longer has to be the responsibility of a central PLC controller. In accordance with IEC 61499, it is possible to freely distribute the program structures created in the engineering tool to the mechatronic components (with CPU) of a system. In this way, a controller-centered automation approach is replaced by an application-oriented one. This means that instead of programming a single controller, an automation project is modeled in its entirety in a software layer that is independent of the hardware - even before a piece of steel has to be installed. Another fundamental difference is the object orientation in IEC 61499. Although IEC 61131 also refers to function blocks or objects, these are directly dependent on global variables and therefore on the overall process. Software objects, as defined by IEC 61499, are much more independent, making them easier to reuse. This has an impact on the development process: the old, process-oriented programming approach is being replaced by a modeling approach based on objects.

Object orientation in the sense of IEC 61499

With regard to the requirements of flexible and modular systems, automation in the case of IEC 61499 is consistently object-oriented. Properties such as reusability, transferability or plug-and-produce are of crucial importance. In order to guarantee this, the software objects must be doubly independent. On the one hand, this concerns the global variables (which, as we know, play no role in IEC 61499) and, on the other hand, the manufacturer binding. Only if the use of software objects is not linked to the presence of specific hardware components can we speak of real openness. And it is precisely here that there is a significant difference to automation according to IEC 61131. As there are no restrictions or guidelines with regard to the manufacturer-specific design of function blocks, a vast number of hardware-dependent function libraries have been created, which imposes strict limits on the reusability of objects. In this respect, although both standards refer to objects, there are significant differences in terms of their properties with regard to reusability and portability.

What is an object?