Domain Specific Views in Model-driven Embedded Systems Design in Industrial Automation Luca Ferrarini*, Alessio Dedè*, Patrick Salaün**, Tuan Dang**, G. Fogliazza *** *Dipartimento di Elettronica e Informazione Politecnico di Milano, Piazza Leonardo da Vinci, 32, 20133 Milano, Italy [email protected], [email protected] ** EDF R&D/STEP Department, 6, Quai Watier, 78403 Chatou Cedex, France, {patrick.salaun}, {tuan.dang}@edf.fr *** MCM SpA, via F. e G. Celaschi, 19, 29020 Vigolzone (PC), Italy, [email protected]

Abstract-The work presented in this paper describes the concept of Domain Specific Views (DSVs) according to which the specification of the control behavior is provided to the control developer. The basic idea is to investigate different application fields, to try to find common rules and models in different fields, and finally to build around this an automatic or semi-automatic transformation into executable code. The original idea is defined in a bigger aim that is the definition of a model oriented to the so-called “automation component”, used to standardize the design of an automation system. In the paper, the investigation is discussed for the discrete manufacturing and energy production fields, while in the main project (MEDEIA FP7-2007-211448) other fields are investigated and many languages and methodologies to develop control, diagnosis and simulation of automatic systems have been analyzed.

I.

INTRODUCTION

The level of automation in factories and plants increases steadily which results in more and more complex systems, composed of a lot of heterogeneous systems that have to work together to perform automation and control tasks [8]. Industries are facing rapidly changing demands due to new production processes, but also to the evolution of hardware and software. For these reasons the industrial automation industry is a very important sector and its innovations can be seen as the backbone for the manufacturing, the power generation and distribution industries, which employs about 45 million people in Europe [4]. The automation industry depends onto newest innovations in automation technology to maintain competitiveness opposite to low-wage countries. The field of automation technology is wide and a lot of small and medium sized enterprises offer automation equipment hardware and software solutions for diverse automation topics. In general, small and medium sized enterprises are more innovative than bigger enterprises within this sector [5]. The need of this scenario is to evolve the automation solutions in response to the rapidly changing demands due to new production processes but also to the evolution of hard and software and therefore also to their growing complexity [9]. The main design trend in automation and control systems is to put components, blocks made of hardware, software and intellectual property (like algorithms and data structures), together [10], [11]; that in turn calls for common, language independent models for representing, saving and reusing such components. Therefore, the main target of the Framework Seven project MEDEIA [3] supported by the European Commission is to radically improve the development productivity of embedded control systems for the industrial

automation sector with a powerful method to design and maintain installations with a long operational time. DSV1

DSV2

. . . DSVi

Automation Component Implementation Model (ACIM)

PSV1

PSI1

PSV2

PSI2

. . .

. . .

PSVj

PSIj

Fig. 1 MEDEIA meta-model and model-transformation architecture summary

The main idea of the proposed approach is to put a common element, the Automation Component Implementation Model (ACIM) [1], as described in Fig. 1, between the specification and implementation elements of a plant automation system as a means of bridging the gap between the different users and their special ways of specifying and implementing any solution. For the design of a plant the Automation Component (AC) provides the basis for interaction among different specification methods, which are called Domain Specific Views (DSVs): a wider description is reported in [2]. The ACIM (Automation Component Implementation Model, see Fig. 1) provides the equivalent of a translator enabling the information specified in any given DSV to be viewed and edited in any other DSV, by means of the AC. Even in the case where the DSVs specify different aspects of the plant, the ACIM will incorporate all the information as a common element. On the other side of the ACIM (see Fig. 1) it provides the possibility for the translation of the information that it stores in executable code for each particular platform. From the end users point of view there are only the different DSVs determined by the particular specification within any given domain (left side of Fig. 1). Any relevant information specified within a DSV will be transformed into the ACIM and can be changed and enriched on this basis by different DSVs. After providing all the necessary information, the DSVs are transformed into possible implementations for the specific platforms included in the system. These translations generate the Platform Specific Implementation Models (PSIM) that will be used to generate the executable implementations,

