Conditions for a safe state of automated road vehicles

0 downloads 0 Views 399KB Size Report
Abstract: The term safe state is not yet defined accurately in the context of automated road vehicles. In this ... Afterward we start the derivation of the conditions for.
it 1/15

Conditions for a safe state of automated road vehicles Andreas Reschka, Markus Maurer

Abstract: The term safe state is not yet defined accurately in the context of automated road vehicles. In this paper we derive several conditions, which are in our opinion important for the discussion of a safe state for automated road vehicles. From an engineering view, several concepts on the classification of automation levels are analyzed and from their results and current research and development approaches a definition of a safe state is proposed. Especially the relation between risk and safety for passengers of automated vehicles and other traffic participants is considered. Several use cases for automated vehicles and events with impact to safety are discussed to identify conditions for a safe state in public traffic, which have to be fulfilled to keep the risk of operating an automated vehicle below a reasonable level. ACM CCS: Applied computing → Physical sciences and engineering → Engineering Keywords: Vehicle Technology, Autonomous Driving, Safety, Transportation

1 Introduction In recent development and discussions about automated vehicle guidance, the safe state is often referred to as a state, which has to be achieved in case of technical failures or dangerous situations. The term is used widely although there is no unique definition of it. Sometimes it is called risk-minimal state (German: risikominimaler Zustand) [9] or minimal risk condition [26]. In this article we focus on the term and its meaning, and the conditions which are relevant to operate an automated vehicle in a safe state. To clarify our understanding of a safe state, we give a short overview on the usage of it. Afterward we start the derivation of the conditions for a safe state with the possible situations in public traffic with mixed traffic of automated and manually driven vehicles. The events which can have an influence on safety for the driver1 , for passengers inside the automated vehicle, and the other traffic participants are discussed as well and lead to conditions that have to be fulfilled to operate in a safe state or to transfer the vehicle into a safe state.

1

A human driver according to [26] is a human person guiding a vehicle or sharing the control with a technical system. A technical system which guides a vehicle is called vehicle guidance system. The combination of a vehicle guidance system and a vehicle is sometimes called a driving robot, an autonomous vehicle or a self-driving vehicle. In [26] the term automated driving system is used for a vehicle guidance system in our understanding.

2 Vehicle Automation In state-of-the-art serial production vehicles advanced driver assistance systems (ADAS) support the driver and exculpate the driver from the driving task. E.g.: In the current Mercedes-Benz S-Class W222 two systems provide a combined longitudinal and lateral control of the vehicle called ’DISTRONIC PLUS with Steering Assist and Stop & Go Pilot’ [24]. Currently available ADAS like the system of Mercedes-Benz have to be monitored by a human driver for technical and judicial reasons, because they are not able to operate in every condition safely. Therefore, the driver has to monitor the traffic and to interfere if the vehicle is acting dangerously or the control is given back to him by the ADAS. As humans perform bad in monitoring a technical system, which is a relatively easy task [31, 2], future vehicle guidance systems will have to operate without permanent human monitoring. This human monitoring has to be replaced by self-monitoring of the vehicle and its vehicle guidance system. The degrees of the increasing automation of vehicle guidance have been a research topic in the past years and there are several different categorizations for automation levels. A generic approach to the classification of unmanned systems is an ongoing process in the Ad Hoc Autonomy Levels for Unmanned Systems Working Group (ALFUS) at the National Institute of Standards and Technology (NIST). The ALFUS project started in 2003 by defining terms and classifying systems to several autonomy grades. In [14] the terminology for unmanned

c de Gruyter Oldenbourg it – Information Technology 57 (2015) 1

1

systems is published in version 2.0. Fully Autonomous is an operation mode without human intervention. A Semi-Autonomous system is able to fulfill its mission mostly automated, but requires various levels of humanmachine-interaction. Between human interventions, the system is able to operate autonomously. Besides these two levels of autonomy, Huang [14] distinguishes further between Teleoperation and Remote Control. Teleoperation is a mode, where the operator is not aboard the unmanned system and uses only sensory feedback from the unmanned system to control its operation. Remote Control is applied, if the operator observes the unmanned system directly from outside [14]. These definitions allow a categorization of all kinds of unmanned system like ground vehicles, aircraft, spacecraft and robots. The classification of unmanned systems is not motivated by the function, but by the result of a detailed analysis on Human Independence, Mission Complexity and Environmental Complexity as presented in [15]. Here, Human Independence means the independence of the technical system from human interference. In Germany the Federal Highway Research Institute (BASt) has published a categorization of vehicle automation levels [9]. In the USA the Society of Automotive Engineers (SAE) [26] and the National Highway Traffic Safety Administration (NHTSA) [19] have published their own versions, which slightly differ from BASt’s definition of automation levels.

