An Approach to Complement Model-Based Vehicle Development by Implementing Future Scenarios

Abstract

Today, vehicle development is already in a process of substantial transformation. Mobility trends can be derived from global megatrends and have a significant influence on the requirements of the developed vehicles. The sociological, technological, economic, ecological, and political developments can be determined by using the scenario technique. The results are recorded in the form of differently shaped scenarios; however, they are mainly document-based. In order to ensure a holistic approach in the sense of model-based systems engineering and to be able to trace the interrelationships of the fast-changing trends and requirements, it is necessary to implement future scenarios in the system model. For this purpose, a method is proposed that enables the consideration of future scenarios in model-based vehicle development. The procedure of the method is presented, and the location of the future scenarios within the system architectures is named. The method is applied and the resulting system views are derived based on the application example of an autonomous people mover. With the help of the described method, it is possible to show the effects of a change of scenario (e.g., best-case and worst-case) and the connections with the highest level of requirements: stakeholder needs.

1. Introduction

Until the beginning of the Corona pandemic, the acronyms CASE (Daimler, Stuttgart, Germany), EASCY (PricewaterhouseCoopers GmbH, Frankfurt, Germany), and ACES (McKinsey & Company, Inc., Düsseldorf, Germany) were still regarded as pointing the way to the mobility of the future. While the automation of the vehicle and the associated connectivity continues to be regarded as trendsetting, and the electrification of the powertrain also remains undisputed due to EU legislation on CO₂ reduction, disruption seems to be emerging for the future trend of sharing [1,2,3].

Worldwide, the number of sharing services in use has declined significantly. According to McKinsey, the decline in shared rides in 2020 was between 60 and 70% [4]. In the long term, this trend break will also have an impact on people’s sharing mentality and their need for safety, and therefore on the business models in this area, as well as on the vehicles themselves. However, the actual development can run in different directions: A best-case scenario could still be assumed, in which a great need for sharing (instead of owning) still exists, or, in the worst-case, this trend is weakened, perhaps even reversed, toward a concept in which the user is also the owner of the vehicle. How does the overall vehicle concept change for such a case? And what impact does the change in the scenario have on vehicle functions and components?

Systems engineering deals with the interdisciplinary development and implementation of technical systems. The assumption is that the system is not merely the sum of its elements but is defined by their interrelationships [5]. A global abstract meta-model does exist that describes the interrelationships and interactions of the individual elements, and it is called Model-Based Systems Engineering (MBSE). The classical requirement management takes place in the MBSE process in the form of requirement engineering (RE), and covers, not only the collection and documentation of requirements, but also the validation and verification over different requirement levels [6]. A significant advantage of MBSE, compared to a document-based approach, is that all information about the system is captured in a holistic system model and can be presented to the respective addressee in a user-friendly manner via different views [7,8].

The automotive industry is also moving away from a component-based view toward a function-oriented and holistic development of systems and subsystems [9]. One of the reasons for this is the steady increase in the proportion of software in modern vehicles, which in turn means that functions can no longer be assigned to a single component or a specific assembly. The resulting increase in networking and interaction between individual functions leads to an increase in the complexity of the so-called “system of interest” (SOI) vehicle. With an increase in the digitalization of the vehicle towards networked and autonomous “driving computers”, the complexity of the SOI itself increases, but at the same time, the influences and interactions of/with the surrounding system also increase.

In the surrounding system, technology and social trends that define the boundary conditions of the future mobility system have a significant influence on the requirements and characteristics of the vehicles to be developed. However, uncertainty about such trends and changes in the surrounding system, such as the importance of car sharing instead of ownership, is very high. Therefore, the scenario technique is a well-known tool for estimating and interpreting future scenarios, which is used in strategic corporate management, but also in product development. However, it has not yet been applied in model-based requirements engineering.

For a detailed recording of scenarios, it is necessary to record several scenarios in different forms (e.g., best-/worst-case). These future scenarios provide the starting point for various use cases that take place in the future. Classically, these future scenarios are still recorded on a document basis. However, to make the possible connections and effects of changes in the scenario on elements of the SOI clear and to make the resulting or influenced requirements visible, it is necessary to make them part of the system model, in the sense of an MBSE approach to requirement elicitation.

