Testing and Evaluation Methods for ICT-based Safety …vti.diva-portal.org/smash/get/diva2:674079/FULLTEXT01… · · 2013-12-03Collaborative Project Grant Agreement Number 215607

Testing and Evaluation Methods for ICT-based Safety Systems Collaborative Project

Grant Agreement Number 215607

Deliverable D1.1

State of the Art and eVALUE scope

Confidentiality level: Public

Status: Final

Executive Summary eVALUE will address the real function of ICT-based safety systems and their capability to perform the function through two courses of action: defining and quantifying the function out-put to be achieved by the safety system and developing the testing and evaluation methods for the ICT-based safety systems.

The safety systems within the eVALUE scope are classified into four clusters: longitudinal, lateral and yaw/stability. The fourth cluster remains open for upcoming systems. Based on market availability and penetration rate, the consortium decided to focus on eight preventive or mitigating safety systems: ACC, FCW and CM by braking, in the longitudinal assistance domain; BSD, LDW and LKA, in the lateral assistance domain; and finally, ABS and ESC, in the yaw/stability assistance domain. Following the description of current test and evaluation methods, sensor technologies, system function output and ECUs globally applicable to ICT-based safety systems, the report covers these technologies and components for the eight se-

lected systems in detail.

As a next step to this deliverable and according to the work plan, concepts for design re-views, physical vehicle testing as well as laboratory testing will be analysed. The result will be an in-depth understanding of the possibilities to investigate and evaluate the eight active safety systems within the first phase of the project. The different concepts will then support the decision about the development of the testing and evaluation methods that are able to point out the safety benefit of those systems in the most representative way.

Deliverable D1.1

eVALUE 2 ICT-2007-215607 eVALUE-080402-D11-V14-FINAL.doc

Document Name

eVALUE-080402-D11-V14-FINAL.doc

Version Chart

Version Date Comment 0.1 18.02.2008 Draft version created by ROBOTIKER 0.2 28.02.2008 Draft version to be discussed during 4/3/08 meeting 1.0 06.03.2008 Draft version, based on outline approved during 4/3/08 meeting 1.1 14.03.2008 Draft version, contributors compiled by ROBOTIKER 1.2 17.03.2008 Draft version, general conclusions added, reviewed by IKA 1.2b 18.03.2008 Draft version, reviewed by SP 1.2c 19.03.2008 Draft version, reviewed by VTI 1.2d 24.04.2008 Draft version, reviewed by IBEO 1.2e 25.03.2008 Draft version, reviewed by CRF 1.2f 26.03.2008 Draft version, reviewed by VTEC 1.3 31.03.2008 Final version, generated by ROBOTIKER 1.4 02.04.2008 Final version as delivered to EC

Authors

The following participants contributed to this deliverable:

Name Company Chapters I. Camuffo CRF 2 K. Fürstenberg, D. Westhoff IBEO 2,7 A. Aparicio IDIADA 2 A. Zlocki, J. Lützow, M. Benmimoun, M. Lesemann

IKA 2, 3, 4, 5, 6

I. Iglesias, L. Isasi,. J. Murgoitio ROBOTIKER-TECNALIA 1, 2, 3, 5, 6, 7 J. Jacobson, H. Eriksson, J. Hérard SP 2, 3, 6, 7 S. Leanderson, K. Heinig, A.-S. Karlsson VTEC 2, 3, 5, 6, 7 J. Jansson, H. Andersson VTI 2, 3, 5, 6, 7

Coordinator

Dipl.-Ing. Micha Lesemann Institut für Kraftfahrwesen Aachen Steinbachstraße 7, 52074 Aachen, Germany Phone: +49-241-8027535 Fax: +49-241-8022147 E-mail: [email protected]

Copyright

© eVALUE Consortium 2008

Deliverable D1.1


Table of Contents

1 INTRODUCTION........................................................................................................... 6

2 STATE OF THE ART..................................................................................................... 7

2.1 Roadmap of ICT-based safety systems ................................................................... 7

2.1.1 Sensor Technologies and Trends......................................................................... 8

2.1.2 Actuators and Trends......................................................................................... 11

2.1.3 ECUs and Trends............................................................................................... 13

2.2 Testing and Evaluation Methods............................................................................ 16

2.2.1 Standards and Reports ...................................................................................... 16

2.2.1.1 Testing Based on Systems.......................................................................... 16

2.2.1.2 Testing Based on Accident Statistics........................................................... 18

2.2.2 Other Projects .................................................................................................... 19

2.2.2.1 ASTE .......................................................................................................... 19

2.2.2.2 PReVAL ...................................................................................................... 21

2.2.2.3 AIDE ........................................................................................................... 22

2.2.2.4 APROSYS................................................................................................... 23

2.2.2.4.1 APROSYS Pre-crash System Test Methodology.................................. 23

2.2.2.4.2 Assessment methods for a side pre-crash protection system............... 23

3 Scope of eVALUE........................................................................................................ 25

3.1 CLUSTER 1: Longitudinal assistance domain........................................................ 27

3.1.1 Adaptive Cruise Control (ACC)........................................................................... 27

3.1.2 Forward Collision Warning (FCW)...................................................................... 27

3.1.3 Collision Mitigation (CM) .................................................................................... 28

3.2 CLUSTER 2: Lateral Assistance Domain............................................................... 29

3.2.1 Blind Spot Detection (BSD) ................................................................................ 29

3.2.2 Lane Departure Warning (LDW)......................................................................... 29

3.2.3 Lane Keeping Assistant (LKA)............................................................................ 30

3.3 CLUSTER 3: Yaw / Stability Assistance Domain ................................................... 31

3.3.1 Antilock Brake System (ABS) ............................................................................. 31

3.3.2 Electronic Stability Control (ESC)....................................................................... 31

Deliverable D1.1


4 CONCLUSIONS .......................................................................................................... 33

5 GLOSSARY AND ACRONYMS................................................................................... 35

6 LITERATURE .............................................................................................................. 37

7 ANNEX........................................................................................................................ 42

7.1 State of the art ....................................................................................................... 42

7.1.1 Detailed description of ICT based safety systems .............................................. 42

7.1.1.1 Cluster 1: Longitudinal Assistance Domain ................................................. 42

7.1.1.2 Cluster 2: Lateral Assistance Domain.......................................................... 44

7.1.1.3 Cluster 3 Yaw/Stability Assistance Domain ................................................. 46

7.1.1.4 Cluster 4: Additional Assistance Domain..................................................... 47

7.1.1.5 Sensor Technologies and Trends................................................................ 49

7.1.1.5.1 RADAR ................................................................................................ 49

7.1.1.5.2 LIDAR .................................................................................................. 51

7.1.1.5.3 VISION................................................................................................. 53

7.1.1.5.4 Infrared (IR).......................................................................................... 55

7.1.1.5.5 Specific Dynamic Sensors.................................................................... 57

7.1.1.6 Actuators and Trends.................................................................................. 60

7.1.1.6.1 Warning ............................................................................................... 60

7.1.1.6.2 Support and Autonomous Intervention ................................................. 61

7.1.1.7 ECUs and Trends........................................................................................ 69

7.1.1.7.1 Functional Safety ................................................................................. 72

7.1.1.7.2 Reliability.............................................................................................. 76

7.1.2 Evaluation methodology ..................................................................................... 78

7.1.2.1 Standards and Reports ............................................................................... 78

7.1.2.2 Other Projects ............................................................................................. 99

7.2 Scope of eVALUE................................................................................................ 109

7.2.1 Adaptive Cruise Control (ACC)......................................................................... 109

7.2.2 Forward Collision Warning (FCW).................................................................... 113

Deliverable D1.1


7.2.3 Collision Mitigation (CM) .................................................................................. 117

7.2.4 Blind Spot Detection (BSD) .............................................................................. 120

7.2.5 Lane Departure Warning (LDW)....................................................................... 123

7.2.6 Lane Keeping Assistant (LKA).......................................................................... 127

7.2.7 Antilock Brake System (ABS) ........................................................................... 130

7.2.8 Electronic Stability Control (ESC)..................................................................... 133

Deliverable D1.1


1 INTRODUCTION

ICT-based safety systems have proven to be a key contributor to the reduction of road casu-alties in the last 20 years. Some of these systems, such as ABS, are nowadays mandatory for new vehicles. In the near future it is likely that other systems will also be mandatory for new vehicles. Accident data has already proven the beneficial effects of systems such as ESC, which seems a good candidate to be included.

All OEMs have implemented in their product range a series of ICT-based safety systems which sometimes mislead the customers in two main aspects: real function of the system and capability of the system to perform the function.

The eVALUE project will address these two aspects through two courses of action:

1. Definition and quantification of the system function to be achieved by the systems

2. Development of testing and evaluation methods for ICT-based safety systems.

This document identifies the technologies and the test and evaluation methods representa-tive for ICT-based safety systems, focusing on commercially available or systems under de-velopment with the aim to prevent or mitigate accidents.

Following the description of current test and evaluation methods, sensor technologies, sys-tem function output and ECUs globally applicable to ICT-based safety systems are pre-sented. An overview of certain systems that are currently available and aiming to increase vehicle safety is given. The involved sensors and actuators as well as the ECUs are also covered.

Much more detailed information to all covered topics is given in the Annex of this report.

Deliverable D1.1


2 STATE OF THE ART

Present safety systems can be classified considering the criteria of active and passive safety. Active safety systems support the driver before a potential crash. The grade of support ranges from acoustic or visual warnings, to interventions in the brake/engine or steering sys-tem. Passive safety systems can be understood as protecting mechanisms, which contribute to the reduction of the accident consequences (see Fig. 2-1).

Active Safety• Warning Systems• Assisting Systems• Automatic Safety Systems

Passive Safety• Safety Systems for minor Accidents• Safety Systems after Crash

Pre-Crash

Acute Occ. Protection Rescue

Collision Avoidance

Post-CrashNormal In-Crash

Situ

atio

nS

yste

mA

ctio

n

Haz

ard

Time

Accident Prevention

Hazard Detection

Damage ReductionHazard

MitigationSta

ge Hazard Avoidance

Fig. 2-1: Classification of active and passive safety

Today different systems for active and passive safety, such as collision avoidance, pre-crash and post-crash are under development or already on the market. The state of the art analysis of all ICT-based safety systems provides an overview of modern and future systems.

2.1 Roadmap of ICT-based safety systems

In Fig. 2-2 a roadmap for ICT-based safety systems is given. The time horizon ranges from today up to long term (> 10 years). All systems help to improve safe driving in order to pre-vent accidents or mitigate the consequences of an accident by means of active safety.

The roadmap shows that ICT-based systems are getting more and more complex, combining existing functionalities, thus the necessary technology needs to be more reliable.

Deliverable D1.1


todayshort-term- 5 years

medium-term5 - 10 years

long-term> 10 years

ACC ACC Stop&Go

LDW

ESC

ABS

Traction Control

Blind Spot Monitoring

Night Vision

BrakeAssistant

Driver Drowsiness Warning

Obstacle and Collision Warning

Lane KeepingAssistant

Adaptive Headlights

Speed Alert

Active Font Steering

Torque Vectoring

Damper Control

Roll Stability Control

Curve Speed Assistant

Warning Traffic Jam End

Active Rear Steering

Active WheelLoad Distribution

Active SpringSystems

Adaptive BrakeAssistant

Intersection Assistant

Lane Change Assistant

Merging Assistant

Overtaking Assistant

Left Turning Assistant

IVDC


Lane Change Warning

Long. Collision Avoidance

Collision Mitigation by Braking

E-Call

Pedestrian Protection

Autonomous Driving

Pre-Crash Systems

Fig. 2-2: Roadmap – time horizon for safety relevant ICT-based systems

Therefore the state of the art for sensor technology, actuators, electronic control elements and necessary hardware is described in the following chapter. Future trends are given, which indicate the next development step of these technologies.

The description of the ICT based systems presented on Fig. 2-2 can be found in Annex 7.1.1 - Detailed description of ICT based safety systems.

2.1.1 Sensor Technologies and Trends

Depending on the safety system functionality, a particular system may use a combination of the following sensor technologies: sensors that detect longitudinal or lateral proximity ob-jects, and sensors that detect features on the roadway or that detect in-vehicle parameters required to achieve stability of the subject vehicle. For instance, in the case of BSM (Blind Spot Monitoring) short-range rear proximity objects can be detected either by IR, vision, short range radar or Laserscanner technologies.

The following picture shows the different view areas coupled with the sensor technologies.

Deliverable D1.1


Fig. 2-3: Sensor technologies depending on the view area

The different sensor technologies that can be applied to the ICT-based safety systems can be summarized in the following:

• Radar. This technology uses high-frequency electromagnetic waves to measure dis-

tance and relative speed. Commonly used radar systems operate at 24 GHz and at 76/77 GHz. 79 GHz can be considered as a future trend.

• Lidar and laserscanner. Laser Imaging Detection and Ranging or laser radar is the

generic term for laser-based sensors. Laserscanner sensors are also called scanning Lidar. They increase the field of view and the resolution of lidar/radar sensors. Laser-scanner track and classify road users and obstacles in the field of view.

• Vision. Vision-based systems use one or more digital video cameras to view the

characteristics of the roadway and/or the objects near or around the subject vehicle. Image processing will determine parameters such as lane position or presence of ob-jects in the path of the subject vehicle, for instance.

• IR. Active IR sensing technologies use an IR LED and a corresponding IR detector

cell to measure lateral distances between points on the subject vehicle and detect-able characteristics on the roadway surface. Both active and passive IR technologies are used in automotive night vision systems. The system used by some manufactur-ers is a near infrared system (NIR) that requires illumination, while other systems are FIR based. Second generation systems will include object recognition and provide some kind of driver support apart form just displaying the IR image.

FRONTAL

LATERAL

REAR

BLIND SPOT

Deliverable D1.1


• Specific dynamics sensor, such as wheel speed sensor, yaw rate sensor, accelera-

tion sensor, steering wheel angle sensor and other sensors are used in some sys-tems by certain OEMs.

Three major trends can be found today in the field of automotive sensors:

• Integration of sensors: Variety of applications require complex measurements that

do not rely on a single sensor signal. For instance, it is very common to measure temperature to compensate for sensor drift. Measuring temperature does not require a complex sensor but e.g. measuring humidity, a variety of gases or even fragrances, oil quality or several axes of vehicles dynamics call for sophisticated solutions. The in-tegration of several sensors needs new stacking and housing technologies. There-fore, paying special attention to the interdependencies of the suggested measuring principles is still a must.

The integration of proximity sensor and other sensors used to create situational awareness outside of the host vehicles body is also another example of sensor inte-gration.

• Distributed systems: Advances in sensor technology and computer networks have

enabled distributed sensor networks (DSNs) to evolve from small clusters of large sensors to large swarms of micro-sensors, from fixed sensor nodes to mobile nodes, from wired communications to wireless communications, from static network topology to dynamically changing topology. However, these technological advances have also brought new challenges to processing large amount of data in a bandwidth-limited, power-constraint, unstable and dynamic environment. Recent developments in DSNs are focused on four aspects: network structure, data processing paradigm, sensor fu-sion algorithm with emphasis on fault-tolerant algorithm design, and optimal sensor deployment strategy.

• Sensor fusion / virtual sensors: Data fusion refers to the fusing of information re-

sulting from several, possibly different, physical sensors, i.e. to compute new virtual sensor signals. These include underlying real sensors used to measure characteris-tics of the environment of the car, to monitor the internal parameters and status of the vehicle and to observe or anticipate the driver’s intent and driving behaviour. All sig-nals are fed into a sensor integration unit, which merges the information from different sources and allows the computation of virtual sensor signals. These, in turn, may be used as inputs to various control systems, such as antiskid systems and adaptive cruise control systems, or in Human/Machine Interfaces (HMI), such as e.g. a dashboard or overhead display.

There is a huge potential for the use of data and sensor fusion technology to substi-tute expensive precision sensors and to create high-precision virtual sensors at a modest cost.

Deliverable D1.1


The possibility to compute virtual sensor signals allows assessing complex dimen-sions like oil quality or obstacle detection. Additionally, fault diagnosis/self-test of the physical sensors can be improved. Thus, by using sensor fusion, analytical redun-dancy is introduced, which can be used to detect and isolate different sensor faults. Classical designs rely on hardware redundancy to achieve these goals, which is a very expensive solution compared to using sensor fusion software.

Sensor technologies are explained more in detail in the Annex 7.1.1.5 Sensor Technologies and trends (page 49).

2.1.2 Actuators and Trends

Depending on the safety system functionality, its function output can be one or a combination of the following:

• Warning: The output from the function is a haptic, acoustic and/or visual warning to

the driver issued by the ICT-based safety system activated. In this case, the system relies on the driver to respond to the warning, with the appropriate action to avoid any hazard. Thus, for proper functionality of the system the driver must responds cor-rectly, e.g. as intended by the system designer.

• Support: The function output is providing a support to the driver linked to vehicle

components such as engine, braking, steering and/or transmission. Unlike a warning the supportive function provides a physical contribution to the driving task by e.g add-ing a torque in the steering or building up the brake pressure. However, rather than carrying out the entire action this type of actuators actively supports and contributes to the driver’s action and gives feedback to the driver on which should be his/her re-sponse.

• Autonomous intervention: A function output through the engine, or through braking,

steering and/or transmission. Occurs when the ICT-based safety system reaction im-plies a physical response such as braking of the subject vehicle for instance and the subject vehicle itself acts directly for the proper functionality of the safety system.

Deliverable D1.1


Fig. 2-4: Warning and autonomous intervention in ICT-based safety systems.

There is currently a generalized trend of integrating electronic devices in existing elements of the steering, engine, and gearbox, allowing autonomous behaviours meant to give more complex answers to the new requirements of the safety systems. In addition, communication among all these systems is now vital, since many systems make use of several vehicle elec-tronic and mechanical devices to solve dangerous situations effectively. The first ESC gen-eration e.g. was limited to stabilize the car actuating exclusively on the brake system. How-ever, today it can stabilize the vehicle more effectively using the brake system, the differen-tial control system and the management of the engine or gearbox.

Fig. 2-5: All-wheel drive schematic

Another trend that is becoming more popular is to replace mechanical actuators with electri-cal ones. Control and operational modes of systems based on this type of electrical actuators

Deliverable D1.1


are then greater than before. A good example for this can be found in electric power steering, EPS, broadly used today in the Automotive industry with multiple possibilities of interaction with safety systems and different modes of operation.

In other systems like the braking system, mechanical parts will be replaced by electrical parts. This change will contribute to increase operation logic versatility and easiness of inte-gration level, in more complex systems.

The electronic-mechanic interface that enables this interaction between safety systems and system components, basically mechanical (braking system, for instance), is not completely free of errors but still valuable for simplifying and extending the operation modes of the safety system.

Fig. 2-6: Electric braking calliper used in the EWB system (source: Siemens-VDO)

A more detailed description on the actuators implemented on the ICT-based safety systems can be found in Annex 7.1.1.6 Actuators and trends (page 60).

2.1.3 ECUs and Trends

Electronic Control Units (ECUs) are subsystems consisting of CPUs and assorted signal in-puts and outputs dedicated to controlling a component within the vehicle. They range in complexity from an Engine Control Unit which handles the logic for managing the power-train system efficiency to an Anti-lock Braking (ABS) Control unit that monitors vehicle speed and brake fluid, to a simple body module that controls the automatic door locks or power win-dows. In many cases, these modules communicate with each other through such protocols as CAN, LIN, J1850, and J1959.

Historically, automotive electronics have been built up using discrete, smaller integrated cir-cuits. They relied on proprietary, dedicated wire communication schemes, at least for many sensor systems, and directly wired power outputs to the actuators. This led to large PCBs,

Deliverable D1.1


large ECU housing sizes, and excessive wiring. Before in-vehicle networks, point-to-point control was the rule, which meant that every system was connected to its control point by a separate wire. Each new wire added complexity and potentially decreased reliability. Wiring introduces other problems since it consumes space, adds weight and expense, is susceptible to EMI, and can be difficult to maintain.

Improvements in vehicle-networking standards and mixed-signal semiconductor processes are addressing these issues and introducing new possibilities to distribute intelligent systems throughout a vehicle. The trend in vehicle-networking standardization includes the wide adoption of CAN and LIN architecture, now in version 2.0. FlexRay protocol serves also as a communication infrastructure for future generation high-speed control applications in vehi-cles, providing various network topologies, communication modes, and message exchange principles. The MOST protocol is a networking standard intended for interconnecting multi-media components in vehicles. It differs from existing vehicle bus technologies due to the fact that an optical fibre is used as the physical medium, thus providing a bus-based network-ing system at bit-rates much higher than available on previous vehicle-bus technologies (see fig. 2.7).

Fig. 2-7: Different network standards in a car.

Basically, LIN and CAN network standards are providing a balance between performance and cost optimization across automotive systems. CAN provides a high-speed network for chassis, power-train and body-backbone communications, while LIN answers the need for a simple network for sensor and actuator subsystems that reduces cost and improves robust-ness through standardization. The wide use of CAN and the availability of LIN coincides with

Deliverable D1.1


improvements in mixed-signal semiconductor-process technologies that bring together all the functionality needed for smaller automotive systems onto a single IC, or a few ICs for more advanced systems.

All together, the vehicle networking standards and advanced mixed-signal processes provide an opportunity for automotive manufacturers to introduce affordable new electronic systems as well as to reduce the cost of existing systems. They also improve maintenance and reli-ability while providing advanced convenience and safety features to the occupants of a car.

In the future, automotive networks will simplify the operation of control systems and simulta-neously increase the number of features by attaching more and more control modules into high-speed data networking backbones.

In-vehicle networking is a mission-critical component of environmentally friendly automobiles such as hybrids, which would not be possible without fast, reliable inter-communication bet-ween hybrid-drive components. Hybrids include energy storage system, which means battery charging and management. The architecture also requires precise coordination between the electric motor and the gasoline engine – adding up to a lot more control and a lot more com-munication.

Within the next years, FlexRay will increase its market penetration. FlexRay is a high-speed (10 Mbps) network well-suited for time-critical applications. It has been in development since

1999 and is now in use in some vehicles, for safety applications such as active suspensions.

Fig. 2-8: Network standard data rate vs. relative cost per node

Because of the growth forecast in the number of ECUs, automotive engineers are looking to combine the functions of multiple ECUs into one. In addition to reduced complexity, func-tional integration also improves cost efficiency. This trend towards combining ECUs presents both a challenge and an opportunity to semiconductor companies. On one hand, it typically means more than one transceiver and perhaps more than one microcontroller per ECU.

Deliverable D1.1


Some companies are taking advantage of the trend by integrating more functionality into their transceiver products. This integration reduces costs and increases reliability because there are fewer components on the ECU circuit board. The architecture also gives first-tier elec-tronic module suppliers and auto manufacturers more flexibility and scalability. Integrating other functions into transceivers has the benefit of allowing the implementation of fail-safe safety features. If, for example, an MCU fails, a smart transceiver can isolate it from the rest of the network.

The integration of CAN/LIN plus other ECU components and functionality will be one of two major networking trends. The other will be the steady growth of FlexRay. Integrated CAN/LIN components will surpass standalone components in the long run and FlexRay will sustain a high growth rate.

ECU technologies are discussed more in detail in the Annex 7.1.1.7 ECUs and Trends (page 69).

2.2 Testing and Evaluation Methods

This section will present the current state-of-the-art with respect to testing and evaluation of active safety systems. The first part will briefly introduce existing and upcoming testing stan-dards and recommendations, and the second part will present results of other research pro-jects that might have an impact on the work to be carried out in the eVALUE project.

2.2.1 Standards and Reports

For ABS, ESC, ACC, FCW, and LDW international performance testing standards and re-ports are available today. Additionally, standardization work is on-going for Lane Change Decision Aid Systems (e.g. Blind Spot Detection) as well as Low Speed Following Systems and Full Speed Range ACC Systems.

2.2.1.1 Testing Based on Systems