SAE Levels 0-2 In SAE Level 0 - No Automation (BASt: Driver only, NHTSA: Level 0 ) no automated driving functions are activated. In SAE Level 1 - Driver Assistance (BASt: Assisted (German: Assistiert), NHTSA: Level 1 ) either longitudinal or lateral control is executed by the driver and the other by the ADAS. There is no adequate classification for this case in the ALFUS framework, because vehicles with ADAS are not unmanned. The previously mentioned DISTRONIC PLUS is a system in this category, because longitudinal control is done by the ADAS and the driver is only assisted in lateral guidance. The driver has to monitor the system permanently and so, such a vehicle can not be unmanned. As Ohl [21] points out, up today all demonstrated driving functions of automated or autonomous vehicles in public traffic are at most SAE Level 2 - Partial Automation (BASt: Partially automated (German: teilautomatisiert), NHTSA: Level 2 ), because even in the automated driving projects from universities and companies, a safety driver is necessary or an emergency stop or a remote stop is integrated and the system is monitored by humans, e.g., [20, 10, 6, 4, 34].

SAE Level 3 - Conditional Automation In this article the systems have to fulfill at least SAE Level 3 - Conditional Automation, which is Highly Auto-

2

mated (German: hochautomatisiert) according to BASt [9] and Level 3 according to NHTSA [19]. The driver does not have a monitoring function and therefore the system has to maintain a safe state or transfer itself into a safe state without human assistance, if it is used in the appropriate situation. In this automation category, the driver is still in the loop as he has to take over control upon a request from the system within a short period of time. As [7] describes, a safe handover could last up to 8 seconds depending on the individual driver. Although systems in this automation level are manned, they fit into the category of Semi-Autonomous systems according to ALFUS, because they can operate autonomously between human interventions [14]. Currently, ADAS which can control the vehicle without human monitoring for limited situations are developed, like the Traffic Jam Assist from Audi AG [27]. Such systems are limited to a single use case like driving in traffic jams up to speeds of 17 m/s. If the system detects its functional boundaries, it tries to handover the control to the human driver. If a handover is not possible, it stops the vehicle immediately [13, 12]. The standing vehicle on a highway driving lane is discussed as a safe state, or at least a safer state than the uncontrolled driving vehicle. The circumstances in which a transition to this safe state is possible are limited - in this case to low velocities and a traffic jam situation.

SAE Level 4 - High Automation In SAE Level 4 - High Automation, which is Fully Automated (German: vollautomatisiert) according to BASt [9] and Level 4 according to NHTSA [19] a handover to the driver is no fallback strategy anymore. Thus, the system has to be capable of detecting its functional boundaries, and maintaining and reaching a safe state in every situation. The main difference from the highest SAE Level 5 - Full Automation is the limitation to certain driving situations in SAE Level 4. Thus, the vehicle can not be operated unmanned in every use case. In future development, a system which is capable of driving with higher speeds on highways could follow the traffic jam assist. In [29] the use cases Interstate Pilot with Availability through Driver and Full Automation with Availability through Driver include systems that can be used to drive automated without a permanent monitoring by the driver. Here the driver can still takeover the control and the system can try to handover to the driver. The system is furthermore capable of always reaching a safe state automatically. It only deactivates itself, if the driver has taken over control. Additionally, a deactivation requested by the driver could be delayed to avoid dangerous situations. In SAE Level 4 a human driver should be present in general, but there are situations, especially in limited applications where a human driver is not mandatory. E.g., the publicly funded research project aFAS (German abbreviation for Automated Unmanned Safeguarding Vehicle for Highway Shoulder

Roadworks) focuses on an unmanned safeguard vehicle for construction sites on German Autobahnen [28].