The goal of this paper is to present the approach of scenario modeling in the MBSE. For this purpose, existing methods for requirements engineering are first described, which are then supplemented by the modeling step of future scenarios. Section 2 concludes with a classification in the overall model, before the described approach is applied in Section 3 to the concrete application example of a “people mover”. Assuming that social attitudes such as ecological awareness, sharing mentality, or openness of the population to a technology change, the effects on the requirements are presented. After a discussion of the results in Section 4, the paper ends with a summary and an outlook for further action.

2. Methodology

In the early development stages of the automotive product creation process, also known as the concept phase, the essential foundation is laid for further development. This is therefore the special focus of the following considerations. Classic document-based approaches start the concept phase with the initial ideation of a product vision, which is documented at the end of the phase in the form of concrete specifications. The identification of future social developments and trends is as important as the customer requirements themselves. Both are essential prerequisites for defining the target area for the vehicle to be developed [10] (p. 1276). With the increasing digitalization of the automobile, interdisciplinary development approaches are also becoming part of the overall vehicle development [9]. As a guideline, VDI 2206 should be mentioned here, which describes a development methodology for mechatronic systems and also represents it graphically in the form of the V-model [11]. With the increase in complexity of the technical system automobile, a tendency towards systems engineering approaches within automotive development can be identified. In addition to the V-model, there are other approaches, such as the requirement, functions, logical, and physical (RFLP) approach, but also quality standards such as Automotive SPICE, which emphasize the high importance of requirements elicitation and the analysis of system requirements, even in the early phase of development [12].

Requirement engineering plays an essential role within every development project. Its primary task is the elicitation, documentation, and management of requirements. Inadequately captured requirements can lead to an inadequate product that is developed past the market and the customer. However, requirements management is not a process that occurs exclusively at the beginning of a development project but must be tracked continuously throughout the entire product development process. For the uncomplicated modification and traceability of requirements, a model-based procedure, as is the case in model-based systems engineering, is a good alternative to a document-based procedure [13].

The basic idea of systems engineering is related to systems thinking—the conception of the product to be developed, in this case, the vehicle, as a system. This system of interest (SOI), which can itself be subdivided into subsystems, is in a superordinate system and simultaneously acts with neighboring systems outside the system boundaries [5,7].

Model-based Systems Engineering (MBSE) focuses on an interdisciplinary, descriptive system model that captures the interrelationships and basic ideas of systems engineering [7]. The graphical modeling language System Modeling Language (SysML), developed for this purpose, can be used for representation. This is a further development of the UML, whereby the four key aspects of a system can be represented: Structure, Behavior, Requirements, and Parametrics. These views of the system represent the subsystems, their elements, and interconnections, which allows the system to be viewed from different, domain-specific views [8].

Morkevicius combines the four pillars of SysML with a level of abstraction (black box, white box, and solution) to span a matrix: the MBSE Grid framework. This framework allows the relation of the different diagram types and system representations, such as stakeholder needs, use case, or system context (all on black-box level) to get a structured overall picture of the system model [14].

The system context includes the entire relevant environment of the system, as well as stakeholders that interact with the system. This is a structural view of the system [13].

The use cases, on the other hand, describe the interaction of the user (or respective stakeholder) with the system in detailed activities. At the most abstract level (the black box level) of the requirements view, there are the stakeholder needs, i.e., requirements or expectations that originate directly from the respective stakeholders [15].

Scenario analysis is mainly known from strategic product planning and can also be used as a method in requirements engineering for eliciting requirements. It is based on two fundamental assumptions: There are multiple futures or alternative development possibilities based on networked thinking, i.e., the assumption that a complex network of influencing factors exists that influence each other and have an effect on the development of the future. This makes it possible, for example, to depict best-case and worst-case scenarios. The development of the future results from the representation of selected parameters, the descriptors, which can come from Sociological, Technological, Ecological, Economic, or Political areas (STEEP-factors), i.e., from the system of the (wide) country environment. These can have different characteristics or values, depending on the development in the named areas. By a combination of selected descriptor characteristics to a set, different scenarios, e.g., also best- or worst-case scenarios, can be represented [16].