In this section, a list of relevant standards and reports is presented. The standards and re-ports are coarsely grouped into four areas: general, longitudinal assistance, lateral assis-tance, and yaw/stability assistance. More thorough descriptions of selected standards can be found in Annex 7.1.2 Evaluation methodology.

General

• ISO 15037-1:2006 Road vehicles – Vehicle dynamics test methods – Part 1: General

conditions for passenger cars [15037-1]

• ISO 15037-2:2002 Road vehicles – Vehicle dynamics test methods – Part 2: General

conditions for heavy vehicles and buses [15037-2]

Longitudinal Assistance Domain

Deliverable D1.1


• ISO 15622:2002 Transport information and control systems – Adaptive Cruise Control

Systems – Performance requirements and test procedures [15622]

• ISO 15623:2002 Transport information and control systems – Forward vehicle colli-

sion warning systems – Performance requirements and test procedures [15623]

• ISO/DIS 22178 Intelligent transport systems – Low speed following (LSF) systems –

Performance requirements and test procedures

• ISO/DIS 22179 Intelligent transport systems – Full speed range adaptive cruise con-

trol (FSRA) systems – Performance requirements and test procedures

• SAE J2399 Adaptive Cruise Control (ACC) Operating Characteristics and User Inter-face [J2399]

• SAE J2400 Human Factors in Forward Collision Warning Systems: Operating Char-

acteristics and User Interface Requirements [J2400]

• FMCSA-MCRR-05-007 Concept of Operations and Voluntary Operational Require-

ments for Forward Collision Warning Systems (CWS) and Adaptive Cruise Control (ACC) Systems On-Board Commercial Motor Vehicles [FMCSA05b]

Lateral Assistance Domain

• ISO 17361:2007 Intelligent transport systems – Lane departure warning systems –

Performance requirements and test procedures [17361]

• ISO/DIS 17387 Intelligent transport systems – Lane change decision aid systems –

Performance requirements and test procedures

• SAE J2478 Proximity Type Lane Change Collision Avoidance

• FMCSA-MCRR-05-005 Concept of Operations and Voluntary Operational Require-

ments for Lane Change Warning System (LDWS) On-Board Commercial Motor Vehi-cles [FMCSA05a]

Stability/Yaw Assistance Domain

• ISO 3888-1:1999 Passenger cars – Test track for a severe lane-change manoeuvre –

Part 1: Double lane change [3888-1]

• ISO 3888-2:2002 Passenger cars – Test track for a severe lane-change manoeuvre –

Part 2: Obstacle avoidance [3888-2]

• ISO 6597:2005 Road vehicles – Hydraulic braking systems, including those with elec-

tronic control functions, for motor vehicles – Test procedures [6597]

• ISO 7401:2003 Road vehicles – Lateral transient response test methods – Open-loop

test methods [7401]

• ISO 7975:2006 Passenger cars – Braking in a turn – Open loop test methods [7975]

• ISO 21994:2007 Passenger cars – Stopping distance at straight-line braking with

ABS – Open-loop test method [21994]

Deliverable D1.1


• SAE J2536 Anti-lock brake system (ABS) road test evaluation procedure for trucks,

truck-tractors and buses [J2536]

• FMVSS 126 Laboratory test procedure for electronic stability control systems

[FMVSS126]

• GRRF-63-26 Draft global technical regulation on electronic stability control systems

Standard/Report ACC FCW BSD LKA LDW ABS ESC ISO 3888-1:1999 ● ISO 3888-2:2002 ● ISO 6597:2005 ● ISO 7401:2003 ● ISO 7975:2006 ● ISO 15622:2002 ● ISO 15623:2002 ● ISO 17361:2007 ● ISO/DIS 17387 ● ● ISO 21994:2007 ● ISO/DIS 22178 ● ISO/DIS 22179 ● SAE J2399 ● SAE J2400 ● SAE J2478 ● SAE J2536 ● FMCSA-MCRR-05-005 ● FMCSA-MCRR-05-007 ● ● FMVSS 126 ● GRRF-63-26 ●

Table 2-1: Connection between different standards/reports and systems (standard names put in italic are not yet public available or at different levels of development)

The connections between standards/reports and different systems are summarized in table 2-1. Naturally, there are more standards/reports available for the systems which have been around for a while, i.e. for ABS and ESC systems. There are also standards available for manoeuvring aids for low speed operation, e.g. reverse collision warning system, but they have been omitted in this report, as they are not considered relevant in terms of safety.

2.2.1.2 Testing Based on Accident Statistics

The previous section discussed standards and reports which are targeting a specific system. However, the tests which are presented in this section are derived from accident data and consequently they do not target a specific system but rather specific (crash imminent) traffic scenarios.

Deliverable D1.1


The Integrated Vehicle-Based Safety System (IVBSS) programme has published a report recommending a basic set of crash imminent test scenarios for integrated vehicle-based safety systems designed to warn the driver of an impending rear-end, lane change, or run-off-road crash [810757]. The scenarios are selected based on the U.S. 2000-2003 General Estimates System (GES) crash databases.

The scenarios are divided into the following categories:

• Rear-end crash threat scenarios

• Lane change threat scenarios

• Road departure crash threat scenarios

• Multiple-threat scenarios

• No-warn threat scenarios

More information on the IVBSS imminent crash test scenarios can be found in Annex 7.1.2 Evaluation methodology.

2.2.2 Other Projects

Strategies and methodologies for test and evaluation of preventive safety functions have been addressed in several research projects in Europe and US during the last years. This section provides a short survey of some of the work done in the field within EU and brings up some key aspects and concepts that are of importance for the future eVALUE work that can be concluded as follows:

� While PReVAL project addressed how to evaluate different systems, ASTE ad-dressed the potential and feasibility of a future performance testing program, where harmonization of test methods and systems is concluded to be an important first step. In AIDE the focus was on methods for evaluating IVIS, but these methods could also be used in evaluation of preventive safety functions (acceptance, workload and us-ability). Therefore it would be of interest for the eVALUE project.

� All these projects described next provided general test concepts for evaluating safety systems; however test methods explicitly derived in detail were not provided so far. Thus it will be the scope of eVALUE to derive detailed test methods.

2.2.2.1 ASTE

This study investigated the feasibility of setting up an objective test program for intelligent vehicle safety systems. The aim of the work was

• To assess the feasibility of setting up an independent performance and conformance testing programme for Intelligent Vehicle Safety Systems

Deliverable D1.1


• To define the needed methods and principles for verification and validation of Intelli-gent Vehicle Safety Systems, and

• To evaluate if a consensus of the proposed principle can be achieved with different stakeholders.

The results from the study were presented in the final report [ASTE]. The report contains a proposal on how to define performance testing and the important dimensions of testing of ac-tive safety systems that need to be considered. A summary of this discussion is provided in Annex 7.1.2 Evaluation methodology.

A major output from ASTE is the proposal of different test strategies for doing performance testing. Two main approaches were proposed for physical testing, each taking into account traffic scenarios based on real accident statistics; the system-based approach and the sce-nario-based approach. These two ways of performing physical test could also be comple-mented with document-based reviews. Each strategy for physical test was concluded to have advantages and disadvantages.

• The scenario-based approach is defined in ASTE as development of test methods for

testing the performance of a vehicle in traffic scenarios, extracted from real accident data, where the tests are independent of specific systems that the vehicle is equipped with. The first step in this approach is to categorize relevant accidents. Based on acci-dent statistics available, assumptions are made on the most important traffic scenarios to test and the characteristics of these scenarios. The tests aim at being general and addressing the performance of the complete vehicle rather then being specifically adapted for a certain type of system. Thus, the performance is addressed with the ve-hicle as a “black-box”, where several different systems could contribute separately or in combination.

• The system-based approach is defined in ASTE as development of test methods,

adapted to certain systems or system cluster, starting from the systems and the tech-nology they are based on. Based on the system descriptions relevant traffic scenarios are searched among the accident statistics available, where the current systems are assumed to have an impact. Assumptions are thus made in what traffic scenarios these systems are useful. For each system that is considered, a number of relevant traffic scenarios will be suggested for testing the performance of the vehicle equipped with the safety function.

For both approaches, real world accident data is of great importance for deriving relevant traffic scenarios for testing a vehicle equipped with a safety function. The main difference is the way of categorizing the accident data and the way of considering the systems installed in the vehicle. Traffic scenarios can be either general; not addressing a certain system in par-ticular (scenario-based approach) or being specified for a certain system (system-based ap-proach). A further discussion of the two approaches as presented in ASTE is provided in An-nex 7.1.2 Evaluation methodology.

Deliverable D1.1


In the ASTE study the scenario based approach was proposed for a future performance test-ing program. A high-level test methodology starting from analysis of accident data was pro-posed. Examples of test cases were provided, that takes into account the important dimen-sions of a test scenario; attributes on driver state, vehicle and environment parameters. A proposal on how to break down a relevant accident to a traffic scenario for performing a test is provided in Annex 7.1.2 Evaluation methodology.

2.2.2.2 PReVAL

This project was performed as a subproject of the PReVENT Integrated Project (IP) of the 6th Framework Programme and aimed at assessing the safety impact of the functions developed within PReVENT and also to develop a general framework for evaluation and assessment of preventive safety functions. A best practice in evaluation was defined based on experience from within PReVENT1 and other projects such as AIDE and APROSYS.

For human factors evaluation the following dimensions were addressed

• Time frame of test; short term testing vs. long term

• Intended effects and unintended effects

• Level of intervention of the function and on what action level the system supports the driver (operational, tactical or strategical, levels proposed by MICHON) [Michon85].

A concept introduced in PReVAL was situational control referring to the degree of control that a driver-vehicle system has in specific traffic situation. With this concept; the purpose of a preventive safety system can be understood as an attempt to increase situational control. In validation, where both technical performance and human factors performance are impor-tant parts, the aim is to collect data to quantify the system effects, and to see whether situ-ational control has been changed. Fig. 2-9 shows how technical performance testing and human factors testing are connected to situational control. According to this figure, situational control is the concept used for the overall effects the function has on the vehicle and the driver, where the technical performance is the input, as well as the driver’s acceptance and usability (part of human factors performance).

1 The PReVENT subprojects, the Response project and Converge

Deliverable D1.1


Fig. 2-9: The technical performance of a safety system and the human factors related is-sues induced, together constitute an assembled impact on the situation which can be summarized as situational control.

The methodology used for evaluation of technical performance and human factors is pre-sented in Annex 7.1.2 Evaluation methodology. A final report will be delivered in PReVAL, with a framework integrating the technical and human factors evaluation, which is currently not yet public.

2.2.2.3 AIDE

This IP project concerns methods for assessment of IVIS and assessment of integrated HMIs for different IVIS applications. However, the project also addresses methods applicable for ADAS evaluation. In the project methods for evaluating human factor related issues like ac-ceptance, usability and workload are suggested, which is applicable for evaluation of both IVIS and ADAS. Some of the methods presented and discussed in AIDE are surveyed in An-nex 7.1.2 Evaluation methodology.

The European Statement of Principles (ESoP) handle in-vehicle information and commu-

nication systems intended for use by the driver while the vehicle is in motion e.g. navigation systems, telephones and traffic information. They are not specifically intended to apply to Advanced Driver Assistance Systems (ADAS) such as adaptive cruise control and collision mitigation systems. Even if ADAS require additional considerations in terms of Human Ma-chine Interaction, in comparison to in-vehicle information systems, these principles might provide an important basis when developing corresponding methods for ADAS.

Deliverable D1.1


2.2.2.4 APROSYS

2.2.2.4.1 APROSYS Pre-crash System Test Methodology

In order to achieve the next significant step in traffic safety, new technologies must be intro-duced into the car.

Two novel technologies have been applied for the first time in an automotive application:

• A side-impact detection system using stereo video and radar sensors.

• A Shape-Memory-Alloy based structural actuator.

As a technological showcase these technologies have been combined in an integrated side-impact protection system. The system was derived from accident statistics, as was the test programme. The latter has proved finally the effectiveness of the two technologies.

Fig. 2-10: APROSYS Pre-Crash systems Generic Test methodology

2.2.2.4.2 Assessment methods for a side pre-crash protection system

Within APROSYS SP1.3 an evaluation methodology for advanced safety systems is being developed. This generic method (as shown above) is suitable to assess the complete safety system. The system specific test conditions and assessment criteria are defined using rele-vant accident and traffic scenarios. The essential evaluation of the technical performance, which is the main part of the method, is split in three steps of pre-crash performance, crash

Deliverable D1.1


performance and driver-in-the-loop performance. This methodology is applied on the SP6 pre-crash safety system.

Deliverable D1.1


3 Scope of eVALUE

The scope of eVALUE is automotive preventive safety systems. These systems inform, warn or support the driver in his actions e. g. by reducing system reaction time or interact autono-mously with the vehicle guidance. Thus, all systems are considered as long as they help to avoid an accident or mitigate its consequences. Pre-crash systems, which help to mitigate accident injuries (e.g. belt pre-tensioners, pre-fired airbags or whiplash protection) are not addressed by eVALUE. Systems, which become active in the post-crash phase (e.g. e-call) are also not considered to be in the scope of eVALUE.

The preventive safety systems can be classified into four domains:

• Longitudinal assistance

• Lateral assistance

• Yaw/stability assistance

• Additional assistance

Fig. 3-1 shows the proposed roadmap for safety relevant ICT-based systems in the four do-mains.

Longitudinal Assistance Domain

Lateral Assistance Domain

Yaw/Stability Assistance Domain

Additional Assistance Domain

today

short-term- 5 years

medium-term5 - 10 years

long-term> 10 years

ACC

ACC Stop&Go

LDW

ESC

ABS

Traction Control

Obstacle and Collision Warning

Long. Collision Avoidance

Intersection Assistant

Lane Change Assistant

Lane KeepingAssistant

Merging Assistant

Overtaking Assistant

Left Turning Assistant

Curve Speed Assistant

Blind Spot MonitoringNight

VisionAdaptive

Headlights

Collision Mitigation by Braking

Warning Traffic Jam End

BrakeAssistant

Speed Alert

Driver Drowsiness Warning

Active Font SteeringTorque

Vectoring

IVDC

Active Rear Steering

Damper Control


Active SpringSystems

Adaptive BrakeAssistant

Lane Change Warning

Roll Stability Control

Fig. 3-1: Roadmap –ICT-based systems in four assistance domains

Deliverable D1.1


The scope of eVALUE includes all four domains. When designing test methods within eVALUE, they will be applied on a selected number of systems, based on the presented roadmap of ICT-based safety systems. The selection process considers:

• All four domains: System should address at least one domain.

• Market availability (time horizon: today). Systems which are available today or within the project development or duration.

• Market penetration rate: Vehicles >50.000 may incorporate the system

The testing and evaluation methods to be developed in eVALUE will cover systems of all four domains. In order to apply and validate the developed methodology, systems need to be available as prototypes or already on the market today. Furthermore a high market penetra-tion range will provide systems with equal functionality from different manufacturers.

Based on this statement the following systems are considered:

• System Cluster 1 (longitudinal assistance):

o ACC

o Forward Collision Warning

o Collision Mitigation, by braking.

• System Cluster 2 (lateral assistance):

o Blind Spot Detection

o Lane Departure Warning

o Lane Keeping Assistant

• System Cluster 3 (yaw/stability assistance):

o ABS

o ESC

• System Cluster 4 (additional assistance):

o Not defined at this stage (ICT-based systems becoming available during pro-ject duration)

A general description of the function of these systems is the focus of the next subchapters. A more detailed description per system can be found in Annex 7.2 Scope of eVALUE (page 109).

Deliverable D1.1


3.1 CLUSTER 1: Longitudinal assistance domain

3.1.1 Adaptive Cruise Control (ACC)

General data on ACC

Name of the system Adaptive Cruise Control (ACC)

General function Stand alone system for taking over task of longitudinal ve-

hicle control

ACC: velocity rangebetween 30 and 200 km/h ACC S&G: velocity range between 0 and 200 km/h

■ Passenger cars

■ Trucks

Type of vehicles

■ Buses Related documents (for further usage in eVALUE)

ISO 15622:2002

SAE J2399

FMCSA-MCRR-05-007

Major technologies • Distance sensor for environmental detection of targets ahead up to 200m

• ECU, which processes sensor signals, time gap and desired velocity and calculates necessary ac-

celeration

• Actuators to apply brake force or acceleration of the vehicle

ACCSUBJECT, speed

SUBJECT to TARGET, relative speed

SUBJECT to TARGET, distance

SUPPORT, braking

INPUTS OUTPUTS

AUTONOMOUS INTERVENTION, acceleration and braking

WARN, on precautious actions

SUBJECT, vehicle dynamics

For further details on this system, refer to Adaptive Cruise Control (ACC), page 109.

3.1.2 Forward Collision Warning (FCW)

General data on FCW

Name of the system Forward Collision Warning (FCW)

General function Stand alone system that provides alerts to assist drivers in

avoiding or reducing the severity of crashes by striking the rear-end of another vehicle.

■ Passenger cars Type of vehicles

■ Trucks

Deliverable D1.1



ISO 15623:2002 SAE J2400

FMCSA-MCRR-05-007

FCW WARN, on precautious actions

INPUTS OUTPUTS

SUBJECT, speed




For further details on this system, refer to Forward Collision Warning (FCW), page 113.

3.1.3 Collision Mitigation (CM)

General data on CM

Name of the system Collision Mitigation (CM) by braking.

General function Stand alone driver assistance system that helps the driver

in mitigating imminent frontal collision by giving brake

support, i.e. amplifying driver initiated braking, pre-

charging the brake system (i.e. very light braking, not no-ticeable to the driver) or by autonomous brake interven-

tion. The objective of the system is to reduce the collision

speed when a collision is imminent. Ideally this means re-

ducing the impact speed to zero.

■ Passenger cars (today)

■ Trucks (currently not on the market)

Type of vehicles

■ Buses (currently not on the market) Related documents (for further usage in eVALUE)

N/A

CMSUBJECT, vehicle dynamics

SUBJECT, environment description

INPUTS OUTPUTS

AUTONOMOUS INTERVENTION, braking

Deliverable D1.1


For further details on this system, refer to Collision Mitigation (CM) by braking, page 117.

3.2 CLUSTER 2: Lateral Assistance Domain

3.2.1 Blind Spot Detection (BSD)

General data on BSD

Name of the system Blind Spot Detection (BSD)

General function Stand alone driver assistance system that helps to avoid

side swipe collisions in lane change situations. The sys-tem issues a warning to the driver when an object is de-

tected in the blind spot area. Normally the warning signal

consists of a red warning light close to the left and right

hand rear-view mirrors.

■ Passenger cars

■ Trucks

Type of vehicles


ISO/DIS 17387

BSD

SUBJECT, lane change detection

SUBJECT’s BLIND SPOT, vehicle detection WARN, on precautious actions

INPUTS OUTPUTS


For further details on this system, refer to Blind Spot Detection (BSD), page 120.

3.2.2 Lane Departure Warning (LDW)

General data on LDW

Name of the system Lane Departure Warning (LDW)

General function Stand alone system that supports the driver to stay in the

lane, by issuing a warning to the driver in case of an unin-tended lane change.

■ Passenger cars

■ Trucks

Type of vehicles


ISO 17361:2007

FMCSA-MCRR-05-005

Deliverable D1.1


LDW


SUBJECT, upcoming lane marks detection WARN, on precautious actions


INPUTS OUTPUTS

For further details on this system, refer to Lane Departure Warning (LDW), page 123.

3.2.3 Lane Keeping Assistant (LKA)

General data on LKA

Name of the system Lane Keeping Assistant (LKA)

General function Stand alone system that supports the driver to stay in the

lane, by enhancing the Lane Departure Warning system with actuators which

• either applies a steering wheel vibration, or

• applies a torque on the steering system into the direc-tion of the lane centre. This torque is not strong

enough to steer back, but it provides feedback to the

driver in which direction he should steer, or

• autonomously steers back in the direction of the lane

centre.

■ Passenger cars

■ Trucks

Type of vehicles

■ Busses

Related documents (for further usage in eVALUE)

N/A

LKA


SUBJECT, upcoming lane marks detection


SUPPORT, steeringSUBJECT, vehicle dynamics

INPUTS OUTPUTS

For further details on this system, refer to Lane Keeping Assistant (LKA), page 127.

Deliverable D1.1


3.3 CLUSTER 3: Yaw / Stability Assistance Domain

3.3.1 Antilock Brake System (ABS)

General data on ABS

Name of the system Antilock Brake System (ABS)

General function Stand alone system that controls the brake wheel slips

and prevents locking of the individual wheels while brak-

ing. The prevention of blocking wheels assures that the vehicle remains steerable and improves the driving stabil-

ity of vehicles in specific braking situations.

■ Passenger cars

■ Trucks

Type of vehicles


ISO 21994:2007

ISO 6597:2005 ISO 7975:2006

SAE J2536

ABS

INPUTS OUTPUTS

AUTONOMOUS INTERVENTION,

individual wheel braking

SUBJECT, individual wheel slip detection


For further details on this system, refer to Antilock Brake System (ABS), page 130.

3.3.2 Electronic Stability Control (ESC)

General data on ESC

Name of the system Electronic Stability Control (ESC)

General function Stand alone system that helps to stabilize the yaw behav-iour of a vehicle in critical driving situations by using con-

trolled braking and engine interventions.

■ Passenger cars

■ Trucks

Type of vehicles


ISO 3888-1:1999

ISO 3888-2:2002 ISO 7401:2003

Deliverable D1.1


FMVSS No. 126

GRRF-63-26

ESC

INPUTS OUTPUTS


brakingSUBJECT, stability loss detection


Engine / transmission


For further details on this system, refer to Electronic Stability Control (ESC), page 133.

Deliverable D1.1


4 CONCLUSIONS

The goal of eVALUE is the development of testing and evaluation methods for ICT-based safety systems. As a baseline, the technologies and components currently used in ICT-based safety systems as well as existing testing and evaluation methods have been col-lected.

An overview of the different systems that are currently available or under development, with aim to increase vehicle safety has been given. Besides the systems in general, the involved sensors and actuators as well as the ECUs are briefly described and summarised in the pre-vious sections. Detailed information is given in the Annex of this report.

While test methods for validation of ICT-based safety systems, with drivers in the loop, are scarce, testing and evaluation methods for testing of a specific system, against requirement specifications exist to some extent. These methods are officially, mainly given by means of standards. Some research projects have already been carried out in the field of testing and evaluation. Their focus was mainly on strategies and methodologies for testing active safety systems. Hence, to assess whether a system works for its intended purpose or not, driver-in-the-loop testing2 is required. For an ADAS system both HMI (graphics, layout, information to driver) and decision algorithms e.g. warning and automation strategies influence the interac-tion with the system.

Different means to evaluate ADAS systems could be used through out the development phase. For eVALUE, focus is on systems on a late prototype stage or systems already on the market. A challenge for eVALUE is to bring forth, collect and put together test methods that create a valid test battery able to capture the complex task of driving.

With the given input, some first conclusions are drawn for the eVALUE project. The systems to be regarded during the project are classified into four clusters. These domains are based on the driving path of the subject vehicle: longitudinal, lateral and yaw/stability. The fourth domain remains open for upcoming systems and will be defined at a later stage, but not after project month 18. This ensures to keep enough time for considering the systems of the fourth cluster within the testing methods.

A further classification of the systems has been done based on availability and market pene-tration. Based on these factors, the consortium decided to consider the following 8 ICT-based safety systems within the three clusters: Adaptive Cruise Control (ACC), Forward Col-lision Warning (FCW) and Collision Mitigation by braking (CM), in the longitudinal assistance domain; Blind Spot Detection (BSD), Lane Departure Warning (LDW) and Lane Keeping As-sistant (LKA), in the lateral assistance domain; and finally, Antilock Brake System (ABS) and Electronic Stability Control (ESC), in the yaw/stability assistance domain.

2 Driver-in-the-loop testing, meaning that the driver takes an active part in the iterative development process.

Deliverable D1.1


