- Email: [email protected]
Interdisciplinary Engineering Methodology for changeable Cyber-Physical Production Systems
12th IFAC Workshop on Intelligent Manufacturing Systems 12th IFAC Workshop on Intelligent Manufacturing Systems December 5-7, 2016. Austin, TX, USA 12th on Manufacturing Systems Available online at www.sciencedirect.com 12th IFAC IFAC Workshop Workshop on Intelligent Intelligent Manufacturing Systems December December 5-7, 5-7, 2016. 2016. Austin, Austin, TX, TX, USA USA December 5-7, 2016. Austin, TX, USA
ScienceDirect IFAC-PapersOnLine 49-31 (2016) 85–90
Interdisciplinary Engineering Methodology for changeable Cyber-Physical Interdisciplinary Engineering Methodology for changeable Cyber-Physical Interdisciplinary Methodology for Interdisciplinary Engineering Engineering Methodology for changeable changeable Cyber-Physical Cyber-Physical Production Systems Production Systems Production Systems Production Systems
E. Marseu*, D. Kolberg*, E. Marseu*, Marseu*, D. Kolberg*, E. Birtel* , D. D. Kolberg*, Zühlke* E.M. Marseu*, M. Birtel* ,, D. D. Kolberg*, Zühlke* M. Birtel* D. M. Birtel* , D. Zühlke* Zühlke* , German Research Center for Artificial Intelligence (DFKI), Trippstadter Strasse 122, 67663 * SmartFactoryKL , German Research Center for Artificial Intelligence (DFKI), Trippstadter Strasse 122, 67663 * SmartFactory SmartFactoryKL KL KL Germany (e-mail: [email protected]) KL, GermanKaiserslautern, Research for Intelligence (DFKI), * Research Center Center for Artificial Artificial Intelligence (DFKI), Trippstadter Trippstadter Strasse Strasse 122, 122, 67663 67663 * SmartFactory , GermanKaiserslautern, Germany (e-mail: [email protected]) Kaiserslautern, Germany (e-mail: [email protected]) Kaiserslautern, Germany (e-mail: [email protected]) Abstract: Fluctuating market demands and increasing demand for customized products require reactive Abstract: Fluctuating market demands and increasingSystems demand(CPPS) for customized products requireofreactive reactive production Fluctuating environments. Cyber-Physical Production describe products the integration CyberAbstract: market demands increasing demand for require Abstract: Fluctuating market demands and and increasingSystems demand(CPPS) for customized customized products requireof reactive production environments. Cyber-Physical Production describe the integration CyberPhysical Systems (CPSs) in production systems in order to enhance their changeability by production environments. Cyber-Physical Production Systems (CPPS) describe the integration of Cyberproduction environments. Cyber-Physical Production Systems (CPPS) describe the integration of CyberPhysical Systems (CPSs) in production production systemschangeable, in order order to also enhance their changeability by modularization. Production systems thereby become but more complex. There is only Physical Systems (CPSs) in systems in to enhance their changeability by Physical Systems (CPSs) systems in production systemschangeable, in order but to also enhance their changeability by modularization. Production thereby become become more complex. There is only only little experienceProduction in engineering modular CPS-based systemsbut foralso themore production. An adequate modularization. systems thereby changeable, complex. There is modularization. Production systems thereby become changeable, but also more complex. There is only little experience in engineering modular CPS-based systems for the design production. An adequate adequate little in modular CPS-based systems for production. An methodology can provide a guideline and support engineers in the complex process. this little experience experience in engineering engineering modular CPS-based systems for the the design production. AnHence, adequate methodology can provide a guideline guideline and support support engineers in modular the complex complex process. Hence, this methodology can provide a and engineers in the design process. Hence, this paper proposes an interdisciplinar methodology for engineering CPPS. methodology can provide a guideline and support engineers in modular the complex design process. Hence, this paper proposes an interdisciplinar methodology for engineering CPPS. paper proposes an methodology for engineering modular CPPS. paper proposes an interdisciplinar interdisciplinar methodology forCyber-Physical engineering modular CPPS. © 2016, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Keywords: Interdisciplinary design; Modularity; System; Production System; Systems Keywords: Interdisciplinary design; Modularity; Cyber-Physical System; Production System; System; Systems Systems Engineering Keywords: Interdisciplinary design; Modularity; Cyber-Physical System; Production Keywords: Interdisciplinary design; Modularity; Cyber-Physical System; Production System; Systems Engineering Engineering Engineering
1. INTRODUCTION 1. 1. INTRODUCTION INTRODUCTION INTRODUCTION Globalized markets 1.require companies to produce variable Globalized markets require companies produce variable and customized product ranges in short to and with low Globalized markets require companies to produce variable Globalized markets require companies toterm produce variable and customized product ranges in short term and with low costs (Bauernhansl 2014). The design, assembly and and customized product ranges in short term and with and customized product rangesThe in short termassembly and with low low costs (Bauernhansl 2014). design, and costs (Bauernhansl 2014). The design, assembly and commissioning from special-purpose production machines to costs (Bauernhansl 2014). The design, assembly and commissioning from special-purpose production machines to commissioning from special-purpose production machines to answer to customized demands is an expensive and timecommissioning from special-purpose production machines to answer to customized demands is an expensive and timeanswer to customized demands is an expensive and timeconsuming task since existing solutions can hardly be reused. answer to customized demands is an expensive and timeconsuming since existing solutions can hardlyproducts be reused. To satisfy task the demand for highly customized in consuming task since solutions can be consuming task since existing existing solutions can hardly hardlyproducts be reused. reused. To satisfy the demand for highly customized in shortest lead time and lower costs, production systems must To satisfy the demand for highly customized products in To satisfy the demand for highly customizedsystems products in shortest lead time and lower costs, production must be highly changeable. shortest lead time and lower costs, production systems must shortest lead time and lower costs, production systems must be highly changeable. be highly changeable. be highly changeable. In the literature, changeability marks the potential to adapt to In the literature, changeability the potential to adapt to changing requirements in a marks reactive or proactive way In the literature, changeability marks the to to In the literature, changeability marks the potential potential to adapt adapt to changing requirements in a reactive or proactive way (Wiendhal 2002). In constrast to flexibility, changeability changing requirements in a reactive or proactive way changing requirements in a reactive or proactive way (Wiendhal 2002). In constrast to flexibility, changeability (Wiendhal 2002). constrast to allows to perform outsidechangeability predefined (Wiendhal 2002). In Innecessary constrast changes to flexibility, flexibility, changeability allows to perform necessary changes outside predefined allows to perform necessary changes outside predefined requirements corridors (Nyhuis 2006). On the physical level, allows to perform necessary changesOnoutside predefined requirements corridors (Nyhuis 2006). the physical level, production systems must be highly reactive and requirements corridors (Nyhuis 2006). On the physical level, requirements corridors (Nyhuis 2006). On the physical level, production systems must be highly reactive and reconfigurable, allowing changeable functionalities production systems must be highly reactive production systems must be highly reactive and and reconfigurable, allowing changeable functionalities and scalable capacities by adding, removing or modifying reconfigurable, allowing changeable functionalities and reconfigurable, allowing changeable functionalities and scalable capacities by adding, removing or modifying modules. On the logical level, the operating IT systems have scalable capacities by adding, removing or modifying scalable capacities by adding, removing or modifying modules. On the logical level, the operating IT systems have to be changeable as well in order to support the physical modules. On level, the IT have modules. On the the logical logical level, the operating operating IT systems systems have to be changeable as well in order to support the physical changes. Additionally, a control loop must monitor change to be changeable as well in order to support the physical to be changeable as well in order to support the physical changes. Additionally, control loop on must monitor change changes. Additionally, aaa control loop must monitor change drivers and trigger change activities both physical and changes. Additionally, control loop on must monitor change drivers and trigger change activities both physical and drivers and trigger change activities on both physical logical levels. drivers and trigger change activities on both physical and and logical levels. logical levels. logical levels. Combining logical level, physical level and control loop into Combining logical level, physical level and control loop into single modules a production system leads Combining logical level, level control loop into Combining logicalwithin level, physical physical level and and control loopto intoaa single modules within a production system leads to distributed system, enabling a higher changeability to react single modules within a production system leads to single modules within a production system leads to aa distributed system, enabling aa higher changeability to react on unforeseen changing market demands. These individual distributed system, enabling higher changeability to react distributed system, enabling a higher changeability to react on unforeseen demands. These individual modules followchanging the ideamarket of autonomous subsystems with on unforeseen changing market demands. These individual on unforeseen changing market demands. These individual modules follow the idea of autonomous subsystems with standardized interfaces designed to ensure inter-changeability modules follow the idea of autonomous subsystems modules follow the idea of autonomous subsystems with with standardized interfaces designed to paradigm, ensure inter-changeability inter-changeability standardized interfaces designed to ensure with little efforts. This known as standardized interfaces designed to paradigm, ensure inter-changeability with little efforts. This known as with little efforts. This paradigm, known as „Plug´n´Produce“, describes the idea of a modular production with little efforts. This paradigm, known as „Plug´n´Produce“, describes the idea of a modular production „Plug´n´Produce“, describes the idea of a modular production system. Like LEGO bricks, production systems are „Plug´n´Produce“, describes the idea of a modular production system. Like LEGO bricks, production systems are assembled by putting system. Like LEGO bricks, production systems are system. Like LEGO together bricks, compatible production modules systems with are assembled by putting together compatible modules with assembled by putting together compatible modules with assembled by putting together compatible modules with
different functionalities. To allow this, production modules different functionalities. To allow this, production modules different functionalities. To allow this, modules have to become smart. A as well as a different functionalities. Tocertain allow intelligence this, production production modules have to become smart. A certain intelligence as well as aa have to become smart. A certain intelligence as well unified communication interface and self-configuration have to become smart. A interface certain intelligence as well as as a unified communication and self-configuration unified communication interface self-configuration abilities are required. (Zühlke 2010) and unified communication interface and self-configuration abilities are (Zühlke abilities are required. required. (Zühlke 2010) 2010) abilities required. (Weyer are et al. 2017) (Zühlke already 2010) described an approach for a (Weyer et al. 2017) already described an approach for aa production line following those paradigms. although (Weyer et al. 2017) already described an approach for (Weyer et line al. 2017) already described anBut approach forthe a production following those paradigms. But although the vision of modular production systems hasBut become clearer production line following those paradigms. although the production line following those paradigms. But although the vision of modular production systems has become now, their engineering is still challenging. To clearer allow vision of production systems has clearer vision of modular modular production systems has become become clearer now, their engineering is still challenging. To allow changeability and Plug´n´Produce abilities, production now, their engineering is still challenging. To now, their engineering is still challenging. To allow allow changeability and Plug´n´Produce abilities, production changeability and Plug´n´Produce abilities, production systems must be designed in a new way where the modules changeability and Plug´n´Produce abilities, production systems must be designed in a new way where the modules systems must designed in aa new way the are considered individual described by their systems must be beas designed in black newboxes way where where the modules modules are considered as individual black boxes described by their are considered as individual black boxes described by functionalities and attributes, composing a whole system and are considered and as individual black boxesa described by their their functionalities attributes, composing whole system and following the paradigm of object-orientation. These functionalities and attributes, composing a whole system and functionalities andparadigm attributes, composing a whole system and following the of object-orientation. These autonomous modules represent individual mechatronical following the paradigm of object-orientation. These following the paradigm of object-orientation. These autonomous modules represent individual mechatronical systems, combining components with mechanical and autonomous modules represent individual mechatronical autonomous modulesIT represent individual mechatronical systems, combining IT components with mechanical and electronical parts. After a review of current approaches to systems, combining IT components with mechanical and systems, combining IT acomponents with mechanical and electronical parts. After review of current approaches to enhance changeability in production environments as well as electronical parts. After a review of current approaches to electronical parts. After aproduction review ofenvironments current approaches to enhance changeability in as well well as as enhance changeability in production environments as existing engineering approaches, this paper presents a enhance changeability in production environments as well as existing engineering approaches, this paper presents aa existing engineering approaches, this paper presents procedural model for engineering CPPS which considers existing engineering approaches, this paper presents a procedural model for engineering CPPS which considers procedural model for CPPS which considers interdisciplinary work asengineering well as modularization. procedural model for engineering CPPS which considers interdisciplinary work as well as modularization. interdisciplinary interdisciplinary work work as as well well as as modularization. modularization. 2. CURRENT APPROACHES TO ENHANCE 2. CURRENT APPROACHES TO ENHANCE CHANGEABILITY BY USING CPS 2. APPROACHES TO 2. CURRENT CURRENT APPROACHES TO ENHANCE ENHANCE CHANGEABILITY BY USING CPS CHANGEABILITY BY USING CPS BY USING CPS to enhance CPS can beCHANGEABILITY considered as a key technology CPS can be considered as a key technology to enhance changeability by modularization (Bauernhansl 2014). CPS can as to CPS can be be considered considered as aa key key technology technology to enhance enhance changeability by modularization (Bauernhansl 2014). Powerful but still affordable microcontrollers with connected changeability by modularization (Bauernhansl 2014). changeability byaffordable modularization (Bauernhansl 2014). Powerful but still microcontrollers with connected Powerful but still affordable microcontrollers with connected sensors and actuators are able to interact with their Powerful but still affordable microcontrollers with connected sensors and actuators are able to interact with their sensors and actuators are able to interact with their environment. By using wide-spread communication protocols sensors and By actuators are able communication to interact with their environment. using wide-spread protocols environment. By using wide-spread communication protocols like the internet protocol, they are able to communicate with environment. By using wide-spread communication protocols like the internet protocol, they are able to communicate with other entities within their environment. As a result, CPS can like the internet protocol, they are able to communicate with like the internet protocol, they are able to communicate with other entities within their environment. As a result, CPS can work autonomously and provide features like selfother entities within their environment. As a result, CPS can other entities within their environment. As a result,like CPSselfcan work autonomously and provide features configuration to seamlessly integrate into existing work autonomously and provide features like selfwork autonomously and provide features like selfconfiguration to seamlessly integrate into existing environments. (Lee Broy 2010) configuration to seamlessly integrate configuration to 2008, seamlessly integrate into into existing existing environments. (Lee 2008, Broy 2010) environments. (Lee 2008, Broy 2010) environments. (Lee 2008, Broy 2010)
2405-8963 © 2016 2016, IFAC IFAC (International Federation of Automatic Control) Copyright@ 93 Hosting by Elsevier Ltd. All rights reserved. Peer review under IFAC responsibility of International Federation of Automatic Control. Copyright@ 93 Copyright@ 2016 2016 IFAC 93 Copyright@ 2016 IFAC 93 10.1016/j.ifacol.2016.12.166
2017 IFAC IMS 86 December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
First architectures for applying CPS in production already exist. (Pirvu et al. 2015) describe an anthropocentric approach for the integration of CPS in the context of machines and humans. Although they highlighted the need for adapters between entities to realize interoperability, they stay on an abstract level and do not deepen these adapters. (Kolberg et al. 2016) presents a framework consisting of an architecture, modeling methodology and procedural model. In their approach they define seven CPS-based entities as well as building bricks to deepen the modeling. The procedural model describes a step-by-step instruction to identify and model use cases for CPS in production, but does not consider modularization. Furthermore, (Kolberg and Zühlke 2015) describe an approach for using CPS as a retrofitting component to digitize working stations in Lean Production. Similar, (Bergweiler 2015) applies CPS on field devices for self-monitoring. Other approaches and architectures for CPS in production are based on serviceoriented architectures and agent-based systems as mentioned in (La and Kim 2010) or (Hu et al. 2012).
Fig. 1. General system architecture for modular production systems (Weyer et al. 2017) 3. REVIEW OF EXISTING ENGINEERING APPROACHES In his work, (Eigner 2014) proposes a comprehensive review of discipline-specific methodologies, including the fields of mechanical, electronical and software engineering. In mechanical engineering, modularization is being considered in the early design phase where the solutions are divided into single modules, resulting in a modular structure. It can thereby be distinguished between assembly modules which enable an assembly friendly product design and variation modules which enable a structure made of building blocks. Thus, the construction ramifies into a parallel development of assemblies and individual parts. In software engineering, modularization is focused within object oriented approaches and multiagent systems design paradigms. They support emergent behaviors, reconfigurability and Plug´n´Produce abilities. This discipline additionally proposes agile methods like Scrum or Kanban in order to master the complexity induced by software development lifecycles (Bleek et al. 2008). (Eigner 2014) doensn´t mention any methodology for the design of usable systems. However, as the useware engineering is taking a growing place next to the hardware and software engineering within the design of production systems, adequate methodologies are exemplarily described in (Zühlke 2012) and by the norm DIN EN-ISO 9241-210.
Besides these research-driven approaches, there is also an approach for a highly modular, CPS-based architecture for production lines. This approach, as described in (Weyer et al. 2017), was developed at the living lab SmartFactoryKL by research and industry partners from the area of automation. The architecture is divided into the product, production, supply, integration and IT layers (Fig.1). By separating these layers from each other, interdependencies are prevented. Still, standardized communication protocols and information models allow a connection between them and enable the read/write access from the IT-systems on the production processes. The production layer consists of process components with standardized interfaces, bundling production functionalities and composing autonomous Plug´n´Produce modules individually controlled by their own PLC or CPS. Each node of the supply layer supplies one or several production modules with energy and industrial Ethernet via a single standardized connector. In this architecture, each production module represents a black box encapsulating functionalities and attributes, which can be connected to surrounding systems like other CPS-moduels or IT-systems and interact with them via standardized interfaces. In the framework of this paper, an autonomous production module controlled by its own PLC is called a CPS-module. Hence, a CPPS is defined as a modular distributed production system composed of several CPSmodules.
The mentioned methodologies all offer powerful disciplinespecific engineering processes, methods and tools. However, today's products are increasingly composed of software and embedded electronics, leading to a paradigm shift from products to open systems that exchange data and must be integrated in their environment. These systems, e.g. CPS, are becoming complex, highly networked and multidisciplinary (Broy 2010). Hence, (Eigner 2014) further reviews intersciplinary methodologies from the fields of mechatronics and Systems Engineering. He further presents the ModelBased Systems Engineering (MBSE) as an evolution of the classical document-based Systems Engineering. This approach enables a collaboration between the disciplines involved and the development phases through centrally available digital models. The V-model for MBSE is further described in (Eigner 2014b). Other contributions for the engineering of CPS-based solutions to be find in the literature
Engineering CPPS is a complicated task. The involvement of several disciplines as well as the difficulties arising from changeability requirements, distributed control and sophisticated interactions set new challenges to their design and integration. Many of the existing classical ways of engineering systems do not fit these paradigms. Additionally, as new production systems must allow an ergonomic humanmachine interaction, the engineering process must further take the usability of the CPPS into account through the integration of user-friendly machine operating systems (Zühlke 2012).
94
2017 IFAC IMS December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
87
mainly define development principles for their own application fields. Exemplarily, (Lee and Seshia 2011) handle the development of CPS in relation to their properties as embedded systems and particularly focus on hardware components and logical aspects of the system design. For embedded systems, (Slomka et al. 2011) further suggest the merging of a software development methodology with a platform-based design for coupling the physical and digital worlds and intergating various subsystems. Current approaches are mainly proposing classical top-down hierarchical design methodologies which require time to describe all behaviours of the system and don´t let room to highly reactives and self-X properties. Furthermore, little contributions in the literature propose approaches for engineering changeable production systems. Exemplarily, (Weber et al. 2016) focus on the function-based modularization of production systems using the axiomatic design (AD), which is further described in (Weber et al. 2015), to achieve maximum changeabilty. The approach from (Francalanza et al. 2014) for changeable production systems is based on the object-oriented method, which is further described in (Schuh et al. 2009). As for (Yamazaki et al. 2016), they apply Lean paradigms in their approach for the development of automated systems and consider changeability as a consequence of Lean Engineering. These methodologies for changeable production systems mainly concern the mechanical parts of the systems and focus on the modularization of the hardware side whithout in-depth consideration of the software side. Although they allow a modular engineering for mechanically reconfigurable production systems, they do not consider the need for reactive properties, the distribution of control tasks, the interaction with third party systems or the integration of the useware.
Fig. 2. Procedural model for Engineering CPPS The model considers multiple levels of abstraction. Consequently, the CPPS is divided into the system, subsystem and component levels. In the 1st phase, the whole system is abstracted and divided into subsystems. An interdisciplinary and model-based description of the CPPS is created on a high abstraction level. On a lower abstraction level, in phase 2, the modularity and the division of the CPPS into subsystems is considered and the interfaces of the CPSmodules are defined. On a third abstraction level, in phase 3, each module is defined more precisely according to its future functions. The phases 4 and 5 represent the integration of the system and merge the results from phases 1 to 3 by putting together the individual modules of the CPPS and hamonising the interfaces between them and with their environment. The individual phases are further divided into multiple steps, whereby discipline-specific methods and tools are to be used. The output of each phase consitutes the input of the following phase. Especially the phases 1, 2 and 3 will be deepened in the following paragraphs.
4. APPROACH FOR A METHODOLOGY FOR ENGINEERING CPPS The presented methodology takes into account the previously mentioned requirements for engineering CPPS. To reduce the complexity resulting from the engineering of these systems, the development is carried out through a structured fivephase procedural model, subdividing the design process into manageable and limited phases. However, the transitions between the different levels happen seamlessly. The resulting procedural model is illustrated in Fig. 2. and includes the design and integration of the CPPS. Predefined goals and requirements form the input and must take the current situation of the production environment into account. The final result is a test-ready CPPS.
4.1 1st and 2nd Phase: Design of the system and its subsystems The initiation phase includes the predefined goals of the project, building the basis for all design activities. The aim of the 1st phase is the conceptual design of a comprehensive model of the CPPS, laying the fundament for a subsequently efficient implementation of the requirements. To this end, mechanical, electrical, software and useware engineers must be involved. The comprehensive system design must include the processes, the system structure as well as a classification of the functionalities. A special focus should lie on the interfaces within the system and the interfaces with the system environment. This concerns exchanged information between control systems on the one hand and streams of physical objects between the different modules on the other hand. For the modeling, existing computer science methods like UML or SysML can be used. Established approaches for the modeling of distributed controlled production environments like ALEM-P (Kolditz 2009) or CyProF
95
2017 IFAC IMS 88 December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
(Kolberg et al. 2016) start with modeling the functions and goals e.g. in a use-case diagram. In two separated next steps, the structure and the process can be modelled. Approaches like ARIS (Scheer 2002) or CyProF recommend to model the process first in order to stronger focus on the processes which are needed to generate an added value or to produce the final product. Approaches like ALEM-P start with the structure, which is more intuitive for the project members. In order to model the structure, relevant physical or digital objects for the CPPS have to be identified and dependencies between these objects must be highlighted. Here, one can make use of UML´s structure diagrams or of SysML´s block diagram. In order to deepen the subsystems any further in the next phases and realize the modularity, it must be decided which subsystems will compose the CPPS and especially what functionalities they will take over. Considering the changeability of a CPPS, a function-oriented approach is recommended. This approach assigns single process steps with similar results, e.g. with similar inputs and outputs, to one group, which must further be taken over by a subsystem. Although components can be redundant in order to ensure modularity, it may be profitable in the long term. An adjustment of the functionality of the CPPS e.g. due to new product variants can be implemented quickly and easily by exchanging subsystems. At this point, since each subsystem in the CPPS is managed by its own CPS, it is helpful to assign to each controller which functionalities it has to assume and what types of sensors and actuators it has to control, as exemplarily pictured in Fig. 3. This allows to identify which task will be handled by which CPS and which actuators and sensors are available.
Fig. 3. Assignment of actuators and sensors to CPS (excerpt) After the subsystems have been identified, they also must be modeled. The interfaces to the rest of the CPPS have to be specified by defining at least the offered functionality (executable functions and expected input and output) as well as the externally retrievable attributes (e.g. process and master data). The sum of these attributes for all the relevant controllers results in the common information model of the CPPS. Here, the widespread service-oriented architecture approach from computer science is transferred to CPPS. Loosely coupled subsystems together form the CPPS. Unlike previous approaches for developing monolithic production systems, the functionality is ensured by the fact that many individual building blocks (subsystems controlled by their own CPS) are assembled due to clearly defined and compatible interfaces.
For modeling the processes on this still high abstraction level, UML activity diagrams or BPMN charts can be used. Since CPPS are highly autonomous systems, the regular production process as well as all the processes for error handling should be modelled. Subsequently, exchanged information and physical objects between the CPS can be read off from the modeled processes and structure. An identified information exchange must be further specified regarding the exchanged content, e.g. in a source-sink chart. This specification include which attributes between which objects are exchanged and with which protocol.
The result of these first two phases is a concept or a model of the future production system which takes the objectives and requirements into account as far as possible, identifies interdisciplinary dependencies and defines subsystems as well as their interfaces. As a consequence, the modularity of the CPPS is guaranteed and a simultaneous work is possible in the next phase. 4.2 3rd Phase: Detailed design of the subsystems
The steps of the 2nd phase are quite the same as the 1st phase. However, they do not refer to the entire CPPS but deepen the identified subsystems. Subsystems or modules distinguish themselves from the rest of the system by having fewer but clearly defined interfaces with other areas. Therefore, they can be developed nearly independently. It’s a repeating and deepening process that only ends when the desired granularity is reached. The finest level is a modularity on the field device level where each field device is independently controlled and embedded in the CPPS.
The 3rd phase corresponds to the parallel and disciplinespecific deepening of each CPS module as individual building blocks of the CPPS. The design tasks for the four disciplines (mechanics, electronics, software and useware) as described in the following paragraphs must be processed for each CPS module and focus on their input, output and function. The main goal of the mechanical design is the realization of a 3D CAD model of the subsystem. The first task is the design of the basic structure considering the dimension, automatibility and mobility requirements. This task must allow the mechanical reconfiguration of the CPPS e.g. by adding or removing the subsystem. The mechanical interfaces with the human, e.g. manual-workig place or end devices, 96
2017 IFAC IMS December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
also must be taken into account here and have to be planned along with the useware design activities. Also the interface for power and network supply must be taken into account and planned along with the electronic design tasks. The definition of the material flow direction, the transport system as well as the transfer points of the products further allows the planning of the the coupling points of the module in the 3D model. The last step of the mechanical design consists in the selection of the actuators and sensors by suppliers and their planning in the 3D model. By this selection, the functionalities of the subsystem are being deepened.
89
must include all variables which are relevant for monitoring and controlling the module. The communication between middleware and IT systems can take place via protocols such as MQTT, SOAP or RESTful web services. The first activity of the useware design is the conversion of the requirements of the use context into a hardwareindependent use model, e.g. with useML. This model describes the user interaction with the module in an abstract form, detached from the realization. It provides an interface between the user tasks and the module functionality and is the basis for the concrete preparation of the operating system (Zühlke 2012). In a further step, the physical human-machine interfaces must be planned along with the mechanical and electrical design activities. To display relevant information for the user, the module needs to access the digital image of the product (assembly instructions, bill of materials, 3D models), which must be made available by the IT systems. Subsequently, the planning of the software platform for the useware devices must be planned along with the software design activities. The last step of the useware design consists in the adaptation of the use model to the requirements and characteristics of the hardware and software platforms and its conversion into a rough concept. Typical tasks here are the development of menu structures, interaction objects and dialogues as well as the design of mock-ups, wireframes or executable program versions.
The electronical design begins with the listing of all the actuators and sensors of the subsystem as well as their connections. Thanks to this list, the type and number of connections between the components to be controlled and the controller can be documented and the electronical hardware can be selected. Microcontrollers or embedded systems are used here for their ability to network and control. In a next step, the Plug'n'Produce capability of the subsystem must be realized on the electrical level. Here, a universal connector for power supply and networking can be used. It connects the CPS module to the modular infrastructure supplying the CPPS e.g. with compressed air, power, industrial Ethernet and security loop as described in (Weyer et al. 2017). Subsequently, the electrical interface to other systems and subsystems must be planned. The detection of adjacent modules may be performed by an RFID system implemented at each connection point of the module. Proximity sensors can additionally ensure the presence of a neighboring module. When all components to be controlled and their connections have been determined, the circuit documents as well as the electronic layout of the module can be mapped.
4.3 4th and 5th Phase: Integration The two last phases will be briefly outlined in this paper, as it mainly focusses on the design part of the methodology. They provide the functionality of the CPPS by bringing the individual modules together and integrating them into the existing production environment. The 4th phase firstly consists in assembling the individual digital models of the modules in order to virtually test the whole CPPS. Here, the use of a PLM software to simulate, visualize, analyze and optimize the material flow or production tasks is recommended. The resulting digital image of the CPPS may later allow the continuous planning, evaluation and control of its production processes. If the virtual tests are satisfying, the real CPPS can be mechanically assembled and electrically wired. The 5th phase consist in the final integration. Typical tasks here are the connection of the CPPS to the supply infrastructure and the implementation of the software. This last activity means the vertical and horizontal integration of the CPPS through the harmonization of the interfaces between the modules and with the existing environment.
The software design must take into account the existing network topology and used communication protocols of the factory. The information model is used here for identification, interpretation of the CPPS structure and IT connection. An individual IP addresse must be assigned to each networked device in order to allow its connection to the network via a TCP/IP-compatible interface, allowing an access to individual services. The subsequent activities are subdivided into the planning of the horizontal and vertical integrations of the module. The first one relates to the intra and inter-company networking with other production resources. Here, the connection can happen via a middleware interconnecting all subsystems. An alternative is the use of common Internet approaches like stateless services with publish-subscribe functionality allowing the logical control of the production process on the shop floor level. The vertical integration concerns the intra- and inter-company connection to the higher level IT systems. To this end, the previously mentioned middleware can acquire the module data in real time, store them and provide them to the IT systems. It takes over the logical data integration and manages the bidirectional read and write access according to the access rights. Hence, it allows both the exchange of data and status messages as well as the exchange of control commands. For this purpose, it disposes of a single communication protocol, e.g. OPC UA or MQTT, to access the information of the module and the information model. The information model
5. SUMMARY AND OUTLOOK First architectures for CPS-based changeable production systems already exist. However, adapted design methodologies still lack in the literature. To guide the engineers throughout the complex CPPS engineering process, this paper proposes a five-phase procedural model and recommends tools and modeling languages to support it. As a proof of concept, the presented methodology has been successfully applied in the construction of a demonstrator at 97
2017 IFAC IMS 90 December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
the living lab SmartFactoryKL. Furthermore, work is already ongoing to extend it. In particular, more agility must be brought into the engineering process in order to make it more flexible and enable a quick reactivity of the CPPS on changing requirements. A combination of a Lean Engineering approach for automated solutions as described in (Takeda 2006) with agile methods and multiagent systems paradigms from the field of software engineering sounds promising.
Lee,
E.A. (2008). Cyber Physical Systems: Design Challenges. 2008 11th IEEE International Symposium on Object Oriented Real-Time Distributed Computing (ISORC), 363–369. Lee, E.A., Seshia, S.A. (2011). Introduction to Embedded Systems: A Cyber-Physical Systems Approach. LeeSeshia.org. Nyhuis, P., Reinhart, G., Abele, E. Wandlungsfähige Produktionssysteme: Heute die Industrie von morgen gestalten. PZH Produktionstechnisches Zentrum GmbH. Pirvu, B.C., Zamfirescu, C.B., Gorecky, D. (2015). Engineering insights from an anthropocentric cyberphysical system. A case study for an assembly station. Mechatronics. System-Integrated Intelligence: New Challenges for Product and Production Engineering, 147-159. Scheer, A.-W. (2002): ARIS - Vom Geschäftsprozess zum Anwendungssystem. Schuh, G., Lenders, M., Nussbaum, C., Kupke, D. (2009). Design for Changeability. In ElMaraghy, H.A. (ed.), Changeable and Reconfigurable Manufacturing Systems, 251-266. Springer, London. Slomka, F., Kollmann, S., Moser, S., Kempf, K. (2011). A Multidisciplinary Design Methodology for Cyberphysical Systems. 11th IEEE Symposium on Object Oriented Real-Time Distributed Computing ISORC. Takeda, H. (2006). LCIA – Low Cost Intelligent Automation. mi-Fachverlag, Landsberg am Lech. Yamazaki, Y., Takata, S., Onari, H., Kojima, F., Kato, S. (2016). Lean Automation System Responding to the Changing Market. 49th CIRP Conference on Manufacturing Systems. Weber, J., Förster, D., Kößler, J., Paetzold, K. (2015). Design of changeable production units within the automotive sector with Axiomatic Design. 9th International Conference on Axiomatic Design. Weber, J., Stäbler, M., Thielen, S., Paetzold, K. (2016). Modularity as Key Enabler for Scalability of Final Assemble Units in the Automotive Sector. 49th CIRP Conference on Manufacturing Systems. Weyer, S., Quint, F., Fischer, S., Gorecky, D. (2016). Individualisierte Kleinserienfertigung. In Reinhart, G. (ed.), Handbuch Industrie 4.0. Hanser Verlag, München. Wiendhal, H.P. (2009). Wandlungsfähigkeit: Schlüsselbegriff der zukunftfähigen Fabrik. wt Werkstatttechnik online, 92(4), 122-127. Zühlke, D. (2010). SmartFactory - Towards a Factory-ofThings. IFAC annual Reviews in control, 34. 129–138. Zühlke, D. (2012). Nutzergerechte Entwicklung von MenschMaschine-Systemen: Useware-Engineering für technische Systeme. Springer, Berlin.
REFERENCES Bauernhansl, T. (2014). Die Vierte Industrielle Revolution. Der Weg in ein wertschaffendes Produktionsparadigma. In Bauernhansl, T., ten Hompel, M., Vogel-Heuser, B. (ed.), Industrie 4.0 in Produktion, Automatisierung und Logistik. Anwendung, Technologien und Migration, 5– 35. Springer Vieweg, Wiesbaden. Bergweiler, S. (2015). Intelligent Manufacturing based on Self-Monitoring Cyber-Physical Systems. The Ninth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies. Bleek, W., Wolf, H. (2008). Agile Softwareentwicklung: Werte, Konzepte und Methoden. Dpunkt, Heidelberg. Broy, M. (2010). Cyber-Physical Systems. Innovation durch softwareintensive eingebettete Systeme. Springer, Berlin. Eigner, M. (2014). Überblick Disziplin-spezifische und übergreifende Vorgehensmodelle. In Eigner, M. (ed), Modellbasierte Virtuelle Produktentwicklung, 15-51. Springer, Heidelberg. Eigner, M. (2014b). Modell Based Systems Engineering auf einer Plattform für PLM. In Stelzer, R. (ed), Entwickeln – Entwerfen – Erleben. Beiträge zur Virtuellen Produktentwicklung und Konstruktionstechnik, 39-56. Verlag der Wissenschaften GmbH, Dresden. Francalanza, E. Borg, J., Constantinescu, C. (2014). Deriving a systematic approach to changeable manufacturing system design. Proceedings of the 47th CIRP Conference on Manufacturing Systems. Hu, L., Xie, N., Kuang, Z., Zhao, K. (2012). Review of Cyber-Physical System Architecture. IEEE 15th International Symposium on Object/Component/ServiceOriented Real-Time Distributed Computing Workshops ISORCW, 25–30. Kolberg, D., Berger, C., Pirvu, B.C., Franke, M., Michniewicz, J. (2016). CyProF - Insights from a Framework for Designing Cyber-Physical Systems in Production Environments. 49th CIRP Conference on Manufacturing Systems. Kolberg, D., Zühlke, D. (2015). Lean Automation enabled by Industry 4.0 Technologies. In Alexander Dolgui, Jurek Sasiadek und Marek Zaremba (ed.), 15th IFAC Symposium on Information Control Problems in Manufacturing INCOM 2015, 1870–1875. IFACPapersOnLine Elsevier. Kolditz, J. (2009). Vorgehensmodell zur Erstellung von Fachkonzepten für selbststeuernde produktionslogistische Prozesse. GITO Verlag, Berlin. La, H.J., Kim, S.D. (2010). A Service-Based Approach to Designing Cyber Physical Systems. 2010 IEEE/ACIS 9th International Conference on Computer and Information Science (ICIS), 895–900. 98
ScienceDirect IFAC-PapersOnLine 49-31 (2016) 85–90
Interdisciplinary Engineering Methodology for changeable Cyber-Physical Interdisciplinary Engineering Methodology for changeable Cyber-Physical Interdisciplinary Methodology for Interdisciplinary Engineering Engineering Methodology for changeable changeable Cyber-Physical Cyber-Physical Production Systems Production Systems Production Systems Production Systems
E. Marseu*, D. Kolberg*, E. Marseu*, Marseu*, D. Kolberg*, E. Birtel* , D. D. Kolberg*, Zühlke* E.M. Marseu*, M. Birtel* ,, D. D. Kolberg*, Zühlke* M. Birtel* D. M. Birtel* , D. Zühlke* Zühlke* , German Research Center for Artificial Intelligence (DFKI), Trippstadter Strasse 122, 67663 * SmartFactoryKL , German Research Center for Artificial Intelligence (DFKI), Trippstadter Strasse 122, 67663 * SmartFactory SmartFactoryKL KL KL Germany (e-mail: [email protected]) KL, GermanKaiserslautern, Research for Intelligence (DFKI), * Research Center Center for Artificial Artificial Intelligence (DFKI), Trippstadter Trippstadter Strasse Strasse 122, 122, 67663 67663 * SmartFactory , GermanKaiserslautern, Germany (e-mail: [email protected]) Kaiserslautern, Germany (e-mail: [email protected]) Kaiserslautern, Germany (e-mail: [email protected]) Abstract: Fluctuating market demands and increasing demand for customized products require reactive Abstract: Fluctuating market demands and increasingSystems demand(CPPS) for customized products requireofreactive reactive production Fluctuating environments. Cyber-Physical Production describe products the integration CyberAbstract: market demands increasing demand for require Abstract: Fluctuating market demands and and increasingSystems demand(CPPS) for customized customized products requireof reactive production environments. Cyber-Physical Production describe the integration CyberPhysical Systems (CPSs) in production systems in order to enhance their changeability by production environments. Cyber-Physical Production Systems (CPPS) describe the integration of Cyberproduction environments. Cyber-Physical Production Systems (CPPS) describe the integration of CyberPhysical Systems (CPSs) in production production systemschangeable, in order order to also enhance their changeability by modularization. Production systems thereby become but more complex. There is only Physical Systems (CPSs) in systems in to enhance their changeability by Physical Systems (CPSs) systems in production systemschangeable, in order but to also enhance their changeability by modularization. Production thereby become become more complex. There is only only little experienceProduction in engineering modular CPS-based systemsbut foralso themore production. An adequate modularization. systems thereby changeable, complex. There is modularization. Production systems thereby become changeable, but also more complex. There is only little experience in engineering modular CPS-based systems for the design production. An adequate adequate little in modular CPS-based systems for production. An methodology can provide a guideline and support engineers in the complex process. this little experience experience in engineering engineering modular CPS-based systems for the the design production. AnHence, adequate methodology can provide a guideline guideline and support support engineers in modular the complex complex process. Hence, this methodology can provide a and engineers in the design process. Hence, this paper proposes an interdisciplinar methodology for engineering CPPS. methodology can provide a guideline and support engineers in modular the complex design process. Hence, this paper proposes an interdisciplinar methodology for engineering CPPS. paper proposes an methodology for engineering modular CPPS. paper proposes an interdisciplinar interdisciplinar methodology forCyber-Physical engineering modular CPPS. © 2016, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Keywords: Interdisciplinary design; Modularity; System; Production System; Systems Keywords: Interdisciplinary design; Modularity; Cyber-Physical System; Production System; System; Systems Systems Engineering Keywords: Interdisciplinary design; Modularity; Cyber-Physical System; Production Keywords: Interdisciplinary design; Modularity; Cyber-Physical System; Production System; Systems Engineering Engineering Engineering
1. INTRODUCTION 1. 1. INTRODUCTION INTRODUCTION INTRODUCTION Globalized markets 1.require companies to produce variable Globalized markets require companies produce variable and customized product ranges in short to and with low Globalized markets require companies to produce variable Globalized markets require companies toterm produce variable and customized product ranges in short term and with low costs (Bauernhansl 2014). The design, assembly and and customized product ranges in short term and with and customized product rangesThe in short termassembly and with low low costs (Bauernhansl 2014). design, and costs (Bauernhansl 2014). The design, assembly and commissioning from special-purpose production machines to costs (Bauernhansl 2014). The design, assembly and commissioning from special-purpose production machines to commissioning from special-purpose production machines to answer to customized demands is an expensive and timecommissioning from special-purpose production machines to answer to customized demands is an expensive and timeanswer to customized demands is an expensive and timeconsuming task since existing solutions can hardly be reused. answer to customized demands is an expensive and timeconsuming since existing solutions can hardlyproducts be reused. To satisfy task the demand for highly customized in consuming task since solutions can be consuming task since existing existing solutions can hardly hardlyproducts be reused. reused. To satisfy the demand for highly customized in shortest lead time and lower costs, production systems must To satisfy the demand for highly customized products in To satisfy the demand for highly customizedsystems products in shortest lead time and lower costs, production must be highly changeable. shortest lead time and lower costs, production systems must shortest lead time and lower costs, production systems must be highly changeable. be highly changeable. be highly changeable. In the literature, changeability marks the potential to adapt to In the literature, changeability the potential to adapt to changing requirements in a marks reactive or proactive way In the literature, changeability marks the to to In the literature, changeability marks the potential potential to adapt adapt to changing requirements in a reactive or proactive way (Wiendhal 2002). In constrast to flexibility, changeability changing requirements in a reactive or proactive way changing requirements in a reactive or proactive way (Wiendhal 2002). In constrast to flexibility, changeability (Wiendhal 2002). constrast to allows to perform outsidechangeability predefined (Wiendhal 2002). In Innecessary constrast changes to flexibility, flexibility, changeability allows to perform necessary changes outside predefined allows to perform necessary changes outside predefined requirements corridors (Nyhuis 2006). On the physical level, allows to perform necessary changesOnoutside predefined requirements corridors (Nyhuis 2006). the physical level, production systems must be highly reactive and requirements corridors (Nyhuis 2006). On the physical level, requirements corridors (Nyhuis 2006). On the physical level, production systems must be highly reactive and reconfigurable, allowing changeable functionalities production systems must be highly reactive production systems must be highly reactive and and reconfigurable, allowing changeable functionalities and scalable capacities by adding, removing or modifying reconfigurable, allowing changeable functionalities and reconfigurable, allowing changeable functionalities and scalable capacities by adding, removing or modifying modules. On the logical level, the operating IT systems have scalable capacities by adding, removing or modifying scalable capacities by adding, removing or modifying modules. On the logical level, the operating IT systems have to be changeable as well in order to support the physical modules. On level, the IT have modules. On the the logical logical level, the operating operating IT systems systems have to be changeable as well in order to support the physical changes. Additionally, a control loop must monitor change to be changeable as well in order to support the physical to be changeable as well in order to support the physical changes. Additionally, control loop on must monitor change changes. Additionally, aaa control loop must monitor change drivers and trigger change activities both physical and changes. Additionally, control loop on must monitor change drivers and trigger change activities both physical and drivers and trigger change activities on both physical logical levels. drivers and trigger change activities on both physical and and logical levels. logical levels. logical levels. Combining logical level, physical level and control loop into Combining logical level, physical level and control loop into single modules a production system leads Combining logical level, level control loop into Combining logicalwithin level, physical physical level and and control loopto intoaa single modules within a production system leads to distributed system, enabling a higher changeability to react single modules within a production system leads to single modules within a production system leads to aa distributed system, enabling aa higher changeability to react on unforeseen changing market demands. These individual distributed system, enabling higher changeability to react distributed system, enabling a higher changeability to react on unforeseen demands. These individual modules followchanging the ideamarket of autonomous subsystems with on unforeseen changing market demands. These individual on unforeseen changing market demands. These individual modules follow the idea of autonomous subsystems with standardized interfaces designed to ensure inter-changeability modules follow the idea of autonomous subsystems modules follow the idea of autonomous subsystems with with standardized interfaces designed to paradigm, ensure inter-changeability inter-changeability standardized interfaces designed to ensure with little efforts. This known as standardized interfaces designed to paradigm, ensure inter-changeability with little efforts. This known as with little efforts. This paradigm, known as „Plug´n´Produce“, describes the idea of a modular production with little efforts. This paradigm, known as „Plug´n´Produce“, describes the idea of a modular production „Plug´n´Produce“, describes the idea of a modular production system. Like LEGO bricks, production systems are „Plug´n´Produce“, describes the idea of a modular production system. Like LEGO bricks, production systems are assembled by putting system. Like LEGO bricks, production systems are system. Like LEGO together bricks, compatible production modules systems with are assembled by putting together compatible modules with assembled by putting together compatible modules with assembled by putting together compatible modules with
different functionalities. To allow this, production modules different functionalities. To allow this, production modules different functionalities. To allow this, modules have to become smart. A as well as a different functionalities. Tocertain allow intelligence this, production production modules have to become smart. A certain intelligence as well as aa have to become smart. A certain intelligence as well unified communication interface and self-configuration have to become smart. A interface certain intelligence as well as as a unified communication and self-configuration unified communication interface self-configuration abilities are required. (Zühlke 2010) and unified communication interface and self-configuration abilities are (Zühlke abilities are required. required. (Zühlke 2010) 2010) abilities required. (Weyer are et al. 2017) (Zühlke already 2010) described an approach for a (Weyer et al. 2017) already described an approach for aa production line following those paradigms. although (Weyer et al. 2017) already described an approach for (Weyer et line al. 2017) already described anBut approach forthe a production following those paradigms. But although the vision of modular production systems hasBut become clearer production line following those paradigms. although the production line following those paradigms. But although the vision of modular production systems has become now, their engineering is still challenging. To clearer allow vision of production systems has clearer vision of modular modular production systems has become become clearer now, their engineering is still challenging. To allow changeability and Plug´n´Produce abilities, production now, their engineering is still challenging. To now, their engineering is still challenging. To allow allow changeability and Plug´n´Produce abilities, production changeability and Plug´n´Produce abilities, production systems must be designed in a new way where the modules changeability and Plug´n´Produce abilities, production systems must be designed in a new way where the modules systems must designed in aa new way the are considered individual described by their systems must be beas designed in black newboxes way where where the modules modules are considered as individual black boxes described by their are considered as individual black boxes described by functionalities and attributes, composing a whole system and are considered and as individual black boxesa described by their their functionalities attributes, composing whole system and following the paradigm of object-orientation. These functionalities and attributes, composing a whole system and functionalities andparadigm attributes, composing a whole system and following the of object-orientation. These autonomous modules represent individual mechatronical following the paradigm of object-orientation. These following the paradigm of object-orientation. These autonomous modules represent individual mechatronical systems, combining components with mechanical and autonomous modules represent individual mechatronical autonomous modulesIT represent individual mechatronical systems, combining IT components with mechanical and electronical parts. After a review of current approaches to systems, combining IT components with mechanical and systems, combining IT acomponents with mechanical and electronical parts. After review of current approaches to enhance changeability in production environments as well as electronical parts. After a review of current approaches to electronical parts. After aproduction review ofenvironments current approaches to enhance changeability in as well well as as enhance changeability in production environments as existing engineering approaches, this paper presents a enhance changeability in production environments as well as existing engineering approaches, this paper presents aa existing engineering approaches, this paper presents procedural model for engineering CPPS which considers existing engineering approaches, this paper presents a procedural model for engineering CPPS which considers procedural model for CPPS which considers interdisciplinary work asengineering well as modularization. procedural model for engineering CPPS which considers interdisciplinary work as well as modularization. interdisciplinary interdisciplinary work work as as well well as as modularization. modularization. 2. CURRENT APPROACHES TO ENHANCE 2. CURRENT APPROACHES TO ENHANCE CHANGEABILITY BY USING CPS 2. APPROACHES TO 2. CURRENT CURRENT APPROACHES TO ENHANCE ENHANCE CHANGEABILITY BY USING CPS CHANGEABILITY BY USING CPS BY USING CPS to enhance CPS can beCHANGEABILITY considered as a key technology CPS can be considered as a key technology to enhance changeability by modularization (Bauernhansl 2014). CPS can as to CPS can be be considered considered as aa key key technology technology to enhance enhance changeability by modularization (Bauernhansl 2014). Powerful but still affordable microcontrollers with connected changeability by modularization (Bauernhansl 2014). changeability byaffordable modularization (Bauernhansl 2014). Powerful but still microcontrollers with connected Powerful but still affordable microcontrollers with connected sensors and actuators are able to interact with their Powerful but still affordable microcontrollers with connected sensors and actuators are able to interact with their sensors and actuators are able to interact with their environment. By using wide-spread communication protocols sensors and By actuators are able communication to interact with their environment. using wide-spread protocols environment. By using wide-spread communication protocols like the internet protocol, they are able to communicate with environment. By using wide-spread communication protocols like the internet protocol, they are able to communicate with other entities within their environment. As a result, CPS can like the internet protocol, they are able to communicate with like the internet protocol, they are able to communicate with other entities within their environment. As a result, CPS can work autonomously and provide features like selfother entities within their environment. As a result, CPS can other entities within their environment. As a result,like CPSselfcan work autonomously and provide features configuration to seamlessly integrate into existing work autonomously and provide features like selfwork autonomously and provide features like selfconfiguration to seamlessly integrate into existing environments. (Lee Broy 2010) configuration to seamlessly integrate configuration to 2008, seamlessly integrate into into existing existing environments. (Lee 2008, Broy 2010) environments. (Lee 2008, Broy 2010) environments. (Lee 2008, Broy 2010)
2405-8963 © 2016 2016, IFAC IFAC (International Federation of Automatic Control) Copyright@ 93 Hosting by Elsevier Ltd. All rights reserved. Peer review under IFAC responsibility of International Federation of Automatic Control. Copyright@ 93 Copyright@ 2016 2016 IFAC 93 Copyright@ 2016 IFAC 93 10.1016/j.ifacol.2016.12.166
2017 IFAC IMS 86 December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
First architectures for applying CPS in production already exist. (Pirvu et al. 2015) describe an anthropocentric approach for the integration of CPS in the context of machines and humans. Although they highlighted the need for adapters between entities to realize interoperability, they stay on an abstract level and do not deepen these adapters. (Kolberg et al. 2016) presents a framework consisting of an architecture, modeling methodology and procedural model. In their approach they define seven CPS-based entities as well as building bricks to deepen the modeling. The procedural model describes a step-by-step instruction to identify and model use cases for CPS in production, but does not consider modularization. Furthermore, (Kolberg and Zühlke 2015) describe an approach for using CPS as a retrofitting component to digitize working stations in Lean Production. Similar, (Bergweiler 2015) applies CPS on field devices for self-monitoring. Other approaches and architectures for CPS in production are based on serviceoriented architectures and agent-based systems as mentioned in (La and Kim 2010) or (Hu et al. 2012).
Fig. 1. General system architecture for modular production systems (Weyer et al. 2017) 3. REVIEW OF EXISTING ENGINEERING APPROACHES In his work, (Eigner 2014) proposes a comprehensive review of discipline-specific methodologies, including the fields of mechanical, electronical and software engineering. In mechanical engineering, modularization is being considered in the early design phase where the solutions are divided into single modules, resulting in a modular structure. It can thereby be distinguished between assembly modules which enable an assembly friendly product design and variation modules which enable a structure made of building blocks. Thus, the construction ramifies into a parallel development of assemblies and individual parts. In software engineering, modularization is focused within object oriented approaches and multiagent systems design paradigms. They support emergent behaviors, reconfigurability and Plug´n´Produce abilities. This discipline additionally proposes agile methods like Scrum or Kanban in order to master the complexity induced by software development lifecycles (Bleek et al. 2008). (Eigner 2014) doensn´t mention any methodology for the design of usable systems. However, as the useware engineering is taking a growing place next to the hardware and software engineering within the design of production systems, adequate methodologies are exemplarily described in (Zühlke 2012) and by the norm DIN EN-ISO 9241-210.
Besides these research-driven approaches, there is also an approach for a highly modular, CPS-based architecture for production lines. This approach, as described in (Weyer et al. 2017), was developed at the living lab SmartFactoryKL by research and industry partners from the area of automation. The architecture is divided into the product, production, supply, integration and IT layers (Fig.1). By separating these layers from each other, interdependencies are prevented. Still, standardized communication protocols and information models allow a connection between them and enable the read/write access from the IT-systems on the production processes. The production layer consists of process components with standardized interfaces, bundling production functionalities and composing autonomous Plug´n´Produce modules individually controlled by their own PLC or CPS. Each node of the supply layer supplies one or several production modules with energy and industrial Ethernet via a single standardized connector. In this architecture, each production module represents a black box encapsulating functionalities and attributes, which can be connected to surrounding systems like other CPS-moduels or IT-systems and interact with them via standardized interfaces. In the framework of this paper, an autonomous production module controlled by its own PLC is called a CPS-module. Hence, a CPPS is defined as a modular distributed production system composed of several CPSmodules.
The mentioned methodologies all offer powerful disciplinespecific engineering processes, methods and tools. However, today's products are increasingly composed of software and embedded electronics, leading to a paradigm shift from products to open systems that exchange data and must be integrated in their environment. These systems, e.g. CPS, are becoming complex, highly networked and multidisciplinary (Broy 2010). Hence, (Eigner 2014) further reviews intersciplinary methodologies from the fields of mechatronics and Systems Engineering. He further presents the ModelBased Systems Engineering (MBSE) as an evolution of the classical document-based Systems Engineering. This approach enables a collaboration between the disciplines involved and the development phases through centrally available digital models. The V-model for MBSE is further described in (Eigner 2014b). Other contributions for the engineering of CPS-based solutions to be find in the literature
Engineering CPPS is a complicated task. The involvement of several disciplines as well as the difficulties arising from changeability requirements, distributed control and sophisticated interactions set new challenges to their design and integration. Many of the existing classical ways of engineering systems do not fit these paradigms. Additionally, as new production systems must allow an ergonomic humanmachine interaction, the engineering process must further take the usability of the CPPS into account through the integration of user-friendly machine operating systems (Zühlke 2012).
94
2017 IFAC IMS December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
87
mainly define development principles for their own application fields. Exemplarily, (Lee and Seshia 2011) handle the development of CPS in relation to their properties as embedded systems and particularly focus on hardware components and logical aspects of the system design. For embedded systems, (Slomka et al. 2011) further suggest the merging of a software development methodology with a platform-based design for coupling the physical and digital worlds and intergating various subsystems. Current approaches are mainly proposing classical top-down hierarchical design methodologies which require time to describe all behaviours of the system and don´t let room to highly reactives and self-X properties. Furthermore, little contributions in the literature propose approaches for engineering changeable production systems. Exemplarily, (Weber et al. 2016) focus on the function-based modularization of production systems using the axiomatic design (AD), which is further described in (Weber et al. 2015), to achieve maximum changeabilty. The approach from (Francalanza et al. 2014) for changeable production systems is based on the object-oriented method, which is further described in (Schuh et al. 2009). As for (Yamazaki et al. 2016), they apply Lean paradigms in their approach for the development of automated systems and consider changeability as a consequence of Lean Engineering. These methodologies for changeable production systems mainly concern the mechanical parts of the systems and focus on the modularization of the hardware side whithout in-depth consideration of the software side. Although they allow a modular engineering for mechanically reconfigurable production systems, they do not consider the need for reactive properties, the distribution of control tasks, the interaction with third party systems or the integration of the useware.
Fig. 2. Procedural model for Engineering CPPS The model considers multiple levels of abstraction. Consequently, the CPPS is divided into the system, subsystem and component levels. In the 1st phase, the whole system is abstracted and divided into subsystems. An interdisciplinary and model-based description of the CPPS is created on a high abstraction level. On a lower abstraction level, in phase 2, the modularity and the division of the CPPS into subsystems is considered and the interfaces of the CPSmodules are defined. On a third abstraction level, in phase 3, each module is defined more precisely according to its future functions. The phases 4 and 5 represent the integration of the system and merge the results from phases 1 to 3 by putting together the individual modules of the CPPS and hamonising the interfaces between them and with their environment. The individual phases are further divided into multiple steps, whereby discipline-specific methods and tools are to be used. The output of each phase consitutes the input of the following phase. Especially the phases 1, 2 and 3 will be deepened in the following paragraphs.
4. APPROACH FOR A METHODOLOGY FOR ENGINEERING CPPS The presented methodology takes into account the previously mentioned requirements for engineering CPPS. To reduce the complexity resulting from the engineering of these systems, the development is carried out through a structured fivephase procedural model, subdividing the design process into manageable and limited phases. However, the transitions between the different levels happen seamlessly. The resulting procedural model is illustrated in Fig. 2. and includes the design and integration of the CPPS. Predefined goals and requirements form the input and must take the current situation of the production environment into account. The final result is a test-ready CPPS.
4.1 1st and 2nd Phase: Design of the system and its subsystems The initiation phase includes the predefined goals of the project, building the basis for all design activities. The aim of the 1st phase is the conceptual design of a comprehensive model of the CPPS, laying the fundament for a subsequently efficient implementation of the requirements. To this end, mechanical, electrical, software and useware engineers must be involved. The comprehensive system design must include the processes, the system structure as well as a classification of the functionalities. A special focus should lie on the interfaces within the system and the interfaces with the system environment. This concerns exchanged information between control systems on the one hand and streams of physical objects between the different modules on the other hand. For the modeling, existing computer science methods like UML or SysML can be used. Established approaches for the modeling of distributed controlled production environments like ALEM-P (Kolditz 2009) or CyProF
95
2017 IFAC IMS 88 December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
(Kolberg et al. 2016) start with modeling the functions and goals e.g. in a use-case diagram. In two separated next steps, the structure and the process can be modelled. Approaches like ARIS (Scheer 2002) or CyProF recommend to model the process first in order to stronger focus on the processes which are needed to generate an added value or to produce the final product. Approaches like ALEM-P start with the structure, which is more intuitive for the project members. In order to model the structure, relevant physical or digital objects for the CPPS have to be identified and dependencies between these objects must be highlighted. Here, one can make use of UML´s structure diagrams or of SysML´s block diagram. In order to deepen the subsystems any further in the next phases and realize the modularity, it must be decided which subsystems will compose the CPPS and especially what functionalities they will take over. Considering the changeability of a CPPS, a function-oriented approach is recommended. This approach assigns single process steps with similar results, e.g. with similar inputs and outputs, to one group, which must further be taken over by a subsystem. Although components can be redundant in order to ensure modularity, it may be profitable in the long term. An adjustment of the functionality of the CPPS e.g. due to new product variants can be implemented quickly and easily by exchanging subsystems. At this point, since each subsystem in the CPPS is managed by its own CPS, it is helpful to assign to each controller which functionalities it has to assume and what types of sensors and actuators it has to control, as exemplarily pictured in Fig. 3. This allows to identify which task will be handled by which CPS and which actuators and sensors are available.
Fig. 3. Assignment of actuators and sensors to CPS (excerpt) After the subsystems have been identified, they also must be modeled. The interfaces to the rest of the CPPS have to be specified by defining at least the offered functionality (executable functions and expected input and output) as well as the externally retrievable attributes (e.g. process and master data). The sum of these attributes for all the relevant controllers results in the common information model of the CPPS. Here, the widespread service-oriented architecture approach from computer science is transferred to CPPS. Loosely coupled subsystems together form the CPPS. Unlike previous approaches for developing monolithic production systems, the functionality is ensured by the fact that many individual building blocks (subsystems controlled by their own CPS) are assembled due to clearly defined and compatible interfaces.
For modeling the processes on this still high abstraction level, UML activity diagrams or BPMN charts can be used. Since CPPS are highly autonomous systems, the regular production process as well as all the processes for error handling should be modelled. Subsequently, exchanged information and physical objects between the CPS can be read off from the modeled processes and structure. An identified information exchange must be further specified regarding the exchanged content, e.g. in a source-sink chart. This specification include which attributes between which objects are exchanged and with which protocol.
The result of these first two phases is a concept or a model of the future production system which takes the objectives and requirements into account as far as possible, identifies interdisciplinary dependencies and defines subsystems as well as their interfaces. As a consequence, the modularity of the CPPS is guaranteed and a simultaneous work is possible in the next phase. 4.2 3rd Phase: Detailed design of the subsystems
The steps of the 2nd phase are quite the same as the 1st phase. However, they do not refer to the entire CPPS but deepen the identified subsystems. Subsystems or modules distinguish themselves from the rest of the system by having fewer but clearly defined interfaces with other areas. Therefore, they can be developed nearly independently. It’s a repeating and deepening process that only ends when the desired granularity is reached. The finest level is a modularity on the field device level where each field device is independently controlled and embedded in the CPPS.
The 3rd phase corresponds to the parallel and disciplinespecific deepening of each CPS module as individual building blocks of the CPPS. The design tasks for the four disciplines (mechanics, electronics, software and useware) as described in the following paragraphs must be processed for each CPS module and focus on their input, output and function. The main goal of the mechanical design is the realization of a 3D CAD model of the subsystem. The first task is the design of the basic structure considering the dimension, automatibility and mobility requirements. This task must allow the mechanical reconfiguration of the CPPS e.g. by adding or removing the subsystem. The mechanical interfaces with the human, e.g. manual-workig place or end devices, 96
2017 IFAC IMS December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
also must be taken into account here and have to be planned along with the useware design activities. Also the interface for power and network supply must be taken into account and planned along with the electronic design tasks. The definition of the material flow direction, the transport system as well as the transfer points of the products further allows the planning of the the coupling points of the module in the 3D model. The last step of the mechanical design consists in the selection of the actuators and sensors by suppliers and their planning in the 3D model. By this selection, the functionalities of the subsystem are being deepened.
89
must include all variables which are relevant for monitoring and controlling the module. The communication between middleware and IT systems can take place via protocols such as MQTT, SOAP or RESTful web services. The first activity of the useware design is the conversion of the requirements of the use context into a hardwareindependent use model, e.g. with useML. This model describes the user interaction with the module in an abstract form, detached from the realization. It provides an interface between the user tasks and the module functionality and is the basis for the concrete preparation of the operating system (Zühlke 2012). In a further step, the physical human-machine interfaces must be planned along with the mechanical and electrical design activities. To display relevant information for the user, the module needs to access the digital image of the product (assembly instructions, bill of materials, 3D models), which must be made available by the IT systems. Subsequently, the planning of the software platform for the useware devices must be planned along with the software design activities. The last step of the useware design consists in the adaptation of the use model to the requirements and characteristics of the hardware and software platforms and its conversion into a rough concept. Typical tasks here are the development of menu structures, interaction objects and dialogues as well as the design of mock-ups, wireframes or executable program versions.
The electronical design begins with the listing of all the actuators and sensors of the subsystem as well as their connections. Thanks to this list, the type and number of connections between the components to be controlled and the controller can be documented and the electronical hardware can be selected. Microcontrollers or embedded systems are used here for their ability to network and control. In a next step, the Plug'n'Produce capability of the subsystem must be realized on the electrical level. Here, a universal connector for power supply and networking can be used. It connects the CPS module to the modular infrastructure supplying the CPPS e.g. with compressed air, power, industrial Ethernet and security loop as described in (Weyer et al. 2017). Subsequently, the electrical interface to other systems and subsystems must be planned. The detection of adjacent modules may be performed by an RFID system implemented at each connection point of the module. Proximity sensors can additionally ensure the presence of a neighboring module. When all components to be controlled and their connections have been determined, the circuit documents as well as the electronic layout of the module can be mapped.
4.3 4th and 5th Phase: Integration The two last phases will be briefly outlined in this paper, as it mainly focusses on the design part of the methodology. They provide the functionality of the CPPS by bringing the individual modules together and integrating them into the existing production environment. The 4th phase firstly consists in assembling the individual digital models of the modules in order to virtually test the whole CPPS. Here, the use of a PLM software to simulate, visualize, analyze and optimize the material flow or production tasks is recommended. The resulting digital image of the CPPS may later allow the continuous planning, evaluation and control of its production processes. If the virtual tests are satisfying, the real CPPS can be mechanically assembled and electrically wired. The 5th phase consist in the final integration. Typical tasks here are the connection of the CPPS to the supply infrastructure and the implementation of the software. This last activity means the vertical and horizontal integration of the CPPS through the harmonization of the interfaces between the modules and with the existing environment.
The software design must take into account the existing network topology and used communication protocols of the factory. The information model is used here for identification, interpretation of the CPPS structure and IT connection. An individual IP addresse must be assigned to each networked device in order to allow its connection to the network via a TCP/IP-compatible interface, allowing an access to individual services. The subsequent activities are subdivided into the planning of the horizontal and vertical integrations of the module. The first one relates to the intra and inter-company networking with other production resources. Here, the connection can happen via a middleware interconnecting all subsystems. An alternative is the use of common Internet approaches like stateless services with publish-subscribe functionality allowing the logical control of the production process on the shop floor level. The vertical integration concerns the intra- and inter-company connection to the higher level IT systems. To this end, the previously mentioned middleware can acquire the module data in real time, store them and provide them to the IT systems. It takes over the logical data integration and manages the bidirectional read and write access according to the access rights. Hence, it allows both the exchange of data and status messages as well as the exchange of control commands. For this purpose, it disposes of a single communication protocol, e.g. OPC UA or MQTT, to access the information of the module and the information model. The information model
5. SUMMARY AND OUTLOOK First architectures for CPS-based changeable production systems already exist. However, adapted design methodologies still lack in the literature. To guide the engineers throughout the complex CPPS engineering process, this paper proposes a five-phase procedural model and recommends tools and modeling languages to support it. As a proof of concept, the presented methodology has been successfully applied in the construction of a demonstrator at 97
2017 IFAC IMS 90 December 5-7, 2016. Austin, TX, USA
E. Marseu et al. / IFAC-PapersOnLine 49-31 (2016) 85–90
the living lab SmartFactoryKL. Furthermore, work is already ongoing to extend it. In particular, more agility must be brought into the engineering process in order to make it more flexible and enable a quick reactivity of the CPPS on changing requirements. A combination of a Lean Engineering approach for automated solutions as described in (Takeda 2006) with agile methods and multiagent systems paradigms from the field of software engineering sounds promising.
Lee,
E.A. (2008). Cyber Physical Systems: Design Challenges. 2008 11th IEEE International Symposium on Object Oriented Real-Time Distributed Computing (ISORC), 363–369. Lee, E.A., Seshia, S.A. (2011). Introduction to Embedded Systems: A Cyber-Physical Systems Approach. LeeSeshia.org. Nyhuis, P., Reinhart, G., Abele, E. Wandlungsfähige Produktionssysteme: Heute die Industrie von morgen gestalten. PZH Produktionstechnisches Zentrum GmbH. Pirvu, B.C., Zamfirescu, C.B., Gorecky, D. (2015). Engineering insights from an anthropocentric cyberphysical system. A case study for an assembly station. Mechatronics. System-Integrated Intelligence: New Challenges for Product and Production Engineering, 147-159. Scheer, A.-W. (2002): ARIS - Vom Geschäftsprozess zum Anwendungssystem. Schuh, G., Lenders, M., Nussbaum, C., Kupke, D. (2009). Design for Changeability. In ElMaraghy, H.A. (ed.), Changeable and Reconfigurable Manufacturing Systems, 251-266. Springer, London. Slomka, F., Kollmann, S., Moser, S., Kempf, K. (2011). A Multidisciplinary Design Methodology for Cyberphysical Systems. 11th IEEE Symposium on Object Oriented Real-Time Distributed Computing ISORC. Takeda, H. (2006). LCIA – Low Cost Intelligent Automation. mi-Fachverlag, Landsberg am Lech. Yamazaki, Y., Takata, S., Onari, H., Kojima, F., Kato, S. (2016). Lean Automation System Responding to the Changing Market. 49th CIRP Conference on Manufacturing Systems. Weber, J., Förster, D., Kößler, J., Paetzold, K. (2015). Design of changeable production units within the automotive sector with Axiomatic Design. 9th International Conference on Axiomatic Design. Weber, J., Stäbler, M., Thielen, S., Paetzold, K. (2016). Modularity as Key Enabler for Scalability of Final Assemble Units in the Automotive Sector. 49th CIRP Conference on Manufacturing Systems. Weyer, S., Quint, F., Fischer, S., Gorecky, D. (2016). Individualisierte Kleinserienfertigung. In Reinhart, G. (ed.), Handbuch Industrie 4.0. Hanser Verlag, München. Wiendhal, H.P. (2009). Wandlungsfähigkeit: Schlüsselbegriff der zukunftfähigen Fabrik. wt Werkstatttechnik online, 92(4), 122-127. Zühlke, D. (2010). SmartFactory - Towards a Factory-ofThings. IFAC annual Reviews in control, 34. 129–138. Zühlke, D. (2012). Nutzergerechte Entwicklung von MenschMaschine-Systemen: Useware-Engineering für technische Systeme. Springer, Berlin.
REFERENCES Bauernhansl, T. (2014). Die Vierte Industrielle Revolution. Der Weg in ein wertschaffendes Produktionsparadigma. In Bauernhansl, T., ten Hompel, M., Vogel-Heuser, B. (ed.), Industrie 4.0 in Produktion, Automatisierung und Logistik. Anwendung, Technologien und Migration, 5– 35. Springer Vieweg, Wiesbaden. Bergweiler, S. (2015). Intelligent Manufacturing based on Self-Monitoring Cyber-Physical Systems. The Ninth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies. Bleek, W., Wolf, H. (2008). Agile Softwareentwicklung: Werte, Konzepte und Methoden. Dpunkt, Heidelberg. Broy, M. (2010). Cyber-Physical Systems. Innovation durch softwareintensive eingebettete Systeme. Springer, Berlin. Eigner, M. (2014). Überblick Disziplin-spezifische und übergreifende Vorgehensmodelle. In Eigner, M. (ed), Modellbasierte Virtuelle Produktentwicklung, 15-51. Springer, Heidelberg. Eigner, M. (2014b). Modell Based Systems Engineering auf einer Plattform für PLM. In Stelzer, R. (ed), Entwickeln – Entwerfen – Erleben. Beiträge zur Virtuellen Produktentwicklung und Konstruktionstechnik, 39-56. Verlag der Wissenschaften GmbH, Dresden. Francalanza, E. Borg, J., Constantinescu, C. (2014). Deriving a systematic approach to changeable manufacturing system design. Proceedings of the 47th CIRP Conference on Manufacturing Systems. Hu, L., Xie, N., Kuang, Z., Zhao, K. (2012). Review of Cyber-Physical System Architecture. IEEE 15th International Symposium on Object/Component/ServiceOriented Real-Time Distributed Computing Workshops ISORCW, 25–30. Kolberg, D., Berger, C., Pirvu, B.C., Franke, M., Michniewicz, J. (2016). CyProF - Insights from a Framework for Designing Cyber-Physical Systems in Production Environments. 49th CIRP Conference on Manufacturing Systems. Kolberg, D., Zühlke, D. (2015). Lean Automation enabled by Industry 4.0 Technologies. In Alexander Dolgui, Jurek Sasiadek und Marek Zaremba (ed.), 15th IFAC Symposium on Information Control Problems in Manufacturing INCOM 2015, 1870–1875. IFACPapersOnLine Elsevier. Kolditz, J. (2009). Vorgehensmodell zur Erstellung von Fachkonzepten für selbststeuernde produktionslogistische Prozesse. GITO Verlag, Berlin. La, H.J., Kim, S.D. (2010). A Service-Based Approach to Designing Cyber Physical Systems. 2010 IEEE/ACIS 9th International Conference on Computer and Information Science (ICIS), 895–900. 98