First Workshop on Industrial Automation Tool Integration for Engineering Project Automation Tools Integration through a Central Model and Automatic Generation of Multi- Platform Control Code Marco Colla Tiziano Leidi SUPSI - University of Applied Sciences of SUPSI - University of Applied Sciences of Southern Switzerland Southern Switzerland CH-6928 Manno, Switzerland CH-6928 Manno, Switzerland marco.colla@supsi.ch tiziano.leidi@supsi.ch Abstract On the other side, the growing number of sensing and acting points of a mechanical device or plant, and the The increasing complexity of automation systems and increasing complexity of the related functionality the great variety of platforms and languages favor an aggravate the task of the control engineer. abstract approach to the design of control applications, In order to reduce the hurdles and risks of which should also integrate mechanical, electrical and implementing a control solution by manually writing process information. A European project tackled this code, various design approaches and tools can be used to problem, and for achieving the goal of integrating tackle the control problem at a more abstract level. engineering activities and tools proposed a link between On the previous themes, a survey and analysis of the design and implementation phases by using a model- current practices and needs has been performed by the based repository, supported by automatic generation of authors [4] on a limited number of industrial enterprises control code for various environments. This paper of different size and from various sectors. It showed that focuses on some project results particularly regarding the step from the design specification to platform the generation of multi-platform control code. specific implementations of control applications is often Even if the project outcome has confirmed the done by hand, and rules for doing such conversion are feasibility of the proposed approach and generated code seldom codified, often relying on the programmer’s skill. has been successfully used by project partners, some To overcome this situation, the European project research questions are still worth to be investigated. MEDEIA [5], Model driven Embedded systems Design Environment for the Industrial Automation sector, was conceived and led by the Austrian company Profactor 1. Introduction GmbH with support of eight partners. The automatic linking of design and implementation phases through a In the industrial automation field, control applications central model-based repository supporting, by contrast to can be run on various hardware platforms, from classical comparable approaches, various tools, methods and Programmable Logic Controllers (PLC) with a closed languages was the main goal. architecture to open Programmable Automation The automatic generation of the control code out of Controllers (PAC), from ad-hoc developed embedded the information contained in the repository is necessary systems to standard PC hardware architectures down to to achieve this goal. Several hardware platforms and Field Programmable Gate Arrays (FPGA). The number programming languages have been considered, and a of programming languages is accordingly wide; the number of transformations have been implemented authors grouped them into three main categories: according to the industrial partners’ needs. − industrial automation specific languages, like the This paper reports some information and results from ones standardized in the IEC 61131-3 norm [1] such experimental development, particularly regarding or the Function Block based IEC 61499 [2] control code generation out of a central model-based − generic computer programming languages, repository. Section 2 introduces more details about some either procedural (C) or object-oriented (Java) project objectives, while section 3 analyzes other − hardware description languages, e.g. Very High approaches from the industry and research domains. Speed Integrated Circuit (VHSIC) Hardware Section 4 details the code generation process adopted by Description Language (VHDL) [3]. the project, section 5 introduce considered languages and In consequence, the implementation of the control platforms, and section 6 ends up the paper resuming solution for a given problem, and the required skills, conclusions and further research issues. greatly varies depending on the chosen hardware, run- time environment and programming language. 1 First Workshop on Industrial Automation Tool Integration for Engineering Project Automation 2. MEDEIA integration approach Engineering of industrial automation systems requires knowledge from and information transfer among different scientific disciplines. Moreover different application fields adopt various design methods and approaches, while solutions based on heterogeneous hardware and software platforms aggravate the implementation of control applications. To overcome these hurdles, specification of systems and of their functionality should be done at a high level of abstraction, different design techniques should be applicable, and the integration of these data and the implementation on different platforms Figure 2. MEDEIA framework. using various languages should be automatic [6]. The MEDEIA project set various goals, covering also An Engineering and Configuration Environment diagnostic, simulation and verification aspects. In this (MECE) coordinates the previously listed applications. presentation we introduce the ones that support the The MECE is based on the open source Eclipse [7] bidirectional flows depicted in Fig. 1, which shows some project and on various plug-ins extensions. This choice considered design techniques on the left and some has been motivated by the diffusion of this environment, implementation languages on the right, namely: by the growing number of projects and plug-ins that − a formal framework for model-driven component- allow an easy integration of ready-to-use functionalities, based development of control applications and last but not least because it is open and free. − a modeling approach that considers design methods and tools currently used by experts from 2.2. Central data repository different domains The information in the central repository is organized − automatic platform specific code generation. using various meta-models. At the basis of the architecture is the Automation Component (AC) meta- model, which represents the control functionality [6]. In the MEDEIA context, a component is similar to an integrated circuit (IC) in the electronic domain. The description of an AC is made up of its interface to other components or the physical environment through custom Figure 1. MEDEIA approach. and plant ports, and of its internal, hidden contents and behavior. The behavior of basic components can be 2.1. Formal framework described e.g. using timed state charts, while bigger The main objective of MEDEIA was the development components and whole applications can be created by of a formal framework for integrating the various hierarchical composition, as shown in Fig. 3. heterogeneous design and implementation models and tools existing in the industrial automation field. For this reason the environment depicted in Fig. 2, named Design and Engineering Framework (MDEF), has been defined. It consists of a project manager and various model editors, transformers, simulators, verifiers and code generators that access a central data repository through a service manager. The whole framework integrates various software applications, some already existing on the market and others developed ad hoc. MEDEIA supports the usage of already existing formal description methods through automatic model transformations to and from the central repository. Figure 3. AC concept. Moreover MEDEIA developed a set of code generators that navigate the information contained in the central Components can produce and consume events and repository and automatically generate the artifacts for the data, contributing to build an event-driven architecture, chosen platform and programming language. This way, and their instances can be connected together using port systems from different vendors and various languages can connections to form bigger ones. A flow-based paradigm be supported inside a single company or application, and is hence used: black boxes (ACs) build networks for existing applications can be reused after platform changes. exchanging information through connections. 2 First Workshop on Industrial Automation Tool Integration for Engineering Project Automation This way the control designer can focus on the this respect, AutomationML precisely focuses on functional properties of the single components Sequential Function Charts (SFC) and adopts the independently from the chosen technical architecture. PLCopen XML data format [18], whose purpose is to Other meta-models allow describing the real allow the exchange of programs among tools from hardware of a specific implementation, and how the different vendors. As a direct consequence, IML is components instances inside an application map to the comparable to SFC, and the transformation between the various physical devices and I/Os. Further meta-models two formats is straightforward. cover diagnostic information for failure detection, To terminate this partial review of comparable identification and handling, and the description of the initiatives it is worthwhile to cite Simulink [19] that, plant architecture for simulation purposes, while starting from Simulink models, Stateflow charts [20], or mechanical and electrical aspects can be added too. Embedded MATLAB functions [21], can generate code for different platforms and languages. A wide family of 3. Comparable initiatives Coder products permits to create C, C++, VHDL and even IEC 61131-3 Structured Text supporting PLCopen In the industrial automation field many research XML as also many other vendor specific data formats. activities have been already undertaken or are currently Aside this commercial product, which supports running, e.g. the CESAR project [8], with goals similar different implementation platforms and languages to MEDEIA. Some commercial products on the market starting from an own model based approach, the other also present some similarities. Nevertheless, generally activities previously presented mainly focus on one they focus either on the design or on the implementation single specific language. Also for the modeling phase a side, and consequently adopt different solutions for the single method or formalism is usually supported, except data repository and the code generation process. in case of AutomationML. As a consequence, the At the University of Patras, Greece, the Software intermediate model between the modeling and the Engineering Group led by Prof. Thramboulidis [9] is implementation levels usually can be similar to the one active since more than ten years on various aspects of the destination language. A transformation of models regarding the model-driven development of component- is then sufficient to accomplish the step towards the based mechatronic systems, particularly focusing on implementation, and a real code generation is not UML [10] and SysML [11] for the design, and on the required. By contrast MEDEIA supports various IEC 61499 standard as implementation platform [2]. methods, formalisms and languages for both the A similar effort, oriented this time towards the modeling and implementation phases. As a consequence, integration of UML with the IEC 61131-3 standard, has the difference between the central component-based been particularly pursued by Witch and Vogel-Heuser model and a given implementation language can be [12], leading to the new object oriented 61131-3 version. large, due to the many-to-many relationship between the The Department of Automatic Control and Systems modeling and implementation environments. Engineering at the University of the Basque Country, Bilbao, Spain, also fosters since many years a 4. MEDEIA code generation process component-based approach for implementing industrial control systems [13]. They developed a markup language Even if the MEDEIA approach turns round the for industrial control systems called icsML whose concept of the Automation Component, the AC meta- software architecture closely follows the model of IEC model is just one of the meta-models used in the 61131-3. This way the data transformation from icsML MEDEIA repository for organizing information. to the IEC 61131-3 platform is straightforward and can For automatically generating code such meta-models be accomplished through eXtensible Markup Language must be navigated and information must be collected, XML [14] based technologies like the eXtensible grouped, integrated with further constructs or modified Stylesheet Language Transformation XSLT [15]. accordingly to the selected platform and language. The At the industrial level, the AutomationML navigation of different models by the code generators organization [16], founded by four leading industries in would be particularly difficult and heavy indeed. the automation field, promotes a free, open and XML Moreover in the various meta-models the same concept, based intermediate data format. The goal is to permit the e.g. the internal behavior of a component, can be data exchange and synchronization among existing tools described with different methods. If code generators for all phases of plant engineering, covering plant would directly access such different ways of information topology, geometry, kinematics, motion planning and representation, then their implementation should cover a control behavior [17]. Regarding the logic description, matrix of N description methods and M specific AutomationML introduces an Intermediate Modeling platforms. For this reason an additional internal model, Layer (IML) for enabling a two step data translation called Platform Oriented Merged Automation from various inputs, like e.g. Gantt charts or Impulse Component Model (POMAC) has been introduced for diagrams, to languages specific to PLC platforms. With concentrating the necessary information, reducing the 3 First Workshop on Industrial Automation Tool Integration for Engineering Project Automation complexity and increasing the efficiency of the code already exists, e.g. in library, in order to convert the generation process. neutral POMAC definition avoiding to generate code. Timer components are an example of application of 4.1. Intermediate meta-model aliases: one defines language independent timer The POMAC can be seen as an intermediate layer that functionality in the model, and then specifies aliases for links the bigger and numerous MEDEIA central meta- e.g. IEC 61131-3 and IEC 61499 implementations. models to the various code output formats. Various The distribution category contains the configuration characteristics and sometimes diverging peculiarities of of an execution system made of applications, hardware the selected platforms have been considered, and the devices types and instances, I/Os, tasks running on the information inside the POMAC model has been devices, network connections, and the mapping of consequently structured for allowing the various code application elements on the physical and logical ones. generators to adequately convert it. Also the naming of The last category, documentation, contains the the single model elements was chosen in order to be information for specifying non functional properties like neutral to the various platforms terms, which sometimes e.g. external behaviour of component interfaces identify different concepts with the same name. An ad (transaction sequence, timing, quality of service ...). hoc model transformer selects, merges and unifies just XMI (XML Metadata Interchange) format [22] has the necessary information that is contained in the various been used for storing the metadata information of the models, particularly in the AC, Mapping and Execution POMAC. Interchangeable code generators, as also System ones, and put it in the POMAC. The resulting additional graphical and textual editors for direct information flow is shown in Fig. 4. information editing, have been then developed and integrated inside the MDEF environment. 4.2. Code generation technique For flexibly driving the transformations and for supporting the management of automatic operations related to generation (e.g. creation of projects and files) a generation engine approach has been implemented. This choice is due to the complex kind of the needed transformations, which include nonlinear generation phases where model objects are related to resulting artifacts in a many to many relationship. This approach was also well suited for handling the large amount of variability when generating source code for computer programming languages like C. The generation engine is supported by the JET (Java Emitter Template) language [23] contained in the EMF (Eclipse Modeling Figure 4. Code generation flow. Framework) [24] plug-in of the Eclipse development environment. JET uses a subset of the JSP (Java Server The POMAC consists of elements, their properties, Pages) syntax [25] for creating template implementation relationships and rules used for automatic validation of classes, in this case Java classes. Such classes have been the models. The meta-information inside can be grouped used for generating small pieces of code made of static in the following main categories: parts, written in the same way they have to be − Event, Variables and Complex elements as a reproduced, and dynamic ones generated using Java combination of events and variables code, embedded in the JET template, which queries the − Components model. This way the generator engines are made of Java − Component Aliases files, written by hand or built through templates without − Component, Parameter and Plant Links for using complicated scripting languages, which query the connecting the components interfaces model, load the elements and produce the code. This − Distribution approach simplifies the navigability and maintenance of − Documentation. the code generator during refactoring phases too. The functional aspects of control applications are built around the component concept, whose internal 5. Languages and platforms behaviour is either described through state charts and actions triggered by events, or through event and data According to the interests of the project partners, the flows among contained components. following four languages have been considered for Aliases for a component and its interface elements are automatic code generation, and the related useful when on a platform a predefined implementation transformations rules have been defined: 4 First Workshop on Industrial Automation Tool Integration for Engineering Project Automation − IEC 61131-3 The code generated for actions inside basic FBs is ST. − IEC 61499 In 61499 the information about the management of a − C control application and its interfacing with the run-time − VHDL. environment, e.g. I/O mapping or timing of execution, For C and VHDL no code generators have been has to be included into the application. Hence extra written during the project due to time constraints. elements, called Service Interface Function Blocks (SIFB), are automatically generated and parameterized 5.1. IEC 61131-3 e.g. with the physical I/O addresses and the plant ports of The concept of component, either basic or composite, the components are connected to them. can be mapped to the concept of Function Block (FB) in XML is used for persistence format as defined by the IEC 61131-3. By contrast events, not present in IEC IEC standard [2], Part 2. The generated code has been 61131-3, have been converted both from the syntactic imported in two different open source runtime and semantic points of view using a BOOL type and environments, 4DIAC [29] and FBDK [30], and used for generating extra code for preserving the transient experimental validation tasks in the robotic domain. character of an event. Complex ports have been converted to structures of data. 6. Conclusions Among the five IEC 61131-3 languages, for the behavior of basic components SFC initially seemed the Industrial partners have successfully employed the ideal choice due to its graphical aspect that resembles a whole MEDEIA framework, e.g. in a manufacturing cell, state chart. Nevertheless some problems arose, due to for semi-carter production for motorbikes, composed of some limitations in the tools implementations and in the two complex machine tools, one common tool storage language itself. For these reasons SFC has been unit, two pallet changers, one robot and one conveyor discarded in favor of Structured Text (ST). belt. Code generation starting from a component-based The IEC 61131-3 language that naturally lend itself event-driven model, most control engineers were scared for expressing the behavior of composite ACs and about, demonstrated to be effective. Reusability of ACs applications was the Function Block Diagram (FBD). and time efficiency rated the highest satisfaction scores The conversion from the POMAC to FBD was (9/10). Process traceability and quality of generated code straightforward; nevertheless some differences and rated 7/10. An assessment of the methodology over ten limitations arose among the considered platforms. years estimated a benefit-cost ratio of 2.2 and a reduction Just a subset of the information in the POMAC about of work hours of about 20%. the execution system and the mapping can be used. In The transformation for different IEC 61131 platforms IEC 61131-3 the available concepts of configuration, showed that, in spite of standardization, considerable resource, task, global variable, access paths or differences exist among the various implementations, communication FBs are more restrictive, and some particularly regarding graphical languages. Often the platform implementations set further limitations. possibility of distributing applications, expressed in term Code generators for three platforms using different of number of supported configurations and resources, is persistence formats, all based on the eXtensible Markup limited. At the end, just some tools support PLCopen Language (XML) [14], have been implemented and XML, or derivatives of it, as exchange format. tested. No one of the platforms directly uses the XML format standardized by PLCopen [18]. Nevertheless, the 6.1. Further research and developments first one, logi.CAD from logi.cals [26], can convert The authors are considering if a pure component- programs to and from PLCopen XML. The second one, based model and the related composition approach is Orchestra Logic Programmaing from Sintesi [27], even appropriate versus a class-based one, or a mix of the two. if it claims to offer this conversion functionality uses a The concept of component is a highly debated one, from slightly modified version of the PLCopen format. The its formal definition of Szyperski [31] as unit of third platform, UnityPro from Schneider Electric [28], independent deployment and of third-party composition, doesn’t offer conversion support at all, and code for its to the distinction between source and binary level proprietary format is directly generated. underlined by Thramboulidis [32]. Defining a control block as a class with methods and calling them inside 5.2. IEC 61499 another block, instead of connecting the interfaces of the The IEC 61499 model is different and more formal two blocks, could offer greater design flexibility. Of than the 61131-3 one, nevertheless the concept of course this approach applies if the two blocks instances component, either basic or composite, can be mapped to cannot be distributed or deployed independently, the concept of Function Block (FB) in IEC 61499. otherwise components are more suitable. As the IEC 61499 model is event based, if the From the industrial partners, two main suggestions definition of a component doesn’t contain events default emerged after the validation phase: first of all the ones are automatically generated and connected. possibility in AC of integrating functionality from a 5 First Workshop on Industrial Automation Tool Integration for Engineering Project Automation parent. The current version of the AC meta-model lacks oriented extensions”, Proceedings of IEEE International of the inheritance concept indeed. Conference on Emerging Technologies and Factory Secondly the possibility to properly instrument Automation (ETFA ‘09), pp. 1-6, 2009. generated code in order to support e.g. application [13] E. Estévez, M. Marcos, D. Orive, “Automatic generation debug. Currently the transformation rules are of PLC automation projects from component-based documented but fixed in the generators Java source code. models”, The Int. Journal of Advanced Manufacturing The authors of the MEDEIA tool chain are now Technology, Springer London, Vol. 35, Nb. 5-6, pp. 527- evaluating the best way for further developing and 540, December 2007. exploiting the proposed approach. [14] XML: eXtensible Markup Language, http://www.w3.org/XML/. Acknowledgements [15] XSLT: eXtensible Stylesheet Language Transformation, http://www.w3.org/TR/xslt. The research leading to these results has received [16] AutomationML, http://www.automationml.org/. funding from the European Community’s Seventh [17] A. Lüder, E. Estévez, L. Hundt, M. Marcos, “Automatic Framework Programme (FP7/2007-2013) under grant transformation of logic models within engineering of o agreement n ICT 2007-211448. embedded mechatronical units”, The Int. Journal of Advanced Manufacturing Technology, Springer London, References Vol. 54, Nb. 9-12, pp. 1077-1089, June 2011. [18] PLCopen Technical Committee 6, “XML Formats for [1] International Electro-technical Commission, (IEC), IEC 61131-3”, Technical Paper, Version 2.01, 2009. “Programmable controllers - Part 3: Programming [19] Simulink: Simulation and Model Based Design, languages, International Standard IEC61131-3”, Second http://www.mathworks.com/products/simulink/. Edition 2003. [20] Stateflow: State Machines and Flowcharts, [2] International Electro-technical Commission, (IEC), http://www.mathworks.com/products/stateflow/. “Function Blocks, Part 1 – 4, International Standard [21] Using the MATLAB Function Block, IEC61499”, First Edition 2005. http://www.mathworks.com/help/toolbox/simulink/ug/f6 [3] Electronic Design Automation (EDA) Industry Working -6010.html. Groups, http://www.vhdl.org/. [22] XMI: Xml Metadata Interchange, [4] M. Colla, T. Leidi, M. Semo, “Design and http://www.omg.org/spec/XMI/. Implementation of Industrial Automation Control [23] JET: Java Emitter Template, Systems: a Survey”, Proceedings of 7th IEEE http://www.eclipse.org/modeling/m2t/?project=jet#jet. International Conference on Industrial Informatics [24] EMF: Eclipse Modelling Framework project, (INDIN ’09), pp. 570-575, 2009. http://www.eclipse.org/modeling/emf/. [5] MEDEIA: Model driven Embedded systems Design [25] JSP: JavaServer Pages Technology, Environment for the Industrial Automation sector, ICT http://www.oracle.com/technetwork/java/javaee/jsp/inde Project Nr. 211448, 7th EU FP, http://www.medeia.eu/. x.html. [6] T. Strasser, M. Rooker, I. Hegny, M. Wenger, A. Zoitl, [26] Logi.CAD automation tool from logi.cals, L. Ferrarini, A. Dedé, M. Colla, “A Research Roadmap http://www.logicals.com/products/logi.CAD/. for Model-Driven Design of Embedded Systems for [27] Orchestra Control Engine by Sintesi SpA, Automation Components”, Proceedings of 7th IEEE http://www.orchestracontrol.com/Home/tabid/36/Default International Conference on Industrial Informatics .aspx. (INDIN ’09), pp. 564-569, 2009. [28] Unity Pro from Schneider Electric, [7] The Eclipse open development platform, http://www.schneider- http://www.eclipse.org. electric.com/site/home/index.cfm/ww/. [8] CESAR: Cost-efficient methods and processes for safety [29] 4DIAC, open source for Distributed Industrial relevant embedded systems, ARTEMIS Joint Automation, http://www.fordiac.org/. Undertaking, http://www.cesarproject.eu/ . [30] FBDK, the Function Block Development Kit, [9] Prof. K. Thramboulidis, University of Patras, Greece, http://www.holobloc.com/doc/fbdk/. http://seg.ee.upatras.gr/thrambo/dev/index.htm. [31] C. Szyperski, Component Software: Beyond Object [10] UML: the Unified Modeling Language, Oriented Programming, Addison-Wesley, 2002. http://www.uml.org/#UML2.0. [32] K. Thramboulidis, “The Function Block Model in [11] SysML: the Systems Modeling Language, Embedded Control and Automation from IEC61131 to http://www.sysml.org/. IEC61499”, WSEAS Transactions on Computers, Issue 9, [12] D. Witsch, B. Vogel-Heuser, “Close integration between Volume 8, September 2009. UML and IEC 61131-3: New possibilities through object 6