PLC programming
The further development of IEC 61131
Today, industrial control systems are often programmed in accordance with the international standard IEC 61131-3. What are the latest developments in this area? And what do future specifications look like with regard to the realization of Industry 4.0 architectures?
The classic centralized structures of industrial automation are increasingly being replaced by decentralized sensors and actuators as a result of the implementation of digital industrial communication systems. In addition, there are a number of implementations that also distribute the control and regulation functions to different devices in order to achieve modularization of the overall system or to assemble the overall system from existing modules.
The engineering of decentralized/distributed automation systems requires an effective, standardized exchange of engineering data between software tools from different manufacturers, especially in a future Industry 4.0 environment, in order to reduce the errors caused by double and multiple entries or reprogramming and the resulting costs. This applies to tools in an identical engineering phase, for example for programming control systems and for configuring or parameterizing drives, but also between different engineering phases - for example when transferring data from production or electrical planning to control system programming.
The IEC 61131-3 standard "Programmable controllers - Part 3: Programming languages" harmonizes the way industrial controllers are viewed and handled. The 3rd edition was published in 2013 after several years of work. Important further developments of the languages were included here, such as rules for implicit data type conversions, functions for explicit data type conversions, functions for byte sequences (endian), references (but no pointer arithmetic), namespaces and abstract interfaces.
The IEC 61131-3, 3rd Edition
Figure 1: Overview of the use of the XML exchange format: Various tools generate and use XML-based IEC 61131-3 information.
© René Simon / PLCopenNew in the 3rd Edition are object-oriented language elements, which can be expected to be an essential further development in the programming of industrial control systems for selected tasks. These language elements include an extension of the classic function blocks and the introduction of the class concept. The latter includes methods, interfaces, inheritance and polymorphism.
The object-oriented language elements are particularly suitable for the development of libraries (use of inheritance) and also the modeling/specification of (external) components (use of methods, interfaces). Object-oriented language elements are currently implemented in the first development environments for industrial control systems and are available to the programmer.
Furthermore, it has been decided to remove the 'Instruction List' programming language from the standard with the future 4th edition, which is expected to be published in 2022. As a result, control programs written in Instruction List, as well as the machines and systems in which they run, will no longer correspond to the recognized state of the art from this date. The instruction list is an assembler-like programming language for which not all language constructs are available even with the 3rd edition. Companies now have around five years to make the changeover and should use this time!
With the contents of the 2nd Edition of IEC 61131-3 in 2001, an OPC UA information model was developed by a joint working group of the OPC Foundation and PLCopen and supplemented by a specification of OPC UA client function blocks for IEC 61131-3. This specification enables controller-to-controller communication with communication function blocks that represent a further development of IEC 61131-5. These include, for example, UA_Connect/UA_Disconnect, UA_Read/UA_Rreadlist, UA_Write/UA_Writelist, UA_Methodcall and UA_Browse. These communication function blocks based on the OPC Unified Architecture not only enable communication between industrial controllers from different manufacturers, but also communication initiated by the controllers to higher-level systems (e.g. MES). This creates an important interface for Industry 4.0. The aim for the future is to integrate or transfer both specifications into an IEC 61131-x standard.
A new industry standard - IEC 61131-10
The PLCopen XML specification was originally developed by the PLCopen Technical Committee 6. The rights were transferred to the IEC via the DKE, the document was revised by Ifak Magdeburg into a format specified by the IEC and a New Work Item Proposal (NWIP) was launched on this basis in January 2014. Following successful coordination, Task Force 10 (TF10) was founded within the IEC TC65/SC65B/WG7. It includes representatives from Austria, France, Japan, Germany, the Netherlands and China. German companies are disproportionately represented: Phoenix Contact Software, 3S-Smart Software Solutions and Siemens. The kick-off meeting took place in October 2014 at the DKE in Frankfurt. In addition to a detailed discussion of the comments from the national committees, it was decided that the first step would be to fully adapt the PLCopen XML schema to the 2nd edition of IEC 61131-3 and to implement the 3rd edition based on this. The International Standard IEC 61131-10 "PLCopen XML Exchange Format according to IEC 61131-3" is expected to be published in 2018.
What is it about in detail? IEC 61131-3 defines the standardized programming languages required by the user. In addition, users want to be able to exchange a complete program or parts of it between different development environments. The standard first defines program organization units; a complete program also consists of user-defined data types, global and external declarations and other elements. The term IEC 61131-3 project is used for this in IEC 61131-10. Such a 'project' contains all the language elements mentioned which are required for an exchange in order to obtain a consistent and executable unit on the target system.
The exchange of program organization units in one of the textual languages (instruction list, structured text, sequence language) is already possible to a limited extent because a syntax description of these languages is part of IEC 61131-3. The aim of IEC 61131-10 is the reuse of programmed solutions for both textual and graphical languages (ladder diagram, function block language, sequential function chart). The possible scope of exchange between the various systems depends on the supported properties, which are listed in the compliance lists required by IEC 61131-3.
For this purpose, IEC 61131-10 defines an application-independent exchange format based on the eXtensible Markup Language (XML), which is supported by the interfaces of various software tools. In addition to textual and logical information, the transfer capability of information relating to graphical representation - such as the position and size of function blocks and their connections - can be made available. The design of the transferred parts must represent the identical program logic and can be changed in appearance in a suitable manner. The exchange format is specified as an XML schema (independent file with the extension .xsd).
The IEC 61131-3 XML exchange format facilitates the life cycle management of automation systems, particularly in the case of redesigns, maintenance or device replacement. If an IEC 61131-3 project is saved as an IEC 61131-3 XML exchange file, it can be
It can be reused independently of a specific development environment and can therefore be processed in any other development environment that supports the IEC 61131-3 XML exchange format.
The aim is not only to describe correct, i.e. compilable program organization units without errors, but also to represent a working status of the IEC 61131-3 project, including the extensions for layout and formatting. Likewise, syntactically incorrect IEC 61131-3 projects can be exported, for example intermediate versions with different, unconnected blocks in function block language (unfinished program organization units).
The XML exchange format should support more than simple export/import from one development environment to another. On the other hand, all relevant information should be exported, including, for example, coordinate information for graphical tools. The importing tool should be able to filter which parts of this information are to be imported into its target environment. Manufacturer-specific information and attributes may be included in the export file and, if appropriate, imported selectively. The manufacturer-specific information must not have any influence on any logical part of the program. Furthermore, filtering should take place during import. Manufacturers must therefore ensure that their extensions to the XML schema are designed in such a way that ignoring this information during import has no effect on the functionality of the IEC 61131-3 project. Manufacturer-specific attributes and information can be made known through manufacturer-specific XML schemas.
Figure 2 shows an overview of the IEC 61131-10 schema. The basic element is 'project', which represents an IEC 61131-3 project. The element 'fileHeader' contains information about the exporting tool of the XML file, 'contentHeader' describes the content of the XML file. All type-related information, such as declarations of data types, program organization units and namespaces, can be found in the 'types'. The 'instances' element contains all instance-related information such as configurations, resources, tasks and variables. Last but not least, 'addData' enables manufacturer-specific extensions and 'documentation' enables documentation of the project.
Figure 3 shows an example of the external interface of the function block - open motion control specification. This interface comprises a series of application-specific input and output variables. Finally, the implementation of the interface of the MC_MoveAbsolute function module in an XML file in accordance with the IEC 61131-10 schema is shown in Figure 4. Some details are hidden for reasons of cost. In addition to some administrative data, the type declaration (types/pouDecl) of a function module with the name MC_MoveAbsolute can be seen. This function module includes a series of input variables (parameters/input vars) such as Execute, Position or Velocity. The Axis variable is displayed in full as an example with its complex data type AXIS_REF. In contrast to the purely graphical representation in Figure 3, which can only be interpreted by humans, this XML file can be processed automatically and error-free by computer-based tools.
In summary, it can be said that The aim of the further development of IEC 61131 is to automatically transfer information from early engineering phases (e.g. system engineering) to control programming and to transfer it to later engineering phases (e.g. documentation). However, it also makes sense to exchange information with tools for creating visualizations, configuring industrial networks or validating functions, for example. The current PLCopen specification is already implemented in a number of tools, particularly those from manufacturers in Japan and Germany. In the AutomationML environment, the exchange format has also been integrated into the engineering workflows, where it is primarily used to exchange logic information. Further development with regard to IEC 61131-10 is expected in the near future.
Author:
Prof. Dr. René Simon heads the Industrial Control Technology department at Harz University of Applied Sciences and is Chairman of the Board of PLCopen.
You might also be interested in
The first steps towards digitization
Real-time transparency in the material flow: this was the goal set by Miba when it set out to digitalize its internal logistics processes. But how successful was the close link between ERP and MES in the end? - A field report.
read more...How will the IoT change companies in 2020?
How will network technology in companies change in 2020? Axel Simon, Chief Technologist at HPE Aruba, takes a look into the crystal ball
read more...Digital twin revolutionizes maintenance
As virtual representatives of real machines, digital twins open up new possibilities for maintaining and servicing complex industrial plants and systems. A project report.
read more...You can't do without Edge and Swarm
The IoT has changed the requirements for processing data provided by machine sensors and actuators. This needs to happen as quickly as possible - preferably where the data is generated. Edge nodes and swarm computing systems take on this task.
read more...Online machine data under control
Turning huge amounts of data into valuable information - how can this smart industry approach be implemented? Linking PC-based controllers with Matlab and a cloud-based IoT analytics service can be a viable approach.
read more...From modeling directly into the PLC
Despite digitalization and I4.0, the technical functions in a process plant do not become simpler if you break them down to the smallest detail. Nevertheless, the high level of difficulty can be overcome by combining the right tools in the right way.
read more...Where are the new business models?
The necessary new business models are repeatedly cited as the hallmark of an Industry 4.0 environment. But to date, very few companies have seen any of this. Schneider Electric now has a few models up and running.
read more...Why predictive maintenance?
Investments in predictive maintenance systems are worthwhile in order to proactively detect damage. Not only does this increase the service life of a machine, it also opens up new business models for machine manufacturers.
read more...First customer projects via BaSys 4.0
The BMBF project 'Basissystem Industrie 4.0' expired at the end of June 2019. Together with NetApp and Objective Partner, Fraunhofer IESE now offers Industry 4.0 solutions with support and adaptation to customer systems on the basis of this project....
read more...