- Email: [email protected]
Increasing flexibility of modular automated material flow systems: A meta model architecture
Management and Control IFAC Manufacturing IFAC Conference Conference on Manufacturing Modelling, June 28-30, 2016. on Troyes, France Modelling, IFAC Conference on Manufacturing Modelling, Management Available online at www.sciencedirect.com Management and and Control Control Management and Control June June 28-30, 28-30, 2016. 2016. Troyes, Troyes, France France June 28-30, 2016. Troyes, France
ScienceDirect
Increasing flexibility of modular automated material flow systems: IFAC-PapersOnLine 49-12 (2016) 1543–1548 modelautomated architecture Increasing flexibilityAofmeta modular material flow systems: Increasing flexibility of modular automated material flow systems: A meta model architecture Thomas Aicher*, Daniel Regulin*, Danielmodel Schütz*,architecture Christian Lieberoth-Leden**, Markus Spindler**, A meta W. A. Günthner**, Birgit Vogel-Heuser* Thomas Aicher*, Daniel Regulin*, Daniel Schütz*, Christian Lieberoth-Leden**, Markus Spindler**, Thomas Daniel Schütz*, Lieberoth-Leden**, Christian Thomas Aicher*, Aicher*, Daniel Daniel Regulin*, Regulin*, Daniel Schütz*,Birgit Christian Lieberoth-Leden**, Markus Markus Spindler**, Spindler**, W. A. A. Günthner**, Vogel-Heuser* W. Günthner**, Birgit Vogel-Heuser* W. A. Günthner**, Birgit Vogel-Heuser* *Institute of Automation and Information Systems, Technische Universität München, Germany (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). *Institute of Automation and Information Systems, Technische Universität München, Germany of and Systems, Technische Universität München, Germany ** Institute*Institute for Materials Handling, Material Flow, Logistics, Technische *Institute of Automation Automation and Information Information Systems, Technische Universität Universität München, München, Germany Germany (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). ** Institute for Materials Handling, Material Flow, Logistics, Technische Universität München, Germany ** Material Flow, Logistics, Universität ** Institute Institute for for Materials Materials Handling, Handling, Material Flow, Logistics, Technische Technische Universität München, München, Germany Germany (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) Abstract: The demand for flexibility and robustness in case of extending, reducing or modifying parts of an automated material flow system (aMFS) is increasing. Therefore the control software architecture of Abstract: The The demand demand for for flexibility flexibility and and robustness in in case case of of extending, reducing reducing or or modifying parts parts of Abstract: present aMFS to be for dynamically adaptable. Several propose reducing an encapsulation and clustering Abstract: The has demand and robustness robustness inapproaches caseTherefore of extending, extending, or modifying modifying parts of of an automated automated material flowflexibility system (aMFS) (aMFS) is increasing. increasing. the control control software software architecture of an material flow system is Therefore the architecture of of related functions to accomplish the(aMFS) changedisrequirements. Hence, a modular architecture, which enables an automated material flow system increasing. Therefore the control software architecture of present aMFS aMFS has has to to be be dynamically dynamically adaptable. adaptable. Several Several approaches approaches propose propose an an encapsulation encapsulation and and clustering clustering present changesaMFS in thehasplant design with adaptable. minimizedSeveral engineering and commissioning effort is and desired. This present dynamically approaches propose an encapsulation clustering of related related functions functionstoto tobeaccomplish accomplish the changed changed requirements. requirements. Hence, modular architecture, which which enables of the Hence, aaa standardized modular architecture, enables contribution presents aaccomplish meta model for an aMFS module including interfaceswhich that enables of related functions to the changed requirements. Hence, modular architecture, changes in in the plant plant design design with with minimized minimized engineering and and commissioning commissioning effort effort is is desired. This This changes code generation for central andwith decentral controlengineering structures ofand aMFS consisting of connected modules.This changes in the the plant engineering commissioning is desired. desired. contribution presents adesign meta model model minimized for an an aMFS aMFS module including including standardized effort interfaces that enables enables contribution presents a meta for module standardized interfaces that contribution presents a meta model for an aMFS module including standardized interfaces that enables Keywords: Automation, logistic, material flow, model driven engineering (MDE), code code generation for central and decentral structures ofHosting aMFS by consisting of connected © 2016, IFAC (International Federation of control Automatic Control) Elsevier Ltd. All generation rightsmodules. reserved. code code generation generation for for central central and and decentral decentral control control structures structures of of aMFS aMFS consisting consisting of of connected connected modules. modules. Keywords: Automation, logistic, material flow, model driven engineering (MDE), code generation Keywords: Automation, logistic, material flow, model driven engineering (MDE), code generation Keywords: Automation, logistic, material flow, model driven engineering (MDE), code generation model driven engineering (MDE), which is suggested by the 1. INTRODUCTION author as methodology based on the results. In order to realize model driven engineering (MDE), which is suggested by the model driven engineering suggested by 1. INTRODUCTION a MDE approach, which(MDE), reduceswhich the is effort in software Today’s automated production systems (aPS) and distribution model driven engineering (MDE), suggested by the the 1. INTRODUCTION author as as methodology based on the thewhich results.is In In order to to realize realize 1. INTRODUCTION author methodology based on results. order (re-)engineering of logistic modules and In modular logistic centres need to handle the raised demand of the costumers author as methodology based on the results. order to realize a MDE approach, which reduces the effort in software Today’s automated production systems (aPS) and distribution MDE effort software Today’s production systems (aPS) distribution this paper which presentsreduces a metathe model forin regardingautomated high sophisticated and individualized products. aasystems, MDE approach, approach, which reduces the effort inautomated software Today’s automated production systems (aPS)ofand and distribution (re-)engineering of logistic modules and modular logistic centres need to handle the raised demand the costumers (re-)engineering of logistic modules and modular centres need to handle the raised demand of the costumers flow modules – themodules AutoMFM. This meta logistic model Since production is becoming more demand flexible and onecostumers plant has material (re-)engineering of logistic and modular logistic centres need to handle the raised of the systems, this paper presents a meta model for automated regarding high sophisticated and individualized products. systems, this paper presents aa meta automated regarding high sophisticated and individualized products. the encapsulated description ofmodel logisticfor modules and to be able to produce a wide range of different products, the enables systems, this paper presents meta model for automated regarding high sophisticated and individualized products. material flow modules – the AutoMFM. This meta model Since production is becoming more flexible and one plant has material flow modules – the This meta model Since production is becoming one plant has their related information as wellAutoMFM. as the composition of multiple material flow within the plant,more but flexible also theand control software material flow modules – the AutoMFM. This meta model Since production is becoming more flexible and one plant has enables the the encapsulated encapsulated description description of of logistic logistic modules modules and and to be able to produce a wide range of different products, the enables to be to produce of products, the to encapsulated a system model. Therefore, due to modules the modular architecture beaa wide able range to accomplish the changing enables the logistic and to be able ableflow to must produce range of different different products, the modules their related related information as asdescription well as as the the of composition of multiple multiple material within the thewide plant, but also also the control control software their information well composition of material flow within plant, but the software approach, the re-use of as parts ofas the automation software is production environment and but thealso associated frequently their related information well the composition of multiple material flow within the plant, the control software modules to to aa system system model. model. Therefore, Therefore, due due to to the the modular modular architecture must must be be able able to to accomplish accomplish the the changing changing modules architecture enabled and the software engineering effort after rearranging changing manufacturing planning and scheduling (Dennert et modules to a system model. Therefore, due to the modular architecture environment must be ableandto the accomplish the frequently changing approach, the re-use of parts of the automation software is production associated approach, re-use of of software production environment the associated frequently the aMFS isthe al. 2013). Consequently, theand demand for a flexible automated approach, thedecreased. re-use of parts parts of the the automation automation software is is production environmentplanning and the associated frequently enabled and the software engineering effort after rearranging changing manufacturing and scheduling (Dennert et enabled and the software engineering effort after rearranging changing manufacturing planning and scheduling (Dennert et material flow system (aMFS) of aand factory or logistic centre, enabled and the software engineering effort after rearranging changing manufacturing planning scheduling (Dennert et the aMFS is decreased. al. 2013). Consequently, the demand for a flexible automated A logistic module in the sense of the presented description is aMFS al. 2013). the for automated including aConsequently, flexible adaptable control software is increasing as the the aMFS is is decreased. decreased. al. 2013).flow Consequently, the demand demand for aa flexible flexible automated material system (aMFS) of a factory or logistic centre, an encapsulated unit, which can execute one or more logistic material flow system (aMFS) of or logistic centre, A logistic module in the sense of the presented description is well. material flow system (aMFS)control of aa factory factory or is logistic centre, A logistic module in the sense of the is including a flexible adaptable software increasing as functionalities through related software functionsdescription that operate A logistic module in the sense ofexecute the presented presented description is including aa flexible adaptable control software is increasing as an encapsulated unit, which can one or more logistic including flexible adaptable control software is increasing as an encapsulated unit, which can execute one or more logistic well. the mechanical hardware and communicate with other Regarding the modification of aMFS, i.e. extending, reducing an encapsulated unit, which can execute one or more logistic well. functionalities through related software functions that operate well. related software functions that operate modules or through higher-level Consequently, these or modifying parts, focused on the software engineering at the functionalities functionalities through relatedsystems. software functions that operate the mechanical hardware and communicate with other Regarding the modification of aMFS, i.e. extending, reducing the mechanical hardware and communicate with Regarding the modification of aMFS, i.e. extending, reducing elements as well hardware as their composition are covered byother the present day, a modification reuse of control software is applied reducing through the mechanical and communicate with other Regarding the of aMFS, i.e. extending, modules or higher-level systems. Consequently, these or modifying parts, focused on the software engineering at the modules or systems. Consequently, these or modifying parts, focused the software engineering at the AutoMFM metahigher-level model. To handle the complexity of a detailed copy, paste and modify ofon existing control code involving modules or higher-level systems. Consequently, these or modifying parts, focused on the software engineering at the elements as well as their composition are covered by the present day, aa reuse of control software is applied through elements as well as their composition are covered by the present day, of applied through approach includes views: error-proneness and high effort.software One wayis minimize the module elementsdescription, asmeta wellmodel. as the their composition are different covered by the present day, and a reuse reuse of control control software is to applied through AutoMFM To handle the complexity of a detailed copy, paste modify of existing control code involving AutoMFM meta model. To handle the complexity of a detailed copy, paste and modify of existing control code involving general information, logistic functionality, module interfaces, static structure of modify an aMFSofand to reduce the effort and error- AutoMFM meta model. To handle the complexity of a detailed copy, paste and existing control code involving module description, the approach includes different views: error-proneness and high effort. One way to minimize the module description, the approach includes different views: error-proneness high One way to minimize the control information. proneness is theand setup of effort. a modular software architecture, module information description,and thestatus approach includesmodule different views: error-proneness and high effort. One way to minimize the general information, logistic functionality, interfaces, static structure of an aMFS and to reduce the effort and errorgeneral information, logistic functionality, module interfaces, static structure of an aMFS and to reduce the effort and errorwherestructure each automated material flow module (aMFM), e.g. a general information, logistic functionality, module interfaces, static of an aMFS and to reduce the effort and errorcontrol information and status proneness is the setup of aa modular software architecture, The remainder of this organized as follows: In the information andpaper status isinformation. information. proneness is the setup of software architecture, conveyor belt including peripheral sensors and actuators or a control information information.addressed by the proneness isautomated the setup material of a modular modular software architecture, where each flow module (aMFM), e.g. aa control following section, and thestatus requirements where each automated material flow module (aMFM), e.g. remainder of this paper is organized as follows: In transverse shuttle, can execute specific tasks(aMFM), and offers thea The where each automated flow module e.g. remainder of paper is as In the the conveyor belt includingmaterial peripheral sensors and actuators or a The introduced approach the module description of aMFS are remainder of this thisfor is organized organized as follows: follows: conveyor sensors and actuators or following section, thepaper requirements addressed byIn the the possibilitybelt to including interact peripheral with neighbouring modules. Theaa The conveyor belt including peripheral sensors and actuators or following section, the requirements addressed by the transverse shuttle, can execute specific tasks and offers the specified. Subsequently, in section III, state of the art following section, for the therequirements addressed by are the transverse shuttle, can execute tasks the introduced approach approach module description description of aMFS aMFS flexibility of this architecture isspecific obtained dueand to aoffers variable transverse shuttle, can execute specific tasks and offers the introduced for the module of are possibility to interact with neighbouring modules. The technologies and approaches are evaluated against these introduced approach for the module description of aMFS are possibility neighbouring modules. The specified. Subsequently, Subsequently, in in section section III, III, state state of of the the art art assembling to of interact modules with to systems that meet the current possibility to interact with neighbouring modules. The specified. flexibility of this architecture is obtained due to aa variable requirements. Based on thisinanalysis, weIII, show our solution for Subsequently, section state of thethese art flexibility of this architecture is obtained due to variable technologies and approaches are evaluated against requirements. Since the design and the tasks of such a specified. flexibility of this architecture is obtained due to a variable technologies and approaches are evaluated against these assembling of modules to systems that meet the current the model-based module description of aMFS,against i.e. the these meta technologies and approaches are evaluated assembling of modules to systems that meet the current Based on this analysis, we show our solution for modularized aMFS can tochange frequently, the time for requirements. assembling modules systems current Based on analysis, we show solution requirements.of Since Since the design design and that the meet tasks the of such such a requirements. model AutoMFM, focused on the structure inour section IV.for A requirements. Based on this this analysis, we show our solution for requirements. the and the tasks of a the model-based module description of aMFS, i.e. the meta programming and commissioning has to be minimized. requirements. Since can the design the tasks suchfora case the model-based description of aMFS, i.e. the meta modularized aMFS aMFS change and frequently, theoftime time study based module on a logistic sequencing module shows the the model-based module description of aMFS, i.e. the meta modularized can change frequently, the for model AutoMFM, focused on the structure in section IV. A modularized canet change frequently, theadvantages time for application model AutoMFM, focused on structure section IV. A programming and commissioning has toshows be minimized. minimized. of AutoMFM as the well as thein of The survey ofaMFS Bohner al. (2010) the modelstudy AutoMFM, focused on the structure in generation section IV.the A programming and commissioning has to be case based on aa logistic sequencing module shows programming and commissioning has to be minimized. case study based on logistic sequencing module shows the IEC61131-3 compliant code, based on previous work of the regarding the engineering and commissioning time using case study based on a logistic sequencing module shows application of AutoMFM as well as the generation of The survey of Bohner et al. (2010) shows the advantages application of AutoMFM as well the of The survey Bohner (2010) shows advantages application of AutoMFM asbased wellonas asprevious the generation generation of The surveytheof of engineering Bohner et et al. al. (2010) shows the the time advantages IEC61131-3 compliant code, work of the regarding and commissioning using IEC61131-3 compliant code, based on previous work of the regarding the engineering and commissioning time using regarding© the and commissioning time using1543IEC61131-3 compliant code, based on previous work of the Copyright 2016engineering IFAC 2405-8963 © 2016, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Copyright 2016 IFAC 1543 Peer review© of International Federation of Automatic Copyright ©under 2016 responsibility IFAC 1543Control. Copyright © 2016 IFAC 1543 10.1016/j.ifacol.2016.07.799
IFAC MIM 2016 1544 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
institute, e.g. Witsch et al. (2010), using the Meta-Object Facility (MOF) in section V. We conclude with a summary of our findings and an outlook on future work.
aMFS, the code generation has to comply with the international standard IEC61131-3 (IEC 2010). 3. STATE OF THE ART
2. REQUIREMENTS In this section the requirements, which were focused by our approach, are defined. Description of the module reference architecture (R1): The standardized description of aMFM should cover the characteristics of the different disciplines, i.e. electric, mechanic, logistic, control, and enable the design of modulespecific aspects based on a generic meta model architecture. Since aMFM are characterized by a specific architecture that can differ regarding complexity and functionality, different levels of granularity of the different views on the system, are required, e.g. the interrelation of mechanical, electrical and functional descriptions, which represent the system in different levels of detail. This demand is also emphasized in the related work by Maga et al. (2011). Additionally, the presented approach should provide different operating strategies, i.e. decentralized or (partial) centralized, by the flexible assignment of module specific software functions to a flexible number of controls. Representation of logistic functionalities (R2): aMFS are characterized by a set of typical functions, e.g. conveying or buffering. Hence, the meta model of aMFM should provide the structural specifications, e.g. locating space, and functional information, e.g. the operation of crosses. These information should be achieved by the description of actuator and sensor capabilities as well as their assignment to higher level operations. Therefore, the meta model should provide the representation of logistic functionalities based on (sub)functions. Since the modules can provide different functionalities, additional logistic operations can be achieved by coupling of several modules. Consistent interface description (R3): Based on a survey from Straube et al. (2010), the participants identified module interfaces as a critical issue (38%) or high barrier (57%) within the technical realisation of aMFS. Since every interface between aMFM has to be specified, the model-based description has to support a set of standardized reference interfaces supporting the adaption to a specific module via parameters. Considering the different engineering domains included in plant manufacturing, the interface should cover the logistic functionality, mechanic hardware, e.g. the main dimensions, the software communication and the workspace of the module. Generation of module-specific software instances (R4): To apply the introduced modelling approach for aMFM, the model-based design should not only represent the engineering aspects, but also provide the specifications for the runtime execution of the model information. In order to realize the applicability, the deployment of model information to the control should be performed by code generation based on the meta object facility (MOF) standard and model to text transformation (MOFM2T). Since programmable logic controller (PLC) are mainly used for software execution of
MDE approaches and modularization are common methodologies for developing automated systems in different domains. In this section different approaches are analysed regarding the introduced requirements in order to consider existing research results for the model-based description of aMFM. Wilfried et al. (2013) emphasised the demand of reconfiguration in logistic chains, due to the adaption to changing market demands and therefore presented a configuration model for a logistic chain. However, since aMFM are a subset of the chain, the model-based design has to enable the adaptation of modules concerning the related changes by an appropriate meta model, which is not published by Wilfried et al. (R1, R4). Vogel-Heuser et al. (2015) emphasized the need of syntactical and semantic correctness of variant-rich automated production systems. Furthermore, a challenge of the evolution is the coverage of all possible solution set variants by a description or tool. In addition Maga el al. (2011) and Feldmann et al. (2012) identified different module structures in different disciplines, e.g. mechanical engineering models do not contain electrical components whereas electrical models are focused on fine- grained wiring diagrams, but describe mechanical components only coarse-grained. Hence, existing approaches cannot support the different levels of granularity (R1). Witsch and Vogel-Heuser (2011) identified appropriate modelling constructs that are able to bridge the gap between the functional programming paradigm in IEC61131-3 of automated production plants and the object-oriented approach based on the unified modelling language (UML). This approach enables the model-based development for automated production systems and the development of further model architectures or the model-based module description for aMFS presented in this paper, but does not address an appropriate description for an aMFM (R1, R3). Weyrich et al. (2012) presented a methodology for identification of modules during engineering of automated plants. The achieved information is accumulated in a knowledge base for increasing the reusability of modules in the engineering process. The interface specification or an architecture of a single module are not presented yet (R1, R3). A model-based design approach for mechatronic systems, is presented by Anacker et al. (2011). The design process uses partial models organized in a "Reconfiguration Structure Matrix" and an "Aggregation–Design Structure Matrix (DSM)". However, a structure for a specific system as well as functional aspects are not proposed (R1, R2). A further approach for generating software for serviceoriented systems (SOA) based on a meta model description is presented by Armentia et al. (2011). The contribution gives an overview about a methodology of development of SOAapplications, but does not address a specific module architecture (R1). Additionally, the application is not focused
1544
IFAC MIM 2016 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
on logistic functionalities (R2). Bonfe et al. (2005) described a methodology for designing complex systems in a modelbased way using the UML and the Systems Modeling Language (SysML). Therefore, different abstraction layers introduced by the object oriented architecture enable an iterative refinement of a module (Bassi et al. (2011)). The approach is lacking regarding the definition of a reference architecture, which can be transferred to aMFS (R1, R2). Black and Vyatkin (2010) described an agent-based design of a baggage handling system applying the IEC61499 standard. Based on function block descriptions, the decentralized system is able to run immediately without programming. However, the approach does not provide a hierarchical generalized meta model architecture, which can be used to describe different modules in the field of aMFS (R1, R2). Zhang et al. (2005) presented a representation of IEC61499 function blocks by the UML standard. As a main advantage, the tool integration for the IEC blocks arises. Additionally, Cao et al. (2011) presented a modelling approach for mechatronic systems based on SysML. The description of the modules with equations enables a simulation using appropriate solvers. However, the publication does not provide the view on logistic functionality or the definition of standardized interfaces (R2, R3). Doukas et al. (2011) presented an approach for model driven engineering based on the IEC61499 function block paradigm for a real-time Linux environment. Since the approach is focused on a framework for modelling and code generation, it does not address information, which is required for describing aMFM (R1, R2). Wehrmeister et al. (2013) presented an approach for UML based design of real-time and embedded systems for automation applications. The proposed design flow covers activities from earlier phases up to system implementation using a predefined target platform. However, the approach does not cover a specification of standardized interfaces or a meta model for aMFM (R1, R3). 4. INTRODUCTION OF THE AUTOMATED MATERIAL FLOW META MODEL (AutoMFM) This section introduces our modelling approach for aMFM focused on the structure. After giving an overview of the top level of hierarchy, a description of the contained classes is presented in the following section.
1545
AutoMFM
General description
Status description
Function description
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Module int. description
Control description
Name : String ID : Int
Name : String ID : Int
Fig. 1. Structure of AutoMFM. but also the types of supported transport unit (TU) like pallets or small boxes, the (sub-)class general description is contained in AutoMFM. Hence, the general class does not contain either variable information, e.g. the unique identifier (ID) of the current handled TU, or runtime values about the logistic or logical behaviour of the module. Instead, a general overview based on static information of the module, e.g. the main spatial dimensions or the version number, which are particularly essential during the engineering and planning, is given. Furthermore, to be able to describe the current position of movable components in the other (sub-)classes of the aMFM, a reference location containing a reference position (x, y, z) and a reference rotation (rx, ry, rz) can be specified as part of the general description. 4.3 Modelling of status description In contrast to the static information from general description, runtime values of variable attributes are essential information for the control software. Consequently, a further (sub-)class named status description is contained in AutoMFM in order to cover these aspects for the generation of module-specific software instances (R4). Hence, the class status description provides a current time and system dependent representation of the aMFM, e.g. the operating mode, i.e. automatic or manual, or further operating numbers, e.g. throughput time or the total number of operating hours (see Fig. 2). To model also time dependent orders of customers, e.g. order numbers and their corresponding ID of the TU, the (sub-)class status description contains information of the current and future orders. To represent or calculate the current values of the module, references to the mathematical equations or logical descriptions, modelled in further classes, e.g. control description or function description, are required. 4.4 Modelling of control description
4.1 Structure of AutoMFM For improving clarity and applicability of the AutoMFM, no attributes and functions to model information and behaviour respectively, are directly allocated to the class. To deal with every requirement introduced in section 2 explicitly, a separation of the module information into the (sub-)classes general description, status description, function description, module interface description and control description is provided (see Fig. 1). To facilitate traceability, each (sub)class is specified by a name and a globally unique identifier.
To deal with the requirement of module-specific generation of software instances (R4) and to support different operating strategies (R1), a description of the (sub-)class control
4.2 Modelling of general description
AutoMFM
General description
Status description
Function description
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Current orders
Future orders
Name : String ID : Int
Name : String ID : Int
Module int. description Name : String ID : Int
Control description Name : String ID : Int
Current position
Operating mode
Name : String ID : Int
Name : String ID : Int
... ...
Manual
In order to describe the basic information of the aMFM, e.g. the type of module (e.g. conveyor system or handling system), 1545
Order one Name : String ID : Int
Order one Name : String ID : Int
Coordinates Name : String ID : Int X, Y, Z : Float
Fig. 2. Structure of status description.
NameAutomatic : String ID : Int Name : String ID : Int
...
IFAC MIM 2016 1546 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
AutoMFM
AutoMFM
General description
Status description
Function description
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
I/O Mapping
Control hardware
Control function
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Inputs Name : String ID : Int Input1 : String
Platform information Name : String ID : Int
Module int. description
Control description
Name : String ID : Int
Name : String ID : Int
Global variable list
...
Name : String ID : Int
...
Enumeration
Driver Sequential
...
AutoMFM
Function description Name : String ID : Int
Logistic function
Operation
Locating space
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Buffering Conveying Name : String ID : Int
Platform information Name : String ID : Int
Material flow interface Name : String ID : Int
... ...
TU restriction Interaction
Name : String ID : Int space
Var1 : Int Var2 : Int
...
4.6 Modelling of module interface description Considering the introduced (sub-)classes control description and function description, standardized interfaces to transfer information between different, e.g. neighboring, modules are necessary to model aMFS and to generate software code (R4). Hence, to improve the consistency of the different kind of interfaces, i.e. logical interfaces, e.g. variables, or material flow interfaces, e.g. to hand over TU, a separate (sub-)class module interface description is contained in AutoMFM (R3). In addition, in order that different modules can interact with each other, they need to define a common working space called interaction space. The interaction space contains properties, e.g. the geometry and the requirement of position accuracy. The maximum size of the interaction space results either from the entire overlap or from boundaries between the working spaces of the operations from neighboring modules (see Fig. 5). 5. EVALUATION
In order to deal with the requirement of representing logistic functionalities (R2), a description of the (sub-)class function containing information of applicable logistic functionalities of the module, e.g. conveying or buffering, is contained in AutoMFM (see Fig. 4). Additionally, the material flow of the TU, e.g. the priority at crosses or between different modules, can be modelled. Hence, this (sub-)class can be used to select modules for specific tasks and define interactions between neighbouring modules. For this purpose, the logistic tasks are segmented in the three categories: material flow, handling and waiting, from which specialized functions are able to inherit properties, e.g. capacity, processing time, transport
Status description
Energy Name : String ID : Int
Control description Name : String ID : Int
restrictions, exit and more. Specialized material flow functions such as conveying, combining or separating inherit these properties and determine suitable values based on the underlying operations for these functions.
4.5 Modelling of function description
Name : String ID : Int
Control interfaces Name : String ID : Int
Module int. description Name : String ID : Int
Fig. 5. Structure of module interface description.
containing information of the software, but also of the hardware is essential. Hence, logical functions of the module written in the programming languages of the IEC61131-3, e.g. structured text or sequential function chart, but also the corresponding variables to store local function dependent information or input and output information of the function, can be modelled in the (sub-)class control description (see Fig. 3) in different levels of granularity based on including PLCopen XML in the meta model. In addition, to read sensor values and to control actuators, a mapping list of inputs and outputs to the corresponding variables, e.g. defined in the global variable list (GVL), is allocated. To deploy the logical functions on different field devices, e.g. PLC or industrial computers, further information to describe the hardware, e.g. the platform information, or to define the cycle time are necessary and can be modelled in the (sub-)classes control hardware or global information, respectively. Furthermore, mathematical or logical equations used for calculating values to represent current information of the module, which are allocated in the (sub-)class status, can be defined in the (sub-)class control description.
General description
Function description Name : String ID : Int
ID : Int Throughput: Float
Fig. 3. Structure of control description.
Name : String ID : Int
Status description Name : String ID : Int
Handshake
Struct Name : String ID : Int Name : String ID : Int Var1, Var2 : Int
Name : String ID : Intfunction Name : String ID : Int Var1, Var2 : Int
General description Name : String ID : Int
Module int. description
Control description
Name : String ID : Int
Name : String ID : Int
...
Safety function Name : String ID : Int
Contact
Disturbances
Workspace Name : String ID : Int Name : String ID : Int
Name : String ID : Int
Fig. 4. Structure of function description.
...
Messages ...
This section gives an evaluation example for modelling aMFS based on the introduced AutoMFM. Due to space limitations it is focused on describing consistent module interfaces and generation of control software. The evaluation of further aspects of the AutoMFM approach are subjected to future works and publications. In the following subsections, first, the structure and the functionality of an application example “sequencing system” will be introduced. Subsequently, section 5.2 describes the evaluation of these requirements using the presented example. 5.1 Application example sequencing system For the application example in this paper the laboratory sequencing system, which serves as a small lab size aMFS for handling small TU of different kind, is used. The sequencing system consists of two modules, a conveyor at the bottom and a crane overhead (see Fig. 6). To control both modules, a generic industrial controller, i.e. PLC, is used. Due to the functionality of the modules, the sequence of TU arriving at the conveyor from the input and are transported to the output, can be changed. Therefore, TU picked up by the vacuum gripper of the crane can be repositioned on a different place, e.g. after a TU, which arrived at the conveyor module earlier.
1546
IFAC MIM 2016 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
1547
Crane
XML
<
XML
M2M
<
Control description Name : String ID : Int
Deploying
Module int. description Name : String ID : Int
GVL Var1 : Bool
Export – MOFM2T
Separator Sensor : Bool
GVL Var1 : Bool
<
Actuator Active : Bool
Control description Name : String ID : Int
<
Module int. description Name : String ID : Int
Conveyor
FB Crane FB Actuator
GVL Var1 : Bool;
PLC PLC
Fig. 6. Illustration of the application example.
FB Conveyor FB Separator
Fig. 7. aMFM evaluation example.
As a prerequisite, both modules have to contain specified interfaces to hand over TU between these modules. In this case, these handover positions are defined at the capacitive sensors installed next to the separating device and at the output of the module conveyor. 5.2 Modelling the application example based on AutoMFM In order to evaluate the support for software engineering realized by AutoMFM, all information to generate control code in IEC61131-3, for example control functions to control the actuators, e.g. the crane, but also to read the values of sensors, e.g. the sensor installed next to the separator, are modelled for both modules separately. In addition, information not limited to one module, e.g. the GVL or the I/O mapping table, which are necessary to define global variables or the mapping between the global variables and the hardware interfaces on a PLC respectively, are modelled in both modules equally. Considering the modules crane and conveyor, the classes general description, status description and function description were developed separately in AutoMFM. However, modelling the classes module interface description and control description depend on the neighbouring modules. In this application example, the module interface description of both modules contain the specified positions next to the separator and at the output to hand over TU. In addition, the signal of both sensors installed at the specified positions to identify TU are contained in the module interface description of both modules (see Fig. 7). Hence, both modules contain the same consistent interface description, which reduce errorproneness during the handover of TU (R3). Based on the model-based description and the compatibility to MOF, the classes were translated to an eXtensible Markup Language (XML) file based on the MOFM2T specification, which contains information about the structure, parameters and the links between the modules’ classes in the model.
Subsequently, to import the control information in an industrial development environment, e.g. CODESYS, in order to compile and deploy on a PLC, a transformation of the XML code into PLCopen XML code is applied (R4). In this application, the generated PLCopen XML file contains two function blocks (FB) crane and conveyor and in addition general control information, e.g. GVL and I/O mapping table. To transfer information between the modules, a handshake data block or GVL containing variables, e.g. Var1, which are readable and writeable for all modules, is defined in the PLCopen XML file (see Fig. 7). In this example the FB Crane reads the global variable Var1, which represents the sensor value of the separator written by the FB Conveyor. Subsequently, in case a TU reached the specified position, the FB Actuator contained in the FB Crane can execute the “pick up” command (R2). To reduce the effort for developing this consistent interface in both modules manual, it was modelled in the (sub-)class module interface description to generate the required code automatically. Within the evaluation it was shown, how two modules, i.e. crane and conveyor, can communicate through a consistent interface description, which has been generated out of the model information according to the meta model AutoMFM (R3). Additionally, it has been presented that the achieved structure has been translated into IEC61131-3 compliant control code organized by FBs. The resulting PLCopen XML file could be integrated in an industrial development environment for compiling and deploying on a PLC (R4). Therefore, based on the introduced model-based module description AutoMFM, the effort for the software engineering could be reduced and the re-use of parts of the automation software could be revealed. 6. CONCLUSION AND FUTURE WORK Considering the software engineering in automated production systems, model-driven engineering approaches have revealed high advantages regarding the engineering and commissioning
1547
IFAC MIM 2016 1548 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
time. Additionally, to improve the re-use of automation software reducing effort and error-proneness in the software (re-)engineering, modular software architectures are applied. In order to apply these approaches in further domains, e.g. automated material flow systems, meta models dealing with the domain specific requirements are necessary to model these modules. This paper presented a model-based design approach for aMFS based on an introduced meta model – the AutoMFM. Hence, the definition of consistent interfaces between different modules and IEC61131-3 compliant code generation to deploy the logical functions on different field devices, e.g. PLC or industrial computers, can be applied. Using this model, it should also be possible to cover the logistic functionality of aMFS. Additionally, the concept enables centralized as well as decentralized control applications. Therefore, the effort for the software engineering could be reduced and the re-use of automation software could be improved by a model based description. The evaluation showed the application of the AutoMFM to a sequencing system, which consists of both modules a conveyor and a crane. Based on this simple application, the modelling of a sensor and actuator of the aMFM as well as the corresponding generation to IEC61131-3 compliant code has been shown. Subsequently the standardised interface definition in the AutoMFM enables the communication between sensor and actuator. The evaluation confirmed the idea of the approach to develop aMFS using MDE, while further evaluations regarding additional logistic functionalities and scalability for centralised and decentralised systems are the next steps for optimisation of the model. Future work will examine the measurement of effort, which can be reduced based on the application of AutoMFM compared to further engineering approaches applied these days. Therefore, special metrics and industrial case studies will be used. A further reduction of engineering effort could be reached by the future application of adaptable interfaces, i.e. wrappers. The concept enables the exchange of hardware parts that require a specific software with predefined interfaces. Thus, the component specific software can be adapted without impact to the surrounding system. In addition, a possibility to increase the efficiency of aMFS can be the application of multi agent systems. By an extension of the meta model of AutoMFM, it should provide the ability to integrate the facilities, which are required for a distributed multi agent system. REFERENCES Anacker, H. et al. (2011). Integrated tool-based approach for the conceptual design of advanced mechatronic systems. In: IEEE International Systems Conference, pp. 506-511. Armentia, A. et al. (2011). Achieving Reconfigurable Service Oriented Applications Using Model Driven Engineering. In: Emerging Technologies and Factory. Bassi, L. et al. (2011). A SysML-based methodology for manufacturing machinery modeling and design. In: IEEE/ASME Trans. Mechat.
Black, G., and Vyatkin, V. (2010). Intelligent componentbased automation of baggage handling systems with IEC 61499. In: IEEE Trans. Autom. Sci. Eng. Bohner, S. et al. (2010). Model-based engineering of software: Three productivity perspectives. In: IEEE Software Engineering Workshop, pp. 35-44. Bonfe, M. et al. (2005). Unified Modeling and Verification of Logic Controllers for Physical Systems. In: IEEE Conf. Decision and Contr. Cao, Y., Liu, Y., and Paredis, C. (2011). System-level model integration of design and simulation for mechatronic systems based on SysML. In: Mechatr., pp. 1063-1075. Dennert, A. et al. (2013). Advanced Concepts for Flexible Data Integration in Heterogeneous Production Environments. In: IFAC Conference on Manufacturing Modelling, Management, and Control, pp. 348-353. Feldmann, S. et al. (2012). Modularity, variant and version management in plant automation - Future challenges and state of the art. In: International Design Conference. Fischer, K. et al. (2004). Conceptual Design of an Engineering Model for Product and Plant Automation. In: H. Ehrig (Ed.), Springer, Berlin, Germany. Maga, C. R., Jazdi, N., and Göhner, P. (2011). Requirements on engineering tools for increasing reuse in industrial automation. In: Emerging Technol. and Fac. Aut. (ETFA). IEC (2010). Programmable Controllers – Part 3: Programming languages, IEC 61131-3, standard. IEEE Standard Glossary of Software Engineering Terminology (1990), IEEE Std 610.12-1990, standard.Object Management Group (OMG). (2008). MOF Model to Text Transformation Language 1.0, standard. Straube, F. et al. (2010) Agenda for Logistics Management in 2010. In BVL German Logistics Association, 2010. Doukas, G., and Thramboulidis, K. (2011). A real-time-linuxbased framework for model-driven engineering in control and automation. In: IEEE Transactions on Industrial Electronics, 58(3), 914-924. Vogel-Heuser, B. et al. (2015). Evolution of software in automated production systems Challenges and Research Directions. In: Journal of Systems and Software. Vogel-Heuser, B. et al. (2005). Automatic code generation from a UML model to IEC 61131-3 and system configuration tools. In: Int. Conf. Contr. Autom. Wehrmeister, M. et. al. (2013). Aspect-oriented model-driven engineering for embedded systems applied to automation systems. In: IEEE Trans. Industrial Informatics. Weyrich, M., and Klein, P. (2012). Assisted engineering for mechatronic manufacturing systems based on a modularization concept. In: Emerging Technol. and Fac. Aut. (ETFA). Wilfried, S. et al. (2013). Evaluation of a configuration model for the design of adaptable logistics chains in the railway vehicle manufacturing industry. In: Manuf. Modelling, Management, and Contr. Witsch, D., and Vogel-Heuser, B. Close integration between UML and IEC 61131-3: New possibilities through objectoriented extensions. In: Emerging Technol. and Fac. Aut. Zhang, W., Halang, W., and Diedrich, C. (2005). Specification of function block applications with UML. In: Conf. on Robotics and Automation, pp. 4002-4007.
1548
ScienceDirect
Increasing flexibility of modular automated material flow systems: IFAC-PapersOnLine 49-12 (2016) 1543–1548 modelautomated architecture Increasing flexibilityAofmeta modular material flow systems: Increasing flexibility of modular automated material flow systems: A meta model architecture Thomas Aicher*, Daniel Regulin*, Danielmodel Schütz*,architecture Christian Lieberoth-Leden**, Markus Spindler**, A meta W. A. Günthner**, Birgit Vogel-Heuser* Thomas Aicher*, Daniel Regulin*, Daniel Schütz*, Christian Lieberoth-Leden**, Markus Spindler**, Thomas Daniel Schütz*, Lieberoth-Leden**, Christian Thomas Aicher*, Aicher*, Daniel Daniel Regulin*, Regulin*, Daniel Schütz*,Birgit Christian Lieberoth-Leden**, Markus Markus Spindler**, Spindler**, W. A. A. Günthner**, Vogel-Heuser* W. Günthner**, Birgit Vogel-Heuser* W. A. Günthner**, Birgit Vogel-Heuser* *Institute of Automation and Information Systems, Technische Universität München, Germany (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). *Institute of Automation and Information Systems, Technische Universität München, Germany of and Systems, Technische Universität München, Germany ** Institute*Institute for Materials Handling, Material Flow, Logistics, Technische *Institute of Automation Automation and Information Information Systems, Technische Universität Universität München, München, Germany Germany (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) (e-mail: {aicher, regulin, schuetz, vogel-heuser}@ais.mw.tum.de). ** Institute for Materials Handling, Material Flow, Logistics, Technische Universität München, Germany ** Material Flow, Logistics, Universität ** Institute Institute for for Materials Materials Handling, Handling, Material Flow, Logistics, Technische Technische Universität München, München, Germany Germany (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) (e-mail: {spindler, lieberoth-leden, kontakt}@fml.mw.tum.de) Abstract: The demand for flexibility and robustness in case of extending, reducing or modifying parts of an automated material flow system (aMFS) is increasing. Therefore the control software architecture of Abstract: The The demand demand for for flexibility flexibility and and robustness in in case case of of extending, reducing reducing or or modifying parts parts of Abstract: present aMFS to be for dynamically adaptable. Several propose reducing an encapsulation and clustering Abstract: The has demand and robustness robustness inapproaches caseTherefore of extending, extending, or modifying modifying parts of of an automated automated material flowflexibility system (aMFS) (aMFS) is increasing. increasing. the control control software software architecture of an material flow system is Therefore the architecture of of related functions to accomplish the(aMFS) changedisrequirements. Hence, a modular architecture, which enables an automated material flow system increasing. Therefore the control software architecture of present aMFS aMFS has has to to be be dynamically dynamically adaptable. adaptable. Several Several approaches approaches propose propose an an encapsulation encapsulation and and clustering clustering present changesaMFS in thehasplant design with adaptable. minimizedSeveral engineering and commissioning effort is and desired. This present dynamically approaches propose an encapsulation clustering of related related functions functionstoto tobeaccomplish accomplish the changed changed requirements. requirements. Hence, modular architecture, which which enables of the Hence, aaa standardized modular architecture, enables contribution presents aaccomplish meta model for an aMFS module including interfaceswhich that enables of related functions to the changed requirements. Hence, modular architecture, changes in in the plant plant design design with with minimized minimized engineering and and commissioning commissioning effort effort is is desired. This This changes code generation for central andwith decentral controlengineering structures ofand aMFS consisting of connected modules.This changes in the the plant engineering commissioning is desired. desired. contribution presents adesign meta model model minimized for an an aMFS aMFS module including including standardized effort interfaces that enables enables contribution presents a meta for module standardized interfaces that contribution presents a meta model for an aMFS module including standardized interfaces that enables Keywords: Automation, logistic, material flow, model driven engineering (MDE), code code generation for central and decentral structures ofHosting aMFS by consisting of connected © 2016, IFAC (International Federation of control Automatic Control) Elsevier Ltd. All generation rightsmodules. reserved. code code generation generation for for central central and and decentral decentral control control structures structures of of aMFS aMFS consisting consisting of of connected connected modules. modules. Keywords: Automation, logistic, material flow, model driven engineering (MDE), code generation Keywords: Automation, logistic, material flow, model driven engineering (MDE), code generation Keywords: Automation, logistic, material flow, model driven engineering (MDE), code generation model driven engineering (MDE), which is suggested by the 1. INTRODUCTION author as methodology based on the results. In order to realize model driven engineering (MDE), which is suggested by the model driven engineering suggested by 1. INTRODUCTION a MDE approach, which(MDE), reduceswhich the is effort in software Today’s automated production systems (aPS) and distribution model driven engineering (MDE), suggested by the the 1. INTRODUCTION author as as methodology based on the thewhich results.is In In order to to realize realize 1. INTRODUCTION author methodology based on results. order (re-)engineering of logistic modules and In modular logistic centres need to handle the raised demand of the costumers author as methodology based on the results. order to realize a MDE approach, which reduces the effort in software Today’s automated production systems (aPS) and distribution MDE effort software Today’s production systems (aPS) distribution this paper which presentsreduces a metathe model forin regardingautomated high sophisticated and individualized products. aasystems, MDE approach, approach, which reduces the effort inautomated software Today’s automated production systems (aPS)ofand and distribution (re-)engineering of logistic modules and modular logistic centres need to handle the raised demand the costumers (re-)engineering of logistic modules and modular centres need to handle the raised demand of the costumers flow modules – themodules AutoMFM. This meta logistic model Since production is becoming more demand flexible and onecostumers plant has material (re-)engineering of logistic and modular logistic centres need to handle the raised of the systems, this paper presents a meta model for automated regarding high sophisticated and individualized products. systems, this paper presents aa meta automated regarding high sophisticated and individualized products. the encapsulated description ofmodel logisticfor modules and to be able to produce a wide range of different products, the enables systems, this paper presents meta model for automated regarding high sophisticated and individualized products. material flow modules – the AutoMFM. This meta model Since production is becoming more flexible and one plant has material flow modules – the This meta model Since production is becoming one plant has their related information as wellAutoMFM. as the composition of multiple material flow within the plant,more but flexible also theand control software material flow modules – the AutoMFM. This meta model Since production is becoming more flexible and one plant has enables the the encapsulated encapsulated description description of of logistic logistic modules modules and and to be able to produce a wide range of different products, the enables to be to produce of products, the to encapsulated a system model. Therefore, due to modules the modular architecture beaa wide able range to accomplish the changing enables the logistic and to be able ableflow to must produce range of different different products, the modules their related related information as asdescription well as as the the of composition of multiple multiple material within the thewide plant, but also also the control control software their information well composition of material flow within plant, but the software approach, the re-use of as parts ofas the automation software is production environment and but thealso associated frequently their related information well the composition of multiple material flow within the plant, the control software modules to to aa system system model. model. Therefore, Therefore, due due to to the the modular modular architecture must must be be able able to to accomplish accomplish the the changing changing modules architecture enabled and the software engineering effort after rearranging changing manufacturing planning and scheduling (Dennert et modules to a system model. Therefore, due to the modular architecture environment must be ableandto the accomplish the frequently changing approach, the re-use of parts of the automation software is production associated approach, re-use of of software production environment the associated frequently the aMFS isthe al. 2013). Consequently, theand demand for a flexible automated approach, thedecreased. re-use of parts parts of the the automation automation software is is production environmentplanning and the associated frequently enabled and the software engineering effort after rearranging changing manufacturing and scheduling (Dennert et enabled and the software engineering effort after rearranging changing manufacturing planning and scheduling (Dennert et material flow system (aMFS) of aand factory or logistic centre, enabled and the software engineering effort after rearranging changing manufacturing planning scheduling (Dennert et the aMFS is decreased. al. 2013). Consequently, the demand for a flexible automated A logistic module in the sense of the presented description is aMFS al. 2013). the for automated including aConsequently, flexible adaptable control software is increasing as the the aMFS is is decreased. decreased. al. 2013).flow Consequently, the demand demand for aa flexible flexible automated material system (aMFS) of a factory or logistic centre, an encapsulated unit, which can execute one or more logistic material flow system (aMFS) of or logistic centre, A logistic module in the sense of the presented description is well. material flow system (aMFS)control of aa factory factory or is logistic centre, A logistic module in the sense of the is including a flexible adaptable software increasing as functionalities through related software functionsdescription that operate A logistic module in the sense ofexecute the presented presented description is including aa flexible adaptable control software is increasing as an encapsulated unit, which can one or more logistic including flexible adaptable control software is increasing as an encapsulated unit, which can execute one or more logistic well. the mechanical hardware and communicate with other Regarding the modification of aMFS, i.e. extending, reducing an encapsulated unit, which can execute one or more logistic well. functionalities through related software functions that operate well. related software functions that operate modules or through higher-level Consequently, these or modifying parts, focused on the software engineering at the functionalities functionalities through relatedsystems. software functions that operate the mechanical hardware and communicate with other Regarding the modification of aMFS, i.e. extending, reducing the mechanical hardware and communicate with Regarding the modification of aMFS, i.e. extending, reducing elements as well hardware as their composition are covered byother the present day, a modification reuse of control software is applied reducing through the mechanical and communicate with other Regarding the of aMFS, i.e. extending, modules or higher-level systems. Consequently, these or modifying parts, focused on the software engineering at the modules or systems. Consequently, these or modifying parts, focused the software engineering at the AutoMFM metahigher-level model. To handle the complexity of a detailed copy, paste and modify ofon existing control code involving modules or higher-level systems. Consequently, these or modifying parts, focused on the software engineering at the elements as well as their composition are covered by the present day, aa reuse of control software is applied through elements as well as their composition are covered by the present day, of applied through approach includes views: error-proneness and high effort.software One wayis minimize the module elementsdescription, asmeta wellmodel. as the their composition are different covered by the present day, and a reuse reuse of control control software is to applied through AutoMFM To handle the complexity of a detailed copy, paste modify of existing control code involving AutoMFM meta model. To handle the complexity of a detailed copy, paste and modify of existing control code involving general information, logistic functionality, module interfaces, static structure of modify an aMFSofand to reduce the effort and error- AutoMFM meta model. To handle the complexity of a detailed copy, paste and existing control code involving module description, the approach includes different views: error-proneness and high effort. One way to minimize the module description, the approach includes different views: error-proneness high One way to minimize the control information. proneness is theand setup of effort. a modular software architecture, module information description,and thestatus approach includesmodule different views: error-proneness and high effort. One way to minimize the general information, logistic functionality, interfaces, static structure of an aMFS and to reduce the effort and errorgeneral information, logistic functionality, module interfaces, static structure of an aMFS and to reduce the effort and errorwherestructure each automated material flow module (aMFM), e.g. a general information, logistic functionality, module interfaces, static of an aMFS and to reduce the effort and errorcontrol information and status proneness is the setup of aa modular software architecture, The remainder of this organized as follows: In the information andpaper status isinformation. information. proneness is the setup of software architecture, conveyor belt including peripheral sensors and actuators or a control information information.addressed by the proneness isautomated the setup material of a modular modular software architecture, where each flow module (aMFM), e.g. aa control following section, and thestatus requirements where each automated material flow module (aMFM), e.g. remainder of this paper is organized as follows: In transverse shuttle, can execute specific tasks(aMFM), and offers thea The where each automated flow module e.g. remainder of paper is as In the the conveyor belt includingmaterial peripheral sensors and actuators or a The introduced approach the module description of aMFS are remainder of this thisfor is organized organized as follows: follows: conveyor sensors and actuators or following section, thepaper requirements addressed byIn the the possibilitybelt to including interact peripheral with neighbouring modules. Theaa The conveyor belt including peripheral sensors and actuators or following section, the requirements addressed by the transverse shuttle, can execute specific tasks and offers the specified. Subsequently, in section III, state of the art following section, for the therequirements addressed by are the transverse shuttle, can execute tasks the introduced approach approach module description description of aMFS aMFS flexibility of this architecture isspecific obtained dueand to aoffers variable transverse shuttle, can execute specific tasks and offers the introduced for the module of are possibility to interact with neighbouring modules. The technologies and approaches are evaluated against these introduced approach for the module description of aMFS are possibility neighbouring modules. The specified. Subsequently, Subsequently, in in section section III, III, state state of of the the art art assembling to of interact modules with to systems that meet the current possibility to interact with neighbouring modules. The specified. flexibility of this architecture is obtained due to aa variable requirements. Based on thisinanalysis, weIII, show our solution for Subsequently, section state of thethese art flexibility of this architecture is obtained due to variable technologies and approaches are evaluated against requirements. Since the design and the tasks of such a specified. flexibility of this architecture is obtained due to a variable technologies and approaches are evaluated against these assembling of modules to systems that meet the current the model-based module description of aMFS,against i.e. the these meta technologies and approaches are evaluated assembling of modules to systems that meet the current Based on this analysis, we show our solution for modularized aMFS can tochange frequently, the time for requirements. assembling modules systems current Based on analysis, we show solution requirements.of Since Since the design design and that the meet tasks the of such such a requirements. model AutoMFM, focused on the structure inour section IV.for A requirements. Based on this this analysis, we show our solution for requirements. the and the tasks of a the model-based module description of aMFS, i.e. the meta programming and commissioning has to be minimized. requirements. Since can the design the tasks suchfora case the model-based description of aMFS, i.e. the meta modularized aMFS aMFS change and frequently, theoftime time study based module on a logistic sequencing module shows the the model-based module description of aMFS, i.e. the meta modularized can change frequently, the for model AutoMFM, focused on the structure in section IV. A modularized canet change frequently, theadvantages time for application model AutoMFM, focused on structure section IV. A programming and commissioning has toshows be minimized. minimized. of AutoMFM as the well as thein of The survey ofaMFS Bohner al. (2010) the modelstudy AutoMFM, focused on the structure in generation section IV.the A programming and commissioning has to be case based on aa logistic sequencing module shows programming and commissioning has to be minimized. case study based on logistic sequencing module shows the IEC61131-3 compliant code, based on previous work of the regarding the engineering and commissioning time using case study based on a logistic sequencing module shows application of AutoMFM as well as the generation of The survey of Bohner et al. (2010) shows the advantages application of AutoMFM as well the of The survey Bohner (2010) shows advantages application of AutoMFM asbased wellonas asprevious the generation generation of The surveytheof of engineering Bohner et et al. al. (2010) shows the the time advantages IEC61131-3 compliant code, work of the regarding and commissioning using IEC61131-3 compliant code, based on previous work of the regarding the engineering and commissioning time using regarding© the and commissioning time using1543IEC61131-3 compliant code, based on previous work of the Copyright 2016engineering IFAC 2405-8963 © 2016, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Copyright 2016 IFAC 1543 Peer review© of International Federation of Automatic Copyright ©under 2016 responsibility IFAC 1543Control. Copyright © 2016 IFAC 1543 10.1016/j.ifacol.2016.07.799
IFAC MIM 2016 1544 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
institute, e.g. Witsch et al. (2010), using the Meta-Object Facility (MOF) in section V. We conclude with a summary of our findings and an outlook on future work.
aMFS, the code generation has to comply with the international standard IEC61131-3 (IEC 2010). 3. STATE OF THE ART
2. REQUIREMENTS In this section the requirements, which were focused by our approach, are defined. Description of the module reference architecture (R1): The standardized description of aMFM should cover the characteristics of the different disciplines, i.e. electric, mechanic, logistic, control, and enable the design of modulespecific aspects based on a generic meta model architecture. Since aMFM are characterized by a specific architecture that can differ regarding complexity and functionality, different levels of granularity of the different views on the system, are required, e.g. the interrelation of mechanical, electrical and functional descriptions, which represent the system in different levels of detail. This demand is also emphasized in the related work by Maga et al. (2011). Additionally, the presented approach should provide different operating strategies, i.e. decentralized or (partial) centralized, by the flexible assignment of module specific software functions to a flexible number of controls. Representation of logistic functionalities (R2): aMFS are characterized by a set of typical functions, e.g. conveying or buffering. Hence, the meta model of aMFM should provide the structural specifications, e.g. locating space, and functional information, e.g. the operation of crosses. These information should be achieved by the description of actuator and sensor capabilities as well as their assignment to higher level operations. Therefore, the meta model should provide the representation of logistic functionalities based on (sub)functions. Since the modules can provide different functionalities, additional logistic operations can be achieved by coupling of several modules. Consistent interface description (R3): Based on a survey from Straube et al. (2010), the participants identified module interfaces as a critical issue (38%) or high barrier (57%) within the technical realisation of aMFS. Since every interface between aMFM has to be specified, the model-based description has to support a set of standardized reference interfaces supporting the adaption to a specific module via parameters. Considering the different engineering domains included in plant manufacturing, the interface should cover the logistic functionality, mechanic hardware, e.g. the main dimensions, the software communication and the workspace of the module. Generation of module-specific software instances (R4): To apply the introduced modelling approach for aMFM, the model-based design should not only represent the engineering aspects, but also provide the specifications for the runtime execution of the model information. In order to realize the applicability, the deployment of model information to the control should be performed by code generation based on the meta object facility (MOF) standard and model to text transformation (MOFM2T). Since programmable logic controller (PLC) are mainly used for software execution of
MDE approaches and modularization are common methodologies for developing automated systems in different domains. In this section different approaches are analysed regarding the introduced requirements in order to consider existing research results for the model-based description of aMFM. Wilfried et al. (2013) emphasised the demand of reconfiguration in logistic chains, due to the adaption to changing market demands and therefore presented a configuration model for a logistic chain. However, since aMFM are a subset of the chain, the model-based design has to enable the adaptation of modules concerning the related changes by an appropriate meta model, which is not published by Wilfried et al. (R1, R4). Vogel-Heuser et al. (2015) emphasized the need of syntactical and semantic correctness of variant-rich automated production systems. Furthermore, a challenge of the evolution is the coverage of all possible solution set variants by a description or tool. In addition Maga el al. (2011) and Feldmann et al. (2012) identified different module structures in different disciplines, e.g. mechanical engineering models do not contain electrical components whereas electrical models are focused on fine- grained wiring diagrams, but describe mechanical components only coarse-grained. Hence, existing approaches cannot support the different levels of granularity (R1). Witsch and Vogel-Heuser (2011) identified appropriate modelling constructs that are able to bridge the gap between the functional programming paradigm in IEC61131-3 of automated production plants and the object-oriented approach based on the unified modelling language (UML). This approach enables the model-based development for automated production systems and the development of further model architectures or the model-based module description for aMFS presented in this paper, but does not address an appropriate description for an aMFM (R1, R3). Weyrich et al. (2012) presented a methodology for identification of modules during engineering of automated plants. The achieved information is accumulated in a knowledge base for increasing the reusability of modules in the engineering process. The interface specification or an architecture of a single module are not presented yet (R1, R3). A model-based design approach for mechatronic systems, is presented by Anacker et al. (2011). The design process uses partial models organized in a "Reconfiguration Structure Matrix" and an "Aggregation–Design Structure Matrix (DSM)". However, a structure for a specific system as well as functional aspects are not proposed (R1, R2). A further approach for generating software for serviceoriented systems (SOA) based on a meta model description is presented by Armentia et al. (2011). The contribution gives an overview about a methodology of development of SOAapplications, but does not address a specific module architecture (R1). Additionally, the application is not focused
1544
IFAC MIM 2016 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
on logistic functionalities (R2). Bonfe et al. (2005) described a methodology for designing complex systems in a modelbased way using the UML and the Systems Modeling Language (SysML). Therefore, different abstraction layers introduced by the object oriented architecture enable an iterative refinement of a module (Bassi et al. (2011)). The approach is lacking regarding the definition of a reference architecture, which can be transferred to aMFS (R1, R2). Black and Vyatkin (2010) described an agent-based design of a baggage handling system applying the IEC61499 standard. Based on function block descriptions, the decentralized system is able to run immediately without programming. However, the approach does not provide a hierarchical generalized meta model architecture, which can be used to describe different modules in the field of aMFS (R1, R2). Zhang et al. (2005) presented a representation of IEC61499 function blocks by the UML standard. As a main advantage, the tool integration for the IEC blocks arises. Additionally, Cao et al. (2011) presented a modelling approach for mechatronic systems based on SysML. The description of the modules with equations enables a simulation using appropriate solvers. However, the publication does not provide the view on logistic functionality or the definition of standardized interfaces (R2, R3). Doukas et al. (2011) presented an approach for model driven engineering based on the IEC61499 function block paradigm for a real-time Linux environment. Since the approach is focused on a framework for modelling and code generation, it does not address information, which is required for describing aMFM (R1, R2). Wehrmeister et al. (2013) presented an approach for UML based design of real-time and embedded systems for automation applications. The proposed design flow covers activities from earlier phases up to system implementation using a predefined target platform. However, the approach does not cover a specification of standardized interfaces or a meta model for aMFM (R1, R3). 4. INTRODUCTION OF THE AUTOMATED MATERIAL FLOW META MODEL (AutoMFM) This section introduces our modelling approach for aMFM focused on the structure. After giving an overview of the top level of hierarchy, a description of the contained classes is presented in the following section.
1545
AutoMFM
General description
Status description
Function description
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Module int. description
Control description
Name : String ID : Int
Name : String ID : Int
Fig. 1. Structure of AutoMFM. but also the types of supported transport unit (TU) like pallets or small boxes, the (sub-)class general description is contained in AutoMFM. Hence, the general class does not contain either variable information, e.g. the unique identifier (ID) of the current handled TU, or runtime values about the logistic or logical behaviour of the module. Instead, a general overview based on static information of the module, e.g. the main spatial dimensions or the version number, which are particularly essential during the engineering and planning, is given. Furthermore, to be able to describe the current position of movable components in the other (sub-)classes of the aMFM, a reference location containing a reference position (x, y, z) and a reference rotation (rx, ry, rz) can be specified as part of the general description. 4.3 Modelling of status description In contrast to the static information from general description, runtime values of variable attributes are essential information for the control software. Consequently, a further (sub-)class named status description is contained in AutoMFM in order to cover these aspects for the generation of module-specific software instances (R4). Hence, the class status description provides a current time and system dependent representation of the aMFM, e.g. the operating mode, i.e. automatic or manual, or further operating numbers, e.g. throughput time or the total number of operating hours (see Fig. 2). To model also time dependent orders of customers, e.g. order numbers and their corresponding ID of the TU, the (sub-)class status description contains information of the current and future orders. To represent or calculate the current values of the module, references to the mathematical equations or logical descriptions, modelled in further classes, e.g. control description or function description, are required. 4.4 Modelling of control description
4.1 Structure of AutoMFM For improving clarity and applicability of the AutoMFM, no attributes and functions to model information and behaviour respectively, are directly allocated to the class. To deal with every requirement introduced in section 2 explicitly, a separation of the module information into the (sub-)classes general description, status description, function description, module interface description and control description is provided (see Fig. 1). To facilitate traceability, each (sub)class is specified by a name and a globally unique identifier.
To deal with the requirement of module-specific generation of software instances (R4) and to support different operating strategies (R1), a description of the (sub-)class control
4.2 Modelling of general description
AutoMFM
General description
Status description
Function description
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Current orders
Future orders
Name : String ID : Int
Name : String ID : Int
Module int. description Name : String ID : Int
Control description Name : String ID : Int
Current position
Operating mode
Name : String ID : Int
Name : String ID : Int
... ...
Manual
In order to describe the basic information of the aMFM, e.g. the type of module (e.g. conveyor system or handling system), 1545
Order one Name : String ID : Int
Order one Name : String ID : Int
Coordinates Name : String ID : Int X, Y, Z : Float
Fig. 2. Structure of status description.
NameAutomatic : String ID : Int Name : String ID : Int
...
IFAC MIM 2016 1546 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
AutoMFM
AutoMFM
General description
Status description
Function description
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
I/O Mapping
Control hardware
Control function
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Inputs Name : String ID : Int Input1 : String
Platform information Name : String ID : Int
Module int. description
Control description
Name : String ID : Int
Name : String ID : Int
Global variable list
...
Name : String ID : Int
...
Enumeration
Driver Sequential
...
AutoMFM
Function description Name : String ID : Int
Logistic function
Operation
Locating space
Name : String ID : Int
Name : String ID : Int
Name : String ID : Int
Buffering Conveying Name : String ID : Int
Platform information Name : String ID : Int
Material flow interface Name : String ID : Int
... ...
TU restriction Interaction
Name : String ID : Int space
Var1 : Int Var2 : Int
...
4.6 Modelling of module interface description Considering the introduced (sub-)classes control description and function description, standardized interfaces to transfer information between different, e.g. neighboring, modules are necessary to model aMFS and to generate software code (R4). Hence, to improve the consistency of the different kind of interfaces, i.e. logical interfaces, e.g. variables, or material flow interfaces, e.g. to hand over TU, a separate (sub-)class module interface description is contained in AutoMFM (R3). In addition, in order that different modules can interact with each other, they need to define a common working space called interaction space. The interaction space contains properties, e.g. the geometry and the requirement of position accuracy. The maximum size of the interaction space results either from the entire overlap or from boundaries between the working spaces of the operations from neighboring modules (see Fig. 5). 5. EVALUATION
In order to deal with the requirement of representing logistic functionalities (R2), a description of the (sub-)class function containing information of applicable logistic functionalities of the module, e.g. conveying or buffering, is contained in AutoMFM (see Fig. 4). Additionally, the material flow of the TU, e.g. the priority at crosses or between different modules, can be modelled. Hence, this (sub-)class can be used to select modules for specific tasks and define interactions between neighbouring modules. For this purpose, the logistic tasks are segmented in the three categories: material flow, handling and waiting, from which specialized functions are able to inherit properties, e.g. capacity, processing time, transport
Status description
Energy Name : String ID : Int
Control description Name : String ID : Int
restrictions, exit and more. Specialized material flow functions such as conveying, combining or separating inherit these properties and determine suitable values based on the underlying operations for these functions.
4.5 Modelling of function description
Name : String ID : Int
Control interfaces Name : String ID : Int
Module int. description Name : String ID : Int
Fig. 5. Structure of module interface description.
containing information of the software, but also of the hardware is essential. Hence, logical functions of the module written in the programming languages of the IEC61131-3, e.g. structured text or sequential function chart, but also the corresponding variables to store local function dependent information or input and output information of the function, can be modelled in the (sub-)class control description (see Fig. 3) in different levels of granularity based on including PLCopen XML in the meta model. In addition, to read sensor values and to control actuators, a mapping list of inputs and outputs to the corresponding variables, e.g. defined in the global variable list (GVL), is allocated. To deploy the logical functions on different field devices, e.g. PLC or industrial computers, further information to describe the hardware, e.g. the platform information, or to define the cycle time are necessary and can be modelled in the (sub-)classes control hardware or global information, respectively. Furthermore, mathematical or logical equations used for calculating values to represent current information of the module, which are allocated in the (sub-)class status, can be defined in the (sub-)class control description.
General description
Function description Name : String ID : Int
ID : Int Throughput: Float
Fig. 3. Structure of control description.
Name : String ID : Int
Status description Name : String ID : Int
Handshake
Struct Name : String ID : Int Name : String ID : Int Var1, Var2 : Int
Name : String ID : Intfunction Name : String ID : Int Var1, Var2 : Int
General description Name : String ID : Int
Module int. description
Control description
Name : String ID : Int
Name : String ID : Int
...
Safety function Name : String ID : Int
Contact
Disturbances
Workspace Name : String ID : Int Name : String ID : Int
Name : String ID : Int
Fig. 4. Structure of function description.
...
Messages ...
This section gives an evaluation example for modelling aMFS based on the introduced AutoMFM. Due to space limitations it is focused on describing consistent module interfaces and generation of control software. The evaluation of further aspects of the AutoMFM approach are subjected to future works and publications. In the following subsections, first, the structure and the functionality of an application example “sequencing system” will be introduced. Subsequently, section 5.2 describes the evaluation of these requirements using the presented example. 5.1 Application example sequencing system For the application example in this paper the laboratory sequencing system, which serves as a small lab size aMFS for handling small TU of different kind, is used. The sequencing system consists of two modules, a conveyor at the bottom and a crane overhead (see Fig. 6). To control both modules, a generic industrial controller, i.e. PLC, is used. Due to the functionality of the modules, the sequence of TU arriving at the conveyor from the input and are transported to the output, can be changed. Therefore, TU picked up by the vacuum gripper of the crane can be repositioned on a different place, e.g. after a TU, which arrived at the conveyor module earlier.
1546
IFAC MIM 2016 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
1547
Crane
XML
<
XML
M2M
<
Control description Name : String ID : Int
Deploying
Module int. description Name : String ID : Int
GVL Var1 : Bool
Export – MOFM2T
Separator Sensor : Bool
GVL Var1 : Bool
<
Actuator Active : Bool
Control description Name : String ID : Int
<
Module int. description Name : String ID : Int
Conveyor
FB Crane FB Actuator
GVL Var1 : Bool;
PLC PLC
Fig. 6. Illustration of the application example.
FB Conveyor FB Separator
Fig. 7. aMFM evaluation example.
As a prerequisite, both modules have to contain specified interfaces to hand over TU between these modules. In this case, these handover positions are defined at the capacitive sensors installed next to the separating device and at the output of the module conveyor. 5.2 Modelling the application example based on AutoMFM In order to evaluate the support for software engineering realized by AutoMFM, all information to generate control code in IEC61131-3, for example control functions to control the actuators, e.g. the crane, but also to read the values of sensors, e.g. the sensor installed next to the separator, are modelled for both modules separately. In addition, information not limited to one module, e.g. the GVL or the I/O mapping table, which are necessary to define global variables or the mapping between the global variables and the hardware interfaces on a PLC respectively, are modelled in both modules equally. Considering the modules crane and conveyor, the classes general description, status description and function description were developed separately in AutoMFM. However, modelling the classes module interface description and control description depend on the neighbouring modules. In this application example, the module interface description of both modules contain the specified positions next to the separator and at the output to hand over TU. In addition, the signal of both sensors installed at the specified positions to identify TU are contained in the module interface description of both modules (see Fig. 7). Hence, both modules contain the same consistent interface description, which reduce errorproneness during the handover of TU (R3). Based on the model-based description and the compatibility to MOF, the classes were translated to an eXtensible Markup Language (XML) file based on the MOFM2T specification, which contains information about the structure, parameters and the links between the modules’ classes in the model.
Subsequently, to import the control information in an industrial development environment, e.g. CODESYS, in order to compile and deploy on a PLC, a transformation of the XML code into PLCopen XML code is applied (R4). In this application, the generated PLCopen XML file contains two function blocks (FB) crane and conveyor and in addition general control information, e.g. GVL and I/O mapping table. To transfer information between the modules, a handshake data block or GVL containing variables, e.g. Var1, which are readable and writeable for all modules, is defined in the PLCopen XML file (see Fig. 7). In this example the FB Crane reads the global variable Var1, which represents the sensor value of the separator written by the FB Conveyor. Subsequently, in case a TU reached the specified position, the FB Actuator contained in the FB Crane can execute the “pick up” command (R2). To reduce the effort for developing this consistent interface in both modules manual, it was modelled in the (sub-)class module interface description to generate the required code automatically. Within the evaluation it was shown, how two modules, i.e. crane and conveyor, can communicate through a consistent interface description, which has been generated out of the model information according to the meta model AutoMFM (R3). Additionally, it has been presented that the achieved structure has been translated into IEC61131-3 compliant control code organized by FBs. The resulting PLCopen XML file could be integrated in an industrial development environment for compiling and deploying on a PLC (R4). Therefore, based on the introduced model-based module description AutoMFM, the effort for the software engineering could be reduced and the re-use of parts of the automation software could be revealed. 6. CONCLUSION AND FUTURE WORK Considering the software engineering in automated production systems, model-driven engineering approaches have revealed high advantages regarding the engineering and commissioning
1547
IFAC MIM 2016 1548 June 28-30, 2016. Troyes, France
Thomas Aicher et al. / IFAC-PapersOnLine 49-12 (2016) 1543–1548
time. Additionally, to improve the re-use of automation software reducing effort and error-proneness in the software (re-)engineering, modular software architectures are applied. In order to apply these approaches in further domains, e.g. automated material flow systems, meta models dealing with the domain specific requirements are necessary to model these modules. This paper presented a model-based design approach for aMFS based on an introduced meta model – the AutoMFM. Hence, the definition of consistent interfaces between different modules and IEC61131-3 compliant code generation to deploy the logical functions on different field devices, e.g. PLC or industrial computers, can be applied. Using this model, it should also be possible to cover the logistic functionality of aMFS. Additionally, the concept enables centralized as well as decentralized control applications. Therefore, the effort for the software engineering could be reduced and the re-use of automation software could be improved by a model based description. The evaluation showed the application of the AutoMFM to a sequencing system, which consists of both modules a conveyor and a crane. Based on this simple application, the modelling of a sensor and actuator of the aMFM as well as the corresponding generation to IEC61131-3 compliant code has been shown. Subsequently the standardised interface definition in the AutoMFM enables the communication between sensor and actuator. The evaluation confirmed the idea of the approach to develop aMFS using MDE, while further evaluations regarding additional logistic functionalities and scalability for centralised and decentralised systems are the next steps for optimisation of the model. Future work will examine the measurement of effort, which can be reduced based on the application of AutoMFM compared to further engineering approaches applied these days. Therefore, special metrics and industrial case studies will be used. A further reduction of engineering effort could be reached by the future application of adaptable interfaces, i.e. wrappers. The concept enables the exchange of hardware parts that require a specific software with predefined interfaces. Thus, the component specific software can be adapted without impact to the surrounding system. In addition, a possibility to increase the efficiency of aMFS can be the application of multi agent systems. By an extension of the meta model of AutoMFM, it should provide the ability to integrate the facilities, which are required for a distributed multi agent system. REFERENCES Anacker, H. et al. (2011). Integrated tool-based approach for the conceptual design of advanced mechatronic systems. In: IEEE International Systems Conference, pp. 506-511. Armentia, A. et al. (2011). Achieving Reconfigurable Service Oriented Applications Using Model Driven Engineering. In: Emerging Technologies and Factory. Bassi, L. et al. (2011). A SysML-based methodology for manufacturing machinery modeling and design. In: IEEE/ASME Trans. Mechat.
Black, G., and Vyatkin, V. (2010). Intelligent componentbased automation of baggage handling systems with IEC 61499. In: IEEE Trans. Autom. Sci. Eng. Bohner, S. et al. (2010). Model-based engineering of software: Three productivity perspectives. In: IEEE Software Engineering Workshop, pp. 35-44. Bonfe, M. et al. (2005). Unified Modeling and Verification of Logic Controllers for Physical Systems. In: IEEE Conf. Decision and Contr. Cao, Y., Liu, Y., and Paredis, C. (2011). System-level model integration of design and simulation for mechatronic systems based on SysML. In: Mechatr., pp. 1063-1075. Dennert, A. et al. (2013). Advanced Concepts for Flexible Data Integration in Heterogeneous Production Environments. In: IFAC Conference on Manufacturing Modelling, Management, and Control, pp. 348-353. Feldmann, S. et al. (2012). Modularity, variant and version management in plant automation - Future challenges and state of the art. In: International Design Conference. Fischer, K. et al. (2004). Conceptual Design of an Engineering Model for Product and Plant Automation. In: H. Ehrig (Ed.), Springer, Berlin, Germany. Maga, C. R., Jazdi, N., and Göhner, P. (2011). Requirements on engineering tools for increasing reuse in industrial automation. In: Emerging Technol. and Fac. Aut. (ETFA). IEC (2010). Programmable Controllers – Part 3: Programming languages, IEC 61131-3, standard. IEEE Standard Glossary of Software Engineering Terminology (1990), IEEE Std 610.12-1990, standard.Object Management Group (OMG). (2008). MOF Model to Text Transformation Language 1.0, standard. Straube, F. et al. (2010) Agenda for Logistics Management in 2010. In BVL German Logistics Association, 2010. Doukas, G., and Thramboulidis, K. (2011). A real-time-linuxbased framework for model-driven engineering in control and automation. In: IEEE Transactions on Industrial Electronics, 58(3), 914-924. Vogel-Heuser, B. et al. (2015). Evolution of software in automated production systems Challenges and Research Directions. In: Journal of Systems and Software. Vogel-Heuser, B. et al. (2005). Automatic code generation from a UML model to IEC 61131-3 and system configuration tools. In: Int. Conf. Contr. Autom. Wehrmeister, M. et. al. (2013). Aspect-oriented model-driven engineering for embedded systems applied to automation systems. In: IEEE Trans. Industrial Informatics. Weyrich, M., and Klein, P. (2012). Assisted engineering for mechatronic manufacturing systems based on a modularization concept. In: Emerging Technol. and Fac. Aut. (ETFA). Wilfried, S. et al. (2013). Evaluation of a configuration model for the design of adaptable logistics chains in the railway vehicle manufacturing industry. In: Manuf. Modelling, Management, and Contr. Witsch, D., and Vogel-Heuser, B. Close integration between UML and IEC 61131-3: New possibilities through objectoriented extensions. In: Emerging Technol. and Fac. Aut. Zhang, W., Halang, W., and Diedrich, C. (2005). Specification of function block applications with UML. In: Conf. on Robotics and Automation, pp. 4002-4007.
1548