NeTWork Workshop 2011: Control and Accountability in Highly Automated Systems
Toulouse, 29 September – 1 October 2011

Technological and Legal Considerations for the Design of Interactions
between Human Driver and Advanced Driver Assistance Systems
Toshiyuki INAGAKI
University of Tsukuba, Tsukuba 305-8573 JAPANinagaki@risk.tsukuba.ac.jp

1. Introduction
Among various modes of transportation, automobile has distinctive characteristics in thesense that its driver is not trained extensively so that he/she can utilize smart machines
properly. Various negative side effects can happen even for fully trained operators (suchas aircraft pilots). Careful considerations are necessary in the design of smart machines
for automobile by taking into account possible interactions between the driver and suchsmart machines.
Driving a car requires a continuous process of perception, situation understanding, action
selection, and action implementation. Various functions are implemented in an Advanced
Driver Assistance System (ADAS) to assist a human to drive a car in a dynamic
environment. Such functions include: (a) perception enhancement, (b) arousing attention
to potential risks, (c) setting off a warning, and (d) automatic safety control (Inagaki 2008).
The first two functions, (a) and (b), are to help the driver to understand the situation.
Understanding of the current situation determines what action needs to be done
(Hollnagel & Bye 2000). Once situation-diagnostic decision is made, action selection isusually straightforward, as has been suggested by recognition-primed decision making
research (Klein 1993). However, the driver may sometimes feel difficulty in action
selection decision. Function (c) is to help the driver in such a circumstance. ADAS thatuses only the three functions, (a) – (c), is completely compatible with the human-centeredautomation principle (Billings 1997, Inagaki 2006) in which the human is assumed to havethe ultimate authority over the automation.
Smart ADAS sometimes contains the forth function, (d). Such an ADAS may not always
be fully compatible with the human-centered automation, because the system can
implement an action that is not ordered by the driver explicitly. Although the automatic
safety control functions are usually effective and indispensable for attaining driver safety,
discussions are still going on regarding to what extent the system may be given authority
to decide and act autonomously without human intervention.
Moreover, as for the function (d), the following question is frequently asked: “When the
ADAS is capable of coping with the situation automatically without any intervention of adriver, is not it possible for the driver to place too much trust in the system and give up
active involvement in driving?” As a matter of fact, the Ministry of Land, Infrastructure andTransport (MLIT), the Government of Japan, has been discreet in introducing highly
automatic safety control functions into ADAS on concern that drivers may place overtrust
in or overreliance on automation. However, discussions regarding overtrust andoverreliance have not been rigorous enough up to about a year and a half ago.
A task force was set up in December 2009 in the MLIT's Advanced Safety Vehicle (ASV)
project to investigate the issue of the driver’s overtrust in and overreliance on the ADAS,
as well as that of authority and responsibility between the driver and the smart machines.
As leader of the task force, the author would like to report our discussions on these issues.

The first issue, the driver's overtrust and overreliance on the ADAS, has been investigatedbased on a theoretical framework (Inagaki 2011), in which two axes, (a) dimension of trust(Lee & Moray 1992) and (b) chance of observations, are introduced for discussing
overtrust in the ADAS, and two more axes, (c) benefits expected and (d) time allowancefor human intervention, are distinguished for discussing overreliance on the ADAS. The
framework has been successful in finding that the driver’s overtrust and overreliance on
ADAS differ appreciably depending on whether the ADAS is for use in routine situations or
for use in crisis situations. For instance, it is conjectured that an adaptive cruise control(ACC) system may induce the driver’s overtrust and/or overreliance more easily than anadvanced emergency braking system (AEBS). The conjecture has been recently
confirmed through a survey by questionnaire distributed to users of ACC and AEBS. The
issue of overtrust and overreliance is currently investigated for situations in which vehicleto-vehicle communication technology is introduced. It has been identified the imprecisionof GPS data can cause overtrust in and distrust of proximity information obtained throughvehicle-to-vehicle communication.
The second issue, authority and responsibility between the driver and the smart machines,
has been investigated mainly for crisis situations, in which two categories of cases are
distinguished. The first category is for cases in which the driver is in his/her good healthconditions, in spite of possibilities of (internal or external) distractions. The second
category, on the other hand, is for cases in which the driver becomes incapacitated whiledriving due to some sickness or disease. The discussions have been made for bothcategories by taking into account malfunctions of ADAS (such as, physical failures, logicalfaults, and limitations of ADAS, inappropriate design of human-machine interface, conflictof intentions between the driver and ADAS, and so on) as well as human errors committed
by the driver. Legal aspects have been analyzed for each case to identify responsibility ofdrivers, designer and manufacturer of ADAS, automobile dealers, and regulatory authority.