SAE Level 5 - Full Automation In SAE Level 5 no limitations are existent and the vehicle can be operated unmanned. The system is capable of driving autonomously without human monitoring. In [29] the use cases Autonomous Valet Parking and Vehicle On Demand fulfill the requirements for SAE Level 5. In both use cases the vehicle is capable of maintaining a safe state or transferring itself to a safe state in case of technical failures and any external events. An additional use case could be an automated bus, which always follows the same route and stops frequently to allow passengers to enter and leave. Such a system has been introduced by the company INDUCT called Navia in several prototype projects. The so called people mover operates in controlled environments and with low speeds [33]. Although the system is limited to a certain area, SAE Level 5 can be applied, because the vehicle has to reach a safe state for its passengers without human interference in every driving mission. In all provided examples the vehicle has to be able to transfer itself into a safe state or maintain a safe state. The resulting questions are, what a safe state for those use cases and in general is, how safety can be measured in specific situations and which operational risk is reasonable for automated driving.

3 The usage of the term safe state Safety is a relative measure, which depends on the individual perception of each involved subject in a situation. In ADAS development the ISO 26262 standard defines a safe state as ’An operation mode of a system or an array of systems without an unreasonable level of risk’ [17, Part I, 1.102]. By this definition a system is safe if the current risk is below an unreasonable level, where risk is a ’combination of the probability of occurrence of harm and the severity of that harm’ [17, Part I, 1.99]. An unreasonable risk is a ’risk judged to be unacceptable in a certain context according to valid societal moral concepts’ [17, Part I, 1.136] and harm is a ’physical injury or damage to the health of persons’ [17, Part I, 1.56]. As a consequence a safe state maintains if the current risk of operation is below a level where injuries and damages to the health of persons are more probable than reasonable. The level which is accepted by society is not yet defined. Although discussed controversial, it seems that the ISO 26262 standard is applicable to high and full automated vehicles, because assuming that the controllability for the driver and other traffic participants is low or null in an automated vehicle, an ASIL (Automotive Safety Integrity Level) determination according to ISO 26262 is possible and the resulting requirements can be derived from the standard [1]. It is subject to further research, if those resulting requirements are sufficient for an open system with an environment perception and an

unlimited number of possible situations. It may be necessary to have a closer look on public traffic and the influencing factors for possible situations to determine a level of risk, which is reasonable. A possible approach to identify the most dangerous situations could be to look at traffic accident data [30]. According to Grunwald [11] the acceptable reasonable risk is strongly related to the benefits of the usage of a technology. It seems necessary to define multiple metrics for the assessment of the technology, which cover potential benefits and potential risks of it to define the level of reasonable risk. For this article, it is assumed that the level is already defined and can be used as a reference, although this is still an ongoing research process. As the technological details of automated vehicles are mostly not known to their users, they use them without a strong knowledge of possible functional deficits. Therefore, it is necessary to use the perspective of a manufacturer of automated vehicles to look at the risks resulting from automated vehicles sold to customers or operated by the manufacturer as a mobility service provider. Grunwald [11] points out, that the users of automated vehicles and other traffic participants experience the risks from automated vehicles in a passive role. From a manufacturers point of view, risk is something which has to be reasonable for customers and other stakeholders affected by the usage of the product. Thus, the reasonable risk of operation is not in the responsibility of users and other traffic participants, but of manufacturers. As stated in [25] universal definitions of safety and reasonableness are not discussed satisfyingly. In [26] a safe state is referred to as a minimal risk condition whereas in [9] a safe state is referred to as a riskminimal state. Both terms don’t set the risk in relation to the involved subjects and a minimal risk does not automatically implicate safety. Therefore, the usage of these terms can be misunderstood. Figure 1 shows this issue. On the x-axis the current risk of operation is depicted. In the middle of the x-axis a point is marked with a vertical line, which is the level of reasonable risk. The risk-minimal state defines the lowest achievable risk. The area between the risk-minimal state and the reasonable risk is the safe state of operation. An operation with a higher risk than the reasonable level is an unsafe operation. A proposed description of this safe state is a term which has a relation to the risk for passengers and other traffic participants. As a result, a safe state as used here is a state where the risk for passengers of an automated vehicle and other traffic participants is below an unreasonable level. This implies a possibly necessary tradeoff between safety for passengers of automated vehicles and other traffic participants. The risk of operation depends on the current performance requirements and the current available performance capabilities. The demanded performance requirements

