(Click here to view article in digital edition)
To explain what makes this platform so flexible, we need to look back to the architecture of classic PLC systems. These are shaped by proprietary runtime systems. Based on an operating system, manufacturer-specific runtime systems run programs in real time, i.e., they perform the task of scheduling. They are also responsible for the consistent exchange of process data. The advantage of this type of system architecture is that the user does not have to deal with the operating system. If changes are made to the operating system as a result of an update, the user's application is unaffected. In fact, changes to the operating system are accommodated by corresponding adaptations that the relevant manufacturer makes to their runtime environment. However, this particular advantage of classic PLC systems has spawned certain disadvantages in the world of modern automation technology (Figure 1).
It is impossible or extremely difficult to meet the requirements of future-oriented applications using the aforementioned system architecture. Examples of this include integrating a new protocol stack such as MQTT, connecting a database or operating the Node.js platform on the controller. This is because existing libraries in the form of a DLL (Dynamic Link Library) for Windows-based systems or shared objects (.so) in Linux solutions cannot be readily integrated into a classic system. In many cases they require access to functions from the operating system API, however this is encapsulated by the runtime environment for the reasons set out above. The controller manufacturer would therefore have to have made the functions available in the runtime. In addition, the system would have to be able to integrate a DLL or a “.so”.
Approaches for optimising classic PLC systems still have drawbacks
Against this backdrop, various solutions have emerged for the classic PLC system outlined above. The simplest yet most costly approach is to leave the classic system architecture in its existing form. The user is additionally provided with a corresponding cross-compiler for the manufacturer-specific runtime environment in their engineering tools – such as Visual Studio or Eclipse. This allows them to program in high-level language and create executable code that can usually be embedded into the actual IEC 61131 program as a block. However, the disadvantage remains that the user only has access to the operating system functions that the PLC system manufacturer has made available to them in the runtime environment. Consequently, the user may have to wait for a control system update in order to implement a certain function (Figure 2).
Another alternative approach sees the user have access to completely open hardware that is usually based on a Linux or Windows operating system – essentially an industrial PC in the form factor of a controller. With this solution the user can plumb the depths of the operating system, however it is then their responsibility to handle the real-time execution of the programs and consistent data exchange between them. This is because classic PLC systems involve functions that are no longer in the scope of the supplied runtime environment. This approach therefore only supports the user to a limited extent in implementing their requirements (Figure 3).
The third concept allows the two approaches described before to be combined in a single device. Consequently, the runtime environment permits the integration of high-level language programs as blocks, but does not grant access to the operating system API. Furthermore, an open operating system – such as Windows or Linux – is provided, but is not intended to handle the processing of programs in real time. Although this solution should be able to accommodate all applications, in reality this is not the case. The third approach is also pushed to its very limits, especially if the user wants to integrate a protocol stack, which operates the operating system API and needs to be executed in real time (Figure 4).
The Execution and Synchronisation Manager
The three concepts outlined for implementing the growing demands with classic PLC systems as well as the analysis of the respective disadvantages make it clear where the actual problem lies: in the monolithic design of manufacturer-specific runtime systems. This also encompasses the Execution Layer, which provides IEC programs with specific functions for processing, as well as the scheduler, which is responsible for real-time execution, i.e., the synchronous starting of threads. Furthermore, the runtime systems include components which handle the consistent exchange of process data between programs as well as with the connected fieldbuses.
PLCnext Technology therefore integrates the three key components for the development of automation applications independently of one another in a single system. This means that the IEC runtime for processing programs, which have been written in accordance with IEC 61131-3 in the PC Worx engineering tool, is one of many programs that can be created in high-level language or Matlab Simulink. In this way, every high-level language program can use the operating system API directly and still be executed in real time. This is because scheduling is managed operating system-wide by a separate component: the Execution and Synchronisation Manager (ESM). The ESM therefore enables the operating system-wide scheduling of any program – whether generated by C++ tools, Matlab Simulink or within the runtime of proprietary IEC 61131 engineering (Figure 5).
The Global Data Space
The situation is similar for consistent data exchange between programs, tasks, and the connected fieldbuses. This function – known as Global Data Space (GDS) – is also implemented as a separate component in PLCnext Technology. The solution enables the programmer to register the relevant data in the GDS via in and out ports, so that other programs can then access the data. The Global Data Space effectively creates a shared memory that takes over many tasks from the programmer. If using the GDS, the programmer doesn't have to worry about blocking memory areas and no longer needs to incorporate their own buffer mechanisms. These are already included in the GDS component.
In addition to combining various programs from different engineering tools to create an automation application, programs can also be managed directly by the operating system without using the ESM. However, the free-running, event-driven program can access the process data of programs executed in real time by using the GDS. PLCnext Technology therefore provides maximum possible flexibility in areas where all other system architectures are stretched to their limits. Due to the myriad of constellations, a program outside the runtime environment could run a continuous video stream analysis or image analysis, for example. The captured data is forwarded to a program created in IEC 61131 using the GDS in order to control an XY positioning table.
Phoenix Contact has built an entire ecosystem around PLCnext Technology, enabling users to connect their devices easily to the cloud. This includes the AXC F 2152 controller with ARM9 dual-core processor and 800 MHz clock frequency for the medium performance range. An App Store, launched at the end of 2018, allows programmers the opportunity to sell their libraries, programs or entire applications. The open platform helps generate new business models. Furthermore, users are able to find a solution for their particular automation requirements more quickly.
For more information, visit: www.phoenixcontact.com/plcnext
Print this page | E-mail this page
Discover the future of engineering today
Download a copy of our digital magazine