- Email: [email protected]
ALM Integration: An Industrial Case Study
ScienceDirect
Available online at www.sciencedirect.com Procedia Manufacturing 00 (2018) 000–000
Available Availableonline onlineatatwww.sciencedirect.com www.sciencedirect.com
ScienceDirect
www.elsevier.com/locate/procedia
ScienceDirect ScienceDirect
www.elsevier.com/locate/procedia
Procedia Manufacturing 00 (2018) 000–000 Procedia Manufacturing 24 (2018) 107–113
Procedia Conference Manufacturing 00on (2017) 000–000 4th International System-Integrated Intelligence
www.elsevier.com/locate/procedia
Developing the Requirements of a PLM/ALM Integration: 4th International Conference on System-Integrated Intelligence An Industrial Case Study Developing the Requirements of a PLM/ALM Integration: a Manufacturing Engineering Society International Conference 2017,Possel-Dölken MESIC 2017, b28-30 June Andreas Deuter*, Andreas Otte, Marcel Ebert , Frank * An Industrial Case Study 2017, Vigo (Pontevedra), Spain OWL University of Applied Sciences, Liebigstr 87, 32657 Lemgo, Germany PHOENIX CONTACT GmbH & Co. KG, Flachsmarktstr. 8, a32825 Blomberg, Germany a
Andreas Deuter*, Andreas Otte, Marcel Ebert , Frank Possel-Dölkenb* b
Costing models for capacity optimization in Industry 4.0: Trade-off OWL University of Applied Sciences, Liebigstr 87, 32657 Lemgo, Germany PHOENIXused CONTACT GmbH & Co. KG,and Flachsmarktstr. 8, 32825 Blomberg, Germany between capacity operational efficiency a
b
Abstract
A.requires Santana P. Afonso , A.Smart Zanin , R.areWernke The digitization of the industry smart ,products and services. products mechatronic products with an increasing Abstract amount of software. To get high quality smart products to the market quickly, manufacturers need to reshape their product lifecycle a University of Minho, 4800-058 Guimarães, Portugal processes. They need to apply system engineering-based methods to enable smooth cross-domain developments with a special b Unochapecó, 89809-000 Chapecó, SC, Brazil The of the industry smart products and services. products are products an increasing focusdigitization on the software domain.requires One significant challenge faced bySmart manufacturers is mechatronic the harmonization of with product lifecycle amount of software. get high qualitythe smart products to the market quickly, manufacturers need to reshape their product lifecycle management (PLM),To which addresses hardware lifecycle, with application lifecycle management (ALM), which addresses the processes.lifecycle. They need to apply system engineering-based methods to enable smooth cross-domain developments with a special software focus on themanufacturers software domain. significant challenge faced demonstrates by manufacturers is theprocess harmonization of product lifecycle To support in thisOne challenging activity, this paper a proven for developing use cases and Abstract management (PLM), which addresses the hardware lifecycle, with application lifecycle management which addresses requirements associated with a PLM/ALM integration. This process has been elicited during an(ALM), industrial case study inthea softwarethe lifecycle. manufacturing company. This paper4.0", explains this process in detail. generally approach forinterconnected, developing the Under concept of "Industry production processes willA be pushedapplicable to be increasingly To support in integration this challenging activity, paper demonstrates a proven process for developing use cases and requirements of a PLM/ALM extracted by this removing the company-specific informationmanufacturers based on a real time basisis and, necessarily, much more efficient. Infactors. this context, capacity optimization requirements associated with a PLM/ALM integration. This process has been elicited during an industrial case study in a goes beyond the traditional aim of capacity maximization, contributing also for organization’s profitability and value. manufacturing company. This paper explains this process in detail. A generally applicable approach for developing the Indeed, lean management and continuous improvement approaches suggest capacity optimization instead of requirements of a PLM/ALM integration is extracted by removing the company-specific factors. © 2018 The Authors. Published by Elsevier Ltd. maximization. The study of capacity optimization and costing models is an important research topic that deserves This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) © 2018 The Authors. Published by Elsevier contributions from both the practical andB.V. theoretical perspectives. This paper presents Conference and discusses a mathematical Selection and peer-review under responsibility of the scientific committee of the 4th International on System-Integrated This is for an open accessmanagement article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) model capacity based on different costing models (ABC and TDABC). A generic model has been © 2018 The under Authors. Published by Ltd. committee of the 4th International Conference on System-Integrated Intelligence. Intelligence. Peer-review responsibility of Elsevier the scientific developed and it was used to analyze idle capacity and to design strategies towards the maximization of organization’s This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) value. The trade-off capacity maximization vs operational efficiency is and it is shown that capacity Keywords: Product Lifecycle Management; Application Lifecycle Management; Smart Systems Engineering Selection and peer-review under responsibility of the scientific committee of theProducts; 4thhighlighted International Conference on System-Integrated Intelligence. might hide operational inefficiency. optimization © 2017 The Authors. Published by Elsevier B.V. Keywords: Product Management; Applicationcommittee Lifecycle Management; Smart Products; Systems Engineering Peer-review underLifecycle responsibility of the scientific of the Manufacturing Engineering Society International Conference 2017. a
a,*
b
b
Keywords: Cost Models; ABC; TDABC; Capacity Management; Idle Capacity; Operational Efficiency
* Corresponding author. Tel.: +49-5261-702-5305; fax: +49-5261-702-85305.
address: [email protected] 1.E-mail Introduction
2351-9789 © 2018 Thecapacity Authors. Published by Elsevier Ltd. * The Corresponding author. Tel.: +49-5261-702-5305; fax: +49-5261-702-85305. cost of idle is a fundamental information for companies and their management of extreme importance ThisE-mail is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) address: [email protected] in modern production systems. In general, it is defined as unused capacity or production potential and can be measured Selection and peer-review under responsibility of the scientific committee of the 4th International Conference on System-Integrated Intelligence. in several ways: tons of production, available hours of manufacturing, etc. The management of the idle capacity 2351-9789 © 2018 The Authors. Published by Elsevier Ltd. * Paulo Tel.:article +351 253 510 +351 253license 604 741 This is anAfonso. open access under the761; CC fax: BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/4.0/) E-mail address: [email protected] Selection and peer-review under responsibility of the scientific committee of the 4th International Conference on System-Integrated Intelligence.
2351-9789 © 2017 The Authors. Published by Elsevier B.V. Peer-review under of the scientificbycommittee the Manufacturing Engineering Society International Conference 2017. 2351-9789 © 2018responsibility The Authors. Published Elsevier of B.V. This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the scientific committee of the 4th International Conference on System-Integrated Intelligence. 10.1016/j.promfg.2018.06.020
108 2
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
1. Introduction Product lifecycle management (PLM) is defined as the business activity of managing a company’s products across their entire lifecycles in the most effective way [1]. Traditionally, PLM addresses a product’s hardware lifecycle. PLM is used, for example, to organize CAD drawings, to create different types of bills of materials (BOM), and to manage product variants. However, when developing mechatronic products, PLM capabilities reach their limits, because they do not address a product’s software lifecycle. This the the task of the so-called Application lifecycle management (ALM). ALM organizes the software lifecycle by “indicating the coordination of activities and the management of artefacts (e.g., requirements, source code, and test cases) during a software product’s lifecycle” [2]. Hence, in smart product development, PLM and ALM coincide. Due to the rapidly advancing digitization of the industry, the product portfolios of industrial manufacturers are increasingly dominated by mechatronic products, which are also referred to as smart products. As many industrial manufacturers traditionally have a hardware-based product portfolio, they struggle to bring PLM and ALM together. They are unclear about the use cases of a PLM/ALM integration, about subsequent requirements, and hence about the common process lifecycle landscape. This paper starts reflecting the related work around PLM/ALM integration. Section 3 introduces the industrial case study and gradually explains the development of the requirements of PLM/ALM integration. Section 4 removes the company-specific elements of the case study and provides a generally applicable approach. The paper finishes with proposals for further research topics and a concluding discussion. 2. Related Work Both PLM and ALM cover a multitude of business processes throughout the entire product lifecycle. As with any business process, they must be carefully designed prior to deployment. However, to manage them efficiently, appropriate tools must be applied [3]. For mature industrial companies with a portfolio of several thousand products, the management of hundreds of product development and product change projects at the same time in different locations all around the world becomes increasingly difficult and complex. To achieve competitive times to market and assure product quality as well as compliance with laws, regulations, and standards, IT-supported business processes are mandatory for PLM and ALM. PLM and ALM are disconnected processes in today’s industrial environments, because the management paths of the hardware development and the software development diverged in the last decades [4]. The hardware development dominated and still dominates the product development. Although the software became more and more important in the last years, the software teams and the hardware teams still work in parallel. They do not use the same tools and do not share the same mindset. However, it is nowadays accepted that smooth PLM/ALM integration improves product development and change processes due to better transparency and data consistency [3]. Based on this acknowledgment, all major global tool vendors enforce PLM/ALM integrations in their respective tool chains [5,6,7]. In addition, analysts have started to address the need for PLM/ALM integration [8]. A major improvement in a PLM/ALM integrated product development and change process is consistent traceability across all involved tools and data artefacts. Traceability is the ability to follow a requirement both forward and backward [9]. Active traceability management increases the quality of product development due to facilitated requirements fulfillment analyses [10]. Furthermore, ensuring consistent traceability allows the strength of both PLM and ALM tools to be leveraged, thereby benefitting from the best of both worlds. The strength of PLM tools lies in the efficient management of product structures including associated documents and files, whereas ALM tools provide more sophisticated functionality for managing the product requirements, the related software code and the test cases [8]. Consistent traceability will ensure, for example, that a product requirement can be tracked down to the physical part structure in the BOM or to a specific software component in the source code. As the industry has started to address the challenge, academia could increase the research effort in the field of PLM/ALM integration by providing general architectural patterns and reference models for integrated business and work processes [3]. Of course, both PLM and ALM are relevant to the well-covered research field of systems engineering. Systems engineering is an interdisciplinary approach used to enable the successful implementation of
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
109 3
systems [11]. There are several concepts and methods guiding manufactures in applying systems engineering in practice, such as the ISO/IEC/IEEE 42010 [12] or SYSMOD [13]. However, these concepts and methods do not address adequately the usage of IT-Systems. Since this is needed to manage systems engineering efficiently, more efforts are required to outline how concepts from systems engineering can be implemented in integrated PLM/ALM environments. In [14], a systematic approach to create use cases for the PLM/ALM integration is proposed. However, this work lacks validation with real-world processes in industrial companies. The EU-funded project CRYSTAL addressed a complete tool chain with the focus on IT prerequisites [15]. Although PLM and ALM are addressed, concrete use cases and requirements from a user perspective are missing. To provide guidelines for system developers and industrial companies on the application of integrated PLM/ALM environments, more efforts are required to work out reference business process scenarios and patterns that match today’s development environments. In this paper, the term “requirements development” refers to the following three core activities of “requirements engineering” as stated in [16]: elicitation, documentation, and negotiation. Requirements engineering also includes the “requirements management” activity. This term describes the administration of the requirements developed, e.g., status control or the assurance of traceability. 3. The Case Study 3.1. Initial Situation Phoenix Contact is a leading supplier of electrical components and automation solutions for industrial applications, headquartered in Blomberg, Germany. In more than 50 worldwide subsidiaries, 16,000 employees develop, manufacture, and distribute more than 60,000 products to various industrial markets. The product portfolio includes pure mechanical devices such as connectors and cables as well as mechatronic devices such as PLCs or marking installation printers. As part of the Phoenix Contact digital transformation strategy, a global enterprise PLM project has been started to improve the future engineering environment. The objectives of the project include replacing a legacy PLM solution with a new one, namely Siemens Teamcenter [17], and the digitalization of all PLM-related processes. One of the processes in focus is the product development process (PDP), which describes the development phases and stage gates for mechatronic products. The PDP follows the traditional development phases from product idea, conception, design, implementation, testing, and development release including the simultaneous development of products and the required production processes. Regarding mechatronic products, the PDP comprises guidelines for the construction of the mechanical parts and the design of the electronic components. However, due to its different nature, different development guidelines were designed for the development of software, and this led to a split development process for hardware and software. For example, each domain manages requirements specifications, technical specifications, testing documentations, etc., in a different way. This led among other things to the rollout of an ALM tool, namely Siemens Polarion ALM [18], by the software development teams with just a low-level integration link to the existing legacy PLM solution. Consequently, the data in the ALM tool is only very tenuously linked to the data of the other domain specific tools, and in particular not to the legacy PLM tool. One of the sub-tasks of the enterprise PLM project is the improvement and further integration of the PDP across all involved disciplines (development and production); this also encompasses improved harmonization between the ALM tool that has already been introduced and the new PLM tool. 3.2. Project Goals Although the project team had a good understanding of PLM and ALM as stand-alone disciplines, it quickly identified that PLM/ALM integration is a rather imprecise term. To clarify the term, the project team needed to agree on the project objectives. It identified that before thinking about any implementation the requirements of the PLM/ALM integration had to be developed. Therefore, the project scope was set to include the following objectives:
110 4
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
1. Development of the requirements of the PLM/ALM integration 2. Validation of the requirements in the given tool chain based on the Phoenix Contact PDP The tool vendor of Teamcenter and Polarion ALM, Siemens, had already implemented an initial integration of both tools, which was available for the project team. The project objectives included a fit-gap analysis of the requirements, which will be identified in the case study, with the functionality already provided by the tool vendor. 3.3. Requirements Development The project team started by analyzing the current PDP (it should be said that any changes to the PDP were not within the project scope). The analysis included the identification of the involved roles, the data created, the data storage, and the links between the data. Regarding the management of a product’s lifecycle, data management in Polarion ALM differs from data management in Teamcenter. In Polarion ALM, all data for all revisions of one mechatronic product, e.g., all versions of the firmware, are managed in a single Polarion project. This is a central storage location in the Polarion ALM database containing requirements, design, implementation, tests, and defects. Data is organized following the principle of the sliced V-Model [19]. In opposition to this central data-oriented approach, in Teamcenter, a separate project item is supplied for each product revision. All hardware-related items, e.g., part items or CAD design items, are linked to this project item. Initially, an item known as a TC development project item is created. With the support of this item, the first product revision is developed. The status of this item follows the milestones of the PDP. Once a first revision is released, each new revision is developed using what is known as a TC change project item. The TC change project item follows either the milestones of the PDP or the milestones of a dedicated change process, depending on the size of the change. After the data analysis, the project team developed a model for task distribution between the PLM tool and the ALM tool. This task distribution model allows the strengths of the PLM tool and the ALM tool to be leveraged without the need to create an interface between the two tools. This means that this activity clarifies which tool manages which type of data (“single source of truth” strategy). The task distribution model is illustrated in Figure 1.
Figure 1: Task distribution between PLM and ALM (inspired by [7])
The model leverages the strength of Polarion ALM as a requirements management and test management tool as well as an issue tracking system. Therefore, the task distribution model proposes managing all requirements (hardware, software, and mechanics) and their test cases in Polarion ALM. Since BOM management and the management of hardware-related data are clearly the strength of any PLM tool, the different types of BOM and the hardware data remain at the heart of Teamcenter. Once the task distribution model had been defined, work moved on to define in detail which type of data (e.g., a document) from the PDP should be managed in which system. We ought to mention that the engineering IT environment of the industrial partner consists of more tools than Polarion ALM and Teamcenter. Therefore, this
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
111 5
detailed table also considered other tools in addition to just these two (specific Phoenix Contact project management solutions, for example). As Figure 1 shows, even with a task distribution model in place, there are points of interaction between the PLM tool and the ALM tool. For example, the hardware requirements managed in Polarion need to be linked to design items in Teamcenter. To identify the requirements of such interactions, a set of use cases was developed. These use cases provide a sequence mapping how a specific actor works with both systems. The use cases in the industrial case study were described in UML syntax [20] as well as in tables. Table 1 shows one example. Table 1: Use case “Linking Polarion baseline and TC item revision” Actor Project manager Trigger
The last milestone of the PDP is reached.
Goal
To create a link between a TC development project item revision and a baseline in the corresponding Polarion project.
Post condition
The link is established.
Normal flow
1. 2. 3.
Revise the TC development project item via a workflow Create a baseline in the corresponding Polarion project Link the TC development project revision to the Polarion baseline
To realize this use case, the interface between Teamcenter and Polarion ALM must fulfil the following requirement: “It shall be possible to link a Teamcenter item with a Polarion baseline”. Based on this principle, the project team created thirteen generalized use cases for integrated PLM/ALM processes and developed the corresponding requirements of the interface between Teamcenter and Polarion. All requirements refer to a specific type of traceability, e.g., linking a Polarion project to a Teamcenter item, creating comprehensive trace reports, and informing a linked item about a change to the partner item. Assuring traceability in a straightforward manner is the core requirement of any PLM/ALM integration. As this paper focuses on describing the process of developing the requirements of a PLM/ALM integration and not on the requirements itself, they are not listed. 3.4. Requirements Evaluation As mentioned, there is an initial implementation of a PLM/ALM interface provided by the tool vendor Siemens. A subsequent step of the project team evaluated which of the identified requirements the current tool chain already meets. The tested tool chain consists of Teamcenter V11.3, AWC V3.3, Polarion ALM V2017.1, and Connector V1.3.0. (Remark: The Connector is a dedicated software linking Teamcenter and Polarion ALM.) Several test cases derived from the use cases were specified and executed. The test execution showed that the given tool chain currently meets two of the identified requirements. 3.5. Project Wrap-up The proposed task distribution model between PLM and ALM can be considered a valuable finding of the project, because it paves the way to PLM/ALM integration without connecting the tools via an interface. Furthermore, it was not expected that all the identified requirements are already be implemented in the given tool chain. As the rollout of the PLM/ALM integration at Phoenix Contact is not expected in the next year, this is not critical. However, before this rollout, which includes the connection between the tools, the most important requirements must be implemented. In order to identify the most important requirements, the project team prioritized the identified requirements by interviewing relevant stakeholders at Phoenix Contact. To conclude, the project team contacted the tool vendor and discussed all the identified requirements. The tool vendor acknowledged that all requirements are comprehensible and most of them are usable for a broader customer audience. The project ended with an agreement between the project team and the tool vendor to jointly manage the implementation of the identified requirements in the order of priority.
112 6
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
4. Generalized Approach Although the development of the requirements of PLM/ALM integration took place in the specific environment of one manufacturing company, a general basic project approach can be outlined. If there is a product development process (PDP) in place, the following steps are generally applicable: 1. Create a data model for ALM and PLM respectively. 2. Identify all tasks of the PDP and assign these tasks either to PLM or to ALM. Remarks: Some tasks will not be in PLM or in ALM as there are always specific tools in use. 3. Identify the data (e.g., documents) and define if it is managed in PLM or in ALM. Remarks: One can consider completing step 1 to step 3 before working through the next steps. This will allow a smooth transition to a PLM/ALM integrated development process without the challenging process of creating a tool interaction. 4. Identify points of PLM/ALM interaction and describe these interactions with use cases. 5. Derive and formulate the requirements from the use cases. 6. Forward the prioritized requirements to the internal IT department and/or the tool vendor. The following process of requirements management includes the implementation, monitoring, and evaluation of the requirements. All these tasks are specific to the environment used in a manufacturing company. The actual implementation depends on the given tool chain. 5. Conclusion PLM/ALM integration relates to the field of systems engineering. It is increasingly required for smart product development to develop high quality products that can be brought to market quickly. Even if manufacturing companies are aware of this fact, they struggle to design and implement an integrated PLM/ALM environment. One of the factors hindering them in doing this is the identification of the corresponding requirements. This paper describes the development of the requirements of a PLM/ALM integration in a manufacturing company. It is a systematic approach, which starts by proposing the clarification of a potential task distribution model between PLM and ALM based on defined data models and without connecting the respective the IT solutions. This step lowers the threshold toward an integrated PLM/ALM environment, because an interface does not need to be built between the IT systems. However, a major quality characteristic of any development – comprehensive traceability across all disciplines and tools – can only be assured if such an interface exists. In this industrial case study, the requirements of this PLM/ALM interface were identified by use cases. Although the paper extracts a generally applicable process for the development of requirements, a manufacturing company needs to have a good understanding of PLM and ALM as stand-alone processes. The proposed process will be difficult to follow if this is not the case. A potential threat to validity is that the described process ends without the validation of the implemented requirements. However, the tool vendor confirmed the usefulness of the requirements and expressed the will to implement them. As mentioned above, academia could intensify its research activity in the field of PLM/ALM integration. A potential subject to investigate is the challenge of introducing an integrated PLM/ALM environment in different departments: a software developer will have to deal with PLM concepts, a CAD designer will have to handle requirements engineering following ALM ideas. This paper did not address this challenge. However, it provides useful hints to help manufacturing companies to maintain their competitiveness in the age of digitization. Acknowledgements We would like to thank the managers and engineers involved at Phoenix Contact for their support in this study. We would also like to express our gratitude to the staff of Siemens Industry Software for their feedback on the findings of the project.
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
113 7
References [1] Stark, J.: Product Lifecycle Management: 21st Century Paradigm for Product Realisation. Decision Engineering. Springer, 2011 [2] Kääriäinen, J.: Towards an Application Lifecycle Management Framework: VTT (179), 2011 [3] Ebert, C.: Improving engineering efficiency with PLM/ALM. In: Software & Systems Modelling 12 (3), pp 443–449, 2013 [4] Deuter, A., Rizzo, S.: A Critical View on PLM/ALM Convergence in Practice and Research. Procedia Technology Vol. 26, pp 405–412, 2016 [5] McAveney, R., Architect, C., Corp, A.: ALM-PLM Integration for Systems Development. In: Global Product Data Interoperability Summit, pp 1–18, 2015 [6] Azoff, M., Baer, T.: ALM for Engineered Products: The software economics of using PTC solutions for software-rich product development. https://www.pdsvision.de/wp-content/uploads/2016/06/ALM-for-Engineered-Products-PDSVision.pdf, 2014, accessed 09 Jan 2018 [7] Azoff, M.: ALM-PLM integration: Why it matters for multi-domain engineering. https://polarion.plm.automation.siemens.com/resources/download/ovum-wp-polarion-alm-plm-integration, 2015, accessed 09 Jan 2018 [8] Prendeville, K., Pitcock, J.: Maximizing the return on your billion-dollar R&D investment: Unified ALM-PLM, https://www.accenture.com/us-en/insight-outlook-maximizing-roi-unified-application-lifecycle-management.aspx, 2013, accessed 09 Jan 2018 [9] Gotel, O.C.Z., Finkelstein, C.W.: An analysis of the requirements traceability problem. In: International Conference on Requirements Engineering, pp 94–101, 1994 [10] Winkler, S., Pilgrim, J.: A survey of traceability in requirements engineering and model-driven development. Software & Systems Modeling 9 (4): pp 529–565, 2010 [11] Walden, D.D., Roedler, G.J., Forsberg, K., Hamelin, R.D., Shortell, T.M. (Eds): Systems engineering handbook: A guide for system life cycle processes and activities, 4th Ed. Wiley, 2015 [12] ISO/IEC/IEEE 42010:2011: Systems and software engineering - Architecture description, 2011 [13] Weilkiens, T.: SYSMOD - the systems modeling toolbox: Pragmatic MBSE with SysML, 2nd edition, MBSE4U booklet series, 2016 [14] Deuter, A., Otte, A., Höllisch, D.: Methodisches Vorgehen zur Entwicklung und Evaluierung von Anwendungsfällen für die PLM/ALMIntegration. In: Wissenschaftsforum Intelligente Technische Systeme (WInTeSys), Verlagsschriftenreihe des Heinz Nixdorf Instituts Vol. 369, Paderborn, pp 211–222, 2017 [15] Crystal – Critical Systems Engineering Acceleration. http://www.crystal-artemis.eu, accessed 09 Jan 2018 [16] Pohl, K.; Rupp, C.: Requirements engineering fundamentals, 2nd Ed. Rocky Nook, 2015 [17] Siemens Teamcenter, https://www.plm.automation.siemens.com/de/products/teamcenter, accessed 09 Jan 2018 [18] Siemens Polarion ALM, https://polarion.plm.automation.siemens.com, accessed 09 Jan 2018 [19] Deuter, A.: Slicing the V-model - Reduced effort, higher flexibility. In Proceedings of the International Conference on Global Software Engineering (ICGSE), pp. 1-10, 2013 [20] Object Management Group: Unified Modeling Language, https://www.omg.org/spec/UML/, accessed 09 Jan 2018
Available online at www.sciencedirect.com Procedia Manufacturing 00 (2018) 000–000
Available Availableonline onlineatatwww.sciencedirect.com www.sciencedirect.com
ScienceDirect
www.elsevier.com/locate/procedia
ScienceDirect ScienceDirect
www.elsevier.com/locate/procedia
Procedia Manufacturing 00 (2018) 000–000 Procedia Manufacturing 24 (2018) 107–113
Procedia Conference Manufacturing 00on (2017) 000–000 4th International System-Integrated Intelligence
www.elsevier.com/locate/procedia
Developing the Requirements of a PLM/ALM Integration: 4th International Conference on System-Integrated Intelligence An Industrial Case Study Developing the Requirements of a PLM/ALM Integration: a Manufacturing Engineering Society International Conference 2017,Possel-Dölken MESIC 2017, b28-30 June Andreas Deuter*, Andreas Otte, Marcel Ebert , Frank * An Industrial Case Study 2017, Vigo (Pontevedra), Spain OWL University of Applied Sciences, Liebigstr 87, 32657 Lemgo, Germany PHOENIX CONTACT GmbH & Co. KG, Flachsmarktstr. 8, a32825 Blomberg, Germany a
Andreas Deuter*, Andreas Otte, Marcel Ebert , Frank Possel-Dölkenb* b
Costing models for capacity optimization in Industry 4.0: Trade-off OWL University of Applied Sciences, Liebigstr 87, 32657 Lemgo, Germany PHOENIXused CONTACT GmbH & Co. KG,and Flachsmarktstr. 8, 32825 Blomberg, Germany between capacity operational efficiency a
b
Abstract
A.requires Santana P. Afonso , A.Smart Zanin , R.areWernke The digitization of the industry smart ,products and services. products mechatronic products with an increasing Abstract amount of software. To get high quality smart products to the market quickly, manufacturers need to reshape their product lifecycle a University of Minho, 4800-058 Guimarães, Portugal processes. They need to apply system engineering-based methods to enable smooth cross-domain developments with a special b Unochapecó, 89809-000 Chapecó, SC, Brazil The of the industry smart products and services. products are products an increasing focusdigitization on the software domain.requires One significant challenge faced bySmart manufacturers is mechatronic the harmonization of with product lifecycle amount of software. get high qualitythe smart products to the market quickly, manufacturers need to reshape their product lifecycle management (PLM),To which addresses hardware lifecycle, with application lifecycle management (ALM), which addresses the processes.lifecycle. They need to apply system engineering-based methods to enable smooth cross-domain developments with a special software focus on themanufacturers software domain. significant challenge faced demonstrates by manufacturers is theprocess harmonization of product lifecycle To support in thisOne challenging activity, this paper a proven for developing use cases and Abstract management (PLM), which addresses the hardware lifecycle, with application lifecycle management which addresses requirements associated with a PLM/ALM integration. This process has been elicited during an(ALM), industrial case study inthea softwarethe lifecycle. manufacturing company. This paper4.0", explains this process in detail. generally approach forinterconnected, developing the Under concept of "Industry production processes willA be pushedapplicable to be increasingly To support in integration this challenging activity, paper demonstrates a proven process for developing use cases and requirements of a PLM/ALM extracted by this removing the company-specific informationmanufacturers based on a real time basisis and, necessarily, much more efficient. Infactors. this context, capacity optimization requirements associated with a PLM/ALM integration. This process has been elicited during an industrial case study in a goes beyond the traditional aim of capacity maximization, contributing also for organization’s profitability and value. manufacturing company. This paper explains this process in detail. A generally applicable approach for developing the Indeed, lean management and continuous improvement approaches suggest capacity optimization instead of requirements of a PLM/ALM integration is extracted by removing the company-specific factors. © 2018 The Authors. Published by Elsevier Ltd. maximization. The study of capacity optimization and costing models is an important research topic that deserves This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) © 2018 The Authors. Published by Elsevier contributions from both the practical andB.V. theoretical perspectives. This paper presents Conference and discusses a mathematical Selection and peer-review under responsibility of the scientific committee of the 4th International on System-Integrated This is for an open accessmanagement article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) model capacity based on different costing models (ABC and TDABC). A generic model has been © 2018 The under Authors. Published by Ltd. committee of the 4th International Conference on System-Integrated Intelligence. Intelligence. Peer-review responsibility of Elsevier the scientific developed and it was used to analyze idle capacity and to design strategies towards the maximization of organization’s This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) value. The trade-off capacity maximization vs operational efficiency is and it is shown that capacity Keywords: Product Lifecycle Management; Application Lifecycle Management; Smart Systems Engineering Selection and peer-review under responsibility of the scientific committee of theProducts; 4thhighlighted International Conference on System-Integrated Intelligence. might hide operational inefficiency. optimization © 2017 The Authors. Published by Elsevier B.V. Keywords: Product Management; Applicationcommittee Lifecycle Management; Smart Products; Systems Engineering Peer-review underLifecycle responsibility of the scientific of the Manufacturing Engineering Society International Conference 2017. a
a,*
b
b
Keywords: Cost Models; ABC; TDABC; Capacity Management; Idle Capacity; Operational Efficiency
* Corresponding author. Tel.: +49-5261-702-5305; fax: +49-5261-702-85305.
address: [email protected] 1.E-mail Introduction
2351-9789 © 2018 Thecapacity Authors. Published by Elsevier Ltd. * The Corresponding author. Tel.: +49-5261-702-5305; fax: +49-5261-702-85305. cost of idle is a fundamental information for companies and their management of extreme importance ThisE-mail is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) address: [email protected] in modern production systems. In general, it is defined as unused capacity or production potential and can be measured Selection and peer-review under responsibility of the scientific committee of the 4th International Conference on System-Integrated Intelligence. in several ways: tons of production, available hours of manufacturing, etc. The management of the idle capacity 2351-9789 © 2018 The Authors. Published by Elsevier Ltd. * Paulo Tel.:article +351 253 510 +351 253license 604 741 This is anAfonso. open access under the761; CC fax: BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/4.0/) E-mail address: [email protected] Selection and peer-review under responsibility of the scientific committee of the 4th International Conference on System-Integrated Intelligence.
2351-9789 © 2017 The Authors. Published by Elsevier B.V. Peer-review under of the scientificbycommittee the Manufacturing Engineering Society International Conference 2017. 2351-9789 © 2018responsibility The Authors. Published Elsevier of B.V. This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the scientific committee of the 4th International Conference on System-Integrated Intelligence. 10.1016/j.promfg.2018.06.020
108 2
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
1. Introduction Product lifecycle management (PLM) is defined as the business activity of managing a company’s products across their entire lifecycles in the most effective way [1]. Traditionally, PLM addresses a product’s hardware lifecycle. PLM is used, for example, to organize CAD drawings, to create different types of bills of materials (BOM), and to manage product variants. However, when developing mechatronic products, PLM capabilities reach their limits, because they do not address a product’s software lifecycle. This the the task of the so-called Application lifecycle management (ALM). ALM organizes the software lifecycle by “indicating the coordination of activities and the management of artefacts (e.g., requirements, source code, and test cases) during a software product’s lifecycle” [2]. Hence, in smart product development, PLM and ALM coincide. Due to the rapidly advancing digitization of the industry, the product portfolios of industrial manufacturers are increasingly dominated by mechatronic products, which are also referred to as smart products. As many industrial manufacturers traditionally have a hardware-based product portfolio, they struggle to bring PLM and ALM together. They are unclear about the use cases of a PLM/ALM integration, about subsequent requirements, and hence about the common process lifecycle landscape. This paper starts reflecting the related work around PLM/ALM integration. Section 3 introduces the industrial case study and gradually explains the development of the requirements of PLM/ALM integration. Section 4 removes the company-specific elements of the case study and provides a generally applicable approach. The paper finishes with proposals for further research topics and a concluding discussion. 2. Related Work Both PLM and ALM cover a multitude of business processes throughout the entire product lifecycle. As with any business process, they must be carefully designed prior to deployment. However, to manage them efficiently, appropriate tools must be applied [3]. For mature industrial companies with a portfolio of several thousand products, the management of hundreds of product development and product change projects at the same time in different locations all around the world becomes increasingly difficult and complex. To achieve competitive times to market and assure product quality as well as compliance with laws, regulations, and standards, IT-supported business processes are mandatory for PLM and ALM. PLM and ALM are disconnected processes in today’s industrial environments, because the management paths of the hardware development and the software development diverged in the last decades [4]. The hardware development dominated and still dominates the product development. Although the software became more and more important in the last years, the software teams and the hardware teams still work in parallel. They do not use the same tools and do not share the same mindset. However, it is nowadays accepted that smooth PLM/ALM integration improves product development and change processes due to better transparency and data consistency [3]. Based on this acknowledgment, all major global tool vendors enforce PLM/ALM integrations in their respective tool chains [5,6,7]. In addition, analysts have started to address the need for PLM/ALM integration [8]. A major improvement in a PLM/ALM integrated product development and change process is consistent traceability across all involved tools and data artefacts. Traceability is the ability to follow a requirement both forward and backward [9]. Active traceability management increases the quality of product development due to facilitated requirements fulfillment analyses [10]. Furthermore, ensuring consistent traceability allows the strength of both PLM and ALM tools to be leveraged, thereby benefitting from the best of both worlds. The strength of PLM tools lies in the efficient management of product structures including associated documents and files, whereas ALM tools provide more sophisticated functionality for managing the product requirements, the related software code and the test cases [8]. Consistent traceability will ensure, for example, that a product requirement can be tracked down to the physical part structure in the BOM or to a specific software component in the source code. As the industry has started to address the challenge, academia could increase the research effort in the field of PLM/ALM integration by providing general architectural patterns and reference models for integrated business and work processes [3]. Of course, both PLM and ALM are relevant to the well-covered research field of systems engineering. Systems engineering is an interdisciplinary approach used to enable the successful implementation of
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
109 3
systems [11]. There are several concepts and methods guiding manufactures in applying systems engineering in practice, such as the ISO/IEC/IEEE 42010 [12] or SYSMOD [13]. However, these concepts and methods do not address adequately the usage of IT-Systems. Since this is needed to manage systems engineering efficiently, more efforts are required to outline how concepts from systems engineering can be implemented in integrated PLM/ALM environments. In [14], a systematic approach to create use cases for the PLM/ALM integration is proposed. However, this work lacks validation with real-world processes in industrial companies. The EU-funded project CRYSTAL addressed a complete tool chain with the focus on IT prerequisites [15]. Although PLM and ALM are addressed, concrete use cases and requirements from a user perspective are missing. To provide guidelines for system developers and industrial companies on the application of integrated PLM/ALM environments, more efforts are required to work out reference business process scenarios and patterns that match today’s development environments. In this paper, the term “requirements development” refers to the following three core activities of “requirements engineering” as stated in [16]: elicitation, documentation, and negotiation. Requirements engineering also includes the “requirements management” activity. This term describes the administration of the requirements developed, e.g., status control or the assurance of traceability. 3. The Case Study 3.1. Initial Situation Phoenix Contact is a leading supplier of electrical components and automation solutions for industrial applications, headquartered in Blomberg, Germany. In more than 50 worldwide subsidiaries, 16,000 employees develop, manufacture, and distribute more than 60,000 products to various industrial markets. The product portfolio includes pure mechanical devices such as connectors and cables as well as mechatronic devices such as PLCs or marking installation printers. As part of the Phoenix Contact digital transformation strategy, a global enterprise PLM project has been started to improve the future engineering environment. The objectives of the project include replacing a legacy PLM solution with a new one, namely Siemens Teamcenter [17], and the digitalization of all PLM-related processes. One of the processes in focus is the product development process (PDP), which describes the development phases and stage gates for mechatronic products. The PDP follows the traditional development phases from product idea, conception, design, implementation, testing, and development release including the simultaneous development of products and the required production processes. Regarding mechatronic products, the PDP comprises guidelines for the construction of the mechanical parts and the design of the electronic components. However, due to its different nature, different development guidelines were designed for the development of software, and this led to a split development process for hardware and software. For example, each domain manages requirements specifications, technical specifications, testing documentations, etc., in a different way. This led among other things to the rollout of an ALM tool, namely Siemens Polarion ALM [18], by the software development teams with just a low-level integration link to the existing legacy PLM solution. Consequently, the data in the ALM tool is only very tenuously linked to the data of the other domain specific tools, and in particular not to the legacy PLM tool. One of the sub-tasks of the enterprise PLM project is the improvement and further integration of the PDP across all involved disciplines (development and production); this also encompasses improved harmonization between the ALM tool that has already been introduced and the new PLM tool. 3.2. Project Goals Although the project team had a good understanding of PLM and ALM as stand-alone disciplines, it quickly identified that PLM/ALM integration is a rather imprecise term. To clarify the term, the project team needed to agree on the project objectives. It identified that before thinking about any implementation the requirements of the PLM/ALM integration had to be developed. Therefore, the project scope was set to include the following objectives:
110 4
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
1. Development of the requirements of the PLM/ALM integration 2. Validation of the requirements in the given tool chain based on the Phoenix Contact PDP The tool vendor of Teamcenter and Polarion ALM, Siemens, had already implemented an initial integration of both tools, which was available for the project team. The project objectives included a fit-gap analysis of the requirements, which will be identified in the case study, with the functionality already provided by the tool vendor. 3.3. Requirements Development The project team started by analyzing the current PDP (it should be said that any changes to the PDP were not within the project scope). The analysis included the identification of the involved roles, the data created, the data storage, and the links between the data. Regarding the management of a product’s lifecycle, data management in Polarion ALM differs from data management in Teamcenter. In Polarion ALM, all data for all revisions of one mechatronic product, e.g., all versions of the firmware, are managed in a single Polarion project. This is a central storage location in the Polarion ALM database containing requirements, design, implementation, tests, and defects. Data is organized following the principle of the sliced V-Model [19]. In opposition to this central data-oriented approach, in Teamcenter, a separate project item is supplied for each product revision. All hardware-related items, e.g., part items or CAD design items, are linked to this project item. Initially, an item known as a TC development project item is created. With the support of this item, the first product revision is developed. The status of this item follows the milestones of the PDP. Once a first revision is released, each new revision is developed using what is known as a TC change project item. The TC change project item follows either the milestones of the PDP or the milestones of a dedicated change process, depending on the size of the change. After the data analysis, the project team developed a model for task distribution between the PLM tool and the ALM tool. This task distribution model allows the strengths of the PLM tool and the ALM tool to be leveraged without the need to create an interface between the two tools. This means that this activity clarifies which tool manages which type of data (“single source of truth” strategy). The task distribution model is illustrated in Figure 1.
Figure 1: Task distribution between PLM and ALM (inspired by [7])
The model leverages the strength of Polarion ALM as a requirements management and test management tool as well as an issue tracking system. Therefore, the task distribution model proposes managing all requirements (hardware, software, and mechanics) and their test cases in Polarion ALM. Since BOM management and the management of hardware-related data are clearly the strength of any PLM tool, the different types of BOM and the hardware data remain at the heart of Teamcenter. Once the task distribution model had been defined, work moved on to define in detail which type of data (e.g., a document) from the PDP should be managed in which system. We ought to mention that the engineering IT environment of the industrial partner consists of more tools than Polarion ALM and Teamcenter. Therefore, this
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
111 5
detailed table also considered other tools in addition to just these two (specific Phoenix Contact project management solutions, for example). As Figure 1 shows, even with a task distribution model in place, there are points of interaction between the PLM tool and the ALM tool. For example, the hardware requirements managed in Polarion need to be linked to design items in Teamcenter. To identify the requirements of such interactions, a set of use cases was developed. These use cases provide a sequence mapping how a specific actor works with both systems. The use cases in the industrial case study were described in UML syntax [20] as well as in tables. Table 1 shows one example. Table 1: Use case “Linking Polarion baseline and TC item revision” Actor Project manager Trigger
The last milestone of the PDP is reached.
Goal
To create a link between a TC development project item revision and a baseline in the corresponding Polarion project.
Post condition
The link is established.
Normal flow
1. 2. 3.
Revise the TC development project item via a workflow Create a baseline in the corresponding Polarion project Link the TC development project revision to the Polarion baseline
To realize this use case, the interface between Teamcenter and Polarion ALM must fulfil the following requirement: “It shall be possible to link a Teamcenter item with a Polarion baseline”. Based on this principle, the project team created thirteen generalized use cases for integrated PLM/ALM processes and developed the corresponding requirements of the interface between Teamcenter and Polarion. All requirements refer to a specific type of traceability, e.g., linking a Polarion project to a Teamcenter item, creating comprehensive trace reports, and informing a linked item about a change to the partner item. Assuring traceability in a straightforward manner is the core requirement of any PLM/ALM integration. As this paper focuses on describing the process of developing the requirements of a PLM/ALM integration and not on the requirements itself, they are not listed. 3.4. Requirements Evaluation As mentioned, there is an initial implementation of a PLM/ALM interface provided by the tool vendor Siemens. A subsequent step of the project team evaluated which of the identified requirements the current tool chain already meets. The tested tool chain consists of Teamcenter V11.3, AWC V3.3, Polarion ALM V2017.1, and Connector V1.3.0. (Remark: The Connector is a dedicated software linking Teamcenter and Polarion ALM.) Several test cases derived from the use cases were specified and executed. The test execution showed that the given tool chain currently meets two of the identified requirements. 3.5. Project Wrap-up The proposed task distribution model between PLM and ALM can be considered a valuable finding of the project, because it paves the way to PLM/ALM integration without connecting the tools via an interface. Furthermore, it was not expected that all the identified requirements are already be implemented in the given tool chain. As the rollout of the PLM/ALM integration at Phoenix Contact is not expected in the next year, this is not critical. However, before this rollout, which includes the connection between the tools, the most important requirements must be implemented. In order to identify the most important requirements, the project team prioritized the identified requirements by interviewing relevant stakeholders at Phoenix Contact. To conclude, the project team contacted the tool vendor and discussed all the identified requirements. The tool vendor acknowledged that all requirements are comprehensible and most of them are usable for a broader customer audience. The project ended with an agreement between the project team and the tool vendor to jointly manage the implementation of the identified requirements in the order of priority.
112 6
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
4. Generalized Approach Although the development of the requirements of PLM/ALM integration took place in the specific environment of one manufacturing company, a general basic project approach can be outlined. If there is a product development process (PDP) in place, the following steps are generally applicable: 1. Create a data model for ALM and PLM respectively. 2. Identify all tasks of the PDP and assign these tasks either to PLM or to ALM. Remarks: Some tasks will not be in PLM or in ALM as there are always specific tools in use. 3. Identify the data (e.g., documents) and define if it is managed in PLM or in ALM. Remarks: One can consider completing step 1 to step 3 before working through the next steps. This will allow a smooth transition to a PLM/ALM integrated development process without the challenging process of creating a tool interaction. 4. Identify points of PLM/ALM interaction and describe these interactions with use cases. 5. Derive and formulate the requirements from the use cases. 6. Forward the prioritized requirements to the internal IT department and/or the tool vendor. The following process of requirements management includes the implementation, monitoring, and evaluation of the requirements. All these tasks are specific to the environment used in a manufacturing company. The actual implementation depends on the given tool chain. 5. Conclusion PLM/ALM integration relates to the field of systems engineering. It is increasingly required for smart product development to develop high quality products that can be brought to market quickly. Even if manufacturing companies are aware of this fact, they struggle to design and implement an integrated PLM/ALM environment. One of the factors hindering them in doing this is the identification of the corresponding requirements. This paper describes the development of the requirements of a PLM/ALM integration in a manufacturing company. It is a systematic approach, which starts by proposing the clarification of a potential task distribution model between PLM and ALM based on defined data models and without connecting the respective the IT solutions. This step lowers the threshold toward an integrated PLM/ALM environment, because an interface does not need to be built between the IT systems. However, a major quality characteristic of any development – comprehensive traceability across all disciplines and tools – can only be assured if such an interface exists. In this industrial case study, the requirements of this PLM/ALM interface were identified by use cases. Although the paper extracts a generally applicable process for the development of requirements, a manufacturing company needs to have a good understanding of PLM and ALM as stand-alone processes. The proposed process will be difficult to follow if this is not the case. A potential threat to validity is that the described process ends without the validation of the implemented requirements. However, the tool vendor confirmed the usefulness of the requirements and expressed the will to implement them. As mentioned above, academia could intensify its research activity in the field of PLM/ALM integration. A potential subject to investigate is the challenge of introducing an integrated PLM/ALM environment in different departments: a software developer will have to deal with PLM concepts, a CAD designer will have to handle requirements engineering following ALM ideas. This paper did not address this challenge. However, it provides useful hints to help manufacturing companies to maintain their competitiveness in the age of digitization. Acknowledgements We would like to thank the managers and engineers involved at Phoenix Contact for their support in this study. We would also like to express our gratitude to the staff of Siemens Industry Software for their feedback on the findings of the project.
Andreas Deuter et al. / Procedia Manufacturing 24 (2018) 107–113 A.Deuter, A.Otte, M.Ebert, F.Possel-Dölken / Procedia Manufacturing 00 (2018) 000–000
113 7
References [1] Stark, J.: Product Lifecycle Management: 21st Century Paradigm for Product Realisation. Decision Engineering. Springer, 2011 [2] Kääriäinen, J.: Towards an Application Lifecycle Management Framework: VTT (179), 2011 [3] Ebert, C.: Improving engineering efficiency with PLM/ALM. In: Software & Systems Modelling 12 (3), pp 443–449, 2013 [4] Deuter, A., Rizzo, S.: A Critical View on PLM/ALM Convergence in Practice and Research. Procedia Technology Vol. 26, pp 405–412, 2016 [5] McAveney, R., Architect, C., Corp, A.: ALM-PLM Integration for Systems Development. In: Global Product Data Interoperability Summit, pp 1–18, 2015 [6] Azoff, M., Baer, T.: ALM for Engineered Products: The software economics of using PTC solutions for software-rich product development. https://www.pdsvision.de/wp-content/uploads/2016/06/ALM-for-Engineered-Products-PDSVision.pdf, 2014, accessed 09 Jan 2018 [7] Azoff, M.: ALM-PLM integration: Why it matters for multi-domain engineering. https://polarion.plm.automation.siemens.com/resources/download/ovum-wp-polarion-alm-plm-integration, 2015, accessed 09 Jan 2018 [8] Prendeville, K., Pitcock, J.: Maximizing the return on your billion-dollar R&D investment: Unified ALM-PLM, https://www.accenture.com/us-en/insight-outlook-maximizing-roi-unified-application-lifecycle-management.aspx, 2013, accessed 09 Jan 2018 [9] Gotel, O.C.Z., Finkelstein, C.W.: An analysis of the requirements traceability problem. In: International Conference on Requirements Engineering, pp 94–101, 1994 [10] Winkler, S., Pilgrim, J.: A survey of traceability in requirements engineering and model-driven development. Software & Systems Modeling 9 (4): pp 529–565, 2010 [11] Walden, D.D., Roedler, G.J., Forsberg, K., Hamelin, R.D., Shortell, T.M. (Eds): Systems engineering handbook: A guide for system life cycle processes and activities, 4th Ed. Wiley, 2015 [12] ISO/IEC/IEEE 42010:2011: Systems and software engineering - Architecture description, 2011 [13] Weilkiens, T.: SYSMOD - the systems modeling toolbox: Pragmatic MBSE with SysML, 2nd edition, MBSE4U booklet series, 2016 [14] Deuter, A., Otte, A., Höllisch, D.: Methodisches Vorgehen zur Entwicklung und Evaluierung von Anwendungsfällen für die PLM/ALMIntegration. In: Wissenschaftsforum Intelligente Technische Systeme (WInTeSys), Verlagsschriftenreihe des Heinz Nixdorf Instituts Vol. 369, Paderborn, pp 211–222, 2017 [15] Crystal – Critical Systems Engineering Acceleration. http://www.crystal-artemis.eu, accessed 09 Jan 2018 [16] Pohl, K.; Rupp, C.: Requirements engineering fundamentals, 2nd Ed. Rocky Nook, 2015 [17] Siemens Teamcenter, https://www.plm.automation.siemens.com/de/products/teamcenter, accessed 09 Jan 2018 [18] Siemens Polarion ALM, https://polarion.plm.automation.siemens.com, accessed 09 Jan 2018 [19] Deuter, A.: Slicing the V-model - Reduced effort, higher flexibility. In Proceedings of the International Conference on Global Software Engineering (ICGSE), pp. 1-10, 2013 [20] Object Management Group: Unified Modeling Language, https://www.omg.org/spec/UML/, accessed 09 Jan 2018