3

safe state risk-minimal state

reasonable risk

risk

Figure 1: safe state vs. minimal risk in relation to the current risk

functional capabilities

risk-minimal state

functional requirements Figure 2: Functional capabilities vs. functional requirements vs. reasonable risk vs. risk-minimal state; for this illustration, functional capabilities and functional requirements are measured in an equivalent metric, which is not yet available

depend on the current driving situation (cf. sec. 6) and the driving maneuvers and their properties necessary for solving the current driving situation. The current available performance capabilities are a result of internal system monitoring. They are an aggregation of values from vehicle sensors, environment sensors, and monitoring functions of involved hardware and software. Combining those values with models of the vehicle, the environment, and performance metrics for hardware and software modules result in a self-representation of the overall system, which reflects the current performance capabilities. As Bergmiller [3] points out, this is necessary for x-by-wire vehicles and thus, also for automated vehicles, because their actuators are controlled by-wire. Figure 2 shows the relation between current performance capabilities, current performance requirements, and the reasonable risk. In the brighter area, the capabilities are higher than the requirements and therefore a safe state of operation is possible. In the darker area, the requirements are higher than the capabilities. The unsafe state has to be avoided. Assuming capabilities and requirements are measured in an equivalent unit, e.g., a parametrized model of the vehicle and its capabilities vs. the derived necessary capabilities from the current driving situation, the difference between capabilities and requirements is a value for the current risk of operation. If it is positive, the vehicle is in a safe state, if it is equal, the system operates with the reasonable risk. If it is negative, which means that requirements are higher than capabilities, the operation is unsafe. The risk-minimal state is a state where the difference between functional capabilities and functional requirements is maximal and therefore, the resulting risk is minimal. According to Isermann et al. [16] a safe state for automobiles is a standstill or driving with low speed at a non-hazardous place. To reach this non-hazardous place the actuator control by the driver has a mechanical fallback solution. With this the driver can steer and brake without electronics. In automated vehicles a mechanical fallback solution in the actuator control is quite useless.

4

Although it is imaginable if electric power is missing or other problems occur, a brake pressure is applied by a spring mechanism and the steering angle is set to zero mechanically. In this case, the vehicle would at least stop, but not necessarily at a non-hazardous place, because the vehicle could stop in any situation anywhere on the road. Even the mechanical fallback solution is not guaranteeing safety, because a steering column could brake under certain circumstances, which results in a (very low) residual risk that the vehicle is uncontrollable by the driver. The driver would have to stop the vehicle immediately and the standstill could be anywhere on or off the road. Because of the low probability of such events, it is accepted by society in today’s vehicles. The probability of mechanical failures per operating hour is quite low and it is possible that with the increasing number of programmable electronic and electric systems (E/E systems) in vehicles, the combined number of electrical and mechanical failures is going to increase in the future as well. Consequently, the number of vehicle breakdowns would increase and vehicles without mechanical fallback and a driver would have to stop more often at hazardous places. Although research results for these effects are not known to the authors. To reach a similar reliability of the E/E systems in comparison to mechanical systems, functional redundancy seems to have the greatest potential, because this principle is used in other safety critical systems as well, e.g., aircraft, trains, power plants. A value how reliable automated vehicles have to be, is not explicitly defined by governmental institutions, but it seems not reasonable to increase the overall number of breakdowns of vehicles because of more and more complex E/E systems and automation technology.

4 Safety-critical Events During operation of an automated vehicle, the current risk changes frequently. If a level of a reasonable risk is defined, a frequent risk estimation has to be integrated into a vehicle guidance system, to compare the current risk with the reasonable risk. Additionally, a method to anticipate the risk of the development of the current situation is necessary to prevent dangerous situations in the near future. The vehicle guidance system has to determine its own capabilities and derive the necessary capabilities from the current situation and its development. The difference between both is a strong indicator for a high risk of a situation. Additionally, the following events can influence the risk and the capabilities of the vehicle guidance system. These events are derived from [22] and [8]. • Technical errors and failures in the vehicle guidance system and the vehicle, which lead to reduced capabilities, e.g., a mechanical defect of the vehicle or of an electronic control unit (ECU). This includes failures to perceive risk-increasing events.