To ensure holistic requirements engineering and to be able to consider the effects of possible trend changes or even trend breaks at an early stage, it is necessary to integrate the future scenarios into the system model.

A starting point for the integration of future scenarios into the system model is a different approach for implementing requirements engineering within an MBSE-based approach. According to Friedenthal [17], the following steps are taken to determine the model architecture in the first step: definition of the system context, naming of stakeholders, and description of use cases. This allows the stakeholder needs to be determined, which represents the most abstract version of the requirements for the system. From these, more concrete system requirements and ultimately component requirements can be derived in further procedure [8].

There is a system modeling toolbox, SYSMOD [18], that describes a procedure whose main components are requirements elicitation, system context description, description of use cases and use case flows, and modeling of domain knowledge. This already contains aspects of the future scenario, but these are not yet variably (best-case/worst-case) executed [19] (p. 75).

The future scenario, which is intended to be integrated into the system model, can be distinguished from the use case and system context as follows: While the system context describes the relationship between environmental systems and stakeholders with the SOI, and the use case describes the interaction between the user and the SOI, the future scenario is a description of the environmental system, in this case, the mobility system, in which the SOI is located. It is therefore a system-of-systems approach. The scenario can refer to the system context or have a concrete influence on the characteristics of the elements it contains. Of course, the scenario can also decide whether a use case can be realized at all in the described future. However, the scenario has a strong influence on the stakeholder needs, whereby the sociological descriptors emphasized here are particularly relevant. At this black box level, the influences of the future scenario on stakeholder needs can be presented. However, a concrete change of the elements or their values only takes place at the white box level, i.e., in the form of a change of the system requirements [20]. Figure 1 hierarchically shows the system architecture, including the black box, white box, and component-level with the views to the system (requirements, behavior, and structure).

The descriptors (d₁, …, d_n+1) are sectioned by the STEEP factors, and their impact on the stakeholder needs, the use case, and the system context is visualized. The red arrows schematically show the relationships between the descriptors and other system elements. In this case, the descriptors d₁ and d₂, both from the sociological domain, are linked to the stakeholder needs and the use case. Another descriptor, d₈, from the environmental domain is related to the system context (e.g., the infrastructure or another adjacent system).

Figure 2 represents the devised procedure for the implementation of the future scenarios in the model-based system architecture. This make them an integral part of the system model. The first step is to identify the known stakeholders and to determine their needs. In addition to the user of the system, these could also be other groups of people or organizations, such as clients or operating companies. The output of this first step are the requirements, captured in the form of a requirements diagram, which can be continuously complemented by further points throughout the method. In the second step, the main use case is modeled, i.e., the one that describes the user’s interaction with the system. Once this is known, the system context can be modeled in step three. The stakeholders from step one also reappear in the system context diagram and are added to it. In addition, adjacent or neighboring systems are described here. With increasing knowledge about the system to be designed, further stakeholder needs can be recorded at any time within the described procedure, and additional relevant use cases can also be modeled. In step four, several future scenarios are modeled (in this case, expressions A and B). For this purpose, it is recommended to structure the scenario using STEEP factors, as mentioned in Figure 1.

By using the described methodology, future scenarios can be converted into a descriptive system model in the sense of the scenario technique. Global megatrends (urbanization, ageing society, etc.) extend over periods of several decades. The mobility trends named here (cf. CASE from Section 1) can be derived from this. However, these are sector trends that tend to cover short periods of time of a few years [21].

Considering the existing product development processes in the automotive industry, which last on average for about 4 years, the mobility trends ultimately have a more significant influence on the SOI. The developed approach can therefore be classified rather in the area of short-term analysis.

The individual steps of the procedure can also be iterated in order to take newly gained knowledge into account in previous steps. The detailed application and evaluation of the methodology are carried out in Section 3 using the use case of an autonomous, electrically driven people mover.

3. Results