As a next step to this deliverable and according to the work plan, concepts for design re-views, physical vehicle testing as well as laboratory testing will be analysed. The result will be an in-depth understanding of the possibilities to investigate and evaluate the 8 active safety systems within the first phase of the project. The different concepts will then support the decision about the development of the testing and evaluation methods that are able to point out the safety benefit of those systems in the most representative way.

Taking into account the performance of the systems the safety impact of active safety in general can be estimated. This enables not only the project, but also all stakeholders to demonstrate the value of ICT-based safety systems and thus increase their acceptance. Eventually, increased acceptance and following market penetration will lead to a reduction of road fatalities, directly contributing to the target of the European Commission on this topic.

Deliverable D1.1


5 GLOSSARY AND ACRONYMS

Driver in the loop Driver-in-the-loop testing, meaning that the driver takes an active part in the iterative development process.

Driver model A model that completely specifies the drivers behaviour in one test case, with regard to vehicle inputs that may effect the test. Such in-puts are steering wheel angle, throttle position, brake pedal position, clutch, gear, turn signals, dummy driver gaze direction or eye closure.

Driver Support Refers to the three levels of driving support defined by MICHON : strategical, tactical, operational [Michon85]

False alarm An alarm where the (driver support) system does not work according to it's specifications/does not fulfil the system requirements.

Function Implementation of a set of rules to achieve a specified goal. Unambi-guously defined partial behaviour of one or more electronic control units

Function output Describes the resulting output of the system/ function in terms of in-formation: A continuous information or a warning is issued to the driver via different channels: optical/ acoustical/ haptical support: am-plify the driver action to a higher level. No autonomous action is taken by the system/ function, but the system ""prepares itself"" to reduce e. g. system reaction time. No action like steering or braking is taken without an initiation by the driver action: the system/ function acts autonomously without any action of the driver

Nuisance alarm An alarm that is perceived by the driver as a nuisance, this includes both false alarms and alarm where the system work as intended.

Rear-end collision A collision where the host vehicle's front-end strikes a target vehicle's rear-end

Subject vehicle Vehicle equipped with the systems under evaluation System Combination of hardware and software enabling one or more func-

tions Set of elements (at least sensor, controller, and actuator) in rela-tion with each other according to design. An element of a system can be another system at the same time. Then, it is called subsystem which can be a controlling or controlled system or which can contain hardware, software and manual operations.

Target vehicle Vehicle detected by the systems of the subject vehicle. Validation Describes the process of evaluating the system impact e. g. on safety.

That is, validation checks and tests whether the system "does what it was designed for", e. g. increase traffic safety by increasing headway, by avoiding impacts and so on. Driver-in-the-loop testing is required.

Verification Describes the test of a system/ function against its requirements, that is, whether it fulfils its requirements.

ACRONYMS:

Deliverable D1.1


ABS Antilock Brake System IR Infrared ACC Adaptive Cruise Control ISO International Standardisation organisation ACIM Alternating Current Induction Motor IVBSS Integrated Vehicle-Based Safety System ADAS Advanced Driver Assistance Systems IVDC Interactive Vehicle Dynamic Control AFS Adaptive Front-Lighting System IVIS Integrated Vehicular Information System AMR Anisotropic Magnetoresistance LCDAS Lane Change Decision Aid System BOS Beginning of Steer LCW Lane Change Warning BSD Blind Spot Detection LDW Lane Departure Warning BSM Blind Spot Monitoring LDWS Lane Departure Warning System CAN Controller Area Network LED Light Emitting Diode CCD Charge Coupled Device LIDAR Light Detection and Ranging CM Collision Mitigation LIN Local Interconnect Network CMbB Collision Mitigation by Braking LKA Lane Keeping Assistance CMBS Collision Mitigation Braking System LRR Long Range Radar CMOS Complementary Metal Oxide Semiconduc-

tor LSF Low Speed Following

CPU Central Processing Unit MCU Microprocessor Control Unit CWS Collision Warning System MMW Milimeter Wave DC Diagnostic Coverage MOST Media Oriented System Transfer DC Direct Current NHTSA National Highway Traffic Safety Administration DTI Diagnostic Test Interval NHTSA National Highway Traffic Safety Administration E/E/PES Electrical/Electronic/Programmable Elec-

tronic Safety NIR Near Infrared

ECU Electrical Control Unit OEM Original Equipment Manufacturer EM Electromagnetic PCB Printed Circuit Board EMI Electromagnetic Interference PDT Peripheral Detection Task EPS Electric Power Steering PFH Probability of dangerous Failures per Hour ESC Electronic Stability Control Radar Radio Detection and Ranging ESD Electrostatic Discharge RBD Reliability Block Diagrams EUC Equipment Under Control RCS Radar Cross Section EWB Electronic Wedge Brake RCS Radar Cross Section FCW Forward Collision Warning SAE Society of Automotive Engineers FIR Far Infrared SAGAT Situation Awareness Global Assessment

Technique FMCW Frequency Modulated Continuous Wave SART Structured Analysis for Real Time Systems FMEA Failure Modes and Effects Analysis SBW Steer by Wire FMVSS Federal Motor Vehicle Safety Standard SFF Safe Failure Fraction FOV Field of View SFF Safe Failure Fraction FTA Fault Tree Analysis SRR Short Range Radar GES General Estimates System SV Subject Vehicle GPIO General Purpose Input/Output SWA Steering Wheel Angle GPS Global Positioning System TC Traction Control GVWR Gross Vehicle Weight Ratio TLC Time to Line Crossing HFT Hardware Fault Tolerance UDF Uncoupled Double Filter HMI Human Machine Interface V2I Vehicle to Infrastructure HUD Head-Up Display V2V Vehicle to Vehicle IC Integrate Circuit VDM Visual Demand Measurement ICT Information and Communication Tech-

nologies

IEC International Electrotechnical Commission

Deliverable D1.1


6 LITERATURE

[15037-1] International standard ISO 15037-1:2006 Road vehicles – Vehicle dynamics test methods – Part 1: General conditions for passenger cars International Standardisation Organisation, 2006

[15037-2] International standard ISO 15037-2:2002 Road vehicles – Vehicle dynamics test methods – Part 2: General conditions for heavy vehicles and buses International Standardisation Organisation, 2002

[15622] International standard ISO 15622:2002 Transport information and control systems – Adaptive Cruise Control Systems Performance requirements and test procedures International Standardisation Organisation, 2002

[15623] International standard ISO 15623:2002 Transport information and control systems – Forward vehicle collision warning systems –Performance requirements and test procedures International Standardisation Organisation, 2002

[17361] International standard ISO 17361:2007 Intelligent transport systems – Lane departure warning systems – Perform-ance requirements and test procedures International Standardisation Organisation, 2007

[21994] International standard ISO 21994:2007 Passenger cars – Stopping distance at straight-line braking with ABS – Open-loop test method International Standardisation Organisation, 2007

[26262] ISO – International Organization for Standardization ISO/WD 26262 “Road vehicles – Functional safety” 2007

[3888-1] International standard ISO 3888-1:1999 Passenger cars – Test track for a severe lane-change manoeuvre – Part 1: Double lane change International Standardisation Organisation, 1999

[3888-2] International standard ISO 3888-2:2002 Passenger cars – Test track for a severe lane-change manoeuvre – Part 2: Obstacle avoidance International Standardisation Organisation, 2002

Deliverable D1.1


[60812] International standard IEC 60812 Analysis techniques for dependability – Procedure for failure mode and effects analysis (FMEA) IEC – International Electrotechnical Commission, July, 1985

[61025] International standard IEC 61025 Fault tree analysis (FTA) IEC – International Electrotechnical Commission, January, 2007

[61078] International standard IEC 61078 Analysis techniques for dependability – Reliability block diagram and Boolean methods IEC – International Electrotechnical Commission, January, 2006

[61165] International standard IEC 61165 Application of Markov techniques IEC – International Electrotechnical Commission, June, 2006

[61508] International standard EN-IEC 61508:2002 Functional safety of electrical/electronic/programmable electronic safety-related systems IEC – International Electrotechnical Commission, 2002

[62380] Technical Report IEC TR 62380 Reliability data handbook – Universal model for reliability prediction of elec-tronic components, PCBs and equipment IEC – International Electrotechnical Commission, August, 2004

[6597] International standard ISO 6597:2005 Road vehicles – Hydraulic braking systems, including those with electronic control functions, for motor vehicles – Test procedures International Standardisation Organisation, 2005

[7401] International standard ISO 7401:2003 Road vehicles – Lateral transient response test methods – Open-loop test methods International Standardisation Organisation, 2003

[7975] International standard ISO 7975:2006 Passenger cars – Braking in a turn – Open loop test methods International Standardisation Organisation, 2006

[810757] Development of Crash Imminent Test Scenarios for Integrated Vehicle-Based Safety Systems (IVBSS)

Deliverable D1.1


Publication DOT 810 757 U.S. Department of Transportation, National Highway Traffic Safety Admini-stration April 2007 Download at http://www.itsa.org/itsa/files/pdf/IVBSS%20Crash%20Imminent%20Test%20Scenario%20Report%20-%20DOT%20HS%20810%20757.pdf

[810842] Integrated Vehicle-Based Safety Systems (IVBSS) First Annual Report

Publication DOT 810 842 U.S. Department of Transportation, National Highway Traffic Safety Admini-stration October 2007 Download at http://www.its.dot.gov/ivbss/docs/IVBSS_FirstAnnualReport_FINAL_October2007.pdf

[AIDE] Johansson, E., et al.

AIDE D 2.2.1 – Review of existing techniques and metrics for IVIS and ADAS

assessment. 11 November 2004

[ASTE07] Jacobson, J., et al.

ASTE project final report D3 - Feasibility Study for the Setting-up of a Per-

formance testing Programme for ICT-based Safety systems for Road Trans-

port

DG INFSO, unit ICT for Transport, 20 September 2007

[Bro96] Brooke, J.

SUS: a "quick and dirty" usability scale

P. W. Jordan, B. Thomas, B. A. Weerdmeester & A. L. McClelland (eds.) Us-

ability Evaluation in Industry. London: Taylor and Francis

[DoD217] DoD MIL HDBK 217F “Military Handbook – Reliability prediction of electronic equipment” Department of Defence , January, 1990

[FMC05a] Houser, A., Pierowicz, J., and Fuglewicz, D.

Concept of Operations and Voluntary Operational Requirements for Lane De-

parture

Warning Systems (LDWS) On-Board Commercial Motor Vehicles.

FMCSA-MCRR-05-005, Federal Motor Carrier Safety Administration, 2005

Deliverable D1.1


[FMC05b] Houser, A., Pierowicz, J., and McClellan, R.

Concept of Operations and Voluntary Operational Requirements for Forward

Collision Warning Systems (CWS) and Adaptive Cruise Control (ACC) Sys-

tems On-Board Commercial Motor Vehicles.

FMCSA-MCRR-05-007, Federal Motor Carrier Safety Administration, 2005

[FMVSS126] FMVSS No. 126 Laboratory Test Procedure for Electronic Stability Control Systems U.S. Department of Transportation National Highway Traffic Safety Administration April, 2007 Download at http://www.nhtsa.dot.gov/staticfiles/DOT/NHTSA/Vehicle%20Safety/Test%20Procedur

es/Associated%20Files/TP126-00.pdf

[GTR-ERC] Integrated Development of the draft global technical regulation on electronic stability control systems Draft global technical regulation on electronic stability control systems Economic Commission for Europe Working party on Brakes and Running Gear, Sixty-second session 25-28 September 2007 Download at http://www.unece.org/trans/doc/2008/wp29grrf/ECE-TRANS-WP29-GRRF-63-

inf26e.pdf

[J2399] SAE standard J2399 Adaptive Cruise Control (Acc) Operating Characteristics and User Interface

Society of Automotive Engineers, 2003-12

[J2400] SAE standard J2400 Human Factors in Forward Collision Warning Systems: Operating Characteris-tics and User Interface Requirements Society of Automotive Engineers, 2003-08

[J2536] SAE standard J2536 Anti-lock brake system (ABS) road test evaluation procedure for trucks, truck-tractors and buses Society of Automotive Engineers, 2004-01

[Michon85] A critical view of driver behavioural models. What do we know, what should we do? In L. Evans & R. Schwing (Eds.) Human behaviour and traffic sfaety (pp.485-525). New York:Plenum press.

Deliverable D1.1


