Shared mobility is currently regarded as one of the most important topics in the automobile industry. Like all future urban mobility concepts, it requires close integration with social future research. For new vehicle car sharing concepts, recording all factors that involve costs and analyzing them in regards to their influence on cost effectiveness and vehicle construction is critical. FEV, share2drive, and the FH Aachen (University of Applied Sciences), together work on the future vehicle classes of personal public vehicles (PPV) as a means of transportation and an interface between public and personal transportation.

>> AT LEAST 10 PERCENT OF THE VEHICLES WORLDWIDE WILL BE USED FOR MOBILITY SERVICES BY 2030

The urban mobility trait (UMT),used in the context of shared mobility,describes relevant forms of urban mobility services from the perspective of individual mobility needs and assesses business models with special vehicle concepts. (Figure 1).

From this, it becomes clear that mobility services with free-floating car sharing consist of sharing vehicles that companies provide for their customers, who function as vehicle drivers. Generally, only a small number of people are transported by free-floating car sharing and the driving distances are generally less than eight kilometers. This differs from ride selling, which includes companies such as Uber or Lyft. For these services, private individuals offer chauffeur services with their own vehicles or vehicles leased through the service provider themselves. Ultimately, customer user needs decide which mobility service they make use of. In addition to the cost of the trip, the time required for users to reach their destination is important.The convenience of the service coupled with comfort and the potential added value experienced, such as being able to use the trip time for personal or business tasks, are also important (Figure 2).

New approaches are necessary for transportation services. Share2drive GmbH, headquartered in Aachen, Germany, is carefully following this innovative approach. This young company was formed as a spin-off from the Aachen University of Applied Sciences. Their goal is to provide advanced mobility concepts in the area of car sharing. One of the main parts of the business model is the PPV – a vehicle that was specially developed in cooperation with FEV and its subsidiaries for car sharing use.

Marketable vehicles for shared mobility

New mobility services with UMT have a disruptive influence on the existing value-added structure within the automotive sector. This is due to actors from the ICT and energy industries forging ahead on the mobility market, bolstered with new business models and established mobility service providers. At the same time, large Tier 1 suppliers in the automotive supplier industry are reorienting themselves to react to market changes, including emerging vehicle manufacturers. In addition to further diversification of vehicle models for end customers, we can expect OEMs to increasingly focus on vehicles for mobility service providers [1]. Various studies forecast that at least 10 percent of vehicles worldwide will be used for mobility services by 2030 [2].

The competition for car sharing vehicle models is apparent. Whether these vehicles are designed according to the concept of “sharing a vehicle” or those of “sharing a ride”, “driver on board” or “be the driver” will influence the vehicle’s UMT. Vehicle concepts are only marketable if they have solid market penetration and an attractive total cost-for-ride. For a new vehicle concept, this means that all factors involving costs must be recorded and analyzed. This includes the vehicles themselves, their maintenance, and expenditures for infrastructure, ICT andactual operation. These costs must be represented in a profitable business model and it is important to consider the influence of vehicle construction for each of the stated factors.

The PPV as a new approach for shared cars

The vehicles, including electric solutions, which have been used for urban mobility services thus far only fulfill their purpose to a limited extent because they were originally designed for end customer use. Fleet operators only make minor modifications to the vehicles, especially in the area of access opportunities. However, the focus on special requirements for urban mobility operators and vehicle users based on car sharing concepts is increasing. At the same time, vehicles for new mobility services in a multimodal world must be understood as “rolling devices.” Therefore, it is logical to develop the requirement profile of a “perfect” sharing vehicle from a mobility concept and business model, not by a conventional customer analysis as is normally done. These sorts of requirements came from car sharing operations and joint research from the Aachen University of Applied Sciences andCambio Aachen, as well as from publications from the German Federal Association of CarSharing e.V. (Figure 2).

The thought behind the concept of the PPV is to develop a realistic vehicle that does not follow the current trend of “weightless” show cars, but that is a timely answer to the shared mobility requirements of the future. The vehicle specifications created for the PPV 1.0 address European homologation. In package engineering, the development process follows a unified representation of the package information according to the European Car Manufactures Information Exchange Group (ECIE) Standard. This makes it possible to compare the ergonomic and technical vehicle packages across manufacturers. During hardware concept development, a modular, easily adjusted interior seat box is used to verify the challenging interior specifications. Functional goals, such as for crashes, are secured by appropriate simulations according to the finite element method with a program called LS-Dyna.