The ERDF innovation network autoMoVe is coordinated by the Lower Saxony Research Center for Vehicle Technology (NFF—Niedersächsisches Forschungszentrum Fahrzeugtechnik, Braunschweig, Germany). The project runs over three years and pursues the goal of developing dynamically configurable vehicle concepts for autonomous driving. By exchanging application-specific modules, a wide range of applications, from internal goods transport to passenger transport on the road, are to be carried out autonomously. One of the possible use cases is passenger transport from the NFF to the main campus of the Technical University of Braunschweig. The dynamically configurable autonomous vehicle (DCAV), equipped with the “people mover” module, should be able to transport up to six students or employees of the TU Braunschweig [22].

The development of the DCAV is based on the fully automated and electrified platform PLUTO [23]. This platform serves as a starting point for the development of the people mover module. Figure 3 shows the first overall vehicle concept for the dynamically configurable autonomous vehicle developed in the ERDF innovation network autoMoVe. The people mover module was designed in collaboration with Formherr industrial designers specifically for the use case of a people shuttle from the NFF to the main campus.

In times of climate change, it is necessary to find concepts to reduce emissions from the transport sector and further increase efficiency. The people mover is a sustainable and also an efficient solution. The electric car sharing concept reduces emissions, which is good for the environment. In addition, passengers can use their time more efficiently. To plan and estimate the application of the people mover, it is necessary to describe and understand future mobility systems. A mobility system is the totality of all transport modes and participants, the relevant infrastructure, and all software systems and applications that are relevant for the operation or implementation of mobility services [24]. The concrete manifestations of these subsystems can be represented, at any point in time, in the form of future scenarios. According to STEEP analysis, the scenarios can be structured by the factors from the areas of Society (S), Technology (T), Economy (E), Ecology (E), and Politics (P) [25] (p. 21). The scenario presented in this application example should initially refer to the Central European region. The concrete point in time in which this scenario takes place is currently irrelevant; much more essential are the associated boundary conditions for the system of interest.

In the following, the procedure for modeling and implementing future scenarios in a SE-based, descriptive system model is described. The procedure consists of the four steps presented in Figure 2: identification of stakeholders and their needs, the definition of use cases, system context, and scenario modeling.

For successful product development, knowledge about customer and user needs or requirements is a prerequisite. Requirements represent the conditions or capabilities that a system has to solve, or what a system should do under certain conditions [26]. For methodical implementation, the first step is therefore to identify the relevant stakeholders and to determine the concise requirements for the SOI. Stakeholders are individuals or groups with interest and involvement in a project or the development and production of a system [9]. Stakeholders can influence the framework of the system being developed and therefore must be considered as well. Therefore, the “stakeholders” and their “requirements” are highly interdependent and must be identified in parallel. (Step 1 and 1b in Figure 2).

3.1. Identify Stakeholders

The commissioning parties of the autoMoVe research project represent the first group of stakeholders. This is the ERDF innovation network, consisting of the TU Braunschweig (Institute of Design Technology and Institute of Automotive Engineering, Braunschweig, Germany), TU Clausthal (Institute of Software and Systems Engineering, Clausthal, Germany), and Ostfalia HaW (Institute of Mechatronics, Wolfenbüttel, Germany).

The Technical University of Braunschweig, therefore, represents a stakeholder in this use case. Its goal is to provide students and employees with other means of transportation besides bus and train and to offer an innovative, progressive, and sustainable mobility solution. The NFF, as one of the most modern centers for mobility research at a German university, builds on a broad and structurally anchored interdisciplinary collaboration from natural and engineering sciences as well as economics and social sciences. Only through interdisciplinary cooperation is it possible to conduct sustainable mobility research in all facets. The people mover makes it easier for all members of the Technical University of Braunschweig to reach the NFF, supporting successful cross-disciplinary collaboration.

For the TU Braunschweig, the linking of the main campus with the NFF also physically offers an improved link between research and teaching. Thus, students of the Technical University Braunschweig can also be transported autonomously and electrically between the NFF and the main campus of the Technical University Braunschweig by the people mover. Lectures at both locations can be attended, which improves the relation of the theoretically taught content to practical activities.

Legislators can be singled out as another stakeholder. In this case, this includes both regional and supra-regional legislative representatives, i.e., both the city of Braunschweig and the state of Lower Saxony, but also the Federal Republic of Germany. These focus on compliance with the legal framework and that there is no negative effect on the roads due to the new road user. In addition, it is the declared goal to protect all other road users, who thus represent the last group of stakeholders. This group includes all participants in public road transport, i.e., all motorists, cyclists, and pedestrians.