• Changes of the environmental conditions which increase the functional requirements, e.g., fog, rain or ice on the road. • Reaching functional boundaries in situations which have not been considered in development, e.g., pedestrians on a motorway. • Erratic behavior of other traffic participants, which can lead to collisions or dilemmas, e.g., loss of control. • Technical errors and failures in traffic control elements, e.g., wrong signs and markings. • Act of nature beyond control, e.g., earthquakes, floods or sun storms, which influence Global Navigation Satellite System (GNSS) signal availability [5, 32]. After single or multiple events a safe state has to be maintained by the vehicle guidance system.

5 Safe states for Exemplary Use Cases The safe state of an automated vehicle heavily relies on the situation in which the state has to be maintained or reached. At first the use cases from section 2 are analyzed on their safe states and afterward generic conditions for a safe state are derived from the exemplary functions. In [22] a similar approach has been taken for the use cases described in [29].

mandatory. The system allows the activation only in conditions, which it was designed for [26]. A safe state has to be maintained by the system, but a human is still present in the vehicle. A handover to the driver can be requested, but a takeover by the driver may not be given. Thus, after a period of time or if the risk increases, the vehicle should enforce other actions, although this is not required according to [26]. These actions are highly dependent on the current situation. The traffic jam assist described in section 2 would stop the vehicle to a standstill. This is a safe solution, because in a traffic jam, it is probable that other vehicles are moving slowly. The risk would increase, if the traffic jam resolves and the vehicle is still standing on a lane of a highway. Thus, the safe state only remains safe for the traffic jam situation on a highway, resulting in a classification of SAE level 3 for the traffic jam assist. In urban traffic standing vehicle seems to be no unreasonable danger, because of lower relative speeds. While driving with higher speeds, e.g. 30 m/s on a rural road, coasting is too dangerous and immediate stopping could result in a dangerous situation as well. A controlled stop is a better solution, if the driver does not take over control. After stopping, the humans aboard have to take over control or safeguard the vehicle according to regional law, if a manual drive is not possible as well.

5.1 SAE Levels 0-2 In systems with a SAE Levels 0-2 classification, monitoring by a human driver is mandatory. Therefore, a safe state maintains, if the human driver controls the vehicle or is at least requested to do so. This can be reached either by automatically deactivating the system and signalizing the driver, or the human driver gets control by intervening in the system’s execution, e.g., by applying a brake pressure or a steering wheel force. In most cases a handover to the driver is sufficient. The only exception is an unconscious or unattended driver, who cannot take over control immediately. In this case the vehicle would coast and thus, gets out of control, either for a short period, or completely. This case is accepted, because the assistant functions are defined only to assist, not to fully control the vehicle. As a result, a first action to maintain a safe state is to handover control to an available human driver, which is also possible in the use cases 1 and 3 in [29]. Bainbridge [2] points out that humans are not performing well at monitoring tasks. For SAE Levels 1 and 2 the driver is responsible for the vehicle guidance and has to monitor the driver assistance systems. To avoid the ’Ironies of automation’ as called by Bainbridge [2] higher automation levels should not have to rely on human monitoring.

5.2 SAE Level 3 - Conditional Automation In conditionally automated systems a permanent monitoring of the system and the traffic by a driver is not

5.3 SAE Level 4 - High Automation Highly automated vehicles do not rely on the human driver as a fallback solution, but are still limited to certain situations. Therefore, a driverless operation is only possible, if the use case is limited to a scenario which can be handled by the vehicle guidance system and a human driver is not necessary to reach a safe state, e.g., for safeguarding the vehicle. A safe state is reached, if the human driver is in control, or the vehicle is no danger to others and its passengers. For the Interstate pilot with available human driver [29] a stop on a driving lane is not safe, if high relative speeds are possible, e.g. on rural roads and highways. Thus, the vehicle has to move out of traffic and come to a stop, where relative speeds are below a certain level, the vehicle is not blocking emergency vehicles and / or emergency routes and the passengers can exit safely. This applies to urban traffic as well. Especially blocking emergency vehicles and routes could lead to a delayed help for others in case of an emergency. Additionally, a stop is only safe, if the vehicle and its state are visible to other traffic participants. Another option is to drive on with a reduced functionality based on the system’s internal conditions or the external conditions (functional degradation). The vehicle guidance system changes driving parameters like speed, Time-To-Collision and longitudinal and lateral safety distances according to the internal and external conditions. The measures which reduce the operational risk are