Dimensions and structure: The greatest challenge comes from the mobility standard of designing a vehicle in the M1 class. In this class, only vehicle lengths of under 2.5 m (diagonal parking allowed) and a width of approximately 1.7 m are allowed. At the same time, three people have to fit into the PPV 1.0 in order to serve 95 percent of all conceivable trips. The standard that the interior should offer a friendly, spacious interior is an additional design impediment. PPV is able to fulfill this challenge with a one-box design that includes three seat occupancy (1+2 seater) in one row. The power train is coordinated and highly integrated as an efficient package with the floor assembly. A new body shell concept allows the windshield to be placed significantly farther forward. An important design element for this is the restored A pillar and very large glass panels. Another component of the structural concept is the driver door. A new swinging or sliding door concept guarantees that opening the door is a first-class experience, even in narrow parking spots.

Design development: Before the design is actually developed, the design DNA of the PPV 1.0 is defined in an interdisciplinary development group. To do so, widely varying urban spheres of association are created first and approximately 250 draft designs are developed based on these associations. The drafts, which will be consolidated into two different concepts from the preferred association, will then lead to the final concept decision. After this step, the design is developed in a typical digital CAS (computer-aided styling) process before the targeted design DNA can be implemented into the final design. In summary, PPV can be referred to as the world’s smallest self-driving bus.

The design language of the interior concept is very different from the exterior and relies heavily on the reduced communication DNA from the bus design and the IT world. The number of operation elements for the PPV 1.0 was reduced to an absolute minimum and the focus was put on intuitive operation. The driver seat is characterized by a modern, digital user interface, and the climate control design is based more on the urban spaces mindset and not on classic vehicle construction. An interior cleaning concept optimized to the cost of each trip, appropriate variability from the two-seater bench, omitting joints that collect filth, surfaces from boat construction, a spray-on floor from railway vehicle design, and consistently omitting “unnecessary” storage areas distinguish the interior as genuine car sharing useable space.

The drive: The drive concept of the PPV 1.0 is mainly based on 400V technology that is well developed and absolutely suitable for electronically driven urban vehicles. The technical data is completely competitive with 45 kW of drive power in the front, a maximum speed of 120 km/h, and a battery pack of nearly 20 kW/h. The range is at 80 km, even under extreme conditions, and is verified by a specially developed car sharing cycle. According to the share2drive business model, this dependably reaches the approximately two hours of operation that are required daily. Flex share from share2drive guarantees that the wireless charging processes will not fail. The conceptual decision of the tandem electrical motor design with two small-diameter electrical machines in the front end is based on the advantages of the crash design, as well as the demand to provide an agile city vehicle.

>> THE CONCEPT OF THE PPV IS TO DEVELOP A REALISTIC VEHICLE THAT IS A TIMELY ANSWER TO THE SHARED MOBILITY REQUIREMENTS

Safety requirement: In addition to the numerous measures in place to avoid accidents, the PPV 1.0 is characterized by superior crash safety (Figure 3). The special challenge of concept development is mainly the design of the frontal crash requirements. The very short frontend forces the development into a radical structural design with four load path planes and controlled deformation behavior. With a total deformation of approximately 350 mm, a mean crash impulse of 31 g with approximately 60 mm of firewall penetration is reached. Deformations were kept away from the centrally designed battery structure in side collisions. Crash resistance is complied with almost 60 kN for the roof crush resistance test according to the FMVSS (Federal Motor Vehicle Safety Standards) 216.

>> THE STRONG RESPONSE TO THE PPV 1.0 AS AN ANSWER TO FUTURE MOBILITY NEEDS IN A SHARED ECONOMY UNTIL 2020, HAS ALREADY INITIATED THE PPV 2.0 “SVEN”