In total, six stakeholders were identified as significant: (1) the ERDF innovation network as the contracting authority; (2) the Technical University of Braunschweig, whose campus is thereby connected; (3) the students who would primarily commute for lectures, seminars, etc.; (4) all other members of the TU Braunschweig, for whom the shuttle could facilitate a transfer with NFF.; (5) all other road users; and (6) the legislator, who has to create the general framework. Based on this, it is now necessary to derive the requirements for the SOI.

3.2. Determination of the Stakeholder Needs

For the use case of the people mover, the electric and autonomous transport of passengers represents two essential requirements. These are primarily named by the clients of the project, the ERDF innovation network. The Technical University of Braunschweig also has the requirement for the people mover that all members of the university can be transported between the main campus and the NFF as efficiently and sustainably as possible. The electric driving and sustainable production of the people mover, in particular, is also a concise requirement for legislators. The German government has decided to reduce the energy demand in the transport sector by 40% (compared to 2005) by 2050 and aims to drastically reduce the dependence of the transport sector on oil. Electric vehicles, among other things, are expected to help achieve this [27]. For the legislator as well as for the TU Braunschweig, it is necessary to have a legal basis for autonomous driving. It is necessary to determine who must assume liability in the event of damage. It is also necessary to clarify how the vehicle will behave in the event of an imminent crash and how it can communicate or interact with all other road users. Without this legal framework, the people mover will not be feasible.

For all other traffic participants, the people mover must not cause traffic congestion. This requirement is also set by the city of Braunschweig, representing the legislator, because congested roads significantly increase pollution in cities, and the probability of collisions increases due to an increased traffic volume [28]. For this reason, the safety aspect is an essential requirement for all road users. These include other, non-autonomously driving, vehicles as well as pedestrians and cyclists, who must not be endangered in any way by the people mover.

The aspect of safety, of course, also concerns all occupants of the people mover, i.e., the students and all employees of the TU Braunschweig. For many people, the safety aspect of autonomous vehicles is a major concern [29]. To alleviate the occupants’ concerns, it is important to ensure the most comfortable transport possible. Only if people feel comfortable and trust the autonomous vehicle can the widespread aversion to autonomous vehicles be diminished [30]. Another requirement for all people mover users is reliable operation. Reliability, in this case, means both that the vehicle is always operational and charged, and that there are no major delays on the route. For example, it should be able to avoid a traffic jam to arrive at its destination on time. Often, there are only a few minutes between lectures or appointments, during which it must be possible to change location.

In addition to transporting people between the main campus and the NFF, which should be autonomous and electric, the vehicle must be safe, comfortable, and reliable. It should also be designed to be sustainable. The use of the people mover must not overload the road network and there must be a legal basis. In total, nine concise requirements can be identified which, together with the associated stakeholders, can be taken from Figure 4. Following this, use cases can now be defined and modeled in the next step.

3.3. Modeling of the Use Case

Following the stakeholder analysis and the derivation of stakeholder needs, the second step is to model the use case of the people mover. A use case provides a high-level abstraction and a clear overview of how the system as a whole can be used by external entities [31]. All goals, expectations, and activities relevant to the users are modeled. The use cases represent the services of the system and are thus central elements of the requirements analysis [15] (p. 88). These can be derived primarily from the “stakeholder needs” that have just been developed. A use case can be defined as the “[…] set of actions of a system that lead to an observable event that […] has value for the stakeholders.” [15] (p. 231).

The system use case, in this case, is autonomous electric transportation between the NFF and the campus of the Technical University of Braunschweig. Passengers are to board the vehicle, where it is then to determine whether they are members of the Technical University Braunschweig. The people mover can check this after reading the TU membership card, via communication with the server. If this is the case, the shuttle autonomously transports the occupants between the NFF and the campus. It must be ensured that the schedule is always adhered to. This is necessary because lectures, as well as appointments, require a punctual arrival. At the destination, the occupants have to leave the people mover again.

