www.diva-portal.org This is the published version of a paper

5 downloads 0 Views 958KB Size Report
bKTH Royal Institute of Technology, Department of Production Engineering, Stockholm, 10044, ... on the system granularity level, each viewpoint can be instanti-.
http://www.diva-portal.org

This is the published version of a paper presented at The 51st CIRP Conference on Manufacturing Systems.

Citation for the original published paper: Rahatulain, A., Onori, M. (2018) Viewpoints and views for the architecture description of cyber-physical manufacturing systems In: (pp. 450-455). Elsevier https://doi.org/10.1016/j.procir.2018.03.116

N.B. When citing this work, cite the original published paper.

Permanent link to this version: http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-231541

Available online atonline www.sciencedirect.com Available online at www.sciencedirect.com Available at www.sciencedirect.com

ScienceDirect ScienceDirect Procedia CIRP 00 (2017) 000–000 Procedia CIRP 72 (2018) 450–455 Procedia CIRP 00 (2018) 000–000

www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia

51st CIRP Conference on Manufacturing Systems

Viewpoints and views for the architecture description of cyber-physical 28th CIRP Design Conference, May 2018, Nantes, France manufacturing systems a,b,* A new methodology to analyze the functional andbphysical architecture of Afifa Rahatulain , Mauro Onori existing products for an assembly oriented product family identification SenseAir AB, Delsbo, 82060, Sweden a

b KTH



Royal Institute of Technology, Department of Production Engineering, Stockholm, 10044, Sweden

Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat

Corresponding author. Tel.: +46-73-461-2496; E-mail address: [email protected]

École Nationale Supérieure d’Arts et Métiers, Arts et Métiers ParisTech, LCFC EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France

Abstract

* Corresponding author. Tel.: +33 3 87 37 54 30; E-mail address: [email protected]

A well-defined architecture covering all the views, viewpoints and related stakeholders’ concerns throughout the life cycle is vital for a good system design. This becomes even more crucial when designing Cyber Physical Manufacturing Systems (CPMS), one of the key elements in factories of the future. This paper identifies views and viewpoints necessary for defining architecture for CPMS. A mapping between system stakeholders, concerns and viewpoints is also presented. The results shall serve as a basis for an architecture-centric development methodology Abstract for CPMS as well as conventional manufacturing systems. In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of c 2018  Authors. Published by Elsevier agile andThe reconfigurable production systemsB.V. emerged to cope with various products and product families. To design and optimize production Peer-review under the scientific the 51st CIRP Conference Manufacturing systems as well as responsibility to choose theofoptimal productcommittee matches, of product analysis methods areonneeded. Indeed, Systems. most of the known methods aim to analyze a product or one product family on the physical level. Different product families, however, may differ largely in terms of the number and Keywords: Cyber-physical manufacturing systems; Architecture; Viewpoints; Views; Factories of future; Industry 4.0 nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production system. A new methodology is proposed to analyze existing products in view of their functional and physical architecture. The aim is to cluster these products in new assembly oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable assembly systems. Based on Datum Flow Chain, the physical structure of the is analyzed. Functional subassemblies are identified, and 2. products Methodology 1. Introduction a functional analysis is performed. Moreover, a hybrid functional and physical architecture graph (HyFPAG) is the output which depicts the similarity providing support to both, production system planners productofdesigners. illustrative The first step towards theand objective this workAn is to identify Cyberbetween physicalproduct systemsfamilies have a by major role indesign defining the facexample a nail-clipper is fourth used toindustrial explain therevolution, proposed methodology. industrial on two product families columns of definecase the study architectural viewpoints [4]ofofsteering the system. The tories ofofthe future in the i.e. Indus- Anand thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach. description of the viewpoints discussed in this paper is based on try 4.0. However, several factors limit their wide-scale adoption © 2017 The Authors. Published by Elsevier B.V. the (i) system stakeholders as identified in [6], (ii) major system by the existing industrial setups. System complexity, safety, Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.