Production advantages: The body shell is a FlexBody, which is a body construction kit that allows the development of profile-heavy, lightweight bodies with a hybrid design for vehicle projects with less than 10,000 production vehicles per year. Body structures can be developed and prepared for production in a very short time with FlexBody by a standardized process, as well as stringent division of the profiles and nodes (Figure 4). The greatest advantage is the very low investment. Construction methods with steel-intensive, and extremely high-strength materials are primarily used for the floor assembly of the FlexBody for the PPV 1.0. Aluminum solutions primarily dominate in the frontend and in the structure. A ladder-integrated frame protects the centrally designed battery. The static torsional stiffness of the 140 kg body is at a high level, with a lightweight index of approximately 3. The body shell is produced in what are called Innofix single shot fixtures and is designed for using a newly developed injection gluing procedure. 7,000 PPVs are planned to be produced annually in a two shift operation.

The PPV as solution for the mobility of tomorrow

Market development of new mobility solutions offers an interesting potential for concepts that merge mobility needs, new business models, and vehicle construction. The strong response to the PPV 1.0 offers an answer to future mobility needs in a shared economy until 2020, as a special vehicle solution has already initiated the PPV 2.0 “SVEN”.

In classic vehicle construction, the quickly advancing development of autonomous driving benefits customers with improved comfort and safety. However, autonomous driving functions greatly exceed this in a shared mobility world. In urban areas, they make the mobility of the population and its logistical implementation possible.

REFERENCES
[1] Kaas, H.W.; et al.: Automotive Revolution – Perspective Towards 2030. How the Convergence of_Disruptive TechnologyDriven Trends Could Transform the Auto Industry. McKinsey & Company, 2017
[2] McKinsey & Company: Carsharing & Co.: 2030_über zwei Billionen Dollar Umsatzpotenzial. Pressemitteilung vom 09.03.2017
[3] Anthrakidis, A.; Jahn, R.; Ritz, T.; et al.: Urbanes eCarSharing in einer vernetzten Welt. SteinbeisEdition, 2013

Klaus Wolff

Modern vehicles are complex systems dominated by continuously evolving software functions and highly cross-linked architectures. With shorter development cycles and increasing cost pressure, new approaches are required to provide safe and affordable mobility solutions. This paper tackles this by merging known computer science techniques with state of the art methods of mechanic and electric engineering: systems engineering is consistently done in four layers while retaining agile efficiency at the same time. Model-based requirements replace written text. Besides cost reduction through maintainable and reusable documentation, this approach enables semi-automated test case derivation cutting down testing effort. For the development of BMW’s next generation electrified drivetrain efficiency and quality objectives can be achieved. Thus, cost, quality and adaptability targets can be met at the same time.

System and Software Business Model Evolution

Automotive system development is confronted with conflicting requirements on the one side and market conditions on the other. Customers require a quicker reaction of product development to new technical trends. This results in a shorter time-to-market dropping from average values of five years in the 1980s to three years in the 21st century [1]. Including upgrades and facelifts as well, this even drops to a level of one to two years. With each system upgrade, customers demand more functionality at a similar price level. If inflation is taken into account, this requires a required cost reduction of 4 percent every year pushing available development budgets to steadily lower levels [2].
However, concentration on cost efficiency does not resolve the trade-off to be made. Individual, mechanically driven vehicles are being replaced by integrated mobility systems including the electrified drivetrain, vehicle-wide functionalities, user experience and diverse traffic scenarios. The integration is realized by complex software systems. If these are developed with the same methods and processes as during the last decades, verification and validation effort will explode. E.g., the migration from a state-of-the-art adaptive cruise control function to an auto pilot results in a validation effort increase by a factor in the magnitude of 100,000 [3]. Test effort, prototype vehicles and hence validation costs explode at abovementioned budget restrictions. As a result, quality assurance is performed risk-based where taken risks result in an explosion of software recall campaigns in the past decade [4].
For deriving right countermeasures, the weaknesses in current system engineering need to be analyzed (Figure 1).
At the begin of the development of new functionalities, system requirements and system architecture are difficult to be completely defined top down – they are usually being elaborated bottom up during prototype sessions to identify a desired behavior. However, description methods are missing to document doubtlessly for all later stages what shall be contained in the system. As a consequence, the entire system architecture is usually described incompletely and is therefore not maintainable. An incomplete or even missing system architecture leads, of course, to weak requirements on system level. Bottom up function level requirements have to be defined without taking consistent system interfaces into account. This causes multiple requirement alignment loops and hence early delay of project milestones. Hence, on a software level, unit tests are defined without consistent system and functional requirements which leads to additional integration loops caused by object code mismatches.
On a component level, test cases are not complete, causing similar integration issues on the vehicle level. These are mitigated by applying large vehicle fleets with intense staff involvement: error identification time is increased through failure detection on system level only, cost limits require a prioritization of test maneuvers.