2. Advanced Safety Vehicle: A Japan’s National Project
Advanced Safety Vehicle (ASV) is a car equipped with technology-based driverassistance systems to enhance safety under normal as well as time-critical situations. The
ASV Project aims to promote development of new technologies for reducing traffic
accidents. The project is carried out through collaboration between vehicle manufacturers,
related organizations (such as user associations, insurance companies, dealer
associations), academia and government agencies (such as National Police Agency,
Ministry of Internal Affairs and Communications, Ministry of Economy, Trade and Industry,
Ministry of Land, Infrastructure and Transport) (MLIT 2007).
The ASV Project was kicked off in 1991. In ASV-1, the first 5-year phase of the project,technological possibilities and accident reduction effects were investigated. In ASV-2(1996-2001), ASV design principles and technology development guidelines were
established. Demonstrations and exhibitions were also made with 35 ASVs. In ASV-3(2001-2006), driver assistance concept was developed, and ASV popularization strategies
were examined. Up to ASV-2, driver assistance systems of the onboard self-sensing typehad been investigated. Such standalone systems can cope with hazards that are within
the driver’s field of view or its equivalent. However, they may fail to detect hazards thatare outside or barely within the driver’s field of view. To cope with such hidden hazards,
communication-based functions were introduced to ASVs. Driver assistance systems ofthe communication-based type can obtain necessary information through road-to-vehicle
and vehicle-to-vehicle communications. In 2005, verification tests were made with a totalof 17 vehicles (9 passenger cars, 4 heavy vehicles and 4 motorcycles). In ASV-4 (20062011), communication-based driver assistance functions were further developed. In2collaboration with the ITS promotion Council, large-scale experiments were conducted on
public roads in four areas of Japan in order to evaluate and validate efficacy ofcommunication-based and onboard sensing-based driver assistance functions.
Fig. 1 depicts the ASV design principles (MLIT 2007). Although ASV technologies provide
drivers with various assistances, it is assumed that drivers should play the primary role indriving vehicles safely. In other words, the driver is responsible for safe driving. The
principle coincides with the Convention on Road Traffic (1968) and human-centeredautomation principle (Woods 1989, Billings 1997) in which the human bears the ultimate
responsibility for system safety and thus human locus of control is assumed: Authority andresponsibility are interconnected.

Fig. 1 ASV design principles (MLIT 2007)
Fig. 2 illustrates the ASV design guidelines, where the following points are requested tobe satisfied for interactions between the driver and the assist system (MLIT 2007):(1) The system should act in line with intent of the driver.
(2) The system should assist the driver to perform safe driving and steady operation.
(3) The driver should monitor operations of the assist system when it is in action.
(4) The system should not cause overconfidence or over-trust of the driver.
(5) The system, when it is in action, should allow the driver’s intervention to override
its operation.
(6) The system’s control should be smoothly passed over to the driver when thesituation goes beyond the range of the system.
The design principle and the guidelines above were established through investigations ofnegative effects of automation, such as loss of situation awareness, overtrust, distrust,automation surprises (see, e.g., Woods 1989, Wickens 1994, Endsley & Kiris 1995, Sarter& Woods 1995, Parasuraman & Riley 1997, Sarter et al 1997).

3