typically to generate executable code Platform Specific Implementations (PSIs). The representation of the PSIM is given by the corresponding Platform Specific View (PSV), which again may represent some existing tool interface that can also be linked to the corresponding component of the Automation Component Model (ACM). The PSV is a developer’s perspective that varies insofar as there are often several different means available to achieve a given functionality (right side of Fig. 1). This paper is organized in two parts; in the first three particular industrial domains will be presented and analyzed under a DSV point of view. The three domains are: • Manufacturing systems, • Energy production and distribution systems, and • (Service) Robotic Systems. The aim of this first part is to reports the results obtained through the analysis of the actual state for the specification of an automation system for each of the three domains considered. To facilitate the creation and description of DSVs for each considered industrial domains a template has been created. This template contains some fields that usually should be present in a general DSV description to collect expected information. It can be divided into three sections, the first of which reports the identification of the DSV, who edits the DSV and the addressee of this information. The second part describes the real content of the DSV reporting the main information. This description can be realized using spoken language or using some formalism such as a Sequential Chart, Mechanical Scheme, Gantt Chart, etc. The third and last section is used to maintain the history of the DSV during its lifetime. The main information stored in this part is the version history. The second and last part of the document presents an analysis of the commonalities among the DSVs of the three considered scenarios. The DSVs will be grouped in three groups and each of them will be mapped in a particular submodel of the ACIM with the object to obtain some rules to have the specification of the Automation Component starting from the information provided in the DSVs. II.

also a virtual image of the storage keeping the actual state of each place and tool stored. So the component has one mechanical-electrical part and a control-software part. The Tool Store has been described using 7 DSVs, each of them reports a particular description of the component. DSV.M.01 Configuration of Tool Store Controller (scheduler) and DSV.M.02 Configuration of Tool Store Controller (tool handler manager): these provide a 3D map of the tool rack, and it is used to obtained a software virtual image of the Tool Store and to configure the control for the tool handler used to move the tools. DSV.M.03 Tool Handler Kinematics Configuration: it shows technical characteristics related to the kinematics mechanism of the Tool Handle for each axis movement. This information is used to configure the CNC control for the cartesian robot used to move the tools. DSV.M.04 Tool request and choice for machining DSV.M.05 Tool moving to a destination: they describe the sequence of operations to request and obtain a particular tool from the Tool Store for the machining, or to move a tool in the Tool Store. These DSVs are described by a Sequential Chart. The information provided with these two DSVs is used for the implementation of the control of this component. DSV.M.06 Tool Store Input Output signals: this is a particular view that represents the wiring and functional description of electric devices and related connections. It could be considered as a mapping view and it is used to configure the PLC fieldbus and all PLC attached devices. DSV.M.07 Fetch a tool and bringing it to Pallet Changer as destination: it’s an example view used to better specifying the control behaviors described in the DSV.M.04 and DSV.M.05. This set of DSVs provides a description of the component, and it can be used to specify the Automation Component Tool Store Model. They provide enough information, containing behavioral and physical descriptions, for specifying al parts of this component.

MANUFACTURING SYSTEMS

In this section, two examples of the manufacturing domain will be described using DSVs. The aim is to give an overview of possible DSVs for this particular domain. The DSV examples presented are related to two components of a typical MCM manufacturing system: Tool Store and Pallet Changer. Each of these, according to the MEDEIA ontology, can be identified also as an Automation Component because they have very precise borders not only as mechanical components but also in terms of automation and their role in the machine environment. A. Tool Store The Tool Store is a particular component present in a machining center. This is used to store tools used for the machining. It is made of a physical store, it is a rack with a lot of places used to keep physical tools, a transport system, usually a Cartesian robot able to move tools from and to a particular place of the rack, and a control part that provides

Fig. 2 SPI Machine. Pallet Changer (A), Tilting Table into the workarea (B) and Tool Store (C). SPI is the name of a National Research Program on Innovative Production Systems.

B. Pallet Changer Next DSVs presented in this section describe the Pallet Changer of a typical Manufacturing Machine. The Pallet Changer is an external component used to load and unload pallets (or pieces) to and from the work area of the machine. In this case the Pallet Changer is a table with

four piece spaces used to load piece into the work area of the SPI Machine (shown in Fig. 2). DSVs used to describe this component are different from those used in the previous example. In this case a functional approach has been used with the aim to obtain principally a functional decomposition of the Pallet Changer. For this component 7 DSVs are provided but each of them describes a particular part of the Pallet Changer under a control point of view, specifying the functionalities of the part and how these functionalities use those of a lower level subpart. In this case only a behavioral description is provided, so it’s not enough for defining the ACIM for the pallet changer, but it’s possible to define the ACM for this device because only the Execution System Model & mapping Model are missing. The reason of this approach is to investigate other kind of DSV specification more oriented to the control implementation. The functional decomposition of the Pallet Changer is shown in Error! Reference source not found. where each box is a subcomponent with a label name and a list of functionalities.