Model-Based System based on Software Development Approaches

One main strategy to handle the mentioned conflicts between time-to-market, cost reductions, arising quality issues and the increased validation time on vehicle level is frontloading. This means it is necessary to increase the efforts in early development steps like requirements development, functional design and architectural design [5]. In fact, frontloading is not a new idea as it shall help to reduce efforts on the more cost-intensive verification and validation tasks on Hardware-in-the-Loop (HiL) level or vehicle level. Furthermore, frontloading is recommended by many standards like ISO/IATF 16949 and ISO 26262. However, it cannot be easily applied as it needs an interdisciplinary approach combining methods from known mechanic and electric engineering techniques as well as computers science approaches.
Model-based systems engineering focuses on a continuously evolving model-based development of architectures and requirements [6, 7, 8, 9]. While a systematic and semi-formal representation of requirements is more intensive in a first step, experience from large scale software projects shows an increased product quality. The higher quality of documents resulting from frontloading activities reduces following costs for validation significantly. High quality models will reduce communication efforts, inconsistencies between requirements and reduce the amount of defects and failures which would otherwise only be detected on later verification levels. An easier communication is especially important in the context of large teams, interdisciplinary exchange and collaborations with external partners and internal departments (aspects, which are all common in the automotive domain).
The System Modeling Language (SysML) is derived from the Unified Modelling Language (UML) which was introduced in the 1990ies [10, 11]. It provides a larger set of structural and behavioral diagram languages to specify systems from different viewpoints on different abstraction levels, but does not provide a concrete process or detailed guidelines which diagram types are to be used in which order or for which level of abstractions. Similar to EAST-ADL, BMW has proposed a model-based system engineering approach called SMArDT (“Specification Method for Architecture, Design and Test”) which comprises four levels: Requirements level, function design level, architectural level, hardware resp. software design level (EAST-ADL: vehicle, analysis, design and implementation level), as shown in Figure 2 [12].

SMArDT combines a systematic vertical refinement approach from layer to layer with a horizontal hierarchical composition from the context of the overall engine to specific modules. From layer to layer additional requirements are identified and derived from higher level requirements, where suitable, to establish a complete tracing (as demanded by standards like CMMI or ISO26262 [13, 14]). On the technical level a first separation between hardware and software aspects is performed, which are then implemented on the fourth level.
SMArDT supports a systematic step-by-step model-based requirement and function specification due to the four abstraction layers [15, 16]. In consequence, on each level the provided requirements and concepts are reevaluated and detailed, which – in terms of frontloading – ensures a very early verification and validation on the ongoing activities. Of course these steps are quite time-intensive but provide also high quality artifacts which can be used to significantly speed up the overall development process. The mentioned abstraction layers are applied for the structured documentation whereas the applied process is meant to be agile [17].
In the context of this paper we will focus on one of several possible new opportunities, which are provided by a high quality set of semi-formal models: the semi-automated generation of test cases [18, 19].

Semi-automated Test Case Generation

The function models on the second layer realized by activity diagrams, state charts and internal block diagrams provide already enough information to generate test cases for verification purposes automatically.
A corresponding process is illustrated in Figure 3.

Based on customer models, like use case and context diagrams, defined in the first layer, activity diagrams and state charts are defined during the function specification. These function models are defined in cooperation of specifier and tester to ensure that functional aspects, like correct failure handling, are also included. Based on these models from the function layer test cases can be generated automatically to fulfill the path coverage criteria C2c [20]. In addition, the tester can configure specific aspects of the model, like specific input parameter or decisions, to manipulate the test case generation for context-related needs.
Exemplary activity diagrams, which are used for test case generation, are shown in Figure 4. Different activities or decision node can be classified to adjust the test case generation for specific needs (e.g. test step execution time/cost, requirements, decision coverage). As the activity diagram and internal block diagram of the function
layer are refinements of the use case and context diagrams of the customer value layer (see Figure 2) and the activity diagram is based on the functional architecture described by the block diagram, the generated test cases represent all the aspects defined on both layers.
To be able to generate test cases from activity diagrams or state charts, besides a correct use of the SysML language, the explicit definition of expected output needs to be defined on an abstract level. While this is common for state charts the activity diagram language has been adjusted to fulfill these needs. Besides these technical requirements, high quality semi-formal models, representing an abstract but distinct functional description, are necessary to generate test cases, which can be used to verify a system based on defined requirements. These models are provided by the process and guidelines provided by SMArDT.