5

dependent on the situation the vehicle is in. In [23] such an approach is described.

in a safe state. The safe state would be only maintained if the conditions for the stopped vehicle apply.

7 Future work 5.4 SAE Level 5 - Full Automation Within the highest degree of automation a human driver is not mandatory. Therefore, the vehicle has to maintain or reach a safe state in every situation autonomously. Therefore, a stop in unmanned operation is only safe where the vehicle does not have to be safeguarded according to traffic rules. E.g., stopping on a driving lane on any road and stopping on an emergency lane on a highway is not safe, because there is no person able to safeguard the unmanned vehicle. The two use cases described in section 2 from [29] can be classified as SAE Level 5 and a safe state has to be maintained or reached by the vehicle guidance system in every situation. The conditions for a safe state are the same as in section 5.3, extended to all possible situations and not limited to certain environments.

6 Conditions to a safe state The discussion of the above mentioned use cases and their safe states results in the following conditions of a safe state: 1. The vehicle is controlled by a driver. 2. The vehicle is controlled by Teleoperation via Vehicleto-Operator communication (V2O) [18, 29]. 3. The vehicle is driving automatically within its functional boundaries, especially with safe speed and adequate safety distances. 4. The vehicle is stopped under the following conditions: • Relative speeds to other traffic participants are below a certain level. • The vehicle and its state are visible to other traffic participants. • The vehicle is not blocking emergency vehicles or emergency routes. These conditions can be applied to every type of road and every traffic situation. Thus, it is possible to use these conditions as a set of general conditions for automated vehicles in urban traffic. If the driver is in control, an automated vehicle has to be treated like a conventional vehicle. No further constraints have to be considered and a safe state from the system’s point of view maintains. Thus, a further discussion of this condition is not necessary, as it is already accepted by society and thus the operation is within a reasonable risk. Vehicle control by Teleoperation is not yet tested and released to traffic. For the future of automated vehicles, it seems possible to use Teleoperation in case an automated vehicle can not reach a safe state. But it has to be considered that for several seconds or minutes the vehicle could be stopped at a hazardous place and thus be not

6

As a result of this approach to specify the safe state for automated vehicles, the following research topics have been identified for our further research in the field of safety for automated road vehicles: • Which maximum value for the risk level of automated vehicle operation is adequate? • Which maximum value for a relative speed of others to a stopped automated vehicle is adequate? • Which safety functions are necessary to measure the current risk of operation? • Which safety functions are necessary to maintain a safe state? • Which consequences can hazardous events have in detail? Acknowledgement This publication has been made possible, in the Stadtpilot project at the TU Braunschweig, the aFAS project funded by the BMWi, and the Villa Ladenburg project of the Daimlerund-Benz-Stiftung. We would like to thank all project members for their ideas and criticism of our work. Literature [1] G. Bagschik and T. Stolte. Personal communication, 2014. [2] L. Bainbridge. Ironies of automation. Automatica, 19:775–779, 1983. [3] P. Bergmiller. Towards Functional Safety in Driveby-Wire Vehicles. PhD thesis, Technische Universit¨ at Braunschweig, 2014. [4] A. Broggi, M. Buzzoni, S. Debattisti, P. Grisleri, M. C. Laghi, P. Medici, and P. Versari. Extensive Tests of Autonomous Driving Technologies. IEEE Transactions on Intelligent Transportation Systems, 14(3):1403–1415, 2013. [5] C. S. Carrano, C. T. Bridgwood, and K. M. Groves. Impacts of the December 2006 solar radio bursts on the performance of GPS. Radio Science, 44(1), 2009. [6] A. Chatham. Google’s Self Driving Cars: The Technology, Capabilities, & Challenges, 2013. Keynote of the Embedded Linux Conference 2013. [7] D. Damb¨ ock. Automationseffekte im Fahrzeug - von der ¨ Reaktion zur Ubernahme. PhD thesis, Technische Universit¨ at M¨ unchen, 2013. [8] K. Echtle. Fehlertoleranzverfahren. Springer-Verlag Berlin Heidelberg, 1990. [9] T. M. Gasser, C. Arzt, M. Ayoubi, A. Bartels, L. B¨ urkle, J. Eier, F. Flemisch, T. Hesse, W. Huber, C. Lotz, M. Maurer, S. Ruth-Schumacher, J. Schwarz, and W. Vogt. Rechtsfolgen zunehmender Fahrzeugautomatisierung : gemeinsamer Schlussbericht der Projektgruppe. Wirtschaftsverlag NW, Verlag f¨ ur neue Wissenschaft, 2012. [10] A. Geiger, M. Lauer, F. Moosmann, B. Ranft, H. Rapp, C. Stiller, and J. Ziegler. Team AnnieWAY’s Entry to the 2011 Grand Cooperative Driving Challenge. IEEE Transactions on Intelligent Transportation Systems, 13(3):1008–1017, 2012. [11] A. Grunwald. Gesellschaftliche Risikokonstellation f¨ ur autonomes Fahren - Analyse, Einordnung und Bewertung. In M. Maurer, C. Gerdes, B. Lenz, and H. Winner, editors, Autonomes Fahren - Technische, rechtliche

