- Email: [email protected]
Model-Based Requirement Engineering to Support Development of Complex Systems
Available online atonline www.sciencedirect.com Available online at Available at www.sciencedirect.com Available online at www.sciencedirect.com www.sciencedirect.com
ScienceDirect ScienceDirect Procedia CIRP 00 (2017) 000–000 Procedia CIRP 84 (2019) 239–244 Procedia CIRP 00 (2019) 000–000 Procedia CIRP 00 (2019) 000–000
www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia
29th 29th CIRP CIRP Design Design 2019 2019 (CIRP (CIRP Design Design 2019) 2019)
Model-Based Requirement Engineering Model-Based28th Requirement Engineering to to Support Support Development Development of of CIRP Design Conference, May 2018, Nantes, France Complex Complex Systems Systems a,∗to analyze a a b and physical b b A new methodology the functional architecture of D. D. Inkermann Inkermanna,∗,, T. T. Huth Hutha ,, T. T. Vietor Vietora ,, A. A. Grewe Greweb ,, C. C. Knieke Kniekeb ,, A. A. Rausch Rauschb Institute forfor Engineering Design, TU Braunschweig, Langer Kamp 8, 38106 Braunschweig, Germany existing products an assembly oriented product family identification Institute for Engineering Design, TU Braunschweig, Langer Kamp 8, 38106 Braunschweig, Germany b Institute b Institute
a a
for Software and Systems Engineering, TU Clausthal, Arnold-Sommerfeld-Straße 1, 38678 Clausthal-Zellerfeld, Germany for Software and Systems Engineering, TU Clausthal, Arnold-Sommerfeld-Straße 1, 38678 Clausthal-Zellerfeld, Germany
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
É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 Abstract About 90% innovations on today’s vehicles are driven by 90% of of the the innovations today’s vehicles are [email protected] by electrics/electronics electrics/electronics or or software software functions. functions. This This shifts shifts the the focus focus from from aa componentcomponent*About Corresponding author. Tel.: +33 on 3 87 37 54 30; E-mailin address: oriented perspective to a function-oriented view engineering. At the same time, descriptions of systems and subsystems are oriented perspective to a function-oriented view in engineering. At the same time, descriptions of systems and subsystems are required required in in order order to coordinate collaboration with suppliers. These different views on the system under development essentially affect requirements engineering. to coordinate collaboration with suppliers. These different views on the system under development essentially affect requirements engineering. On On the the one one hand, hand, information information have have to to be be provided, provided, e.g., e.g., for for requirement requirement specifications specifications for for single single systems. systems. On On the the other other hand, hand, requirements requirements have have to be defined for functions realized on different systems and subsystems. This paper presents a concept for model-based requirement to be defined for functions realized on different systems and subsystems. This paper presents a concept for model-based requirement engineering engineering Abstract supporting supporting to to gather gather and and provide provide requirements requirements needed needed for for different different views views within within the the automotive automotive development development process. process. The The concept concept presented presented is is based on five partial models representing the emerging automotive system from an abstract concept (use cases) to aa solution (system structure). based on five partial models representing the emerging automotive system from an abstract concept (use cases) to solution (system structure). In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of Each of partial namely cases, functions, function realization, system and product are described with regard Eachand of the the partial models, models, namely use use cases,emerged functions, realization, system structure structure and families. product structure structure areand described with regard to to agile reconfigurable production systems to function cope with various products and product To design optimize production required artifacts and their relations based on object-oriented modeling. These artifacts and relations serve for the allocation of requirements or requiredasartifacts and their relations basedproduct on object-oriented modeling. Thesemethods artifactsare andneeded. relations serve for theofallocation of methods requirements or systems well as to choose the optimal matches, product analysis Indeed, most the known aim to can by existing requirements. The proposed concept support different views the system and to structured, can be be specified specified by requirements. The proposedlevel. concept supportproduct different views upon upon the vehicle vehicle system and allow allow to generate generate structured, analyze a product orexisting one product family on the physical Different families, however, may differ largely in terms of the number and consistent documents, like requirements specifications for single systems within the development process. At the same time, the impact of changes consistent documents, like requirements specifications for single systems within the development process. At the same time, the impact of changes nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production concerning single requirements, use or can The of the proposed concept highlighted using the concerning single requirements, use cases, cases,tofunctions functions or systems systems can be beinanalyzed. analyzed. The application application proposed concept is is The highlighted using the system. Aofnew methodology is proposed analyze existing products view of their functional of andthe physical architecture. aim is to cluster example an electric vehicle. example of an electric vehicle. 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 products is analyzed. Functional subassemblies are identified, and cc 2019 The by Elsevier © Authors. 2019 Theanalysis Authors.isPublished Published by Moreover, Elsevier B.V. B.V. aPeer-review functional performed. a committee hybrid functional and physical architecture2019. graph (HyFPAG) is the output which depicts the Peer-review under underresponsibility responsibilityof ofthe thescientific scientific committee ofthe theCIRP CIRP DesignConference Conference 2019. of Design Peer-review under responsibility of the scientific of the CIRP Design Conference 2019. similarity between product families by providingcommittee design support to both, production system planners and product designers. An illustrative Keywords: Model-Based Systems Engineering; Function Modeling;case Design Activities; Development; SysMLcolumns of example of aRequirement nail-clipperEngineering; is used to explain the proposed methodology. An industrial study on twoAutomotive product families of steering Requirement Engineering; Model-Based Systems Engineering; Function Modeling; Design Activities; Automotive Development; SysML Keywords: thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach. © 2017 The Authors. Published by Elsevier B.V. Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018. in challenges when gathering and documenting requirements in
in challenges when gathering and documenting requirements in different different stages stages of of the the development development process process and and different different docdocuments like specification sheets. On the one hand, uments like specification sheets. On the one hand, information information have With have to to be be provided, provided, e.g., e.g., for for requirement requirement specifications specifications for for sinsinWith regard regard to to automotive automotive industry, industry, there there is is an an essential essential gle systems (specification sheet for a specific system like change of innovation drivers: approx. 90% of the innovations on gle systems (specification sheet for a specific system like the the change of innovation drivers: approx. 90% of the innovations on gearbox of the requirements have vehicles gearbox of aa vehicle) vehicle) and on on the other other hand, hand, requirementsand/or have today’s vehicles are are driven driven by by electrics/electronics electrics/electronics or or software software 1.today’s Introduction of the product range and characteristics manufactured to for functions (specification sheet for aa function functions. to be be defined defined for system. functions (specification sheet forchallenge function functions. This This leads leads to to an an increasing increasing shift shift in in the the importance importance assembled in this In this context, the main in like start-stop of a vehicle) realized by different systems and of the individual disciplines within product development [6, 1]. like start-stop a vehicle) realized by different and of Due the individual within product to the disciplines fast development in development the domain[6, 1]. of modelling and of analysis is now not only to cope systems with single subsystems. Whereas were based subsystems. Whereas in in the the past past products were mainly mainly developed based on on communication andproducts an ongoing trend developed of digitization andaa products, a limited product range or existing product families, component-oriented view as well as models documents guided component-oriented view as well as models guided digitalization, manufacturing enterprises aredocuments facing important but also to be able to analyze and to compare products to define by structure, function-oriented deby this this component component structure, nowadays function-oriented dechallenges in today’s marketnowadays environments: a continuing new product families. It can be observed and that classical existing 1.1. 1.1. Model-based Model-based Systems Systems Engineering Engineering and need need of of different different scriptions of the systems become of high relevance. However, scriptionstowards of the systems become of high relevance. times However, tendency reduction of product development and product families are regrouped in function of clients or features. views in development of complex systems views in development of complex systems descriptions of and with regard to their descriptions of systems systems and subsystems subsystems regard their memeshortened product lifecycles. In addition,with there is antoincreasing However, assembly oriented product families are hardly to find. chanical and are required in to coorchanicalofstructure structure and properties properties arethe required in order order coordemand customization, being at same time in atoglobal On the product familyinlevel, products differ mainly in two Product Product development development in automotive automotive engineering engineering is is still still strucstrucdinate collaboration with suppliers. These different views result dinate collaboration with suppliers. These result competition with competitors all over thedifferent world. views This trend, main characteristics: (i)by themilestone-based number of components and (ii) the tured and documented stage gate processes tured and documented by milestone-based stage gate processes which is inducing the development from macro to micro type of components (e.g. mechanical, electrical, electronical). [25]. [25]. Many Many of of the the product product models models used used during during development development ∗ Corresponding markets, results in diminished lot sizes due to augmenting Classical methodologies considering mainly single products pick up component-oriented structures and author. +49 531/391-3304 ∗ Corresponding author. +49 531/391-3304 pick up component-oriented structures and hierarchies hierarchies estabestabE-mailvarieties address: [email protected] (D.production) Inkermann). product (high-volume to low-volume or solitary, existingHowever, product processes families analyze the lished within the and E-mail address: [email protected] (D. Inkermann). [1]. lished withinalready the company. company. However, processes and product product To cope with this augmenting variety as well as to be able to product structure on a physical level (components level) which models are increasingly being adapted to support interdiscimodels are increasingly being adapted to support interdiscic 2019 The optimization 2212-8271 possible Authors. Published by Elsevier B.V. identify in the existing causes difficulties regarding an efficient definition and plinary development. This by established c 2019 The Authors. Publishedpotentials 2212-8271 by Elsevier B.V. plinary2019. development. This is is achieved achieved by adapting adapting established Peer-review under responsibility of the scientific committee of the CIRP Design Conference production system, it is important to have a precise knowledge comparison Peer-review under responsibility of the scientific committee of the CIRP Design Conference 2019. of different product families. Addressing this 1. 1. Introduction Introduction Keywords: Assembly; Design method; Family identification
2212-8271©©2017 2019The The Authors. Published by Elsevier 2212-8271 Authors. Published by Elsevier B.V. B.V. Peer-review under responsibility of scientific the scientific committee theCIRP CIRP Design Conference 2019. Peer-review under responsibility of the committee of the of 28th Design Conference 2018. 10.1016/j.procir.2019.04.345
240
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
interdisciplinary development approaches, as proposed in [24] and the fundamental principles of systems engineering. Furthermore, new and adapted product models like black and white box views or descriptions from a functional perspective are established. These models pick up different views upon the system under development like represented in the MBSE-Grid [17]. Methodologies from Systems Engineering (SE) Model-based Systems Engineering (MBSE) take up the basic elements of system theory [21] and are used to integrate different (engineering) views upon a system. The basic character and goal of the SE is formulated by [10]: “Systems engineering is a consistent, interdisciplinary approach for developing multidisciplinary systems. Not only does it address the system to be developed, but also the associated project.” In addition to this understanding, MBSE aims to document the results of various development activities in a central common system model and supports the generation of context-specific views of this information and relationships. MBSE follows the transition from heterogeneous, document-based product models to consistent and connected product models. Established methods of MBSE are investigated and characterized for example by [8] and [4]. System modeling is of fundamental importance for the MBSE. This modeling is based on the three elements language, tool and method. Existing standards such as UML [19] or SysML [18] define the elements and syntax to be used, while modeling tools such as Enterprise Architect are used to create and analyze the models. These tools support the correct use of language and allow different analyses and views of the model. The languages used within MBSE are of generic character in order to support the representation of different types of systems as well as views of different engineering disciplines.
2
1.3. Focus of research and structure of the paper This paper presents a novel concept for model-based requirement engineering in order to meet current challenges in automotive development. The concept is indented to support a continuous derivation and documentation of requirements as well as deduction of consistent sets of requirements for different views during development of complex systems. A focus is laid on the integration of structure-driven and functional perspectives upon the system under development. The paper is organized as follows: Section 2 briefly presents the state of the art in the field of view-specific system modeling as well as traceability and structuring of requirements. In Section 3 the modelbased concept for processing requirements in automotive product development is described. In Section 4 an exemplary application of the concept in the context of the development of a vehicle’s subsystem is described. Section 5 concludes the paper with a short summary and an outlook. 2. State of the Art The following section gives a brief overview of the state of the art for the topics design stages and views in development and traceability of requirements. 2.1. Design Stages and Views in Development The development of a system can be understood as a step wise extension of the knowledge about the system to be developed (see, e.g., [3]). These different information states processed within a development project, are called design states (see [2, 7]). Eisenbart investigated several development methodologies and identified a number of elementary design states [7]. Each of these design stages can be understood as a specific view of the system under development. In SE and MBSE many established approaches, like RFLP [16] or MBSE-Grid [17] pick up this different views upon the emerging system. These approaches suggest essential description elements (views) for systems under development. For example, the MBSE-Grid introduces 12 different views upon a system. Views at different levels of abstraction (problem and solution space) are proposed for the four areas requirements, behaviour, structure and parametrics. For the requirements area, the views Stakeholder Needs, System Requirements and Component Requirements are differentiated. The established V-model [8] emphasizes different levels of abstraction in system decomposition and description. The focus is on the overall system as well as the necessary perspectives and abstraction levels to describe the system.
1.2. Requirements and Requirements Engineering Requirements engineering (RE) is the first step of many established development processes, such as the V-model (see [8, 16]. The requirements determined within the scope of the RE activities serve, among others, to document wishes and needs of different stakeholders as well as specify boundary conditions, capabilities and characteristics for the system under development [14]. Requirement engineering in the automotive industry becomes a key factor for successful vehicle development due to the described shift of innovation drivers. This is not only accompanied by increasing complexity of the implemented system. Product development itself is becoming more complex due to interrelations between individual components of the vehicle and the corresponding development activities. Previous requirements engineering processes are usually geared towards the creation of document-based requirement specifications for the top (complete vehicle) and bottom (components) levels of the system composition [26] but do not allow effective description of all composition levels. Weber and Weisbord investigated requirement engineering in automotive development for an OEM and point out important problems and fields of action in [26], e.g. combining document-based and model-based RE, avoidance of redundancies, user-specific views and traceability of requirements across multiple hierarchical levels of the systems.
2.2. Traceability of requirements
2
Traceability of artifacts in development processes here is understood in the sense of computer science: “Software artifact traceability is the ability to describe and trace the life of an artifact (requirements, code, tests, models, reports, plans, etc.)
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
that has been developed forward and backward during the software lifecycle.” [12]. This definition can also be used for complex technical systems, such as vehicles. Here, a proper implementation of the traceability of artifacts can give insights into system development and support the general understanding of the system, the impact analysis and reuse of existing artifacts [5]. The traceability of artifacts can thus be divided into two dimensions: vertical and horizontal relations as well as pre- and post-traceability. With regard to horizontal relations, we refer to traceability relations with elements of the same kind of artifact (e.g., relations between requirements). Vertical relations designate relations of an artifact to different other kinds of artifacts (e.g., relation between a requirement and system component) [22, quoted from (Lindvall, Tvedt, & Costa, 2003)]. The second dimension includes pre- and posttraceability, also known as forward and backward traceability [12]. Pre-traceability describes the relationships between requirements and their sources (e.g., stakeholders or use cases), while post-traceability describes the relationships between requirements and artifacts created in later development phases (e.g., component specifications or interface definitions). In addition to the traceability of requirements, their structuring is relevant in order to support access to requirements as well as to enable the generation of specific views for the requirements collective. In literature various approaches for structuring requirements are described, e.g. [9, 20]. These are not conceived for a model-based requirement engineering, but can be adapted to model-based approaches [23, 13]. Furthermore, there are original model-based approaches to requirements engineering, e.g. [23, 27].
241 3
• Complete system description required the functional and structural view. Each view describes different parts of the system and result in different system scopes (differing elements needed to fulfill a function or defining the mechanical setup of a system). • The description of the system has the primary goal to support and uncover the traceability of requirements in the sense of their origin and their relevance for the elements of the partial models. Based on these premises and scopes, the proposed concept supports documentation of requirements for different views and on different levels of abstraction during development. Structure and partial models constituting the model-based concept for requirements engineering are described in the following sections. 3.2. Basic structure of the concept and required partial models The proposed concept constitutes the description of the system under development from a functional and structural view in order to support the requirements engineering within the interdisciplinary development of complex systems like vehicles. A description of the system can be developed differing between three main views, cf. Fig. 1. These views are strongly interconnected and represent essential design stages. The distinction between functional and structural view is picked up form established methodologies in engineering design like [11] focusing on the aspects of functions, structure and behaviour. Thereby, the functional description represents the tasks to be fulfilled as well as the demanded behavior of the system. The structural description comprises the physical representation of the system. Both views are linked by the function realization view. This partial model allocates physical components to the demanded behavior by indicating their contribution to single functions. Based on this basic structure, five partial models are used within this model-based concept to describe the system under development, see Fig. 1. The following Subsections introduce these partial models in detail with regard to content and structure. The modeling is based on the modeling languages UML [19] and SysML [18] with additional stereotypes.
3. Concept for model-based requirement engineering Based on the described challenges and approaches, a concept for model-based requirements engineering in complex system development was developed. The concept is intended to support the requirement engineering during the early phases of the development of automotive subsystems, integrating the structural and functional perspectives on the emerging subsystem. Subsystems, therefore, are understood as complex systems, like the drive train involving different components like drive, gearbox or axis. The subsystem itself is part of the vehicle system and contributes to different functions of the vehicle, like start-stop for instance. 3.1. Premises and scope of the approach The approach was developed based on the following premises and objectives established in automotive industry: • The overall system under development is a single vehicle derivative or a vehicle family (referred to as a system in the following): Relations of the vehicle to its environment (e.g., Car2X communication, connection to cloud based services, etc.) were not considered in this first scope of the concept.
Fig. 1. Basic views and five partial models to structure and describe complex systems from a requirements engineering point of view.
3
3.2.1. Functional view The functional view is implemented by the two partial models, namely Capabilities and Functions. The partial model Ca-
242
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
pabilities describes the capabilities [15], understood as purposes the system is used for as well as tasks that have to be fulfilled by the system under development. These include generic capabilities like acceleration or deceleration as well as specific capabilities like vehicle start off or climate management. The modeling of this partial model is based on the use case modeling of the UML, extending the UML use case via a stereotype <>. The partial model Functions is used to define the functions to be realized by the system based on the defined capabilities. Whereas, functions are understood as a logical combination of capabilities. Based on the logical as well as chronological combination and ordering, activities are defined as a refinement of the capabilities to describe the single functions. A capability can be assigned to several activities and thus different functions. Activity diagrams of the UML are used to represent the functional and logical structure of the functions based on the defined activities. The structure is represented by signal flows connecting the activities in the logical sequence that is required to realize the function. Fig. 2 gives an example of the links between capabilities and a function using activities.
4
resenting the components that are modeled in the partial model system structure, e.g. traction motor or transmission. To represent elements of the product structure blocks of the SysML extended by the stereotype P-Block and the block definition diagram are used.
Fig. 3. Extract of the system structure of the front drive axis of a BEV.
The partial model system structure contains all components of the system needed to fulfill the defined functions. In this partial model, however, these elements are not arranged in a hierarchical way but strictly functional. Therefore, the elements of the system structure are linked to each other using ports and connectors. Each port has a type attribute that specifies a limited set of relation types needed to describe the intended functions like high voltage, mechanical mounting or communication. These attributes are also applied to specify the connectors linking the ports of the elements. Fig. 3 illustrates an extract for the system structure of the front drive axis of a battery electric vehicle (BEV). For modelling the system structure blocks of the SysML are used and extended by a new stereotype: S-Block. Ports and connectors are also extended by stereotypes to differ between the functional attributes mentioned above. Fig. 2. Describing the functional view on the system by linking capabilities and a function based on activities.
3.2.2. Structural view The structural view of the system comprises the partial models product structure and system structure. The partial model product structure represents the elements of a system structured in a non-functional way. In order to structure the systems and components in this partial model, for instance, brakedown structures of the overall product can be used. However, this structuring in most cases is not driven by functional aspects but existing organizational structures within a company, defining responsibilities for development and taking into account requirements for acquisition of single subsystems and components. The structuring of the elements of the product structure covers a defined number of levels. Here, the later product, e.g. the vehicle, represents the root element and is broken down into subsystems and components. This structuring and definition of system levels is important to locate the system to be described within the overall system as well as to indicate interfaces to neighbouring systems. The last level of the subsystems is rep-
3.2.3. Function realization view To combine the functional and structural views on the system, the partial model function realization is used. Within this model, the previously defined functions are matched to realizing components. For this purpose block definition diagrams of the SysML and additional defined realization objects, extending the SysML blocks, are used. These objects serve as brokers between the functional and structural descriptions of the system. During further development, the functions or subfunctions to be fulfilled by a component can be determined from these relations. The realization objects enable to describe the realization of a function in more detail, as well as to capture dependencies on the level of the function realization between the objects of this partial model. Fig. 4 shows the realization object engine and its connection to the S-Block traction motor as well as the activities ramp up and engine on. 3.3. Allocation and documentation of requirements
4
The described modelling concept serves as a basis to derive and allocate requirements to the single model elements like ca-
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
pabilities, functions or system elements and their interrelations. Requirements are therefore used to specify the elements and relations in each of the partial models and, thus, refine the solution spaces. However, there is no dedicated requirement model, but each partial model contains specific requirements allocated to the elements and relations represented in this partial model. For instance, in the partial model capabilities, the requirements relevant for each capability are modeled focusing on requirements with regard to customer demands and, e.g. legal restrictions. Requirement can also indicate additional capabilities of the future system. Thus, the solution space as well as basic tasks of the system are defined by additional requirements with regard to the performance or scope of single capabilities. In the partial model functions, requirements are specified based on the ones in the partial model capabilities and additional requirements are derived form the required behaviour. The resulting requirements are linked to the functions and activities as well as further elements of the activity diagrams. This procedure is continued for all partial models and results in detailed requirements for each partial model based on the development context and information. By linking the partial models the defined requirements are related to each other. Thus, vertical traceability between requirements and the artifacts of the individual partial models is realized. The single requirements as well as relations between these are modeled using the SysML standard. Thus, the presented concept supports the horizontal (requirement to requirement) and vertical (requirement to other kind of artifacts) traceability. The horizontal traceability of requirements can be supported based on the concept of [23] in combination with the presented system modeling concept. Only the requirement description itself is extended by a partial model-specific stereotype: e.g., <>, to enable identification of the affiliation of a requirement.
other elements of the different partial models. The S-Block traction motor is also connected to the realization object engine of the partial model function realization. This, in turn, is connected to activities from the partial model functions (ramp up and engine on). In both partial models, requirements exist that are relevant for the different system elements. For the single elements of the partial models, requirement collectives or context-specific views for individual elements can be derived based on the proposed modelling concept. For instance, the requirements collective for the P-block assy-axis of the product structure can be derived based on the relations as described in the paragraph before. For this purpose, all requirements that are directly connected to the P-block or to the elements of the other partial models are indicated. These requirement collectives can serve as basis for requirement documents like system specification for component suppliers. Furthermore, the modeling concept supports the analysis and evaluation with regard to vertical and horizontal as well as the post-traceability of requirements (cf. Sec. 2.2) relevant for single systems or functions. By linking requirements and elements of the different partial models, identification of associated requirements is enabled when elements are omitted or removed from the model and any derived document. Furthermore, in case of changed systems, impacts to requirements can be indicated based on the model. This ensures consistent requirements in different engineering situations as well as an efficient derivation of specific views on the requirements. Thus, the proposed concept serves as a sound basis to combine model-based and document-based RE within the development of complex systems. 5. Conclusion and further research
4. Application of the concept In order to highlight the application and benefits of the described concept for model-based requirement engineering acquisition and documentation as well as analysis of requirements is explained in this section using the extracts of a battery electric vehicle (BEV). The focus is laid on the explanation of the vertical traceability and the linking between the elements of the individual partial models within the model. Fig. 4 gives a diagram containing essential elements of different partial models as well as requirements associated with these elements. The description of the system based on the proposed modelling concept results in a graph of nodes and edges representing the capabilities, functions, activities, and system elements as well as requirements, c.f. Fig. 4. The different edges represent the relevant links like ”requirement has to be satisfied by block”. The graph can be traversed from any node in order to analyze the given relations. For instance, focusing on the Pblock assy-axis it can be analyzed which other nodes are linked, here traction motor (TM) and gearbox. These nodes of the type S-Block are linked to requirements that are also connected to
243 5
5
In this paper, a novel approach to structure different views in system development focusing on the functional and structural views needed for model-based requirement engineering is presented. Namely, the five partial models capabilities, functions, function realization, product structure, and system structured are used to derive and document requirements from different stakeholders and in different design stages. The requirements are allocated to elements and relations as well as links between the partial models. The direct allocation of the requirements and the linking of the five partial models ensures vertical and horizontal traceability of requirements and enables to derive consistent collectives of requirements for single systems or functions. The proposed approach was developed and initially applied in the context of automotive development and presents an initial concept. It has to be detailed with regard to the modelling of each partial model as well as allocation of requirements. Further research will focus on classification of requirements with regard to the relevance for different system levels taking dependencies between requirements and system structure into account. Moreover, refinement of the allocation of requirements will be part of further research of the modelling concept. To support the application of the proposed concept in industry, processing of the requirements collectives based on a software tool will be investigated. Therefore, the integration of the modelling concept
244
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
6
Fig. 4. Example of modeling the drive components of a BEV with requirements using the introduced approach.
into existing requirement management processes including interfaces to established software for requirements management, e.g. IBM Doors, will be further pursued. Applicability and use of the model-based requirement engineering concept will be evaluated in the field of automotive industry.
[12] Gotel, O.C.Z., Finkelstein, C.W., 1994. An analysis of the requirements traceability problem, in: Proc. of IEEE Int. Conf. on Requirements Engineering, pp. 94–101. doi:10.1109/ICRE.1994.292398. [13] Huth, T., Inkermann, D., Vietor, T., 2017. Ein Ansatz f¨ur eine integrierte modellbasierte Anforderungs- und Variantenmodellierung, in: Gausemeier, J.e. (Ed.), Wissenschaftsforum Intelligente Technische Systeme (WInTeSys), pp. 169–182. [14] ISO/IEC/IEEE International Standard, 2017. ISO/IEC/IEEE 24765:2017(E) - Systems and software engineering–Vocabulary. doi:10.1109/IEEESTD.2017.8016712. [15] J¨arvenp¨aa¨ , E., 2012. Capability-based adaptation of production systems in a changing environment. Tampere University of Technology. [16] Kleiner, S., Kramer, C., 2013. Model Based Design with Systems Engineering Based on RFLP Using V6, in: Abramovici, M., Stark, R. (Eds.), Smart Product Engineering. Springer, Berlin, pp. 93–102. doi:10.1007/ 978-3-642-30817-8_10. [17] Morkevicius, A., Aleksandraviciene, A., Mazeika, D., Bisikirskiene, L., Strolia, Z., 2017. MBSE Grid: A Simplified SysML-Based Approach for Modeling Complex Systems. INCOSE International Symposium 27, 136– 150. doi:10.1002/j.2334-5837.2017.00350.x. [18] Object Management Group, 2017a. OMG Systems Modeling Language (OMG SysMLTM ). URL: https://www.omg.org/spec/SysML/1.5/. [19] Object Management Group, 2017b. OML Unified Modeling Language (OMG UML ). URL: http://www.omg.org/spec/UML/2.5.1. [20] Pohl, K., 2010. Requirements Engineering. Springer, Berlin. doi:10. 1007/978-3-642-12578-2. [21] Ropohl, G. (Ed.), 1975. Systemtechnik - Grundlagen und Anwendung. Hanser, M¨unchen. [22] Smit, K., Zoet, M., and Berkhout, M., . A Framework for Traceability of Legal Requirements in the Dutch Governmental Context, in: BLED 2016 Proceedings. [23] Stechert, C., 2010. Modellierung komplexer Anforderungen. Phd-thesis. TU Braunschweig. Braunschweig. [24] VDI, 2004. VDI 2206 - Entwicklungsmethodik f¨ur mechatronische Systeme. BeuthVerlag, Berlin (2004). [25] Volker, S., Prostean, G., 2016. Research of automotive change management and combined risk-management models. Procedia - Social and Behavioral Sciences 221, 395–404. doi:10.1016/j.sbspro.2016.05.129. [26] Weber, M., Weisbrod, J., 2003. Requirements engineering in automotive development: experiences and challenges. IEEE Software 20, 16–24. doi:10.1109/MS.2003.1159025. [27] Weilkiens, T., 2014. Systems Engineering mit SysML/UML: Anforderungen, Analyse, Architektur. 3 ed., dpunkt.verl., Heidelberg.
References [1] Anderl, R., Eigner, M., Sendler, U., Stark, R., 2012. Smart Engineering: Interdisziplin¨are Produktentstehung. acatech DISKUSSION, Springer, Berlin. doi:10.1007/978-3-642-29372-6. [2] Blessing, L.T.M., 1995. Comparison of design models proposed in prescriptive literature. The role of design in the spaping of technology, COST A3/COST A4 International research workshop URL: https://ci.nii. ac.jp/naid/10015770748/en/. [3] Browning, T.R., Deyst, J.J., Eppinger, S.D., Whitney, D.E., 2002. Adding value in product development by creating information and reducing risk. IEEE Transactions on Engineering Management 49, 443–458. doi:10. 1109/TEM.2002.806710. [4] Browning, T.R., Fricke, E., Negele, H., 2006. Key concepts in modeling product development processes. Systems Engineering 9, 104–128. doi:10. 1002/sys.20047. [5] D¨omges, R., Pohl, K., 1998. Adapting Traceability Environments to Project-specific Needs. Commun. ACM 41, 54–62. doi:10.1145/ 290133.290149. [6] Eigner, M., Roubanov, D., Zafirov, R., 2014. Modellbasierte virtuelle Produktentwicklung. Springer Vieweg, Berlin. doi:10.1007/ 978-3-662-43816-9. [7] Eisenbart, B., 2014. Supporting Interdisciplinary System Development Through Integrated Function Modelling. Phd-thesis. Universit´e du Luxembourg. Luxembourg. [8] Estefan, J.A., 2008. Survey of model-based systems engineering (mbse) methodologies 25. URL: https://www.omg.org/MBSE_Methodology_ Survey_RevB.pdf. [9] Feldhusen, J., Grote, K.H., Pahl, G., Beitz, W. (Eds.), 2013. Konstruktionslehre: Methoden und Anwendung erfolgreicher Produktentwicklung. 8 ed., Springer Vieweg, Berlin. doi:10.1007/978-3-642-29569-0. [10] Gausemeier, J., Dumitrescu, R., Steffen, D., Czaja, A., Wiederkehr, O., Tschirner, C., 2015. Systems Engineering in Industrial Practice, Paderborn, Germany. [11] Gero, J., 1990. Design prototypes a knowledge representation schema for design. AI Magazine 11, 26–36.
6
ScienceDirect ScienceDirect Procedia CIRP 00 (2017) 000–000 Procedia CIRP 84 (2019) 239–244 Procedia CIRP 00 (2019) 000–000 Procedia CIRP 00 (2019) 000–000
www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia
29th 29th CIRP CIRP Design Design 2019 2019 (CIRP (CIRP Design Design 2019) 2019)
Model-Based Requirement Engineering Model-Based28th Requirement Engineering to to Support Support Development Development of of CIRP Design Conference, May 2018, Nantes, France Complex Complex Systems Systems a,∗to analyze a a b and physical b b A new methodology the functional architecture of D. D. Inkermann Inkermanna,∗,, T. T. Huth Hutha ,, T. T. Vietor Vietora ,, A. A. Grewe Greweb ,, C. C. Knieke Kniekeb ,, A. A. Rausch Rauschb Institute forfor Engineering Design, TU Braunschweig, Langer Kamp 8, 38106 Braunschweig, Germany existing products an assembly oriented product family identification Institute for Engineering Design, TU Braunschweig, Langer Kamp 8, 38106 Braunschweig, Germany b Institute b Institute
a a
for Software and Systems Engineering, TU Clausthal, Arnold-Sommerfeld-Straße 1, 38678 Clausthal-Zellerfeld, Germany for Software and Systems Engineering, TU Clausthal, Arnold-Sommerfeld-Straße 1, 38678 Clausthal-Zellerfeld, Germany
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
É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 Abstract About 90% innovations on today’s vehicles are driven by 90% of of the the innovations today’s vehicles are [email protected] by electrics/electronics electrics/electronics or or software software functions. functions. This This shifts shifts the the focus focus from from aa componentcomponent*About Corresponding author. Tel.: +33 on 3 87 37 54 30; E-mailin address: oriented perspective to a function-oriented view engineering. At the same time, descriptions of systems and subsystems are oriented perspective to a function-oriented view in engineering. At the same time, descriptions of systems and subsystems are required required in in order order to coordinate collaboration with suppliers. These different views on the system under development essentially affect requirements engineering. to coordinate collaboration with suppliers. These different views on the system under development essentially affect requirements engineering. On On the the one one hand, hand, information information have have to to be be provided, provided, e.g., e.g., for for requirement requirement specifications specifications for for single single systems. systems. On On the the other other hand, hand, requirements requirements have have to be defined for functions realized on different systems and subsystems. This paper presents a concept for model-based requirement to be defined for functions realized on different systems and subsystems. This paper presents a concept for model-based requirement engineering engineering Abstract supporting supporting to to gather gather and and provide provide requirements requirements needed needed for for different different views views within within the the automotive automotive development development process. process. The The concept concept presented presented is is based on five partial models representing the emerging automotive system from an abstract concept (use cases) to aa solution (system structure). based on five partial models representing the emerging automotive system from an abstract concept (use cases) to solution (system structure). In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of Each of partial namely cases, functions, function realization, system and product are described with regard Eachand of the the partial models, models, namely use use cases,emerged functions, realization, system structure structure and families. product structure structure areand described with regard to to agile reconfigurable production systems to function cope with various products and product To design optimize production required artifacts and their relations based on object-oriented modeling. These artifacts and relations serve for the allocation of requirements or requiredasartifacts and their relations basedproduct on object-oriented modeling. Thesemethods artifactsare andneeded. relations serve for theofallocation of methods requirements or systems well as to choose the optimal matches, product analysis Indeed, most the known aim to can by existing requirements. The proposed concept support different views the system and to structured, can be be specified specified by requirements. The proposedlevel. concept supportproduct different views upon upon the vehicle vehicle system and allow allow to generate generate structured, analyze a product orexisting one product family on the physical Different families, however, may differ largely in terms of the number and consistent documents, like requirements specifications for single systems within the development process. At the same time, the impact of changes consistent documents, like requirements specifications for single systems within the development process. At the same time, the impact of changes nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production concerning single requirements, use or can The of the proposed concept highlighted using the concerning single requirements, use cases, cases,tofunctions functions or systems systems can be beinanalyzed. analyzed. The application application proposed concept is is The highlighted using the system. Aofnew methodology is proposed analyze existing products view of their functional of andthe physical architecture. aim is to cluster example an electric vehicle. example of an electric vehicle. 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 products is analyzed. Functional subassemblies are identified, and cc 2019 The by Elsevier © Authors. 2019 Theanalysis Authors.isPublished Published by Moreover, Elsevier B.V. B.V. aPeer-review functional performed. a committee hybrid functional and physical architecture2019. graph (HyFPAG) is the output which depicts the Peer-review under underresponsibility responsibilityof ofthe thescientific scientific committee ofthe theCIRP CIRP DesignConference Conference 2019. of Design Peer-review under responsibility of the scientific of the CIRP Design Conference 2019. similarity between product families by providingcommittee design support to both, production system planners and product designers. An illustrative Keywords: Model-Based Systems Engineering; Function Modeling;case Design Activities; Development; SysMLcolumns of example of aRequirement nail-clipperEngineering; is used to explain the proposed methodology. An industrial study on twoAutomotive product families of steering Requirement Engineering; Model-Based Systems Engineering; Function Modeling; Design Activities; Automotive Development; SysML Keywords: thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach. © 2017 The Authors. Published by Elsevier B.V. Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018. in challenges when gathering and documenting requirements in
in challenges when gathering and documenting requirements in different different stages stages of of the the development development process process and and different different docdocuments like specification sheets. On the one hand, uments like specification sheets. On the one hand, information information have With have to to be be provided, provided, e.g., e.g., for for requirement requirement specifications specifications for for sinsinWith regard regard to to automotive automotive industry, industry, there there is is an an essential essential gle systems (specification sheet for a specific system like change of innovation drivers: approx. 90% of the innovations on gle systems (specification sheet for a specific system like the the change of innovation drivers: approx. 90% of the innovations on gearbox of the requirements have vehicles gearbox of aa vehicle) vehicle) and on on the other other hand, hand, requirementsand/or have today’s vehicles are are driven driven by by electrics/electronics electrics/electronics or or software software 1.today’s Introduction of the product range and characteristics manufactured to for functions (specification sheet for aa function functions. to be be defined defined for system. functions (specification sheet forchallenge function functions. This This leads leads to to an an increasing increasing shift shift in in the the importance importance assembled in this In this context, the main in like start-stop of a vehicle) realized by different systems and of the individual disciplines within product development [6, 1]. like start-stop a vehicle) realized by different and of Due the individual within product to the disciplines fast development in development the domain[6, 1]. of modelling and of analysis is now not only to cope systems with single subsystems. Whereas were based subsystems. Whereas in in the the past past products were mainly mainly developed based on on communication andproducts an ongoing trend developed of digitization andaa products, a limited product range or existing product families, component-oriented view as well as models documents guided component-oriented view as well as models guided digitalization, manufacturing enterprises aredocuments facing important but also to be able to analyze and to compare products to define by structure, function-oriented deby this this component component structure, nowadays function-oriented dechallenges in today’s marketnowadays environments: a continuing new product families. It can be observed and that classical existing 1.1. 1.1. Model-based Model-based Systems Systems Engineering Engineering and need need of of different different scriptions of the systems become of high relevance. However, scriptionstowards of the systems become of high relevance. times However, tendency reduction of product development and product families are regrouped in function of clients or features. views in development of complex systems views in development of complex systems descriptions of and with regard to their descriptions of systems systems and subsystems subsystems regard their memeshortened product lifecycles. In addition,with there is antoincreasing However, assembly oriented product families are hardly to find. chanical and are required in to coorchanicalofstructure structure and properties properties arethe required in order order coordemand customization, being at same time in atoglobal On the product familyinlevel, products differ mainly in two Product Product development development in automotive automotive engineering engineering is is still still strucstrucdinate collaboration with suppliers. These different views result dinate collaboration with suppliers. These result competition with competitors all over thedifferent world. views This trend, main characteristics: (i)by themilestone-based number of components and (ii) the tured and documented stage gate processes tured and documented by milestone-based stage gate processes which is inducing the development from macro to micro type of components (e.g. mechanical, electrical, electronical). [25]. [25]. Many Many of of the the product product models models used used during during development development ∗ Corresponding markets, results in diminished lot sizes due to augmenting Classical methodologies considering mainly single products pick up component-oriented structures and author. +49 531/391-3304 ∗ Corresponding author. +49 531/391-3304 pick up component-oriented structures and hierarchies hierarchies estabestabE-mailvarieties address: [email protected] (D.production) Inkermann). product (high-volume to low-volume or solitary, existingHowever, product processes families analyze the lished within the and E-mail address: [email protected] (D. Inkermann). [1]. lished withinalready the company. company. However, processes and product product To cope with this augmenting variety as well as to be able to product structure on a physical level (components level) which models are increasingly being adapted to support interdiscimodels are increasingly being adapted to support interdiscic 2019 The optimization 2212-8271 possible Authors. Published by Elsevier B.V. identify in the existing causes difficulties regarding an efficient definition and plinary development. This by established c 2019 The Authors. Publishedpotentials 2212-8271 by Elsevier B.V. plinary2019. development. This is is achieved achieved by adapting adapting established Peer-review under responsibility of the scientific committee of the CIRP Design Conference production system, it is important to have a precise knowledge comparison Peer-review under responsibility of the scientific committee of the CIRP Design Conference 2019. of different product families. Addressing this 1. 1. Introduction Introduction Keywords: Assembly; Design method; Family identification
2212-8271©©2017 2019The The Authors. Published by Elsevier 2212-8271 Authors. Published by Elsevier B.V. B.V. Peer-review under responsibility of scientific the scientific committee theCIRP CIRP Design Conference 2019. Peer-review under responsibility of the committee of the of 28th Design Conference 2018. 10.1016/j.procir.2019.04.345
240
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
interdisciplinary development approaches, as proposed in [24] and the fundamental principles of systems engineering. Furthermore, new and adapted product models like black and white box views or descriptions from a functional perspective are established. These models pick up different views upon the system under development like represented in the MBSE-Grid [17]. Methodologies from Systems Engineering (SE) Model-based Systems Engineering (MBSE) take up the basic elements of system theory [21] and are used to integrate different (engineering) views upon a system. The basic character and goal of the SE is formulated by [10]: “Systems engineering is a consistent, interdisciplinary approach for developing multidisciplinary systems. Not only does it address the system to be developed, but also the associated project.” In addition to this understanding, MBSE aims to document the results of various development activities in a central common system model and supports the generation of context-specific views of this information and relationships. MBSE follows the transition from heterogeneous, document-based product models to consistent and connected product models. Established methods of MBSE are investigated and characterized for example by [8] and [4]. System modeling is of fundamental importance for the MBSE. This modeling is based on the three elements language, tool and method. Existing standards such as UML [19] or SysML [18] define the elements and syntax to be used, while modeling tools such as Enterprise Architect are used to create and analyze the models. These tools support the correct use of language and allow different analyses and views of the model. The languages used within MBSE are of generic character in order to support the representation of different types of systems as well as views of different engineering disciplines.
2
1.3. Focus of research and structure of the paper This paper presents a novel concept for model-based requirement engineering in order to meet current challenges in automotive development. The concept is indented to support a continuous derivation and documentation of requirements as well as deduction of consistent sets of requirements for different views during development of complex systems. A focus is laid on the integration of structure-driven and functional perspectives upon the system under development. The paper is organized as follows: Section 2 briefly presents the state of the art in the field of view-specific system modeling as well as traceability and structuring of requirements. In Section 3 the modelbased concept for processing requirements in automotive product development is described. In Section 4 an exemplary application of the concept in the context of the development of a vehicle’s subsystem is described. Section 5 concludes the paper with a short summary and an outlook. 2. State of the Art The following section gives a brief overview of the state of the art for the topics design stages and views in development and traceability of requirements. 2.1. Design Stages and Views in Development The development of a system can be understood as a step wise extension of the knowledge about the system to be developed (see, e.g., [3]). These different information states processed within a development project, are called design states (see [2, 7]). Eisenbart investigated several development methodologies and identified a number of elementary design states [7]. Each of these design stages can be understood as a specific view of the system under development. In SE and MBSE many established approaches, like RFLP [16] or MBSE-Grid [17] pick up this different views upon the emerging system. These approaches suggest essential description elements (views) for systems under development. For example, the MBSE-Grid introduces 12 different views upon a system. Views at different levels of abstraction (problem and solution space) are proposed for the four areas requirements, behaviour, structure and parametrics. For the requirements area, the views Stakeholder Needs, System Requirements and Component Requirements are differentiated. The established V-model [8] emphasizes different levels of abstraction in system decomposition and description. The focus is on the overall system as well as the necessary perspectives and abstraction levels to describe the system.
1.2. Requirements and Requirements Engineering Requirements engineering (RE) is the first step of many established development processes, such as the V-model (see [8, 16]. The requirements determined within the scope of the RE activities serve, among others, to document wishes and needs of different stakeholders as well as specify boundary conditions, capabilities and characteristics for the system under development [14]. Requirement engineering in the automotive industry becomes a key factor for successful vehicle development due to the described shift of innovation drivers. This is not only accompanied by increasing complexity of the implemented system. Product development itself is becoming more complex due to interrelations between individual components of the vehicle and the corresponding development activities. Previous requirements engineering processes are usually geared towards the creation of document-based requirement specifications for the top (complete vehicle) and bottom (components) levels of the system composition [26] but do not allow effective description of all composition levels. Weber and Weisbord investigated requirement engineering in automotive development for an OEM and point out important problems and fields of action in [26], e.g. combining document-based and model-based RE, avoidance of redundancies, user-specific views and traceability of requirements across multiple hierarchical levels of the systems.
2.2. Traceability of requirements
2
Traceability of artifacts in development processes here is understood in the sense of computer science: “Software artifact traceability is the ability to describe and trace the life of an artifact (requirements, code, tests, models, reports, plans, etc.)
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
that has been developed forward and backward during the software lifecycle.” [12]. This definition can also be used for complex technical systems, such as vehicles. Here, a proper implementation of the traceability of artifacts can give insights into system development and support the general understanding of the system, the impact analysis and reuse of existing artifacts [5]. The traceability of artifacts can thus be divided into two dimensions: vertical and horizontal relations as well as pre- and post-traceability. With regard to horizontal relations, we refer to traceability relations with elements of the same kind of artifact (e.g., relations between requirements). Vertical relations designate relations of an artifact to different other kinds of artifacts (e.g., relation between a requirement and system component) [22, quoted from (Lindvall, Tvedt, & Costa, 2003)]. The second dimension includes pre- and posttraceability, also known as forward and backward traceability [12]. Pre-traceability describes the relationships between requirements and their sources (e.g., stakeholders or use cases), while post-traceability describes the relationships between requirements and artifacts created in later development phases (e.g., component specifications or interface definitions). In addition to the traceability of requirements, their structuring is relevant in order to support access to requirements as well as to enable the generation of specific views for the requirements collective. In literature various approaches for structuring requirements are described, e.g. [9, 20]. These are not conceived for a model-based requirement engineering, but can be adapted to model-based approaches [23, 13]. Furthermore, there are original model-based approaches to requirements engineering, e.g. [23, 27].
241 3
• Complete system description required the functional and structural view. Each view describes different parts of the system and result in different system scopes (differing elements needed to fulfill a function or defining the mechanical setup of a system). • The description of the system has the primary goal to support and uncover the traceability of requirements in the sense of their origin and their relevance for the elements of the partial models. Based on these premises and scopes, the proposed concept supports documentation of requirements for different views and on different levels of abstraction during development. Structure and partial models constituting the model-based concept for requirements engineering are described in the following sections. 3.2. Basic structure of the concept and required partial models The proposed concept constitutes the description of the system under development from a functional and structural view in order to support the requirements engineering within the interdisciplinary development of complex systems like vehicles. A description of the system can be developed differing between three main views, cf. Fig. 1. These views are strongly interconnected and represent essential design stages. The distinction between functional and structural view is picked up form established methodologies in engineering design like [11] focusing on the aspects of functions, structure and behaviour. Thereby, the functional description represents the tasks to be fulfilled as well as the demanded behavior of the system. The structural description comprises the physical representation of the system. Both views are linked by the function realization view. This partial model allocates physical components to the demanded behavior by indicating their contribution to single functions. Based on this basic structure, five partial models are used within this model-based concept to describe the system under development, see Fig. 1. The following Subsections introduce these partial models in detail with regard to content and structure. The modeling is based on the modeling languages UML [19] and SysML [18] with additional stereotypes.
3. Concept for model-based requirement engineering Based on the described challenges and approaches, a concept for model-based requirements engineering in complex system development was developed. The concept is intended to support the requirement engineering during the early phases of the development of automotive subsystems, integrating the structural and functional perspectives on the emerging subsystem. Subsystems, therefore, are understood as complex systems, like the drive train involving different components like drive, gearbox or axis. The subsystem itself is part of the vehicle system and contributes to different functions of the vehicle, like start-stop for instance. 3.1. Premises and scope of the approach The approach was developed based on the following premises and objectives established in automotive industry: • The overall system under development is a single vehicle derivative or a vehicle family (referred to as a system in the following): Relations of the vehicle to its environment (e.g., Car2X communication, connection to cloud based services, etc.) were not considered in this first scope of the concept.
Fig. 1. Basic views and five partial models to structure and describe complex systems from a requirements engineering point of view.
3
3.2.1. Functional view The functional view is implemented by the two partial models, namely Capabilities and Functions. The partial model Ca-
242
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
pabilities describes the capabilities [15], understood as purposes the system is used for as well as tasks that have to be fulfilled by the system under development. These include generic capabilities like acceleration or deceleration as well as specific capabilities like vehicle start off or climate management. The modeling of this partial model is based on the use case modeling of the UML, extending the UML use case via a stereotype <
4
resenting the components that are modeled in the partial model system structure, e.g. traction motor or transmission. To represent elements of the product structure blocks of the SysML extended by the stereotype P-Block and the block definition diagram are used.
Fig. 3. Extract of the system structure of the front drive axis of a BEV.
The partial model system structure contains all components of the system needed to fulfill the defined functions. In this partial model, however, these elements are not arranged in a hierarchical way but strictly functional. Therefore, the elements of the system structure are linked to each other using ports and connectors. Each port has a type attribute that specifies a limited set of relation types needed to describe the intended functions like high voltage, mechanical mounting or communication. These attributes are also applied to specify the connectors linking the ports of the elements. Fig. 3 illustrates an extract for the system structure of the front drive axis of a battery electric vehicle (BEV). For modelling the system structure blocks of the SysML are used and extended by a new stereotype: S-Block. Ports and connectors are also extended by stereotypes to differ between the functional attributes mentioned above. Fig. 2. Describing the functional view on the system by linking capabilities and a function based on activities.
3.2.2. Structural view The structural view of the system comprises the partial models product structure and system structure. The partial model product structure represents the elements of a system structured in a non-functional way. In order to structure the systems and components in this partial model, for instance, brakedown structures of the overall product can be used. However, this structuring in most cases is not driven by functional aspects but existing organizational structures within a company, defining responsibilities for development and taking into account requirements for acquisition of single subsystems and components. The structuring of the elements of the product structure covers a defined number of levels. Here, the later product, e.g. the vehicle, represents the root element and is broken down into subsystems and components. This structuring and definition of system levels is important to locate the system to be described within the overall system as well as to indicate interfaces to neighbouring systems. The last level of the subsystems is rep-
3.2.3. Function realization view To combine the functional and structural views on the system, the partial model function realization is used. Within this model, the previously defined functions are matched to realizing components. For this purpose block definition diagrams of the SysML and additional defined realization objects, extending the SysML blocks, are used. These objects serve as brokers between the functional and structural descriptions of the system. During further development, the functions or subfunctions to be fulfilled by a component can be determined from these relations. The realization objects enable to describe the realization of a function in more detail, as well as to capture dependencies on the level of the function realization between the objects of this partial model. Fig. 4 shows the realization object engine and its connection to the S-Block traction motor as well as the activities ramp up and engine on. 3.3. Allocation and documentation of requirements
4
The described modelling concept serves as a basis to derive and allocate requirements to the single model elements like ca-
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
pabilities, functions or system elements and their interrelations. Requirements are therefore used to specify the elements and relations in each of the partial models and, thus, refine the solution spaces. However, there is no dedicated requirement model, but each partial model contains specific requirements allocated to the elements and relations represented in this partial model. For instance, in the partial model capabilities, the requirements relevant for each capability are modeled focusing on requirements with regard to customer demands and, e.g. legal restrictions. Requirement can also indicate additional capabilities of the future system. Thus, the solution space as well as basic tasks of the system are defined by additional requirements with regard to the performance or scope of single capabilities. In the partial model functions, requirements are specified based on the ones in the partial model capabilities and additional requirements are derived form the required behaviour. The resulting requirements are linked to the functions and activities as well as further elements of the activity diagrams. This procedure is continued for all partial models and results in detailed requirements for each partial model based on the development context and information. By linking the partial models the defined requirements are related to each other. Thus, vertical traceability between requirements and the artifacts of the individual partial models is realized. The single requirements as well as relations between these are modeled using the SysML standard. Thus, the presented concept supports the horizontal (requirement to requirement) and vertical (requirement to other kind of artifacts) traceability. The horizontal traceability of requirements can be supported based on the concept of [23] in combination with the presented system modeling concept. Only the requirement description itself is extended by a partial model-specific stereotype: e.g., <
other elements of the different partial models. The S-Block traction motor is also connected to the realization object engine of the partial model function realization. This, in turn, is connected to activities from the partial model functions (ramp up and engine on). In both partial models, requirements exist that are relevant for the different system elements. For the single elements of the partial models, requirement collectives or context-specific views for individual elements can be derived based on the proposed modelling concept. For instance, the requirements collective for the P-block assy-axis of the product structure can be derived based on the relations as described in the paragraph before. For this purpose, all requirements that are directly connected to the P-block or to the elements of the other partial models are indicated. These requirement collectives can serve as basis for requirement documents like system specification for component suppliers. Furthermore, the modeling concept supports the analysis and evaluation with regard to vertical and horizontal as well as the post-traceability of requirements (cf. Sec. 2.2) relevant for single systems or functions. By linking requirements and elements of the different partial models, identification of associated requirements is enabled when elements are omitted or removed from the model and any derived document. Furthermore, in case of changed systems, impacts to requirements can be indicated based on the model. This ensures consistent requirements in different engineering situations as well as an efficient derivation of specific views on the requirements. Thus, the proposed concept serves as a sound basis to combine model-based and document-based RE within the development of complex systems. 5. Conclusion and further research
4. Application of the concept In order to highlight the application and benefits of the described concept for model-based requirement engineering acquisition and documentation as well as analysis of requirements is explained in this section using the extracts of a battery electric vehicle (BEV). The focus is laid on the explanation of the vertical traceability and the linking between the elements of the individual partial models within the model. Fig. 4 gives a diagram containing essential elements of different partial models as well as requirements associated with these elements. The description of the system based on the proposed modelling concept results in a graph of nodes and edges representing the capabilities, functions, activities, and system elements as well as requirements, c.f. Fig. 4. The different edges represent the relevant links like ”requirement has to be satisfied by block”. The graph can be traversed from any node in order to analyze the given relations. For instance, focusing on the Pblock assy-axis it can be analyzed which other nodes are linked, here traction motor (TM) and gearbox. These nodes of the type S-Block are linked to requirements that are also connected to
243 5
5
In this paper, a novel approach to structure different views in system development focusing on the functional and structural views needed for model-based requirement engineering is presented. Namely, the five partial models capabilities, functions, function realization, product structure, and system structured are used to derive and document requirements from different stakeholders and in different design stages. The requirements are allocated to elements and relations as well as links between the partial models. The direct allocation of the requirements and the linking of the five partial models ensures vertical and horizontal traceability of requirements and enables to derive consistent collectives of requirements for single systems or functions. The proposed approach was developed and initially applied in the context of automotive development and presents an initial concept. It has to be detailed with regard to the modelling of each partial model as well as allocation of requirements. Further research will focus on classification of requirements with regard to the relevance for different system levels taking dependencies between requirements and system structure into account. Moreover, refinement of the allocation of requirements will be part of further research of the modelling concept. To support the application of the proposed concept in industry, processing of the requirements collectives based on a software tool will be investigated. Therefore, the integration of the modelling concept
244
D. Inkermann et al. / Procedia CIRP 84 (2019) 239–244 D. Inkermann et al. / Procedia CIRP 00 (2019) 000–000
6
Fig. 4. Example of modeling the drive components of a BEV with requirements using the introduced approach.
into existing requirement management processes including interfaces to established software for requirements management, e.g. IBM Doors, will be further pursued. Applicability and use of the model-based requirement engineering concept will be evaluated in the field of automotive industry.
[12] Gotel, O.C.Z., Finkelstein, C.W., 1994. An analysis of the requirements traceability problem, in: Proc. of IEEE Int. Conf. on Requirements Engineering, pp. 94–101. doi:10.1109/ICRE.1994.292398. [13] Huth, T., Inkermann, D., Vietor, T., 2017. Ein Ansatz f¨ur eine integrierte modellbasierte Anforderungs- und Variantenmodellierung, in: Gausemeier, J.e. (Ed.), Wissenschaftsforum Intelligente Technische Systeme (WInTeSys), pp. 169–182. [14] ISO/IEC/IEEE International Standard, 2017. ISO/IEC/IEEE 24765:2017(E) - Systems and software engineering–Vocabulary. doi:10.1109/IEEESTD.2017.8016712. [15] J¨arvenp¨aa¨ , E., 2012. Capability-based adaptation of production systems in a changing environment. Tampere University of Technology. [16] Kleiner, S., Kramer, C., 2013. Model Based Design with Systems Engineering Based on RFLP Using V6, in: Abramovici, M., Stark, R. (Eds.), Smart Product Engineering. Springer, Berlin, pp. 93–102. doi:10.1007/ 978-3-642-30817-8_10. [17] Morkevicius, A., Aleksandraviciene, A., Mazeika, D., Bisikirskiene, L., Strolia, Z., 2017. MBSE Grid: A Simplified SysML-Based Approach for Modeling Complex Systems. INCOSE International Symposium 27, 136– 150. doi:10.1002/j.2334-5837.2017.00350.x. [18] Object Management Group, 2017a. OMG Systems Modeling Language (OMG SysMLTM ). URL: https://www.omg.org/spec/SysML/1.5/. [19] Object Management Group, 2017b. OML Unified Modeling Language (OMG UML ). URL: http://www.omg.org/spec/UML/2.5.1. [20] Pohl, K., 2010. Requirements Engineering. Springer, Berlin. doi:10. 1007/978-3-642-12578-2. [21] Ropohl, G. (Ed.), 1975. Systemtechnik - Grundlagen und Anwendung. Hanser, M¨unchen. [22] Smit, K., Zoet, M., and Berkhout, M., . A Framework for Traceability of Legal Requirements in the Dutch Governmental Context, in: BLED 2016 Proceedings. [23] Stechert, C., 2010. Modellierung komplexer Anforderungen. Phd-thesis. TU Braunschweig. Braunschweig. [24] VDI, 2004. VDI 2206 - Entwicklungsmethodik f¨ur mechatronische Systeme. BeuthVerlag, Berlin (2004). [25] Volker, S., Prostean, G., 2016. Research of automotive change management and combined risk-management models. Procedia - Social and Behavioral Sciences 221, 395–404. doi:10.1016/j.sbspro.2016.05.129. [26] Weber, M., Weisbrod, J., 2003. Requirements engineering in automotive development: experiences and challenges. IEEE Software 20, 16–24. doi:10.1109/MS.2003.1159025. [27] Weilkiens, T., 2014. Systems Engineering mit SysML/UML: Anforderungen, Analyse, Architektur. 3 ed., dpunkt.verl., Heidelberg.
References [1] Anderl, R., Eigner, M., Sendler, U., Stark, R., 2012. Smart Engineering: Interdisziplin¨are Produktentstehung. acatech DISKUSSION, Springer, Berlin. doi:10.1007/978-3-642-29372-6. [2] Blessing, L.T.M., 1995. Comparison of design models proposed in prescriptive literature. The role of design in the spaping of technology, COST A3/COST A4 International research workshop URL: https://ci.nii. ac.jp/naid/10015770748/en/. [3] Browning, T.R., Deyst, J.J., Eppinger, S.D., Whitney, D.E., 2002. Adding value in product development by creating information and reducing risk. IEEE Transactions on Engineering Management 49, 443–458. doi:10. 1109/TEM.2002.806710. [4] Browning, T.R., Fricke, E., Negele, H., 2006. Key concepts in modeling product development processes. Systems Engineering 9, 104–128. doi:10. 1002/sys.20047. [5] D¨omges, R., Pohl, K., 1998. Adapting Traceability Environments to Project-specific Needs. Commun. ACM 41, 54–62. doi:10.1145/ 290133.290149. [6] Eigner, M., Roubanov, D., Zafirov, R., 2014. Modellbasierte virtuelle Produktentwicklung. Springer Vieweg, Berlin. doi:10.1007/ 978-3-662-43816-9. [7] Eisenbart, B., 2014. Supporting Interdisciplinary System Development Through Integrated Function Modelling. Phd-thesis. Universit´e du Luxembourg. Luxembourg. [8] Estefan, J.A., 2008. Survey of model-based systems engineering (mbse) methodologies 25. URL: https://www.omg.org/MBSE_Methodology_ Survey_RevB.pdf. [9] Feldhusen, J., Grote, K.H., Pahl, G., Beitz, W. (Eds.), 2013. Konstruktionslehre: Methoden und Anwendung erfolgreicher Produktentwicklung. 8 ed., Springer Vieweg, Berlin. doi:10.1007/978-3-642-29569-0. [10] Gausemeier, J., Dumitrescu, R., Steffen, D., Czaja, A., Wiederkehr, O., Tschirner, C., 2015. Systems Engineering in Industrial Practice, Paderborn, Germany. [11] Gero, J., 1990. Design prototypes a knowledge representation schema for design. AI Magazine 11, 26–36.
6