To ensure a trouble-free journey, the people mover must be regularly recharged. In addition, the vehicle must be easy to enter and inspect.

These different use cases can be related to each other by classification, inclusion, and extension [8] (p. 289). The relation <<inclusion>> makes it possible to implement the functionality of another use case. The included use case is always executed when the base use case is executed. In this case, this includes boarding and exiting the vehicle, as well as schedule control and identity verification. All of these use cases necessarily belong to the use case of exclusive transportation of TU members between the NFF and the campus. In the model, these relationships are denoted by <<include>>.

In addition to the basic use cases, there are also extended use cases. These only occur under certain conditions and depend on the behavior of the basic applications. In the case of the people mover, extended use cases are cleaning and inspecting, as well as charging the vehicle. These cases only occur under certain conditions, for example, when the battery is empty, or the interior is dirty. This relationship is marked with <<extend>> in the use case diagram.

The direction of the arrows in the diagram should be understood as including the rear end or extending the front end. Thus, a base use case includes an included use case, and an extended use case extends a base use case [8] (p. 300).

The representation of the use case, together with the system context modeled below, can be seen in Figure 5.

3.4. System Context Modeling

The system context is modeled in the third step and describes how the system interacts with its environment. This allows the identification of interfaces, interactions, and relationships between the system, in this case, the people mover, and its environment. A system can be defined as “a human-made artifact consisting of system building blocks that work together to achieve a common goal. A building block can be software, hardware, a person, or any other entity.” Delineating and therefore answering the question of what is part of the system is fundamental to further consideration and modeling of the system [15] (p. 66).

At the center of the model is the system of interest, in this case, the people mover. This is considered as a black box to identify the interaction partners who are outside the system. The interaction partners are called actors. These do not comprise a concrete system or person, but a role in the system context [15] (p. 67). For a better understanding, these can be divided more coarsely.

The first group are the users. These are the human actors that interact directly with the system [15] (p. 360). In the case of the people mover, these are the occupants, i.e., the students and all TU members. The remaining stakeholders, such as legislators (see “Identification of stakeholders”) also interact with the system. However, these are not individual persons, but systems of their own—so-called external systems. These are considered only as a black box in this model. In addition to the stakeholders mentioned above, they also include the charging infrastructure. (cf. Figure 5).

Sensors are a special type of external system. These pick up information from the environment and pass it on to the system. These include road signs and traffic lights, and also the GPS signal, which enables the vehicle to find its way autonomously in road traffic by querying its exact position. In addition, actuators belong to the external systems as a special type. These serve the considered system, the people mover. The connection to the server enables the system to perform passenger control.

Some factors from the environment also influence the system, but without interacting with it directly. Among these environmental effects is the weather, including temperature and precipitation. They also include general road conditions, such as potholes, and road conditions such as accidents, closures, etc.

3.5. Modeling Scenarios

The fourth step is the representation and modeling of the future scenario. To do this, descriptors that span the future scenario must first be defined. These descriptors can be systematized with the help of STEEP analysis. This comprises the Sociological, Technological, Economical, Environmental, and Political framework conditions [25] (p. 21). The sociological framework conditions concern the values and norms of society [32]. Examples of this area include the population’s openness to technology, their sharing mentality, and their ecological awareness. The technological framework includes new technological developments and their impact on the mobility sector [33]. The economic framework concerns the overall economic situation. In the case of the electrified autonomous shuttle, monetary incentives or electricity or alternative mobility costs are particularly relevant. The environmental framework covers emission targets, as well as data and charging infrastructure. The legal framework and its enforcement, such as Road Traffic Regulations, are summarized as political framework conditions. The complete list of used descriptors can be found in Figure A1 in Appendix A. For a holistic view, all descriptors relevant to the considered system have to be assigned to the respective framework. At the Institute of Engineering Design, a cross-project team developed a “vision board”. The aim of the project was to determine relevant parameters for the universal description of mobility systems and their environment. For this purpose, various studies and publications were evaluated, the relevant descriptors determined, and their different characteristics recorded for various future scenarios.