und gesellschaftliche Aspekte, pages 661–685. Springer Vieweg, 2015. [12] M. H¨ orwick and K.-H. Siedersberger. Aktionspl¨ ane zur Erlangung eines sicheren Zustandes bei einem autonomen Stauassistenten. In 4. Tagung Fahrerassistenz, Munich, Germany, 2010. [13] M. H¨ orwick and K.-H. Siedersberger. Strategy and architecture of a safety concept for fully automatic and autonomous driving assistance systems. In 2010 IEEE Intelligent Vehicles Symposium (IV), pages 955–960, San Diego, CA, USA, 2010. [14] H.-M. Huang, editor. Autonomy Levels for Unmanned Systems (ALFUS) Framework - Volume I: Terminology - Version 2.0 (NIST Special Publication 1011-I-2.0). Gaithersburg, MD, USA, 2008. [15] H.-M. Huang, E. Messina, and J. Albus. Autonomy Levels for Unmanned Systems (ALFUS) Framework - Volume II: Framework Models - Version 1.0 (NIST Special Publication 1011-II-1.0), 2007. [16] R. Isermann, R. Schwarz, and S. St¨ olzl. Fault-tolerant drive-by-wire systems. IEEE Control Systems, 22(5):64– 81, 2002. [17] ISO 26262:2011 Road vehicles - Functional safety, 2011. [18] R. Matthaei. Personal communication, 2014. [19] National Highway Traffic Safety Administration (NHTSA). Preliminary Statement of Policy Concerning Automated Vehicles, 2013. [20] T. Nothdurft, P. Hecker, S. Ohl, F. Saust, M. Maurer, A. Reschka, and J. R. B¨ ohmer. Stadtpilot: First fully autonomous test drives in urban traffic. In 2011 IEEE International Conference on Intelligent Transportation Systems (ITSC), pages 919–924, Washington DC, USA, 2011. [21] S. Ohl. Fusion von Umfeld wahrnehmenden Sensoren in st¨ adtischer Umgebung. PhD thesis, Technische Universit¨ at Braunschweig, 2014. [22] A. Reschka. Sicherheitskonzept f¨ ur automatisierte fahrzeuge. In J. C. Gerdes, B. Lenz, M. Maurer, and H. Winner, editors, Autonomes Fahren - Technische, rechtliche und gesellschaftliche Aspekte, pages 490–513. Springer Vieweg, 2015. [23] A. Reschka, J. R. B¨ ohmer, T. Nothdurft, P. Hecker, B. Lichte, and M. Maurer. A surveillance and safety system based on performance criteria and functional degradation for an autonomous vehicle. In 2012 IEEE International Annual Conference on Intelligent Transportation Systems (ITSC), pages 237–242, Anchorage, AK, USA, 2012. [24] M. Schopper, L. Henle, and T. Wohland. DISTRONIC PLUS mit Lenk-Assistent und Stop&Go Pilot. ATZextra, 18(5):106–114, 2013. [25] B. W. Smith. Lawyers and engineers can speak the same robot language. Robot Law, forthcoming 2015. [26] Society of Automotive Engineers (SAE). Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems, 2014. [27] B. Stertz. Piloted driving, 2013. http://www.audiusanews.com/newsrelease.do;?id=3304. [28] T. Stolte, G. Bagschik, A. Reschka, and M. Maurer. Automatisch fahrerlos fahrendes Absicherungsfahrzeug f¨ ur Arbeitsstellen auf Autobahnen (aFAS). In Automatisierungssysteme, Assistenzsysteme und eingebettete Systeme f¨ ur Transportmittel 2015 (AAET), Braunschweig, Germany, 2015. [29] W. Wachenfeld, H. Winner, C. Gerdes, B. Lenz, M. Maurer, S. A. Beiker, E. Fraedrich, and T. Winkle. UseCases des autonomen Fahrens. In M. Maurer, C. Gerdes, B. Lenz, and H. Winner, editors, Autonomes Fahren Technische, rechtliche und gesellschaftliche Aspekte, pages 9–37. Springer Vieweg, 2015.