During the system requirement and function specification phase labels from a keyword database are reused to define interfaces and conditional aspects. These keywords are mapped to concrete platform-specific signals and their specific test execution. During the data dictionary implementation step for each keyword (and related signals), a concrete test sequence is implemented to be able to perform the initialization and evaluation automatically. Combining the mapping between keyword and signal database (and their test implementation) with the semi-automated test case generation, the effort to define, setup and execute verification tests is reduced significantly. In addition, because of the neutral nature of customer and function models the generated test cases can be reused for different platforms.

Application: Project “MTSF”

SMArDT and the approach for semi-automated test case generation is currently used in an ongoing series development project to define BMW’s upcoming generation of electric drives. In collaboration with the FEV Europe GmbH and the Software Engineering Chair of the RWTH Aachen University additional modeling guidelines for function models have been identified to allow a semi-automated test case generation, called “Model-based Testing of Software-based Functions” (MTSF).
During the development, efforts have been monitored systematically to evaluate if the proposed expectations are fulfilled. In Figure 5, a first evaluation on five different functions is shown, which highlights the additional effort on function specification level for specifier and tester to be able to derive test cases.

In relation to the complexity of the function the amount of effort, but also the amount of generated test cases, is increasing.
Function A is the first measured function including diagnosis and safety aspects and thereby highlighted the additional benefits in the context of these areas. As a path-wise test case generation requires logical branches to increase the amount of test cases, error detection and handling mechanisms highly increase the potential for automated test case generation.
Regarding the measured efforts it needs to be considered that the additional guidelines for test case generation have been applied the first time in a serious development context. Thereby, reduced efforts can be expected once the approach is established. In addition, not only the effort could be reduced, but also the quality of models is increased, because of the semi-formal nature of the introduced guidelines.
Nevertheless, comparing the measured efforts with ongoing traditional development, the expectations can already be matched, as reduced efforts on requirement interpretation and verification tasks are already negating the additional efforts on function specification level as shown in Figure 6.
Based on the current experiences further improvements on the test generation configuration are already identified to increase the quality of resulting test cases even more.
The overall process is supported by an integrated toolchain as represented in Figure 7. A fluent connection between the tools DOORS, PTC, ECU Test and HPQC is established to sustain the ongoing industrialization.

Summary and Outlook

The MTSF system engineering approach tackles the current conflict between solid requirements, test case and architecture definition for complex systems and cost and time pressure due to mobility market conditions. The method bases on model-based description of system functionalities through clearly defined abstraction levels. Semi-formal description enables efficient requirement alignment and semi-automated test case generation.
In this article, the design on the higher abstraction levels was focused sharing application experiences for the next generation of BMW’s electrified powertrains. For the first time, model-based specification was applied to system level development of automotive series products. Driven by a systematic function architecture definition, more than 50 functions reflect the designed behavior of energy management, charging and torque provision. Considering coverage criteria, test costs and execution time, test cases were derived semi-automatically for defined model paths. At the end of the workflow, automatically executable test sequences were produced.
The overall development effort could be reduced while working within given market and product milestones. Even more importantly, system quality is increased. More test cases are defined, test coverage can be determined in early stages, bugs can be identified at earlier design stages. Also, requirements, test cases and development artefacts can be aligned easily and traced doubtlessly.
Next steps will include the continuation of system development on lower abstraction levels. Quality gains will be observed – when reaching the vehicle test level, a significant reduction of prototypes and debugging phases is expected. The MTSF method will be expanded application-wise to other vehicle development domains outside the powertrain. Also, Failure-tree-analysis for e.g. safety applications will be facilitated. Next method development steps will focus the industrialization for large, distributed and cross-enterprise development teams. Here, we especially expect further work on bridging established development cultures of computer and engineering science domains.