To clarify the procedure and to illustrate the subsequent interactions between descriptors and requirements, the socio-cultural framework will serve as an example for the people mover use case. Here, one of the most decisive socio-cultural descriptors is ecological awareness. The ecological awareness of the population, and thus also of the users of the people mover, influences, among other things, the demand for sustainable, emission-free mobility systems. In addition, another decisive descriptor is the sharing mentality, which has a significant influence on the success of an autonomous shuttle. In addition, openness and trust toward new technology determine the extent to which people will embrace a new mobility concept without drivers and their control. These three sociological descriptors will serve to clarify the approach of this thesis.

In the best-case scenario for the people mover, the demand for autonomous, sustainable, and low-emission mobility systems is very high. Thus, the previously described socio-cultural descriptors ecological awareness, sharing mentality, and openness to technology show a high level of expression. The opposite is the case in the worst-case scenario, where all of them have a low expression.

3.6. Interactions Between Scenario and Requirements

In the next step, the two scenarios, described through descriptors, are linked to the stakeholder needs of the system model—this is the only way to show which requirement is influenced by which external trend. The concrete relationships between selected requirements and descriptors can be seen in Figure A2 in Appendix A. However, showing a general correlation does not say much per se; rather, it is important to compare different scenarios, and thus the different expressions of the descriptors, to be able to uncover possible effects on the SOI from the variances (see the output of point 4 in Figure 2). This allows a design team to estimate the impact of changes and to consider them to an appropriate degree early in the development process. This improves the design engineers’ decisions under uncertainty [34]. These variances can be taken into account by considering best- and worst-case scenarios. This allows different impacts on stakeholder requirements to be presented. The two above-mentioned scenarios for the people mover have very different effects on the requirements of the stakeholders. These can be represented by implementing << dependency>> depending on the respective scenario.

In the best-case scenario, strong ecological awareness leads to a demand for electric driving, avoiding traffic increases—to avoid emissions as well as the desire for sustainable solutions. The situation is different in the worst-case scenario. More important than the question of propulsion or sustainability is the question of the comfort of the means of transport. It is the same with the descriptor “sharing mentality”. While a weak expression of this descriptor leads to the fact that safe travel is primarily important, a strong expression mainly focuses on sustainability. A high level of openness to technology results in greater demand for autonomous and electric driving, partly due to greater trust. Lack of trust, as in the worst-case scenario, results in increased demands for convenience and legal basis to make occupants feel safer. In addition, fewer failures are tolerated and a higher standard of safety is expected. These different scenarios can thus be integrated into the system architecture model. The different impacts of a best-case and a worst-case scenario on stakeholder needs can be seen in Figure 6.

By implementing scenarios in the system architecture model, scenario-oriented requirements, functions, or even structures of the people mover can be developed, and thus risks for uncertain events or trends can also be reduced. A holistic understanding of the system to be developed, the different perspectives, and the influences of the scenarios, as well as how to avoid redundant data, drastically reduces the complexity of the development process in an agile and volatile environment [20].

4. Discussion

Model-based systems engineering has been used in the automotive industry for some time to handle complex systems, in this case, vehicles. It enables the visualization of system interrelationships, even beyond the boundaries of individual development departments. The focus is on the common system model, which represents the SOI, its subsystems, and elements as well as their interrelationships from different views. To be able to better assess future developments and the resulting risks, this article describes a method that makes it possible to implement future scenarios in a model-based vehicle development procedure.

Section 2 describes the development of the method itself, including relevant basics from literature and research. In this context, special attention was paid to procedures from requirements engineering. A sequential process for modeling the system model and the future scenarios was presented. Furthermore, a classification of the future scenarios in the MBSE grid, a holistic framework for the handling of system models according to Morkevicius, took place.