[Pop07] M. Poppel and M. Staeblein “Microcontrollers promise to improve automotive electronic control units” Automotive Design Line (http://www.automotivedesignline.com/) October 2nd, 2007

[PReVAL1] PReVAL Project Deliverable D16.1, Review of validation procedures for preventive and active safety functions 11.6.2007

[PReVAL2] PReVAL Project deliverable D16.3- Proposal of procedures for assessment of preven-tive and active safety functions. 21/12 2007 PR-16000-SPD-070831-v110-D16_3.pdf

[Van97] Van der Laan, J.D., Heino, A., & De Waard, D. A simple procedure for the assessment of acceptance of advanced transport telematics. Transportation Research - Part C: Emerging Technologies, 5, 1-10, 1997.

Deliverable D1.1


7 ANNEX

7.1 State of the art

7.1.1 Detailed description of ICT based safety systems

In the following sections systems of the four clusters of driver assistance are presented and briefly described in order to provide a common understanding of these systems.

The time horizon describes the time, in which the system will be integrated into series vehicle production, independent of the vehicle class.

7.1.1.1 Cluster 1: Longitudinal Assistance Domain

System name: Adaptive Cruise Con-trol (ACC)

Time horizon: Today

Automatically adjusts a car’s speed to maintain a safe following distance. It uses forward-looking distance sensors to detect the speed and distance of the vehicle ahead of it up to 200 meters. ACC is similar to conventional cruise control in that it maintains the vehicle’s pre-set speed. However, unlike conventional cruise control, this new system can automati-cally adjust speed by braking or accelerating in order to maintain a proper distance between vehicles in the same lane. Standard ACC systems are usually not operational below a cer-tain speed threshold. The operational speed is between 30 and 200 km/h for common sys-tems, which are available on the market today.

System name: ACC Stop & Go (Traffic Jam Assistant)

Time horizon: Today

It adds a traffic jam assistant Stop & Go functionality to the Adaptive Cruise Control (ACC) system. Using the ACC long range radar, the Traffic Jam Assistant allows the ACC vehicle to follow a target to stop and upon driver command follow that target in traffic jam situations. It uses additional short range radars to cover a wider field in front of the ACC vehicle. ACC Stop & Go permits the ACC vehicle to automatically follow its target in a traffic jam situation.

System name: Brake Assist System Time horizon: Today

The system supports the driver in an emergency braking situation in case the driver does not apply the brake pedal hard enough on his own. A sensor recognizes the attempt to per-form an emergency braking and transmits the signal to the hydraulic booster calling for full brake pressure. The system adjusts the amount of brake power applied to the wheels during emergency braking.

Deliverable D1.1


System name: Collision Mitigation Braking System (CMBS)

Time horizon: Today

It helps to reduce injuries in a frontal impact. Distance and speed of potential obstacles in front of the subject vehicle are constantly evaluated by means of one or more proximity sen-sors, e.g. radar, lidar, vision and IR. If the system/ function estimates as high probability of a collision, acoustic or visual warnings are issued to the driver. If the driver does not take ac-tion to reduce speed, the CMBS will provide the driver with a warning and begin warm brak-ing. If the system evaluates an unavoidable frontal collision, the front seat belts tensioned and emergency braking is automatically applied to reduce the impact velocity and collision force.

System name: Adaptive Brake Assis-tant

Time horizon: Today

Distance sensors at the front of the car measure both the distance to the vehicle ahead and its current speed. If the vehicle ahead stops suddenly, or if an obstacle appears in the lane ahead, the Adaptive Brake Assistant calculates whether emergency braking must be ap-plied, and the necessary amount of brake pressure. Having calculated the optimum braking power, the system activates the brakes only after the driver has applied the brake pedal and not by itself. It also gives the driver warning signals: depending on the model, visual warn-ings are provided on the dashboard or on the Head-up display.

System name: Obstacle and Collision Warning

Time horizon: Today

Combining long and short range radars with a video camera, the system identifies potential collision targets in its field of view and informs driver through audible or visual alerts and can also pre-fill the braking system to provide full brake force as soon as the driver applies the brakes. The system warns the driver, but does not interact autonomously.

System name: Curve Speed Assistant Time horizon: Short-term (<5 years)

While the driver is about to enter the curve, the system calculates an appropriate speed for the curve. The main parameters for speed estimation are the curve radius, the change of di-rection and the class of the road. The estimated speed is compared with the current vehicle speed. If the speed of travel is too high a warning is issued.

System name: Speed Alert Time horizon: Today

Speed Alert is a system of in-vehicle speed limitation. It requires that the vehicle is accu-

Deliverable D1.1


rately located and provided with information about the speed limit on the road. This can be achieved through a combination of Global Positioning System (GPS) and a digital road map. In case the driver exceeds the posted speed limit, he receives a warning by means of acoustic, visual of haptic HMI. In a second stage Speed Alert takes over and slows the vehi-cle until it’s at or below the legal speed limit.

System name: Longitudinal Collision Avoidance

Time horizon: Long-term (>10 years)

A sensor installed at the front or back end of a vehicle constantly scans the road for vehicles and obstacles. When one is found, the system determines whether the vehicle is in immi-nent danger of crashing, and if so, a warning is issued, or a collision avoidance manoeuvre is undertaken, depending on the system.

If a car in front suddenly brakes or is stationary, it automatically pre-charges the brakes to help the driver avoid an accident by slowing down in time, or steering away from a potential collision. However if a collision is imminent, the system activates the car’s brakes automati-cally.

System name: Warning Traffic Jam End

Time horizon: Long-term (>10 years)

The system warns the driver in case the vehicle is approaching the end of a traffic jam. Es-pecially at night time, in foggy weather conditions and in case the driver is distracted the warning supports the driver in the decision process to reduce the vehicle velocity. The warn-ing is communicated via vehicle-to-vehicle communication.

7.1.1.2 Cluster 2: Lateral Assistance Domain

System name: Blind Spot Monitoring Time horizon: Today

This system monitors the rear blind spots on both sides of the vehicle where the driver’s vis-ual field using for instance, radars located behind the rear bumper or cameras located in the mirrors and an image processing system. When a vehicle is present in either blind spot, the driver is informed about this potential hazard optically.

System name: Lane Departure Warn-ing

Time horizon: Today

The system supports the driver to stay in his lane. For that purpose the position of the vehi-cle between the lane markings is evaluated and TLC (Time to line crossing) is estimated. In

Deliverable D1.1


case the system detects an unintended lane change (e. g. TLC falls below a certain thresh-old and the turning indicators are not engaged) a warning is issued to the driver. This warn-ing is either given acoustically, often activating the “right” speaker of the sound system, or haptic by means of vibrations in the steering wheel or the driver seat.

System name: Lane Change Assistant Time horizon: Medium-term (5-10 years)

This function is a combination of longitudinal vehicle guidance and steering control, there-fore ACC and lane keeping system, supports the driver when intentionally changing lanes by alerting him or her in the case of danger and/or intervening in driving dynamics.

System name: Lane Change Warning Time horizon: Short-term (<5 years)

Extended version of the blind spot detection that warns the driver when he/she is about to change lane in a potentially dangerous situation, when a vehicle is present or fast approach-ing from behind in the adjacent lane. The perception system monitors the areas in the blind spot as well as fast-approaching vehicles at a range of about 50 meters to the rear of the car. If the system detects that the driver has activated the turning indicators and identifies another vehicle approaching, it warns the driver (visually, acoustically, haptically) before changing the lane.

System name: Lane Keeping Assistant Time horizon: Today

Active assistance by an intervention in the steering. Just like LDW, the assistant measures the vehicle position relative to the lane, but offers active support in keeping the vehicle to the lane. However, the driver always retains the driving initiative, meaning that although he can feel the recommended steering reaction as a gentle movement of the steering wheel, his own decision takes priority at all times.

System name: Intersection Assistant Time horizon: Long-term (>10 years)

Advance driving assistance based on cooperative manoeuvres. Information coming from the infrastructure (I2V) in order to assist the driver when approaching an intersection. This ap-proach can also be achieved by vehicle-to-vehicle (V2V) communication.

System name: Left Turning Assistant Time horizon: Long-term (>10 years)

The assistance is based on cooperative manoeuvres and digital maps. Information coming from the infrastructure (I2V) and vehicle-to-vehicle (V2V) communication will assist the driver when turning left. The system detects object next to the left side of the vehicle and

Deliverable D1.1


warns the driver in case it is not possible to perform the turning manoeuvre. Weak traffic participants such as pedestrians and cyclists are also detected by the system.

System name: Merging Assistant Time horizon: Long-term (>10 years)

Advance driving assistance based on cooperative manoeuvres and digital maps. Information coming from the infrastructure (I2V) and vehicle-to-vehicle (V2V) communication will assist the driver when merging into a motorway.

System name: Overtaking Assistant Time horizon: Long-term (>10 years)

Advance driving assistance based on cooperative manoeuvres and digital maps. Information coming from the infrastructure (I2V) and vehicle-to-vehicle (V2V) communication will assist the driver when overtaking.

7.1.1.3 Cluster 3 Yaw/Stability Assistance Domain

System name: ABS Time horizon: Today

An anti-lock brake system (ABS) is a system which prevents the wheels from locking while braking. An anti-lock brake system allows the driver to maintain steering control under hard braking by preventing a skid and allowing the wheel to continue to forward roll and create lateral control, as directed by driver steering inputs.

System name: Active Front Steering Time horizon: Today

Steering system that allows an active stabilisations by active steering interventions (instead or in addition to the braking interventions of the ESC) as well as the programming of desired variable steering ratios.

System name: Active Rear Steering Time horizon: Short-term (<5 years)

Is an active low-angle rear wheel steering system, that helps to minimize over steer and un-der steer at all speeds, and on virtually all surfaces, even during normal driving, without slowing the vehicle. The system can also be used to improve the stability of the vehicle in critical situations.

Deliverable D1.1


System name: Electronic Stability con-trol (ESC)

Time horizon: Today

System that stabilizes the vehicle and prevent skidding under all driving conditions and situations within the physical limits by active brake intervention on one or more wheels and by intelligent engine torque management.

System name: Torque Vectoring Time horizon: Today

This system allows the transmission output torque to be dynamically and continuously varied between front and rear axles of a 4WD vehicle. New systems even provide a distribution of the driving torque between left and right side of the vehicle. So the function can be used to improve the handling and stability of a vehicle.

System name: Integrated Vehicle Dy-namics Control (IVDC)

Time horizon: Medium-term (5-10 years)

IVDC means an integrated controller/system including all the different active safety systems which influence yaw and stability behaviour of the vehicle. Today there are mainly co-existing systems, each with its own controller (e.g. ESC, AFS, damper control, torque vec-toring). Integrated controller aim to minimize negative interactions between the systems and to combine all systems to the best effect in a specific situation.

System name: Traction control (TC) Time horizon: Today

System designed to prevent loss of traction (and therefore the control of the vehicle) when excessive throttle or steering is applied by the driver.

7.1.1.4 Cluster 4: Additional Assistance Domain

System name: Adaptive Headlights Time horizon: Today

An adaptive headlight system automatically adapts the light distribution in order to provide the most suitable illumination. By means of the vehicle speed, steering angle, yaw rate and weather conditions a dynamic bending light function can be realized, which swivels in accor-dance to the vehicle motion data the whole headlights into the curve.

In combination with the vehicle speed, different light distributions to increase the visibility for

Deliverable D1.1


certain driving situations are developed. Besides the regular low and high beam light, a town, rural street, motorway and adverse weather light is realized. The situations are classi-fied according to the vehicle speed.

A further possibility to increase the visibility at night is driving with the high beam light. The high beam assist activates permanently the high beam and deactivates itself, if the light of oncoming vehicles and the rear lights of preceding vehicles are detected and if the street lighting is sufficient or driving at lower speed.

System name: Night Vision Time horizon: Today

Night Vision allows the driver to see well beyond the reach of the car's headlights. This technology helps drivers detect and avoid potentially dangerous situations. The system cre-ates an image of the surroundings based on heat: warm objects such as animals or pedes-trians appear as bright shapes.

System name: Driver Drowsiness Warning

Time horizon: Today

Driver drowsiness warning system keeps track of several indicators of driver alertness to act when the driver is becoming too tired to drive. By observing the driver throughout each trip, the computer develops a profile for each individual and uses that profile as a baseline for analysis of alertness. When the computer senses a significant deviation from the profile, it compares that deviation with known signs of tiredness and the trip length, time of day and driving style. If it thinks it is appropriate, it will warn the driver of his or her tiredness. The ob-servation is conducted by means of comparing vehicle data such as changes in the steering wheel angle throughout the driver and therefore detection of abnormal behaviour. In future systems the driver is monitored directly by image processing systems (monitoring of eyelid movements).

System name: Damper Control Time horizon: Short-term (<5 years)

EDC (electronic damper control), which constantly adjusts the suspension to environmental and vehicular conditions, and can also be set in three modes, comfort, normal and sport. The Systems are able to minimize roll and pitch motion of the vehicle body as well as wheel load variations (which means they provide a higher grip level)

System name: Active Wheel Load Dis-tribution

Time horizon: Medium-term (5-10 years)

Deliverable D1.1


System that uses active suspension elements (e.g. active roll bars, active springs and active dampers) to influence the distribution of the wheel loads. So the transferable forces between tire and road are also influenced. So the system is able to influence the handling of the vehi-cle as well as stability in critical situations.

System name: Active Spring Systems Time horizon: Medium-term (5-10 years)

Part of an active vehicle suspension, that allows a dynamic and real time adjustment of the elastic elements of the suspension, in order to adjust the car behaviour to the vehicle and road conditions

System name: Roll Stability Control system

Time horizon: Today

Roll stability control systems take corrective action, such as throttle control or braking, when sensors detect that a vehicle is in a potential rollover situation. The functionality combines different systems such as ESC, AFS, and active roll bar in order to mitigate roll over scenar-ios.

7.1.1.5 Sensor Technologies and Trends

7.1.1.5.1 RADAR

Radio Detection and Ranging (RADAR) is a technology that uses high-frequency electro-magnetic waves to measure distance and differences in velocity. ICT–based safety systems considered in eVALUE can use two types of radars: impulse and Frequency Modulated Con-tinuous Wave (FMCW) radar. Depending on the type of radar the distance is obtained either by determining the time-of-flight of the EM waves through the air, i.e., emitted from the radar, reflected off of the object, and then detected by the radar (impulse) or by the phase shift be-tween emitted and reflected wave. In both types it is possible to know the relative speed be-tween the subject vehicle and the object ahead. This parameter is very convenient special for forward looking safety systems, such as ACC or FCW for instance. Radar sensors are rela-tively insensitive to the environmental conditions of fog, rain, snow, and dirt on the sensor. 76/77 GHz long range RADARs are currently some of the most expensive proximity sensors.

Radar systems used in ICT-based safety systems must operate at frequencies in atmos-pheric windows, i.e., frequencies at which the signals are not affected by atmospheric ab-sorption. Radar systems most commonly used in this type of systems operate at 24 GHz and at 76/77 GHz. The size of the sensor is inversely proportional to the operating frequency, so smaller units can be manufactured by using sensors that operate at higher frequencies.

Deliverable D1.1


Short Range Radar (SRR). SRR 24GHz uses short–medium range radar sensors typically mounted in the rear bumper of a vehicle. Detection range normally varies from a distance of 0.2 to 30m, with a resolution of 15cm and accu-racy up to 7.5 cm. This radar certainly does not have the full performance of its 77GHz counterpart, but the 24GHz ACC function is robust enough in practice on test cars. The po-tential of this new sensor is high, as it allows a significant cost reduction.

Fig. 7-1: Short range radar (source: BMW)

Long Range Radar (LRR). 77GHz uses long range radar

sensors. Immune to external agents (like fog) and very reli-able, these systems are very expensive and voluminous. It can detect objects up to 150m in front of the vehicle, and ef-fectively scan the radar beam over an angle of approxi-mately 15º in order to cover the lane occupied by the sub-ject car and the side lanes.

Fig. 7-2: Long range radar sensor (source: AUDI)

As a future trend concerning radar sensors, the 79GHz SRR can be considered.

The European Commission (EC) has identified automotive SRR as a significant technology for the improvement of road safety in Europe. However, from middle 2013 new vehicles will have to be equipped with SRR sensors which operate in the frequency band of 79 GHz (77 GHz to 81 GHz), as decided by the EC in March 19th 2004 (ECC/DEC(04)03).

The transition from 24 GHz to 79 GHz causes an increase in frequency and a reduction of wavelength by the factor 3.3. The smaller wavelength enables reduced antenna size and spacing, and lower effective antenna area. The higher frequency yields increased atmos-pheric and bumper losses. With higher frequencies semiconductor power output decreases (roughly 20 dB per decade), parasitic effects are more stringent, and packaging and testing are more difficult. Hence, Silicon Germanium (SiGe) has been identified as the chip technol-ogy which may fulfil the technological requirements and the cost constraints and which might be an alternative to Gallium Arsenide (GaAs). SiGe HBT technology has the potential to real-ize cost effective “radar on chip” solutions with 79 GHz carrier frequency, 4000MHz band-width, 160° field of view: 160, angular resolution of 5°, bearing accuracy of 1°, distance range from 0-30 m, accuracy of 5cm, both for stationary and moving targets.

Essential features of future 79 GHz radar sensor systems are: low chip and component costs, low assembly costs, improved performance, reduced power consumption, improved electrostatic discharge (ESD)/electromagnetic interference (EMI) and high update rates.

Deliverable D1.1


Another trend related to radar, is that there is a fundamental problem on next generation col-lision warning automotive radar applications: the estimation of lateral velocity of tracked ob-stacles. An uncoupled double filter, namely UDF, exploits the benefits of a multi-sensor sys-tem fusion consisting of an IR mono camera and a MMW radar sensor eliminating their un-certainties in the longitudinal and lateral motion estimation respectively. Results indicate that UDF fusion approach can be deployed in automotive safety applications widening the opera-tional scenarios of such systems and minimizing the false alarms.

7.1.1.5.2 LIDAR

Light Detection and Ranging (LIDAR), sometimes also known as Laser Imaging Detection and Ranging or laser radar is the generic term for laser-based sensors. Time-delay, intensity, and/or phase characteristics of back-scattered EM radiation from a laser are used to deter-mine the distance to an object or surface. Two techniques exist for detecting objects and de-termining relative velocity. One technique uses a high-power pulsed beam of IR light, while the other modulates the light beam with a sinusoidal signal. As in radar, it can determine the relative velocity between the subject and the target vehicle.

By convention, lidar outputs are generally specified in terms of wavelength rather than fre-quency. Lidar systems used in ICT-based safety systems typically operate in the near-IR re-gion of the EM spectrum, between 750 nm and 1000 nm.

Lidar sensors can be grouped into two classes: single- or multi-beam lidar and laserscanner.

A laser beam used in single-beam lidar has a very narrow FOV, typically one degree. These sensors offer a detection range (from 1 up to 120 m), high directionality, and fast re-sponse time. The drawback to these systems is that they may be subject to visibility limitations: dirty sensor, fog, rain, etc. In addition, roadway features such as retro-reflective lane markings, guardrails, and construction bar-riers are highly visible and may be interpreted by the lidar system as a vehicle travelling at the same speed as the subject vehicle. Signal processing algorithms are em-ployed to properly interpret these objects as well as adjust for limited visibility issues.

Fig. 7-3: Lidar sensor (source: LEXUS)

Some systems handle an array of lasers with non-overlapping fields of view (multi-beam li-dar) to achieve an adequate overall area of coverage. We refer to these systems as multiple-beam lidar.

The enhanced field of view provided by multiple-beam lidar is likewise achieved by the sec-ond group of lidar systems referred to as laserscanners. Laserscanners achieve their large

Deliverable D1.1


field of view by using single laser pulses and deflecting them by a rotating mirror into different directions. Currently a horizontal field of view of up to 100 degree is common. The range measurements are based on the time-of-flight principle. A single laser pulse is send out, re-flected by some obstacle and received by the laserscanner. The time passed between transmission and reception yields the distance to the obstacle.

The small size of today’s laserscanners and a weight of less than one kilogram allows a seamless integration into different type vehicles.

Current state-of-the-art laserscanners stand out against other lidar systems by the use of multiple scan layers and multiple echo analysis.

Nowadays they are laserscanners in the market with four layers and providing a vertical field of view of 3.2 degree. By this, the pitching of a vehicle is compensated. Addi-tionally, the intensity of the received echo pulse is used for further computations. If some of the layers perceive the road’s surface it is possible to distinguish between the lane, the lane markings and the roadside.

Fig. 7-4: LUX laserscanner (source: Ibeo)

The range of detection from 0.3 m to 200 m covers the range and field of view of SRR as well as LRR systems. Latest devices have an accuracy of up to 4 cm for the dis-tance measurements and an angular resolution up to 0.125 degree is available. The synchronization with other devices (like laserscanner or video) as master or slave is possible

Multiple echo analysis is applied to account for weather conditions like heavy rainfall where a first reflection echo of the laser pulse may be reflected by a raindrop and a second one by the actual obstacle. Latest laserscanners are developed that these adverse weather conditions will not inhibit a reliable performance of their application.

Fig. 7-5: LUX Laserscanner field of view (source: Ibeo)

Specifically tests with dense traffic on expressways under heavy rainfall conditions revealed full functionality. Problems of blooming, as known from video technology, are unknown to la-serscanners because they carry their own light source and sunlight is removed by an ade-quate filtering technique. Also there exists no danger of being blinded by other vehicles which themselves are carrying infrared sensors. The receiver characteristics of the laser-scanner matches -at worst- only for the fraction of a second the transmitter characteristics of the sensor on the other vehicle which results in the drop-out of a small number of measure-

Deliverable D1.1


ment points. These points can easily be removed by a software filtering process and do not affect the performance of applications.

The TEAM LUX car was the only car in the 2007 DARPA Grand Challenge that performed autonomous driving us-ing only laserscanner and GPS data.

With modern laserscanner technology autonomous driving has already become reality as the 2007 Grand Challenge demonstrated.

As a future trend concerning the next generation of lidar sensors and laserscanners in par-ticular, it can be made out that they will be capable of detecting pedestrians, bicycles, motor-cycles, passenger vehicles, trucks as well as some road infrastructure like lane markings. In addition, they will classify and distinguish the different road users. This is something millime-tre-wave radar cannot do. Object classification is based on object-outlines (static data) of typical road users. Additionally the history of the object classification and the dynamics of the tracked object are used in order to support the classification performance.

When more than one laserscanner is used on a vehicle the laserscanners usually detect the same object at different times. If one just combines the raw measurements of the same ob-ject in a fusion step, the object would be at different places in the vehicle coordinate system. To minimise this effect, a scan data fusion is available for synchronised laserscanners to provide a consistent fused scan.

It can be summarized that, in the past, lidar sensors have been unable to receive reflected light input from some road users to signal their presence. Novel lidar sensors detect all ob-stacles in a vehicle’s path whether they are highly reflective or poorly reflective. In addition, laserscanners provide advanced object information by distinguishing and classifying them.

7.1.1.5.3 VISION

Vision-based systems use one or more digital video cameras to view the characteristics of the roadway and/or the objects near or around the subject vehicle. Image processing will de-termine parameters such as lane position, presence of objects in the subject vehicle’s path, for instance. Most popular applications are blind spot and lane detection warning systems.

Deliverable D1.1


CCD (Charge Coupled Device) sensor is the most popular imaging sensor. High quality, with low noise images but higher power consumption. CMOS (Complementary Metal Oxide Semiconductor) digital alternative to CCD. Cheaper than CCD (up to 100 times) it has a fixed high noise pat-tern and lower energy consumption. CCD-based cameras are the most post popular technology but the growth of CMOS-based cameras is firmly increasing

Even if CMOS-based 3D range cameras are currently available most of the applications use 2D camera. Being a cheaper solution than radar or LIDAR, it is more expensive than US or IR.

Depending on the application the image processing is dif-ferent. Digital images are processed in order to obtain pa-rameters such as lane position, obstacles detection or dis-tance. Vision systems do not provide a direct measure-ment of distance. Instead, this parameter must be calcu-lated based on the geometry of the captured image, a process that requires powerful image processing. Then again, because the technology is based on visual images, the application and capability of vision-based systems are limited only by the computing power and speed available to process the image. Therefore, one of the strengths of vision technology is its versatility.

Fig. 7-6: CMOS camera (source: VOLVO)

Fig. 7-7: Detail view of CMOS camera (source: VOLVO)

Vision-based systems share the same disadvantage that other optical systems (LIDAR and IR sensing). These systems are sensitive to adverse environmental conditions, such as dirt on the windshield or camera lens, fog, rain, and snow. However, image processing algo-rithms can reduce the effects of these factors.

As future trends concerning vision-based sensors, it can be found the following:

3D CMOS sensor performance has been successfully in-vestigated in different test scenarios, including moving ob-jects. Evaluation of traffic scenarios has shown useful range data up to 20 m, in outdoor-situations including bright sun light. 3D sensor technology based on a chip de-sign of 64×8 pixels and image repetition rates of up to 100 Hz are available today. Future development points towards pedestrian protection and collision mitigation, including

Fig. 7-8: 3D CMOS camera for

Deliverable D1.1


short distance vehicle perception up to 25 m BSD (source: PREVENT pro-ject)

The CMOS vision-based sensors will integrate the proces-sor and the logic in, offering a compact and powerful proc-essing platform for computationally intensive real time vis-ual recognition and scene interpretation applications. This standalone camera and vision processing module for automotive applications will include vision processor, a CMOS image sensor, flash and SDRAM memories and all the additional components required for a stand alone vi-sion system: CAN and GPIO interfaces, protected power supply and expansion connector.

Fig. 7-9: Standalone automotive vision application based on CMOS technology (source: Mo-bileye).

Vision sensors can be deployed in a vehicle to perform a variety of functions, including driver monitoring for work-load management; passenger monitoring for intelligent air-bag deployment; pedestrian and object recognition for pre-crash sensing; lane marker and roadway tracking for lane/roadway departure warnings; and general scene and object recognition to improve ACC/FCW/CA (adaptive cruise control/forward collision warning/collision avoid-ance) system robustness through sensor fusion.

Another trend, related to sensor fusion is to use CMOS camera based sensors together with infrared sensors for LDW, LKA and LCA applications.

Fig. 7-10: Sensor fusion radar-dual vision cameras (source: HONDA)

7.1.1.5.4 Infrared (IR)

Two types of sensing techniques are used in IR-based systems: active sensing and passive sensing. Active IR sensing technologies use an IR LED and a corresponding IR detector cell to measure lateral distances between points on the subject vehicle and detectable character-istics on the roadway surface. Specifically, the IR detector cell senses variations in the inten-sity of reflections from the IR beams emitted by the LED onto the roadway surface. Active IR sensing can also be used for range finding, wherein the intensity of scatter is measured as the IR reflects off of nearby object surface. Passive IR sensing measures the thermal energy

Deliverable D1.1


emitted by objects in the vicinity of the sensor. The advantage of IR sensors is that they are inexpensive and small in size.

However, their ability to determine precisely the distance to a detected object is poor, and they have slow response times. Characteristic images detected by IR sensors can include high-reflectance areas (hot spots) that are spatially separated by dark areas. For example, a lead vehicle might produce simultaneous hot spots from the bumper, C-pillar, rear windshield, and rear-view mirror. These hot spots require extra processing to determine whether they belong to a vehicle. Also, the characteristics of short-wavelength IR backscatter may change abruptly as the viewing angle changes. The resultant changes in hot spot reflections may cause the detected vehicle to instantane-ously disappear from the sensor’s view The use of long wave IR is expected to alleviate the problem. Finally, vehi-cles with dark paint or shallow angle geometry (e.g., sports cars) may not reflect sufficient IR energy to exceed the de-tection threshold.

Active IR sensing, as used in current applications, is ar-guably one of the simpler technologies to implement. In order for passive IR sensing to become more widely used, techniques for improving range resolution and reflectivity issues must be refined.

Fig. 7-11: Active IR sensors (source: Citröen)

Fig. 7-12: Passive IR sensors

Future trends concerning IR coincide on using this type of – small and inexpensive - sensors fused with more – complex and pricey - ones in order to ensure 100% detection.

For instance, there is a research about IR technology to create sensors cheaper in order to integrate expensive systems (like the ACC) in middle class vehicles and not only in the lux-ury car segment. To ensure a 100% detection of objects ahead of the vehicle the ACC sen-sor will be supplemented by 24 GHz radar sensors for close distance measurements.

Another trend related to IR is the infrared focal plane array (FPA) operating at a wavelength of 10 µm. It is a promising device for automotive sensor systems because it can detect a human body both day and night without any light source, measure temperature, and easily distinguish a human body from the background. Since infrared radiation emitted from the human body have less energy than visible light, semiconductor sensors made of expensive materials such as HgCdTe traditionally needed to be cooled to cryogenic temperature, and the influence of thermal noise had to be eliminated. It has been difficult to apply these infra-red detectors to vehicles because of such factors as the cooling system price and size.

Deliverable D1.1


7.1.1.5.5 Specific Dynamic Sensors

At this point, it is compulsory to identify the sensors that are needed to obtain in-vehicle pa-rameters necessary for the proper performance of the eVALUE ICT-based safety systems, such as wheel speed, yaw rate, acceleration, steering wheel angle and other vehicle dynam-ics sensors.

Wheel speed sensor

Wheel speed sensors measure the actual wheel speeds of the wheels of a vehicle. The sen-sors are normally assembled into the wheel carrier while an impulse-wheel is connected to the rotating wheel. Mainly two types of wheel speed sensors are in use:

− Passive wheel speed sensors using the effects of in-duction. The sensor consists of a pole pin (5), a permanent magnet (2), an electrical coil (4) assem-bled in a waterproofed casing (3). The rotating im-pulse-wheel (6) connected to the wheel is made of ferromagnetic material. A rotation of the impulse-wheel influences the magnetic flux inside the sensor because of the effects of induction and causes an AC-voltage. The frequency of AC-voltage is propor-tional to the wheel speed an can be to calculate the wheel speed and the wheel acceleration. The AC-voltage signal of passive wheel speed sensors can only be analysed when the amplitude of the signal fits to a specific voltage-level. Therefore passive sensors don’t provide wheel speed information for low velocities.

Fig. 7-13: Passive wheel speed sensor.

− Active wheel speed sensors using the Hall effect. Active wheel speed sensors consist of a magneto resistive Sensor (2) am a impulse wheel with alter-nating magnetic N/S pole (1). The wheel speed can be measured because of the influence of an alternat-ing magnetic field on the electrical resistance of the magneto resistive sensor element. Advantages of active wheel speed sensors compared to passive ones are that a measurement of the wheel speeds is even possible for low velocities.

Fig. 7-14: Active wheel speed sensor integrated into the wheel bearing [(1) wheel bearing, (2) wheel speed sen-sor, (3) impulse-wheel]

Deliverable D1.1


Trends related to wheel speed sensors are focused on reducing weight and space by using more integrated sensors. For instance, wheel speed sensors integrated into the wheel bear-ing. Yaw rate sensor

Yaw rate sensors measure the angular velocity of the rotation of a vehicle referred to its ver-tical axis. Usual yaw rate sensors use oscillating masses to provide a sensor signal propor-tional to the yaw rate. The sensor signal is derived from the oscillation of the masses which are influenced by the Coriolis acceleration in the regarding rotation direction.

− Precision mechanics yaw rate sensor. Measurement of the Coriolis acceleration with an oscillating steel mass. Capacitive measurement of the Coriolis ac-celeration.

Fig. 7-15: Precision mechan-ics

− Micro-mechanics yaw rate sensor. Measurement of the Coriolis acceleration with quartz oscillator crys-tals. Oscillation frequency approximately 15 Hz. Ca-pacitive measurement of the Coriolis acceleration. Derivation of the yaw rate using integrated signal-evaluation electronics. Integration of an additional acceleration sensor for the measurement of the lat-eral acceleration.

Fig. 7-16: Micro-mechanics

Trends related to yaw rate sensors are focused on reducing weight and space by using more integrated sensors. Also integrated sensor-clusters for the combined measurement of roll, pitch and yaw motion are developed to ensure a complete data basis for further vehicle func-tions such as damper control or rollover prevention.

Deliverable D1.1


Acceleration sensor

Acceleration sensors are used to provide information about the actual driving state of the vehicle.

− Micro mechanical acceleration sensors. The accel-eration in a referred direction is measured by the displacement of a seismic mass.

Fig. 7-17: Micro-

mechanical Steering angle sensor

Steering wheel angle sensors deliver information about the steering wheel angle set by the driver. Sensors are mainly located in the steering column next to the steering wheel or in the steering gear.

− AMR-steering angle sensors use the dependency of

the electrical resistance of magneto resistive materi-als on the direction of a constant magnetic field. Magnetic gears connected with the steering shaft are and the rotation of the magnetic fields are measures by AMR-elements. The steering angle is derived from the signal of the AMR-elements.

Fig. 7-18: AMR steering angle

− Optical steering angle sensors. Optical provide in-formation about the steering angle with the help of optical photo elements an encoder wheel connected to the steering shaft. The signals of the photo ele-ments are analyzed with the help of an internal con-troller and converted into a steering angle signal

Fig. 7-19: Optical steering an-gle

Deliverable D1.1


7.1.1.6 Actuators and Trends

7.1.1.6.1 Warning

A warning issued by the safety system will use different human perception alternatives in or-der to warn or inform the driver, depending on the level of importance of the information to be transmitted and on precautious actions he could execute. Thus, this function output, oriented to human perception can be: visual, acoustic and haptic. Lights, buzzers or loudspeakers, are examples of warning indicators used in the safety systems.

- Audible warnings typically use the ex-isting loudspeakers of the vehicle.

Fig. 7-20: Electric motor for use in an electric retractor application

- Haptic belt uses an electrical seatbelt retractor to “tug” the driver seat belt. These are also used to pretension the belt prior to a crash.

- Brake pulse uses the brake actuators to produce a short brake pulse. The pulse is not intended to reduce vehicle speed but mainly to provide a haptic warning.

- Haptic seat uses vibrator integrated in the driver seat and warns the driver with a vibration pulse.

Fig. 7-21: LDW system with ECU and seat buzzers. (source: Citröen)

Deliverable D1.1


- There are several versions of visual displays examples: in-vehicle light closed to the side mirror, as shown in the picture on the right where the visual function output is from the BSD ICT-based safety system, lights in the dashboard instrumentation, or lights projected on the windshield (head up display, HUD), as the one shown in the picture on the right where the visual function output could be from most of the ICT-based safety system;

Fig. 7-22: Examples of visual warnings (source: VOLVO)

Fig. 7-23: Visual warning display, the light is re-flected on the windshield providing a simple HUD (source: VOLVO)

7.1.1.6.2 Support and Autonomous Intervention

Autonomous interventions under this report is understood as the subject vehicle physical re-action in order to the reach the ICT-based safety system proper functionality. The following could autonomously intervene on the subject vehicle:

Deliverable D1.1


Autonomous intervention in the ENGINE

- Previous devices, based on actuators in the me-chanical throttle. In the first cruise control sys-tems the throttle was only a mechanical system (not the potentiometer activated throttles used today), and the cruise control system adjusted the speed of the vehicle controlling mechanically the throttle position.

- Actual devices, based on actuators in the elec-tronic throttle. The actual throttle systems are managed with a potentiometer moved by the throttle pedal. Reading the potentiometer output, the ECU activates an electronic motor in the air intake butterfly valve, limiting how much air the engine takes in. Some OEMs have developed in-take systems without intake butterfly valve, only with continuously variable intake valve lift, from ~0 to 10 mm, on the intake camshaft only. These engines are unique in that they rely on the amount of valve lift to throttle the engine rather than a butterfly valve in the intake conduct. Only one OEM uses this technology in mass-market engines.

- Trends, in the throttle actuation are based on camless valvetrains. This new system allows for lean-burn operation and individual cylinder shut-down for fuel saving. As a result, fuel consump-tion and emissions can be improved by 20%, all while increasing the engine's performance. The technology also eliminates the weight and fric-tional losses of rotating camshafts and cams. With this camless valvetrains each valve oper-ates individually, so the butterfly valve is not necessary, and the actuator associated with it can disappear.

Fig. 7-24: Wires connecting gas to the throttle and the cruise control ac-tuator in an old fashioned cruise con-trol system.

Fig. 7-25: Electric intake throttle with an intake butterfly valve moved by an electrical motor (source: MAVEL).

All the manufacturers have similar modules both in throttle and brake actuators. The tech-nologies are widely known, and therefore the product manufacturing and the technical solu-tions are very similar, with no major differences.

Deliverable D1.1


Manufacturers: BOSCH, SIEMENS-VDO, AISAM, PIERBURG, DENSO, DELPHI, MAGNETI MARELLI, MGI COUTIER, JOHNSON CONTROLS, VISTEON, ATTAN, SOLEX.

- Throttle mod-ule, controls the air intak-ing.

Fig. 7-26: Throttle actuator. (source: MAVEL)

Autonomous intervention in the BRAKE

Current devices are based on the following mechanical brake actuators. Today in the Auto-motive industry the hydraulic brake system is used almost in every mass-production vehicle.

Basically the hydraulic brake system contains the following mechanical elements:

- Master cylinder. Supplies pressure to the circuit.

Manufacturers: ATE, TRW, BOSCH, ADVICS, NISSIN, MANDO, KASKO.

- Brake servo (booster). Multiplies the force applied by the driver through the brake pedal.

Manufacturers: ATE, TRW, BOSCH,

Fig. 7-27: Master cylinder. (source: MAVEL)

Deliverable D1.1


ADVICS, NISSIN, MANDO.

- Brake control unit. This module man-ages the brake pressure in the circuit when one of the systems that use the brake system is activated (ACC, ESC, etc.). The modulation of the brake pressures for the single wheel is real-ized by this central hydraulic control unit equipped with the required valves and hydraulic components. Usually ECU and HCU are integrated into an ABS control unit block.

Manufacturers: TRW, BENDIX, SU-MITOMO, KELSEY HAYES, MOBIS, BOSCH, ADVICS, CONTI-TEVES, HONDA, TOYOTA

- Brake calliper is the assembly that houses the brake pads and the pis-tons.

Manufacturers: TRW, BOSCH, KASKO, ATE, ADVICS, NISSIN.

Fig. 7-28: Brake servo. (source: MAVEL)

Fig. 7-29: Electronic control unit (ECU) (1) and attached hydraulic control unit (HCU) (2).

Fig. 7-30: Brake calliper. (source: MAVEL)

Deliverable D1.1


- Trends are basically in the brake cal-lipers, i.e., electric brake actuators (brake by wire). Most TIER1 suppliers of brake systems have their brake by wire system developed. With this sys-tem all the components of the conven-tional hydraulic brake system are re-moved except the brake callipers, re-placed for electric brake callipers. Eliminating the hydraulic system of pipes, brake cylinders, brake boosters and brake control hydraulic units low-ers vehicle weight, increases reliabil-ity, and reduces maintenance re-quirements.

Fig. 7-31: Electric brake calliper, EBW (source: Siemens-VDO)

Autonomous intervention in the STEERING

Electric Power Steering (EPS) is the basic option for autonomous intervention in the steering. Basically, an EPS is a regular steering system with an electric motor providing torque assis-tance. Huge amount lot of data is processed to determine when and how much torque should be applied, but at the end the main thing is torque. Safety must be the most important con-

sideration about EPS designing.

Fig. 7-32: From left to right: electrically powered hydraulic steering, column-drive electric power steering and belt-driven electric power steering

First electric power steering (EPS) systems were based on a brush DC motor. Since torque assist is the goal of any power steering system, the DC motor is a natural choice for this ap-

Deliverable D1.1


plication, just because torque can easily be controlled by regulating the motor current. The DC motor is still a popular choice for many designs. It's interesting to note that most hybrid vehicles employ EPS not only for the energy savings provided, but also because of the need for continued steering assist even when the engine is switched off. But the DC motor also has some unattractive attributes, such as brush arcing and commutator/brush friction, and possible "unwanted steer" if the system fails, perhaps the most dangerous failure mode in a power steering system. A mechanism is therefore required to mechanically disconnect the motor from the steering system when this condition is detected.

Fig. 7-33: EPS electric motor (source: MAVEL)

In the mid 90´s, switched reluctance (SR) type of motor started to have more attention, with promising potential for EPS systems. SR are easy to construct and contain no permanent magnets, resulting in excellent high-temperature performance and superb reliability. In fact, SR machines can survive a single-phase failure and keep on spinning.

Brushless permanent magnet (BPM) type of motor promised new levels of efficiency and power densities, based on its powerful rare earth magnets. Compared to SR motors, BPM machines exhibit a dramatic reduction in motor vibration.

AC induction motor (ACIM) designs can achieve lower levels of torque ripple compared to BPM motors. Since ACIM is free of any permanent magnets, it offers another advantage in EPS designs that can be exploited during a system failure. Similar to SR motor, the field in an ACIM can be extinguished by simply disabling the inverter transistors. In a fault condition, this effectively turns the rotor into an inert piece of rotating metal in a fraction of a second. Even though no power assist is available, the motor offers no resistance to manual steering. By contrast, the magnetic field in a permanent magnet motor is, well permanent. This means that although the drive transistors are switched off, the motor can still generate magnetic drag as a result of the rotor flux.

Deliverable D1.1


Fig. 7-34: EPS electric motor, with integrated ECU (source: MAVEL)

Related to autonomous intervention by steering, the most important well known trend is that within a decade starting now, EPS will be the dominant technology. However, as more and more automotive systems incorporate electric motors, the vehicle's alternator is quickly be-coming overtaxed. Migrating from 12V to 42V systems promises to mitigate the power-utilization problem.

Additionally, there is much discussion about the potential for steer-by-wire (SBW). This system would completely remove any mechanical linkage between the steering wheel and steering rack. The steering power is generated by electric or electro-hydraulic wheel positioning systems. With current EPS designs, a system fault results in the motor being disabled, but manual steering is still possible. With SBW, no mechanical linkage exists, which means that new failsafe strategies will need to be developed. The benefits include: improved crash characteristics, new steering-comfort functions, and a layout according to er-gonomic aspects.

Fig. 7-35: EPS

Deliverable D1.1


Autonomous intervention in the TRANSMISSION

Transmission systems activated electronically are nowadays integrated in safety systems, providing better stability. The actuators in those systems are usually electric motors, with no special requirements but with different designs, depending on the OEMs.

Some active differentials incorporate an electronically-controlled hydraulic multi-plate clutch. The system optimizes clutch cover clamp load for different driving conditions, regulating the differential limiting action between free and locked states to optimize front/rear wheel torque split and thereby producing the best balance between traction and steering response.

Fig. 7-36: Central electronically activated differential (source: Haldex).

The use of engine torque and brake pressure information in the regulation of the differential allows the system to determine more quickly whether the vehicle is accelerating or decelerat-ing, and actuate in consequence. This torque transfer regulation increases the car stability permitting higher levels of cornering performance.

Using integrated management of different systems is possible to effectively and seamlessly control vehicle dynamics when accelerating, decelerating or cornering under all driving condi-tions.

Fig. 7-37: Electrical motor in a central differential (source: BMW).

Deliverable D1.1


7.1.1.7 ECUs and Trends

In-vehicle networks provide fast, reliable, and efficient communications for the control of vir-tually all mechanical and electric automotive systems—everything from windshield wipers to braking and suspension, to heating and air conditioning systems. Networks also deliver in-formation from all over the vehicle to the dashboard where drivers can check fuel level, en-gine temperature, and other indicators at a glance.

Instead of a thick wiring harness composed of dozens of wires (50 kg weight), networks im-plement a "common carrier" approach by sending control information for numerous systems over just a few wires.

Just like any other network, the information stream is organized according to a network pro-tocol to assure that a particular system actuator can identify which data packet is intended for it and act accordingly. From a functional perspective, the four basic components of an in-vehicle network are:

• The transport medium—usually copper wire

• Transceivers—integrated circuits (ICs) dedicated to the critical task of transmitting and receiving information

• The network protocol—software that provides identification criteria and rules for ex-changing information

• Microcontrollers (MCUs) —execute the network protocol and continuously provide and receive information via the transceivers

Actually, an automobile network is far more complex. It includes other components to assure the high reliability and safety required by automobile manufacturers.

General Electronic Control Unit Architecture

An electronic control system includes, in addition to the calculator, input signals (sensors and parameters) and actuators (see figure 7-38). An electronic system can be divided into four functional blocks. Sensors report on the conditions of car operation and carry out the conver-sion of several physical parameters into electrical signals. The actuators (electromechanical components) do just the opposite, convert electrical signals from the ECU (calculator) to the mechanical magnitude.

Deliverable D1.1


Fig. 7-38: Electronic Control System (source: Bosch).

The communication bus consists of information exchange between different ECU systems in a single wire bus called multiplexed bus. The increasing number of electronic systems trans-lates into ever greater complexity of cabling. A medium range vehicle contains approximately 1,6 km of cables. On the whole, the electrical wiring contains up to 300 connectors and around 2000 terminals. The initial aim of multiplexed bus is simplifying the wiring, resulting in increased reliability. The other advantage is to make possible, through these exchanges, the addition of new functionalities. There are now up to 4 networks in production cars.

The self-diagnosis block aims to monitor continuously the smooth operation of the four parts mentioned above and acts in the event of a malfunction (activation of the emergency mode). Any anomaly detected is stored in a specific memory that the after-sales services can access through a terminal via a specific interface. Over the years, the horizon of possibilities for this interface has been extended. Nowadays, it allows to activate actuators manually to check their operation and read directly some parameters of system operation. Today this interface allows the setting of some functions, or downloads of software upgrades (new features).

As a main component, the calculator (electronic control unit) has several roles:

• Activate some actuators through electrical signals, according to a programmed soft-ware and depending on the signals from the sensors.

• Communicating with other electronic systems for the exchange of information.

• Diagnose System (self-testing).

ECU Architecture

Deliverable D1.1


The safety, comfort and pollution standards imposed on automobiles require electronics sys-tems of control and regulation. The calculator is the core of these devices (see figure 7-39):

(1). Input signal conditioning, (2). digital treatment, (3) low intensity power stage, (4) high

intensity power stage, (5) power and (6) CAN bus (multiplexed)

Fig. 7-39: Engine control calculator

The calculator optimizes control commands based on collected data by the sensors, and generates the signals to manage the actuators. The current vehicles incorporate about 20 or more calculators. The increase in benefits and the new features are obtained synchronizing processes controlled by each of them, and adapting to each other, in real time, interchanging information through the multiplexed bus.

Software development

Microcontroller instructions are directly encoded in binary, and to improve the programming, high level languages have been developed for each microprocessor. Programming of com-plex functions needs more advanced languages (C language) to facilitate the programming and minimize the risk of errors. These languages need compilers to translate software. Thanks to these compilers, programs like an ABS function for example, can be easily mi-grated from one microcontroller to another.

For calculators programming, software developers use "emulators" instead of microcontrol-lers (see figure 7-40). Thanks to them, the program can be designed and validated on a PC with high level languages such as C.

Deliverable D1.1


Fig. 7-40: Emulator device (source: NEC)

Electronic control development

The development of an electronic system is carried out taking several steps into account ac-cording to the manufacturer's workbook ( "how and why") and the workbook functional pro-vider ( "how"). Mainly, these are:

• Materials’ design. "Material" means all of the mechanical and electronic components that make up the calculator and the electronic system as a whole.

• Functional design. To specify a very precise functions to be performed by the future system.

• Software design and develop. To design and develop a program according to system functions defined in the functional design phase.

7.1.1.7.1 Functional Safety

A safety system is characterised by the safety functions that are provided. The safety func-tions are composed by the interaction of safety-related modules and sub-functions.

The correct operation of safety functions is specified by well defined safety parameters and safety attributes. The integration of the safety entities is summarised by the concept of func-tional safety.

Functional safety for a safety system is specified in terms of safety functions and safety in-tegrity levels. Each safety function has a safety integrity level assigned. Safety functions are designed to provide the risk reduction pointed out by the risk and hazard analysis, by elimi-nating or mitigating dangerous faults or critical system states.

Figure 7-41 illustrates the risk reduction to be implemented by the integration of an electri-cal/electronic/programmable electronic safety-related system E/E/PES, other technology or external devices [61508]. The safety function of an E/E/PES such as a Lane Keeping Assis-tant System (LKA) is intended to reduce the risk of a vehicle to unintentionally leave the lane.

Deliverable D1.1


The safety-related functions of a LKA include e.g. the lane detection function, the generation of warning signals according to the position of the vehicle within the lane, the adjustment of the steering assist torque etc. By implementing the specified safety functions, the LKA pro-vides its share of the necessary risk reduction as pointed out by the hazard and risk analysis.

Actu

al risk redu

ction

External riskreduction

E/E/PES

Othertechnology

Necessary risk red

uction

Basic riskWithout the safety

function(”EUC risk”)

Tolerable risk

Residual risk

Risk

Fig. 7-41: Principle for risk reduction

Activities required to allocate safety functions and to achieve the specified safety integrity level are directly linked to the development process and relate to the concept of overall safety lifecycle.

The safety functions integrated in an overall safety system are defined and implemented as a result of a hazard and risk analysis to comply with the overall safety lifecycle requirements. The overall safety lifecycle represented in fig. 7-42 shows the different phases of activity re-lating to development, of functional safety of electrical/electronic/programmable electronic safety-related systems (E/E/PES).

Requirements set-up

The following tasks are included in the set-up requirements:

• Concept

• Overall scope definition

• Hazard and risk analysis

Deliverable D1.1


• Overall safety requirements

• Safety requirements allocation

Externalrisk

reduction

11

Modificationand retrofit

15

Other tech.

10

Concept1

Overall scope definition2

Hazard and risk analysis3

Overall safety requirements

4

Safety requirements allocation

5

RealisationE/E/PES

9

Overallinstallation

12

Overall safety validation

13

Operationmaintenance

14

Overallplanning

76 8

RequirementsSet-up

Productdevelopment

AfterStart ofproduction

Fig. 7-42: Overall safety lifecycle

The objective of the concept phase is to provide enough information to develop a level of un-derstanding of the equipment under control (EUC), in this case the vehicle and its environ-ment. A Lane Keeping Assistant System e.g. would at the concept phase be described as a system intended to reduce the driver’s need to make frequent steering corrections.

Deliverable D1.1


Additional information would be added to precise the principles for lane detection and active steering in order to settle the Overall scope definition that determines the driving conditions (boundaries of the EUC) and the EUC control system (E/E/PES). Assumptions for keeping the LKA function enabled, concerning e.g. driver input, curvature limits, etc. is a mandatory information to carry out a hazard and risk analysis that ultimately defines the overall safety requirements set-up.

The safety requirements allocation ends the first sequence of activities. Thus, the fulfilment of the overall safety requirements is achieved by the proper execution of the development process which combines the overall planning and the realisation of the associated tasks.

Product development

The following tasks are included in the product development process:

• Overall operation and maintenance planning

• Overall safety validation planning

• Overall installation planning

• Realisation E/E/PES

• Realisation other technology

• External risk reduction

• Realisation Overall installation

• Realisation Overall safety validation

• Realisation Operation maintenance

The realisation, validation, installation and the maintenance of the E/E/PES requires a plan for each activity. Such plans are developed to ensure that the safety integrity level for each required safety function is reached.

Appropriate techniques and measures to detect and control hardware failures are listed in the current standard [61508]. A number of measures and techniques for avoidance of sys-tematic failures such as design faults or specification errors are described as well.

After start of production

The following task eventually takes place under the “After start of production” process:

• Modification and retrofit

The activities carried out under this phase ensure that the functional safety for the E/E/PES is appropriate both during and after modification and retrofit.

The replacement e.g. of original components by modified items such as new types of radar may introduce new risks or potential sources of faults. Hence, it is important that the activities

Deliverable D1.1


subsequent to such a task are considered at the appropriate phase of the overall safety life-cycle.

7.1.1.7.2 Reliability

The internationally recognized safety standard IEC 61508 [61508] as well as the upcoming standard for functional safety in road vehicles, ISO/WD 26262 [26262], both put several types of hardware requirements on the design to achieve a specific safety integrity level. Fundamental requirements are those on hardware fault tolerance (HFT), safe failure fraction (SFF), and probability of failure (either per hour or per demand). The former two essentially put requirements on the system architecture and the diagnostic functions used, while the lat-ter one puts requirements on the quality of components as well as maintenance strategies. SSF and probability of failure are assessed using quantitative analysis, i.e. reliability calcula-tions, whereas the HFT is assessed using qualitative analysis, e.g. inspection of the system architecture.

The safety integrity level is determined during a risk analysis where risks are classified ac-cording to e.g. severity and frequency. Automotive safety systems are expected to belong to the SIL2 and SIL3 categories [Pop07].

A specific safety integrity level can be claimed according to Table 7-1 and Table 7-2. As an example, a continuous mode SIL2 system shall have a probability of failure per hour in the range from 10-7 to 10-6. Since all automotive systems are built on complex components (Type B subsystem according to IEC 61508) Table 7-2 becomes relevant. SIL2 could be claimed e.g. by having a hardware fault tolerance of 1 and a safe failure fraction larger than 90% or a hardware fault tolerance of 1 and a safe failure fraction larger than 60%.

Safety integrity level Low demand mode Continuous mode

4 ≥ 10-5 to < 10-4 ≥ 10-9 to < 10-8

3 ≥ 10-4 to < 10-3 ≥ 10-8 to < 10-7

2 ≥ 10-3 to < 10-2 ≥ 10-7 to < 10-6

1 ≥ 10-2 to < 10-1 ≥ 10-6 to < 10-5

Table 7-1: Probability of failure limits for low demand and continuous mode vs. safety integ-rity level [61508]

Deliverable D1.1


Hardware fault tolerance Safe failure fraction 0 1 2

< 60 % not allowed SIL1 SIL2

≥ 60 % to < 90 % SIL1 SIL2 SIL3

≥ 90% to < 99% SIL2 SIL3 SIL4

≥ 99% SIL3 SIL4 SIL4

Table 7-2: Safe failure fraction and hardware fault tolerance vs. safety integrity level for type B subsystems [61508]

To be able to calculate the probability of failure and safe failure fraction it is necessary to know the individual failure rates of the safety-relevant subsystem components. To identify the safety-relevant components, it is important to study the circuit schematic drawings and estab-lish a block diagram where safety-related parts are clearly distinguishable from non safety-related parts. Failure rates could either be provided by the component vendor or there is a possibility to use reliability data prediction handbooks. Two common handbooks are MIL-HDBK-217F [DoD217] and IEC TR 62380 [62380], e.g. IEC TR 62380 provides failure rates based on mission profiles. The mission profile takes into account, operating cycles per year, working phases, and ambient temperatures. In the handbook the failure rates are assumed to be constant, i.e. the components are only in operation during their useful life. Additionally IEC TR 62380 provides failure modes, e.g. for a surface mount resistor, 60% of the failures will be drifts and 40% will be open circuits.

Time

Fai

lure

Rat

e

Infantmortality

Useful life Wearout

Fig. 7-43: Failure rate of electronic components, the bathtub curve

Deliverable D1.1


Once all component failure rates and failure modes have been determined, a failure modes and effects analysis (FMEA) [60812] is performed to classify failure rates into safe or dan-gerous. It is also important to determine the dangerous failures which are detected by diag-nostic tests or monitoring. For non-complex parts this is done in the detailed FMEA but for complex parts the undetected dangerous failure rates have to be calculated from the highest diagnostic coverage value which can be considered achievable for a used technique [4], e.g. a RAM checkerboard test.

The overall failure rates are calculated by reliability block diagrams (RBDs) [61078] or fault-tree analysis (FTA) [61025]. Safe failure fraction can now be calculated as the sum of total safe and detected dangerous failure rates divided by the total failure rate, whereas the over-all diagnostic coverage is calculated as the total dangerous detected failure rate divided by the total dangerous failure rate.

It is a bit trickier to calculate the probability of failure. Here diagnostic test interval, proof test interval, and mean time to repair have to be considered. Diagnostic test interval is the fre-quency at which diagnostic test are run. Proof tests are performed to detect failures so that, if needed, the system can be restored to an “as new” condition. Markov techniques [61165] are usually used to calculate the probability of failure.

The following information shall be provided by the vendor of a SIL-rated subsystem, e.g. an ECU (electronic control unit):

• PFH, Probability of dangerous failures per hour

• SFF, Safe failure fraction

• HFT, Hardware fault tolerance

• T, proof test interval

• DI, Diagnostic test interval

• DC, Diagnostic coverage

• Highest achievable SIL (on the basis of techniques and measures used to prevent

systematic faults being introduced and the design features which make the subsys-tem tolerant against systematic faults)

7.1.2 Evaluation methodology

7.1.2.1 Standards and Reports

ISO 15622:2002

ISO 15622:2002 [15622] contains seven parts: scope, normative references, symbols, classi-fication, requirements, and performance evaluation test methods, of which the latter three parts are the most interesting for the eVALUE project. There is also an Annex which contains

Deliverable D1.1


technical information on e.g. how to determine certain parameters which are important for the tests.

ISO 15622:2002 classifies ACC systems into four different types and four different perform-ance classes with respect to curve radius capability (table 7-3).

Type Manual clutch operation

Active brake control

Performance class

Curve radius capa-bility

1a yes no I no capability claimed 1b no no II ≥500 m 2a yes yes III ≥250 m 2b no yes

IV ≥125 m Table 7-3: ACC system types and performance classifications

The requirements are grouped into the following six categories:

• Basic control strategy, requirements on e.g. ACC system states and at what velocities the ACC function can be engaged.

• Functionality, requirements on e.g. clearance capabilities, following capability, target discrimination, and curve capability (performance classes II - IV).

• Basic driver interface and intervention capabilities, requirements on e.g. operation elements and system reactions, display elements, and symbols.

• Operational limits, requirements on e.g. minimum set speed as well as maximum de-celeration and acceleration rates.

• Activation of brake lights, requirements on illumination of brake lights for type 2 ACC systems, i.e. systems with automatic braking.

• Failure reactions, requirements on how the system shall react upon the failure of a subsystem (engine, gearbox, sensor, ACC controller).

The performance evaluation tests shall be conducted with specified environmental condi-tions: test track surface material (flat dry asphalt or concrete), temperature (20 ± 20 °C), and horizontal visibility (> 1 km). Test targets are also specified. For LIDAR-based ACC systems, the test targets are specified using a coefficient value for a diffuse reflector. For the RADAR-based ACC systems on the other hand, the targets are specified using the radar cross sec-tion (RCS).

Three (two for performance class I) different performance evaluation tests shall be per-formed:

• Detection range test, the goal of this test is to find out if a test target can be detected between minimum and maximum detection range. The maximum detection range is calculated from maximum selectable set speed and maximal selectable time gap at maximum selectable set speed. The minimum detection range is selected as the maximum of 2 m/s or 25% of minimum speed at which automatic acceleration is al-lowed. There is also a boundary between the maximum and minimum detection ranges below which is enough to only detect vehicles (no ranging is necessary). This

Deliverable D1.1


boundary is calculated from the minimum speed at which automatic acceleration is al-lowed and minimum selectable time gap at minimum speed at which automatic accel-eration is allowed.

• Target discrimination test, the goal of this test is to find out if the subject vehicle under ACC control can follow a target vehicle while passing an identical (to the target vehi-cle) forward vehicle in an adjacent lane. The test starts by having the target and for-ward vehicle travelling along side each other with the subject vehicle in steady state time gap control mode behind. Then the target car accelerates and pulls away after which the subject vehicle shall follow.

Subject Vehicle

Forward Vehicle

Target Vehicle

c

v

Fig. 7-1: Target discrimination test (clearance, c, vehicle velocity, v).

• Curve capability test, the goal of this test is to find out if the subject vehicle can detect and decelerate when the target vehicle slows down in a constant radius curve. The ACC of the subject vehicle shall be in time gap mode and the deceleration shall start before the time gap becomes short than 2/3 of the maximum selectable time gap.

SAE J2399

SAE J2399 [J2399] contains four parts: scope, references, definitions, and requirements as well as two appendices. One of the appendices contains the ACC system characterization procedure. There is no classification of ACC systems in SAE J2399.

The requirements are grouped into the following five categories:

• Sensor capability, requirements on the response capability of the sensor.

• Operational characteristics, requirements on e.g. minimum and maximum set speed as well as time gap settings. There are also requirements on the illumination of stop lights.

• Operating state transitions, requirements on ACC system states and via what means the ACC can be disengaged.

Deliverable D1.1


• Displays, requirements on indicators, signals, warnings, and alerts.

• Performance evaluation test methods, requirements for a minimum available time gap test and a maximal available time gap test.

The goals of the performance evaluation tests are to find out if the ACC system fulfils its maximal and minimal time gap throughout the ACC velocity range. The subject vehicle shall be travelling in speed mode until it closes in, when the time gap mode shall be automatically activated. The forward vehicle shall be travelling at three different speeds: 97 km/h, 16 km/h above the minimum ACC operating speed, and 16 km/h below the maximum ACC operating speed.

Considering maximum set and operating speed, SAE J2399 refers to ISO 15622:2002 for compliance test procedure.

ISO/DIS 22178 and ISO/DIS 22179

Both these standards are draft standards, i.e. not publicly available, however most likely they will become officially during the duration of the eVALUE project.

ISO/DIS 22178 [22178] considers low speed following (LSF) systems. LSF systems provides automatic car following at low speeds. The standard is very similar to ISO 15622:2002. The significant difference is that there two extra performance evaluation tests: one of the auto-matic deceleration and one of the automatic re-targeting capabilities.

ISO/DIS 22179 [22179] considers full speed range adaptive cruise control (FSRA) systems. This system is an enhancement to conventional ACC systems. The FSRA system allows the subject vehicle to follow a forward vehicle down to a standstill. The standard is very similar to ISO 15622:2002. The significant difference is that there is an extra performance evaluation test of the automatic stop capability.

ISO 15623:2002

Transport information and control systems – Forward vehicle collision warning systems (FVCWS) – Performance requirements and test procedures

ISO 15623:2002 specifies performance requirements and test procedures for systems capa-ble of:

• Warning the vehicle driver for short inter-vehicle distance

• Closing speed which may result into a rear-end collision with other vehicles or includ-ing motor cycles, ahead of the subject vehicle while it is operating at ordinary speed.

ISO 15623:2002 is applicable to operations on roads with curve radii over 125 m.

Functional FVCWS elements

Deliverable D1.1


The functional elements of the FVCWS inter-act with each other together in realising the se-quence of operating states and warnings issued during a specific operation. The functional elements belong to three domains, namely: the environment, the vehicle and the driver. To each domain is associated one or more functional elements as described in (table 7-4).

Domain Functional FVCWS elements

Comments

Environment Detection and ranging of obstacle vehicles

Obstacle vehicles are vehicles moving or stationary that are considered as potential hazards that can be

detected by this system

Vehicle 1) Subject vehicle motion determina-tion