network security, performance metrics, lack of a comprehensive architecture, of well-defined Keywords: Assembly;non-availability Design method; Family identification methodology, legislative requirements and support & integration tools are to name a few [1–3]. The main focus of this paper is to define a basis for the archi1. Introduction tectural descriptions of a cyber-physical manufacturing system, which can be used for a holistic development approach throughto cycle the stages fast of development in The the methodology domain of outDue the life the system [4,5]. communication andtheanobjectives ongoing oftrend of digitization adopted to achieve this work is describedand in digitalization, enterprises arepaper facing important section 2. The manufacturing main results discussed in this are: challenges in today’s market environments: a continuing tendency towards reduction of product development times and • Identification of architectural viewpoints based on identishortened product lifecycles. In addition, there is an increasing fied stakeholders (section 3.2). demand of customization, being at the same time in a global • Classification of major views with respect to the identified competition with competitors all over the world. This trend, viewpoints and relevant abstraction levels (section 3.3). which is inducing the development from macro to micro • A mapping between the stakeholders and their concerns markets, results in diminished lot sizes due to augmenting with respect to the identified viewpoints is also presented product varieties (high-volume to low-volume production) [1]. (section 3.4). To cope with this augmenting variety as well as to be able to identify possible optimization potentials in the existing This paper is concluded in section 4 with a brief summary production system, it is important to have a precise knowledge and ideas for possible future work.

challenges & stakeholders’ concerns [7] and (iii) existing architecture definitions for manufacturing concepts based on cyber physical systems, such as Evolvable Production Systems (EPS) [1,8,9] and Holonic Manufacturing Systems (HMS) [10]. The next step after viewpoints identification, is the classifiof the of product and characteristics manufacturednamely; and/or cation major range possible views and their characteristics, assembled in this system. In this context, the their mainrelationships challenge in function, behavior and structure, along with modelling and of analysis is now not in only to copeThe with single with the levels abstraction (LoA) a CPMS. relationproducts, a limited product or existing families, ship between the views andrange different levels ofproduct abstraction has but also to be from able to and compareinproducts to define been derived theanalyze Y-model asto described [11]. Depending new product It can be observed that classical existing on the systemfamilies. granularity level, each viewpoint can be instantiproduct regrouped in function of clients ated intofamilies one or are more views, each corresponding toor a features. different However, assembly oriented product families are hardly to find. level of abstraction. On product level, products differ mainly in two Thethe results are family then summarized in the form of a matrix whichcharacteristics: provides a mapping thecomponents stakeholders, concerns main (i) the between number of and (ii) the and the viewpoints. (e.g. This mechanical, work has major inspirations from the type of components electrical, electronical). architecture descriptions and dependencies for single cyber products physical Classical methodologies considering mainly systems and in particular automotive systems [12–14]. or solitary, already existing product families analyze the product structure on a physical level (components level) which causes difficulties regarding an efficient definition and comparison of different product families. Addressing this

c©2018 2212-8271  The Authors. Published by Elsevier B.V. 2212-8271© 2018The The Authors. Published by Elsevier 2212-8271 2017 Authors. Published by Elsevier B.V. B.V. Peer-review under responsibility of the scientific committee of the of 51st CIRP on Manufacturing Systems. Systems. Peer-review under responsibility of scientific the scientific committee the 51stConference CIRP Conference Conference on Manufacturing Peer-review under responsibility of the committee of the 28th CIRP Design 2018. 10.1016/j.procir.2018.03.116

2

Afifa AfifaRahatulain Rahatulainetetal. al./ /Procedia ProcediaCIRP CIRP72 00(2018) (2018)450–455 000–000

451

Fig. 1: Methodology adopted for the research work presented in this paper

3. Architectural Viewpoints, Views and Levels of Abstraction in a CPMS This section discusses the stakeholders, major concerns, viewpoints, and views with reference to cyber-physical manufacturing systems. The relationship of views with the levels of abstraction is also discussed. To ensure a common understanding of the terminologies used in this work, the basic definitions of the architecture-related aspects are also provided below: • Stakeholder: A person, team or organization having an interest (concern) in a system is known as system stakeholder [4,5]. • Views: An architecture view addresses one or more concerns of the system stakeholders and is governed by a viewpoint. [4]. • Viewpoint: The viewpoint provides conventions to construct, interpret and analyze the corresponding views using models, notations, design rules, languages, etc. [4]. • Level of Abstraction: The levels of a system hierarchy corresponding to different complexity and detail levels. The higher the level of abstraction, the less is the complexity of the details describing that particular level. In the context of this work, the levels of abstraction in a production system are classified as system, line, cell, device, component and control levels. Fig. 2 shows an overview of the dependencies and relationships between different system elements and related architectural aspects. The stakeholders define their concerns for the system which are then framed by one or more viewpoints. Several views can be instantiated within a single viewpoint depending on the level of abstraction. Each level of abstraction can be defined under different view categories as having function, structure and behavior. Several views and viewpoints have been proposed in the reference architectures for CPS in manufacturing (for example, Evolvable Production Systems (EPS) [9] and Holonic Manufacturing Systems (HMS) [10]). The work presented in this

