Computer aided derivation of vehicle modules and functions from use cases in order to create user orientated vehicle interior concepts

Trends such as autonomous driving, non-driving related activities and digitalisation are contributing to a revolution in vehicle concept design. An aspect of this is the consideration of future use cases in shaping vehicle architectures. Future user scenarios can help identify relevant use cases, from which the user needs and system requirements can be derived. The derived requirements need to be matched to vehicle functions and architectural modules that can fulfil them. However, the optimal combination of functions and modules can be difficult to identify due to the numerous possibilities. The aim of this paper is to apply a matrix-based methodology that enables the systematic matching of requirements to vehicle functions and/or modules, as well as the identification of an ideal module/function combination for all the considered requirements. An example is presented that considers a requirement specification that has been derived from predetermined user needs. The requirements are matched to suitable functions/modules and the best possible combinations are determined using the proposed matrix-based methodology. Two optimal combinations are selected, one for a vehicle in the entry level segment and the other for a premium vehicle. The results indicate it is possible to determine an optimal combination for both vehicle segments considered, as well as the substantial influence the rating parameters have on the end result. Lastly, it is shown how the results can be applied by concept designers in order to draft tailored, user-orientated interior concepts.


Motivation
Traditionally, vehicles have been developed in an evolutionary fashion. Most of the requirements for modern vehicles have been derived from either predecessor models or competitor analyses. One of the reasons for this could be that use cases and therefore user needs have not dramatically changed in the past decades. This evolutionary trend is recognisable in the similarity between previous vehicle model generations.
However, global megatrends are having a significant impact on mobility trends. In this context, it is generally agreed that autonomous driving, the electrification of the powertrain and shifted business models within the automotive industry are examples of these trends. At the same time, their impact on vehicle concepts, in particular on the requirements is evident. Such new technologies enable new use cases that previously were not possible. The possibility in the future of being able to work on a laptop while being chauffeured or to simply relax and watch a movie are made possible by such technologies. These new use cases can be seen as the new user needs of the future user and therefore, should be identified and considered in the generation of new vehicle concepts.
An approach addressing this topic has been created in the form of a model, called the user oriented concept development (UOCD) process model [20]. This is a five-step process based on systems engineering that has been tailored to the application of concept design and can be seen in Fig. 1.

3
Apart from the first step, each step in the process relies on the output of the previous step in order to be executed. The first step in the process is the definition of a future scenario from which user needs, and thereafter, system requirements can be derived. These requirements are then utilised to determine the relevant vehicle functions and modules. In the context of this paper, a function refers to an operation the vehicle should perform in order to fulfill a specific purpose, whereas a module refers to a physical component of the vehicle that ultimately enables a particular function. The main difference being that a module always takes up physical space within the vehicle. The last step in the process is the generation of a concept based on the required vehicle functions and modules. These steps are described in more detail in Chapters 4 and 5. The focus of this paper is on the 4 th step of the process in which the optimal combination of vehicle functions and modules is determined based on the system requirements.

Problem statement
In the automotive industry, vehicle functions and modules are often used over a range of platforms and models, thereby reducing development costs. Additionally, innovations exist that are yet to be integrated into series production models. These have the potential to outperform existing technical solutions with regard to some product properties. However, identifying the optimal combination of functions and modules for a new concept based on user needs, or rather system requirements, cannot be achieved by using the existing models in the literature.
The first aspect to consider is the matching of requirements to suitable functions and modules that can fulfill them, as described in the RFLP logic [14] of system engineering and the general product design model shown in Fig. 2 [27]. It is not sufficient to only identify suitable matches in a binary fashion, as it does not allow for match strength evaluation. The matches need to be rated and assigned a numerical value, in order to determine the strength/quality of the match and allow for further evaluation in identifying the optimal combination.
The second aspect to consider is the way in which all matches can be analysed to determine an optimal combination. To do so, every possible combination needs to be evaluated based on the rating values of the matches. A combination is valid when all the considered requirements are fulfilled by suitable functions/modules. The optimal combination should also consider the requirements importance.

Challenges
The first challenge in addressing this problem is the way in which a match can be evaluated in order to achieve a numeric rating value. This means identifying the aspects of a match (eg. functionality, comfort, cost, size) that can be rated, as well as determining a numerical rating system.
Another challenging aspect is the analysis of the resulting network of connections in order to determine an optimal combination. The complexity is increased by the fact that a requirement can potentially be filled by multiple functions/modules, and that a function/module can potentially fulfil multiple requirements.
The last challenging aspect is the analysis of all valid combination sets in order to determine an optimal set. This analysis needs to take into account the individual rating values of the considered matches in the given combination, the priority of the requirements as well as the functions/ modules that fulfil multiple requirements.

Introduction of the MatchMatrix
This paper presents a matrix-based process and methodology that enables a systematic coupling of system requirements to vehicle functions and modules, as well as the identification of an optimal function/module combination set. The MatchMatrix (MM) was developed in the context of systems engineering to support the preliminary and conceptual development of automotive concepts. It is intended to help engineers and product planners deal with the complexity and unfamiliarity of new concepts and to uphold the short development times that are common in industry. These goals are achieved in that a solution space is systematically identified and quantified, meaning that decisions can be made in a more transparent and stable manner. As a methodology, the MM has to be integrated into the environment of (other) methodologies and processes.