2) FVCWS warning

strategy

Driver 1) Driver prefer-ences

2) Warning

1) Chosen level of sensitivity, style of driving

2) Preliminary collision warning is the information that the system gives to the driver indicating the presence of a forward obstacle vehicle.

The collision warning is issued in the advanced stages of a dangerous situation to warn the driver of the need to perform emergency braking, lane chang-

ing or other manoeuvres in order to avoid a collision

Table 7-4: FVCWS system elements

Basic consideration of collision warning

Collision warning uses the same sensor information as ACC. It estimates the time necessary to avoid a collision, taking the driver's reaction time into consideration. If the driver doesn't appear to react when a collision risk has been determined, collision warning emits an audible and visual warning to draw immediate attention. The driver can often choose different levels of sensitivity, according to the style of driving.

• Basic equation

• Scenarios where warning is issued

• Evaluation results of T and a

• Calculation examples of the warning distance

Deliverable D1.1


• Design parameter

The specifications and requirements addressed in the standard concern the following:

1) Warnings

a) Monitoring distance and relative speed between obstacle vehicle and subject vehicle

b) Judging the timing of collision

c) Preliminary collision warning and collision warning

d) Fault indicator

2) System classification

Class Horizontal curve radius capability

I Curve radius ≥ 500 m

II Curve radius ≥ 250 m