Fig. 2: Dependencies between different architectural elements for CPMS (adopted from ISO/IEC/IEEE 42010 [4])

paper complements the existing viewpoints and further defines and categorizes them into distinct viewpoints and corresponding views. The classification is based on the stakeholder requirements and concerns with reference to the architecture descriptions provided in ISO/IEC/IEEE 42010 [4]. 3.1. System Stakeholder and Concerns Stakeholder identification is the first step towards the development of a well-defined methodology based on an holistic approach. Flood and Carson method [15] was used to identify the system stakeholders and to classify them according to the narrow and wider system of interests. Table 1 provides a list of the major stakeholders. Only the stakeholders under the narrow SOI domain are considered for this work. The identification of the main requirements and concerns relevant to the system stakeholders is the next step towards the architecture development. The major concerns which are considered in this work are [7]: system safety, robustness, flexibility, mobility, security, performance, functional safety, autonomy, cost, standardization, real-time compatibility, tool chain integration, information management, verification & valida-

Afifa Rahatulain et al. / Procedia CIRP 72 (2018) 450–455 Afifa Rahatulain et al. / Procedia CIRP 00 (2018) 000–000

452

3

Table 1: A list of major stakeholders involved in the development of a CPMS [6] Narrow System of Interest

Wider System of Interest

Sensors provider Equipment provider Controller provider Software Engineer Programmer Network provider Maintenance Support Operator System Integrator Customer (Industry)

Product design Logistics Operations planning Management / Decision-making Human resource Supply chain Sales & marketing Administration IT support Customer (Product)

tion, and traceability. Table 2 provides a summary of the identified concerns. 3.2. Classification of Viewpoints Three major identified viewpoints for the architecture description of CPMS are; Implementation viewpoint, Functional viewpoint and Operational viewpoint. The implementation viewpoint is further categorized into hardware, software, and deployment viewpoints, while the operational viewpoint has two sub-categories, i.e.usability and communication viewpoints. The different viewpoints are shown in Fig.3 and a brief description of each viewpoint is as follows:

1. Implementation Viewpoint: This viewpoint covers mainly the technical aspects related to the implementation and development of a system. It is further divided into three main categories: • Hardware viewpoint • Software viewpoint • Deployment viewpoint 2. Functional Viewpoint: The functional viewpoint covers the performance and functionality related aspects of a system. The focus is on what the system is supposed to do (e.g. process production orders, manufacture, selfconfigure, etc.) and how (e.g. KPIs, efficiency, etc.) 3. Operational Viewpoint: This viewpoint covers the operation related concerns of the system stakeholders, including how the system will be monitored, controlled and managed. It is further divided into the following categories: • Usability viewpoint • Communication viewpoint

Fig. 3: Classification of viewpoints

The usability viewpoint covers the concerns related to operational details and management of the system, where as the communication strategies and information flow between the stakeholders, different abstraction levels and corresponding system elements is provided in the communication viewpoint.

Table 2: Major system challenges and stakeholders’ concerns [7] S.No.

Stakeholders’ concern

Description

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Flexibility Autonomy Security Performance System safety Functional safety Cost Real-time compatibility Verification & validation (V&V) Standardization Tool-chain integration Information management Traceability Mobility Robustness

In terms of hardware (machines, equipment, controllers, etc.), software, and communication network The extent to which a system can have self-x properties Connected networks, clouds, cyber attacks KPIs for system optimization, efficiency, effectiveness Advanced fail-safe mechanisms, synchronization issues, communication failures Safety critical systems, safety integrity levels, etc. Design, implementation, operational, functional costs, etc. Real-time constraints for implementing a self-managed system Well-defined risk and change management strategies for V&V activities throughout different life cycle stages Compliance with existing standards related to safety, programming, distributed control and automation, etc. Finding synergies between tools at different LoA, integrating discrete & continuous times and events Multi-disciplinary information, completeness of knowledge models, common ontology, efficient information flow, etc. Traceability of information, system design, testing, validation, etc. in all the life cycle phases Particularly with reference to hardware flexibility At different abstraction levels, e.g. system, device, control, etc.