REFERENCES
[1] Prasad, B.
Analysis of pricing strategies for new product introduction
Pricing Strategy and Practice,
Vol. 5 Issue: 4, pp.132-141
Bingley (UK), 1997
[2] Mohr, D. et al.
The road to 2020 and beyond: What’s driving the global automotive industry?
Mc Kinsey & Company, Inc.
Stuttgart, 2013
[3] Hübner, H.-P.
Automatisiertes Fahren –
Wohin geht die Fahrt?
Proc. 18. Kongress Fortschritte in der Automobilelektronik
Ludwigsburg, 2014
[4] Steinkamp, N.
2016 Automotive Warranty & Recall Report: Industry Insights for the Road Ahead, Chicago, 2015
[5] Kriebel, Stefan
Economic High Quality Software for Automotive Systems
3d Congress on Real Time, INCHRON; Braunschweig 2011
[6] Wymore, A. Wayne
Model-Based Systems Engineering CRC Press, Inc. USA, 1993
[7] Estefan, Jeff A.;
Survey of Model-Based Systems Engineering (MBSE) Methodologies
Incose MBSE Focus Group 2007
[8] Grönniger, Hans et al.
View-Centric Modeling of Automotive Logical Architectures
In: Tagungsband des Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung eingebetteter Systeme IV. Informatik-Bericht 2008-02, CFG-Fakultät, TU Braunschweig, 2008
[9] Kriebel, Stefan
Timing propagation in the development of software-based automotive systems 4th Symtavision NewsConference on Timing Analysis, Braunschweig
2010
[10] Weilkiens, Tim
Systems Engineering with SysML/UML: Modeling, Analysis, Design Morgan Kaufmann, USA, 2008
[11] Rumpe, Bernhard
Agile Modeling with UML: Code Generation, Testing, Refactoring
Springer International
Germany, 2017
[12] Cuenot, D. et al. Managing Complexity of Automotive Electronics Using the EAST-ADL 12th IEEE International Conference on Engineering Complex Computer Systems 2007
[13] Paulk, Mark
Capability Maturity Model for Software, John Wiley & Sons, 2002
[14] Hillebrand, Martin
Funktionale Sicherheit nach ISO 26262 in der Konzeptphase der Entwicklung von Elektrik/Elektronik Architekturen von Fahrzeugen KIT Scientific Publishing, Germany, 2012
[15] Grönniger, Hans et al.
View-Centric Modeling of Automotive Logical Architectures
4th European Congress ERTS – Embedded Real Time Software, Toulouse, 2008
[16] Grönniger, Hans et al.
In: Proceedings of the Object-oriented Modelling of Embedded Real-Time Systems (OMER4) Workshop, Paderborn, 2007
[17] Linz, Tilo
Testen in Scrum-Projekten Leitfaden für Softwarequalität in der agilen Welt dpunkt.verlag, 2. Auflage 2016
[18] Pretschner, Alexander et al.
Model-based testing for real. STTT 5(2-3): 140-157, 2004
[19] Philipps, Jan et al.
Model-Based Test Case Generation for Smart Cards.
Electronic Notes in Theoretic Computer Science 80: 170-184, 2003
[20] Liggesmeyer, Peter Software-Qualität: Testen, Analysieren und Verifizieren von Software Spektrum Verlag 2009

This article is an excerpt from the publication: “1. Kriebel, S., Richenhagen, J., et al.: High Quality Electric Powertrains by model-based systems engineering.
Published in: Proc. 26th Aachen Colloquium Automobile and Engine Technology (2017), Vol. 1, pp. 211-222, ISBN 978-3-00-054182-7 “

Dr. Johannes Richenhagen

For the functional safety of series production road vehicles, the standard ISO26262 specifies a comprehensive development process from concept to production. For prototype and demonstrator vehicles, no dedicated functional safety standard is available and ISO26262 is not applicable, because the development efforts would by far exceed the scope of a prototype build-up. Nevertheless, it is necessary to consider functional safety for prototype vehicles in order to protect operators, passengers and persons nearby the vehicle from any harm caused by a malfunction. An according documentation is essential, because it proves that the safety has been taken into account and safety measures have been implemented.
Therefore, FEV has developed a tailored functional safety process for prototype vehicles, which is based on the main tasks as defined in the concept phase of ISO26262, but with reduced complexity. These tasks are the preliminary item definition, a high-level hazard analysis and risk assessment and the definition of safety mechanisms which shall be implemented in the prototype vehicle. Furthermore, an iteration loop is included in the process, in order to re-assess the remaining risk in combination with the defined safety mechanisms (Figure 1).