III Curve radius ≥ 125 m

3) Obstacle vehicle detection area and performance

a) Obstacle vehicle detection area

b) Warning distance accuracy

c) Target discrimination ability

4) User safety requirements

a) Optical radar

b) Radio wave radar

5) Human interface requirements a) Warning output specification

b) Interface with other warnings

c) Operational status display

6) Awareness of system limitations

The evaluation test methods for measuring detection performance include:

1) Test target specification

a) Optical radar

b) Radio wave radar

Deliverable D1.1


2) Environmental conditions

3) Test method for detection zone

4) Test method for warning distance accuracy

5) Test method for target discrimination ability

a) Longitudinal discrimination

b) Lateral discrimination

c) Overhead discrimination

SAE J2400

FCW systems are onboard systems intended to provide alerts to assist drivers in avoiding striking the rear end of another moving or stationary motorised vehicle.

The report describes elements for a FWC operator interface as well as requirements and test methods for systems capable of warning drivers of rear-end collisions.

The information gathered in the report concerns original equipment and aftermarket FCW systems for passenger vehicles including cars, light trucks and vans. The report does not apply to heavy trucks nor addresses integration issues associated with adaptive cruise con-trol (ACC). Consequently aspects considered in this report may be inappropriate for an ACC system integrated with a FCW system.

The report contains a requirement set-up for operating characteristics and for the occurrence of crash alerts, as follows:

1) System and Information Display Characteristics (16 parameters)

2) Requirements for the occurrence of Crash Alerts

a) Geometric characteristics of the alert zone

b) Longitudinal conditions for alerts

c) Computing alert timing requirements (6 steps are used)

Performance evaluation test methods to verify compliance with J2400 are addressed as fol-lows.

3) Testing criteria and assumptions

a) A Pass/Fail criteria

b) Crash alert timeliness

c) In-path nuisance alerts

d) Out-of-path nuisance alerts

4) Test procedure descriptions

Deliverable D1.1


12 test scenarios where the speed and acceleration of the subject vehicle (SV) and lead vehicle (LV) or target vehicle, are presented in next figure.

The FCW-equipped vehicle is called the “subject vehicle” while the “lead vehicle” represents the potential collision threat. VSV and VLV denote the initial speeds of the SV and the LV as shown in Fig. 0-4. aSV and aLV denote the acceleration of the SV and the LV respectively.

SV (Subject vehicle) LV (Lead vehicle )

Vsv, asv VLV, aLV

Fig. 7-44: Rear Instantaneous observed alert onset

A schematic for combining alert timing rules and alert zone requirements is presented in next figure.

Alerts triggered by objects or LV outside alert zone are Out -of-Path Nuisance

AlertsAlerts

triggered by a LV here are in -Path Nuisance

Alerts

Alert range limits

depend on speeds of

both vehicles and acceleration

of LV

SV

Must give alert when LV is here

OK to begin alert when LV is here

3.6 m

5 m

R too-late

R too-early

Fig. 7-45: Combining alert timing rules and alert zone requirements

# FCW system test Crash

alert test Out-of-path Nui-sance Alert test

Number of trials

1 SV at 100 kph approaches stopped vehicle * 5

Deliverable D1.1


2 SV 70 kph behind principal other LV. Changing lanes to reveal stopped LV

* 5

3 SV (nominally at 60 kph) approaches 10 kph. Principal other LV

* 5

4 SV at 100 kph approaches a motorcycle that is following a truck at 35 kph

* 5

5 SV at 50 kph approaches a 30 kph principal other LV * 5

6 SV tailgating a principal other LV at 100 kph – principal other LV brakes mildly

* 5

7 SV at 100 kph principal other LV braking moderately hard from same initial speed

* 5

8 SV (nominally at 100 kph) passes principal other LV travelling at 40 kph in adjacent lane, in curve

* 10

9 SV 100 kph passes between trucks travelling at 35 kph in adjacent lanes

* 10

10 SV passes roadside signs along straightaways and curves

* 10

11 SV at 100 kph approaches overpass * 10

Table 7-5: Summary of object test scenarios

Parameters for test 1 – test 12 and coefficient for weighing out-of-path nuisance tests are also listed.

ISO 17361:2007

ISO 17361:2007 [17361] contains five parts: scope, normative references, terms and defini-tions, specifications and requirements, and test method. The standard also contains one an-nex on national road markings.

ISO 17362:2007 classifies LDWSs into two types with respect to vehicle speed and curve ra-dius capabilities (table 7-6).

Class Parameter

I II

Radius of curvature ≥500 m ≥250 m

Vehicle speed ≥20 m/s ≥17 m/s

Table 7-6: LDWS Classification types

The requirements are grouped into the following three categories:

• Basic requirements, requirements on basic functionality, i.e. monitor system status, detect lateral position, warn driver, and so forth.

• Operational requirements, requirements on e.g. the location of earliest and latest warning lines.

Deliverable D1.1


• Human interface requirements, requirements on warning presentation and system status indication.

The tests shall be conducted with specified environmental conditions: test track surface ma-terial (flat dry asphalt or concrete), temperature (10 ± 30 °C), lane markings (visibility), and horizontal visibility (> 1 km). Test vehicle conditions are also specified. Three different tests shall be performed:

• Warning generation test, the goal of this test is to find out if warnings are generated in curves according to curve classification. Tests shall be conducted in different curves, in different departure directions, and at different rates of departure (table 7-7). The warnings shall be issued somewhere within the earliest and latest warning lines.

Deliverable D1.1


Right curve Left curve Rate of de-parture Left departure Right departure Left departure Right departure

0 to 0.4 m/s one trial one trial one trial one trial

0.4 m/s to

0.8 m/s one trial one trial one trial one trial

Table 7-7: Warning generation tests

• Repeatability test, the goal of this test is to find out if warnings are issued within a warning zone of 30 cm on a segment of straight road for four consecutive trails. Dif-ferent departure directions and rates of departure shall be tested (table 7-8). (V1 and V2 shall be selected by the manufacturer.)

Earliest warning line

Latest warning line

Lane boundary

No warning zone

Fig. 7-46: Warning line definitions

Rate of departure Departure direction

m/s Left Right

0.1 < (V1±0.05) < 0.3 four trials four trials

0.6 < (V2±0.05) < 0.8 four trials four trials

Table 7-8: Repeatability tests

• False alarm test, the goal of this test is to find out if the system produces no warnings while driving within the no warning zone for a straight course total distance of 1000 m.

ISO/DIS 17387

Deliverable D1.1


The Lane Change Decision Aid System (LCDAS) is intended to warn the driver of the subject vehicle against a potential collision with target vehicles moving in the same direction during a lane change manoeuvre. The LCDAS operates as a supplement to the interior and exterior rear-view mirrors of the vehicle; it does not eliminate the need for driving mirrors.

The LCDAS shall detect vehicles to the rear and sides of the subject vehicle within the cov-erage zone (refer to next figure). By indicating the desire to make a lane change, the subject vehicle driver causes the LCDAS to evaluate the situation. The LCDAS delivers a warning if a lane change is not recommended.

The LCDAS is not intended to support aggressive driving and hence the absence of warning does not guarantee a safe lane change manoeuvre. The system does not provide automatic action to prevent a possible collision. The responsibility for the safe operation of the vehicle remains with the driver.

TargetVehicle

TargetVehicle

SubjectVehicle

TargetVehicle

Left Adjacent Zone

Right Adjacent Zone

Left Rear Zone

Right Rear Zone

Lateral Clearance

Lateral Clearance

Rear Clearance

Rear Clearance

Fig. 7-47: LCDAS Concept

Classification

The standard specifies system requirements and test methods for LCDAS. LCDAS are clas-sified by minimum required coverage in Type I Systems, Type II Systems, Type III Systems according to table 7-9.

Deliverable D1.1


Type Left Right Left Rear Right Rear Function

I X X Blind Spot

II X X Closing

III X X X X Lane

Table 7-9: Coverage Zone Classification

LCDAS of type II and III are classified by the maximum target vehicle closing speed and the

minimum roadway radius of curvature as shown in table 7-10.

Type Maximum target vehicle Minimum Roadway Radius

A 10 m/s 125 m

B 15 m/s 250 m

C 20 m/s 500 m

Table 7-10: Target Vehicle Speed Classification

Functional requirements

LCDAS state diagram

LCDAS shall at minimum operate according to the state diagram of next figure:

Activation criteria met

Activation criteria not met

LCDAS inactive

WarningLevel 2

and above

LCDASActive

Non-Warning

WarningRequirements

fulfilled

WarningRequirements

Not fulfilled

Warning

Warning level 1

Evaluation criteria not

met

Evaluation criteria met

Fig. 7-48: LCDAS state diagram

System performance

Deliverable D1.1


The LCDAS shall fulfil:

Minimum Detectable Target Vehicle

Requirements for the Blind Spot warning Function

• Left Side Blind Spot Warning Requirements

• Right Side Blind Spot warning requirements

• Optional Blind Spot Warning Suppression

Requirements for the Closing Vehicle Warning Function

• Left side closing vehicle warning requirements

• Right side closing vehicle warning requirements

• Optional dual side closing vehicle warning

Requirements for the Lane Change Warning Function

• System response time

• User interface

• LCDAS inactive indication

• LCDAS active indication

• LCDAS warning indication

• LCDAS failure indication

• Operation with trailers

• Self-test requirements

The standard also specifies test requirements. These requirements include environmental conditions, blind spot warning test requirements and lane change warning test requirements.

FMVSS 126

The US National Highway Traffic Safety Administration (NHTSA) has published the Federal Motor Vehicle Safety Standard (FMVSS) No. 126, on Electronic Stability Control Systems, in April 2007. This document requires new passenger cars, multipurpose passenger vehicles, trucks, and buses with a gross vehicle weight rating of 4,536 kg (10,000 pounds) or less, to be equipped with an ESC system that meets the requirements of the standard. Vehicles must be equipped with an ESC system which fulfils the definition of an ESC system, and must also pass a test.

Deliverable D1.1


An ESC system must be capable of applying brake torques individually to all four wheels, and have a control algorithm utilizing this capability. The control algorithm has to be opera-tional during all phases of driving including acceleration, coasting and deceleration, expect when the driver has disabled the ESC. The ESC system must also be capable of detecting and warning of system malfunctions.

Test execution

Each manoeuvre should be performed as follows:

• initial straight line at constant velocity @ 80 km/h (duration > 2sec)

• dropped gas pedal on straight line (duration 1sec)

• steering wheel actuation with dropped gas pedal (see graph below)

• final straight line at constant velocity or with vehicle stopped (duration > 2sec)

The complete test procedure requires:

• definition of the reference steering wheel angle SWA_ref, i.e. the steering wheel an-gle needed to reach a lateral acceleration of 0.3g in a slowly increasing steer ma-noeuvre at a constant vehicle speed of 80 km/h

• steering wheel actuation with the following features:

- steering wheel angle amplitude = L x SWA_ref with L = 1.5, 2.5, 3.5, 4.5, 5.5, 6.5

- highest steering wheel angle amplitude = 270 deg or 6.5 x SWA_ref whichever is greater

- frequency of actuation = 0.7 Hz

- dwell duration after 1.07sec (Dt_dwell) = 0.5sec

Deliverable D1.1


Fig. 7-49: Sine with dwell

Data Evaluation

The main parameters to be evaluated, following indications of NHTSA, are:

• yaw rate at 1sec after steering wheel input has finished (Stability Metric)

• lateral displacement at 1.07sec after steering wheel input has started (Responsive-ness Metric)

Other useful parameters are:

• peak values of lateral acceleration

• peak values of yaw rate

• peak values of sideslip angle

The test will verify the requirements for lateral stability and responsiveness performance. The lateral stability is verified by yaw rate thresholds. The yaw rate measured one second after completion of a 0.7 Hz ``sine with dwell steering input'' manoeuvre must not exceed 35 per-cent of the first peak value of yaw rate recorded after the steering wheel angle changes sign (between first and second peaks) during the same test run, and the yaw rate measured 1.75 seconds after completion of the same manoeuvre must not exceed 20 percent of the first peak value of yaw rate recorded after the steering wheel angle changes sign (between first and second peaks).

Deliverable D1.1


The responsiveness of the vehicle is verified by the lateral displacement. The lateral dis-placement of the vehicle centre of gravity with respect to its initial straight path must be at least 1.83 m (6 feet) for vehicles with a GVWR of 3,500 kg (7,716 lb) or less, and 1.52 m (5 feet) for vehicles with a GVWR greater than 3,500 kg (7,716 lb) when computed 1.07 sec-onds after the Beginning of Steer (BOS) at specified commanded steering wheel angles.

The “Sine with dwell” test uses a steering robot maintaining a reasonable level to produce a single 0.7Hz sine wave with a half second steering angle hold between the third and fourth quarter cycles. The test is performed at 80 km/h (50 mph) with no throttle application and on dry ground. The test focuses on oversteer mitigation because it is believed to prevent more crashes than understeer mitigation.

ISO 7401:2003

Test execution

The manoeuvre should be performed as follows:

• more then 2sec of initial straight line at constant velocity @ 100 km/h in IV gear (if not differently specified)

• step steer input (SWA_nom) with steering wheel angle gradient higher then 300 deg/s and then steering wheel value SWA_nom kept fixed for at least 5sec

• final offset on straight at constant speed or with vehicle stopped (duration > 2sec)

The manoeuvre can be performed either maintaining a fixed gas pedal position during the steering wheel actuation or dropping the gas pedal 1sec before the start of the steering wheel actuation.

Suitable steering wheel amplitudes could be defined as follow:

• definition of the reference steering wheel angle SWA_ref, i.e. the steering wheel an-gle needed to the 85 % of maximum lateral acceleration value in a slowly increasing steer manoeuvre at a vehicle speed of 100 km/h (steering wheel gradient = 30-60 deg/s, fixed gas pedal position)

• use of steering wheel angle amplitudes SWA_nom = L x SWA_ref with L = 1, 1.1, 1.2, … 2.

Data evaluation

The parameters evaluated in this manoeuvre are related to yaw rate, sideslip angle and sideslip rate. They are:

Deliverable D1.1


• First peak

• Difference between second and first peak

• Time of the first peak

• Time lag between first and second peak

• RMS value after 1sec from the beginning of the steering wheel input

• RMS value after 2.5sec from the beginning of the steering wheel input

ISO 21994:2007

Test execution

In this case there of uniform adherence level on left and right wheels, the manoeuvre should be performed as follows:

• 2sec of initial straight line at constant velocity (100 km/h if not differently specified)

• Step brake pedal input (panic stop) with clutch pedal down until vehicle stops with steering wheel angle fixed at 0 deg

• Final offset (duration > 2sec)

Adherence level could be chosen on the basis of the investigation to do

In this case of different adherence level (high - low) between left and right wheels, the ma-noeuvre should be performed as follows:

• 2sec of initial offset straight line at constant velocity (100 km/h if not differently speci-fied)

• Step brake pedal input (panic stop) with clutch pedal down until vehicle stops

• Steering wheel correction by driver is allowed in order to keep one side of the vehicle with the two wheels on low adherence

• Final offset (duration > 2sec)

Data evaluation

The parameters evaluated in this manoeuvre are:

• Stopping distances according to ISO 21994

• Peaks, mean values and jerk of longitudinal deceleration

• Yaw rate and steering wheel variations in the case of mu-split

• Analysis of pressure and slip on each corner

Deliverable D1.1


ISO 7975:2006

Test execution

In this case the manoeuvre requires an initial steady-state part on constant radius with con-stant vehicle speed. The manoeuvre should be performed as follows:

• Initial offset straight line at constant velocity (duration > 2sec)

• Drive the vehicle on a constant radius of 100 m reaching a steady-state lateral accel-eration of 0.5 g (about 80 km/h)

• Step brake pedal inputs from a longitudinal deceleration of 0.4g to the limit (panic stop) with clutch pedal down. Steering wheel angle must be kept fixed in the initial steady-state position

• Final offset in straight line condition or with stopped vehicle (duration > 2sec)

Data evaluation

The parameters evaluated in this manoeuvre are:

• Stopping distances according to ISO 21994

• Peaks, mean values and jerk of longitudinal deceleration

• Yaw rate and steering wheel variations

• Analysis of pressures and slips on each corner

NHTSA DOT HS 810 757

The U.S. Department of Transportation is working together with industry to accelerate the deployment of ICT-based safety systems under the Integrated Vehicle-Based Safety System (IVBSS) programme. The IVBSS initiative will build and field test prototypes of safety sys-tems. This will require objective test procedures to verify that the IVBSS prototypes meet their performance specifications and are safe for use by ordinary drivers.

There is a report [810757] recommending a basic set of crash imminent test scenarios for in-tegrated vehicle-based safety systems designed to warn the driver of an impending rear-end, lane change, or run-off-road crash. The scenarios are selected based on the U.S. 2000-2003 General Estimates System (GES) crash databases.

Four dominant scenarios account for 97% of light-vehicle rear-end crashes and 95% of heavy truck rear-end crashes. These four scenarios are recommended as base test scenar-ios for the rear-end crash warning function:

Deliverable D1.1


1. Subject vehicle changes lanes and encounters a stopped lead vehicle ahead in daylight, clear weather, on straight and level road.

2. Subject vehicle is moving at constant speed and encounters a lead vehicle moving at slower constant speed in daylight, clear weather, on straight and level road

3. Subject vehicle is following a lead vehicle at constant speed and then lead vehicle suddenly decelerates in daylight, clear weather, on straight and level road

4. Subject vehicle is moving at constant speed and encounters a stopped lead vehicle in daylight, clear weather, on straight and level road

Four dominant scenarios account for 65% of light-vehicle lane change crashes and 76% of heavy truck lane change crashes. These four scenarios are recommended as base test sce-narios for the lane change crash warning function:

1. Subject vehicle changes lanes to the right and encroaches on an adjacent vehicle in daylight, clear weather, on straight and level road.

2. Subject vehicle passes to the left and encroaches on an adjacent vehicle in day-light, clear weather, on straight and level road.

3. Light vehicle turns left at 20-40 mph (heavy truck turns right at 15-35 mph) and en-croaches on an adjacent vehicle going straight in daylight, clear weather, on straight and level road. (refer to next figure)

4. Subject vehicle drifts right (light vehicle at 35-60 mph and heavy truck at 35-55 mph) and encroaches on an adjacent vehicle in daylight, clear weather, on straight and level road.

Fig. 7-50: Definition scenario where vehicle turns left and encroaches on adjacent vehicle [810757]

Five dominant scenarios account for 63% of light-vehicle lane change crashes and 83% of heavy truck run-off road crashes. These five scenarios are recommended as base test sce-narios for the run-off road countermeasures:

Deliverable D1.1


1. Subject vehicle is going straight and departs road edge to the right in daylight or darkness, clear weather, on straight and level road.

2. Subject vehicle is going straight and departs road edge to the left in daylight or darkness, clear weather, on straight and level road

3. Subject vehicle is negotiating a curve and departs road edge to the right in daylight or darkness, clear weather, on sloped road.

4. Subject vehicle is negotiating a curve and loses control in daylight, clear or adverse weather, on sloped road.

