CASE - Connected, Autonomous, Shared & Service and Electric Drive. These four terms describe the major trends Mercedes-Benz Passenger Car has identified for the next years. In this keynote, we present some insights into these challenges and discuss their impact on requirements engineering. • Traditional combustion engines are replaced or supplemented by electric driving. Reasons for this are both a growing ecological understanding and regulative forces. Local emission free driving is identified as a means to lower fine dust - which becomes more and more relevant due to increasing urbanization - and increases independence from fossil fuel. • New types of companies are entering the automotive market. Apple, Google, or Tesla - just to name a few - have their origin in other technological fields. • Especially young people value mobility, but no longer the personal ownership of a car. It is ok to have a car at hand when they have a mobility need. We can observe this trend in many areas of our life (“Sharing Economy”).
Today, the automotive world faces much more changes than in the past decades. In the past, we mainly viewed evolutionary changes – better solutions in areas of safety, comfort, or driver assistance. In pace with digital advances, more and more electronics entered the car resulting in about 100 ECUs in modern premium cars, several hundred sensors and actuators, dozens of communication busses with several ten thousands of different signals. Core paradigms, however, kept unchanged; like combustion engine, and the car is driven by a human driver who is connected to his or her environment mainly by human’s senses (except radio and/or telephone). Having an own car is a kind of status symbol, and cars are developed by traditional automotive OEMs. Now, these paradigms (partially) are no longer valid and we face more and more disruptive change, like: cess to his or her car through an app or web page. Additionally, functions like community-based parking, i.e. sharing information on free parking lots collected by parking sensors build in Mercedes-Benz cars, aim to share information between cars (carto-X communication).
In the past few years we see a significant increase of functions on the way to autonomous driving that is not only available in research cars, but accessible to normal drivers. A system known as “drive pilot” offers semi-automated driving on highways, supports overtaking and can initiate an emergency braking. With parking pilot, it can place the car autonomously in a parking lot – even with the driver being outside the vehicle. 2
Before we can discuss the impact of the CASE areas on automotive requirements engineering, we first have to define automotive requirements engineering. At Mercedes-Benz passenger car development, the term “system” plays here an important role. A “system” is a set of functions that provides added value to a customer. Typical examples of systems are exterior light (consisting of low and high beam, braking light, turn indicator, and so on), automatic backdoor, adaptive cruise control, or traffic sign assistant. Often, systems can be ordered as optional equipment. To implement a system, we usually need an interaction of many components. So, system-level requirements have to be refined and allocated to components. Figure 1 illustrates the decomposition of the system Adaptive Cruise Control with Steering Assistant into several functions and its allocation to several components.
Adaptive Cruis e Control with Steering As s istant
Fig. 1. Allocation of Functions to Components FCuunscttoiomne-/r view ▸ Maintain speed ▸ Maintain distance ▸ Lane keeping └ Lane detection └ Steer vehicle └ Brake vehicle
Function structure
Component mapping Stereo Multipurpose camera
Radar Decision unit
Electronic stability control
Instrument cluster
Brake
Electric
Steering Technic-/ Component view Overall, we can observe three requirements areas: • Concept Requirements: Here, product innovations are shaped. Starting point is often a vision. The vision is refined both from a user’s perspective (user’s demands) and technological side (possibilities). Here, prototypes play an important role. Usually, we do not see “classical” requirements engineering artifacts here. Instead, presentations, pictures, mission statements, high-level user stories, or personas are used. • System Requirements: Here, requirements are documented on system-level describing the various system functions along with their allocation to the individual components. For the adaptive cruise control example, the specification consists of 130 pages. From the system specification we are able to derive requirements packages that are handed over to the components. • Component Requirements: Most of the electronics are not built by automotive OEMs themselves. Instead, they are developed by suppliers. Thus, an explicit requirements specification as part of the development contract is necessary. Beside the product requirements, this component specification also contains process requirements (e.g. on logistics, quality management, or development responsibilities). When compiling the component requirements specification, the engineer in charge has to consolidate the handed over system requirements packages. If he or she encounters contradicting requirements from the different systems, there is the need for clarification and harmonization.
Both system and component requirements specification are documented in the tool DOORS from IBM. Additionally, test specifications are also documented in DOORS. The individual test cases are linked with the requirements they are verifying. Test specifications are mainly written on system level as integration and testing on system level are in an OEM’s responsibility. Testing on component level is mainly done on supplier’s side. However, there are also tests on component level; but mainly as random sample tests. 3
In this section, we discuss the impact of the CASE trends on requirements engineering. 3.1
From an automotive requirements engineering perspective, electric drive is almost a “normal” technological innovation, like replacement of traditional instrument cluster needles by high-resolution displays. However, on the concept requirements we saw that identifying the market’s needs was (and is) challenging. Which performance requirements (like range, charging time, maximum speed) at which price is demanded and accepted by the market? When we have these constraints, system and component level requirements engineering is more “traditional”. For new types of automotive components, like DC-DC converter, electric motor, or HV-battery, we had to develop adequate quality requirements. Here we observed that in the beginning we tended to be too strict. As we are now specifying the fourth generation of electric drive components, we see a “normalization” of quality requirements. 3.2
Requirements engineering challenges in the connectivity and shared & services field are multifaceted: • For intra-car needs, like simple connection of consumer devices in the car infrastructure, it is again “standard.” From a technological point the variety of devices along with the high change rate is clearly a challenge. But this does not require new requirements engineering approaches. Clearly, requirements change management and requirements variant handling has to be done more strictly, but there is nothing really new. • The web-based access of a driver to his or her car (e.g. to see the current charging status of the HV-battery or the car’s location) brings in requirements engineering technologies from the IT field. So, some news from an automotive RE perspective, but not from requirements engineering in general. • Communication between cars (either directly or by means of backbone servers) implies from a requirements engineering perspective mainly dealing with uncertainties (how reliable are the transferred information?), security issues (is there an attack?), and standardization (the more partners are offering information, the higher is the benefit for all). • Offering new ways of getting temporary access to mobility, for instance by freefloating car sharing or app-supported renting of private owned cars.
In essence, we can conclude that connectivity as well as shared & services bring new requirements engineering challenges into the automotive business. But from an RE perspective, there is nothing really new. 3.3
From a requirements engineering perspective, with autonomous driving we are indeed entering a new field. Here, a system has to interact with the real world without a human fallback option and no immediate accessible safe state. The more we are moving ahead in that field, the more challenges we face, like: • Detecting the state of a traffic light can be a really hard problem if there are multilights (e.g. for separate lanes or different directions) • On average, we face an obstacle object on motorways every 8,000 km. The reaction to such an object should be adequate. • Interaction with human road users: At intersections, crosswalk, bottlenecks, to name just a few, the negotiation with others is often done by gesture or other informal means of communication. • In critical situations (e.g. a mudslide on the motorway) the driver is requested by the police to behave against clear regulations (e.g. use a prohibited motorway exit or drive back contrary to the driving direction.
From these examples we can easily see that there are uncountable situations that cannot be foreseen and it is thus impossible to specify the desired behavior precisely. So, classic solution-oriented requirements engineering approaches are doomed to fail. Clearly, we have to start with goal-based requirements. But here we often end up with contradictions, like the following simple example shows: • Goal 1: Do not pass a red traffic light • Goal 2: If an emergency vehicle (e.g. emergency doctor) approaches, enable its bypassing So, we might run in the situation that we are waiting ahead of a red traffic light, when an emergency vehicle approaches from the back. Shall we pass the red traffic light? Shall we move the car on the pavement? Shall we wait as the emergency vehicle has other options? And please note: We already have identified this situation; however, there are many options that have to be evaluated in the concrete context at hand. There are even more situations that nobody has already identified.
From a requirements engineering perspective we are facing a completely new class of problems where no proper requirements engineering solutions are available yet. 4
Automotive business is facing radical changes in years to come – in fact, the changes have already started. At Mercedes-Benz passenger car the key change areas are summarized with the abbreviation CASE: Connectivity, Autonomous, Shared & Services, and Electric Drive. From a requirements engineering perspective, some change areas can be treated with automotive requirements engineering means; some change areas require the adaptation of requirements engineering approaches that are well-known from other types of projects outside the automotive world. With autonomous driving a new class of problem shows up, where traditional requirements engineering approaches seem to fail.
The good news is that requirements engineering does not come with a well-defined set of tools; instead it emerges with technologies it is coping with. We will not see a direct move to autonomous driving – instead there will be a stepwise migration from assisted driving via semi-automated driving (where a driver has to monitor the system constantly) via highly automated driving (where the driver does not have to monitor the system all the time but is able to take over within a short time frame) to fully automated driving (where a driver is not necessary at all). Fortunately, requirement engineering has also a possibility to give its answers to the new challenges step-by-step.