Fig. 2 ASV technology development guidelines (MLIT 2007)
The ASV project has developed various systems that provide the drivers with assistances
for perception, cognition, and action selection. However, Ministry of Land, Infrastructure
and Transport (MLIT) as well as National Police Agency of the Government of Japan havebeen taking a cautious stance on putting systems into practical use when the assistancesystems are for action implementation. It is true, of course, that there are such systems.
The adaptive cruise control (ACC) and the lane keeping assistance (LKA) are examples ofsystems for assisting driver's action implementation by relieving the driver's load. The
electronic stability control (ESC) and the antilock brake system (ABS) are also examplesof systems for assisting driver's action implementation by amplifying or extending thecapabilities of the driver.
The arguments become different when it comes to the assistance systems that havecapabilities to back up or replace the driver. Take, as an example, the advanced
emergency braking system (AEBS). When the host vehicle is approaching relatively fast
to a lead vehicle, most AEBS firstly tightens the seat belt and adds a warning to urge thedriver to put on the brake. If the AEBS determined that the driver is late in braking, then it
applies the brake automatically based on its decision. However, the AEBS has been
implemented in Japan as a collision damage mitigation system, in stead of as a collision4

avoidance system. Behind the design decision to ‘downgrade’ the AEBS, there has been
concern among the regulatory authorities that “If a driver assistance system would
perform every safety control action automatically, the driver may become overly reliant on
the assistance system, without paying attention to the traffic situations himself or herself.”
Although the above ‘concern’ seems to be reasonable, there have been some discussions
in the ASV project that more precise investigations would be necessary so as not to lose
opportunities for the drivers (especially, elder drivers) to be benefited by the assistancesystem that may back up or replace them when appropriate. The MLIT set up a task force
in December 2009 in the ASV project to investigate future directions of driver assistancein light of (1) driver’s overtrust in and overreliance on the ADAS and (2) authority andresponsibility between the driver and the automation.

3. Overtrust and overrelianceThis section gives an overview of the theoretical framework that the author used at the
ASV task force to discuss issues of overtrust in and overreliance on driver assistancesystems (Inagaki 2011). The two terms ‘overtrust’ and ‘overreliance’ are differentiatedrigorously, although they sometimes have been used as if they were synonyms.

3.1 Overtrust
Overtrust in a driver assistance system is an incorrect diagnostic decision to conclude thatthe assistance system is trustworthy, when it actually is not. Two axes are introduced for
discussing overtrust in the assistance system. The first axis is the dimension of trust andthe second the chance of observations.
3.1.1 Dimension of trust
The first axis is to describe in which way the driver can overrate trust. Lee and Moray(1992) distinguished four dimensions of trust: (a) foundation, representing thefundamental assumption of natural and social order, (b) performance, resting on the
expectation of consistent, stable, and desirable performance or behavior, (c) process,depending on an understanding of the underlying qualities or characteristics that govern
behavior, and (d) purpose, resting on the underlying motives or intents. Three types ofovertrust can be distinguished depending on which dimension among (b) through (d) isoverrated; the first dimension (a) is usually met in cases of the driver assistance systems.
Overrating of (b) can be seen in a case where a driver thought, “The assistance system
has been responding perfectly to all the events that I have encountered so far. Whatever
events may occur, the system will take care of them nicely.” Improper evaluation of (c) isseen in a case where a driver has been using an assistance system without reading theuser’s manual at all by thinking, “It would be quite alright even if I do not know the detailsof the system functions.” Overestimation of (d) may be seen in a case where a driverbelieves that “I do not understand why my assistance system is doing such a thing.
However, it must be doing what it thinks it necessary and appropriate.”
3.1.2 Chance of observations
The second axis is to describe how often the driver can see the assistance system
functions. The chance of observations affects the ease of constructing a mental model ofthe assistance system. The possibility of the driver’s overtrust can differ depending on5

whether the assistance system is for use in normal driving or is for use in emergency.
Take the ACC as an example of the assistance system to reduce the driver workload innormal driving. Based on a large number of opportunities to observe the ACC’s
functioning repeatedly in daily use, it would be easy for the driver to construct a mental
model of the ACC. If the driver has been satisfied with ‘intelligent’ behaviours of the ACC,
it would be natural for him/her to place trust in the assistance system. However, the trust
can sometimes be overtrust. Suppose the driver encounters a new traffic condition that is
seemingly similar to a previous one but is slightly different. If the driver expected that the
ACC would be able to cope with the situation without any intervention of the driver, it canbe an overestimation of the ACC’s functionality.
Take next the AEBS as an example of the assistance system activated only in emergency
to assure the driver safety. It would be rare for an ordinary driver to see the AEBS works,
and he/she may not be able to construct a complete mental model of the AEBS becauseof lack of enough number of chances to experience the AEBS. The driver might havebeen told (by a car dealer, for instance) that the AEBS shall be activated automatically inemergency. However, the driver may not be fully convinced because of lack of chances toobserve himself/herself that the AEBS works properly and constantly when necessary.