5. Subject vehicle is turning left at an intersection and departs road edge to the right in daylight, clear weather, on straight and level road.

Situations can occur, when threats are combinations of the previously presented crash immi-nent test scenarios for rear-end, lane change, and run-off-road crashes. These five scenarios evaluate the capability of the integrated system to issue crash alerts in near simultaneous threat events:

1. Subject vehicle is moving at constant speed and encounters a lead vehicle moving at lower constant speed, subject vehicle then attempts to pass to the left adjacent lane occupied by another vehicle.

2. Subject vehicle is moving at constant speed and encounters a stopped lead vehi-cle; subject vehicle then attempts to change lanes to the right adjacent lane occupied by another vehicle.

3. Subject vehicle drifts and is about to unintentionally depart to the right adjacent lane occupied by another vehicle.

4. Subject vehicle drifts and is about to unintentionally depart to the left adjacent lane occupied by another vehicle.

5. Subject vehicle is following a lead vehicle at a constant speed on a straight road, both driving too fast for the upcoming curve; and then lead vehicle suddenly deceler-ates.

The first annual report of IVBSS [810842] gives a suggestion for verification test procedures. These procedures are scenario-based and fall into two broad categories; closed-courses test track and on-road tests. They are intended to use at qualification of the safety functions de-veloped in the program.

There are twelve rear-end crash threat scenarios. One of the test scenarios is intended to verify the appropriateness of an FCW when a vehicle approaches, from behind, a slower moving vehicle in the centre of the same lane. In this test the vehicles are travelling at a con-

Deliverable D1.1


stant speed with a speed differential between them of at least 8.9 m/s (20 mph). (refer to next figure).

Fig. 7-51: Rear-end crash scenario1 [810842]

There are: ix lane change threat scenarios; seven road departure crash threat scenarios; three multiple-threat scenarios, and eight no-warn threat scenarios. The no-warn tests are designed to verify that the system does not issue warnings that the driver might perceive as false or nuisance alarms.

The IVBSS first annual report [810842] also lists tests for human factors. These test include

• Auditory warning selection

• Time course for various test conditions

• Shared warnings

• System time or Accuracy Trade-off

• Co-Occurring Warnings

7.1.2.2 Other Projects

ASTE summary

Performance testing and important dimensions of testing of active safety systems

In ASTE functional performance of an Intelligent Vehicle Safety System was represented by the dimensions presented in next figure, where the methods proposed by ASTE addressed

Deliverable D1.1


specific target scenarios and technical performance testing and HMI testing was concluded to be two parts of the evaluation. For HMI testing a set of important dimensions was con-cluded

• Time frame of test; short term testing vs. long term

• Intended effects and unintended effects

• Level of intervention of the function and on what action level the system supports the driver (operational, tactical or strategical, levels proposed by Michon). Michon defined a three-level model of the driving task where a distinction was made between strate-gic level (e.g general trip planning), tactical level (e.g the decision to overtake another vehicle) and the operational level (e.g. pressing/releasing the throttle). See further Ref [Michon85]

Performance testing

Testing during normal driving Testing in target scenarios

Technicalevaluation

HMI evaluation

HMI evaluation

Long termunintended

effects

Long termintendedeffects

Shorttermunintended

effects

Shorttermintendedeffects

Shorttermunintended

effects


Long termunintended

effects

Long termintended

effects

Long termunintended

effects


Shorttermunintended

effects


Short termunintended

effects


Long termunintended

effects


Technicalevaluation

Fig. 7-52: The dimensions of performance testing proposed in ASTE.

For a potential performance testing program, short term testing of intended effects for all level of system intervention should be the focus.

System based vs Scenario based approach:

With the scenario-based approach you start from accident databases to make assumptions

on the most relevant and critical accidents in order to develop test methods for these situa-tions. The advantage here is that the focus is the most crucial accident types, derived from real world accident data. Thus performance will be evaluated in traffic scenarios, not adapted to specific function. However, an important difficulty is the level of detail on which accident data is available today and the various ways accident statistics is presented. It is very difficult

Deliverable D1.1


to retrieve sufficient facts on accident data to make good assumptions on the most relevant accident types, in favour of others. To choose the most representative accident types or to decide which the most crucial accident types to address are puts high demands on the knowledge on causation of accidents, the frequency of accidents and the outcome of it. This approach might lead to that certain systems are found to contribute more than others in in-creasing safety in the particular situations addressed, which might stimulate development of these systems. It is then important to know that the accident types selected are the most rep-resentative ones.

With the system-based approach you define traffic scenarios for specific systems, where

each system is assigned to certain traffic scenarios. The system-based approach will face the similar difficulty in defining the most representative traffic scenarios among available ac-cident data, as for the scenario-based approach, but the scope is narrowed due to the fact that the most relevant accident types, applicable for a certain system is searched. A conse-quence here is that the accident types are not prioritized or ranked after criticality or impor-tance to end up in a few general test scenarios, independent of all safety systems. Instead all systems are assigned a set of relevant traffic scenarios, based on accident statistics, where the traffic scenarios are more specific and adapted to the systems they are addressing.

In ASTE the scenario-based approach was proposed, with the idea that this approach is general; not adapted to specific systems. Furthermore it should be robust for new future technologies and interaction of two or more systems. Also since the scenarios selected are not adapted to specific systems it might stimulate development for new systems with different types of technology solutions to increase safety in these particular scenarios.

Specification of test scenario

A proposal on how to present and break down a traffic scenario was provided in matrix for-mat in ASTE, of which an example is inserted below:

Accident type Driver state Degree of interaction

Light condition

Road state Traffic environment

Type of road Speed restrictions

Weather condtion

Rear-end collision Vehicle in front brakes

Alert driver Inform Daylight Dry road Urban Main road 50 Dry

Rear-end collision Forward collision with stationary object/parked car

Drowsy driver Support Dark Wet road Non-urban Street 70 Rain

Rear-end collision Own vehicle accelerates

Distracted driver

Intervene Thin icelayer

Highway 90 Snow

Table 7-11: Breakdown of traffic scenarios proposed in ASTE

PReVAL summary

Deliverable D1.1


In a recently published deliverable from PReVAL [PReVAL2] a methodology for evaluating the technical performance of a function and a methodology for evaluating human factors i.e the function’s interaction with the driver is proposed. The term “human factors evaluation” was adopted in PReVAL and included evaluation of the user’s comprehension of the HMI e.g. acceptance and usability and the functions influence of driver behaviour and driving per-formance. The two methodologies for evaluation of technical performance and human factors will be integrated into one holistic framework, which will be presented in the PReVALs final report, D16.4, not yet published.

The evaluation methodologies derived was mainly aimed for supporting evaluation in re-search projects like PReVENT, and addressed evaluation to be done during the later stage of the projects, thus addressing functional verification and validation (terms inherited from Response project, refer to chapter 5 Glossary and Acronyms). Technical evaluation methods were mainly developed to see whether the function met its specification while human factors, including subjective measures like usability and acceptance as well as objective measures of driving performance and driver behaviour, addressed whether the overall driver – vehicle re-sponse was in agreement with the intended system effects – did the function do what it is in-tended to do?

Situational control

The background for this concept is the aim a preventive safety function have; to increase safety in a particular traffic situation. However the definition of safety is very subjective and there is a need for a general definition on how to describe the system effects, in a scientific way, for translation into safety. This concept would then be generic for various situations and systems. An approach developed within PReVAL was to represent safety by the degree of control in a certain situation; situational control.

Evaluation methodology

For the technical evaluation an adapted version of the established V-model was used in PReVAL, addressing verification and validation, according to the figure below. The evalua-tion methodology for human factors addressed validation and followed the V-model. The de-tailed procedure is presented to the left of the same figure below.

Deliverable D1.1


Fig. 7-53: A framework suggested for technical performance testing, adapted to V-model (to the right), and the corresponding procedure for human factors evaluation (to the left) proposed in PReVAL

The common base for human factor and technical evaluation is to define the systems, and use cases directly from the system descriptions. For technical performance key indicators re-flecting the requirements, correct alarm rate (CAR), false alarm rate (FAR), correct percep-tion and actuation (e.g. timing of warning) is addressed. In human factors a key issue is to define hypothesises on intended effects with representative indicators. A consecutive step was then to define detailed traffic scenarios and to selects appropriate test methods and test environments.

An indicator reflecting technical performance can for instance be timing of warning issued. An indicator on human factor performance could for instance be reaction time. An indicator for overall response could be the overall time of a lane excursion.

A final report will be delivered in PReVAL, with a framework integrating the technical and human factors evaluation, which is currently not yet public.

AIDE summary

Below some of the methods presented and discussed in AIDE, applicable for evaluation of both IVIS and ADAS are presented.

Acceptance

Deliverable D1.1


• Van der Laan acceptance scale – is measuring usefulness and satisfaction. Van der Laan, J.D., Heino, A., & De Waard, D. (1997).

Usability

• Usability Questionnaire

• Think aloud protocol (J. Nielsen "Usability Engineering", pp 195-198, Academic Press, 1993)

• SUS: The System Usability Scale (SUS) is a simple, ten-item scale giving a global view of subjective assessments of usability. The SU scale is generally used after the respondent has had an opportunity to use the system being evaluated, but before any debriefing or discussion takes place. Respondents should be asked to record their immediate response to each item, rather than thinking about items for a long time. Brooke, J. (1996)

Driver Workload

The level of workload that drivers have to cope with has to be compared between the ‘old’, unsupported, situation and the situation in which the system assists them. Workload can be measured in several ways, each of them focusing on different aspects of the driving task.

“Objective” workload measures: PReVAL D 16.1

• VDM (Visual Demand Measurement) tool. This permits a fast and efficient measure-ment and analysis of visual glance patterns, in particular whether glances are on the road or on a display inside the vehicle.

• PDT (Peripheral Detection Task) tool. This permits estimating the workload of the primary driving task from a driver’s performance level on a secondary task, which is the quick and correct detection of events in the form of artificial stimuli generated at random moments in time.

• Primary task performance measurement. The quality with which the driving task itself is performed may also be used to estimate workload. Steering wheel parameters have been identified as the most promising in this respect, and a new parameter (steering wheel reversal rate) has been found to be maximally discriminative.

“Subjective”/ self-reported workload measures - estimation scales (AIDE 2.2.1)

• One-dimensional scales: rely on one dimension to assess workload. (MCH-scale, RSME, OW)

• Multi-dimensional scales: assess more than one aspect of workload. (NASA-TLX, PSA-TLX, SWAT, DALI)

Situation awareness measures

Deliverable D1.1


Situation Awareness (what is going on in the environment and what is going to happen in the nearest future). SA is related to workload. A high SA might lower the workload and a high level of workload can lead to low SA. BUT it is not necessarily true.

• It is important to assess workload and SA separately

• Performance is NOT a function of SA BUT the more complete SA, the higher the probability to have high performance measures.

SA can be assessed in terms of self-reported measures and in terms of performance meas-ures.

Self-reported SA measures

• SART scale – to be used in combination with performance measures.

• SAGAT technique – to be used in simulator.

Performance measures

• Global measures – rely on task accomplishment by subjects

• Embedded task measures – consider specific measurements for the system being tested, e.g. deviation from reference values in steering wheel.

• External task measures – examine subject reactions to changes to or removal of in-formation relevant to the task at hand.

• Testable responses or impact measures – serve to eliminate ambiguity of Global measures. Extremely controlled experimental conditions.

When measuring SA it is interesting to create abnormal behaviour situations e.g. a car break-ing abruptly, a pedestrian crossing where not allowed.

APROSYS SP6 Summary

Sub-project 6 of the European funded project APROSYS has developed two different innova-tive technologies: shape memory alloy actuators and a pre-crash sensing system observing the side of a vehicle. As a technology showcase, these have been put together into an inte-grated system for side impact protection.

After evaluating accident statistics, various concepts for side impact protection were studied in multi-body and finite elements simulations. Also human behaviour in side crashes was ex-amined. Accordingly, the sensor and actuator systems were defined, developed and inte-grated into several vehicles. A thorough evaluation programme has tested sensor and actua-tor system. The sensor system consists of the fusion of 24 GHz radar sensors with a stereo video camera. The actuator was kept generic, so that it could be built into any vehicle.

Deliverable D1.1


Sensor system evaluation: Field test and track tests

A SP6 field test was organised and planned as a five day trip on European roads (France, It-aly, Austria, Germany) with the intention to record as much as possible real world and also typical regional traffic scenarios, infrastructure or other specific objects or situations.

For this, the experimental vehicle has been equipped with an additional camera and data re-cording system. An observation vehicle with another camera system escorted the vehicle under test for the complete test distance and kept records from the total traffic scene.

Finally, 67 trigger events were recorded and classified as “false”, “plausible” or “acceptable”. In a development process these results would lead in an optimisation of the decision algo-rithms – for an end user oriented assessment the alarm rate has to be discussed in connec-tion with the actuator functionality.

The field test was complemented with driving test on a test track to qualify again the sensor system in terms of a false alarm rate in specific non accident but challenging traffic situations (“near misses”).

Sensor system evaluation: Impact detection tests

To be able to verify the sensor system pre-crash tests have to be done to assess the time-to-collision small enough to trigger the system. Test conditions are derived from seven scenar-ios based on accident analysis, taking into account the possible limitations from the test facil-ity and the implications on the expected system effectiveness.

APROSYS Pre-Crash systems Generic Test methodology

APROSYS, Advanced Protection systems, developed its testing method for assessment of pre-crash systems in WP 1.3. The generic methodology is split into 5 main phases; General system information, Field of application, General System information, Evaluation technical performance and finally, Assessment. These phases have been carefully considered and de-vised to be completed in the respective order, so as to achieve a complete and effective process for the assessment of pre-crash systems.

General System information:

This is the first phase, involving the initial System description of the pre-crash system under assessment, followed by the start of application category for this system.

Field of application:

Deliverable D1.1


Completes the step of applying category to the system, and then focuses on the Typical traf-fic and accident scenarios which is done with the use of already known statistics and real world data available.

Side impact represents a large part of all the vehicle accidents. Most common are the side to front and side to pole situations. The EACS accident database was used to investigate these situations in more detail. Based on the accident analysis work the test parameters were de-fined for both the sensor as for the actuator system as well as the pre-crash test scenarios.

Specific system information:

This third step, like the initial step in the methodology is based upon gathering the informa-tion of the pre-crash system being assessed. At this stage however emphasis is placed upon the system objective i.e. what it has been designed to achieve when implemented.

Evaluation Technical Performance:

This phase consists of several steps, which will ultimately be combined at the end to com-plete the final assessment. The focus at this stage in the methodology is now on the actual testing and technical performance of the system under review.

The first step here is the Definition of specific test conditions and assessment criteria, mean-ing that the information gathered so far is reviewed, and based upon this the needs for as-sessment are defined. These evaluations of Technical performance fall into three main cate-gories

• Pre –Crash performance is the next assessment stage, conducted with all systems.

• Crash performance is an assessment step leading on from the Pre-crash perform-ance, not applied to all pre-crash systems, but conducted when deemed relevant in the previous definition stage.

• Driver in the Loop performance, is a separate stage of evaluation conducted along-side a and b. It is not always performed in the testing process, however when deemed necessary in conjunction with the consideration of the pre-crash system ob-jective, and possible scenarios it is included in the evaluation process.

Assessment:

The final stage where in all the information and data from the latter phases are compiled and put alongside each other for consideration so as to come to a conclusion regarding the Overall system performance. This includes:

Deliverable D1.1


• All of the relevant supporting information gathered in phases 1 through 3, specifically what it is that the system should be able to achieve and its requirements that must be considered.

• All of the technical performance evaluations conducted after the definition stage. This will include:

a) Pre-Crash performance

b) Possibly Crash performance

c) Sometimes Driver-in-the-loop performance

Deliverable D1.1


7.2 Scope of eVALUE

7.2.1 Adaptive Cruise Control (ACC)

Functional specifications of ACC

Main use-cases In free traffic on the motorway (ACC) In Stop&Go situations on the motorway (ACC S&G)

Major technology Perception: Current solutions are using information ob-

tained long and/or short range radar or lidar sensors

possible in combination with a video camera.

On detection level the function identifies target vehicles in the vehicles driving lane.

The system reduces the subject vehicle velocity by

braking and accelerates the vehicle in order to keep

desired velocity. The driver is warned in case the nec-

essary deceleration cannot be performed by the sys-tem. Informative/Advisory/Warning

■ Support

Function output

Autonomous intervention

Strategical

Tactical

Level of driver support

■ Operational

Intended benefits with function To support drivers on monotonous tasks of vehicle

guidance at a constant velocity. Velocity adaptation and following target vehicle in safe distance.

Intended driver behaviour Drivers control the system and react to warnings and

take over longitudinal vehicle control in critical situa-

tions

Time schedule The time gap (following distance depending on veloc-

ity) can be adjusted by the driver

Function classification of ACC

Type of target object for detection Vehicles ahead of subject vehicle

Urban

■ Rural roads (partly)

Road types

■ Highway

Road section type All motorways (without entrance and exit ramps)

Function limitations of ACC

Vehicle requirements Interaction with engine controller and brake system re-

quired

Traffic environment requirements Independent from traffic environment

Deliverable D1.1


Function limitations of ACC

Infrastructure requirements Independent from infrastructure

■ Adverse (Rain): functionality independent from rain

condition with modern distance sensors

■ Adverse (Snow): functionality dependent on senor type

■ Adverse (Ice on road): functionality independent from

friction coefficient between road and tyre ■ Adverse (Fog): functionality dependent on senor type

Weather that function should work well in

■ Normal: functionality given in normal weather condi-

tions

■ Dark: functionality independent from light condition Lightning condition the function should work well in

■ Light: functionality independent from light condition

Description of subsystems for ACC

Sensors Distance sensor (radar, lidar or laser scanner)

Yaw rate sensor for curve prediction (included in modern

distance sensors)

Vehicle velocity sensor Vehicle acceleration sensor

Actuators • Brakes

• Engine

HMI design detail Activation/deactivation control

Adjustment of desired velocity (set speed)

Time gap adjustment

Loudspeaker for driver warning Display/LED for set speed visualisation

ACCSUBJECT, speed



SUPPORT, braking

INPUTS OUTPUTS

AUTONOMOUS INTERVENTION, acceleration and braking



ACC sensors will measure: subject vehicle speed, distance from subject to target vehicle and relative speed of target vehicle.

ACC actuators will accelerate or brake the subject vehicle automatically.

Deliverable D1.1


Subject vehicle speed Engine or wheel (active/pasive) speed sensor

LIDAR, far distance range laser radar up to 200m

77 GHz LRR, forward detection up to 200 m

24 GHz SRR, forward detection up to 40 m. full speed range (30 - 200 km/h)Limited use of vision CMOS forward looking camera, mounted behind rear-view mirror.

Radar and vision fusion: SRR (56º FOV, 65m DOV) and LRR (17º FOV, 200 m DOV) with dual-CMOS (50º FOV, 150m with follow-through to 200m DOV)

IR LIDAR sensor fusion

IR SRR sensor fusionIR makes it a lon-range cheaper solution and SRR for closed distance measurements

Subject vehicle dynamics

Yaw rate sensorSteering angle sensorAcceleration sensorOther sensors depending on OEM

Distance and relative speed between subject and target vehicle

Adaptive Cruise Control (ACC)

SENSOR INPUT TECHNOLOGIES (current / trends)

Fig. 7-54: ACC sensors: technologies

Warning: HapticVibration actuators in contact with driver (seat belt, seat, steering wheel)

Warning: Visual Display mounted on cockpit

Warning: Acoustic Gradual sound alert

Hydraulic brake

Electric brake

Electrical throttle

Camless valvetrain

Hydraulic brake

Electric brake

Adaptive Cruise Control (ACC)

FUNCTION OUTPUT SYSTEM REACTION (current / trends)

Support: Brake (warm braking)

Autonomous Intervention: Engine

Autonomous Intervention: Brake

Fig. 7-55: ACC actuators: function outputs

ACC ECU

In order to have a top-down structure about functionalities carried out by ACC system, the following “high level functions” (HLF) has been defined to be detailed in “Detailed functions” section:

HLF-ID Requirement Statement

Deliverable D1.1


HLF_ACC_01 Maintain subject vehicle speed.

HLF_ACC_02 Keep safe distance with target vehicle

Fig. 7-56: ACC high level functions

The following detailed functions are coming from the above HLF to help in future test meth-ods definition taking each detailed function into account:

DF-ID Requirement Statement Description Source

DF_ACC_01 Curve detection.

Identify the curves on the road based on information of: steering angle sensor, vehicle yaw rate sensor and speed wheels sensors.

HLF_ACC_02

DF_ACC_02 Target vehicle detection

Determine any vehicle in front is in the same lane as the subject vehicle based on sensor information (LIDAR, LRR or SRR) and the result of curves de-tection.

HLF_ACC_02

DF_ACC_03 Speed control Algorithm of subject vehicle speed control. HLF_ACC_01 HLF_ACC_02

DF_ACC_04 Distance control Algorithm of subject vehicle distance control HLF_ACC_02

DF_ACC_05 Command powertrain system Command instructions for subject vehicle accelera-tion as result of distance control and speed control.

HLF_ACC_01 HLF_ACC_02

DF_ACC_06 Command brakes Command instructions for subject vehicle brakes as result of distance control and speed control.

HLF_ACC_02

DF_ACC_07 System Management System management and self-diagnostic functions. HLF_ACC_01 HLF_ACC_02

Fig. 7-57: ACC detailed level functions

Deliverable D1.1


7.2.2 Forward Collision Warning (FCW)

Functional specifications of FCW

Main use-cases The subject vehicle approaches another vehicle from behind with a speed and distance to which the risk of a

rear-end collision of the other vehicle is high. A preven-

tive action; braking or steering manoeuvre is required to

avoid the collision.

Major technology Perception: Current solutions are using information ob-tained long and/or short range radar sensors or lidar

sensors possible in combination with a video camera.

On detection level the function identifies potential colli-

sion targets in the vehicles field of view.

If a collision is imminent the action from the function is to warn the driver by issuing an auditory and/or visual

warning.

■ Informative/Advisory/Warning

Support

Function output


Strategical

■ Tactical


Operational

Intended benefits with function To support drivers in situations where a rear-end colli-sion/forward collision is imminent. The intended benefit

of the function is to avoid or mitigate frontal/rear-end

collisions by issuing a warning with aim to focus the

driver´s attention to the critical situation and take an ac-

tion.

Intended driver behaviour Drivers react to the issued warning and respond by

braking and/or steering away.

Time schedule The system acts within a few seconds before an actual

incident.

Function classification of FCW

Type of target object for detection (Moving) vehicles

■ Urban

■ Rural roads

Road types

■ Highway

Road section type Straight roads

Deliverable D1.1


Function limitations of FCW

Traffic environment requirements

Infrastructure requirements

■ Adverse (Rain)

Adverse (Snow)

Adverse (Ice on road)

Adverse (fog): depending on sensor technology


■ Normal

■ Dark Lightning condition the function should work well in

■ Light

Other limitations Function is active only in a certain speed range

Description of subsystems for FCW

Sensors Short and long range radar, video camera + image processing,

Actuators • Acoustic warning

• Visual warning

HMI design details -

FCW WARN, on precautious actions

INPUTS OUTPUTS

SUBJECT, speed




FCW sensors will measure: subject vehicle speed, distance from subject to target vehicle and relative speed of target vehicle.

FCW actuators will warn the driver using visual, acoustic or haptic warnings.

Deliverable D1.1




77 GHz LRR, forward detection up to 200 m

24 GHz SRR, forward detection up to 40 m. full speed range (30 - 200 km/h)Limited use of vision CMOS forward looking camera, mounted behind rear-view mirror.



IR SRR sensor fusionIR makes it a lon-range cheaper solution and SRR for closed distance measurements




Foward Collision Warning (FCW)


Fig. 7-58: FCW sensors: technologies




Forward Collision Warning (FCW)

FUNCTION OUTPUT SYSTEM REACTION

