- Email: [email protected]
Model-Driven Engineering and Semantic Technologies for the Design of Cyber-Physical Systems
11th IFAC Workshop on Intelligent Manufacturing Systems The International Federation of Automatic Control May 22-24, 2013. São Paulo, Brazil
ThCT1.2
Model-Driven Engineering and Semantic Technologies for the Design of Cyber-Physical Systems S. Feldmann, S. R¨ osch, D. Sch¨ utz, B. Vogel-Heuser Institute of Automation and Information Systems, Technische Universit¨ at M¨ unchen, 85748 Garching bei M¨ unchen, Germany (e-mail: {feldmann; roesch; schuetz; vogel-heuser}@ais.mw.tum.de) Abstract: Rapid changes in product and system requirements force today’s companies to cope with unforeseen adaptations of industrial plants. To enable the implementation of intelligent, self-adapting systems, manufacturing systems must be composed to Cyber-Physical Systems (CPS) out of Cyber-Physical Modules (CPMs). However, cross-disciplinary design of CPS and the multitude of persons involved in this process increases complexity in (re-)engineering drastically. Identification and modeling of typical CPM types in a CPM library provides a first step towards enabling reuse of constructed and verified CPMs and, thus, a knowledge base making automatic composition of CPS out of CPMs possible. In this paper, a concept for retrieving existing automation software functionality from a given hardware description by means of model-driven engineering and semantic technologies is presented. Keywords: manufacturing systems, knowledge-based systems, cyber-physical systems 1. INTRODUCTION
knowledge base making automatic composition – and later self-organization – of CPS out of CPMs possible.
Recent market trends such as changes in product and system requirements during operation of industrial plants as well as changes in lot sizes up to mass customization necessitates to cope with unforeseen adaptations of the automation control software. Manufacturing systems must therefore be composed to Cyber-Physical Systems (CPS) out of Cyber-Physical Modules (CPMs) that encapsulate intelligent software components enabling the implementation of intelligent, self-adapting systems. The term CPS refers to “embedded systems, i.e. devices, buildings, means of transportation, medical devices, logistics (...) and management processes as well as internet services, which [among others] capture physical data using sensors and influence physical processes by means of actuators [and] interpret and store data as a base to interact actively or reactively with the physical and digital world (...)” (Geisberger and Broy, 2012).
In this paper, a concept for a semantic CPM library is proposed making a retrieval of corresponding software functionality possible. Therefore, an approach for integrating interdisciplinary aspects in automation software engineering through describing CPMs semantically by means of ontologies and reasoning mechanisms is presented. Based on an existing CPM’s hardware description, matching software functionalities are retrieved. Furthermore, to increase usability of the approach, a modeling approach supporting the modeling of CPMs is shown.
However, engineering of CPS is a highly cross-disciplinary field of research (Sztipanovits, 2012). Due to the participation of multiple persons and disciplines in design of CPS, e.g. mechanical engineering, electrical engineering and software engineering, challenges such as interoperability in between CPMs and their efficient design arise. One of the main challenges originates from cross-disciplinary effects: changes in a single discipline result in changes in the other disciplines causing a drastic increase of complexity in (re-)engineering of such systems. Hence, providing correct CPMs during each phase of (re-)engineering is a prerequisite in order to support the engineer. To meet this challenge, identifying and modeling of typical CPM types in a CPM library provides a first step towards enabling reuse of constructed and verified CPMs and enables a 978-3-902823-33-5/13/$20.00 © 2013 IFAC
The paper is organized as follows: In the next section, a scenario is introduced illustrating the objectives of a CPS platform as well as the use cases and requirements of a CPM library. In section 3, related work is discussed. The approach of a semantic CPM library enabling the software functionality retrieval is presented in section 4. Its applicability and the coverage of the use cases and integrity of the requirements are evaluated in section 5. The paper is summarized in section 6. 2. MOTIVATION: A CPS SCENARIO In the scenario a manufacturing system comprises a logistics system which transports objects through numerous conveyor belts and rotating switches to production units PU1 and PU2 (cf. Fig. 1). The CPM conveyor (configuration 1 ) is used to transport the objects and can be combined with further actuators and sensors such as light barriers (1 and 2), a velocity sensor (3) and a motor (4). The software component implemented for the initial configuration encapsulates two operations: moveForward() and
210
Maintenance personnel
moveBackward(). The CPMs the manufacturing system is composed of are registered in a central CPM library. During operation of the manufacturing system, jams occur more often than planned beforehand. In order to analyze the cause of these jams, the maintenance personnel downloads relevant engineering documents from a CPS platform (see Fig. 2) containing the constantly updated engineering document database of the company. Having received the data he makes a query on comparable manufacturing systems. The query finishes with the result of a noticeably higher throughput in PU1 compared to PU2; thus, the CPS platform proposes to integrate a buffer system into the manufacturing system. The buffer system shall consist of several additional conveyor belts and switches of a similar type as the ones already used in the plant. Furthermore, a conveyor containing an additional stopper (configuration 2 ) enabling to stop and continue the object throughput shall be used. To plan the integration, the engineer responsible for the changes downloads the current documents for the mechanical construction (mCAD) of the manufacturing system. He plans and models the integration of the buffer system into the mCAD model and registers the finished model into the database as a new variant. Next the electrical layout is planned. The electrical layout (eCAD) is automatically updated with the changes made in the mCAD combined with the engineering information available for the additional modules. The inputs and outputs of the new modules are highlighted to show where the hardware has to be configured anew. Suggestions for the configuration are also made according to available resources. The engineer adapts the suggestions and registers the resulting eCAD. Finally, the software has to be implemented by retrieving matching software functionality from the CPM library. In the presented conveyor example, such a CPM library must be able to identify same CPM types and hence retrieve the same software functionality (use case UC1). However, given a similar CPM structure, e.g. monostable and bistable cylinder, the same software functionality must also be retrievable (UC2). If software components are applicable for CPMs that are completely different, Production Unit 1
Buffer System
Production Unit 2
CPS Platform
Manufacturing system
Construction engineer
Engineering document database
Suppliers
Fig. 2. Interconnection between stakeholders using CPS platform their software functionality – if applicable for both – must also be retrieved (UC3). Furthermore, if more than one software component is matching for a CPM, both components must be proposed to the engineer (UC4). However, the vision of a CPS platform for the production automation domain is not yet state of the art. A semantic CPM library making the retrieval of software functionality possible is a prerequisite for such a CPS platform. Therefore, the engineer must encapsulate the CPM’s functionality in software components (requirement R1). In conveyor configuration 1, the automation software developer implements a software component containing the operations moveForward() and moveBackward(). He also models restrictions on the execution of software functionality (R2), e.g. that an object is transported forward only if present at light barrier 1. Furthermore, in order to make the software components retrievable for future applications, he describes the semantics of software functionality integrating aspects from other disciplines into the CPM (R3) thus regarding the CPM as mechatronic module. As he later wants to retrieve the software for conveyor configuration 2, the CPM’s description must be human-readable (R4), e.g. through an appropriate notation, and machine-readable (R5), e.g. in order to process the information modeled. Subsequently, inference mechanisms (R6) are being applied in order to exploit the available knowledge and identify the matching software functionality. Therefore, the given hardware description is processed and matching software functionality is retrieved. 3. RELATED WORK
2
stopper
1
In this section, related work in the fields of system modeling as well as knowledge-based systems and semantic technologies is discussed. 3.1 System modeling
3 4
Configuration 1
Configuration 2
Fig. 1. Manufacturing system with conveyor configurations 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Modeling techniques are increasingly applied for improving reuse of CPMs and for providing a common system understanding when developing software systems (Thramboulidis, 2010). Secchi et al. (2007) showed that Unified Modeling Language (UML) has proven to support engineers offering a higher usability than traditional program-
211
ming approaches (cf. requirement R4). Model-based engineering reduces effort in automation systems engineering (Obermeier et al., 2011). To provide a more holistic view on the system and to provide modeling other discipline parts (cf. R3), e.g. mechanical and electrical engineering, Systems Modeling Language (SysML) has been developed (Bassi et al., 2011; Thramboulidis and Frey, 2011). However, all these techniques currently do not provide to model the semantics of a CPM (cf. R2), neglecting “what the CPM can do” and rather modeling “what the CPM has to do” (Legat et al., 2013a). An approach proposed by Sch¨ utz et al. (2012) thus enables the modeling of preconditions and effects of a CPM’s software functionality aiming at modeling the space of action of a manufacturing system. Nevertheless, model-based engineering techniques often do not provide applying inference mechanisms (cf. R5 and R6), making the application of semantic technologies and inference mechanisms necessary. 3.2 Knowledge-based systems and semantic technologies In contrast to classical programming which requires to program knowledge explicitly and symbolically within the software code’s structure, a knowledge-based system is capable of supporting the explicit representation of knowledge and of exploiting it through appropriate reasoning mechanisms (Legat et al., 2013b). A technique that has especially been established in order to represent knowledge formally are Web Ontology Language (OWL) ontologies standardized by the World Wide Web Consortium (W3C). Using reasoning mechanisms, such ontologies can be processed automatically to infer implicitly available information from the modeled knowledge (cf. R5 and R6). Several upper ontologies aiming at describing very general concepts of a domain have been developed in manufacturing systems engineering, e.g. ADACOR (Leit˜ao and Restivo, 2006) and MASON (Lemaignan et al., 2006), which use ontologies as a common vocabulary. Nevertheless, these upper ontologies do not address the modeling of restrictions on the execution of software functionality (cf. R2). An approach to solve this challenge is OWL-S (World Wide Web Consortium (W3C), 2004) which addresses the dynamic retrieval and orchestration of encapsulated web services (cf. R1). However, OWLS proposes top-level concepts and enables a rather pure software description. Modeling the physical aspects of a manufacturing system is not part of OWL-S (cf. R3). A main field of application of ontologies are design support systems supporting the engineering in production automation domain using semantic technologies. Orozco and Lastra (2006) aim at retrieving Automation Objects (AO) using inference mechanisms; thus, the Automation Object Reference of the Industrial Electrotechnical Commission has been formalized and extended by a mechatronics and an IEC 61499 ontology. Dibowski and Kabitzsch (2010) evaluate the applicability of semantic technologies for specifying automation system’s hardware and application making validation techniques possible, such as checking consistency, completeness and correctness. Further concepts, e.g. design support systems for flexible production (Lohse et al., 2006) and maintenance (Stephan et al., 2011) propose approaches to support the engineer regarding dif978-3-902823-33-5/13/$20.00 © 2013 IFAC
ferent aspects in developing manufacturing systems. All these approaches aim at modeling single disciplines not considering the mechanical or electrical discipline (cf. R3). Multi agent systems have recently emerged to provide modularization, decentralization, autonomy, scalability and reusability of mechatronic modules (Lepuschitz et al., 2011). Alsafi and Vyatkin (2010) developed an approach based on the MASON upper ontology in order to infer valid system configurations and, thus, providing reconfiguration of a manufacturing system fulfilling changed requirements. Further on, ontologies are especially used as the agents’ vocabulary in approaches such as Warden et al. (2007); Merdan et al. (2008) not focussing on describing CPM in a holistic manner (cf. R2). Another field of application in which ontologies are used is service-oriented architectures enabling to reuse automation processes by encapsulating them as services. An approach developed by Ollinger et al. (2011) focuses on encapsulation of mechatronic functions provided by production devices into web services. However, identification of appropriate CPMs for fulfilling the required functionality is not focused. Semantic technologies enable semantic description of such services in order to automatically orchestrate them to a complete automation software (Lastra, 2006). Especially OWL-S as upper ontology is being used to describe such semantic web services (Delamer and Lastra, 2006; Loskyll et al., 2011). The application of rulebased inference enables the mapping of services using their preconditions and effects in order to compose the web services (Redavid et al., 2008). However, these serviceoriented techniques are not yet applied in industry and do not consider the mechanical and electrical aspects of an automation system (cf. R2). Additionally, appropriate notation support needs to be provided in order to support the engineer in designing the CPS (cf. R4). 4. APPROACH In this section, the approach for retrieving existing software functionality applicable for a given CPM’s hardware description is presented (cf. Fig. 3). During engineering, the CPM’s structure and software functionality is modeled. In order to retrieve matching functionality for newly designed CPMs during re-engineering, their hardware as well as their feasible states are described. Providing an appropriate notation for mechatronic modules, SysML was chosen as a basis for the modeling approach based on the results of Sch¨ utz et al. (2012). However, since SysML is of a mere semi-formal character and automatic inference mechanisms cannot be applied directly, the modeled information is transformed into a formal model (steps 1 and 2), i.e. ontology. Providing appropriate editing tools and reasoning machines and hence enabling the automatic processing of the information, OWL-DL was chosen as language for the ontology. By that, software functionality can be retrieved by applying inference mechanisms (step 3). The results are then transformed back to a SysML model to support the engineer in choosing the correct software functionality (steps 4 and 5). In the following subsections, the core concepts of the approach are presented using the example of the conveyor introduced in section 2: configuration 1 will be made available in the CPM library in order to retrieve its software functionality for configuration 2.
212
Engineering
into the CPM library in order to make the software functionality available for future applications.
Construction of a new CPM
4.2 Using semantic technologies for CPM retrieval Specification of module’s mechatronic structure
Modeling software structure and behavior
Modeling semantics according to hardware
Re-Engineering
1 Modeling structure
2
Ontology has_Preceding_Operation has_Out_Matching_Operation
val1
postIn1 has_Postcondition_ Input
Operation op
has_Post condition
post
stIn1 has_Value
has_Value
has_Postcondition_ Input
val2
postIn2
SW_State
has_SW_State_Input
stIn2 has_Value
has_Value
st
has_SW_State_Input
n has_SW_State_Input
has_NumberOfInputs has_NumberOfInputs
Modeling feasible states Attachment of a new CPM instance
Identifying matching software 5
valn stInn postInn m Variable_Input has_Postcondition_ has_Value has_Value has_Related_ Input has_NumberOfOutputs in1 Variable
n
is_Possible_SW_State_of has_Variable_Input
has_Variable_Input Operation
has_Variable_Input
has_Tag
op
is_Possible_SW_State_of
tagn has_Related_
opInn
has_Tag
is_Possible_SW_State_of
tag2
opIn2
has_Tag
opIn1 has_Precondition
Action
is_Possible_SW_State_of
out1
has_Variable_Output
tag1 Variable_Output has_Tag
has_Tag
Operation_Complex
is_Possible_SW_State_of
FunctionBlock Operation
Actuate
M_State
Operation_Simple
var1
Sense
Actuator
preInn
has_Precondition_Input
Module_Atomic
Mechatronics SW_Effect_FunctionBlock
has_Precondition_Input
opPre
Tags
Condition
var2 has_Tag
outm
is_Possible_SW_State_of has_Variable_Input
varn
Variable
inn
has_Variable_Output
has_Variable_Input
SW_Effect_Operation
preIn1
Sensor SW_Effect
Software
Module
SW_Effect_Variable
postInn has_Postcondition
Thing
SW_State_Module
has_Postcondition_Input
Module_Basic
SW_State SW_State_Variable
opPost
has_Postcondition_Input
Block_Cylindrical
postIn1
Block
Local
Block_Prismatic
Condition
4
SW_State_ Variable
has_SW_Effect
Output
efInn
Flow_In
Input
has_Effect_Input
Flow Variable
Flow_Out
Variable_Boolean
opEffect SW_Effect_ Operation
has_Effect_Input
efIn1 SW_Effect_ Variable
Variable_Float
Load Electronics Mechanics
ME_Effect ME_State_Module
Variable_Integer ME_State
ME_State_Part Position
3
Reasoning
Fig. 3. Overall concept of CPM library 4.1 Modeling CPM types and instances in SysML In the first step of the modeling approach during engineering, the CPM’s mechatronic structure is specified. Therefore, a new SysML stereotype is introduced containing the information necessary to characterize the CPM. This information is later used in order to classify a newly designed CPM as instance of a CPM type in the library. Regarding configuration 1, the CPM contains two light barriers, a velocity sensor and a motor. In a second step, the CPM’s discipline-specific components, i.e. mechanical and electrical hardware and software functionality, are modeled independently from the CPM. By that, disciplinespecific components are not directly bound to a specific CPM, but may also be used for further CPMs. In the application example, the software operations moveForward() and moveBackward() have been encapsulated in a software component. In this simple scenario, the conveyors shall transport objects from one end to another; hence, the preconditions and effects of these operations are modeled as described by Sch¨ utz et al. (2012). The information modeled during engineering is made available in the library. During re-engineering, in a first step, the new CPM instance’s mechatronic structure is modeled as a SysML block. Regarding configuration 2, the newly designed CPM contains the characteristics of the conveyor described above plus the characteristics added by the additional stopper. The second step involves the modeling of the CPM instance’s feasible states representing the cartesian product of the CPM instance’s sensor values. By that, transitions between feasible states can be inferred later. For the newly designed conveyor configuration 2, permitted states may include object positions at or in between the ends of the conveyor. These software states can be enhanced with semantics by binding the mechanic equivalent to the software states, e.g. further information such as LeftEndPosition and RightEndPosition describing the meaning of the CPM instance’s software states. Subsequently, the models are transformed into the ontology. After a software functionality matching a CPM has been retrieved, the information is transformed back into SysML in order to visualize the result to the engineer. In the example of configuration 2, the engineer can then adapt the retrieved functionality for its new application as well as transform the newly implemented software component 978-3-902823-33-5/13/$20.00 © 2013 IFAC
In order to underline the separation of discipline-specific components of a CPM and enable a retrieval of discipline components, the ontology modeled for the presented approach contains three parts: mechanics, electronics and software ontology. The ontologies contain respective main concepts representing the discipline-specific components, e.g. Function Blocks, States, Operations, Pre- and Postconditions for the software ontology. The CPM structure modeled during engineering is transformed into the TBox representing the terminological knowledge, i.e. the actual module library. By that, newly generated instances can be classified as instances of a certain CPM. Discipline-specific components, e.g. software functionalities, that have been made available during engineering are modeled in the ABox representing the assertional knowledge, i.e. the available software components. These components are then assigned to instances generated during re-engineering. Extending the expressiveness of OWL, DL-safe rules are applied in order to map software functionalities to CPM instances. The mapping between software components and CPM is done as follows: The input and output variables of the software components are mapped to CPM instances that contain equivalent sensors and actuators. Hence, a software functionality is declared executable for the specific CPM instance. Furthermore, the preconditions and effects of a software operation are compared with the CPM’s feasible states. If a feasible state matches the preconditions of a CPM’s executable operation, the operation is declared executable (relation isExecutable) in a specific state. The effects of an operation are used to determine the postconditions of a CPM’s executable operation in order to determine if an operation results into a CPM’s feasible state (relation resultsIn). In the conveyor example, the software functionality of configuration 1 can be retrieved for configuration 2; thus, possible transitions between feasible states of configuration 2 can be proposed. 5. EVALUATION In the following, exemplary CPMs are introduced for which the proposed concept has been proven. Subsequently, quantitative results regarding reasoning times and modeling effort are presented. In order to evaluate the proposed approach, two CPMs switch and pick-and-place unit are used. During engineering, the mechatronic structure and the software of the rotary switch is modeled as described in section 4. During re-engineering, the structure and feasible states of the pick-and-place unit are modeled in order to retrieve the software of the rotary switch. The CPM rotary switch is used to transport discrete object from a source to a target position (cf. Fig. 4, A). It consists of an angle sensor (1) used to measure the current location of the switch, as well as two actuators to either turn the switch clockwise (2) or counterclockwise (3). For the rotary switch, two operations turnLeft90() and turnRight90() have been implemented to turn the CPM by 90 degrees. To make the rotary switch’s software available
213
for its application for further CPMs, a SysML stereotype has been modeled used to generate an equivalent OWL axiom (cf. Fig. 4, B). Therefore, each CPM to be classified as rotary switch must contain an angle sensor as well as two actuators for turning the module clockwise and counterclockwise. Furthermore, the preconditions and effects for the operations have been modeled: As the rotary switch may turn in each of its positions, the precondition is true. The effects of the software operations constitute an increase or decrease of the angle by 90 degrees.
Using the application examples, it has been shown that the proposed concept enables the encapsulation of intelligent CPMs and the modeling of restrictions on the software operations’ execution (cf. R1 and R2). The discipline-specific aspects (cf. R3) as well as the structure and behavior of a CPM are modeled in SysML – a notation supporting the engineer while modeling mechatronic systems (cf. R4) – and then transformed into OWL – a both human- and machine-readable format (cf. R5) – in order to enable automatic processing of the modeled knowledge (cf. R6). Furthermore, as OWL is standardized by the W3C, a Rotary switch 3
2
A
2
Pick-and-place unit
3 1
B
1
bdd PickAndPlaceUnit <>
: Integer
state machine PickAndPlaceUnit <>
Sensor1
turnLeft90()
C
Measure_Angle() <> <>
<>
PickAndPlace
Actuator1
: Sensor1 : Actuator1 : Actuator2 turnRight90() turnLeft90()
turnRight90() : Boolean
Actuator2 Set_Right()
: Boolean
turnLeft90()
turnRight90()
270°
turnLeft90()
Fig. 4. Exemplary OWL axiom and SysML models of the CPMs rotary switch and pick-and-place unit 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Reasoning Time [s]
Crane
100
0
1
2
3
4
5
6
7
8
9
10
9
10
Number of modeled CPM instances per CPM type [-] 600 Separator
500
Cylinder Conveyor
400
Crane
300 200 100 0 0
1
2
3
4
5
6
7
8
Number of modeled CPM instances per CPM type [-]
Fig. 5. Evaluation of reasoning times and modeling effort CPM library stored centrally in an OWL ontology enables the implementation of further interfaces and the access from different sources. Thus, the requirements imposed in section 2 have been evaluated to be fulfilled. In order to determine reasoning times and modeling efforts quantitatively, the presented approach was applied for multiple examples. The reasoning task implemented using OWL API v3.3 1 was performed on a standard office PC 2 . The ontology has been reduced to the axioms necessary to retrieve a specific CPM type. Subsequently, multiple CPM instances of the same type have been modeled in order to measure the time to retrieve the CPM software functionality and to count the instances necessary. Fig. 5 shows the results of the evaluation. The results of the measured reasoning times (Fig. 5, top) show that an increasing number of modeled CPM instances leads to an exponential increase in reasoning times. Furthermore, the number of physical inputs and outputs of a CPM increases the reasoning time drastically. The reason for this dependency is the application of DL-safe rules as for each combination of inand outputs a new rule must be generated increasing the inference’s complexity. Regarding the modeled instances (Fig. 5, bottom), there is a linear dependency between number of CPM instances and number of OWL instances to be modeled. The large number of instances to be modeled supports the necessity to automatically transform the SysML models into the OWL ontology.
turnLeft90()
0°
turnRight90()
Conveyor 150
0
6. CONCLUSION
turnRight90()
180°
<>
Cylinder
50
<>
Set_Left() <>
90°
Separator 200
Number of modeled OWL instances [-]
During re-engineering, the CPM pick-and-place unit shall be implemented. Therefore, the structure of the CPM is being modeled as well as the feasible states of the CPM (cf. Fig. 4, C). The specific CPM type is inferred based on the standard OWL reasoning task instance checking. Furthermore, executable operations are determined using customized DL-safe rule inference by matching the interfaces of the software functionality to the hardware of the CPM. Based on preconditions and effects modeled previously, the transitions between the CPM’s feasible states are inferred. Thus, using the CPMs’ mechatronic descriptions, adequate software functionality can be retrieved out of the CPM library. Thus, the proposed concept intended to retrieve software functionality for a given CPM’s structure can be used to address the use cases as presented in section 2.
250
In this paper, an approach for a semantic CPM library was proposed. As a pure syntactic software description is not sufficient, it must be enhanced with semantics from a CPM’s hardware. A first step towards developing a central CPS platform intended to support the engineer 1 2
http://owlapi.sourceforge.net/ Quad Core, 2.53 GHz, x86 platform
214
while designing CPS composed of CPM was made. Based on a given hardware description modeled in SysML, existing software functionality can be retrieved and matched to CPM by applying semantic technologies and inference mechanisms. A concept based solely on semantic technologies lacks in usability for the engineer; thus, model-driven approaches such as the use of SysML need to be integrated. By that, SysML can be used for modeling and OWL can be used to apply inference mechanisms in order to retrieve software functionality for a given hardware description. Future work will include the revision of the semantic model in order to reduce reasoning times for CPM’s software functionality retrieval. Furthermore, the software prototype implemented for research purposes will be enhanced by support mechanisms such as an automatic transformation from SysML to OWL, e.g. using the Query View Transformation specification (Object Management Group (OMG), 2011). In order to provide a CPS platform as presented in the application scenario, a (semi-) automatic composition of CPS out of the semantic CPM library will be provided. Additionally, the proposed approach will be adapted in order to support variant and version management considering a CPM’s life cycle on the one hand and its variants on the other hand. ACKNOWLEDGEMENTS This work was supported by German Research Foundation (DFG) within the Cluster of Excellence “Cognition for Technical Systems (CoTeSys)”, EXC 142. REFERENCES Alsafi, Y. and Vyatkin, V. (2010). Ontology-based reconfiguration agent for intelligent mechatronic systems in flexible manufacturing. Robot. Comput.-Integr. Manuf., 26(4), 381–391. Bassi, L. et al. (2011). A SysML-Based Methodology for Manufacturing Machinery Modeling and Design. IEEE/ASME Trans. Mechatronics, 16(6), 1049–1062. Delamer, I. and Lastra, J.L.M. (2006). Ontology Modeling of Assembly Processes and Systems using Semantic Web Services. In IEEE Int. Conf. Ind. Informat., 611–617. Singapore, Singapore. Dibowski, H. and Kabitzsch, K. (2010). Ontology-based Device Descriptions and Triple Store based Device Repository for Automation Devices. In IEEE Int. Conf. Emerging Tech. Factory Autom., 1–9. Bilbao, Spain. Geisberger, E. and Broy, M. (eds.) (2012). agendaCPS. Integrierte Forschungsagenda Cyber-Physical Systems. Springer, Berlin, Heidelberg, Germany. Lastra, J. (2006). Semantic Web Services in Factory Automation: Fundamental Insights and Research Roadmap. IEEE Trans. Ind. Informat., 2(1), 1–11. Legat, C. et al. (2013a). Automatic generation of field control strategies for supporting (re-)engineering of manufacturing systems. J. Intell. Manuf., in press. Legat, C. et al. (2013b). Knowledge-Based Technologies for Future Factory Engineering and Control. In SCI, volume 472, 355–374. Springer, Berlin, Heidelberg, Germany. Leit˜ao, P. and Restivo, F. (2006). ADACOR: A holonic architecture for agile and adaptive manufacturing control. Computers in Ind., 57(2), 121–130. 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Lemaignan, S. et al. (2006). MASON: A Proposal For An Ontology Of Manufacturing Domain. In IFAC Workshop Distrib. Int. Syst., 195–200. Prague, Czech Republic. Lepuschitz, W. et al. (2011). Toward Self-Reconfiguration of Manufacturing Systems Using Automation Agents. IEEE Trans. Syst., Man, Cybern. C, 41(1), 52–69. Lohse, N. et al. (2006). Equipment ontology for modular reconfigurable assembly systems. Int. J. Flexible Manuf. Syst., 17(4), 301–314. Loskyll, M. et al. (2011). Semantic service discovery and orchestration for manufacturing processes. In IEEE Int. Conf. Emerging Tech. Factory Autom., 1–8. Toulouse, France. Merdan, M. et al. (2008). Application of an ontology in a transport domain. In IEEE Int. Conf. Ind. Techn., 1–6. Chengdu, China. OMG (2011). Meta Object Facility (MOF) 2.0 Query/ View/ Transformation Specification. URL http://www. omg.org/spec/QVT/1.1/. Obermeier, M. et al. (2011). Fundamental Aspects Concerning the Usability Evaluation of Model-Driven Object Oriented Programming Approaches in Machine and Plant Automation. In LNCS, volume 6770, 497–506. Springer, Berlin, Heidelberg, Germany. Ollinger, L. et al. (2011). Leveraging the Agility of Manufacturing Chains by Combining Process-Oriented Production Planning and Service-Oriented Manufacturing Automation. In IFAC World Congr., 5231–5236. Orozco, O.J.L. and Lastra, J.L.M. (2006). Using semantic web technologies to describe automation objects. Int. J. Manuf. Research, 1(4), 482–503. Redavid, D. et al. (2008). OWL-S Atomic Services Composition with SWRL Rules. In LNCS, volume 4994, 605–611. Springer, Berlin, Heidelberg, Germany. Sch¨ utz, D. et al. (2012). On Modelling the State-Space of Manufacturing Systems Using UML. In IFAC Symp. Inform. Control Problems Manuf., 469–474. Bucharest, Romania. Secchi, C. et al. (2007). Object-Oriented Modeling of Complex Mechatronic Components for the Manufacturing Industry. IEEE/ASME Trans. Mechatronics, 12(6), 696–702. Stephan, P. et al. (2011). Using semantic technologies in location aware applications for mobile factory maintenance. In Int. Conf. Manuf. Sci. Educ. Sibiu, Romania. Sztipanovits, J. (2012). Cyber Physical Systems Convergence of Physical and Information Sciences. Inform. Techn. (it), 54(6), 257–265. Thramboulidis, K. (2010). The 3+1 SysML View-Model in Model Integrated Mechatronics. J. Softw. Eng. Applicat., 3(2), 109–118. Thramboulidis, K. and Frey, G. (2011). Towards a ModelDriven IEC 61131-Based Development Process in Industrial Automation. J. Softw. Eng. Applicat., 4(4), 217– 226. Warden, T. et al. (2007). Towards Ontology-based Multiagent Simulations: The PlaSMA Approach. In European Conf. Modeling Simulation, 50–56. Kuala Lumpur, Malaysia. W3C (2004). OWL-S: Semantic Markup for Web Services. URL http://www.w3.org/Submission/OWL-S/.
215
ThCT1.2
Model-Driven Engineering and Semantic Technologies for the Design of Cyber-Physical Systems S. Feldmann, S. R¨ osch, D. Sch¨ utz, B. Vogel-Heuser Institute of Automation and Information Systems, Technische Universit¨ at M¨ unchen, 85748 Garching bei M¨ unchen, Germany (e-mail: {feldmann; roesch; schuetz; vogel-heuser}@ais.mw.tum.de) Abstract: Rapid changes in product and system requirements force today’s companies to cope with unforeseen adaptations of industrial plants. To enable the implementation of intelligent, self-adapting systems, manufacturing systems must be composed to Cyber-Physical Systems (CPS) out of Cyber-Physical Modules (CPMs). However, cross-disciplinary design of CPS and the multitude of persons involved in this process increases complexity in (re-)engineering drastically. Identification and modeling of typical CPM types in a CPM library provides a first step towards enabling reuse of constructed and verified CPMs and, thus, a knowledge base making automatic composition of CPS out of CPMs possible. In this paper, a concept for retrieving existing automation software functionality from a given hardware description by means of model-driven engineering and semantic technologies is presented. Keywords: manufacturing systems, knowledge-based systems, cyber-physical systems 1. INTRODUCTION
knowledge base making automatic composition – and later self-organization – of CPS out of CPMs possible.
Recent market trends such as changes in product and system requirements during operation of industrial plants as well as changes in lot sizes up to mass customization necessitates to cope with unforeseen adaptations of the automation control software. Manufacturing systems must therefore be composed to Cyber-Physical Systems (CPS) out of Cyber-Physical Modules (CPMs) that encapsulate intelligent software components enabling the implementation of intelligent, self-adapting systems. The term CPS refers to “embedded systems, i.e. devices, buildings, means of transportation, medical devices, logistics (...) and management processes as well as internet services, which [among others] capture physical data using sensors and influence physical processes by means of actuators [and] interpret and store data as a base to interact actively or reactively with the physical and digital world (...)” (Geisberger and Broy, 2012).
In this paper, a concept for a semantic CPM library is proposed making a retrieval of corresponding software functionality possible. Therefore, an approach for integrating interdisciplinary aspects in automation software engineering through describing CPMs semantically by means of ontologies and reasoning mechanisms is presented. Based on an existing CPM’s hardware description, matching software functionalities are retrieved. Furthermore, to increase usability of the approach, a modeling approach supporting the modeling of CPMs is shown.
However, engineering of CPS is a highly cross-disciplinary field of research (Sztipanovits, 2012). Due to the participation of multiple persons and disciplines in design of CPS, e.g. mechanical engineering, electrical engineering and software engineering, challenges such as interoperability in between CPMs and their efficient design arise. One of the main challenges originates from cross-disciplinary effects: changes in a single discipline result in changes in the other disciplines causing a drastic increase of complexity in (re-)engineering of such systems. Hence, providing correct CPMs during each phase of (re-)engineering is a prerequisite in order to support the engineer. To meet this challenge, identifying and modeling of typical CPM types in a CPM library provides a first step towards enabling reuse of constructed and verified CPMs and enables a 978-3-902823-33-5/13/$20.00 © 2013 IFAC
The paper is organized as follows: In the next section, a scenario is introduced illustrating the objectives of a CPS platform as well as the use cases and requirements of a CPM library. In section 3, related work is discussed. The approach of a semantic CPM library enabling the software functionality retrieval is presented in section 4. Its applicability and the coverage of the use cases and integrity of the requirements are evaluated in section 5. The paper is summarized in section 6. 2. MOTIVATION: A CPS SCENARIO In the scenario a manufacturing system comprises a logistics system which transports objects through numerous conveyor belts and rotating switches to production units PU1 and PU2 (cf. Fig. 1). The CPM conveyor (configuration 1 ) is used to transport the objects and can be combined with further actuators and sensors such as light barriers (1 and 2), a velocity sensor (3) and a motor (4). The software component implemented for the initial configuration encapsulates two operations: moveForward() and
210
Maintenance personnel
moveBackward(). The CPMs the manufacturing system is composed of are registered in a central CPM library. During operation of the manufacturing system, jams occur more often than planned beforehand. In order to analyze the cause of these jams, the maintenance personnel downloads relevant engineering documents from a CPS platform (see Fig. 2) containing the constantly updated engineering document database of the company. Having received the data he makes a query on comparable manufacturing systems. The query finishes with the result of a noticeably higher throughput in PU1 compared to PU2; thus, the CPS platform proposes to integrate a buffer system into the manufacturing system. The buffer system shall consist of several additional conveyor belts and switches of a similar type as the ones already used in the plant. Furthermore, a conveyor containing an additional stopper (configuration 2 ) enabling to stop and continue the object throughput shall be used. To plan the integration, the engineer responsible for the changes downloads the current documents for the mechanical construction (mCAD) of the manufacturing system. He plans and models the integration of the buffer system into the mCAD model and registers the finished model into the database as a new variant. Next the electrical layout is planned. The electrical layout (eCAD) is automatically updated with the changes made in the mCAD combined with the engineering information available for the additional modules. The inputs and outputs of the new modules are highlighted to show where the hardware has to be configured anew. Suggestions for the configuration are also made according to available resources. The engineer adapts the suggestions and registers the resulting eCAD. Finally, the software has to be implemented by retrieving matching software functionality from the CPM library. In the presented conveyor example, such a CPM library must be able to identify same CPM types and hence retrieve the same software functionality (use case UC1). However, given a similar CPM structure, e.g. monostable and bistable cylinder, the same software functionality must also be retrievable (UC2). If software components are applicable for CPMs that are completely different, Production Unit 1
Buffer System
Production Unit 2
CPS Platform
Manufacturing system
Construction engineer
Engineering document database
Suppliers
Fig. 2. Interconnection between stakeholders using CPS platform their software functionality – if applicable for both – must also be retrieved (UC3). Furthermore, if more than one software component is matching for a CPM, both components must be proposed to the engineer (UC4). However, the vision of a CPS platform for the production automation domain is not yet state of the art. A semantic CPM library making the retrieval of software functionality possible is a prerequisite for such a CPS platform. Therefore, the engineer must encapsulate the CPM’s functionality in software components (requirement R1). In conveyor configuration 1, the automation software developer implements a software component containing the operations moveForward() and moveBackward(). He also models restrictions on the execution of software functionality (R2), e.g. that an object is transported forward only if present at light barrier 1. Furthermore, in order to make the software components retrievable for future applications, he describes the semantics of software functionality integrating aspects from other disciplines into the CPM (R3) thus regarding the CPM as mechatronic module. As he later wants to retrieve the software for conveyor configuration 2, the CPM’s description must be human-readable (R4), e.g. through an appropriate notation, and machine-readable (R5), e.g. in order to process the information modeled. Subsequently, inference mechanisms (R6) are being applied in order to exploit the available knowledge and identify the matching software functionality. Therefore, the given hardware description is processed and matching software functionality is retrieved. 3. RELATED WORK
2
stopper
1
In this section, related work in the fields of system modeling as well as knowledge-based systems and semantic technologies is discussed. 3.1 System modeling
3 4
Configuration 1
Configuration 2
Fig. 1. Manufacturing system with conveyor configurations 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Modeling techniques are increasingly applied for improving reuse of CPMs and for providing a common system understanding when developing software systems (Thramboulidis, 2010). Secchi et al. (2007) showed that Unified Modeling Language (UML) has proven to support engineers offering a higher usability than traditional program-
211
ming approaches (cf. requirement R4). Model-based engineering reduces effort in automation systems engineering (Obermeier et al., 2011). To provide a more holistic view on the system and to provide modeling other discipline parts (cf. R3), e.g. mechanical and electrical engineering, Systems Modeling Language (SysML) has been developed (Bassi et al., 2011; Thramboulidis and Frey, 2011). However, all these techniques currently do not provide to model the semantics of a CPM (cf. R2), neglecting “what the CPM can do” and rather modeling “what the CPM has to do” (Legat et al., 2013a). An approach proposed by Sch¨ utz et al. (2012) thus enables the modeling of preconditions and effects of a CPM’s software functionality aiming at modeling the space of action of a manufacturing system. Nevertheless, model-based engineering techniques often do not provide applying inference mechanisms (cf. R5 and R6), making the application of semantic technologies and inference mechanisms necessary. 3.2 Knowledge-based systems and semantic technologies In contrast to classical programming which requires to program knowledge explicitly and symbolically within the software code’s structure, a knowledge-based system is capable of supporting the explicit representation of knowledge and of exploiting it through appropriate reasoning mechanisms (Legat et al., 2013b). A technique that has especially been established in order to represent knowledge formally are Web Ontology Language (OWL) ontologies standardized by the World Wide Web Consortium (W3C). Using reasoning mechanisms, such ontologies can be processed automatically to infer implicitly available information from the modeled knowledge (cf. R5 and R6). Several upper ontologies aiming at describing very general concepts of a domain have been developed in manufacturing systems engineering, e.g. ADACOR (Leit˜ao and Restivo, 2006) and MASON (Lemaignan et al., 2006), which use ontologies as a common vocabulary. Nevertheless, these upper ontologies do not address the modeling of restrictions on the execution of software functionality (cf. R2). An approach to solve this challenge is OWL-S (World Wide Web Consortium (W3C), 2004) which addresses the dynamic retrieval and orchestration of encapsulated web services (cf. R1). However, OWLS proposes top-level concepts and enables a rather pure software description. Modeling the physical aspects of a manufacturing system is not part of OWL-S (cf. R3). A main field of application of ontologies are design support systems supporting the engineering in production automation domain using semantic technologies. Orozco and Lastra (2006) aim at retrieving Automation Objects (AO) using inference mechanisms; thus, the Automation Object Reference of the Industrial Electrotechnical Commission has been formalized and extended by a mechatronics and an IEC 61499 ontology. Dibowski and Kabitzsch (2010) evaluate the applicability of semantic technologies for specifying automation system’s hardware and application making validation techniques possible, such as checking consistency, completeness and correctness. Further concepts, e.g. design support systems for flexible production (Lohse et al., 2006) and maintenance (Stephan et al., 2011) propose approaches to support the engineer regarding dif978-3-902823-33-5/13/$20.00 © 2013 IFAC
ferent aspects in developing manufacturing systems. All these approaches aim at modeling single disciplines not considering the mechanical or electrical discipline (cf. R3). Multi agent systems have recently emerged to provide modularization, decentralization, autonomy, scalability and reusability of mechatronic modules (Lepuschitz et al., 2011). Alsafi and Vyatkin (2010) developed an approach based on the MASON upper ontology in order to infer valid system configurations and, thus, providing reconfiguration of a manufacturing system fulfilling changed requirements. Further on, ontologies are especially used as the agents’ vocabulary in approaches such as Warden et al. (2007); Merdan et al. (2008) not focussing on describing CPM in a holistic manner (cf. R2). Another field of application in which ontologies are used is service-oriented architectures enabling to reuse automation processes by encapsulating them as services. An approach developed by Ollinger et al. (2011) focuses on encapsulation of mechatronic functions provided by production devices into web services. However, identification of appropriate CPMs for fulfilling the required functionality is not focused. Semantic technologies enable semantic description of such services in order to automatically orchestrate them to a complete automation software (Lastra, 2006). Especially OWL-S as upper ontology is being used to describe such semantic web services (Delamer and Lastra, 2006; Loskyll et al., 2011). The application of rulebased inference enables the mapping of services using their preconditions and effects in order to compose the web services (Redavid et al., 2008). However, these serviceoriented techniques are not yet applied in industry and do not consider the mechanical and electrical aspects of an automation system (cf. R2). Additionally, appropriate notation support needs to be provided in order to support the engineer in designing the CPS (cf. R4). 4. APPROACH In this section, the approach for retrieving existing software functionality applicable for a given CPM’s hardware description is presented (cf. Fig. 3). During engineering, the CPM’s structure and software functionality is modeled. In order to retrieve matching functionality for newly designed CPMs during re-engineering, their hardware as well as their feasible states are described. Providing an appropriate notation for mechatronic modules, SysML was chosen as a basis for the modeling approach based on the results of Sch¨ utz et al. (2012). However, since SysML is of a mere semi-formal character and automatic inference mechanisms cannot be applied directly, the modeled information is transformed into a formal model (steps 1 and 2), i.e. ontology. Providing appropriate editing tools and reasoning machines and hence enabling the automatic processing of the information, OWL-DL was chosen as language for the ontology. By that, software functionality can be retrieved by applying inference mechanisms (step 3). The results are then transformed back to a SysML model to support the engineer in choosing the correct software functionality (steps 4 and 5). In the following subsections, the core concepts of the approach are presented using the example of the conveyor introduced in section 2: configuration 1 will be made available in the CPM library in order to retrieve its software functionality for configuration 2.
212
Engineering
into the CPM library in order to make the software functionality available for future applications.
Construction of a new CPM
4.2 Using semantic technologies for CPM retrieval Specification of module’s mechatronic structure
Modeling software structure and behavior
Modeling semantics according to hardware
Re-Engineering
1 Modeling structure
2
Ontology has_Preceding_Operation has_Out_Matching_Operation
val1
postIn1 has_Postcondition_ Input
Operation op
has_Post condition
post
stIn1 has_Value
has_Value
has_Postcondition_ Input
val2
postIn2
SW_State
has_SW_State_Input
stIn2 has_Value
has_Value
st
has_SW_State_Input
n has_SW_State_Input
has_NumberOfInputs has_NumberOfInputs
Modeling feasible states Attachment of a new CPM instance
Identifying matching software 5
valn stInn postInn m Variable_Input has_Postcondition_ has_Value has_Value has_Related_ Input has_NumberOfOutputs in1 Variable
n
is_Possible_SW_State_of has_Variable_Input
has_Variable_Input Operation
has_Variable_Input
has_Tag
op
is_Possible_SW_State_of
tagn has_Related_
opInn
has_Tag
is_Possible_SW_State_of
tag2
opIn2
has_Tag
opIn1 has_Precondition
Action
is_Possible_SW_State_of
out1
has_Variable_Output
tag1 Variable_Output has_Tag
has_Tag
Operation_Complex
is_Possible_SW_State_of
FunctionBlock Operation
Actuate
M_State
Operation_Simple
var1
Sense
Actuator
preInn
has_Precondition_Input
Module_Atomic
Mechatronics SW_Effect_FunctionBlock
has_Precondition_Input
opPre
Tags
Condition
var2 has_Tag
outm
is_Possible_SW_State_of has_Variable_Input
varn
Variable
inn
has_Variable_Output
has_Variable_Input
SW_Effect_Operation
preIn1
Sensor SW_Effect
Software
Module
SW_Effect_Variable
postInn has_Postcondition
Thing
SW_State_Module
has_Postcondition_Input
Module_Basic
SW_State SW_State_Variable
opPost
has_Postcondition_Input
Block_Cylindrical
postIn1
Block
Local
Block_Prismatic
Condition
4
SW_State_ Variable
has_SW_Effect
Output
efInn
Flow_In
Input
has_Effect_Input
Flow Variable
Flow_Out
Variable_Boolean
opEffect SW_Effect_ Operation
has_Effect_Input
efIn1 SW_Effect_ Variable
Variable_Float
Load Electronics Mechanics
ME_Effect ME_State_Module
Variable_Integer ME_State
ME_State_Part Position
3
Reasoning
Fig. 3. Overall concept of CPM library 4.1 Modeling CPM types and instances in SysML In the first step of the modeling approach during engineering, the CPM’s mechatronic structure is specified. Therefore, a new SysML stereotype is introduced containing the information necessary to characterize the CPM. This information is later used in order to classify a newly designed CPM as instance of a CPM type in the library. Regarding configuration 1, the CPM contains two light barriers, a velocity sensor and a motor. In a second step, the CPM’s discipline-specific components, i.e. mechanical and electrical hardware and software functionality, are modeled independently from the CPM. By that, disciplinespecific components are not directly bound to a specific CPM, but may also be used for further CPMs. In the application example, the software operations moveForward() and moveBackward() have been encapsulated in a software component. In this simple scenario, the conveyors shall transport objects from one end to another; hence, the preconditions and effects of these operations are modeled as described by Sch¨ utz et al. (2012). The information modeled during engineering is made available in the library. During re-engineering, in a first step, the new CPM instance’s mechatronic structure is modeled as a SysML block. Regarding configuration 2, the newly designed CPM contains the characteristics of the conveyor described above plus the characteristics added by the additional stopper. The second step involves the modeling of the CPM instance’s feasible states representing the cartesian product of the CPM instance’s sensor values. By that, transitions between feasible states can be inferred later. For the newly designed conveyor configuration 2, permitted states may include object positions at or in between the ends of the conveyor. These software states can be enhanced with semantics by binding the mechanic equivalent to the software states, e.g. further information such as LeftEndPosition and RightEndPosition describing the meaning of the CPM instance’s software states. Subsequently, the models are transformed into the ontology. After a software functionality matching a CPM has been retrieved, the information is transformed back into SysML in order to visualize the result to the engineer. In the example of configuration 2, the engineer can then adapt the retrieved functionality for its new application as well as transform the newly implemented software component 978-3-902823-33-5/13/$20.00 © 2013 IFAC
In order to underline the separation of discipline-specific components of a CPM and enable a retrieval of discipline components, the ontology modeled for the presented approach contains three parts: mechanics, electronics and software ontology. The ontologies contain respective main concepts representing the discipline-specific components, e.g. Function Blocks, States, Operations, Pre- and Postconditions for the software ontology. The CPM structure modeled during engineering is transformed into the TBox representing the terminological knowledge, i.e. the actual module library. By that, newly generated instances can be classified as instances of a certain CPM. Discipline-specific components, e.g. software functionalities, that have been made available during engineering are modeled in the ABox representing the assertional knowledge, i.e. the available software components. These components are then assigned to instances generated during re-engineering. Extending the expressiveness of OWL, DL-safe rules are applied in order to map software functionalities to CPM instances. The mapping between software components and CPM is done as follows: The input and output variables of the software components are mapped to CPM instances that contain equivalent sensors and actuators. Hence, a software functionality is declared executable for the specific CPM instance. Furthermore, the preconditions and effects of a software operation are compared with the CPM’s feasible states. If a feasible state matches the preconditions of a CPM’s executable operation, the operation is declared executable (relation isExecutable) in a specific state. The effects of an operation are used to determine the postconditions of a CPM’s executable operation in order to determine if an operation results into a CPM’s feasible state (relation resultsIn). In the conveyor example, the software functionality of configuration 1 can be retrieved for configuration 2; thus, possible transitions between feasible states of configuration 2 can be proposed. 5. EVALUATION In the following, exemplary CPMs are introduced for which the proposed concept has been proven. Subsequently, quantitative results regarding reasoning times and modeling effort are presented. In order to evaluate the proposed approach, two CPMs switch and pick-and-place unit are used. During engineering, the mechatronic structure and the software of the rotary switch is modeled as described in section 4. During re-engineering, the structure and feasible states of the pick-and-place unit are modeled in order to retrieve the software of the rotary switch. The CPM rotary switch is used to transport discrete object from a source to a target position (cf. Fig. 4, A). It consists of an angle sensor (1) used to measure the current location of the switch, as well as two actuators to either turn the switch clockwise (2) or counterclockwise (3). For the rotary switch, two operations turnLeft90() and turnRight90() have been implemented to turn the CPM by 90 degrees. To make the rotary switch’s software available
213
for its application for further CPMs, a SysML stereotype has been modeled used to generate an equivalent OWL axiom (cf. Fig. 4, B). Therefore, each CPM to be classified as rotary switch must contain an angle sensor as well as two actuators for turning the module clockwise and counterclockwise. Furthermore, the preconditions and effects for the operations have been modeled: As the rotary switch may turn in each of its positions, the precondition is true. The effects of the software operations constitute an increase or decrease of the angle by 90 degrees.
Using the application examples, it has been shown that the proposed concept enables the encapsulation of intelligent CPMs and the modeling of restrictions on the software operations’ execution (cf. R1 and R2). The discipline-specific aspects (cf. R3) as well as the structure and behavior of a CPM are modeled in SysML – a notation supporting the engineer while modeling mechatronic systems (cf. R4) – and then transformed into OWL – a both human- and machine-readable format (cf. R5) – in order to enable automatic processing of the modeled knowledge (cf. R6). Furthermore, as OWL is standardized by the W3C, a Rotary switch 3
2
A
2
Pick-and-place unit
3 1
B
1
bdd PickAndPlaceUnit <
: Integer
state machine PickAndPlaceUnit <
Sensor1
turnLeft90()
C
Measure_Angle() <
<
PickAndPlace
Actuator1
: Sensor1 : Actuator1 : Actuator2 turnRight90() turnLeft90()
turnRight90() : Boolean
Actuator2 Set_Right()
: Boolean
turnLeft90()
turnRight90()
270°
turnLeft90()
Fig. 4. Exemplary OWL axiom and SysML models of the CPMs rotary switch and pick-and-place unit 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Reasoning Time [s]
Crane
100
0
1
2
3
4
5
6
7
8
9
10
9
10
Number of modeled CPM instances per CPM type [-] 600 Separator
500
Cylinder Conveyor
400
Crane
300 200 100 0 0
1
2
3
4
5
6
7
8
Number of modeled CPM instances per CPM type [-]
Fig. 5. Evaluation of reasoning times and modeling effort CPM library stored centrally in an OWL ontology enables the implementation of further interfaces and the access from different sources. Thus, the requirements imposed in section 2 have been evaluated to be fulfilled. In order to determine reasoning times and modeling efforts quantitatively, the presented approach was applied for multiple examples. The reasoning task implemented using OWL API v3.3 1 was performed on a standard office PC 2 . The ontology has been reduced to the axioms necessary to retrieve a specific CPM type. Subsequently, multiple CPM instances of the same type have been modeled in order to measure the time to retrieve the CPM software functionality and to count the instances necessary. Fig. 5 shows the results of the evaluation. The results of the measured reasoning times (Fig. 5, top) show that an increasing number of modeled CPM instances leads to an exponential increase in reasoning times. Furthermore, the number of physical inputs and outputs of a CPM increases the reasoning time drastically. The reason for this dependency is the application of DL-safe rules as for each combination of inand outputs a new rule must be generated increasing the inference’s complexity. Regarding the modeled instances (Fig. 5, bottom), there is a linear dependency between number of CPM instances and number of OWL instances to be modeled. The large number of instances to be modeled supports the necessity to automatically transform the SysML models into the OWL ontology.
turnLeft90()
0°
turnRight90()
Conveyor 150
0
6. CONCLUSION
turnRight90()
180°
<
Cylinder
50
<
Set_Left() <
90°
Separator 200
Number of modeled OWL instances [-]
During re-engineering, the CPM pick-and-place unit shall be implemented. Therefore, the structure of the CPM is being modeled as well as the feasible states of the CPM (cf. Fig. 4, C). The specific CPM type is inferred based on the standard OWL reasoning task instance checking. Furthermore, executable operations are determined using customized DL-safe rule inference by matching the interfaces of the software functionality to the hardware of the CPM. Based on preconditions and effects modeled previously, the transitions between the CPM’s feasible states are inferred. Thus, using the CPMs’ mechatronic descriptions, adequate software functionality can be retrieved out of the CPM library. Thus, the proposed concept intended to retrieve software functionality for a given CPM’s structure can be used to address the use cases as presented in section 2.
250
In this paper, an approach for a semantic CPM library was proposed. As a pure syntactic software description is not sufficient, it must be enhanced with semantics from a CPM’s hardware. A first step towards developing a central CPS platform intended to support the engineer 1 2
http://owlapi.sourceforge.net/ Quad Core, 2.53 GHz, x86 platform
214
while designing CPS composed of CPM was made. Based on a given hardware description modeled in SysML, existing software functionality can be retrieved and matched to CPM by applying semantic technologies and inference mechanisms. A concept based solely on semantic technologies lacks in usability for the engineer; thus, model-driven approaches such as the use of SysML need to be integrated. By that, SysML can be used for modeling and OWL can be used to apply inference mechanisms in order to retrieve software functionality for a given hardware description. Future work will include the revision of the semantic model in order to reduce reasoning times for CPM’s software functionality retrieval. Furthermore, the software prototype implemented for research purposes will be enhanced by support mechanisms such as an automatic transformation from SysML to OWL, e.g. using the Query View Transformation specification (Object Management Group (OMG), 2011). In order to provide a CPS platform as presented in the application scenario, a (semi-) automatic composition of CPS out of the semantic CPM library will be provided. Additionally, the proposed approach will be adapted in order to support variant and version management considering a CPM’s life cycle on the one hand and its variants on the other hand. ACKNOWLEDGEMENTS This work was supported by German Research Foundation (DFG) within the Cluster of Excellence “Cognition for Technical Systems (CoTeSys)”, EXC 142. REFERENCES Alsafi, Y. and Vyatkin, V. (2010). Ontology-based reconfiguration agent for intelligent mechatronic systems in flexible manufacturing. Robot. Comput.-Integr. Manuf., 26(4), 381–391. Bassi, L. et al. (2011). A SysML-Based Methodology for Manufacturing Machinery Modeling and Design. IEEE/ASME Trans. Mechatronics, 16(6), 1049–1062. Delamer, I. and Lastra, J.L.M. (2006). Ontology Modeling of Assembly Processes and Systems using Semantic Web Services. In IEEE Int. Conf. Ind. Informat., 611–617. Singapore, Singapore. Dibowski, H. and Kabitzsch, K. (2010). Ontology-based Device Descriptions and Triple Store based Device Repository for Automation Devices. In IEEE Int. Conf. Emerging Tech. Factory Autom., 1–9. Bilbao, Spain. Geisberger, E. and Broy, M. (eds.) (2012). agendaCPS. Integrierte Forschungsagenda Cyber-Physical Systems. Springer, Berlin, Heidelberg, Germany. Lastra, J. (2006). Semantic Web Services in Factory Automation: Fundamental Insights and Research Roadmap. IEEE Trans. Ind. Informat., 2(1), 1–11. Legat, C. et al. (2013a). Automatic generation of field control strategies for supporting (re-)engineering of manufacturing systems. J. Intell. Manuf., in press. Legat, C. et al. (2013b). Knowledge-Based Technologies for Future Factory Engineering and Control. In SCI, volume 472, 355–374. Springer, Berlin, Heidelberg, Germany. Leit˜ao, P. and Restivo, F. (2006). ADACOR: A holonic architecture for agile and adaptive manufacturing control. Computers in Ind., 57(2), 121–130. 978-3-902823-33-5/13/$20.00 © 2013 IFAC
Lemaignan, S. et al. (2006). MASON: A Proposal For An Ontology Of Manufacturing Domain. In IFAC Workshop Distrib. Int. Syst., 195–200. Prague, Czech Republic. Lepuschitz, W. et al. (2011). Toward Self-Reconfiguration of Manufacturing Systems Using Automation Agents. IEEE Trans. Syst., Man, Cybern. C, 41(1), 52–69. Lohse, N. et al. (2006). Equipment ontology for modular reconfigurable assembly systems. Int. J. Flexible Manuf. Syst., 17(4), 301–314. Loskyll, M. et al. (2011). Semantic service discovery and orchestration for manufacturing processes. In IEEE Int. Conf. Emerging Tech. Factory Autom., 1–8. Toulouse, France. Merdan, M. et al. (2008). Application of an ontology in a transport domain. In IEEE Int. Conf. Ind. Techn., 1–6. Chengdu, China. OMG (2011). Meta Object Facility (MOF) 2.0 Query/ View/ Transformation Specification. URL http://www. omg.org/spec/QVT/1.1/. Obermeier, M. et al. (2011). Fundamental Aspects Concerning the Usability Evaluation of Model-Driven Object Oriented Programming Approaches in Machine and Plant Automation. In LNCS, volume 6770, 497–506. Springer, Berlin, Heidelberg, Germany. Ollinger, L. et al. (2011). Leveraging the Agility of Manufacturing Chains by Combining Process-Oriented Production Planning and Service-Oriented Manufacturing Automation. In IFAC World Congr., 5231–5236. Orozco, O.J.L. and Lastra, J.L.M. (2006). Using semantic web technologies to describe automation objects. Int. J. Manuf. Research, 1(4), 482–503. Redavid, D. et al. (2008). OWL-S Atomic Services Composition with SWRL Rules. In LNCS, volume 4994, 605–611. Springer, Berlin, Heidelberg, Germany. Sch¨ utz, D. et al. (2012). On Modelling the State-Space of Manufacturing Systems Using UML. In IFAC Symp. Inform. Control Problems Manuf., 469–474. Bucharest, Romania. Secchi, C. et al. (2007). Object-Oriented Modeling of Complex Mechatronic Components for the Manufacturing Industry. IEEE/ASME Trans. Mechatronics, 12(6), 696–702. Stephan, P. et al. (2011). Using semantic technologies in location aware applications for mobile factory maintenance. In Int. Conf. Manuf. Sci. Educ. Sibiu, Romania. Sztipanovits, J. (2012). Cyber Physical Systems Convergence of Physical and Information Sciences. Inform. Techn. (it), 54(6), 257–265. Thramboulidis, K. (2010). The 3+1 SysML View-Model in Model Integrated Mechatronics. J. Softw. Eng. Applicat., 3(2), 109–118. Thramboulidis, K. and Frey, G. (2011). Towards a ModelDriven IEC 61131-Based Development Process in Industrial Automation. J. Softw. Eng. Applicat., 4(4), 217– 226. Warden, T. et al. (2007). Towards Ontology-based Multiagent Simulations: The PlaSMA Approach. In European Conf. Modeling Simulation, 50–56. Kuala Lumpur, Malaysia. W3C (2004). OWL-S: Semantic Markup for Web Services. URL http://www.w3.org/Submission/OWL-S/.
215