Preliminary item definition

In this article, the transformation of a conventional powertrain into a P2 hybrid powertrain is chosen as an example for the prototype application. Besides the integration of a high-voltage system, the powertrain modification itself is safety-related, too, as will be shown for one its main functions, electric driving. The preliminary item definition describes all functionalities, operating modes, interfaces and operating conditions of the system of scope, i.e. the P2 hybrid system in our example. This information is an essential input for the identification of potential risks resulting from malfunctions of the item.

High-level hazard analysis and risk assessment

Main steps of the hazard analysis and risk assessment (HARA) are the selection of relevant use cases for the prototype vehicle, the functional hazard analysis (FHA) and the risk assessment of the resulting hazardous situations. The FHA assigns standard malfunctions (does not, too much, not enough, wrong direction/distribution, unintended, stuck) to each function. Combined with the respective use cases, these malfunctions result in hazardous situations. One example for the e-drive function of the prototype vehicle is:

• Function: Electric drive
• Use case: Vehicle is stopped at red traffic light or at cross roads
• Malfunction: Unintended torque
• Hazardous situation: unintended vehicle movement, resulting in crash with crossing vehicle

The risk assessment of such a hazardous situation is based on three criteria as defined in ISO26262. Exposure (E) represents the frequency of the use case – not of the hazardous situation. Severity (S) is the rating for the harm that can be caused to somebody. And controllability (C) is a measure for the ability of the vehicle driver to avoid the hazard by his intervention. Since the exact determination of these criteria is quite time-consuming, a simplified, conservative rating catalogue is applied for the prototype application and a risk level is calculated instead of an Automotive Safety Integrity Level (ASIL) as defined in ISO26262 (Figure 2).
The initial rating for the above mentioned example will be as follows:

• Exposure for standing at traffic light / cross roads: E = 3
• Severity for crash with crossing traffic: S = 3
• Controllability for unintended movement: C = 2

The C-rating is depending on certain boundary conditions. In the example, the maximum wheel torque that the electric machine can generate is lower than the brake torque which the vehicle driver can realize by pressing the brake pedal. If such boundary condition is not fulfilled or if it cannot be ensured, a more conservative rating has to be chosen.

With E + C = 5 and S = 3, a “Medium” risk level is resulting, which requires safety measures as described in the following paragraph.

Derivation of safety measures

In order to achieve the risk level “Acceptable”, safety measures have to be defined for the risk levels “Low”, “Medium” and “High” as shown in Figure 2.

For example, the “Medium” risk level can be reduced to “Acceptable” by several steps. The first step is the installation of an emergency stop button, which switches off the electric propulsion system. The driver has to be trained in its use, e.g. by inducing the fault on the test track. Only trained drivers will be allowed to operate the vehicle in urban traffic, which has to be documented e.g. by an according logbook in the vehicle. The C-rating is reduced from 2 to 1 with this measure. This will result in a “Low” risk according to Figure 2, so that an additional measure is needed. For example, the use of the prototype vehicle could be restricted to drive cycles with less than 1 percent of operating time at traffic lights and cross roads. This would reduce the E-rating from 3 to 2, resulting in an “Acceptable” risk. Since the example described in this article represents only one situation out of numerous other scenarios, there might be other risks that are rated as “High” and therefore demand further safety measures like monitoring algorithms. Such safety measures could then also be used for the mitigation of lower rated risks and allow to avoid restrictions like the limitation of use cases or operation of the vehicle by trained drivers only.

For the completion of the simplified functional safety process, it is important to ensure that the defined safety measures are implemented and tested before the actual investigations with the prototype vehicle start. This can be supported by check lists and tests of the vehicle on the test track.
Besides the achievement of technical targets, a strict compliance with a safety-related development and release process is mandatory also for prototype applications. FEV has developed the described prototype process for this purpose and successfully applied it in several projects.

Dr. Bastian Holderbaum, Marc Schneeberg