Fig. 7-59: FCW actuators: function outputs

FCW ECU

In order to have a top-down structure about functionalities carried out by FCW system, the following “high level functions” (HLF) has been defined to be detailed in “Detailed functions” section:

HLF-ID Requirement Statement HLF_FCW_01 Detect a target vehicle in the travel lane.

HLF_FCW_02 Warn the subject vehicle driver with sufficient time to avoid forward crashes.

Fig. 7-60: FCW high level functions


Deliverable D1.1



DF_FCW_01 Detect target vehicle

Determine if any vehicle in front is in the same lane as the subject vehicle based on sensor in-formation (LIDAR, LRR or SRR) and yaw rate sensor (optional).

HLF_FCW_01

DF_FCW_02 Measure subject vehicle speed. Determine subject vehicle speed based on in-vehicle speed sensor signal.

HLF_FCW_02

DF_FCW_03 Measure the distance to target vehicle Determine distance to target vehicle based on sensor information

HLF_FCW_01 HLF_FCW_02

DF_FCW_04 Measure relative speed to target vehicle Determine relative speed to target vehicle based on sensor information

HLF_FCW_01 HLF_FCW_02

DF_FCW_05 HMI Management. Warn the driver on precautions actions with time enough to avoid the accident. The warning can be acoustic or visual.

HLF_FCW_02

Fig. 7-61: FCW detailed level functions

Deliverable D1.1


7.2.3 Collision Mitigation (CM)

Functional specifications of CM

Main use-cases The driver and his/hers vehicle approaches another ve-

hicle from behind with a speed and distance to which the risk of a rear-end collision of the other vehicle is

high. A preventive action; braking or steering manoeu-

vre is required to avoid the collision.

Major technology Perception: Current solutions are using information ob-

tained long and/or short range radar or lidar sensors

possible in combination with a video camera. On detection level the function identifies potential colli-

sion targets in the vehicles field of view.

If a collision is imminent the action from the function is

to reduce the threshold for the brake assist system or/and to perform autonomous braking. Informative/Advisory/Warning

■ Support

Function output

■ Autonomous intervention

Strategical

Tactical


■ Operational

Intended benefits with function Reduced collision speed.

Intended driver behaviour No intended driver reaction. In case of driver imitated

braking the driver is expected to maintain the pedal pressure.

Time schedule Autonomous braking occur less than one second before

time to collision.

Activation of enhanced brake assist functionality occur

less than 2 seconds before time to collision.

Function classification of CM

Type of target object for detection First generation systems only considers movable target

e.g. target that is or has been seen to move. Second

generation systems also recognise stationary vehicles. Third generation system recognises pedestrians and pos-

sible other classes of targets

■ Urban

■ Rural roads

Road types

■ Highway

Road section type All

Deliverable D1.1


Function limitations of CM



Adverse (Rain)

Adverse (Snow)


Adverse (fog): depending on sensor technology


■ Normal

■ Dark Lightning condition the function should work well in.

■ Light

Other limitations Function is not capable of triggering timely for high rela-

tive speeds > 100 km/h

Description of subsystems for CM

Sensors Short and long range radar, lidar, video camera, IR

cameras.

Actuators • Brakes

• Engine

HMI design details Changes in the brake pedal feedback

Noise from the pump during activation

CMSUBJECT, vehicle dynamics

SUBJECT, environment description

INPUTS OUTPUTS

AUTONOMOUS INTERVENTION, braking

CM sensors will measure subject vehicle’s speed, detect an object inside subject vehicle’s environment, measure object’s speed and classify the object inside subject vehicle’s envi-ronment.

When the collision is imminent CM actuators will brake the subject vehicle to mitigate acci-dent consequences.

Deliverable D1.1




77 GHz LRR, forward detection up to 200 m24 GHz SRR, forward detection up to 40 m. full speed range (30 - 200 km/h)Limited use of vision CMOS forward looking camera, mounted behind rear-view mirror.



IR SRR sensor fusionIR makes it a lon-range cheaper solution and SRR for closed distance measurementsFIR (Far IR) camera for object classification, size and position deduction, up to 80m





Collision Mitigation (CM)

Fig. 7-62: CM sensors: technologies

Hydraulic brake

Electric brakeAutonomous Intervention: Brake

Collision Mitigation (CM)

DETAILED FUNCTIONS SYSTEM REACTION (current / trends)

Fig. 7-63: CM actuators: function outputs

CM ECU

In order to have a top-down structure about functionalities carried out by CM systems, the following “high level functions” (HLF) has been defined to be detailed in “Detailed functions” section:

HLF-ID Requirement Statement HLF_CM_01 Detect a target vehicle in the travel lane.

HLF_CM_02 Warn the subject vehicle driver with sufficient time to avoid forward crashes.

HLF_CM_03 Actuate to mitigate the impact of the crash.

Fig. 7-64: CM high level functions


Deliverable D1.1



DF_CM_01 Detect target vehicle

Determine any vehicle in front is in the same lane as the subject vehicle based on information from outside sensor (LIDAR, LRR or SRR) and yaw rate sensor (optional).

HLF_CM_01

DF_CM_02 Measure subject speed. Determine subject vehicle speed based on inside speed sensor signal.

HLF_CM_02

DF_CM_03 Measure the distance to target vehicle Determine distance to target vehicle based on in-formation from outside sensors

HLF_CM_01 HLF_CM_02

DF_CM_04 Measure relative speed to target vehicle Determine relative speed to target vehicle based on information from outside sensors

HLF_CM_01 HLF_CM_02

DF_CM_05 HMI Management

Warn the driver on precautions actions with time enough to avoid the accident. The warning can be for acoustic, visual, warn breaking, haptic.

HLF_CM_02

DF_CM_06 Activate mitigation measures

Activate accident mitigation measures when there is not time enough to avoid the accident (activate brakes, adjust seat belt, prime air-bag).

HLF_CM_03

Fig. 7-65: CM detailed level functions

7.2.4 Blind Spot Detection (BSD)

Functional specifications of BSD

Main use-cases The driver receives a visual warning when an object is in the subject vehicles blind spot.

Major technology Perception: Current solutions are using 24 GHz radars

or vision sensors to detect objects in the blind spot

zone.

Prototype systems which monitor vehicles that are rap-

idly closing in on the blind spot in the adjacent lanes have been demonstrated by the use of radar sensors.


Support

Function output


Strategical

Tactical


■ Operational

Intended benefits with function Avoid sideswipe collisions during lane change ma-

noeuvres

Intended driver behaviour Upon receiving the warning the driver is assumed to avoid lane changes target to a collision.

Time schedule The warning should be issued as soon as another ve-

hicle is in the defined blind spot zone

Function classification

Type of target object for detection No sophisticated object recognition is currently used for

blind spot detection systems. Any object may be de-

Deliverable D1.1


tected by the sensors currently used.

■ Urban

■ Rural roads

Road types

■ Highway

Road section type All

Function limitations of BSD



■ Adverse (Rain)

■ Adverse (Snow)

■ Adverse (Ice on road)

■ Adverse (fog): depending on sensor technology


■ Normal


■ Light

Other limitations

Description of subsystems for BSD

Sensors Radar or vision sensors.

Actuators Various warning displays

HMI design details Visual displays may be hard to recognise when exposed to direct sunlight.

BSD


SUBJECT’s BLIND SPOT, vehicle detection WARN, on precautious actions

INPUTS OUTPUTS


BSD sensors will detect short-range laterally oriented vehicles on subject vehicle’s blind spot and subject vehicle’s lateral movement.

BSD actuators will warn the driver using visual, acoustic or haptic warnings.

Deliverable D1.1


Subject vehicle lane change Blinker active in-vehicle sensor and/or steering angle sensor

SRR 24GHz, mounted in host's rear bumperleft/right sensing, 150-degree FOV, up to 40m.

2D CMOS camera, mounted in host's exterior rear-view mirror up to 130-degree FOV

Radar and vision fussion:SRR (56º FOV, 65m DOV) and LRR (17º FOV, 200m DOV) with dual-CMOS (50º FOV, 150m with follow-through to 200m DOV)



Blind Spot Detection (BSD)


Short-range laterally oriented objects detection

Fig. 7-66: BSD sensors: technologies




Blind Spot Detection (BSD)


Fig. 7-67: BSD actuators: function output

BSD ECU

In order to have a top-down structure about functionalities carried out by BSD system, the following “high level functions” (HLF) has been defined to be detailed in the “Detailed func-tions” section:

HLF-ID Requirement Statement

HLF_ BSD _01 Warn the subject vehicle driver when preparing for a lane change with coming vehicle in the blind spot.

Fig. 7-68: BSD high level functions



DF_ BSD _01 Detect coming vehicle in blind spot Short-range laterally oriented objects detection based on sensor information (SRR 24Ghz, 2D

HLF_ BSD _01

Deliverable D1.1


CMOS, or Radar and Vision fusion)

DF_ BSD _02 Detect subject vehicle lane change Detect the subject vehicle intention change lane based on information of steering angle sensor and/or blinker active in-vehicle.

HLF_ BSD _01

DF_ BSD _03 HMI management Warm on precautious actions. The warning can be acoustic, visual, or haptic.

HLF_ BSD _01

Fig. 7-69: BSD detailed level functions

7.2.5 Lane Departure Warning (LDW)

Functional specifications of LDW

Main use-cases Subject vehicle is going to cross lane markings unin-

tentionally, without turn indication.

Major technology System perception based on image processing. A camera located in the area of the rear-view mirror

continuously monitors the road and keep track of where

the subject vehicle is in relation to the lane markings.

The function evaluates the trajectory of the subject ve-

hicle related to the lane boundaries represented by road markings or guard rails.

System decision based on detection of an unintentional

lane departure, from computation of e.g. Time to Line

Crossing (TLC) and turning indicator signal. System action is based on TLC threshold and if turning

indication is off, the lane change is determined to be

unintended and a warning is issued to the driver. If the

turning indication is on, no warning is issued.


Support

Function output


Strategical

■ Tactical


Operational

Intended benefits with function This function is intended to reduce crashes or incidents

resulting from unintended lane departures.

To support drivers on tactical level in situations of unin-

tended lane changes for heading back in correct lane. Unintended lane changes are avoided.


steering the vehicle back to the correct lane.

Time schedule The system acts within a few seconds before an actual

departure.

Function classification of LDW

Type of target object for detection Lane markings

Road types Urban

Deliverable D1.1


■ Rural roads

■ Highway

Road section type straight roads, wide curves

Function limitations of LDW Traffic environment requirements

Infrastructure requirements Lane markings

This function may have hard time recognizing lane mark-

ing in specific situations such as under a tunnel.

■ Adverse (Rain)

Adverse (Snow)


Adverse (fog)


■ Normal


■ Light

Other limitations Function not active below certain speed threshold.

All lane markings cannot be detected. Sharp curves

Description of subsystems for LDW

Sensors Camera + image processing


• Visual warning

• Haptic warning


LDW


SUBJECT, upcoming lane marks detection WARN, on precautious actions


INPUTS OUTPUTS

LDW sensors will detect long-range longitudinal upcoming lane marks and subject vehicle’s lateral movement.

LDW actuators will warn the driver using visual, acoustic or haptic warnings.

Deliverable D1.1



Active IR, fixed number of sensors, integrated under front bumper, determine lane departure by detecting marks on the road

2D CMOS forward looking camera, mounted on interior rear-view mirror, can detect upcoming lane markings130-degree FOV

Active IR and CMOS forward looking camera fusion

Subject vehicle dynamicsSteering angle sensorAcceleration sensorOther sensors depending on OEM

Long-range longitudinal detection, for tracking lane deviation

Lane Departure Warning (LDW)


Fig. 7-70: LDW sensors: technologies





Lane Departure Warning (LDW)

Fig. 7-71: LDW actuators: function outputs

LDW ECU

In order to have a top-down structure about functionalities carried out by ldw system, the fol-lowing “high level functions” (HLF) has been defined to be detailed in the “Detailed functions” section:

HLF-ID Requirement Statement HLF_ LDW _01 Warn on precautious actions when involuntary lane departure of the subject vehicle.

Fig. 7-72: LDW high level functions


DF-ID Requirement Statement

Description Source

DF_ LDW _01 Track upcoming lane Determine upcoming lane by detecting approaching marks on the road based on sensor information (SRR 24Ghz, 2D CMOS, IR).

HLF_ LDW _01

DF_ LDW _02 Detect involuntary lane change Detect the subject vehicle involuntary lane departure based on information coming from steering angle sensor, blinker active in-vehicle and long-range longitudinal detec-

HLF_ LDW _01

Deliverable D1.1


tion, for lane tracking deviation.

DF_ LDW _03 HMI management Warm on precautious actions. The warning can be acous-tic, visual, or haptic.

HLF_ LDW _01

Fig. 7-73: LDW detailed level functions

Deliverable D1.1


7.2.6 Lane Keeping Assistant (LKA)

Functional specifications of LKA

Main use-cases Subject vehicle is going to cross lane markings uninten-tionally, without turn indication.

Major technology System perception based on image processing: A

camera located in the area of the rear-view mirror con-

tinuously monitors the road and keep track of where the

subject vehicle is in relation to the lane markings. The function evaluates the trajectory of the subject ve-

hicle related to the lane boundaries represented by

road markings or guard rails.

System decision based on detection of an unintentional

lane departure, from computation of e.g. Time to Line Crossing (TLC) and turning indicator signal.

System action is based on TLC threshold and if turning

indication is off, the lane change is determined to be

unintended and a warning is issued to the driver and a support is given by a torque in the steering wheel.

If the turning indication is on, no warning is issued.


■ Support

Function output


Strategical

Tactical


■ Operational

Intended benefits with function This function is intended to reduce crashes or incidents resulting from unintended lane departures.

To support drivers on tactical level in situations of unin-

tended lane changes for heading back in correct lane.

Unintended lane changes are avoided.


steering the vehicle back to the correct lane.

Time schedule The system acts within a few seconds before an actual departure.

Function classification of LKA

Type of target object for detection Lane markings

Urban

■ Rural roads

Road types

■ Highway

Road section type Straight roads, wide curves

Deliverable D1.1


Function limitations of LKA


Infrastructure requirements Lane markings This function may have hard time recognizing lane mark-

ing in specific situations such as under a tunnel.

■ Adverse (Rain)

Adverse (Snow)


Adverse (fog)


■ Normal


■ Light

Other limitations Function not active below certain speed threshold.

All lane markings cannot be detected.

Sharp curves

Description of subsystems for LKA

Sensors Camera + image processing


• Visual warning

• Haptic warning

• Steering actuator


LKA


SUBJECT, upcoming lane marks detection


SUPPORT, steeringSUBJECT, vehicle dynamics

INPUTS OUTPUTS

LKA sensors will detect long-range longitudinal upcoming lane marks and subject vehicle’s lateral movement.

Initially LKA actuators will warn the driver to avoid the involuntary lane changing using the haptic, visual or acoustic options, next if the involuntary lane changing is unavoidable, LKA actuators will apply a force feedback on the steering wheel that it will gradually change pro-portionally to the subject vehicle’s lateral deviation.

Deliverable D1.1



Active IR, fixed number of sensors, integrated under front bumper, determine lane departure by detecting marks on the road

2D CMOS forward looking camera, mounted on interior rear-view mirror, can detect upcoming lane markings, and host driver’s fatigue, by tracking relative lane-keeping accuracy over time 130-degree FOV, up to 25m



Lane Keeping Assistance (LKA)

SENSOR INPUT TECHNOLOGIES

Long-range longitudinal detection, for tracking lane deviation

Fig. 7-74: LKA sensors: technologies




Electric power steering (EPS)

Steer by wire, force feedback

Lane Keeping Assistance (LKA)


Support: Steering (gradual assistance)

Fig. 7-75: LKA actuators: function outputs

LKA ECU

In order to have a top-down structure about functionalities carried out by LKA system, the fol-lowing “high level functions” (HLF) has been defined to be detailed in “Detailed functions” section:

HLF-ID Requirement Statement HLF_LKA_01 Warn the driver when the vehicle begins to move out of its lane.

HLF_LKA_02 Actuate in the steering to keep the vehicle to the lane.

Fig. 7-76: LKA high level functions



DF_LKA_01 Track ahead lane Determine upcoming lane by detecting approaching marks on the road based on sensor information

HLF_LKA_01 HLF_LKA_02

Deliverable D1.1


(SRR 24Ghz, 2D CMOS, IR.), and in-vehicle sen-sors like yaw rate sensor, wheel speed sensor or steering angle sensor.

DF_LKA_02 Detect involuntary lane change Detect the subject vehicle involuntary lane depar-ture based on information of steering angle sensor, blinker active in-vehicle and ahead lane.

HLF_LKA_01 HLF_LKA_02

DF_LKA_03 HMI management Warm on precautious actions. The warning can be acoustic, visual, or haptic.

HLF_LKA_01

DF_LKA_04 Assist steering wheel force Autonomous intervention management of the steer-ing wheel.

HLF_LKA_02

Fig. 7-77: LKA detailed level functions

7.2.7 Antilock Brake System (ABS)

Functional specifications of ABS

Main use-cases Heavy braking or braking on low friction surfaces

Braking on different friction surfaces (µ-Split)

Major technology Derivation and assessment of the individual wheel slips

and wheel accelerations of the wheels.

Autonomous modulation of the braking pressures on

the wheel regarding to the ideal braking slip.

Informative/Advisory/Warning

■ Support

Function output


Strategical

Tactical


■ Operational

Intended benefits with function To prevent the locking of the wheels to assure maxi-

mum transferable forces in the tire contact patches.

Ensure the transfer of lateral forces between tires and road surface so that the vehicle remains steerable while

braking.

Intended driver behaviour System is acting autonomously.

Time schedule System autonomously intervenes immediately on the

brake pressure of a specific wheel if a locking of the

wheel is detected.

Function classification of ABS

Type of target object for detection Vehicles ahead of subject vehicle

■ Urban


Road types

■ Highway

Road section type All motorways (without entrance and exit ramps)

Function limitations of ABS

Deliverable D1.1


Function limitations of ABS

Vehicle requirements Hydraulic braking system and ABS-System components (Wheel-speed sensors, Electronic- and Hydraulic Control

Unit)



■ Adverse (Rain)

■ Adverse (Snow)


■ Adverse (Fog)


■ Normal



Description of subsystems for ABS

Sensors • Wheel Speed Sensors

Actuators • HCU (Hydraulic Control Unit) which controls and modulates the brake pressures for the wheels

HMI design detail No HMI existing.

ABS

INPUTS OUTPUTS


individual wheel braking

SUBJECT, individual wheel slip detection


ABS sensors will measure individual wheel speed in order to avoid wheel slip.

When a locking tendency of a wheel during a braking situation is detected the ABS actuators modulate the specific braking pressure of the wheel to avoid a locking.

Deliverable D1.1


Subject individual wheel (FL, FR, RL, RR) speedWheel (active/pasive) sensors mounted individually on the wheel (FL, FR, RL, RR)

Subject vehicle dynamics Other sensors depending on OEM (engine, transmission)

Anti-lock Braking System (ABS)


Fig. 7-78: ABS sensors: technologies

Hydraulic brake

Electric brakeAutonomous Intervention: Brake

Anti-lock Braking System (ABS)


Fig. 7-79: ABS actuators: function outputs

ABS ECU

In order to have a top-down structure about functionalities carried out by ABS system, the fol-lowing “high level functions” (HLF) has been defined to be detailed in “Detailed functions” section:

HLF-ID Requirement Statement HLF_ABS_01 Prevent individual slip wheel during braking

Fig. 7-80: ABS high level functions



DF_ABS_01 Detect individual wheel slip. Determinate the individual wheel slip based on sensors mounted individually on the wheel.

HLF_ABS_01

DF_ABS_02 Individual wheel braking. Modulate the individual braking pressure of the wheel to avoid a locking.

HLF_ABS_01

Fig. 7-81: ABS detailed level functions

Deliverable D1.1


7.2.8 Electronic Stability Control (ESC)

Functional specifications of ESC

Main use-cases Stabilization of the vehicle in critical driving situations

Major technology Derivation of the current vehicle behaviour by the as-

sessment of measured vehicle data (e.g. yaw rate or

lateral acceleration)

Model based calculation of the desired vehicle behav-

iour by the assessment of current vehicle (e.g. velocity) data and driver inputs (e.g. steering angle.)

Comparison of current and desired vehicle behaviour

and derivation of stabilizing brake and engine interven-

tions. Informative/Advisory/Warning

■ Support

Function output


Strategical

Tactical


■ Operational

Intended benefits with function Prevent skidding of the vehicle and loss of control of

the driver

Intended driver behaviour System is acting autonomously.

Time schedule System autonomously intervenes immediately when a

critical driving situation is detected.

Function classification of ESC

Type of target object for detection No target object.

■ Urban


Road types

■ Highway

Road section type All motorways

Function limitations of ESC

Vehicle requirements Hydraulic braking system and engine interaction are re-quired.

Add on to ABS components:

• Yaw rate, acceleration and steering angle sensors

• Electronic Control Unit (ECU) with observation, de-

tection and control algorithms

• Hydraulic Control Unit (HCU )for the realization of autonomous brake interventions

• Engine intervention device



Deliverable D1.1


Function limitations of ESC

■ Adverse (Rain)

■ Adverse (Snow)


■ Adverse (Fog)


■ Normal



Description of subsystems for ESC

Sensors • Wheel Speed Sensors

• Yaw Rate Sensor

• Acceleration Sensors

• Steering angle Sensor

Actuators • HCU (Hydraulic Control Unit) which controls and modulates the brake pressures for the wheels

• Engine intervention device

HMI design detail Most systems do not have a HMI. Some OEM’s allow

deactivation of the ESC or offer variable intervention

thresholds (ESC-Switch).

ESC

INPUTS OUTPUTS


brakingSUBJECT, stability loss detection


Engine / transmission


ESC sensors will measure subject vehicle’s yaw rate, acceleration, individual wheel speeds and steering wheel angle, in order to avoid stability.

In critical driving situations when a loss of stability is detected ESC actuators will help the driver to control the vehicle by using controlled brake and engine/transmission autonomous interventions.

Deliverable D1.1


Subject yaw rate Precision and micromechanics sensors

Subject acceleration Micromechanics sensors

Subject wheel speedWheel (active/pasive) sensors mounted individually on the wheel (FL, FR, RL, RR)

Subject steering wheel angle AMR and optical steering angle sensors

Subject vehicle dynamics Other sensors depending on OEM (engine, transmission)


Electronic Stability Control (ESC)

Fig. 7-82: ESC sensors: technologies

Hydraulic brake

Electric brake

Electrical throttle

Camless valvetrain

Electronically managed transmission, electric actuators (motors)

Autonomous Intervention: Engine/Transmission

Electronic Stability Control (ESC)


Autonomous Intervention: Brake

Fig. 7-83: ESC actuators: technologies

ESC ECU

In order to have a top-down structure about functionalities carried out by ESC system, the following “high level functions” (HLF) has been defined to be detailed in “Detailed functions” section:

HLF-ID Requirement Statement HLF_ESC_01 Remain subject vehicle stability.

Fig. 7-84: ESC high level functions



DF_ESC_01 Detect subject vehicle stability loss

Determine if the vehicle is going where the driver is steering based on information from yaw rate sensor, acceleration sensor, individual wheel speed sensor and steering wheel angle sensor.

HLF_ESC_01

DF_ESC_02 Individual wheel braking Autonomous intervention in individual wheel brak-ing to correct the vehicle stability.

HLF_ESC_01

DF_ESC_03 Engine/transmission actions Autonomous intervention to reduction of engine power to facilitate the adjust of the stability.

HLF_ESC_01

DF_ESC_03 HMI management Warn subject vehicle driver when the system is active

HLF_ESC_01

Fig. 7-85: ESC detailed level functions

Documents

Testing and Evaluation Methods for ICT-based Safety …vti.diva-portal.org/smash/get/diva2:674079/FULLTEXT01… · · 2013-12-03Collaborative Project Grant Agreement Number 215607