[30] T. Winkle. Sicherheitspotenzial automatisierter Fahrzeuge: Erkenntnisse aus der Unfallforschung. In M. Maurer, C. Gerdes, B. Lenz, and H. Winner, editors, Autonomes Fahren - Technische, rechtliche und gesellschaftliche Aspekte, pages 351–376. Springer Vieweg, 2015. [31] R. M. Yerkes and J. D. Dodson. The relation of strength of stimulus to rapidity of habit-formation. J. Comp. Neurol. Psychol., 18:459–482, 1908. [32] X. Yue, W. S. Schreiner, Y.-H. Kuo, B. Zhao, W. Wan, Z. Ren, L. Liu, Y. Wei, J. Lei, S. Solomon, et al. The effect of solar radio bursts on the GNSS radio occultation signals. Journal of Geophysical Research: Space Physics, 118(9):5906–5918, 2013. [33] R. Zhang. Autonomous Mobility-on-Demand A Solution for Sustainable Urban Personal Mobility, 2014. http://energyclub.stanford.edu/wpcontent/uploads/2014/04/Zhang.pdf. [34] J. Ziegler, P. Bender, H. Lategahn, M. Schreiber, T. Strauß, and C. Stiller. Kartengest¨ utztes automatisiertes Fahren auf der Bertha-Benz-Route von Mannheim nach Pforzheim. In Workshop Fahrerassistenzsysteme, Walting, Germany, 2014.

Andreas Reschka studied Computer Science at the Technische Universit¨ at Bergakademie Freiberg and the University of Hildesheim (Bachelor 2006, Master 2008). He was research assistant at the Institute of Technology at the University of Hildesheim 2008-2013, and sholarship holder of the Daimler und Benz Stiftung 2013-2014. Since 2014 he is research assistant at the Institute of Control Engineering at the Technische Universit¨ at Braunschweig. In 2009 he started his work on safety for automated vehicles in the Stadtpilot project. Address: Technische Universit¨ at Braunschweig, Institute of Control Engineering, D-38106 Braunschweig, E-Mail: [email protected] Prof. Dr.-Ing. Markus Maurer studied Electrical Engineering at the Technische Universit¨ at M¨ unchen (Diplom 1993). He then joined the group of Prof. E. D. Dickmanns at the Universit¨ at der Bundeswehr M¨ unchen where he finished his PhD in 2000 in the field of automated driving. He received the Research Award of Universit¨ at der Bundeswehr M¨ unchen for his PhD thesis in 2000. From 1999 to 2007 Prof. Maurer was a project manager and head of the development department of ’Driver Assistance Systems’ at Audi. Since 2007 he is a full professor for Automotive Electronics Systems at the Institute of Control Engineering at the Technische Universit¨ at Braunschweig. Since 2001 he was involved in several committees and councils, e.g. in the project ’invent’, the Collaborative Research Center ’Cognitive Automobiles’, the Uni-DAS e.V., the NFF (Nieders¨ achsisches Forschungszentrum Fahrzeugtechnik) and the ’round table automated driving’ of the BMVI. Address: Technische Universit¨ at Braunschweig, Institute of Control Engineering, D-38106 Braunschweig, E-Mail: [email protected]

7