4

Afifa Rahatulain et al. / Procedia CIRP 72 (2018) 450–455 Afifa Rahatulain et al. / Procedia CIRP 00 (2018) 000–000

3.3. Views And Their Relationship With Levels Of Abstraction Depending on the level of abstraction, every viewpoint can be instantiated into one or more views, each corresponding to a different level of detail. The major possible views defined in this work are shown in Fig. 4. This work has inspirations from an automotive architecture description [12] as discussed earlier. Following is a brief description of each of the identified views:

453

1. Function 2. Behavior 3. Structure Each of the above views is governed by the modeling formalisms, tools and other conventions defined in the corresponding viewpoint. The basic relationship between the levels of abstraction and CPMS views inspired by the Y-model [11] is shown in Fig. 6. 3.4. Mapping of Viewpoints with Stakeholders and Concerns

Fig. 4: Major identified views for CPMS

• Software view provides a detailed representation of the software architecture of a system. The details about function blocks, software components, source codes descriptions, etc. are often provided in the software view. • Hardware view represents the mechanical, electrical and electronic characteristics of a system. It typically consists of sensors, actuators, manufacturing equipment, ECUs, communication interfaces, buses, etc. • Control view covers the aspects related to the control system functionality. • Deployment view covers the placement strategies and issues related to the deployment of software agents onto the physical controllers. • Use case view represents the user interactions with the system. • Timing view covers the timing related aspects of the system, including; message exchange delays, bus communication delays, response times, etc. • Network view describes the connections between the system elements including the software and hardware topologies. • Information view represents the information management strategies between different stakeholders and system elements. It covers the aspects related to the completeness of information and efficient communication flow in the system. • Allocation view specifies the allocation of resources in the system as per the product requirements. Resource allocation algorithms and strategies are covered in this view. Each of the view is further defined as having three basic aspects:

The identified viewpoints are further mapped to the system stakeholders and concerns as shown in Fig. 5 in the form of a “viewpoint matrix” adapted from [13]. The concerns are plotted on the x-axis and the stakeholders are on the y-axis. The legend shows different viewpoints and their combinations represented by different colours, e.g. green, blue and orange colours represent the operational, functional and implementation viewpoints, respectively. Each stakeholder has several concerns in the system which can be framed by one or more viewpoints and are shown by the repsective viewpoint colour for each x-y axis graph area. The mapping follows the correspondence rules defined in the ISO/IEC/IEEE 42010 standard [4], i.e. a concern can be framed by one or more viewpoints, whereas a viewpoint may also cover various concerns simultaneously. For example, for an operator, all the concerns related to the system such as safety, robustness, traceability, autonomy, etc. comes under the operational viewpoint except the system performance which is related to functional viewpoint. Whereas, for a system integrator, the flexibility of the system is to be covered by all the three aspects, i.e. functional, operational and implementation. Similarly, cost may be a concern of implementation for an equipment provider, but comes under both functional and operational viewpoints for a customer. 4. Conclusion Cyber-physical systems shall have a major role in manufacturing industry in shaping the factories of the future during the 4th industrial revolution. The increase in ICT dependency, connectivity and digitalization emphasizes the need for developing manufacturing systems on a standard architecture accepted by the industrial sector. The standard architecture shall be able to cover not only the technical viewpoints but should also incorporate other important factors such as business models, operational planning, knowledge management, tool-chain integration, etc. RAMI 4.0 [16], the reference architecture for Industry 4.0 is one of such approaches being developed by active collaboration between industrial and academic stakeholders. The work presented in this paper provides a basis for developing the architecture framework and methodology for a holistic system development for CPMS. The viewpoints and views defined in this work are based on the stakeholders and their concerns relevant to the shop-floor level, i.e. the narrow System of interest (SOI) as shown in table 1[5,6]. This implies that the stakeholders related to the wider SOI, e.g. supply chain, operations management, planning, business model considerations, etc. are not in the scope of this work. The inclusion of stakeholders from the wider SOI will further broaden the scope of this work and will contribute to the