3.2 Overreliance
Overreliance on a driver assistance system is an incorrect action selection decision
determining to rely on the assistance system by placing overtrust in it. Regarding
overreliance on automated warning systems, there are relevant studies in aviation domain(see, e.g., Parasuraman et al 1993, Mosier et al 1997, Meyer 2001, Sheridan &Parasuraman 2002). Suppose that the automated warning system almost always alerts
the human when an undesirable event occurs. Although it is possible for a given alert tobe false, the human can be confident that there is no undesirable event as long as no alert
is given (A similar situation can happen in automobile domain when the driver is provided
with a communication-based alert from the road infrastructure to let the driver know of an
approach or existence of cars on a crossing road behind some buildings). Meyer (2001)
used the term ‘reliance’ to express such a response of the human. If the human assumed
that the automated warning system will always give alerts when an undesirable event
occurs, that may be overtrust in the warning system and the resulting reliance on thewarning system is overreliance. The definition of overreliance on the driver assistancesystem, given at the beginning of this section, is a generalization of that of overreliance on
the warning system in the previous studies in the sense that the assistance system is not
only for setting off warnings but also for executing control actions.
Two axes are given for overreliance in the assistance systems. The first axis is thebenefits expected and the second the time allowance for human intervention.
3.2.1 Benefits expected
The first axis is to describe whether the driver can produce some benefits by relying on
the assistance system. Suppose the driver assigns the ACC all the tasks for longitudinal
control of the vehicle. That may enable the driver to find time to relax muscles and extend
legs after stressful maneuvering, or to allocate cognitive resources to finding a right way tothe destination in a complicated traffic conditions. In this way, relying on the assistancesystem sometimes brings extra benefit to the driver, when the system is for use in normal
driving.

6

The discussion can be quite different in case of AEBS. The AEBS is activated only inemergency, and the time duration for the AEBS to fulfil its function is short, say several
seconds. It is thus not feasible for the driver to allocate the time and resources, saved byrelying on the AEBS, to something else to produce extra benefit within the several
seconds. A similar argument may apply to other assistance systems designed for
emergency.
3.2.2 Time allowance for human intervention
The second axis is to describe whether the driver can intervene into the assistancesystem’s control when the driver determined that the system performance differs fromwhat he or she expected. In case of ACC, it may not be hard for the driver to intervene tooverride the ACC when its performance was not satisfactory. However, in case of AEBS, it
might be unrealistic to assume that the driver can intervene into control by the AEBS
when he or she decided that the AEBS performance was not satisfactory, because thewhole process of monitoring and evaluation of AEBS performance as well as decision andimplementation of intervention must be done within a few seconds.

3.3 From Collision Damage Mitigation to Collision Avoidance
Based on the framework given in sections 3.1 and 3.2, the following argument was madein the ASV task force: “Since the AEBS is activated only in cases of emergency, it would
be very rare for an ordinary driver to see how the system works (i.e., chance-ofobservation axis). It is thus hard for the driver to construct a precise mental model of the
AEBS, and may be hard for him/her to engender a sense of trust in the system (i.e.,
dimension-of-trust axis). However, it is known that people may place inappropriate trust(i.e., overtrust) without having any concrete evidence proving that the object is trustworthy.
Now, let us assume that the driver places overtrust in the assistance system. We have to
ask whether the driver may rely on the system excessively (i.e., overreliance). In case of
AEBS, even if the driver noticed that the system’s behavior was not what was expected,
no time may be left for the driver to intervene and correct it (i.e., time allowance for humanintervention). In spite of that, does the driver rely on the AEBS and allocate his/herresource to something else at the risk of his/her life (i.e., benefits expected)? The answer
would be negative.”
The ASV task force approved the above argument and decided that the AEBS may be
developed as a collision avoidance system, instead of a collision damage mitigation
system. The task force investigated design requirements for such collision avoidance
AEBS so that it may not interfere with the driver’s own actions (by letting it apply theautomatic brakes at the latest time possible) but still it can avoid a collision against aforward obstacle effectively. Human factors viewpoints played major roles in determining
the design requirements on the AEBS timing to initiate an automatic emergency braking
and its deceleration rate. In fact, they were determined through the analyses of drivers’
braking behaviors in normal and critical traffic conditions. Moreover, a couple ofconventional requirements for the AEBS were abolished from human factors viewpoints(e.g., to reduce mode confusion or automation surprise).
Based on the conclusion of the ASV task force, the MLIT has been revising the design
guidelines for the AEBS. The new guidelines will be announced to the public shortly.