In Section 3, the application of the method was successfully implemented on the concrete example of a people mover. Under the assumption that the technology openness, sharing mentality, and ecological awareness of the users are strongly or less strongly pronounced in different futures, the connections to the respective requirements were shown. The framework for this comes from the autoMoVe research project, in which dynamically configurable and autonomous vehicle concepts are being conceived. The use case of the people mover, which connects the Braunschweig NFF with the main campus of the Technical University, is based on the assumption that autonomous driving of at least SAE level 4 is permitted in public spaces. Furthermore, the necessary data infrastructure must be available to implement Car2Car or Car2Infrastructure communication, for example. Taking current forecasts into account, such a future at the earliest is expected for 2025 [24], whereby the high number of limiting factors rather speaks for a long-term future scenario. Accordingly, the differences between the characteristics of the descriptors can be large. Nevertheless, the interactions within the model and its chosen architecture can be depicted sufficiently well. It is important to mention that the origin of the data and information used in the future scenarios must be clarified. It must be verified that they are appropriate descriptors for the transport system under consideration. This should have been determined using an evaluation system. Often, this is data from companies that pursue their own interests or want to support their arguments. [21] (125 ff.) The quality of the subsequent forecast is directly dependent on the implemented scenarios; therefore, a major focus should be placed on this. In this paper, the internal scenarios and descriptors of the so-called vision board were used for the illustrative examples.

Especially, the effects of the descriptors from the socio-cultural area on the stakeholder needs could be mapped on the black-box level. Descriptors with a technological or economic background could be mapped directly to the system context, and then, via the detour of the use case and the interaction of the stakeholder with the vehicle, also to the stakeholder needs. It is expected that these effects will become even more apparent at a more concrete requirements level. In the further course of the autoMoVe project, requirements will first be derived from the stakeholder needs at the system level, and finally at the component level. This will show whether the links to the descriptors and their characteristics will become even more apparent, especially at the non-socio-cultural level.

The structure of the system model was based mainly on the theory of the four pillars of SysML and the level structure according to MBSE-Grid (black box, white box, solution). In addition, other approaches exist, such as the RFLP approach. In further work, it is to be examined to what extent the considerations made here can be transferred to these. The software Enterprise Architect (Sparx Systems) was chosen for modeling. This software allows the description of systems in common modeling languages (e.g., UML or SysML) and the integration of common Microsoft Office documents via further add-ins. To make the selected classes of the descriptors as well as their best- and worst-case characteristics even clearer for the user, it would be desirable to define ones’ own classes. The choice of another software (e.g., Cameo Systems Modeler from Dassault Systems) would also be conceivable. This offers existing solutions for the representation of variants and variances via the integration of the SYSMOD Add-In.

The SysML models are graphical or descriptive. It seemed desirable in the modeling process to also pass parameters or to map mathematical relationships between two elements. Simple Matlab-Simulink models could be linked here to provide assistance. Other approaches, such as those from the discipline of system dynamics, would even be able to fully simulate complex or dynamic systems. One thinks here of the results of the Club of Rome to “The Limits of Growth” from the year 1972 [35]. A system model that is not only able to name the interdependencies but also to quantify them, seems tempting at first sight. However, if one considers the modeling effort and the basic idea of modeling, namely the abstraction of reality to the extent that it serves the desired benefit, it becomes clear that a clear demarcation must be made at this point.

The system model supports the cross-domain understanding of the system, its sub-systems, and components, as well as their interrelationships. For the calculation and simulation, it is left to the individual disciplines to implement these more detailed steps using further, domain-specific models. A declared goal of the modeling of future scenarios undertaken here is the transfer of the basic framework and the descriptors, and also their characteristics, to as many other development tasks as possible. In the autoMoVe project, this procedure should therefore be transferable to all other vehicle superstructures and the associated use cases. At best, the procedure can also be transferred to other projects dealing with the conception of autonomous driving vehicles. However, it would be desirable to further develop the future scenario model so that it can be applied to any mobility carrier in any mobility system. Looking beyond vehicle development from a purely de-sign-methodological perspective, this approach should also apply to classic non-automotive product development.

In order to identify the stakeholder needs, user-centered creativity methods were applied. In particular, the persona method, which is derived from the field of design thinking, was used to describe the stakeholders, in this case, the students. This involves a detailed description of the stakeholders as well as their pains and gains, which are worked out in joint creative workshops. In the future, it would be conceivable to make this process part of the MBSE-based method and to describe and document the personas within the system model, instead of it being document-based as before. In this way, customer wishes could be preserved in the model and their connections to the technical requirements could be shown. User-centered development or stakeholder-centered development leads to a high degree of usability and thus more successful products on the market.