An ES is first described by means of mechanical diagram views including main functional characteristics.

Elementary Systems ES.1

Mechanical view

ES.2

equipment.1.1

Electrical view

…

ES..255

equipment.1.1 equipment.1.2

equipment.1.2

equipment.1.3

equipment.1.3

… Neutronic view

equipment.1.3

Fig. 4 Decomposition of process into elementary systems

The I&C part of an ES is then described in Analog (DFA) and Logic (DFL) Functional Diagram views whose description is similar to Functional Block Diagram (FBD in IEC 61131-3, see Fig. 5).

Fig. 5 Example of DFA (Analog Functional Diagram) view Fig. 3 Functional Decomposition of the Pallet Changer

III.

ENERGY PRODUCTION SYSTEMS

The second scenario used as an example in this analysis is the field of electric power generation and distribution. In this case the DSV examples are related to different I&C (Instrumentation & Control) components of power plants. Specification methods depend on the power plant technologies (fossil-fired, hydro, renewable and nuclear power plants), which have different process complexity levels According to the MEDEIA ontology, the I&C of an Elementary System (ES) of a nuclear power plant can be identified also as a set of ACs. Each ES corresponds to a subpart of a power plant process that has a precise functional boundary (see Fig. 4). This decomposition of a power plant process in many ESs (about 255 in Nuclear Power Plant) comes from a functional analysis that can be described in SADT (Structured Analysis and Design Technique) views.

The logic I&C can also be described using flowchart views in nuclear power plants or Grafcet views in hydraulic power plants. The DSVs presented for this example (see Fig. 6) can be grouped in 5 different categories, divided by their particular description: • Hierarchical functional analysis -

•

Process description -

•

DSV.E.01: SADT View DSV.E.07: UML/SysML Diagram View DSV.E.08: Textual View DSV.E.02: Mechanical Diagram View DSV.E.06: Textual View

Automation description -

DSV.E.03: Analog Functional Diagram View DSV.E.04: Logic Functional Diagram View DSV.E.05: Flowchart View DSV.E.06: Grafcet View DSV.E.07: UML/SysML Diagram View DSV.E.08: Textual View

•

Interface: operator, instrumentation (sensors, actuators…) and other functional components

•

Platform description

DSV.E.08: Textual View

-

SADT (IDEF 0) Process description Automation Functional description Behaviour description

I/O

Mechanical Diagram (P&ID)

UML, SYSML…

Internal data

Analog Functional Diagram (DFA)

Logic Functional Diagram (DFL)

T extua l Desc rip tio n (finc tio na l, no n finc tio na l, p erfo rmanc e, safety… req uire me nts)

DSV.E.09: Platform Component View DSV.E.10: I&C Architecture View

-

I/O

Fig. 6 DSVs and their inter-relationship for a power plant

This subdivision of the DSVs suggests that it’s possible to group DSVs characterized by the same focus. These particularities will be used at the end of the paper to group and map a particular DSV with a part of the ACIM. The descriptions of the DSVs for the power plant, as done for the Tool Store example of the previous section, are provided using Sequential Chart, Mechanical Scheme, Gantt Char, spoken language, etc. IV.

ROBOTIC SYSTEMS

The last considered scenario is in the field of (Service) Robotic Systems. In this case it has been analyzed a particular architecture of Robotic technology developed by Schunk, a German company. This architecture provides different intelligent mechatronical modules (called PowerCubes, see Fig. 7) which can be combined in a very flexible way to modular configurations for different automation solutions. These solutions and systems can be applied to various applications fields like: Factory Automation, Laboratory Automation, Inspection Systems, and Service Robotics. Different from Industrial Robotics (IR), the PowerCube modules can be combined very flexibly together to obtain many different configurations instead of one of the fixed configurations that the different robotics manufacturers are offering.

Fig. 7 Example of a PowerCube configuration