7

4. Authority and Responsibility
It has been assumed in the ASV project that the driver is responsible for safe driving.
However, humans have limited capabilities and we have technology to make machines
more autonomous so that they can help humans in difficulty, which makes the issue ofauthority and responsibility complicated. Sudden death or onset of disease while driving is
one of cases for which such autonomous machines may be in need.

4.1 Driver incapacitation due to sudden death or onset of disease
Sudden death and onset of disease while driving occur sometimes in Japan. For instance,around 300 cases are reported during the period of 2007-2009 for commercial vehicles,
such as trucks, buses, and taxies. Although primary importance is definitely given to
health management by drivers themselves and their employers, we may need to think
about some technological measures for avoiding accidents. One of working groups in the
ASV project investigated feasibility of such technologies. The technologies investigatedinclude: (1) an equivalent of the train’s dead-man feature (or, dead man’s switch) thatapplies the emergency brakes when the driver ceases to hold on the controller arm, (2) anequivalent of the train’s safety protective system that applies the emergency brakes when
the driver does not supply any control input for a given length of time, (3) an emergency
stop button that applies the emergency brakes when being pushed, and (4) a drivermonitoring system that applies the emergency brakes when it determined that the driver
may be incapacitated. The working group chose the emergency stop button as areasonable solution for automobile at this moment in time. The working group and the
MLIT asked the ASV task force to investigate the emergency stop button from theviewpoint of authority and responsibility.
The task force has been discussing (A) trading of authority as well as (B) authority andresponsibility of an accident if it occurred after the emergency stop button was pushed.
(A) Trading of authority
The following four cases are distinguished by taking into account who decides the needfor and implements the trading of authority.
Case A1: driver-initiated trading of authority
The driver notices a sign of ill-health himself/herself and decides it would be hard for
him/her to continue to be in charge of driving. The driver then pushes the emergency
stop button to let the automation take care of stopping the vehicle safely.
Case A2: passenger-initiated trading of authority
A passenger of the vehicle notices a sign of ill-health of the driver and decides it
hard for the driver to continue driving. The passenger then pushes the emergency
stop button.
Case A3: passenger-initiated trading of authority
A passenger of the vehicle notices a sign of ill-health of the driver and decides it
hard for the driver to continue driving. The passenger seizes the authority to control
the vehicle to stop it safely.
Case A4: machine-initiated trading of authority
The onboard computer detects a sign of ill-health of the driver and decides it would
be hard for the driver to continue driving. The computer then activates the
emergency stop button without any human intervention.

8

For each case, discussions have been made on acceptability of a ‘false alarm’ and its
inconveniences. The task force also discussed whether the driver should be given
authority to override the decision of the other agent (a passenger or the computer).
(B) Authority and responsibility of an accident
Suppose that the emergency stop button has been pushed, and the automation is trying tostop the vehicle safely. Various types of accidents can occur in such a phase. For eachcase listed below, who should be responsible for the accident?
Case B1: The automation was trying to slow down the vehicle. Although the control
was successful while the road was straight, the host vehicle departed from the roadat the curve and overturned.
Case B2: The automation was able to slow down and stop the vehicle safely on thelane. However, a following vehicle crashed against the host vehicle.
Case B3: The automation was trying to slow down the vehicle. Before it came to acomplete stop, it ran into a forward vehicle standing at the stop sign and then had aconflict with a pedestrian on the roadside.
Case B4: While the automation was slowing down the vehicle, the driver came tohimself. He tried to seize the control back from the automation. During the process,he got in an accident.
Case B5: One of the passengers tried to control the bus on behalf of theincapacitated driver. However, in spite of his wish to save other passengers onboard,
he lost control of the bus because of no previous experience and skill to drive a bus.