454

Afifa Rahatulain et al. // Procedia CIRP 00 72 (2018) 000–000 450–455

5

Fig. 5: Mapping of viewpoints with reference to system stakeholders and their concerns

References

Fig. 6: Levels of abstraction in a Cyber Physial Manufacturing System

addition of further viewpoints into the architecture framework. Another prospect for the the future work includes finding synergies between manufacturing and other domains working with CPS, such as automotive industry. This can be further utilized in architectural descriptions for CPMS and incorporating them with the existing reference architectures, e.g. RAMI 4.0. Acknowledgements The authors would like to thank SenseAir AB for funding and supporting this research under the EU openMOS project.

[1] Onori, M., Semere, D., Lindberg, B.. Evolvable Systems: An Approach to Self-X Production. In: CIRP-sponsored International Conference on Digital Enterprise Technology, Advances in Intelligent and Soft Computing; vol. 66. 2009, p. 789–802. [2] Leitao, P., Karnouskos, S.. A Survey on Factors that Impact Industrial Agent Acceptance. In: Industrial Agents. Elsevier Inc.; 2015, p. 401 – 429. [3] Wang, L., T¨orngren, M., Onori, M.. Current status and advancement of cyber-physical systems in manufacturing. Journal of Manufacturing Systems 2015;37:517–527. [4] ISO/IEC/IEEE 42010: Systems and Software Engineering - Architecture Description. 2011. [5] ISO/IEC/IEEE 15288: Systems and Software Engineering - System Life Cycle Processes. 2008. [6] Rahatulain, A., Lawson, H.B.. Towards Life Cycle Management of Industrial Manufacturing Systems: A Systems Perspective. In: The 9th Annual IEEE International Systems Conference. 2015,. [7] Rahatulain, A., Onori, M.. Production System Innovation Through Evolvability: Existing Challenges and Requirements. Journal of Machine Engineering 2015;15(3):50–64. [8] Onori, M., Alsterman, H., Barata, J.. An Architecture Development Approach For Evolvable Assembly Systems. In: The 6th IEEE International Symposium on Assembly and Task Planning: From Nano to Macro Assembly and Manufacturing, ISATP 2005. 2005, p. 19–24. [9] Semere, D., Barata, J., Onori, M.. Evolvable Assembly Systems: Development and Advances. In: IEEE International Symposium on Assembly and Manufacturing. 2007, p. 282 – 287. [10] Brussel, H.V., Wyns, J., Valckenaers, P., Bongaerts, L., Peeters, P.. Reference Architecture for Holonic Manufactruring Systems: PROSA. Computers in Industry 1998;37:255–274. [11] Boutekkouk, F., Benmohammed, M., Bilavarn, S., Auguin, M.. UML2.0 Profiles for Embedded Systems and Systems On a Chip (SOCs). Journal



6

Afifa Rahatulain et al. / Procedia CIRP 72 (2018) 450–455 Afifa Rahatulain et al. / Procedia CIRP 00 (2018) 000–000

of Object Technology 2009;8(1):135–157. [12] Dajsuren, Y., Gerpheide, C.M., Serebrenik, A., Wijs, A., Vasilescu, B., van den Brand, M.G.. Formalizing Correspondence Rules for Automotive Architecture Views. In: Proceedings of the 10th International ACM Sigsoft Conference on Quality of Software Architectures. QoSA ’14; 2014, p. 129– 138. [13] Broman, D., Lee, E.A., Tripakis, S., T¨orngren, M.. Viewpoints, Formalisms, Languages and Tools for Cyber- Physical Systems. In: Proceedings of the 6th International Workshop on Multi- Paradigm Modeling. 2012, p. 49 – 54. [14] Behere, S., Asplund, F., S¨oderberg, A., T¨orngren, M.. Architecture Challenges for Intelligent Autonomous Machines: An Industrial Perspective. In: 13th International conference on Intelligent Autonomous Systems (IAS-13). 2014, p. 1669 – 1681. [15] Flood, R., Carson, E.. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science. 1988. [16] IEC PAS 63088: Smart Manufacturing - The Reference Architectural Model Industry 4.0 - RAMI4.0. 2017.

455