The DSV example for this scenario is related to a so called Robot Configurator which will be applied to modular service robotics based on the PowerCube modules. The modules of the PowerCube series provide a basis for flexible combinations of service robotics and automation. Complex systems and multiple-axis robot structures with several degrees of freedom can be combined very flexibly. The Robot Configurator is used in order to check different specifications of a service robot with different PowerCube actuators (e.g. grippers, linear and rotating axis, etc.). In order to make and describe a configuration for a specific robotic and/or automation application based on the PowerCube construction kit the following DSVs are used: • PowerCube Module Editor (DSV.R.01): is used to describe the PowerCube modules. The different actuators shall be fully describable by virtual data sheets. The virtual data sheet description covers both, the hardware and the software aspects of the PowerCube modules. It is mainly a textual editor rather than a graphical editor tool. • Robot Configurator (DSV.R.02): is used to describe an advanced service robotics or automation solution based on the PowerCube modules. This DSV offers the possibility to describe a whole robot configuration based on different actuators. The result is a virtual robot configuration. With this information it is possible to check the pay-load of the robot configuration and also the working space of the robot. It is a graphical editor tool. • Robot Simulator (DSV.R.03): is used to make a virtual reality environment of the advanced service robotics or automation solution to test/verify the system configuration. This DSV offers the possibility to simulate a virtual robot configuration. With the robot simulator is possible to make a more detailed check of the robot configuration as with DSV.R.02 Robot Configurator. It is a graphical editor tool. V.

DSVS ANALYSIS AND GROUPS DEFINITION

As seen in the previous sections, DSVs appear to be quite different. However, the DSVs presented in this document should be used to obtain some information about possible similarities among the different domains. A result is a list of groups to catalogue all possible DSVs, and to define some rule to map each DSV on one or more particular parts of the ACIM. Referring to all examples presented in the previous sections it is possible to define three typologies useful to distinguish three main groups in order to catalogue each DSV: Mechanical Specification, Electrical Specification and Control & Behavior Specification. These three groups can be used to divide the DSVs and to obtain some guidelines to map DSVs in the Automation Component, helping, in this way, the process of transformation between the particular view and the standard model proposed in the MEDEIA project. This process can

also give some idea about what is necessary to insert in the DSVs used to describe an AC. Each DSV must be grouped into at least in one of the specification groups described before. This means that a DSV could be a member of more than one of these groups. Conversely, each group can collect several DSVs, but each must collect at least one DSV, that is, no group can remain empty. A. Mechanical Specification Mechanical Specification describes the mechanical and, more generally, the physical part of a system. This specification groups together all the DSVs which contain information about the mechanical and physical configuration of the system. The most common information collected in this section could be the cinematic or dynamic descriptions of the system including constraints of the physical configuration. No behavioral or control descriptions will be inserted here, but only information regarding the physics of the system. The DSVs could collect dynamic equations, kinematic equations, CAD files or some other possible description of the mechanics of the system. B. Electrical Specification Electrical Specification describes the electrical part of a system. This specification can be given using a list of inputoutput signals, electrical schemes or some other formalism useful to describe the electrical part of a system. According to what is defined in the MEDEIA project, the choice of the formalism used is open, and each particular domain has its software and languages used to describe an electrical part of the system. Like other specifications, the electrical specification could be given in more than one DSV. C. Control & Behavior Specification Control and Behavior Specification describes the target behavior of the systems specifying all that concerns the control such as algorithms, architectures, etc. This is the main group of DSVs. Most of the AC has a part of control and behavior in the model to specify its interaction with the external world. Most of the DSVs grouped in the other two groups are also belonging to this group because most of them contains, more than pure mechanical and electrical description, also behavioral and control information. All DSVs provided for each of the example reported before can be subdivided in these three groups. VI.

DSVS MAPPING INTO THE ACIM

Each of the three groups proposed before collects one piece of the information to specify an Automation Component. Referring to the ACIM presented before it is interesting to find some idea to map the information collected in the groups into the model proposed by the MEDEIA project. The ACIM is composed by three sub-models: • Automation Component Model. This model collects all the information about the target behavior of the component. This behavior is obtained specifying the control and the diagnostics of the AC. In this sub-model stores also the data to describe the physics of the