Traditional development methods
The process of automotive development is defined individually for each OEM in the so-called product development process. A basic structure and sequence is demonstrated by Pischinger und Seiffert [17]. The basic or general procedure for developing technical systems and products is described in various articles [2,4]. Using the guideline 2221 of the Association of German Engineers [27], the MM can be placed into context. As marked in Fig. 2, the MM assists in the assessment and selection of solution concepts.
This early development phase begins parallel to the derivation and specification of the requirements. Building on this, suitable and solution-neutral functions must be developed in a functional structure in order to meet the requirements. From the moment the functions are assigned a (technical) active principle for the solution, one can start to speak of a concept. Generally, several concepts are created in parallel, as the best concept has to be determined/evaluated. The modules that represent the functions in turn represent the product structure. This principle procedure is rooted in the (VDI-Richtlinien 2221) and system engineering. The parallels to the RFLP logic [14] of systems engineering are intentional.
Initially, needs and goals for the technical product must be translated into quantifiable and measurable requirements against which the product can be checked in a later development phase. The vertical connection "product design" shown here is the same as the horizontal connections in the V-model of systems engineering and describes the connection of a requirement once it has been made with its associated evaluation. In step two, functions that the product must fulfill are formulated with the help of the need sources and requirements. These are collected in a function list or a function catalog. They have the format < Object > < Verb > and are specified in different levels of detail from coarse to fine. This can be achieved by applying the level model, which enables a structured decomposition of needs and requirements [24].
Step three serves to fulfill the functions. Each function is assigned a solution or operating principle as to how this function is to be fulfilled. For example, the "heating of the interior" function may require a sub-function "heat supply air". The supply air can in principle be heated by a heat exchanger directing energy from the cooling system into the supply air. In the fourth step, these functions and operating principles must be summarized in realizable modules so that it is clear which module fulfills which functions with which solution principles. In the fifth step, the most important, decisive or architecture-defining modules are formed.
The 3F method according to Küçükay [12,13] is used to represent the use of the vehicle by the users under all relevant operating conditions. All relevant influencing parameters are statistically evaluated to determine their influence on the target module. The target module depends to a large extent on the problem and can relate, for example, to components in the transmission (see Müller-Kose [16] or chassis (see Janßen [10]. In this context, it becomes clear that the influence parameters are problem-specific and should be defined separately for each problem. However, the 3F method can also be applied in connection with the conceptual design of a vehicle interior. On the one hand, the relevant use cases are considered in a cluster, so that all influences from mutual interactions of the driver, vehicle and driving environment can be taken into account. Furthermore, it is possible to record the use of the vehicle systematically in the sense of the 3F method within the framework of a user needs assessment. Provided that potential influencing variables from customer use are defined and are measured, it is possible to determine and systematically evaluate statistical distributions of the influencing parameters. In this way, all relevant boundary conditions for use of interior vehicle functions can be determined and the resulting requirements for individual modules can be derived. These can include, for example, the frequency of use of certain vehicle functions or boundary conditions to be taken into account, such as uneven road surfaces.

Matrix based development models
Matrix based models are present in various existing development methodologies, such as the Domain Mapping Matrix (DMM), Quality Function Deployment (QFD) in the form of the House of Quality (HoQ), Axiomatic Design (AD) in the form of the Functional Requirements-Design Parameters (FR-DP) Design Matrix, the Morphological Box and the Module Indication Matrix (MIM). They are generally used as tools to facilitate the matching of elements within multiple domains. Each methodology is discussed further in this chapter.
The DMM is a basic concept which allows the mapping of two domains over a two-dimensional matrix [3] and is also referred to as the inter-domain matrix by Lindemann et al. [15]. The basic structure of the DMM can be seen in Fig. 3. The concept is simple-two domains, for example two views of a system, are considered on the X&Y axes of the matrix. Each domain is usually comprised of multiple elements. The connections between elements are normally identified using a binary rating system, such as an 'X' or '[space]', meaning a connection or no connection, respectively. The DMM is the basis from which most matrix models are built upon.
The House of Quality (HoQ) is an important component of Quality Function Deployment (QFD). It adopts the same basic structure of the DMM, in the sense two domains are considered in a two-dimensional matrix. There are numerous variations of the HoQ, but the core aspects of a typical HoQ are shown in Fig. 4. The voice of the customer is formulated in the form of customer's needs/wants, which are normally considered on the Y axis, whereas the technical solutions/requirements are normally considered on the X axis. These two domains differ slightly depending on the application of the HoQ and are sometimes more generically referred to as the 'what?' and 'how?' domains, respectively. Each customer need can be numerically weighted depending on its relative importance to the other considered needs. This is achieved in the customer needs priorities area of the HoQ. Relationships between elements of the two domains are determined in the correlations matrix and are represented by various symbols, that sometimes represent a numerical value. The type of symbol is determined depending on the strength of the relationship. Furthermore, interrelationships between the technical solutions can be identified by filling out the interrelationship's matrix. This part of the HoQ is sometimes referred to as the 'Roof'. The strength of the interrelationship is also distinguishable with various rating symbols. After the correlation's matrix has been filled out, the technical solutions importance can be calculated by firstly multiplying the relationship strength values with the customer need priority values, also referred to as the weight of the need. In the case multiple relationships exist for one technical solution, these multiplied figures are added together. This results in a numerical value that indicates the importance of the corresponding technical solution in regard to the customer needs. The higher the value, the more important the technical solution is in fulfilling the customers' needs [1].
Axiomatic design (AD) is broadly described as a scientific approach in determining good designs (mapping of the functional space to the physical space). However, it could be argued all the addressed models fit this description. AD considers four main domains, namely the customer domain, the functional domain, physical domain and the process domain. These reflect different stages of the product development process. Similarly to the HoQ and the DMM, AD utilises a matrix based model called the FR-DP design matrix. The basic structure of this matrix can be seen in Fig. 5. Two of the four domains are considered in this matrix, namely the functional requirement and the design parameter domains. Matches are indicated with a binary rating system, similar to that of the DMM. For every functional requirement a corresponding design parameter is specified. The relationship is shown in the relationship matrix, usually with an 'X'. Further relationships or dependencies between design parameters and functional requirements are also indicated in the relationship matrix. The main purpose of the design matrix is not to identify which designed parameters are required to satisfy the functional requirements, but rather to identify if a design is coupled, partially coupled or uncoupled. The ultimate goal is to achieve an uncoupled design, meaning that functional requirements are able to be satisfied without affecting the other functional requirements [25].
The Module Indication Matrix (MIM) assists in the identification of possible modules from various sub-functional groups, or rather, technical solutions. Each sub-function is tested against the module drivers, which are effectively the criteria of modularity. Initially, the module drivers need to be determined, as well as the sub-functions. Determining the sub-functions can be assisted by a sub-function selection matrix. The next step is the evaluation of each sub-function against the module criteria. Once complete, this assists the logical identification of possible modules, including the number of modules needed for the considered sub-functions. As visible in Fig. 6, goals can additionally be set for each module driver and the interfaces between the sub-functions identified with the interfaces and connections matrix [5].
The morphological box is a creativity method for the systematic analysis of complex tasks and the search for solutions [2]. The morphological box was developed by the Swiss astrophysicist Fritz Zwicky in the 1940s and is therefore also known as the Zwicky box [28]. Although developed earlier, it has similarities to the DMM as visible in Fig. 7. In its two-dimensional application, the morphological box allows, for example, functions and operating principles to be compared in different phases of development. In the same way, requirements and functions can also be compared. The criteria can be selected in a variety of ways. The aim of this procedure is to collect the possible characteristics of the one criterion in the box. In the case of the morphological box, there are not always the same number of possible solutions  available to choose from across all criteria. The application takes place by looking for conceptual characteristics for the criteria (i) as a functional requirement. For example, "Heating the vehicle interior" could be solved with the concepts "PTC heating", "heat pump" or "resistance heating in surfaces". With the morphological analysis of the morphological box, the available or conceivable possibilities can be systematically examined. However, a disadvantage of the morphological box is that the resulting combinations are not checked for plausibility in the procedure itself and many options are possible from the combinatorics. The latter problem is also referred to as a combinatorial explosion [7].

The MatchMatrix
The MM differs to the existing matrix based models in that it presents a new way of evaluating matches between requirements and functions/modules by considering various assessment criteria. This enables a more in-depth determination of the match quality. Furthermore, it provides a way of determining optimal function/module combinations when multiple viable combination sets exist.
Like most of the models in the literature, the basic structure of the MM reflect similarities to the DMM in the sense that two domains are considered in a 2-dimensional matrix. In the DMM, matches are normally demonstrated with a binary rating system, whereas in the MM, matches are nonbinary, allowing not only matches to be identified but to also be numerically rated. This non-binary rating system is characteristic of the HoQ and MIM, however, the way in which the ratings are determined differ in the MM. This is discussed further in this chapter.
It is intended for the MM to be applied in either the predevelopment or concept development phase of the automotive specific product development process, as depicted by Pischinger und Seiffert [17]. This depends on if the intended purpose is to analyse rough feasibility (predevelopment phase) or to define a concept (concept phase). In the context of the generic life cycle model [9], the MM would be most applicable in the concept phase.
The considered variables of the MM, also referred to as the 'Inputs' in Fig. 8, consist of system requirements as well as a comprehensive catalogue of vehicle functions and modules. The system requirements specification is the result of the first three steps of the UOCD process model discussed in Chapter 1. Whereas the catalogue is made up of vehicle functions and modules, either already implemented or yet to be implemented in series production models. These inputs are demonstrated and described further in Chapter 4.
The end result of the MM, referred to as the 'Output' in Fig. 8, is the optimal combination of functions and modules that satisfy all of the considered requirements. This is presented in the form of a functions and modules specification and is further described in Chapter 5.
As mentioned, the basic structure of the MM reflects that of the DMM. This can be seen in Fig. 9. Two domains are considered, namely the two input variables of the MM-the The system requirements are sourced from the systems requirements specification and are considered in the columns of the MM. An example specification can be found in Table 3. The functions and modules are sourced from the catalogue and are considered in the rows. This is visualised in Fig. 10.
The first step in the process is to match the requirements to suitable functions/modules, which is achieved by calculating a quantifiable 'Rating value'. The rating value is determined with the help of an evaluation criteria shown in Fig. 11. To determine a rating value, each criterion is individually evaluated for the given possible match, and thereby assigned both a 'Match value' and an 'Importance factor' so that the rating value can be calculated. The match value can be seen as a rating of the strength of the match for the given criterion, whereas the importance factor enables the various criterion to be assigned different weightings, depending on their importance in the evaluation. This plays a crucial role in determining the optimal combination.
For the criteria shown in Fig. 11, the match value can be either 0, 1 or 2, however, an arbitrary rating scale can be used. A low match value, such as a '0' represents no correlation, whereas a high match value, such as a '2' indicates a high correlation, or rather, fulfilment. The evaluation criteria represent different rateable aspects of the match. For each of the criterion, a match value must be assigned. For example, when considering the requirement "Heating the interior" and the module "Climate control module", the 'Functionality' criterion refers to how well the climate control module fulfils the functional aspects of heating the interior (eg. Interface to user, usability). In this case, a match value of '2' would be assigned, as the functional aspect is well fulfilled.
Additionally, an importance factor for each criterion must be assigned. The importance factor in this example is a numerical value between 1 and 5, with five indicating high importance. This allows the criteria to have various relative weightings. For example, if the functionality of the "Climate control module" is more important than how much it costs, then the functionality criterion should be assigned a higher importance factor as that of the price. Depending on  The evaluation criteria considered in determining a rating value the application, the importance factor can be fixed for each evaluation criterion and used universally for each match, as opposed to assigning importance factors for each individual match.
The formula used to determine the rating value can be seen in Eq. 1, and, as shown in Fig. 11, a rating value needs to be determined for every possible requirement-function/ module match.
The rating value for the example shown in this paper has a range between 0 and 100, with a higher value indicating a more suitable match. This range is based on the possible match values (0-2) and importance factors (1-5) shown in Fig. 11, as well as a scale value of 50. The scale value is primarily used to achieve a desired rating value range. However, it is not essential and can be disregarded for other applications. Furthermore, the 'crit.i' in the equation refers to the corresponding evaluation criterion. For example, if only the 'Functionality' criterion was considered, with an importance factor of 5, the resulting rating value of the "heating the interior" and "climate control module" match would be (2 * 5)50∕5 = 100.
The second step in the process is to determine the optimal combination, which can be achieved once the rating values have been calculated. Initially, the considered requirements need to be sequentially prioritised from most important to least important, as this has a large influence in determining an optimal combination.
Based on the priority of the requirements, minimum acceptable rating values of suitable functions/modules are specified for each requirement. This part of the process reduces the solution space, or rather the possible number of combinations and ensures that highly prioritised requirements are fulfilled by the most suitable functions/modules. Typically, higher prioritised requirements will have a higher minimum acceptable rating value. This is achieved by firstly plotting all the matched functions/modules to the corresponding requirements on a scatter plot. The requirements are considered on the X-axis and rating values of the matched functions/modules on the Y-axis. An example of this can be seen in Fig. 12.
Following this, a 'Minimum acceptance curve' is defined which determines the minimum acceptable rating values for each requirement and consequently, the functions/modules that can be considered in an optimal combination. This threshold curve can be of any form, but generally adopts a degrading quadratic or linear form as higher prioritised requirements should have a higher minimum acceptance rating value. It's important to note that in Fig. 12, the requirements are plotted according to their priority, with the most important being considered first. The first requirement shown in Fig. 12 has three possible functions/modules that can fulfil it, all of which have different rating values. However, only one of these solutions is above the minimum acceptance curve, meaning for this requirement, there is only one solution that can be considered for the optimal combination set. For example, requirement one could be "Heating the interior" and the highest position dot could represent the "Climate control module", in this instance, possessing a rating value of about 90.
In order to quantitively evaluate viable combination sets of the functions/modules above the minimum acceptance curve, a 'Quality factor' is calculated for each possible combination. The formula for the quality factor can be seen in Eq. 2.
Two variables are considered in the quality factor function, namely, the rating values of the functions/modules considered in the combination and the priority factors of the requirements-referred to as 'sol' and 'req' in Eq. 2, respectively. The method of calculating a rating value has been described previously in this chapter and determined by applying Eq. 1. Furthermore, the priority factor is determined by the minimum acceptance curve, specifically, it is the minimum acceptable rating value for each considered requirement. For example, the priority factor for Req. 1 in Fig. 12 is about 70, whereas Req. 2 has a priority factor of around 50. This is to ensure that highly prioritised (2) Quality factor comb.n = ∑ � Rating value sol.i * Priority factor req.i � ∑ Priority factor . It is important to note that the quality factor applies to a combination set of functions/modules and not the individual matches. It is effectively a weighted average of the function/module rating values considered in the combination. After every possible combination set has been evaluated and assigned a quality factor, the sets can be plotted in order to visualise the results and assist in determining an optimal combination. One way of doing this is by means of a scatter plot that considers the quality factor value and the number of functions/modules in the given combination set. This can be seen in Fig. 13.
Each dot plotted in Fig. 13 represents a combination of functions/modules that fulfill all of the considered requirements. The optimal combination set is simply that with the highest quality factor value, as indicated in the example. An alternative representation of the possible combination sets is to consider the cost of the set against the quality factor, which is demonstrated in Fig. 14. This is arguably more appropriate for industry applications as cost is often a decisive factor. This assists in determining the best combination based not only on the quality factor, but also the absolute price of the set. Of course, the prerequisite for such a representation is that the cost of each function/module is known at the time of analysis.
Even though it is generally considered in this methodology that the optimal combination is the set possessing the highest quality factor value, the selection process can be subjective. In Fig. 14, an optimal combination set is pointed out. However, it could be argued that a combination with a lower total combination cost and only slightly lower quality factor is a better option, depending on the target concept or rather, target customer.
Once an optimal combination has been selected, the functions/modules can be viewed and further analysed. It can be determined which functions/modules were selected for each of the requirements, as well as how well they matched. In the analysis, the match strength is determined by both the rating value of the match, as well as the deviation of the rating value to that of the corresponding minimum acceptable rating value. This is demonstrated and discussed in Chapter 5.1.
Upon completion of the first iteration, the MM also allows for further iterations in the matching process, in that the requirements and functions/modules can be decomposed and considered on a second level. The MM process repeats itself in that the sub-functions of the functions and module components of the modules are matched to the decomposed requirements. This concept is demonstrated in Fig. 15. It is important to note that a 2nd iteration can only occur after a combination set has been selected on the upper level. For example, the requirement "Heating the interior" would have to be matched to "Climate control module" in the chosen combination before proceeding to the second iteration level.
The concept of decomposed requirements refers to refining an initially broadly defined requirement in the form of more specific functional and potentially, nonfunctional requirements. The decomposed requirements are derived directly from the initial requirement on the first level, however, often take into consideration the function/ module that has been matched to the initial requirement. This makes the decomposed requirements dependent on the chosen function/module for the 'Parent' requirement and is further described by the extended peaks model [20], which illustrates the dependency of decomposed requirements on the chosen architecture.
Similarly to that of the decomposition of requirements, the functions/modules can be broken down into sub-functions and module components. This allows for the decomposed requirements to be matched to suitable subfunctions and module components. It is important to achieve a similar level of detail between the decompose requirements

Application of the MatchMatrix
In order to demonstrate the functions and possible results of the MM, a realistic example is considered. The complete UOCD process is applied in the example, meaning that a future scenario is initially defined from which the user needs and corresponding system requirements can be derived. The MM is then applied to match the system requirements to suitable vehicle functions/modules, as well as to determine the optimal combination. In this chapter, the individual steps of the MM are shown and the results are analysed.
Two cases are considered based on the same system requirements and catalogue of vehicle functions and modules. In this analysis, two target markets are considered in which an entry level vehicle from a standard vehicle manufacturer is compared against a premium vehicle from a premium vehicle manufacturer. This is achieved by adjusting the importance factors in the evaluation process and results in two unique optimal combinations. The future scenario, derived user needs and system requirements, as well as the catalogue of vehicle functions and modules are fictitious in this example. They are only means to demonstrate the methodology presented in this paper.

Future scenario
The different development paths and thus possible characteristics of the future can be presented in the form of structured future scenarios. In order to visualise the connections between the future scenarios and the respective requirements consistently, it is necessary to implement the future scenarios consequently within the Use Case-based concept development.
The first step in any product development is to clarify and specify the task (cf. Chapter 2.1). In the development of mechatronic systems [26], the determination of requirements is also the first priority. In order to be able to capture these user needs, it is necessary to have a clear understanding of what the world looks like, in which the use cases and thus the interaction between user and system take place. Once this framework is known, the use cases can be described in detail in order to derive stakeholder needs. This procedure has already been described in the context of the UOCD process model [20].
The future scenarios must be able to depict market and trend developments as well as the expected future state of the art of technology. These have a significant influence on user behaviour, which in turn can be described via personas and user journeys [24]. The development of future scenarios, e.g. using the scenario technique, is already known from the product planning phase, but also as a creativity technique in a classical requirements engineering. [6,18]. It is also a well-known tool for describing future mobility developments [23] and, along with numerous flanking studies, e.g. Neue autoMobilität 2 [8], provides the basis for defining the future scenario.
In a document-based approach, however, the developed scenarios are decoupled from further product development. Changes to the characteristics of the imagined future are difficult to reconstruct, and their effects on the derived requirements are not traceable. Here, model-based systems engineering offers an approach that enables the continuous modelling of the system, including its environment and stakeholders [19].
For a structured modelling of the future scenarios, the classification of the descriptors according to the STEEP fields (Sociological, technological, economic, environmental and political) is useful. The sociological factors have a particularly strong influence on the user. They represent, among other factors, ecological awareness or safety needs, which have a direct effect on user behaviour. Technological or environmental influences, in turn, can be mapped directly to the system context. This describes the connections between the system to be developed, the system of interest (SoI), as well as environmental and neighbouring systems. The infrastructure is particularly important here.
For this example, the following future scenario has been defined for the Central European region: An essential condition for the operation of autonomous vehicles is the corresponding valid legislation. This requires legalisation of SAE Level 4 operation in public road traffic. In addition, relevant questions regarding right-of-way rules in a possible mixed traffic between autonomous and conventional vehicles and liability issues in case of accidents have to be clarified. Stricter CO2 regulations of the European Union have ensured that complete local CO2 neutrality must be maintained for vehicles in inner cities. An electric drive is derived from this, the traction battery is dominant as an energy storage device in motorised private transport. On the infrastructure side, an extensive 5G network is required to enable communication between the vehicles (Car2Car) and with the existing infrastructure (Car2X). In addition, there is a comprehensive network of charging stations, mainly at workplaces or in public areas (e.g. supermarket car parks) [22]. The ecological awareness of users remains high, but at the same time there is also an increased safety need. As a result of the CORONA pandemic, the sharing mentality has decreased. Although the attitude of "using instead of owning" remains, this is not reflected in the increased use of ridepooling or ridesharing services. Instead, motorised private transport remains strong-even with privately owned vehicles-although business models in the form short-term leasing are enjoying greater popularity. Users also attach great importance to the compatibility of family and work [11].
In the first step, the described future scenario can be mapped in a structured way with the help of the graphical modelling language SysML, as depicted in Fig. 16.
This can then be linked to the system model of the vehicle via the use cases (Chapter 4.2) or the system context. Subsequently, as described in the UOCD process, user needs can be derived in step 2 and system requirements in step 3.

System requirements
Based on the described future scenario, various relevant use cases can be defined. However, in order to reduce unnecessary complexity, only one use case is considered in this example. This is namely the use case of working on a laptop which takes place while the occupant is being autonomously driven to their destination. This use case is described in the form of a structured user journey, which is shown in Table 1. The user journey is broken down into steps which describe the single activities of the occupant while carrying out the use case. The user journey can be seen as a textually described future scenario.
Through critical analysis of the steps of the user journey, the user needs can be derived and specified. Each step of the user journey is coupled with a unique ID to ensure the traceability to the derived user needs. This is namely the second step in the UOCD model. The needs are formulated with the help of a predefined sentence syntax which is specified in Fig. 17. This predefined syntax should only act as a guide, as some user needs cannot be written in this form.
The user needs derived from the considered user journey are listed in Table 2. Each user need is accompanied with Fig. 16 Integration of the future scenario into the UOCD process a unique user need ID, as well as a source ID. The source ID refers to the information from which the user need was derived, in this case, the steps of the user journey.
In a similar fashion, the system requirements are derived directly from the user needs. This is the third step in the UOCD process. This step should be carried out by an expert in the field and supported by relevant literature and studies. For this example, the derived requirements can be seen in Table 3. The structure is similar to that of the user needs in which a source ID and unique ID are assigned to each system requirement. Additionally, the priority of each requirement is also represented. The relevance of prioritising system requirements is addressed later in Chapter 4.4.
The system requirements are also formulated on the basis of a predefined sentence syntax, similar to that of the user needs. This can be seen in Fig. 18. The syntax reflects aspects of the requirement templates constructed by Rupp [21]. The purpose of this predefined sentence They take a seat and stow their laptop bag and other possessions within arms reach UJ1. 3 The journey begins and they take their laptop out of its bag and place it on a work surface UJ1. 4 The seat is too far away from the working surface, so they adjust their sitting position UJ1. 5 The ambient light is bright, so they increase the brightness of the laptop display to the maximum UJ1. 6 They proceed to establish an internet connection and begin to read their e-mails UJ1. 7 In the meantime, they receive a call through the laptop. They try to take the call but struggle to connect their headphones in time UJ1. 8 They miss the call, however, they return the call straight away after connecting their headphones UJ1. 9 The conversation is carried out through voice and video, but they have trouble understanding the caller due to the loud ambient noise UJ1. 10 The skype call ends and they start working on a document that requires a large amount of concentration UJ1. 11 After a while, their laptops battery is almost empty, so they take the charging cable out of their bag and plug it into the nearest power source UJ1. 12 While working, they sip on their drink, which is now at room temperature UJ1. 13 Relevant news updates and information are continually conveyed during the drive UJ1.14 Just before arrival at the destination, they pack all their possessions in the laptop bag and prepare to leave the vehicle  syntax is to ensure that the system requirements focus on what the system must do or achieve in order to satisfy the user needs. Furthermore, it ensures consistency between the requirements in the system requirement specification. Most importantly, the system or subsystem that must fulfil the requirement is mentioned at the beginning of the sentence. It is demonstrated in Table 3, that multiple system requirements can be derived from one user need. Additionally, one system requirement can potentially address multiple user needs. This is also true for user needs in that one user need can address multiple steps of the user journey. This is heavily dependent on how broadly the user needs and system requirements are defined. Generally speaking, one should aim to match the detail level of the user needs and system requirements to the user journey.

Catalogue of vehicle functions and modules
The second input of the MM is the catalogue of vehicle functions and modules. This catalogue can consist of existing functions and modules, as well as new concepts and ideas which are yet to be implemented into series production models. The more comprehensive the catalogue, the better the evaluation.
It is possible to only consider physical modules in the catalogue, those of which require construction space in the vehicle architecture. However, in order to determine a comprehensive optimal combination, all relevant system requirements should be considered in the matching process. This also means that a comprehensive catalogue, one that is more extensive than only physical modules, is required. Most modules provide a function, for example, a car seat The vehicle must be able to securely store the occupants wallet within arms reach N1 R2 15 The vehicle must be able to securely store the occupants cell phone within arms reach N1 R3 18 The vehicle must be able to securely store the occupants keys within arms reach N1 R4 20 The vehicle must be able to securely store the occupants mask within arms reach N1 R5 21 The vehicle must be able to securely store the occupants umbrella within arms reach N1 R6 16 The vehicle must be able to securely store the occupants open drink within arms reach N2 R7 4 The vehicle must allow the occupants laptop to be held in an ergonomic working position N2 R8 5 The vehicle must provide the occupant additional ways in which they can control their Laptop N3 R9 1 The vehicle must offer the occupant the opportunity to adopt an ergonomic working position N3 R10 2 The vehicle must fully support the occupants back in the upright position N3 R11 3 The vehicle must offer the occupant the opportunity to adjust his body position during the drive N4 R12 14 The vehicle must offer the user the opportunity to limit the ambient light entering the interior N5 R13 8 The vehicle must be able to wirelessly recognise, connect and communicate with the occupants personal devices N5 R14 9 The vehicle must always have a permanent internet connection N5 R15 10 The vehicle must be able to share the internet connection with the occupants devices N6 R16 12 The vehicle must allow the occupant to display and enlarge the content on their laptop within the interior N7 R17 13 The vehicle must offer the user the opportunity to reduce ambient noise in the interior N8 R18 22 The vehicle must offer the user the opportunity to illuminate parts or all of the interior in various colours N8 R19 23 The vehicle must offer the user the opportunity to change the aroma of the interior N9 R20 6 The vehicle must support the charging of the occupant's laptop N9 R21 7 The vehicle must support the charging of the occupant's cell phone N10 R22 17 The vehicle must be able to keep the occupants drink cool N11 R23 11 The vehicle must constantly convey relevant information to the occupant in real time provides the function of holding a person in a certain position. However, some functions cannot be described as modules, such as many embedded systems. In conclusion, all of the items in the catalogue provide functions. It is simply more practical to describe some of these items as modules and some as functions.
The catalogue used in this example can be seen in Table 4 and is made up of both existing and yet to be developed functions and modules. The functions and modules are intentionally broadly defined in this example to keep the solution space open and to ensure a similar detail level between the needs and requirements. The sub-functions or module components can be defined later in the decomposition of the requirements and architecture.
It is important that each function and module in the catalogue is described in detail. This is achieved in practice by defining the core characteristics of each module either in writing, orally, or when a pre-existing function or module is considered, graphicly.

Determining the rating values
The MM can be applied after the two necessary inputs have been defined, namely the system requirement specification and catalogue of vehicle functions and modules. The first step, as defined in Chapter 3.1, is to assign a match value to each evaluation criteria. This process is repeated for all possible matches. For this example, the match values of 0, 1 or 2 are applied. This is a subjective process that is carried out by experts in the field, that have a clear understanding of the requirements as well as all the items in the catalogue. In order to ensure the validity of the evaluation, this task is normally carried out in groups. For this example, the requirements listed in Table 3 and the functions/modules listed in Table 4 are considered. The MM-matrices displaying the match values for each possible match are too large to present in this paper, however, the resulting rating values are presented in Tables 5  and 6. The next step is to define the importance factors of each evaluation criterion. As mentioned at the beginning of this chapter, two cases are considered. The way in which they differ in the analysis is in the determination of the importance factors. The first set of importance factors is based on the first case, being the entry level vehicle. The second set is based on the premium vehicle case. These scenario preconditions allow the importance factors to be appropriately determined based on the target customer and vehicle segment. The fictitious importance factors chosen for both cases can be seen in Fig. 19. Determining these values is a subjective process carried out by experts in the field, who take into consideration the preconditions and future scenario. For this example, the importance factors are not defined for each possible match, but rather defined for each case. It can be seen that for the premium vehicle case, the frequency of use, assembly space, price and transferability have low importance factors, and therefore, will have little influence in determining the corresponding rating values. The highly weighted criteria: functionality, comfort and enthusiasm factor will therefore play the biggest role in determining suitable matches. In the case of the entry level vehicle, the price, transferability, and functionality are considered the most important criteria. This demonstrates the difference in priorities between the two cases.
By applying Eq. 1, that considers the match values and importance factors in Chapter 3.1, a rating value can be calculated for every possible match. A sample of the resulting rating values for the premium vehicle case can be seen in Table 5 and for the entry level vehicle in Table 6, respectively. The y-axis of the tables represents the functions/modules listed in Table 4; whereas the x-axis, the requirements in Table 5 Sample of calculated  rating values for the premium  vehicle case   Requirements  R1  R2  R3  R4  …  R23  Functions/modules   C1  74  88  74  0  …  0  C2  88  88  88  0  …  0  C3  41  26  26  0  …  0  C4 26  19 Importance factors of the two considered cases Table 3. As previously mentioned, the rating values for this example have a range between 0 and 100, and behind every rating value is a filled-out match value table.

Reducing the solution space
The next step is to use this data of rating values to determine an optimal combination. In order to do so, the requirements are prioritised from most important to least important, and the solution space is reduced by filtering out the obvious non-suitable matches. This is achieved by specifying a minimum acceptance curve. As mentioned in Chapter 3.2, this curve reduces the solution space and defines the priority factors used to calculate the quality factor. For this example, a typical acceptance curve has been defined in that higher minimum acceptance values are specified for highly prioritised requirements, which can be seen in Fig. 20. The same minimum acceptance curve is applied to both cases considered. Furthermore, the requirements were prioritised based on their relevance in achieving the considered use case. For example, ensuring the user had a space in which they could work was prioritised higher than keeping their drink cool, as keeping a drink cool is not an essential aspect in carrying out the use case. Additionally, the priorities of the user were also taken into consideration. The priority of each requirement can be seen in Table 3.
The dots in the figure represent functions/modules that have rating values of more than zero for the corresponding requirements, which are considered on the x-axis. It is possible for a function/module to be represented multiple times in such a figure, depending on the requirements. For example, the "Climate control module" could potentially fulfil the requirements "Heating the interior" and "Cooling the interior".
The dots above the minimum acceptance curve, which have a higher value of the corresponding point on the curve, are functions/modules that can be considered in an optimal combination. The rest of the matches with low rating values are considered unsuitable. Furthermore, the priority factor values for the requirements are derived from the minimum acceptance curve, which are necessary in determining the quality factor. Once a curve has been established, the quality factor for each possible combination set can be calculated.

Results analysis
In order to determine an optimal combination, the representation and analysis of the possible combinations according to their quality factor is necessary. This can be achieved by plotting all possible combinations on two types of scatter plots. The first considers the quality factor and the number of functions/modules in the combination, whereas the second considers the quality factor and the total cost of the combination. Examples of these, based on the entry level vehicle, can be seen in Figs. 21 and 22, in which each dot represents a possible combination.
In the entry level vehicle example, there are around 6 million possible combinations of functions/modules. The combinations with low quality factor values are generally  A similar trend can be observed in both plots, in that the combinations are within a parabolic envelope. Initially, as the total cost and number of functions/modules increases, so does the quality factor of the combinations. However, at a certain point the quality factor ceases to further improve and eventually begins to decrease.
At first glance, parts of the results may seem counter intuitive. However, in order to understand this, it is necessary to examine which functions/modules have been matched to the requirements in the individual combinations. In Table 7, the matches between functions/modules and requirements are shown for the entry level vehicle. Two combinations are displayed, being the best 21-function/module combination and the best 18-function/module combination. The values marked in green represent matches that are shared by both combinations, whereas the values marked in yellow are matches unique to the 21-function/module combination and those marked in cyan are unique to the 18-function/module combination.
The values represent the fulfillment factor, which is the quotient of the match rating value and the minimum acceptance value for the corresponding requirement. If the fulfillment factor is equal to or more than one, the corresponding function/module satisfactorily fulfils the corresponding requirement. However, when the fulfillment factor is less than one, the requirement is not satisfactorily fulfilled. This occurs when there is no better function/module for the corresponding requirement and identifies a need for new ideas or optimization. This also applies in the case of requirements that cannot be fulfilled by any of the functions/modules under consideration.
It can be seen in Table 7 that the lower factor values are mostly from the 21-function/module combination. Additionally, the functions/modules from this combination (marked in yellow) only fulfil one requirement each. On the other hand, the functions/modules from the 18-function/module combination (marked in cyan) fulfill multiple requirements and also have higher factor values. The 21 function/module combination is possible, legitimate, and also the best combination containing 21 functions/modules, however, lower number function/module combinations can proof to be better solutions-as evident in this example. This also demonstrates that increasing the number of functions/modules in a vehicle architecture does not guarantee a better fulfillment of the requirements.
In order to understand this with an example, requirement R23-"The vehicle must constantly convey relevant information to the occupant in real time" is considered. In the 18-F/M combination, this is fulfilled by the module C25-'2D LCD Panel (Touch)' with a fulfillment factor of 1.51. This module additionally fulfills requirement (R16) in the combination. In the 21-F/M combination, however, an additional module fulfills this requirement, namely C20-'Head

Determining an optimal combination
In order to make a decision as to which combination should be selected, the optimal point between quality and cost, or quality and number of functions/modules must be weighed up. In theory, all combinations shown are good enough to meet all requirements. A sensible course of the acceptance curve ensures that the more important requirements are better met than those with a lower priority. In order to meet the requirements of the user, it is logical to consider the quality factor-cost plot. Here, a combination between the cheapest and the highest quality has to be selected, depending on how the engineer and the company define their values. It is counterproductive to choose an arbitrarily expensive combination, as at a certain point, the more expensive combinations do not result in any added value, or rather an improvement in the quality factor of the combinations.
It can occur, that several combinations exist for one point in the plot. The reason for this is that there can be functions/modules in combinations with exactly the same rating value for the corresponding requirements. It does not matter which combination is selected, as long as one of the functions/modules does not depend on another requirement. In this case, the expert opinion of the user is required as to which function/module is ultimately better. In addition, two combinations of the same functions/modules may be displayed, which raises the question of the difference. This can occur when two functions/modules that independently meet two different requirements are both eligible for a third requirement and are rated equally. This results in two possible solutions with the same function/module list. In this case, the expert opinion of the user is again required in order to select a solution.
For the two examples considered in this paper, an optimal combination was selected for each. These are indicated in Fig. 25 by the dots marked in black. The two variables considered in the selection process are the quality factor and total cost of the combination. Ideally, the combination with the highest quality factor and lowest total cost is the optimal combination. As to be expected, the combination for the entry level vehicle has a total cost significantly lower as the premium vehicle combination. Furthermore, both quality factors are similar at around 90.
The functions and modules contained within the selected combination sets are listed in Table 8. Additionally, the function/module ID and a fictitious cost are shown. The costs of the functions/modules are only shown to demonstrate the effectiveness of the methodology and do not reflect the actual cost of each item. A noticeable observation is that the entry level vehicle combination has one less function/ module in the set as that of the premium vehicle.
Furthermore, in a subjective observation of the selected functions and modules in the two combinations, it can be seen that the premium vehicle combination is made up of more high value or rather premium functions and modules. For example, in the premium vehicle combination, an inductive mobile phone holder is selected to both hold and charge the phone at the same time. Whereas for the entry level vehicle combination, a more cost-effective solution of a mobile phone holder and USB connection is selected for the same requirements.
If an unexpected function/module has been selected in an optimal combination, the importance factors of the weighting criteria should be checked to determine whether they are appropriate. It can occur that an unexpected combination is selected due to, for example, too little emphasis on functionality and too much on cost, frequency of use, etc. Therefore, it is important to pay attention to a very well-thought-out weighting.

Comparison of the two types of result plots
As previously mentioned, there are two ways of displaying the combination sets on scatter plots-the quality factor against the number of functions/modules in a combination and the quality factor against the total cost of the combination. In order to analyze and compare these two types of plots, Figs. 26 and 27 are considered. In Fig. 26, the best combinations from the 'number' plot (left side), indicated by the coloured dots, are considered in the 'cost' plot (right side) and vice versa in Fig. 27. The coloured dots in Fig. 26 represent the same combination sets in both plots and the ' + ' represents other possible combinations. Whereas, due to the large amount of combinations in Fig. 27, the same combination sets in both plots are represented by both dot colour and size. For example, the small light blue dot and the large light blue dot represent two different combinations.
The diagrams indicate that it does not make sense to decide the optimal combination based on the number of modules exclusively, as only avoidable complexity and quality are taken into consideration. However, there are cheaper solutions that have higher quality factors. If the combination with the least number of functions/modules were to be selected, which is marked in Fig. 26 by the orange dot, it can be seen in the 'cost' plot that this combination represents only an average, but not significantly cheaper solution. This is due to the fact that not every function/module is equally expensive and therefore no relationship between cost and number of functions/modules in a combination exists. If the choice was made according to the cost, the orange combination would never be considered, as this is not on the outer limit of the envelope curve around the combinations.
Viewed the other way around, it can be seen in Fig. 27 that the best combinations according to their cost and quality factor are plotted in the quality factor against 'numbers' plot. Many of the combinations would not come into consideration in the quality factor against the numbers plot as most combinations would be blended out in the filtering. It is worth noting however, that the highest rated combinations for 17 and 18 in the 'numbers' plot are also viable optimal combinations in the 'cost' plot.
In summary, in most industry applications it would make the most sense to consider the quality factor against the total cost of the combinations plot. This means that even though estimating the cost of each function/module in the early development phase may be difficult, it does play an important role in determining the optimal combination. It can also be stated that the total cost of a combination is more important than the number of functions/modules in a combination.

Comparison of premium and entry level examples
The influence of the importance factors presented in Fig. 19 on the optimal combination is analyzed below. It should be noted that in this analysis the same requirements, requirement prioritization and acceptance curve are used for both cases. This ensures an exclusive analysis of the influence importance factors have on optimal combinations. It can be seen in Fig. 28 that the variation in importance factors results in significantly different viable combinations for both cases.
As to be expected, significantly cheaper solutions can be considered for the entry level vehicle. This is partly due to the fact that inexpensive solutions achieve a better rating due to their low cost. It is also noticeable that the best quality factors in the entry level segment fare better than the best in the premium segment. A reason for this is that very few functions/modules have an excellent enthusiasm factor, which plays a greater role in the premium segment than in the entry level segment. It should be pointed out that the quality factor is generally lower in vehicles that tend to be more luxurious. Therefore, when comparing two segments/ levels, the quality factor should be considered relatively.  The following considers how well the respective best combinations of one segment would be rated according to the importance factors of the other segment. This is shown in Figs. 29 and 30. It is noticeable that the best solutions for one segment would not even be considered in the other. Additionally, some of these combinations may not be allowed in the other segment because they potentially contain functions/modules that fall below the segments acceptance curve. It is also noticeable that the gradation of the combinations is not constant. For example, in Fig. 30, the combination marked in red for about €1150 is significantly better than the combinations marked in green or orange, which rate better according to the importance factors of the entry level segment.
This reveals a clear relevance of the importance factors, which should be chosen sensibly in any case, since they have a major influence on the optimal combinations.

Influence of the acceptance curve
The intended influence of the acceptance curve is to increase the solution space with lower threshold values and to increase the influence of high priority requirements in determining the the optimal combination. It was determined that the course of the acceptance curve had no significant influence on the results for the examples considered in this paper. The only notable change is the change in the solution space. As a result, simpler solutions are generally possible with lower thresholds. However, this does not have a major influence on the selection of a combination, since the qualitative arrangement of the combinations does not change significantly. In practice, the influence of the curve will be greater with a significantly larger requirement field.

Discussion
The aim of this paper was to present and demonstrate a matrix-based methodology that enables the systematic matching of requirements to vehicle functions/modules, as well as the identification of an ideal function/module combination for the considered requirements. The methodology was described and applied with the help of the UOCD process, which included deriving user needs and system requirements from a broadly described future scenario. These system requirements, along with a catalogue of vehicle functions/modules were used as the input parameters in the presented two domain matrix-based model, the Match-Matrix. Expert determined match values and importance factors were used to determine rating values, which enabled a numerical evaluation and rating of each possible match. Lastly, quality factor values (weighted average of the rating values) were generated for each possible combination set in order to determine the optimal combinations.
The strength of the MatchMatrix methodology lies in a systematic and numeric approach to not only matching requirements to suitable technical solutions, but also identifying comprehensive optimal function/module combinations. It enables complex analysis of matches with the application of an evaluation criteria and, furthermore, offers an algorithm to determine optimal combinations. This results in concrete solutions that require no further interpretation or analysis, which can be used as a basis to generate vehicle concepts. Moreover, a comprehensive trade-off between key factors that play a decisive role in determining the most suitable function/module combinations, including function, quality and costs, is made possible by the MatchMatrix. This is crucial to a practical application in industry. This includes aspects that previously have not been considered in a holistic approach of determining a match. In addition, multiple cases can be accessed from one data set with little effort, as demonstrated in this paper. This is achieved by adjusting the importance factors, acceptance curve or the priority of the requirements. Furthermore, once a database of requirements have been matched to functions/modules, case specific specifications can be created and assessed with little effort.
However, there are some weaknesses to this methodology. The requirement specification is derived from the first three steps of the UOCD process which relies on the definition of future scenarios. The definition of such scenarios can be difficult as it requires the forecasting of future trends, the prediction of technological advancements and also an understanding of future user behaviour. Because of this, there is always a degree of uncertainty in the defined future scenarios. Moreover, in order to determine a rating value for a match, a match value and an importance factor need to be manually assigned. These are not computer assigned values, but rather values assigned by experts in the field, making this a subjective process and thereby subject to error. Additionally, the time and effort required in assigning match values for each evaluation criteria is considerable. This weakness in the methodology is best solved by working in groups. This reduces the error percentage and insures a realistic match value and therefore realistic optimal combinations. Moreover, the methodology can only assess functions/modules considered in the catalogue, in other words, only 'known' functions/modules. This can be compensated by including both existing innovations and not yet developed ideas and concepts. On the other hand, the need for new technical solutions for individual requirements can be recognized when no match is identified.
To conclude, the aim of this paper was achieved in that a systematic matching between system requirements and vehicle functions/modules could be demonstrated. Furthermore, optimal combinations for both example product variants could be identified. The resulting combinations indicated that the importance factors of the evaluation criteria have a large influence on the end result and are crucial in identifying industry applicable optimal combinations.
Funding Open Access funding enabled and organized by Projekt DEAL. This research was supported by AUDI AG.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http:// creat iveco mmons. org/ licen ses/ by/4. 0/.