4.2 Should ADAS design be blamed?
Even if the driver is in his/her good health, an accident can occur in the interaction with
the ADAS. The ASV task force has defined sample cases to investigate who should be
responsible for an accident.
Case 1: malfunction of ADAS
A malfunction of ADAS prevented the driver from controlling the vehicle.
Case 2: combination of ADAS malfunction and driver error
A forward vehicle collision warning was not given to the driver because the sensor
got an intermittent (or, a permanent) failure to detect the lead vehicle. The driver did
not notice the lead vehicle at that time, either, due to an external distraction.
Case 3: overtrust in and/or overreliance on ADAS
The driver was not paying attention fully to a lead vehicle by assuming that, “myAEBS should tell me when an event occurs to which I need to respond.”
Case 4: limited functionality of ADAS(a) The sensor failed to detect a lead vehicle in the thick fog.
(b) The sensor was late in detecting a lead vehicle, because the host vehicle’s
velocity relative to the lead vehicle was too high.

9Case 5: driver implemented exactly what was suggested by ADAS
Upon receiving a forward vehicle collision warning, the driver applied the brakes
precisely without any delay. However, the host vehicle was rear-ended by afollowing vehicle.
Case 6: conflict of intentions between the driver and ADAS
The driver tried to pass a lead vehicle by steering a wheel with a slight acceleration.
The AEBS judged, however, that a collision was imminent to the lead vehicle, andapplied emergency brakes. Because of the deceleration, instead of the driver’s
intended acceleration, the host vehicle was rear-ended by a following vehicle.
Case 7: ADAS control-induced accident
The AEBS was activated successfully to prevent a crash against a lead vehicle.
However, the host vehicle was rear-ended by a following vehicle.
Case 8: ADAS control-induced injury(a) The AEBS reduced the collision speed successfully. However, a passenger
without wearing the seatbelt got injured at that time.
(b) The AEBS prevented a crash against a lead vehicle successfully. However, apassenger without wearing the seatbelt got injured at that time.
Case 9: automation-induced surprises
The driver was surprised to see the AEBS applied emergency brakes unexpectedly,
which caused an abrupt and inappropriate steering by the driver. The host vehicle
finally ran out of the road.

4.3 ASV-5: the fifth 5-year phase
The issues described in sections 4.1 and 4.2 need more extensive investigations, which
will be one of major themes of the ASV-5 starting 2011 autumn. The task force is
expected to give some guidelines for designing and developing ADAS so that drivers,
ADAS, and people in the society may be harmonized. The task force is also supposed toinvestigate reasonable ways for promoting the drivers’ proper understanding of the ADAS.
It has been found through questionnaires distributed to ADAS users in 2010 that somedrivers misinterpreted the aim of some ADAS. For instance, 23% of ACC users said that
the ACC contributes well in improving safety, and 47% of AEBS users claimed that the
AEBS reduces the workload appreciably.
Another major theme of the ASV-5 is further developments of communication-based
ADAS. Among them, car-to-pedestrian communication systems are supposed to bestudied extensively.

5. Concluding Remarks
Collaborations among the government, industries, and academia for better design ofhuman-automation interface and interaction are increasing in automobile domain. For
instance, the author has been involved in a National Policy Agency’s committee to define
specifications for car-to-infrastructure communication-based ADAS in 2009, in which theauthor was expected to contribute to clarify design requirements for human-machineinterface as well as human-machine interactions so that human factor issues (such as,
loss of situation awareness, mode confusion, automation surprise, overtrust in and distrust10

of automated assistance, etc) may be resolved.
The author was also a member of study committee of MLIT to discuss measures against
quietness problem of Hybrid Electronic Vehicles (HEV) and Electronic Vehicles (EV) in2009. It was claimed by some organizations, including the Japan Federation of the Blind,that “it is hard for the visually-impaired to recognize HEV/EV approaching at low speeds
because these vehicles are too quiet.” The study committee discussed various points fromseveral different disciplines, in which human factors was one of major disciplines. Some ofhuman factors related points for discussions were:(a) Do we need to add artificial sound to vehicles that have been made quiet?
(b) If Yes, what kind of sound is appropriate?
(c) Should the sound permanently on or switchable manually?
(d) If the sound is on permanently, is a temporary stop switch necessary?
The conclusion for each point was:(a) We need an audible measure, because: visually-impaired pedestrians can catch thepresence or approach of vehicles only audibly.
(b) The artificial sound must be one that enables people to recognize the presence andbehavior (such as, starting, slowing down, direction of movement) naturally and easily
even without prior knowledge on what kind of sound is emitted from HEV/EV.
(c) Basically, the sound will be kept on permanently. If the driver is requested to turn on
the sound when necessary, no sound is failed to be emitted when the driver is not awareof the pedestrian. Moreover, the pedestrians may not be able to grasp the behavior of thevehicles if the sound is emitted only a short time period.
(d) A switch to stop the sound temporarily must be allowed. For instance, the drivers
would want to stop the sound when they drive residential area late at night. If such a stop
switch is prohibited, some drivers may accelerate the vehicle so that no artificial soundwould be emitted.
The discussions and conclusions of the study group were adopted by the MLIT toestablish the “Guideline for Measure against Quietness Problem of HV, etc” (2010).