system with the goal to have enough information to simulate the AC. • Mapping Model. Information stored in this submodel has the main aim to allow the map-ping of the control for the target behavior to the real hardware of the AC. • Execution System Model. This sub-model collects the information about the target hard-ware of the AC. This data is composed by lists of IO signals, HW configuration, drivers, etc. Each of the three sub-models refers to a particular part of the AC, and starting from the ACM, that is a platform independent specification, it’s possible to obtain a platform dependent implementation using the Mapping Model information to link the ACM with the Execution System Model. Following this idea it is possible to divide the major part of the information collected in the three groups presented before into the ACIM. Control & Behavior Specification is a collection of descriptions and information used to define the target behavior and so the control of the AC. This group contains information that will be stored into the sub-model Automation Component Model. So all the DSVs grouped in the Control & Behavior Specification provide a part of the ACM, in particular most of them are mapped with some sections of the Behaviour-Diagnostics Model. Mechanical Specification collects all the DSVs which describe the physical model of the system. These DSVs must be used to specify the Plant Model section of the sub-model ACM, where information for possible simulation of the AC is stored. Electrical Specification groups the DSVs which contain information regarding the Mapping Model and the Execution System Model. These DSVs describe for example the IO signals and lines, the protocols used, etc. This information should be used according with others to obtain a platform dependent implementation for the AC. It is clear that if a DSV can belong to more than one of the proposed groups, such a DSV can contain information useful to define more than one sub-model of the ACIM. For this reason is not simple at the moment to define a list of specific rules to map each possible DSV with a particular part of the AC, now it’s important to find some first guideline to understand how many kinds of DSV we can have, and how the information stored in them will be linked to the ACIM. Control&Behavior

ACIM AC Model Behaviour Model

Mechanical

Plant Model

Mapping Model

Electrical

Execution System Model

Fig. 8 Mapping between the DSVs information and the ACIM

Fig. 8 shows the presented mapping idea; each group of DSVs is linked to the parts of the ACIM where the information specified by the DSVs is stored. The Control & Behavior Specification and Electrical Specification are linked to the Mapping Model of the ACIM with dotted arrows because these two groups contain DSVs useful also to map the platform independent part with the platform dependent part of the ACIM, but usually these DSVs are not specified for this particular aim. An example of this could be the list of I/O signals. VII. CONCLUSION In the paper, the basic results of an analysis on domain specific views used to edit the specification of control behavior, mechanical and electrical structure in different fields have been reported and discussed. The analysis from discrete manufacturing domain, including robotics, and energy domain shows that there are some strong similarities that should be suitably exploited in the definition of a fundamental module, the automation component, and of (semi) automatic transformation rules of Domain Specific Views into ACIM. The next step will be to define specific rules to map the information contained in each group of DSVs into a particular part of the ACIM, reaching in this way one of the objectives of MEDEIA: to define a standard model starting from non standard descriptions given by a collection of DSVs. Such an approach, innovative with respect to the everyday industrial practice and also from a scientific perspective, in MEDEIA will allow the automation industry to leverage challenges in engineering complex automation systems that require flexibilities and long lifespan cycles. ACKNOWLEDGMENT This work was supported by the MEDEIA Consortium within the MEDEIA EU project (FP7-ICT-2007-1-211448), and, in particular, by MCM S.p.A., providing the DSVs for Machining Systems, EDF, providing the DSVs for Energy Production Systems, and Schunk, providing the DSVs for Robotic Systems. REFERENCES [1]

The MEDEIA Consortium, Project Deliverable 3.3, “Overall MEDEIA Architecture Model Definition”, 2009. [2] The MEDEIA Consortium, Project Deliverable 3.1, “Domain Specific Views, overview & excerpt of key methodology”, 2009. [3] The MEDEIA Consortium web site, www.medeia.eu, 2008. [4] The agile, wireless manufacturing plant, IST – FP7 Workshop Programme, Consultation “ICT for Manufacturing” WS3, 2005. [5] Länderinformation Ungarn, intec.net, 2004. Retrieved July 28, 2005, http://www.inteconline.net/fileadmin/contentpool/laenderinformationen /Ungarn_Laenderinformation.pdf [7] The MEDEIA Consortium, “Annex I - Description of Work”, 2007. [8] ARTIST2, Roadmap on Real-Time Techniques in Control System Implementation – Control for Embedded Systems Cluster, EU/IST FP6 Artist2 NoE, www.artist-embedded.org, 2006. [9] Artemis Strategic Research Agenda, 2005. [10] T. Tommila, et al., Next generation of industrial automation – Concepts and architecture of a component-based control system, VTT Research Notes 2303, 2005. [11] D. Woll, Setting the Stage for the Next Generation of Automation Control System Software: IEC 61499, ARC Advisory Group – Industry Trends, 2007.