References
Billings, C.E. (1997). Aviation automation – The search for a human-centered approach.
LEA, Mahwah
Convention on Road Traffic (1968) 1993 version & amendments in 2006. United Nations,
New York
Endsley, M.R., Kiris, E.O. (1995). The out-of-the-loop performance problem and the levelof control in automation. Human Factors, 37(2):3181-3194
Guideline for Measure against Quietness Problem of HV, etc (2010). QRTV-03-01.
http://live.unece.org/trans/main/wp29/wp29wgs/wp29grb/qrtv_3.html

Hollnagel, E. & Bye, A. (2000). Principles for modeling function allocation. Int. J. HumanComputer Studies, 52: 253-265
Inagaki, T. (2006). Design of human-machine interactions in light of domain-dependenceof human-centered automation. Cognition, Technology & Work, 8(3):161-167
Inagaki, T. (2008). Smart collaborations between humans and machines based on mutual
understanding. Annual Reviews in Control, 32:253-261

11

Inagaki, T. (2011). To what extent may assistance systems correct and prevent'erroneous' behaviour of the driver?. In P.C. Cacciabue et al (eds.), Human Modelling in
Assisted Transportation. Springer, Milan, pp 33-41
Klein, G. (1993). A recognition-primed decision (RPD) model of rapid decision making. In
G. Klein, et al (eds), Decision making in action. Ablex, New York, pp 138-147
Lee, J.D. & Moray, N. (1992). Trust, control strategies and allocation of function in humanmachine systems. Ergonomics, 35(10), 1243-1270
Meyer, J. (2001) Effects of warning validity and proximity on responses to warnings.
Human Factors 43(4):563-572
MLIT (2007). ASV, the bridge to an accident-free society. Ministry of Land, Infrastructure
and Transport, Government of Japan
Mosier, K., Skitka, L.J., Heers, S., & Burdick, M. (1998). Automation bias: decision making
and performance in high-tech cockpits. Int J Aviation Psychol, 8:47-63
Parasuraman, R., & Riley, V. (1997). Humans and automation: use, misuse, disuse,abuse. Human Factors, 39(2):230-253
Parasuraman, R., Molloy, R., & Singh, I.L. (1993). Performance consequences ofautomation-induced ‘complacency.’ Int J of Aviation Psychol, 3(1):1-23
Sarter, N.B., & Woods, D.D. (1995). How in the world did we ever get into that mode?
Mode error and awareness in supervisory control. Human Factors, 37(1):5-19
Sarter, N.B., Woods, D.D., & Billings, C.E. (1997). Automation surprises. In: Salvendy, G.
(ed). Handbook of human factors and ergonomics, 2nd edn. Wiley, New York, pp 19261943
Sheridan, T.B. & Parasuraman, R. (2005). Human-automation interaction. In: Nickerson
RS (ed) Reviews of human factors and ergonomics, Vol 1, Human Factors and
Ergonomics Society, Santa Monica, pp 89-129
Wickens, C.D. (1994). Designing for situation awareness and trust in automation. In:
Proceedings of IFAC integrated systems engineering, pp 77-82
Woods, D. (1989). The effects of automation on human’s role: Experience from nonaviation industries. In Flight deck automation: Promises and realities (NASA CR-10036,
pp.61-85)12