dissertacao final [071] - fenix.tecnico.ulisboa.pt · 1 acknowledgements i would like to thank...
TRANSCRIPT
Preside
Orienta
Vogal:
D
E
nte: Prof
dor: Prof
Prof
Highwa
I
Dissertaçã
ngenhar
fessor Dout
fessor Dout
fessor Dout
ay hypno
nfluence
Acácio Ca
o para ob
ria Inform
tor Mário Ru
tor João Ma
tor Tiago Ale
Nove
osis and i
in driving
arreira Po
btenção do
mática e
Júri:
ui Fonseca d
anuel Brisso
exandre Ab
embro de
n‐car tel
and safet
orta Nova
o grau de
de Comp
dos Santos
on Lopes
branches Te
2007
lematics
y
Mestre em
putadore
Gomes
ixeira Lopes
m
es
s Farias
1
Acknowledgements I would like to thank everyone who helped me accomplish this work, especially my supervising
professor João Brisson Lopes, for embracing the idea of this work from the very beginning; for
guiding me throughout its evolution, clarifying my doubts (some of them philosophical), reviewing
every draft produced, supplying some of the material needed to build the simulator and motivating
me towards the conclusion of this dissertation.
I would also like to thank the accompanying professor João Madeiras Pereira for his assistance during
all the work and his permission to use the laboratory on which the usability tests were conducted.
Finally, a word of appreciation to my mother, Ana Maria, an endless source of inspiration, my father,
Acácio, whose pragmatism and experience were extremely important at some stages of the writing
of this text, my sister, my girlfriend and my friends, for being there and helping me maintain my
mental sanity and supporting me through this time of my life, and a special thank you for all the
users who were willing to participate in the usability tests.
Thank you all!
2
Resumo Este trabalho está focado na usabilidade de interfaces de dispositivos no interior do automóvel e na
sua influência no comportamento dos condutores quando na presença do efeito de monotonia e do
fenómeno de highway hypnosis. Já existem variados trabalhos académicos: na área das interfaces
para dispositivos dos automóveis, com estudos de usabilidade e discussões sobre as novas
abordagens disponíveis na indústria para substituir os tradicionais botões e alavancas, como os
sistemas iDrive, COMAND e MMI; na área da monotonia durante a condução, com trabalhos que vão
desde a dimensão fisiológica até a trabalhos a propor novas regras na concepção de estradas para
diminuir estes problemas. No seguimento do trabalho anterior, que procurou comparar os sistemas
integrados com os sistemas ditos “tradicionais”, ainda vulgares, este trabalho introduz os dois
tópicos num só estudo: a questão da monotonia na condução e a highway hypnosis e a influência das
interfaces dos sistemas de conforto neste tópico da segurança rodoviária. O estudo consiste em
testes de usabilidade com simulador em que os condutores descrevem um percurso monótono
tendo de desempenhar tarefas com os sistemas de conforto em determinados sítios estando atento
a mudanças subtis no ambiente envolvente. As conclusões apontam para uma tendência de quebra
no efeito de monotonia aquando do uso dos sistemas de conforto, em especial no caso das
interfaces integradas, apesar de se manterem as conclusões relativamente à maior dificuldade no
manuseamento deste tipo de interfaces.
Palavraschave: simulador de condução, segurança rodoviária, interfaces pessoa‐máquina,
highway hypnosis, monotonia.
Abstract This work focuses on the usability of interfaces controlling in‐vehicle functions and devices and their
influence in driving behavior when under monotony in driving and highway hypnosis. Much academic
research has been published in the area of in‐vehicle functions interfaces, for systems such as the
iDrive, COMAND and MMI, with usability studies and discussions on the new integrated approaches
provided by the industry to replace the traditional knobs and switches; in the area of monotony
while driving, works assessing from the physiological dimension to changes in road conception rules
to counter such problems. Following previous work, aimed at comparing the integrated systems with
the “traditional” ones, still widespread, this work introduces both topics into one study: the issue of
monotony in driving and highway hypnosis and the influence of the comfort systems interfaces in
this road safety subject. The study conducted usability tests with a simulator where drivers go
through a monotonous course and in given places perform tasks using the comfort systems while
constantly being aware of subtle changes to the surrounding environment. Conclusions point at a
tendency to break the monotony effect when using comfort systems, especially in the case of
integrated interfaces, although the conclusions regarding the greater difficulty in handling this type
of interface are still pertinent.
Keywords: driving simulator, road safety, human‐machine interfaces, highway hypnosis,
monotony.
3
Index List of tables and figures ......................................................................................................................... 6
List of abbreviations ................................................................................................................................ 8
1. Introduction ..................................................................................................................................... 9
1.1. Motivation ............................................................................................................................. 10
1.2. Goals ...................................................................................................................................... 10
1.3. Document structure .............................................................................................................. 11
2. Monotony and distraction ............................................................................................................. 12
2.1. Why monotony? .................................................................................................................... 12
2.2. Monotony and predictability ................................................................................................. 12
2.3. Vigilance and fatigue ............................................................................................................. 13
2.4. Monotony and habituation ................................................................................................... 14
2.5. Highway hypnosis .................................................................................................................. 15
2.6. Research aims – distraction & monotony ............................................................................. 16
3. Interface Usability ......................................................................................................................... 18
3.1. Usability of in‐car telematics and interfaces ......................................................................... 18
3.1.1. The need for vision in using comfort systems ............................................................... 18
3.1.2. Haptic switches, voice control, not‐solely‐visual control and feedback ....................... 19
3.2. Comparative study between some production systems ....................................................... 21
3.3. User categorization in this work ............................................................................................ 22
4. Comfort systems interfaces ........................................................................................................... 24
4.1. Basic concepts ....................................................................................................................... 24
4.2. Comfort functions and in‐car telematics ............................................................................... 25
4.3. Traditional interfaces for comfort systems ........................................................................... 26
4.4. Integrated solutions used by the car industry ...................................................................... 26
4.4.1. iDrive ............................................................................................................................. 26
4.4.2. COMAND ....................................................................................................................... 27
4.4.3. MMI ............................................................................................................................... 29
4.4.4. Other systems ................................................................................................................ 30
4.4.5. Add‐on equipments ....................................................................................................... 31
4.5. Concluding remarks ............................................................................................................... 32
5. Simulators for usability testing ...................................................................................................... 33
5.1. Simulator development and usage in the study of road safety issues .................................. 33
4
5.1.1. Simulators with actual car bodies and 360º field‐of‐view ............................................ 35
5.1.2. Simulators with audio and haptic feedback .................................................................. 36
5.1.3. Simulator using advanced physics (to handle simulator sickness) ................................ 37
5.1.4. Simulators that monitor physiological data .................................................................. 37
5.1.5. Simulation software ...................................................................................................... 38
5.1.6. The simulator used in the present work ....................................................................... 38
5.1.7. Partial driving simulators ............................................................................................... 39
6. Experiment Setup & Protocol ........................................................................................................ 41
6.1. Setup ...................................................................................................................................... 41
6.1.1. Course characteristics ................................................................................................... 41
6.1.2. New scenario elements ................................................................................................. 43
6.1.3. Adjustments to vehicle behavior and validation procedure ......................................... 43
6.2. Protocol ................................................................................................................................. 44
6.2.1. Participants .................................................................................................................... 44
6.2.2. Roles .............................................................................................................................. 44
6.2.3. Procedure ...................................................................................................................... 45
6.2.4. Tasks using the comfort systems ................................................................................... 46
6.2.5. Performance metrics ..................................................................................................... 46
7. Results and analysis ....................................................................................................................... 49
7.1. Sample population ................................................................................................................ 49
7.2. Log data ................................................................................................................................. 50
7.3. State of monotony ................................................................................................................. 50
7.3.1. Speed monotony ........................................................................................................... 52
7.3.2. Side deviation monotony .............................................................................................. 54
7.4. Behavior while in monotony ................................................................................................. 56
7.4.1. Mean and minimum speed ........................................................................................... 57
7.4.2. Attention flaws .............................................................................................................. 58
7.4.3. Task errors ..................................................................................................................... 61
8. Conclusions .................................................................................................................................... 63
8.1. Possible future improvements .............................................................................................. 64
Bibliography ........................................................................................................................................... 66
Glossary ................................................................................................................................................. 70
Annex A. Changes to the simulator .................................................................................................. 71
A.1. Introduction ........................................................................................................................... 71
5
A.1.1. Platform ......................................................................................................................... 71
A.1.2. Architecture ................................................................................................................... 72
A.2. Changes to scenario definitions ............................................................................................ 73
A.2.1. Assumptions made on the scenario .............................................................................. 73
A.2.2. Road stretches ............................................................................................................... 73
A.2.3. Road curves ................................................................................................................... 75
A.2.4. Billboards ....................................................................................................................... 76
A.2.5. Texture pre‐loading ....................................................................................................... 77
A.2.6. Transparency modes ..................................................................................................... 78
A.3. New logging behavior ............................................................................................................ 78
A.3.1. Log definitions ............................................................................................................... 78
A.3.2. Log stretches ................................................................................................................. 79
A.4. Other minor changes ............................................................................................................. 80
A.4.1. Changes to vehicle behavior ......................................................................................... 80
A.4.2. Changing the comfort systems interface during the simulation ................................... 80
A.4.3. New course .................................................................................................................... 80
A.4.4. Minor bugs .................................................................................................................... 80
A.5. Acknowledgements ............................................................................................................... 81
Annex B. User’s Manual .................................................................................................................... 82
B.1. Material ................................................................................................................................. 82
B.1.1. Device installation ......................................................................................................... 83
B.2. Running the simulator ........................................................................................................... 83
B.2.1. Driving the vehicle ......................................................................................................... 83
B.2.2. Comfort systems – traditional interface ....................................................................... 84
B.2.3. Comfort systems – integrated interface ....................................................................... 84
Annex C. Quiz for the usability tests ................................................................................................. 86
Annex D. Examiner form ................................................................................................................... 88
6
List of tables and figures Figure 4.1. Examples of interfaces for comfort systems: traditional (left) and integrated (right). ....................... 24
Figure 4.2. Overview of the iDrive system on a BMW 7 series (left) and two versions of the Controller: the original one, available on the 7 series (right‐above) and the one available on the current 5 series (right‐below). .............................................................................................................................................................................. 27
Figure 4.3. Overview of the COMAND system (2007); notice the similarity with the iDrive Controller (right). ... 28
Figure 4.4. Picture of a COMAND Console using the navigation application (left). Photo of a console including the COMAND Console and the climate control console below (right). ................................................................ 28
Figure 4.5. Overview of the MMI on an Audi A6 (left) and detailed view of the A8 controller interface (right). . 29
Figure 4.6. Detail on the Jaguar Touchscreen interface: early S‐Type (left) and current XJ (right). ..................... 30
Figure 4.7. Overview of the Porsche Communication Management (available in the 2007 Cayenne model). .... 31
Figure 4.8. Example of a post‐mounted GPS system (left) and a car DVD‐Video player (right)............................ 31
Figure 5.1. Outside view (left) and car body detail (right) of the Wrap‐around Simulator (WAS). ....................... 35
Figure 5.2. Arriva Simulator, one of the possible configurations for the Cranfield University’s Driving Simulator. .............................................................................................................................................................................. 36
Figure 5.3. Outside view (left) and usage demonstrations (right) of the UCF Driving Simulator, using an automobile car body. ............................................................................................................................................ 37
Figure 5.4. Outside (left) and inside view (right, using a jeep body) of the NADS simulator. ............................... 38
Figure 5.5. Simulator setup (left) and example view (right) of the simulator used on the previous work. .......... 39
Figure 6.1. The simulator (left); example screen using the traditional (middle) and integrated (right) interfaces. .............................................................................................................................................................................. 41
Figure 7.1. Charts illustrating the distribution of the sample population by gender and age groups. ................. 49
Figure 7.2. Charts plotting speed and accelerator pedal pressure (A, right column) and side deviation and steering wheel position (B, left column) for each of the 3 monotony control stretches (each row). .................. 51
Figure 7.3. Chart showing valid (A, B and C, green) and invalid (D, E, F and G, red) “speed monotony” periods. 52
Table 7.1. Average number of “speed monotony” periods by age group and by stretch. ................................... 53
Figure 7.4. Chart depicting the number of users having “speed monotony” period in terms of stretches. ......... 54
Figure 7.5. Chart showing 2 valid (A and B) “side deviation monotony” periods. ................................................ 55
Table 7.2. Average number of “side deviation monotony” periods by age group and by stretch. ....................... 55
7
Figure 7.6. Chart depicting the number of users having “side deviation monotony” period in terms of stretches. .............................................................................................................................................................................. 56
Figure 7.7. Mean speed in stretches in terms of age group. ................................................................................ 57
Figure 7.8. Minimum speed in stretches in terms of age group. .......................................................................... 57
Figure 7.9. Charts comparing the number of users performing better in each combination of situations. ......... 59
Figure 7.10. Comparing the number of users performing better in each combination of situations by age group. .............................................................................................................................................................................. 59
Figure 7.11. Users’ perceived attention to the course. ......................................................................................... 61
Figure 7.12. Charts depicting the number of users in terms of tasks with error and age groups. ........................ 61
Figure A.1. UML instalation diagram for the simulator. ....................................................................................... 72
Figure A.2. Simplified state diagram for the simulator. ........................................................................................ 72
Figure A.3. Example placement of 2 road stretches according to the specified format. The black lines along the road stretches represent the shoulders and the arrows the direction span of the stretches. ............................. 74
Figure A.4. XML source code corresponding to the scheme in figure A.3. ........................................................... 74
Figure A.5. Example placement of 2 road curves according to the specified format. The black lines along the road stretches represent the shoulders and the arrows the direction span of the curves. ................................. 75
Figure A.6. XML source code corresponding to the scheme in figure A.5. ........................................................... 75
Figure A.7. XML sample code of a billboard declaration group. ........................................................................... 76
Figure A.8. XML sample code of a texture pre‐loading declaration group. .......................................................... 77
Figure A.9. Sample XML source code in a logDefs.xml file. ........................................................................... 78
Figure A.10. Graphic scheme of the stretch defined in figure A.9. Whatever path is described by the vehicle (in purple), logging will begin when it enters the red circle and end when it enters the green circle. ..................... 79
Figure B.1. Screen sequence for activating the centering spring (from top to bottom). ...................................... 82
Figure B.2. Integrated interface controls. ............................................................................................................. 84
Figure B.3. Two example screen for the integrated interface: the top level menu of the climate control (left) and the volume control menu for the sound system (right). ....................................................................................... 85
8
List of abbreviations ABS Anti‐lock Braking System API Application Programming Interface ASR Automatic Speech Recognition CATSS Center for Advanced Transportation Systems Simulation CD Compact Disk COMAND Cockpit Management and Navigation Display DSL Driving Simulator Laboratory DVD Digital Versatile Disk DWAM Driving Without Attention Mode ESP Electronic Stability Program / Electronic Skid Prevention ETC Electronic Throttle Control GPS Global Positioning System LCD Liquid Crystal Display MMI MultiMedia Controller NADS National Advanced Driving Simulator NHTSA National Highway Traffic Safety Administration PCM Porsche Communication Management UCF University of Central Florida V2C Voice to Control VTI Väg‐och TransportforskningsInstitut (Swedish institute) WAS Wrap‐Around Simulator WIMP Windows, Icon, Menu, Pointing device WIMP Windows, Icons, Menus and Pointer WIVM Würzburger Institut für Verkehrswissenschaften
9
1. Introduction Road safety is a major issue these days. Each day thousands of new cars enter the streets worldwide
and the need for them to interact safely is a major concern for governments, car manufacturers and
the society as a whole.
Nowadays, most automobiles are equipped with systems that largely exceed those required for the
task of driving. The increasing number of in‐car telematics forces drivers to focus their attention and
cognitive skills on more instruments and devices than before. This might result in an awkward
situation: the introduction of new devices for increasing comfort and safety may lead to failures in
driving because the driver’s cognitive skills do not improve, and he or she is unable to cope with the
increased complexity of the available instruments and devices.
Highway hypnosis can be described as a “tendency of the automobile driver to become drowsy and
to fall asleep during monotonous, uneventful highway driving” (Wertheim, see [TB03]). In such state,
the driver’s cognitive skills are diminished and he or she might get unaware of the driving task,
compromising safety and increasing the risk of a traffic accident.
The combination of over‐demanding comfort systems requiring excessive cognitive load and
monotonous road environments leading to conditions such as highway hypnosis can result in major
hazards for road safety. This work tries to analyze the issue by using usability methodologies and
concepts and applying them to interfaces for in‐car telematics.
It is important to distinguish between the two types of devices available in automobiles and the two
main types of interfaces for these systems. When considering types of devices, according to Burnett
and Porter in [BP01], we can divide available devices in vehicles into two categories: driving assisting
devices, which directly affect the driving task (steering wheel, pedals …) and comfort devices, which
aim at improving the driving experience (radio, climate control …). On the other hand, considering
the types of interfaces for controlling these devices, according to Porta Nova in [Por06], we can split
them in traditional interfaces, which exhibit most of the commands in the central dashboard console,
in separated switches, handles and knobs, and integrated interfaces, consisting of a single input and
output device (typically a rotary switch / buttons and a LCD screen) that control more than one
device (typically all of them) simultaneously. This work addresses about the usability of the two types
of interfaces relating to the use of comfort devices.
10
1.1. Motivation There has been a lot of research work related to road safety and distraction originating from both the
surrounding environment and the inside of the vehicle. The increase of in‐vehicle devices has taken
up as much “dashboard real estate” [GC99] as attention from the driver, trying to achieve the best
compromise between driving safely and properly operating the available devices which constitute a
great part of the driving experience. Research on the way that cognitive load on the driver increases
has been studied in works such as [Por06] and [Horb06]. They emphasize that an overwhelming and
over‐demanding road environment tends to decrease driving performance and safety if combined
with the use of accessory devices (such as the vehicle’s comfort functions).
Research on driving monotony and fatigue has also been a major subject for road sciences
publications. The consensus nowadays is that under‐demanding road environments are responsible
for drowsiness, sleepiness and phenomena like highway hypnosis and DWAM – Driving Without
Attention Mode – and studies like [Hawo98] recommend countermeasures concerning educational
programs, pavement treatments and regulatory demands to lower safety risks, especially concerning
professional drivers. To the regular driver, monotonous road environments cause the same effects,
and can lead to the same safety hazards. However, one new variable comes into play: comfort
functions.
Among the recently available comfort functions in production vehicles, many aim at entertaining
passengers and assisting drivers – especially in long trips through unknown places (GPS systems,
video entertainment, etc.). This increase in the number of comfort functions has lead to integrated
interfaces for comfort systems, which although aiming at improving usability, may not be performing
that well [Por06]. This introduces the problem of comfort systems usage interfering with the driving
task in monotonous environments. Taking into account the different nature of the interaction
between driver and road, the same issues concerning the differences between traditional and
integrated comfort function interfaces emerge. Is one approach better than the other? Is the
interaction with comfort systems having an effect on the monotonous state of the driver? The work
described in this document attempts to approach this subject with a comparative simulator study.
1.2. Goals Given the previous section, this work aims at adapting a simulator developed in [Por06] and using it
to study the influence of a monotonous road environment in the driving task, while the driver is
operating the comfort systems available, using both types of interfaces for these systems. This study
recreates a monotonous driving task in a simulator to allow comparing drivers’ behavior when simply
driving and using the comfort systems to perform given tasks, while still driving safely, and determine
11
the influence of such tasks in drivers’ behavior. The study also aims at determining if there are
significant differences between drivers’ behavior when using either of the comfort systems
interfaces, in order to determine the influence that the use of each interface has in driving.
1.3. Document structure This document is a master’s thesis. It starts with a brief introduction to the subject, presenting some
fundamental concepts and briefly describing the context, in the Introduction. Monotony and
distraction presents the ideas behind the work, relating these concepts to automobile driving and
formulating the problem. Interface usability discusses the usability of car interfaces, especially for
comfort systems, refers to some projects in the same area and recalls user categorization in the
context of an interface usability study. The following chapter, Comfort systems interfaces, presents
some of the systems in use by the automobile industry, as well as some considerations on the
subject of traditional and integrated interfaces for comfort systems. A survey of simulators and their
uses for testing interfaces usability is presented in Simulators for usability testing, where simulators
are divided into categories and the concept of partial simulators for usability testing is introduced.
The next chapter Experiment Setup & Protocol describes the experiment conducted in this work,
detailing the procedure, the equipment and the data collected, which are analyzed in the chapter
Results and Analysis. Finally, Conclusions summarizes the main results that were obtained and
suggests some possible follow‐ups.
12
2. Monotony and distraction 2.1. Why monotony? In order to introduce the role that monotony has in the development of this work, a reference must
be made to the previous work. [Por06] reports a comparative study for analyzing the influence that
traditional and integrated interfaces might have in driving performance. The method was to have
users driving in the designed simulator, while performing a series of tasks involving the use of the
comfort systems interfaces, making it possible to observe the impact of the courses’ differences on
the drivers’ performance, namely driving errors (e.g., leaving the correct lane) or inability to
accomplish the desired task. Besides using several different persons for statistical significance, the
study took two main variables into account: the type of interface in use (either traditional or
integrated) and the nature of the course in which the user was driving (either fast or sinuous). Thus,
each user had to drive a total of 4 times, two courses using both interfaces, one at a time. Although
both courses took place in the same set (an urban scenery, simulating a small town) the courses,
named respectively rápido (fast) and sinuoso (sinuous) had distinct features. The first course literally
went around the whole scenario, made up mostly of long stretches of straight road with sharp curves
which were visible in the distance. The second course, on the other hand, was composed of a
succession of sharp turns in a constant zigzag throughout the whole scenario (hence its name),
aiming at keeping high concentration demands on the driver and observing if the difference in the
courses was reflected in the driving performance, namely driving errors (e.g. leaving the correct lane)
or inability to carry out the designated task. Although the courses were significantly different – which
was observed on the users’ performance – some users noticed that the fast course lacked
“monotony” and was even too “predictable”, making them simply just two versions of the same
course with different degrees of difficulty. This meant drivers would just go through the course faster
in the fast course and slower in the sinuous course, but they always knew what they could count on –
if they saw a long straight street, they knew they could just leave the car on “auto‐pilot” and use the
comfort systems carelessly. Evidently, they were simply 2 versions of an urban course.
2.2. Monotony and predictability Before discussing why “monotony” and “predictability” are so important, it is necessary to clarify
these two concepts. Starting with the latter, “predictability” relates to determinism, to events that
are bound to happen and it is known that they are bound to happen. Predictability implies some sort
of knowledge about what the future holds, an understanding of the rules and events that happen
and, above all, an understanding of the way to handle things when they happen. Predictability
13
seldom comes associated with real world driving. In a typical automobile trip, we can expect a great
deal of random events to occur: pedestrians may, or may not, be waiting on the next zebra (or they
may simply decide to cross the street without looking), other vehicles may come out of side streets,
or unexpected traffic jams may occur at unusual hours. All of these elements are part of the road
driving experience and they should come as no surprise to any driver. We can say that the real world
driving environment is “unpredictable” because, as said earlier, something we didn’t expect may
come up at any time.
But even considering real world driving is unpredictable we can make a distinction between two
major driving environments: urban areas and countryside roads. In both environments, unexpected
situations may show up, making them equally unpredictable, but there is a major difference between
them: the frequency at which unexpected events do happen, and the frequency at which the drivers
expect anything unpredicted to happen. The road environment itself sets the scenery: in urban areas,
there are zebras, sidewalks, buildings, people all around, parked cars, side streets, lower speed limits.
All of these elements contribute to keep the driver concentrated on the road in an attempt to
prevent accidents, because the driver is always counting on something to happen. In contrast, on
countryside roads, there are few distracting elements, usually the pavement is smoother, the curves
are gradual, the speed limit is higher (although usually not as high as drivers would desire!), any
unexpected obstacles, like sharp elbows and crossroads, are signaled in advance and the driver tends
to assume that no unexpected events will happen. This kind of road environment can be called
“monotonous”, in the sense that is eventless (the driver only has to keep the car on the correct lane
and maintain a constant speed) and the driver tends to expect it to be eventless. We shall therefore
consider the driving environment in countryside road “monotonous”, in opposition to urban areas,
where boredom is certainly not a feature.
2.3. Vigilance and fatigue It is common to associate monotony problems related to driving and road safety to tiredness and
sleepiness caused to the driver. Driver fatigue is frequently associated with sleepiness only [Stee04],
but other aspects like the monotony of the task must also be taken into account. Several studies
made by the road safety scientific community associate diminished driving performance to driver
monotony while driving an automobile [Stee04]. However, because monotony is a complex condition
with implications in the nature of the monotonous task and the physiological and psychological
(boredom) dimensions of the person, it is very complicated to separate clearly between monotony
and other similar related factors (such as drowsiness and fatigue). In spite of that, it has already been
shown in the past that performing a monotonous task causes a drop of vigilance over a period of
14
time [TB03]. If the driving task becomes monotonous, it can be expected that the attention that the
driver devotes to the road and to the driving task drops over a period of time.
Different definitions of concepts concerning monotony are often used in a way that causes
confusion, because of the similar meanings given to them. For the sake of comprehensibility, some
terms and concepts will be explained first. This distinction is based on the works of Lyznicki et al,
Pribram and McGuiness and others – for specific references, see [TB03]. There are two perspectives
in vigilance: one is related to the physiological processes, considering wakefulness; other is related to
the psychological behavior of the driver, considering sustained attention. Tiredness generally impacts
on both these perspectives simultaneously. Fatigue is a general term that reflects a decreased
capacity to perform, a state that alters vigilance and alertness, diminishing the driver’s ability to
perform tasks like driving. Vigilance, on the other hand, is the ability to maintain sustained attention
to a task being performed within a particular road environment.
Both vigilance and fatigue change with the road characteristics (like geometry, pavement condition
and surrounding environment), and that change can have an impact on driving performance,
affecting alertness, driver arousal and his ability to process information. A road that is under‐
demanding, eventless and has little or no traffic can cause a drop in the drivers’ attention. This
phenomenon can increase with such factors like night driving and the resulting drop in environment
visibility, and can be attenuated in roads with a dense surrounding environment, more cars and
higher traffic (like urban stretches of motorways). This implies that both the driving task
characteristics and the surrounding environment are essential when assessing the driver’s attention
levels. Nelson [Nels97] mentions that the lack of stimulation while driving is a relevant issue in
fatigue‐related accidents, emphasizing that “it [fatigue] is no longer regarded solely as something
within the brain (…) it depends of what you are, what you are doing and where you are doing”
([Nels97], see [TB03]). This leads one to consider the idea of task‐induced fatigue, and the concept of
monotony associated with the driving task.
2.4. Monotony and habituation Monotony in a task can be presented taking into account the nature of the task and the situation as a
whole. McBain, in [McBa70] (see [TB03]) considers a situation to be monotonous when the stimuli
remain unchanged or change in a predictable way over a given period of time. O’Hanlon in [OHan80]
(see [TB03]) refers to monotony as a situation where sensory stimulation is constant or highly
repetitive. In [Wert91], Wertheim points out that both monotony and predictability have a major
impact on driving performance. Cabon associates monotony to two components: task monotony and
the person’s internal state of monotony ([Cabo92], see [TB03]), the first referring to simple actions
15
taking place in a repetitive manner over long periods of time and the latter referring to the inner
changes that these repetitive tasks produce on the person performing the tasks. These psychological
changes consist mainly of a feeling of boredom and drowsiness [TB03] and, together with a loss of
interest in performing the task at hand, it can affect the driver’s ability to process information by
altering his vigilance.
Driving in a monotonous environment can be viewed as a vigilance task (O’Hanlon and Kelly 1997,
see [TB03]). Others have associated it to sleepiness and sustained attention – “the ability of
maintaining visual vigilance and reacting quickly decreases with increased levels of sleepiness”
[TB03]. It could be also viewed under arousal theory considerations, considering performance to be
poor when arousal is either weak or very strong (Davies and Parasuraman 1982, see [TB03].
However, driving in a monotonous environment can be viewed from another angle – taking
habituation theory into account. On the light of this theory, vigilance and alertness can be altered
because of habituation – the central nervous system tends to habituate its reactions to repetitive
stimulation, leading to a progressive decline in detection rate over time during vigilance tasks.
2.5. Highway hypnosis The concept of highway hypnosis is used to define a condition occurring in drivers in monotonous
highway driving. This term was used by Shor and Thackray in [ST70], being described as “the
tendency of the automobile driver to become drowsy and to fall asleep during monotonous,
uneventful highway driving”. Remembering habituation theory, this can be associated with
habituation to repetitive null stimulation, leading to a drop in detection rates and eventually to an
inattentive state which could severely influence the task of driving.
Two competing theories are suggested to better explain the concept of highway hypnosis. Wertheim
proposes a hypothesis based on the idea of controlled versus automatic attention [Wert91].
Controlled attention is associated with perception, sensorial feedback, while automatic attention is
based on a automatic internal process where feedback is no longer essential. What this means is
that in roads where the driving task is too easy and too predictable, the driver will enter “autopilot
mode”, restricting the search for external feedback, leading drivers to fail detecting and acting on
slowly developing errors (such as steering bias/tendency to approach the shoulders and changes in
the speed of surrounding vehicles or the own vehicle itself). Kerr’s theory proposes a different
concept, DWAM [Kerr91] – Driving Without Attention Mode – which is similar to highway hypnosis.
DWAM often occurs in situations where drivers have difficulty in remembering details occurring over
long driving periods. According to this theory, under monotonous road conditions, in the absence of
external stimuli, drivers shift from external to internal stimuli, becoming less conscious of what is
16
happening on the road and driving according to an internal model of what he or she considers to be
the driving task at hand, taking into consideration not what the environment presents, but what he
or she expects it to present.
2.6. Research aims – distraction & monotony In this chapter distraction is mentioned as a factor that can compromise road safety. Distraction
while driving often comes associated with environment complexity, driver age and concurrent in‐
vehicle tasks. In fact, those were the bases for the previous work of the author [Por06]: it aimed at
observing the effect of concurrent comfort systems usage while driving under‐demanding road
conditions and reaching conclusions about how distracted a driver got from the main task – driving –
while operating the different types of comfort systems. Other authors have made similar
investigations, like Horberry in [Horb06] who aimed at studying the effect of two sources of
distraction in driving performance: in‐vehicle distraction (using comfort systems, cell‐phones, etc.)
and environment distraction (the existence of roadside advertisements, increased traffic flow, etc.).
However, the subject of in‐car telematics and derived distraction usually comes associated with over‐
demanding driving environments. In this work, we try to look at the problem through a different
angle: the distracting influence of comfort systems interfaces usage in under‐demanding road
environments. It is already known that using comfort systems, in certain conditions, may become the
controlled task, rather than the automatic one [BGI03], but, on the other hand, because it demands
an excessive mental workload, it may get the user distracted [Ozk05]. As we discussed previously, we
have been able to see that driving in a monotonous, uneventful road can lead the driver into highway
hypnosis state or DWAM [Wert91], causing him or her to drive according to a mental representation
of what he or she expects the road to be.
In a situation where one is driving in a monotonous road, for a long period of time, and at certain
points in the course he decides to manipulate the comfort systems in some way, how will it affect his
driving performance? Will he or she be paying more attention to the driving task because the
stimulus of manipulating the comfort system acted on him by putting him back into attentive driving
mode? Or, on the other hand, will he completely forget that he is actually performing a driving task
and simply ignore the driving task as a whole, concentrating all of his cognitive skills on using the
comfort systems interface?
This was an option that we were unable to explore in [Por06], because even though we had two
different driving courses, none of them could be considered either “monotonous” or
“unpredictable”. At best, in a long straight in the fast course, one could assume there was plenty of
time to perform any desired task using the comfort systems. Or, in absence of a task, he could
17
accelerate and drive through the stretch faster. In the sinuous course, the driver simply knew he had
to be extra careful, because a new elbow turn could appear sooner than expected.
In this work, a comparative study was conducted, introducing monotony as the main characteristic of
the course. As before, the influence that the usage of comfort systems interfaces has on driving
performance continued to be investigated. This implied the need to expand the simulator to
adequately support the new function, with the introduction of a new behavior for the vehicle, more
tolerant to mistakes and enabling a more subtle performance. It also required the creation of a
monotonous course with unpredictable events occurrence and environment characteristics
demanding some degree of attention, as well as adapting the simulator to record the data for further
analysis.
18
3. Interface Usability The variety of interfaces for comfort systems (as well as the wave of integrated interfaces itself) did
not come out by accident. Even before they were actually available on the market, investigators have
been concerned about the usability of comfort systems while driving, eventually leading to the new
breakthroughs in technology available today (and in days to come). The following sections will
discuss interface usability and particularly comfort systems interfaces usability, introducing problems
brought up by the scientific community and solutions already in place in production systems, as well
as discussing ways to evaluate interface usability, namely by using simulators to recreate driving
tasks and environments.
3.1. Usability of incar telematics and interfaces Different research projects aimed at proposing new solutions for managing control of in‐vehicle
comfort systems and in‐car telematics. They measured pros and cons of several ideas, some of them
produced mixed feelings about the feasibility and usefulness of such solutions. Research focused
mainly on the trend for screen and menu navigation systems, the use of haptic feedback in the
switches, knobs and dials used for control and alternative non‐visual control solutions, namely voice
control.
3.1.1. The need for vision in using comfort systems
As can be seen from the next chapter, most of the solutions for integrated control of the vehicles’
comfort functions rely on both vision and touch; in this, they are no improvement relatively to the
traditional interfaces found on older cars. Recent versions of all these systems add voice as another
input and output method (at least for limited functionality) and other manufacturers include voice
recognition in not‐so‐integrated interfaces – in fact, manufacturers start to offer complete voice
control solutions, like Ford’s V2C and even BMW with its Voice Recognition systems, showing that
integration may solve some problems, but it is not the solution.
However, most of the control over the comfort systems still relies on vision and touch – either in
traditional interfaces, by finding buttons and pressing them or in integrated interfaces, by using
whatever device to navigate on a menu structure and visualize what is being done – and a
consequence of such need is distraction. Distraction was discussed in [Por06] and relates to the
human inability to do two things at the same time. In what concerns the driving issue, and recalling
Bengtsson et al in [BGI03], a driver can do two simultaneous tasks if one of them is done in an
automatic way while the other is being done in a controlled way. An example of this is the ability to
talk to passengers while driving –driving being the controlled task (on which the driver is completely
19
focused) and talking the automatic task (in which he is mostly a passive agent). In what concerns to
certain car instruments, their control is also done in an automatic way – the brain instinctively tells
the driver to activate the direction lights when turning in a crossroads; however, in certain complex
tasks like searching for a specific track on a CD album there is significant mental load making the task
not automatic, thus inducing distraction to the driver [Ozk05]. This is a major issue because if
controlling comfort functions interferes with driving – through distraction – then these comfort
functions are compromising safety driving [BGI03].
3.1.2. Haptic switches, voice control, notsolelyvisual control and feedback
Investigation concerning the use of haptic switches to control in‐vehicle equipment has been around
for a while. Bengtsson et al, in [BGI03] performed a comparative study between the traditional
knobs‐and‐switches interface of a vehicle and a proposed interface for the same functions (audio and
climate control). The study was made with use of a simulated interface mounted on a production
vehicle, and consisted of having drivers perform different tasks through use of both systems, one at a
time, and measuring, with 3 levels, the degree of task completion (from 1‐failure to 3‐success). The
conclusions were that “the participants’ degree of task completion improved with the haptic/graphic
interface concerning the more complex tasks” but, on the other hand, task completion was “slightly
slower with the haptic/graphic interface” and it was noted that participants “looked considerably
more off the road with the haptic/graphic interface”. They also noted a difference between «newer
drivers» (those with a driving license less than 10 years old) and those who have been driving for
longer than 10 years in that newer drivers tended to complete the complex tasks in equal times using
both systems. Their conclusion is that none of the systems is preferable as a rule; whereas the
traditional interface appears to be safer, as it causes less diversion of gaze from the road, the
haptic/graphic was regarded as imposing less mental workload.
In a follow‐up work, Grane and Bengtsson took the study of haptic/graphic interfaces to a higher
level by attempting to compare three types of interfaces: using only haptic information, only
graphical information, and using both. This was studied outside the context of a car or car simulator,
aiming exclusively at studying the influence of the three types of interfaces in user performance: the
purpose was to compare how well participants could discriminate a target in a simple menu selection
task. This was evaluated based on completion time, error rate and mental workload (measured with
specific questionnaires), and the conclusions the authors reached are that case H (haptic only)
participants have a number of turn errors (passing the desired menu option without selecting) higher
than the other two cases and longer task completion times, case HG (haptic and graphical)
participants yielded significantly lower mental workload then both case H and case G (graphical
only); summing all up, case HG provided the best results, haptic‐only feedback obtained the worst
20
results. Grane and Bengtsson propose a distraction study for a natural continuation for their study,
using a driving task and performing some haptic feedback task as secondary task.
Voice control has been mentioned as an alternative for quite a while, and nowadays it has started
appearing in some production vehicles, such as the Ford C‐Max (featuring the Ford Voice to Control –
V2C system, see [Ford07]) and the BMW 7 series (featuring the BMW Voice Recognition system, see
[BMWwA] and [AutoWe00]). But even before they started to be a trend in production cars, studies
have been made comparing speech input and manual control. Graham and Carter, in [GC99], made a
comparison study between speech control and manual control on a mobile phone and using the ICE
application (used by Jaguar in their S‐Type vehicle to control comfort functions). The motivations for
this study were that “dashboard real estate available (…) is very limited”, making it difficult to
provide complex information and feeding back the results of control operations to the driver and
that, obviously, controlling the comfort functions is a secondary task and the driver should always
concentrate on the primary task – driving. The authors considered that the use of ASR (Automatic
Speech Recognition) and speech output could show a number of advantages: both being hands‐free
and eyes‐free, it should be less of a distraction element to the primary task; the act of speaking,
being a “natural, everyday activity”, should be better accepted by users and involve less mental
workload. The conclusions reached with this study were that speech input caused less driving errors
than manual control while using a mobile phone, and also that manual control required a greater
mental workload. However, task performance was significantly worse using voice input, mostly
because of limitations in the voice recognition system. Since then, ASR systems have improved, and
the conclusion that speech recognition is easier to learn has probably been one major cause for the
adoption of voice control by manufacturers.
Considering both previous studies and industry trends, there appears to be a consensus in that it is
necessary to steer away from the traditional touch/sight interface in a way to diminish the time
drivers spend not looking at the road and to lower the mental workload of manipulating in‐vehicle
functions. It is important to notice, however, that just not having vision as the main sense used for
control does not necessarily mean the interface causes less distraction. In this matter, Özkurt
remembers that driver distraction may not be exclusively visual – it can show up in other ways.
When, for example, the driver searches for a specific button on the dashboard, avoiding to look at it
as to keep the eyes on the road (for examples, by counting buttons until the right one) he is
distracted in the same manner, because his or her brain is focused on the searching task rather than
on driving – experiencing something that can be called “looking without seeing” [Ozk05].
21
3.2. Comparative study between some production systems Together with usability tests of devices used to operate integrated (or traditional) comfort systems
interfaces and considerations on their use being or not of benefit, the next step is to compare some
production systems with each other. In [TJT05], Thatcher et al performed a comparative study
between BMW iDrive, Audi MMI and the Jaguar system. As mentioned before, both iDrive and MMI
are based on a LCD screen for viewing and a rotary switch and auxiliary buttons for control1; on the
other hand, the Jaguar system uses a touch screen for interaction, along with several buttons.
This study was made with actual vehicles during “a 20 minute driving route, mainly motorway” in
Sweden involving cars of the 3 referred brands (no models mentioned) and included, besides the
actual driving task, performing a list of 10 tasks in sequence. The study involved 4 persons (2
beginners who didn’t get to be trained to the systems, and 2 trained users who were instructed on
the systems to use). On a second stage, a usability inspection was made by six professional
evaluators in the area of HMI – Human Machine Interaction – consisting on a Nielsen’s heuristics
evaluation of the three systems [Niel94].
Tests with users showed that with the rotary switch systems (iDrive and MMI) tasks took almost the
same time to carry out for the beginner and the trained groups (with the exception of the first and
more complicated task, navigation input, done with the car stopped). Some tasks were more difficult
for the beginner group, but the difference was not generally significant. An important note was that
the operation of the Jaguar system (based on touch screen) by beginners was significantly easier
then the other, while the iDrive rotary switch (which concentrates more functions) seemed to be the
most difficult to operate; however, for the trained group, the operation of all three systems seemed
to be of a similar difficulty, and much easier than for the beginner group – in fact, for the trained
group, the iDrive system was best classified in their time‐to‐task‐completion metric. Thatcher et al
consider that it is possible that a touch screen interface is more intuitive to new users, but for trained
users the rotary switch systems are just as effective.
They advise against some limitations on their conclusions, like the need to evaluate eyes‐off‐road
time (which they did not) and propose a more controlled experiment between touch screen and
rotary switch interfaces. Whatsoever, it is important to emphasize that beginners perform poorer
than trained users, and that they did the study in a motorway but, considering that they were using
real automobiles, certain aspects were not taken into account, like the effect of monotony motorway
driving could have caused to drivers.
1 Although not mentioned, the iDrive version used in this work is not the 2002 one and, by the pictures and comments, it appears to be the 2004 version, which includes many improvements to the original version.
22
3.3. User categorization in this work When discussing users it’s common to classify them, among other factors, according to the level of
previous contact with the interfaces tested or interfaces similar to the ones considered. It is usual to
split users in 2 or 3 levels, typically the pair naïve and trained, as in [TJT05], or the triplet
beginner/average user/expert. In the first case, the division is usually based on whether the user has
had none or superficial contact with a given interface (naïve/beginner) or, on the other hand, the
user has been taught how to use the interface (trained user); the second case is more frequently
used where it is convenient to distinguish between a regular user, who is able to use the interface to
achieve his goals (the average user) and a power user who, beyond knowing how to use the
interface, has a deep knowledge on its usage, knowing tricks and shortcuts that provide for more
efficient usage (the expert). While the former division can be used in most interfaces, the latter case
is frequently used when studying the usability of computer applications and systems.
The interface considered for this work is composed of 2 parts: the driving interface and the comfort
systems interfaces. Knowledge of these two interfaces varies and it is important to classify the users’
ability in using one separately from the ability in using the other.
The users in the usability tests had one imperative pre‐requisite: they must bear a driver’s license.
Considering that the issue with monotony while driving concerns to a particular situation in the
driving task, in which the adequacy of the driving interface is not at stake but instead the interface is
to be considered as “the interface”, it felt important that the users where pretty much accustomed
to it’s usage; also, the need to know some basic driving concepts and rules (for example, the need to
know which lane to take, what traffic signs mean, etc.) implies that the users should have an intuitive
knowledge of the driving task, hence the need for users who actually drive and are qualified to drive.
This said, it can be assumed that users are already familiar with the usage of a steering wheel and
pedals, except for sensibility differences of the devices in this particular simulator, which means that
after an adaptation period all the users can be considered as trained users for the driving interface.
Another argument for this is that the driving interface in the simulator is actually simpler than the
one in a typical automobile – at least in Portugal, where most vehicles use manual transmission,
whereas the simulator used automatic transmission, eliminating the clutch pedal and the need to
change gears.
There are several aspects to take into account when considering interfaces for the comfort systems.
First, and most importantly, these interfaces try to recreate the ones actually used in production
vehicles, but they are not fac simile: there are fundamental differences, mostly because of limits of
the emulation technology used ‐ the traditional buttons are emulated with a touch screen which only
allow to press buttons, not dials or switches; the integrated interface is emulated with a joystick
23
which allows only limited, and necessarily different, motion patterns. Also, limited functionality is
provided in these make‐do interfaces, especially because the functionalities available are the most
frequently available and used in production cars and are the ones it was chosen to consider in these
tests. Secondly, when comparing the integrated and traditional interfaces, it is a fact that traditional
interfaces are easier to use by untrained users (as discussed previously) while the learning curve is
larger with integrated interfaces. Additionally it should be noted that the issue of monotonous
driving conditions typically occurs in situations where the driver is using his own vehicle and to which
he is familiarized, making the beginner/trained user duality particularly irrelevant for the matter.
Taking these ideas into account, it was chosen not to differentiate users in this aspect, training every
user for the usage of both comfort systems interfaces, and being particularly careful with the
integrated interface to insure proper knowledge of it so as not to bias the test results.
In conclusion, it can be said that the users in this experiment were trained and experienced
concerning the driving interface and trained but inexperienced concerning the comfort systems
interfaces. This implies that differences in task performance while using the comfort systems were
considered as differences between individuals and thus implying the need for adjustments to the
number of times a task is performed in each case, given the need for a certain amount of time using
the interface to test for implications in the driving task.
One final word to the fact that this simulator has already been used in a previous work: although
some of the users had previously used the simulator, such usage didn’t mean the users where
accustomed to it and much less that their usage of the interfaces was better than its usage by users
who had never used it, and even these users had to get used to the driving interface, as well as
trained in both comfort systems interfaces, to get enough knowledge to enable them to correctly
participate in the usability tests.
24
4. Comfort systems interfaces Interfaces for comfort systems are one of the main subjects of this work, since it aims at studying the
influence of their use in driving performance in monotonous road environments.
4.1. Basic concepts Before introducing some of the interfaces for comfort systems available in the industry, it is
important to explain some concepts which will be used throughout the text. Taking into account the
proposed definitions by Burnett and Porter, in [BP01], and Bengtsson et al, in [BGI05], one can
distinguish between two different types of devices available in automobiles:
• Driving assisting devices (primary devices): those directly affecting the driving task and driver
performance. These devices include the steering wheel, gearbox, pedals, blinker lights
handle, etc.
• Comfort devices (secondary or auxiliary devices): those targeted at improving the driving
experience but having no direct impact in it. Examples of such devices are the radio,
navigation systems, air conditioning system, etc.
The proposed work concerns these secondary comfort devices, and the usability of the interfaces
used to control these devices. These interfaces can, in turn, be divided in two major types, according
to Porta Nova in [Por06]:
• Traditional interfaces: characterized for having most of the commands located in the
dashboard central console, consisting mostly of handles, buttons and knobs which are
geographically separated according to the device they control, without integration between
them;
Figure 4.1. Examples of interfaces for comfort systems: traditional (left) and integrated (right).
25
• Integrated interfaces: these represent the latest trend by automakers, grouping the control
of several comfort systems into single, integrated interfaces, resembling a computer system:
typically, one finds a screen (and/or windshield image projection) supplying visual feedback,
and a joystick‐like rotary switch, touch screen or several buttons to control the interface,
much like in a WIMP computer interface.
4.2. Comfort functions and incar telematics The use of electronics in car has become generalized in recent years, and nowadays electronic
components, computer chips and wiring make much of a car’s total components. Electronics come in
different flavors, like fuel injection control, wheel blockage avoidance (ABS), traction control (ESP),
drive‐by‐wire mechanisms such as ETC (Electronic Throttle Control) and brake‐by‐wire, and even
malfunction diagnose through sensors placed in critical places – much of the car’s behavior is now
controlled by computers. And electronics don’t just stick to that – they are also there to provide a
more pleasant experience to its driver, by giving him entertainment and comfort. Nowadays, almost
every car has at least some of the devices/functionalities presented below:
• Car radio / sound system (including cassette or CD players);
• Air conditioning/climate control;
• Inside and outside thermometer;
• Navigation system/GPS;
• Video entertainment system (TV tuner, DVD player)
• Cell phone dock (or similar gadget) and hands‐free conversation equipment;
• Interface for portable MP3/audio players (typically used through the car radio).
These devices are the comfort equipment or comfort functions of a car. The presence of these
functions aims at keeping the driver happier while using his car by supplying him with a sense of
comfort and fulfilling his desire to be entertained – especially if he is doing some sort of monotonous
or tedious task such as commuting, waiting on a traffic jam, driving people around, … Electronics also
aim at fulfilling the same needs of car passengers, who tend to face travelling time more positively if
they are entertained.
The presence of these equipments carries the need to interact with them, to control them and
instruct them to do whatever we please. As the number of functions increases, so does the amount
of time and the concentration we need while operating them, and the complexity of some of these
functions provides the grounds for time‐consuming interaction.
26
4.3. Traditional interfaces for comfort systems Nowadays cars tend to come with dashboards full of buttons, switches and knobs allowing the driver
– mainly the driver – to control whichever equipment is available. These take up much of the space
available in the dashboard between the steering wheel and the glove compartment, and as the
number of such buttons increases, their size tends to decrease. Looking at these dashboards can
make the choice of the correct button baffling, considering the driver has a limited amount of time to
make such choice – otherwise one could hit another car or run over some old lady on a zebra.
Burnett and Porter [BP01] consider “there is a danger that drivers of the future will be overwhelmed
by all the functionality on offer within their vehicles” and that, in the worst case, the drivers’ ability
to control their vehicles safely may be at stake. Besides, using this sort of interfaces relies mostly on
sight (for locating the correct button, knowing how to handle it and making sure the right thing was
done), and this is an issue both in traditional and integrated interfaces, making this a risk factor in
using comfort systems while driving.
4.4. Integrated solutions used by the car industry Automobile manufacturers have been using integrated solutions for a few years now. These solutions
attempt to provide a unique interface for some or all of the devices previously mentioned. Most are
based on some scheme of menu navigation with visualization on a screen and controlled by buttons.
The most important systems around are the iDrive by BMW, the COMAND by Mercedes‐Benz and
the MMI by Audi. The following provides a brief analysis on what these systems do, the concept
behind their creation and their pros and cons. These systems do not only attempt to integrate the
interface but to make it easier and safer to use the comfort functions, especially while driving.
4.4.1. iDrive
The iDrive system was developed by BMW with the goal of reducing the amount of buttons and
different commands available in automobiles [Day04]. This system replaces the traditional buttons
and knobs with a centralized interfaced based on a dial, a few auxiliary buttons and visual feedback
via an LCD screen. BMW clearly distinguishes what is to be controlled and what is not to be
controlled by iDrive, separating secondary devices (mostly controlled by the latter) from primary
devices (controlled by specific buttons and knobs). Its first version came on the market in 2002.
The iDrive makes use of a dial – or a joystick‐like button – with haptic feedback (the Controller) to
navigate an hierarchy of menus that allows the user to control most of the comfort systems, among
which the audio and video entertainment systems, the climate control, navigation system (GPS), On‐
Board Diagnosis, the park‐assist function, a battery discharge alert indicator, cell‐phone functionality
and car manual. Recent versions of iDrive also allow for voice command (in some versions, as an
27
option) allowing the driver to perform some operations hands‐free, and provide voice output,
namely for the navigation system.
According to several authors, namely Day in [Day04] and Brauer in [Brau04], the main reason for the
failure of the first version of the iDrive was the excessive concentration of functionalities as well as
the variety of ways one could manipulate the Controller. As an example, [Brau04] refers that tuning
into a specific radio station “requires scrolling through multiple LCD screens”, and the problem is
generalized: any and every task to perform required the user to navigate through multiple menu
levels. Also, as referred in [Day04] the multiple ways in which one could slide the Controller (8, all the
cardinal and intercardinal directions) and the different actions that could be performed (slide, press,
rotate) contributed to a learning curve that could go to weeks or months, leaving highly unsatisfied
customers. This also led to the listing of the 2002 BMW 7 series as one of “The 50 Worst Cars of All
Time” (sic) in [Time07], the iDrive system being the main reason for its appearance on the list.
Meanwhile, most of the major iDrive flaws have been corrected with the addition of shortcut keys
(back and return to menu) and the systems as a whole is presently (2007) being redesigned. The
errors by BMW and Mercedes (with their COMAND system, whose description follows) were useful
for other manufacturers, such as Audi and, more recently, even Mercedes, who redesigned their
products using similar approaches to that of the improved iDrive.
4.4.2. COMAND
The COMAND system (COckpit MAnagement and Navigation Display) was developed by Mercedes‐
Benz in 2000 (before the iDrive system came along). The goal for its development was the integration
of the comfort functions in a single interface, for the higher model ranges. The system consisted of a
LCD screen for visual feedback and a large set of buttons through which the system was to be
Figure 4.2. Overview of the iDrive system on a BMW 7 series (left) and two versions of the Controller: the original one, available on the 7 series (right‐above) and the one available on the current 5 series (right‐below).
controlle
function
Besides
number
and a ro
steering
audio an
control i
The majo
the cont
concent
P
Figure
ed. Unlike B
s, but COMA
the LCD scre
keys (among
otary volum
wheel for d
nd video ent
s done elsew
or handicap
trol layout [B
rate such fun
FigurPhoto of a con
e 4.3. Overview
MW, Merce
AND only had
een mentione
g others, for
e on/off bu
direct access
tertainment
where in a de
of the COMA
Brau04]. Alth
nctionality in
re 4.4. Picturensole includin
w of the COM
des didn’t e
d control ove
ed, the syste
r cell‐phone
tton. Along
s to some fu
systems, th
edicated con
AND system
hough it was
n a single int
of a COMANDng the COMAN
MAND system (
xplicitly refe
er these func
em resorts to
integration),
with these,
unctions (lik
e navigation
nsole, as can
was the she
s a pioneer i
tegrated inte
D Console usiND Console an
(2007); notice
er to COMAN
ctions.
o an extensiv
, arrow keys,
, other func
ke volume co
n system and
be seen in F
eer volume o
n the area,
erface, it was
ng the navigand the climate
e the similarity
ND as being
ve keyboard
, context but
tion keys w
ontrol). The
d the cell‐ph
Figure 4.3.
of buttons av
being the fir
s too conserv
tion applicatioe control cons
y with the iDr
exclusive to
– with funct
ttons next to
were availabl
system con
hone system
vailable that
rst system to
vative in the
on (left). ole below (rig
rive Controller
28
o comfort
tion keys,
o the LCD
e on the
ntrols the
. Climate
made up
o actually
e solution
ght).
r (right).
29
for user command, creating a solution that not only did not decrease the number of buttons on the
central console but made using the system very complicated because of the added menu‐navigation
complexity. This created a “confusing setup”, according to Wardlaw in [Ward07], and made the
system very hard to use – especially while driving.
Aware of these limitations, Mercedes rethought the system completely, getting inspiration from the
iDrive but, again quoting [Ward07], “though it takes cues from BMW’s iDrive arrangement, it’s much
more intuitive to use if not easier”. A video demonstration on the functionality of the new COMAND
interface is available in [eMer07]. The nowadays COMAND also supports voice input and output for
some functions, as can be seen in the previous reference.
4.4.3. MMI
The MMI system (MultiMedia Interface) was created by Audi with the purpose of integrating comfort
functions in all of their model ranges. It was firstly released in 2004 in the A8 model range [Brau04]
and, as in the other competing systems shown earlier, aims only at controlling the comfort functions
of the vehicle.
Much like the iDrive and the newer versions of the COMAND, MMI makes use of a LCD screen for
viewing and uses a knob or rotating button for menu navigation, but goes further ahead and provides
buttons to control onscreen menu options and provides keys for direct access to the main functions.
Like the COMAND system, MMI controls the audio and video entertainment system, the navigation
system and integrated cell‐phone, leaving the climate control interface out of the package.
Having released MMI roughly 4 years after the first version of COMAND and 2 after the first version
of iDrive came to market, Audi was able to learn from the mistakes these 2 systems made: in this
Figure 4.5. Overview of the MMI on an Audi A6 (left) and detailed view of the A8 controller interface (right).
30
fashion, MMI does not try to focus all control on the rotating knob, providing direct access to
functions to decrease the number of the menu levels, and provides context‐changing keys to
navigate through menus, leaving the knob almost exclusively for controlling values (tuning radio
stations, writing destinations on the navigation system, etc.). Being a compromise between the 2
competitors, MMI has become quite popular. It is said that “MMI uses a «just right» approach to
mixing dials, buttons and LCD menus” [Brau04] and nowadays the 2 pioneer systems tend to
approach the MMI design solution.
4.4.4. Other systems
Besides the previously mentioned systems, other attempts have been made by the industry to
integrate comfort functions in a single interface. The three mentioned above are the most relevant,
but others do exist.
For example, Jaguar uses an integrated system based on a touch‐screen LCD, originally only allowing
control of the navigation system (in the early version available in the S‐Type), but currently providing
control over most of the comfort functions (audio, climate control, cell‐phone and navigation system)
in their models XJ and XK, with the curiosity that the interface is developed in Macromedia Flash
[CarP05] [Newc07].
Other brands like Porsche use, in their most recent models, some systems inspired on the COMAND
system, like the PCM (Porsche Communication Management) provided in their Cayenne model
range. It’s very similar to the original COMAND interface, using a LCD screen for viewing and (lots of)
buttons for control. It allows control of the audio system, TV tuner, DVD player, navigation system,
on‐board computer and connection to telephony services [Porsche]. Climate control is done in a
dedicated console below the PCM, as can be seen in figure 4.7.
Figure 4.6. Detail on the Jaguar Touchscreen interface: early S‐Type (left) and current XJ (right).
31
Other makers have other solutions, but the systems previously analyzed pretty much cover the main
aspects of integrated interfaces for comfort systems.
4.4.5. Addon equipments
There are several equipments, namely navigation systems/GPS and DVD‐Video players that can be
added to vehicles a posteriori. These are usually based on touch screen LCD (most of the navigation
systems) or screens that are connected to the car stereo system. The functionality varies across
models, but in the case of GPS most of them allow input of destination through some sort of on‐
screen keyboard, map display with path indication and sometimes voice indications. Some allow
voice command also. In the case of DVD players, they usually come to be connected to the car radio
and focus on entertainment, providing audio and video playback, radio and sometimes TV‐tuner
functions.
Figure 4.8. Example of a post‐mounted GPS system (left) and a car DVD‐Video player (right).
Figure 4.7. Overview of the Porsche Communication Management (available in the 2007 Cayenne model).
32
4.5. Concluding remarks This chapter presented the distinction between comfort devices and their counterpart driving
assisting devices, as well as the distinction between the concepts of traditional interfaces and
integrated interfaces when applied to the control of comfort devices. A brief tour over some of the
solutions available on the market (specially the ones by Audi, BMW and Mercedes) is also made in
this section.
Integrated interfaces for comfort systems in automobiles use mostly (or are now evolving to start
using) rotary switches to control some sort of menu hierarchy on a computer system providing
graphical feedback through a LCD display, like some computer systems and specially home
entertainment systems now available; however, devices for a posteriori integration in vehicles are
mostly based on LCD touch screens. Voice control is now being introduced to offer further control
possibilities for all of these systems and research is underway along the line of haptic/tactile
feedback (see chapter 3 for this purpose). Although not yet the dominant option for comfort systems
interfaces, integrated interfaces are now in a maturing phase, are well established in the industry
(specially in luxury car brands) and tend to become the dominant type of interface for comfort
systems in the years to come. All of these interfaces are based in the “computer system” metaphor,
or more precisely, in the idea of a WIMP interface; they all focus specially on providing better control
for comfort devices and adding more comfort functions to the ones already available; they have
evolved towards a balance between the number of separate buttons/dials and the number of menu
levels in the application hierarchy (it is interesting to compare the first iDrive and the first COMAND
with the more recent versions of both systems).
The biggest handicap of integrated interfaces for comfort systems still lies on the necessity of
training: as works like [BGI03] and [TJT05] show, the performance for untrained users is lower in
integrated systems than in traditional systems; however, they tend to break even when the user gets
accustomed to using the integrated system. The major advantages in using integrated comfort
systems are the extended options in the number of devices and functions available in the vehicle, as
well as the possibility for integration between devices and communication between them to provide
better functionality – as well as saving space in the vehicle’s dashboard, and lowering the
overwhelming effect on drivers.
33
5. Simulators for usability testing This work’s aim is road safety and the use of the principles of human‐machine interfaces and
computer science in investigating and contributing to the improvement of road safety conditions.
More precisely, this work is concerned with the influence of the in‐car telematics, comfort devices
and interfaces on the driving task, both in a positive or negative way. This subject has been recently
studied broadly, and the explosion of in‐car telematics, along with the ubiquity of other user
electronics (such as mobile phones, portable media players, GPS systems) in the last few years has
driven automobile manufacturers into exploring alternative ways to control these brand new devices
in easier, safer and simpler ways. Along with much more complex devices available, one must take
the road environment into account when evaluating road safety: both roads and driving habits have
changed, and we must consider aspects such as driving in traffic‐intensive roads, driving in
monotonous roads, in different times of the day and with different levels of alertness, and the
implications these differences have in the use of in‐car telematics.
Much of this research has been done using computer auto‐simulations, varying from low‐budget
simulators which resemble computer games to advanced simulators consuming much money and
effort into replicating the driving environment as realistically as possible. The work presented here is
also a simulator‐based investigation, comparing the use of in‐car telematics in monotonous road
environments using both traditional and integrated interfaces.
Some modern cars resort to using integrated interfaces to control comfort devices. They were
discussed in detail in chapters 3 and 4 but, for now, it should be noted these integrated interfaces
are not the solution for all problems concerning user attention issues while using comfort devices –
these solve some of the problems, but add other variables to the equation and can cause more
problems than the ones they solve.
Different studies have been made aiming at two things: first, discovering new interaction techniques
that increase the awareness of the driver, both in terms of correctly interacting with the available
functions and in terms of road and environment attention; second, relating the use of such interfaces
and the driving performance in different conditions.
5.1. Simulator development and usage in the study of road safety issues The use of simulators is current practice today, and much of the research in this area is done via the
use of computerized simulators. Examples of this are the works [GB05], [Ozk05], [GC99], [Horb06],
[Stee04] and [TB03].
34
The simulators used in these works vary from more to less realistic according to such aspects as
budget, availability and objective of the work itself; they can also vary in terms of the object of study
(randomly occurring situations, adverse weather conditions, psychological and physiological aspects
of the driver). Therefore, throughout the latest years, simulators have evolved from the most
primitive versions (such as the display of driving footage, with severe limitations regarding the
simulation itself and the possible reactions by the user/driver) to the more realistic simulators
available today, using top‐of‐the‐notch technology and being extremely concerned about the
visualization’s realism (presenting near‐real graphics and a wide viewing scope), using audio
feedback and force feedback (e.g., on the steering wheel, simulating the road inertia and
imperfections such as pot holes), exhibiting advanced hydraulic systems to simulate the vehicle’s
behavior according to the driving environment and style, and some are actually moving along tracks
to simulate acceleration effects, trying to increase the feeling of actually driving and preventing the
so‐called “simulator sickness” (see [Drap96] on this subject).
The use of simulators carries some advantages when compared to using actual automobiles for these
studies, among them:
• Less costly (at least if the simulator is already available) and less ecological burden;
• Less safety hazards for both the participants and the vehicles involved;
• Greater control over the task: bigger number of desirable situations, which can be
intentionally placed on a test‐by‐test basis, and bigger determinism (the situations desired
will happen, those not wanted aren’t likely to show up);
• Better data logging possible;
• The possibility of testing with users without a driver’s license.
Despite the advantages, the use of simulators also has some handicaps, such as:
• Depending on the demands for the particular study, simulators can be very costly – specially
if one must develop it specifically for a given study;
• In case of budget limitations, one could get stuck with a low‐realism simulator and inducing
user into not taking it as a serious tool;
• The simulator sickness effect previously referred.
In the following, a survey on some of the available simulators is presented, along with their
capabilities and the usage they are given. This is partly inspired in the work by João Ferreira [Ferr07],
which should be consulted for further details.
35
5.1.1. Simulators with actual car bodies and 360º fieldofview
Most of the simulators offer minimum realism: the existence of a course through which the user
navigates, with some realistic features (such as roads, buildings, road signs, random objects, other
vehicles, pedestrians) and control of the vehicle with a steering wheel and pedals (or some similar
device) which can be found, for gaming purposes, in any computer hardware store. One of such
devices was in fact used in our previously developed work, along with a joystick. These aspects are
present in many computer games, and there is a particular one, Streets of Simcity, which can be used
as an elementary driving simulator if one has limited goals for the simulation: this game can be
controlled with a standard computer steering wheel, and courses can be easily developed using
another computer game – Simcity 2000. Taking into account that the game is clearly aimed at leisure,
and remembering that this game was not a particularly successful game, Streets of Simcity has some
serious flaws in its behavior, such as having the vehicle driving through some objects in the scenario,
incompatibility with some features in the scenario (e.g., motorways do not show up as expected), car
behavior issues and others, this is certainly a simulator to be used in a last‐case situation.
Figure 5.1. Outside view (left) and car body detail (right) of the Wrap‐around Simulator (WAS).
The simulators used for research purposes have other features for augmented realism and
immersion. One of these aspects is the use of real car bodies. Simulators like the Wrap‐Around
Simulator from the University of Minnesota (WAS), the UCF Driving Simulator developed by the
CATSS (Center for Advanced Transportation Systems Simulation in the University of Central Florida),
the Driving Simulator Laboratory from George Washington University (DSL) and the VTI Simulator III
by the Statens Väg‐och TransportforskningsInstitut, a Swedish institute studying roads and
transportation) use real car bodies, given away by the manufacturers or purchased specifically, and
the whole simulator is built inside them, using the car’s own instruments (steering wheel, pedals,
gearbox, …) when desired.
As an alt
occurs s
some sim
make‐do
Cranfield
Renault
helmet
augment
Figure 5.
On the
(scenery
case of t
similar t
reality a
As an a
dashboa
used by
driver, t
and instr
5.1.2. S
Audio an
increase
available
ternative to
ometimes. T
mulators allo
o. Examples
d University
ULTIMATE D
to create t
ted reality.
.2. Arriva Simu
side of visu
y projection)
the WAS sim
echnologies,
ll around thr
lternative, s
ard (or part o
Strayer and
he other tw
ruments from
Simulators
nd haptic/ta
ed driving re
e set of m
real car bodi
These car bo
ow the use o
of such simu
(which can
Driving Simu
he scenerie
ulator, one of
ualization, si
outside the
ulator), to co
, producing
rough the sim
simpler solut
of it) from an
d Dreys in [S
o slightly tilt
m a Ford Cro
s with audio
actile feedba
alism. Hapti
ovements f
ies, sometim
odies are cre
of more than
ulators are t
be used bo
ulator which
s – thus op
f the possible
mulators us
e car body,
oncave scree
a realistic vis
mulator car b
tions such a
n actual prod
SD04], wher
ted on each
own Vitoria a
o and hapti
acks are tech
c feedback c
from compu
mes car bodie
eated with th
n one body,
the Driving S
oth with an
, besides ha
perating in
configuration
sing car bod
using video
ens (the solu
sualization e
body.
as the use o
duction auto
e the scene
side of the
automobile a
c feedback
hnologies be
consists, in t
uter steering
es are specifi
he same lev
according to
Simulator of
automobile
aving its own
a mode clo
ns for the Cran
dies usually
projectors o
ution used in
effect in whic
of N monito
mobile, as is
is viewed i
front one) a
are used for
eing used in
the most ele
g wheel an
ically develo
el of detail a
o the vehicle
the School o
and a bus/
n car body,
osely related
nfield Univers
implement
over spheric
the Cranfiel
ch the drive
ors associate
s done in the
n 3 screens
and a dashb
control and
videogames
ementary ap
nd joystick
ped for the s
as the real o
e type one w
of Engineeri
/truck body)
uses a virtu
d to the co
ity’s Driving S
the graphic
al domes (th
ld simulator)
r can see a p
ed with the
e PatrolSim s
(one in fron
board, steerin
look‐and‐fee
s and simula
pproach, in u
libraries (e.
36
simulator
ones, and
wishes to
ng of the
and the
al reality
oncept of
Simulator.
s display
his is the
) or other
projected
use of a
imulator,
nt of the
ng wheel
el.
ations for
using the
g., using
37
DirectInput). However, most simulators take the concept beyond this point, using elaborate
techniques to provide increased realism.
Figure 5.3. Outside view (left) and usage demonstrations (right) of the UCF Driving Simulator, using an automobile car body.
WAS, for instance, uses a specifically developed engine providing force feedback to the steering
wheel (both for road conditions and inertia) and the whole car body (for road conditions), as well as
using a sound bank for audio feedback; the Cranfield simulator uses audio feedback only; the UCF
simulator has the car body mounted on a hydraulic support that, in coordination with the simulation
software, can mimic the movements the vehicle would supposedly perform should the simulator be
an actual car; the DSL simulator uses an engine to simulate steering wheel inertia and audio
feedback.
5.1.3. Simulator using advanced physics (to handle simulator sickness)
In addition to haptic feedback systems, some simulators have advanced mechanisms to handle the
simulator sickness effect and increase the user immersion while using the simulator.
Two such examples are the NADS Simulator (National Advanced Driving Simulator, developed by
NHTSA (National Highway Traffic Safety Administration) in cooperation with the University of Iowa
and the VTI Simulator III, mentioned previously. They implement vehicle acceleration by moving the
simulator along rails (the movement occurs in 2 dimensions on the NADS Simulator and in 1
dimension only on the VTI Simulator) and, in association with a 360° rotation in all the 3 axis, enable
the simulator to recreate the feelings of movement and vibration sensed in real driving, reducing the
incidence of simulator sickness. This is done in association to mechanisms to transmit realistic
behavior to other elements such as the steering wheel (e.g., through force feedback).
5.1.4. Simulators that monitor physiological data
For some purposes there are simulators that use tools not destined to increase realism in the
simulation but instead to obtain physiological data from users participating in the study, while they
38
drive. For this, the DSL uses an eye monitoring system using an eye sensor to register data on where
the user is looking at, the pupil dilation, frequency and duration of eye blinking, among other factors;
the WIVM simulator (Würzburger Institut für Verkehrswissenschaften – a German transportation
sciences institute) has tools to elaborate electrocardiograms and electroencephalograms to register
heart and brain activity in response to stimuli produced during the simulation.
5.1.5. Simulation software
The previously described simulators were created, in some cases, by reusing some previously existing
tools. Therefore, some of them use generic driving simulation software products that can adapt to
the control devices and imagery mechanisms desired. The list of products includes the STIsim driving
simulator (used by both the Cranfield simulator and the DSL) and SILAB (used by the WIVM
simulator). Other simulators use specifically devolped software, such as the WAS, using a C/C++
application built on top of the SGI Performer and Multi‐Gen Paradigm Vega APIs, with custom‐made
sceneries.
Figure 5.4. Outside (left) and inside view (right, using a jeep body) of the NADS simulator.
5.1.6. The simulator used in the present work
After describing some of the simulators used for investigation purposes it is time to refer to the
simulator developed by and used in the author’s previous work, and which was modified for the
current work. This is a low‐budget simulator completely developed by the author and it does not
intend to rival any previously presented simulators; however, this particular simulator offers some
possibilities making it useful for usability studies relating to the use of in‐car telematics interfaces –
the subject for which it was developed in the first place.
The purpose of the simulator was to carry out usability testing on two types of comfort systems
interfaces (traditional and integrated) associated with a driving task. The driving task was performed
on an urban scenario with two predefined courses. The comfort systems controlled were the
radio/sound system and the climate control; the traditional interface was based on a 2‐console set
with but
and me
wheel.
The simu
screen, c
3D joyst
was dev
keyboar
Complem
3.4Ghz,
feedbac
Figu
5.1.7. P
All the s
less reso
because
aspect is
because
devices
mimic th
to consid
their use
The desi
that sim
in real‐li
ttons only, a
nu navigatio
ulator itself l
control throu
tick (periphe
veloped in C+
d was also
mentos de V
2Gb of RAM
k is used in t
re 5.5. Simula
Partial driv
simulators de
ources and/
of the subje
s to be studie
there is a
on a real ve
he behavior
der these to
e to approac
ignation “pa
ulate some a
ife cars (suc
nd the integ
on). Access
looked like a
ugh a Thrust
rals used, as
++ on OpenG
used for me
Visualização
M memory a
this simulato
ator setup (lef
ving simula
escribed so f
or realism,
ect of the wo
ed (e.g., one
will to mix
ehicle), there
and function
ols “driving s
h the driving
rtial driving
aspects of d
ch as car‐tel
grated interf
to some fun
a computer g
tmaster Ferra
s one can gu
GL graphics
enu navigati
at IST, and
and a nVidia
or. Further de
ft) and examp
ators
far are “tota
to immerse
ork (which m
e may want t
the real wit
e are cases
nality of only
simulators”,
g experience
simulator” i
riving, tools
lematics inte
ace was bas
nctions was
game, with v
ari GT 2 in 1
uess, mainly
and resorted
on. The sim
currently r
a FX Quadra
etails on this
le view (right)
al simulators
the user in
may not focu
to study how
th the virtua
in which so
y certain par
but it make
.
is then used
used in com
erfaces simu
ed on the or
available th
visualization
Rumble ste
for gaming
d to DirectIn
mulator can
uns on a co
4000 graph
simulator ca
) of the simula
s”, in the sen
n a full drivi
s exclusively
w a user hand
al (e.g., app
ome tools ne
rts of the aut
s sense to re
to describe
mbination wit
ulators, befo
riginal iDrive
hrough butt
on a WACOM
ering wheel
purposes). T
nput for peri
be found on
omputer wit
hics adapter
an be found
ator used on t
nse that they
ing experien
y on driving),
dles differen
lying simula
eed to be de
tomobile. It w
efer to them
e these tools
th other sim
ore their ins
e idea (one c
tons on the
M Cintiq 21
and a Logite
The applicat
ipheral inter
n the Labora
th a Pentium
. No audio o
in [Por06].
the previous w
y seek, with
nce. Howeve
, since only a
t steering de
ted instrum
eveloped, se
would not b
in this secti
s. These inclu
ulators or em
sertion in pr
39
controller
steering
UX touch
ech Force
tion itself
raction. A
atório de
m 4 with
or haptic
work.
more or
er, either
a specific
evices) or
ents and
eeking to
e correct
on, given
ude tools
mbedded
roduction
40
cars). There are several examples of partial simulators: the one found in [BG03], where Bengtsson et
al use a simulator made of a screen and a device with a rotary switch capable of reproducing several
tactile stimuli and 2 regular buttons, mounted on the central console of a car; or Graham and
Carter’s [GC99], where users resort to a steering wheel and a pedal set to keep a moving block on a
computer screen in motion, similarly to a driving task, while performing other tasks related to cell‐
phones (in the first part of the study) or using the ICE application, supplied by Jaguar and which is
used in their S‐Type automobiles (in the second part of the study).
41
6. Experiment Setup & Protocol 6.1. Setup The experiment took place at the Laboratório de Complementos de Visualização at IST, using the
simulator developed for [Por06], which was conveniently adapted for this study and described in
section 5.1.6.
Some changes and adaptations were made to allow the simulator to be used in this particular study;
namely the introduction of a new scenario providing an uneventful monotonous course on which to
drive, changes to the physics of the vehicle in order to make it more adjusted to the desired behavior
(for example, altered steering so that curves can be described more gently and more tolerant pedals
to allow for smoother behavior). The logger module was also changed to allow logging of new
variables, as well as some course‐dependent behavior to help data processing (e.g., the separation of
certain parts of the log according to the parts of the course to allow the division of the course
according to the procedure shown ahead). More details on what the changes mean, and images of
the altered simulator can be found further on in this section; details on the technical aspects of the
adaptation can be found in Annex A. Changes to the simulator.
6.1.1. Course characteristics
As mentioned before, the course was created specifically for this works’s usability tests. The new
course was defined so that 2 conditions could be asserted in this test:
1. The driver was entering a state of monotony while driving;
2. The driver had to perform predefined sets of tasks using the comfort systems while in a state
of monotony.
Figure 6.1. The simulator (left); example screen using the traditional (middle) and integrated (right) interfaces.
42
For this to happen the course had to appear monotonous and unchanging, with slight variations in
the surrounding environment to test if the user was aware of some details in the course; some of
these elements are just there to be seen, others are obstacles and action must be taken by the driver
to avoid them.
Thiffault, in [TB03], suggests that uneventful and monotonous road environments are ideal to induce
monotony and tiredness to users. The dimension of fatigue in monotony is necessarily exploited to
create the best scenario for monotony. In this context, [Hawo98] states that fatigue contribution in
monotony‐related accidents occurs, among others, in rural area roads, where the road environment
is less stimulant, roads are often straight stretches and speed tends to be higher; following the idea
used in the procedure for the work in [TB03], a rural two‐lane road with repetitive characteristics
was the chosen option.
The presence of visual clutter resulted in lower speeds in the experiment described in [Horb06].
According to the authors, visual clutter and increased details on the road environment forced users
to slow down to have more time to process the extra information. Because one of the goals with this
experiment was that users did not need to process more information than necessary – thus
increasing the boredom and monotony in driving – a scenario with less “highway furniture” [Horb06]
was considered the best approach for this work.
The course has a first part, used for the introduction phase, consisting of an urban scenario similar to
the one used in [Por06]; the second part is a monotonous part, consisting of a rural road scenario
with small turns and features. The course consists of a dual‐lane single‐carriageway in most of its
length, with sporadic changes to the profile (namely intersections, extra lanes on either side or both
sides of the road). Along the road different elements are located at different places in order to create
a slightly changing surrounding environment, like trees and traffic signs. Some obstacles are also
placed along the course, forcing the driver to make a detour or pass through a narrow passage. Some
of the elements along the course are hidden in the middle of similar elements: e.g. in the middle of a
stretch of trees it is possible to find a tree of a different color. The whole course is planned for 25
minute driving sessions (more or less) plus the introductory part, adding up to half‐an‐hour total
time.
The course is divided into 3 stretches of 2 sections each: one stretch for each of the three driving
variants wanted (driving task only, driving and performing tasks using the traditional interface,
driving and performing tasks using the integrated interface), and in each stretch one section in which
no road elements occur (in fact, the first section of every stretch is a full‐length straight road) and a
43
second one in which changes to both environment elements and road profile happen. The 3
stretches are more or less the same size and the matching sections are of identical length either.
The ambience of the course is made to simulate a foggy dawn, enhancing the feeling of monotony
and limiting the visibility of objects during the course.
6.1.2. New scenario elements
To accomplish the monotony needs for this scenario, two new elements were created: road curves
and road stretches. Previously, curves were limited to a fixed radius, which worked out fine for urban
scenarios where speeds are low and there is no problem in having to slow down to correctly do
them; however, in monotonous roads, short‐radius curves would imply either no curves at all or
sudden breaks in the monotony. This fact lead to the creation of road curves of variable radius,
adequately adapting the road texture to its shape and enabling more flexible courses. While the new
road curves were needed to create a more flexible modeling environment, road stretches were
created mostly for the sake of simplicity and straightforward‐ism in the definition of courses.
Previously, road stretches had to be declared in an element‐by‐element basis, and road stretches
now accommodate the need for extra‐long stretches by enabling the declaration of a variable‐sized
stretch. Both these elements were complemented with other features to enable more realistic and
monotonous road environments; for further details on the technical aspects refer to Annex A:
Changes to the simulator.
6.1.3. Adjustments to vehicle behavior and validation procedure
In [Por06] some users complained that the simulator’s vehicle was particularly unforgiving, especially
the accelerator and brake pedals behavior. Steering was also deemed not appropriate for
monotonous driving, as the minimum movement made the car steer a lot. While this behavior was a
need in the previous work because of the sharp turns required by an urban scenario, a more tolerant
behavior was necessary for the present work. Steering behavior was also in need for improvements,
because one of the goals was to achieve a state of monotony, and having unforgiving steering wheel
and pedals would imply constant attention to their settings and thus less monotony.
Technically, changes required altering the accelerating behavior, now using logarithmic functions and
an inner‐state 5‐speed gearbox with a set of 5 appropriate functions for determining speed in terms
of acceleration and brake intensity; constant parameters determining accelerator and brake intensity
are now defined in a configuration file and can be adjusted on a per‐user basis if desired. Steering
was kept linear, but the steering sensibility can also be adjusted in the same configuration file. For
details on the technical aspects refer to Annex A: Changes to the simulator.
44
To determine the appropriate values to keep for the usability experiment some user testing was
made. An expedite two‐stage procedure took place for such adjustment: two persons were involved
in the first stage, consisting of a short driving period on a small test course while adjusting the
parameters dynamically; the persons involved in stage one and an extra 2 were involved in the
second stage. In this stage, all the persons involved considered driving was easier than with the
original definitions and that the vehicle’s behavior was acceptable when compared to that of a real
vehicle, after appropriate training.
6.2. Protocol The following section describes the protocol for the usability tests, including details on the
participants, the roles of each participant on the usability tests, the procedure (including tasks to
perform using the comfort systems) and performance metrics.
6.2.1. Participants
The experiment was conducted on 14 subjects, from both sexes and divided in two categories:
• Younger drivers: less than 40 years old and less than 20 years driving experience;
• Older drivers: 40 years old or more and 20 years driving experience at least.
This division by ages is based on the works [SD04] by Strayer and Drews and [Horb06] by Horberry et
al, who suggest that age may influence driving performance when considering distraction while
driving and performing other tasks, and also in [BGI03] by Bengtsson et al who observed differences
between drivers with more than 10 years of driving and those with less than that. The division in two
classes is based on [SD04] and the boundaries between classes were chosen based on the study
group (with minor adjustments taking into account the particular volunteers for the usability tests).
The information concerning users’ information was collected in a quiz presented to the driver after
they took the experiment, and which can be seen in Annex C: Quiz for the usability tests. A more
detailed analysis on participants can be found further on this work.
6.2.2. Roles
Each test was conducted with 2 persons involved in different roles: the volunteer user who was
driving the simulator (the driver) and an examiner who controlled several aspects of the driving task.
The examiner’s role was played by the author of this work in all the experiments. The driver’s role
includes driving the simulator in the predefined course; at the same time, he or she has other
responsibilities such as:
45
• Maintaining the vehicle in a constant speed close to 80Km/h, except where the driver does
not feel safe driving at such speed and needs to slow down;
• Being alert to the road and the driving environment, so as to notice any strange or varying
features;
• Following instructions given by signaling and road marks during the course (for example,
keeping to the correct lane);
• Performing certain tasks using the comfort systems when instructed by the examiner.
While the driver is conducting the experiment, the examiner asks several questions and asks the
user to perform certain tasks using either comfort system in predetermined places of the course,
according to the form in Annex D. Examiner form. These questions are about given features on the
road (for example, «on which side of the road was the previous road sign?», or «what was the road
profile on the last curve?») or about details on the stretch (e.g. «did you notice the tree next to the
traffic sign?»). Also, the examiner takes notes on whether the answer was right or wrong, and some
notes on the user’s behavior, especially when performing tasks.
6.2.3. Procedure
The procedure for the usability tests consists of three phases: an introduction phase, in which the
user learns the simulator, a formal test phase, in which the driver is evaluated in his performance,
and a quiz phase, in which the user fills in a quiz about its subjective notion of his performance
during the usability experience.
The introduction phase consists of two stages. In the first stage, the driver is instructed on how to
operate both comfort systems: with the vehicle stopped, he is given a crash course on the usage of
both interfaces, given some tasks to perform in order to confirm the knowledge of the systems. The
driver is instructed to only pass to the following stage when he or she feels confident about his or her
ability to properly operate the comfort systems. In a second stage, the driver gets accustomed to the
physical behavior of the vehicle. In this stage, he is instructed to drive along the road in a first stretch
which occurs in an urban scenario with a lot of sharp curves to get the driver comfortable with the
sensibility of the steering wheel and the accelerator and brake pedals. Once again, the driver is
instructed to only pass to the next stage when feeling confident with his or her driving skills. After
these two stages, the usability experience itself is initiated.
The formal test phase is divided into several stretches and sections as mentioned before. The first
section on every stretch has the purpose of inducing the driver into a monotonous state, as well as to
assert that monotony state and, in the stretches where the user is performing tasks, to compare his
46
or her behavior with the stretch in which the only task is driving; the second section on each stretch
aims at observing the driver’s behavior while in a monotonous state and road elements change. Each
section is planned to be driven through in approximately 5 minutes. In the second section of all
stretches, the questions and tasks (when applicable) are predetermined; in the first section, random
questions and tasks may be introduced if necessary, to get the driver in the mood for the test.
During this phase the examiner remains silent (except when instructing the driver to perform tasks or
asking questions about the road environment) and the driver remains silent except when answering
questions or if he or she has a doubt concerning the test.
The third phase of the procedure consists in filling a quiz on the subjective opinion on the experiment
conducted. This quiz includes questions concerning perceived attention to the environment while
driving, perceived influence of the tasks involving the comfort systems in the driving task and
perceived difference between attention levels while using either one of the interfaces. The quiz used
can be consulted in Annex C: Quiz for the usability tests.
6.2.4. Tasks using the comfort systems
One set of tasks was used during the experiment: the same set was used all the times the driver was
required to perform tasks using the comfort systems, to avoid differences in performance concerning
different tasks. The tasks were carried out upon request when the driver reached specific places
along the course. The set of tasks is based on the set used in [Por06] and include:
• Changing the sound volume on the radio (either decrease or increase);
• Changing the climate control fan speed (either decrease or increase);
• Changing where the air flow is aiming (either feet and body or windshield);
• Changing the radio frequency to a given preset (from 1 to 6) or to a given frequency;
• Changing the climate control temperature (either increase or decrease).
The actual tasks to perform depended on the actual state of the comfort system (e.g. if the sound
volume was set to the maximum, the task will implicate decreasing the sound volume). A list of the
actual tasks, as well as the indication of when/where they are performed is available on the Annex D:
Examiner form.
6.2.5. Performance metrics
Performance was measured considering two aspects: determination of the monotony state of the
driver and comparison between attention levels while simply driving and while using either of the
comfort systems’ interfaces. The metrics used are speed, side deviation in given stretches of road,
47
user input on the driving equipment (pedals and steering wheel), attention (or not) to changes in
road environment, driving errors (collisions, leaving the correct lane, etc.) and task completion
performance.
Speed and side deviation aim mostly at determining if the driver is in a monotonous state. According
to [Hawo98] these are some of the measures of fatigue while driving, and as seen in previous
sections fatigue can be related to the psychological dimension of monotony, thus being a good
metric for the state of monotony of the driver. Average speed is also used by Horberry et al in order
to know whether the user is paying attention to the driving task [Horb06], while side deviation is
used by [TB03] in order to test for reactions to slowly developing driving errors in monotonous
driving. To simplify the processing of the information, these metrics will be analyzed in specific
stretches of the course (the 3x2 sections, as mentioned previously), rather than in the whole course.
Pedals and steering wheel behavior also provides a source of information on the driver’s behavior.
From this information it can be seen whether the user keeps constant pressure on the pedals or, on
the contrary, it keeps making small adjustments, allowing the determination of whether the user is
behaving monotonously or is in an attentive state.
The attention to changes to road environment again aims at determining if the driver is in a
monotonous state. This particular metric has the specificity of being user‐dependent with its pros
and cons, given that for one hand it tends to keep the user alert to the road environment but on the
other hand it enables us to suggest a monotonous state given certain trends in the drivers’ behavior
(e.g., if he tends to detect less changes as the time goes by).
Driving errors are a metric that was used in [Por06] to simply evaluate driving performance. The
number of driving errors itself does not yield much information, but associating the number of
driving errors to the part of the course where they occur can provide useful information about the
attention the driver pays to the road. Errors are identified as whether occurring while the user is
simply driving or whether he or she is performing tasks on either system. Errors are classified in 2
classes:
• Class A errors: errors that compromise road safety but are not associated with an actual
hazard (e.g. diverting to the wrong lane or to road shoulders, reaching an excessively low
speed – below 40Km/h in regular roads with no obstacles);
• Class B errors: errors that compromise road safety and are associated with an actual
hazardous situation (crashes, sudden pushes to the brake pedal);
48
A subjective appreciation of the reaction to the changes placed in the scenario was also taken into
account when evaluating these aspects. Although subjective, it takes into account aspects like time
of reaction, the nature of the reaction (if any) and if the user is able to keep driving safely during and
after the reaction to changes.
Finally, task completion performance is measured by taking notes on whether a given task using the
comfort system is correctly performed, either in the traditional and the integrated systems. The time
to perform a given task is not taken into account, as it is already known that tasks with the integrated
system take longer to accomplish (e.g. from the conclusions in [TJT05] and [Por06]).
Some of the metrics correspond to values that are logged by the simulator, such as:
• Instantaneous speed;
• XYZ coordinates of the vehicle;
• Stretch in which the vehicle is at a given time;
• Pressure on the accelerator and brake pedals;
• Angle of rotation of the steering wheel.
49
7. Results and analysis Results from the usability tests come from several sources: the log files, created for each course, the
examiner form and the user quiz; the first accounts for data collected from the simulator, the second
data was gathered by the examiner during the test, from observation of user reactions and behavior,
and the last one reflects the users’ opinion on the test. Many possible analyses can be made from the
available data: only the ones considered useful for the discussion in hands are presented in this
section.
As mentioned earlier, data logged by the simulator includes instantaneous speed, position in the
scenario (XYZ coordinates), amount of pressure on the accelerator and brake pedals and steering
wheel turn angle; the examiner form includes data about attention flaws during the course and
errors in performing the tasks using the comfort systems; the user quiz assesses the subjective
opinion about concentration needs and perceived monotony during the course. These data were
used for two distinct purposes: for establishing that users reached a state of monotony and to
observe their behavior in presence of such state, taking into account both the details on the course
they were supposed to take notice of and comparing the attention levels when the users limited
themselves to driving or when they were using one of the two comfort systems interface while
driving. This section attempts to provide a comprehensive analysis of the data collected, focusing on
the results yielding information that is useful to some degree.
7.1. Sample population Users in this test are of both genders and are aged between 21 and 63 years old, with driver’s license
time between 1 and 40 years. Figure 6.1 shows the distribution of the sample population both by age
group and gender and age group.
Figure 7.1. Charts illustrating the distribution of the sample population by gender and age groups.
012345678
[18, 15] ]25,40] ]40, 55] ]55, …[
Num
ber o
f elemen
ts
Sample population by age group
0
1
2
3
4
5
6
Male Young Male Old Female Young Female Old
Num
ber o
f elemen
ts
Sample population by gender and age group
50
Two age groups are considered: the young age group was constituted by 9 persons (5 males and 3
females) aged 21 through 32 and with a driver’s license since 1 to 14 years; the old age group was
constituted by 5 persons (3 males and 2 females) aged 42 through 63 and having had a driver’s
license since 24 to 40 years. Gender distribution was almost balanced both on the sample population
(8 males against 6 females) and in both age groups (5 males and 4 females in the young group; 3
males and 2 females in the old group).
7.2. Log data Log data are recorded every half second and the logging period is divided in 6 stretches. These
stretches are numbered as 11, 12, 21, 22, 31 and 32: the first digit denotes the driving variant (1:
driving task only; 2: driving and performing tasks using the traditional interface; 3: driving and
performing tasks using the integrated interface) while the second digit denotes the nature of the
stretch (1: monotony control stretch; 2: stretch in which tasks are performed and question
concerning the course are asked). With this in mind, it is reasonable to use the data from stretches
11, 21 and 31 to determine if the driver is in a state of monotony, and data from stretches 12, 22 and
32 to analyze the driver’s behavior in presence of other elements in the road.
7.3. State of monotony Determination of a state of monotony is done taking into account the data on the users’ behavior
while driving on the purely monotonous stretches (11, 21 and 31). These stretches consist of long
straight roads with unchanging profile (single carriageway, one lane in each direction) and no
roadside features at all. In these stretches, users are simply required to maintain the speed close to
80 Km/h and keep the vehicle in the correct lane. In these conditions users are expected to reach a
state of monotony characterized by diminishing attention to vehicle behavior, including unwanted
speed and side deviation variations.
For each stretch considered (of a total of 14x6 stretches) 2 charts were made to compare the logged
variables. Chart A plots instantaneous speed and accelerator pedal pressure in terms of elapsed time,
chart B plots side deviation (X or Z, whichever represents the transversal axis) and steering wheel
position in terms of elapsed time. Figure 7.2 (in the next page) shows the 6 charts plotted for a given
user for the monotony control stretches, as an example of what can be seen in the charts.
After observing the charts, two good indicators of what a monotony condition can be were
determined: the inability to maintain a constant speed (by increasing or decreasing it too much
without acknowledging it) and the inability to keep the vehicle in a straight line.
51
Figure 7.2. Charts plotting speed and accelerator pedal pressure (A, right column) and side deviation and steering wheel position (B, left column) for each of the 3 monotony control stretches (each row).
In Figure 7.2., accelerator units are expressed in a scale from 0 to 200, where 0 is the rest position
and 200 is the maximum pressure. Steering wheel rotation is expressed in percentage of the
maximum turn angle: given that the maximum turn angle is of about 90° in each direction, ‐100 is a
rotation of 90° to the left, 0 is the rest position and 100 is a rotation of 90° to the right. Side deviation
is expressed in OpenGL units, whereas 1 OpenGL unit equals 0.5 meters at real world scale.
0
50
100
150
200
0
20
40
60
80
100
120
140
160
05:36.9 06:36.9 07:36.9 08:36.9
Accelerator
Spee
d (Km/h)
Elapsed time (mm:ss.)
Stretch 11
Speed (t) Accelerator pedal (t)
‐20
0
208235
8257.5
05:36.9 06:36.9 07:36.9 08:36.9
Stee
ring
whe
el rotation (%
of max angle)
Side
deviation
(Ope
nGL un
its)
Elapsed time (mm:ss.)
Stretch 11
Side deviation (t) Steering wheel position (t)
0
50
100
150
200
0
20
40
60
80
100
120
140
160
15:32.7 16:32.7 17:32.7 18:32.7
Accelerator
Spee
d (Km/h)
Elapsed time (mm:ss.)
Stretch 21
Speed (t) Accelerator pedal (t)
‐20
0
2017595
17617.5
15:32.7 16:32.7 17:32.7 18:32.7
Stee
ring
whe
el rotation (%
of max angle)
Side
deviation
(Ope
nGL un
its)
Elapsed time (mm:ss.)
Stretch 21
Side deviation (t) Steering wheel position (t)
0
50
100
150
200
0
20
40
60
80
100
120
140
160
25:12.9 26:12.9 27:12.9 28:12.9
Accelerator
Spee
d (Km/h)
Elapsed time (mm:ss.)
Stretch 31
Speed (t) Accelerator pedal (t)
‐20
0
20‐12183.7
‐12159.4
‐12135.1
25:12.9 26:12.9 27:12.9 28:12.9 Stee
ring
whe
el rotation (%
of max angle)
Side
deviation
(Ope
nGL un
its)
Elapsed time (mm:ss.)
Stretch 31
Side deviation (t) Steering wheel position (t)
52
7.3.1. Speed monotony
The first indicator, which is obtained based on the chart plotting speed and accelerator pedal
pressure, shall be called “speed monotony”. This indicator is essentially obtained by counting the
number of periods in which the driver is either letting speed increase or decrease too much but
keeps a constant accelerator pedal pressure, as such behavior can be assumed as unconscious; this
can be followed or not by a sudden release or full press on the accelerator pedal.
Some assumptions are made on this indicator. First, there has to be a reasonable minimum time for
such behavior to be counted as monotonous (because no driver can keep the car at a constant speed
at all times, slight variations occur!); after observation of the charts, a period of 10 seconds was
considered enough, as it corresponds to a distance of 225 meters at the recommended speed of
80Km/h, and although being 10 seconds a high enough value to qualify for monotony, it is still
possible to have almost 20 such periods in each stretch for each user. Second, speed variation has to
diverge from the recommended speed of 80Km/h – if a user is able to keep the speed constant it is
not certain that he is in monotony, he can just be good at it; also, if a user is converging to the
recommended speed, even if slowly, the occurrence of monotony is not certain for the same reason.
Third, the minimum threshold for considering the user is entering a “speed monotony” period is of
more or less 10 Km/h with an accelerator pedal pressure variation of more or less than 25 units
(12,5%) allowing for sensibility issues.
Figure 7.3. Chart showing valid (A, B and C, green) and invalid (D, E, F and G, red) “speed monotony” periods.
Figure 7.3 shows the chart for stretch 11 of a given user, illustrating which periods are considered of
“speed monotony” and which ones are not. Period A shows a behavior similar to the expected
53
normal behavior, in which the driver keeps a speed close to 80 Km/h although slightly changing (in a
30 second period the speed changes between 65 and 75 Km/h), while maintaining a regular pressure
on the accelerator pedal (except for some periods in which the accelerator is released and pressed
again, but this has to do with the way each user controls the vehicle).
Periods B, C and D represent “speed monotony periods”: in period B, the driver lets the speed
increase to more than 100Km/h while keeping the accelerator almost constant, and at the end the
driver releases the accelerator pedal and speed starts decreasing; period C is a new “speed
monotony” period because, while losing speed, the driver presses the accelerator again, but not
enough to keep the desired speed, and speed keeps decreasing until the end of period C, when the
driver accelerates again to regain control; period D again is a “speed monotony” period because for
some reason the driver decides to release the accelerator pedal and lets speed decrease to near 50
Km/h, after which the driver presses the accelerator again to regain control.
Periods E, F and G show periods that appear to be “speed monotony” periods, but are not. Periods E
and F show the vehicle’s speed decreasing constantly, but the decrease is less than 10 Km/h away
from the recommended speed and is considered simply speed adjustment behavior; period G shows
a decrease in speed slightly bigger than 10 Km/h but because it happens around the recommended
speed, it is again considered as speed adjustment behavior. So this chart shows three periods, period
B with a total length of 30 seconds, and periods C and D with approximately 10 seconds each. This
accounts for 5 “speed monotony” periods.
All Young Old Stretch 11 3.2 2.7 4.2Stretch 21 4.1 4.1 4.0Stretch 31 4.6 3.6 6.0Global 10.9 9.1 14.2
Table 7.1. Average number of “speed monotony” periods by age group and by stretch.
Table 7.1. shows the average number of “speed monotony” periods by stretch and by age group. As
can be observed, the average number of “speed monotony” periods is between 3 and 6 for all
stretches and considering the global stretch, slightly smaller among the young users and a little
higher among the old users (except for stretch 21). This is a good indicator that the course is
monotonous, because in average users spend a total of near 110 seconds (11 periods) in a “speed
monotony” condition, more than 18% of the global stretch (considering the stretches are designed to
take 3x200 seconds to traverse at the recommended speed of 80Km/h).
54
Figure 7.4. Chart depicting the number of users having “speed monotony” period in terms of stretches.
It is interesting to look at these data through a slightly different perspective: the number of persons
who happen to have a given number of “speed monotony” periods in each stretch. Figure 7.4 shows
the chart for this perspective, with the number of users experiencing a given number of speed
monotony periods in each stretch, as well as a global average for the 3 stretches.
As seen in the figure 7.4, the number of users experiencing 0 or 1 “speed monotony” periods in each
stretch is significantly less than the two other categories and similar to the number of users
experiencing more than 8 such periods. Also, globally, most users experience between 2 to 7 “speed
monotony” periods per stretch, which translates to 85% of the users spending between 10% and 35%
of the total course time in “speed monotony”.
7.3.2. Side deviation monotony
The second indicator, obtained from the chart plotting side deviation and steering wheel position,
shall be called “side deviation monotony”. This indicator essentially counts the number of periods in
which the driver is letting the vehicle deviate from the center of the lane while keeping the steering
wheel in a constant position; this can be followed or not by a sudden turn of the steering wheel and a
zigzagging behavior for a brief period. Again some assumptions are made on this indicator. First, the
minimum period of time for such behavior to be counted as monotonous is of 10 seconds. Second,
the deviation must take place without relevant movements to the steering wheel (in which case it
could be interpreted as lack of steering sensibility by the user). Third, such behavior must be
followed by an adjustment to the direction resulting in sharp steering wheel movement (that can
indicate the driver suddenly realizing the vehicle was diverting).
0
2
4
6
8
10
12
[0,1] [2,4] [5,7] [8,…[
Num
ber o
f users
Number of speed monotony periods
Number of users having speed monotony periods in terms of stretches
Stretch 11
Stretch 21
Stretch 31
Global Average
55
Figure 7.5. Chart showing 2 valid (A and B) “side deviation monotony” periods.
Figure 7.5 shows the chart for stretch 31 of a given user, illustrating the periods considered of “side
deviation monotony”. Both periods A and B exhibit the above behavior, as the user deviates towards
the lane limit while keeping the steering wheel at a constant position. Between periods A and B the
adjustment is exaggerated and in period B the vehicle starts deviating in the opposite direction,
causing the intense adjustments that follows period B. Period A lasts for approximately 50 seconds
and period B lasts for more or less 10 seconds, accounting for 5 + 1 “side deviation monotony”
periods in this stretch for this user.
Global Young Old Stretch 11 4.9 4.5 5.5Stretch 21 5.4 4.0 7.5Stretch 31 6.1 5.8 6.5Global 16.4 14.3 19.5
Table 7.2. Average number of “side deviation monotony” periods by age group and by stretch.
Table 7.2 shows the average number of “side deviation monotony” periods by stretch and by age
group. As can be observed, the average number of “side deviation monotony” periods is roughly
between 5 and 6, being slightly lower for the young group and slightly higher for the old group. Again
this is a good indicator of a monotonous course, because on average users spend near 165 seconds
(16.5 periods) in a “side deviation monotony” condition, more than 27% of the global stretch (again
considering the stretches are designed to take 3x200 seconds to traverse at the recommended speed
of 80Km/h).
56
Figure 7.6 shows the chart for the number of users who have a given number of “side deviation
monotony” periods in each stretch, as well as a global average for the 3 stretches.
Figure 7.6. Chart depicting the number of users having “side deviation monotony” period in terms of stretches.
As seen in the above figure, the number of users experiencing 0 through 4 “side deviation
monotony” periods is much less than the number of users experiencing 5 or more such periods in
every stretch (except for stretch 21, where this number is roughly equal). Also, globally, most users
experience between 5 and 7 “side monotony deviation” periods per stretch, translating to 70% of the
users spending from 25% to 35% of the total course time in “side deviation monotony”.
The results obtained with these two indicators are coherent with the users’ perceived opinion on the
course, as 13 out of 14 users considered it to be monotonous.
7.4. Behavior while in monotony The following section attempts to compare drivers’ behavior when just driving with the behavior
when performing tasks using one of the comfort systems, while in a state of monotony. Several
indicators are used for this purpose, and they are presented here.
It is important to say that in stretches 12, 22 and 32 the analysis of monotony patterns gives very
little information, as the stretches have curves and obstacles exist at certain places, forcing the user
do take detours and causing speed and route changes. However, certain indicators are useful in
understanding drivers’ behavior on such stretches and comparing it with the behavior in straight
stretches 11, 21 and 31.
0
1
2
3
4
5
6
7
8
[0,1] [2,4] [5,7] [8, …[
Num
ber o
f users
Number of side deviation monotony periods
Number of users having "side deviation monotony" periods in terms of stretches
Stretch 11
Stretch 21
Stretch 31
Global Average
57
7.4.1. Mean and minimum speed
When comparing the mean and minimum speeds in the set of stretches 11, 21 and 31 with the mean
and minimum speeds in each of the stretches 12, 22 and 32, some interesting results are obtained.
Figure 7.7 shows the chart for the mean speed in the those stretches while figure 7.8 shows the chart
for the minimum speed in the same stretches, both in terms of age groups.
Figure 7.7. Mean speed in stretches in terms of age group.
Figure 7.8. Minimum speed in stretches in terms of age group.
Stretches are named according to their use in the usability test: stretches 11, 21 and 31 count as a
single “Just Driving” stretch; stretch 12 is the “Driving & Attention” stretch because in it the driver is
asked questions about the surrounding environment; stretch 22 and 32 are respectively the “Driving
& Traditional” and “Driving and Integrated” stretches because when in it, in addition to the questions
asked, the users must perform tasks using one of the interfaces.
60
65
70
75
80
85
90
Just Driving Driving & Attention
Driving & Traditional
Driving & Integrated
Spee
d (Km/h)
Mean speed in stretches, by age groups
General
Young
Old
05101520253035404550
Just Driving Driving & Attention
Driving & Traditional
Driving & Integrated
Spee
d (Km/h)
Minimum speed in stretches, by age groups
General
Young
Old
58
Figure 7.7 suggests that speed decreases when the cognitive load increases: when just driving the
average speed is higher, it decreases a little when the user starts paying attention to details in the
surrounding environment and decreases even more when the user starts using the comfort systems.
This behavior is visible whether considering the whole sample population or when considering each
individual age group. The difference in mean speeds between stretches when using each comfort
system interface is small for the whole population, with the average speed being a little higher when
using the traditional system for the young group and a little higher when using the integrated system
for the old group. Additionally, when just driving, the young group kept an average speed slightly
higher than the recommended 80 Km/h, while the old group kept a slightly lower speed.
The analysis of the minimum speed chart in figure 7.8 is similar to that of the mean speed: minimum
speed tends to decrease when the cognitive load increases. The only abnormal behavior appears to
be that of the old group in the “Driving & Attention” stretch, but this can be due to the limitation on
the statistical behavior of this group, because of its reduced number of elements.
Both these indicators (mean and minimum speed) can be interpreted as meaning that when the user
is confronted with a greater cognitive load he tends to let the vehicle lose speed, causing it to reach
lower average and minimum speeds.
7.4.2. Attention flaws
First we will analyze the figures concerning attention flaws during the course. Attention flaw, in this
context, refers to elements or characteristics of the course the user is expected to take notice of
(which he or she was warned about before the beginning of the usability test and during the practice
stretch) but was unable to see or correctly identify. Examples of attention flaws can be not noticing a
given traffic sign, not noticing a different tree on the road shoulder, etc.
Figures 7.9 and 7.10 show the comparison, for each user, of the number of attention flaws observed
in the 3 tested situations (just driving, driving and using the traditional comfort system, driving and
using the integrated comfort system). The charts in figure 6.9 show the comparison globally, while
the charts in figure 6.10 address also age groups. The value chosen for the “equal” category does not
correspond to 0%, as it would not be representative of small differences in behavior and because the
number of possible attention flaws close to 10 for each of the 3 situations it would result in a useless
metric. The margin considered for the equal value was set to 7%, empirically, considering the values
for each difference. The charts plot the histogram for the difference in percentage between attention
flaws in the situations considered; negative values correspond to a better performance of the left
value, positive values correspond to a better performance of the right value. The plotted charts
already take this into account.
59
Figure 7.9. Charts comparing the number of users performing better in each combination of situations.
Figure 7.10. Comparing the number of users performing better in each combination of situations by age group.
02468
10
Best when just driving
Equal behavior [‐7%,7%]
Best when using traditional
Num
ber o
f users
Attention flaws comparison
02468
10
Best when just driving
Equal behavior [‐7%,7%]
Best when using integrated
Num
ber o
f users
Attention flaws comparison
02468
10
Best when using traditional
Equal behavior [‐7%,7%]
Best when using integrated
Num
ber o
f users
Attention flaws comparison
60
Looking at figure 7.9, one can see that when comparing the behavior while just driving with the
behavior while driving and using the traditional comfort system, the population is almost evenly
distributed: the highest bar is the one corresponding to the equal behavior, and the difference
between users who performed better while just driving and those who performed better while
driving and using the traditional system is small, with little advantage to the behavior while using the
traditional system. This suggests that a given user had no significant difference in the number of
attention flaws between when just driving and when using the traditional system.
The difference in behavior is quite different when comparing the situations in which the user just
drives and when he or she uses the integrated comfort systems, or when comparing the user’s
behavior when using either comfort system: in both cases, the user has less attention flaws when
using the integrated system, therefore showing better behavior. There are some users who behave
better when using the traditional system when comparing with the integrated system, but none who
behaves better when just driving. This is quite a surprising observation, especially when considering
the integrated system has a much greater mental workload [BGI03].
This can be explained by the fact that the driver’s awareness of the demanding nature of the task
causes him or her to be more alert to the surrounding environment and thus has less attention flaws;
this way, the number of attention flaws decreases as the mental workload increases, because the
user gets more aware of the surrounding environment and that it can change unexpectedly.
When looking at the same comparisons separated by age group, in figure 7.10, the same global
tendency remains: the behavior while using the integrated system is better than when just driving or
when using the traditional system, and the difference between just driving and using the traditional
system is small, but with a slightly better behavior while using the traditional system. However, old
users tend to perform better when just driving than young users, and tend to the equal behavior
when comparing just driving with using the integrated interface. This can be explained by the fact
that old users tend to have more limited skills and thus the usage of such interfaces tends to go from
“monotony” to “overwhelming” and the concepts of distraction in [Por06] take place.
Comparing the logged behavior in terms of attention flaws with user awareness of the attention
devoted to driving in these situations is also interesting. Figure 7.11 shows the chart for the users’
perceived attention to the course in the situations mentioned previously, as obtained from the user
quiz.
61
Figure 7.11. Users’ perceived attention to the course.
As can be seen in figure 7.11, half the users considered themselves to be more attentive to the
course while driving and performing tasks using the comfort systems, whereas a little more than 25%
considered themselves more attentive while just driving. This is coherent with the logged behavior,
especially when comparing the behavior while just driving with the behavior while driving and using
the integrated interface.
7.4.3. Task errors
Task errors are defined in this work as the inability to complete the task at hand, using the comfort
system, or not being able to complete the task before the next task was to be performed. Users were
expected to perform a total of 14 tasks, 7 tasks using either system. The number of tasks with error
per user can be seen in the chart in figure 7.12.
Figure 7.12. Charts depicting the number of users in terms of tasks with error and age groups.
0
1
2
3
4
5
6
7
8
Best when just driving Identical Best when driving & tasks
Num
ber o
f users
Users' perceived attention to the course
62
A closer look at figure 7.12 shows that the number of users committing errors when performing tasks
with the traditional system is much lower than the number of users committing errors when
performing tasks with the integrated system. 11 out of 14 users made no mistakes using the
traditional interface, while 10 out of 14 users made one or more mistakes using the integrated
interface. The distribution is very similar when looking at the sample population as a whole and when
looking at any of the age groups.
Another interesting result is observed when comparing the difference between the number of errors
a given user makes using each comfort system interface: while a little less than half the users make
the same number of mistakes in either interface, the other half makes more errors using the
integrated interface; no single user makes more mistakes using the traditional interface than using
the integrated interface. This is expected behavior based on [Por06], [BGI03] and others, but
together with the results from the attention flaws provides a better explanation for the
phenomenon: as the user is more concerned with the obstacles that might show up on the road
while using the integrated system, it dedicates more cognitive skills to actually driving and watching
the road, sacrificing the accessory task of using the comfort system. This is a strong result that
suggests that using the integrated interface has a more intense effect in breaking the monotony than
using the traditional interface, as it makes users more attentive to the road environment, even if
they can not correctly perform the desired task. This behavior is coherent with the perceived
behavior by users, as 9 out of 14 considered that using the integrated interface demanded more
concentration than using the traditional system to perform the same tasks, thus implying the
integrated interface was more error‐prone than the traditional one.
63
8. Conclusions The results obtained from the experiment point to several conclusions. The first and foremost is that
the simulator was able to achieve the proposed goals, because it induced most drivers into a state of
monotony during the course. Remembering the use of two indicators, “speed monotony” and “side
deviation monotony”, in average 18% of the control stretch time was spent in “speed monotony”
and 27% in “side deviation monotony”; additionally, 85% of the users spent from 10% to 35% of the
control stretch time in “speed monotony” and 70% of the users spent from 25% to 35% of the
control stretch time in “side deviation monotony”. Also, 92% of the users found the course to be
monotonous and tedious, which is a good indicator that drivers were indeed in a state of monotony.
We were able to conclude that there are differences in behavior when a driver in a state of
monotony is confronted with a varying surrounding environment: as cognitive skills demands
increase a decrease in mean speed is observed, as drivers attempt to compensate for the new
demands. Minimum speed also decreases as users lose trust in their capabilities and attempt to drive
safer.
The use of the comfort systems interfaces forces the user to be more aware to the surrounding
environment as he becomes conscious of the demanding nature of the task. Drivers’ attention levels
are higher when the tasks demand greater mental workload, as less attention flaws are observed
while the users drive and perform tasks using the integrated interface than when using the
traditional interface or than simply driving. On the contrary, more attention flaws are observed when
comparing the “just driving” situation with when the driver uses the traditional system. This might be
due to de decreasingly demanding nature of the tasks: as users are more accustomed to using the
traditional interface, the cognitive load is lower than when using the integrated interface, and even
lower when using none of them. Users have a perception of this difference, with half of them
considering their attention levels higher when driving and performing tasks, and more than 70% at
least considering their attention levels equal or higher.
However, more attention to the road and its environment translates into less accuracy in performing
tasks, as the number of errors and unaccomplished tasks while using the integrated interface is much
bigger than that of the traditional interface. Once again users show a correct perception of this
difference, as the majority of them considered that using the integrated interface demanded more
concentration than using the traditional one.
When comparing the two age groups, it is possible to realize that older users drive slower in every
situation, are more susceptible to monotony as they spend larger amounts of time in each of the
64
monotony states suggested by the indicators – this is consistent with the results in [SD04]. They also
perform worse when using the comfort systems than the young, both in terms of attention flaws and
in terms of task accuracy, as it is possible that in such situations they go from a “monotony state” to
an “overwhelming state”, getting this age group closer to the study in [Por06].
8.1. Possible future improvements Future work on this subject should take place because some of the conclusions stated herein could
be stronger if the investigation had been made with other conditions. Improvements in the test
procedure could be of 2 distinct natures: one more concerned with the technical aspects of the
simulation, the other concerning the part of the usability tests in this work. Also, this work could be
driven to follow new directions, considering aspects like roadside furniture and external distracting
elements as a way to decrease monotony in the situations studied.
On the technical improvements to the present work, it would be important if the tests could be
redone in a more realistic simulator, like the NADS simulator from the National (United States)
Highway Traffic Safety Administration or the UCF Driving Simulator from the University of Central
Florida. More important than the use of a more realistic simulator is the use of the actual comfort
systems available (both integrated like iDrive or MMI and traditional from different brands) which
can only be done in a simulator that uses a car body or, at least, the car console integrated with the
simulator. The use of a more realistic simulator would also provide for additional metrics for
comparison (like the use of direction lights in crossroads or the awareness of changing lighting
conditions), better mistake determination (like determining distance to shoulders or lane limit
crossing) and testing the reaction to a larger variety of hazards like other vehicles, animals,
pedestrians, etc, as well as making the courses less repetitive albeit still monotonous.
The use of sound effects and the study of how sound may influence highway hypnosis would also be
of interest. On the one hand, modern automobiles are greatly soundproofed and the sounds of the
car engine and the friction between tires and the road are but discrete humming sounds, which are
known to induce fatigue. In fact, countries everywhere [Hawo98] are introducing rumble strips on
the shoulder marks, using sound to maintain drivers alert to the road environment. On the other
hand, the influence of the sound coming out of the entertainment systems should be studied, as
people are known to put the volume levels on their radios high when in fatigue, attempting not to
fall asleep.
In terms of usability testing, future tests should take longer time (probably a couple of hours, which
would probably imply the need for paid volunteers) and involve a larger set of users. The set of tasks
should be more diverse (which would be easy using the actual devices instead of emulations) and
65
especially, these usability experiences should be made in cooperation with traffic authorities and
traffic safety institutions (which do not exist in Portugal) and also in cooperation with medical
schools to better deal with the psychomotor aspects of the subject.
In this work it was concluded that the demanding nature of the accessory task (using comfort
systems) somehow compensates for the under‐demanding nature of the road environment, leading
attention levels to where it is required. It is interesting to remember that studies like the one
described in [Horb06] consider that the amount of visual information from the surrounding road
environment is another cause of driver distraction. This author points out that drivers inadvertently
spend considerable time looking at roadside advertising, which can become a hazard in driving
situations where no distraction is allowed. The referred work is, indeed, a study on the influence of
both in‐vehicle (interior) and exterior distracting elements on the driving task. However, as it was
seen in the present work that some of the factors that can induce distraction in presence of an over‐
demanding task (like using comfort systems interfaces while driving) may, in the context of road
monotony and under‐demanding tasks, return the driver into controlled‐mode driving, thus having
an opposite effect. In this context, it would be interesting to study the influence of roadside furniture
together with the influence of internal distracting elements in the driving task, combined with a
monotonous road environment. This study would be similar to the one described in [Horb06] but,
instead of being concerned with distraction and the driver being overwhelmed by the distracting
factors, this new study would be focused on road monotony and the possibility of using these factors
to reduce driving safety risks.
66
Bibliography [AutoWe00] – Voice Recognition For BMW 7 Series, in autoweb.com, seen on 2007/06/26 at
http://www.autoweb.com.au/cms/newsarticle.html?&start=45&showall=&id=BMW&doc=bmw0003
035 .
[BGI03] – P. Bengtsson, C. Grane and J. Isaksson, Haptic/Graphic Interface for In‐Vehicle Comfort
Functions‐ a Simulator Study and an Experimental Study, in Proceedings of the IEEE International
Workshop on Haptic, Audio and Visual Environments and their Applications 2003, pp. 25‐29. Ottawa,
Canada. Article reference 0‐7803‐8108‐4/03, © 2003 IEEE.
[BMWwA] – BMW Technology – Voice Recognition, in BMWWorld.com, seen on 2007/06/26 at
http://www.bmwworld.com/technology/voice_recognition.htm .
[BP01] – G. Burnett and J. Porter, Ubiquitous computing within cars: Designing controls for non‐visual
use, in International Journal of Human‐Computer Studies 2001, 55(4), pp. 521‐531.
[Brau04] – K. Brauer, Why iDrive Won’t Fly, in Edmunds.com, posted on 2004/07/08, seen on
2007/05/14 at http://www.edmunds.com/news/column/carmudgeon/102470/article.html.
[CarP05] ‐ Evolutionary Interface System Set To Be Standard Fit On New Jaguar XK, 2005, in
carpages.co.uk, seen on 2007/05/15 at http://www.carpages.co.uk/jaguar/jaguar‐xk‐alpine‐28‐10‐
05.asp?switched=on&echo=922645605.
[Day04] – J. Day, Can BMW’s iDrive Pass Its Road Test Now?, in Electronic Design, 2004, seen on
2007/05/10 at http://www.elecdesign.com/Articles/Print.cfm?ArticleID=8246.
[Dix98] – A. Dix, J. Finlay, G. Abowd e R. Beale, Human‐Computer Interaction, 2nd edition , 1998,
Prentice Hall, ISBN 0‐13‐239864‐8
[Drap96] – M. Draper, Can your eyes make you sick?: Investigating the Relationship between the
Vestibulo‐ocular Reflex and Virtual Reality, 1996/04/29, seen on 2007/05/10 at
http://www.hitl.washington.edu/publications/r‐96‐3/ .
[eMer07] – 2007 S‐Class COMAND System Demonstration, in eMercedesBenz, seen on 2007/05/17
at http://www.emercedesbenz.com/Jul06/11_2007_S_Class_COMAND_System_Demo.html .
[Fernandes] – A. Fernandes, Billboarding Tutorial, in www.lighthouse3d.com, seen on 2007/05/10 at
http://www.lighthouse3d.com/opengl/billboarding/ .
[Ferr07] – J. Ferreira, Suporte de Tarefas Perceptivas e Motoras em Simuladores, 2007, Artigo para a
disciplina de Introdução à Investigação, IST.
67
[Ford07] – Ford 'Voice to Control'(V2C): Comunicação Interactiva e em Português, in Em destaque –
notícias do site oficial da Ford Portugal, seen on 2007/06/26 at
http://www.ford.pt/Noticias/Inst_14/cv_news_item251/‐/‐/15/37 .
[GB05] – C. Grane and P. Bengtsson, Menu Selection with a Rotary Device Founded on Haptic and/or
Graphic Information, in First Joint Eurohaptics Conference and Symposium on Haptic Interfaces for
Virtual Environment and Teleoperator Systems 2005 (WHC'05), pp. 475‐476. Article reference 0‐
7695‐2310‐2/05 © 2005 IEEE.
[GC00] – R. Graham and C. Carter, Comparison of speech input and manual control of in‐car devices
while on the move, in Personal and Ubiquitous Computing, June 2000, vol. 4, nos. 2‐3, pp. 155‐164.
DOI 10.1007 / BF01324122.
[GC99] – R Graham and C. Carter, Comparison of Speech Input and Manual Control of In‐Car Devices
while on‐the‐move, in Proceedings of the W4: Second Workshop on Human Computer Interaction
with Mobile Devices, 1999.
[Hawo98] – N. Haworth, Fatigue and fatigue research: the Australian experience, presented in the
Biennial Australasian Traffic Education Conference, Speed, Alcohol, Fatigue, Effects, February 1998,
seen on 2007/05/10 at http://www.monash.edu.au/muarc/reports/papers/fatigue.html.
[Horb06] – T. Horberry, J. Anderson, M. Regan, T. Triggs e J. Brown, Driver distraction: the effects of
concurrent in‐vehicle tasks, road environment complexity and age on driving performance, in
Accident Analysis and Prevention 38 (2006), pp. 185–191.
[Howa06] – B. Howard, Car Controllers Evolve, in Technoride, published on 2/10/2006, seen on
2007/05/14 at http://www.technoride.com/print_article/Car+Controllers+Evolve/171294.aspx.
[Kerr91] – J. Kerr, Driving without attention mode (DWAM): a formalization of inattentive states in
driving, in Vision in Vehicle III, 1991, pp. 473‐479.
[Llan02] – R. Llaneras, In‐Vehicle Navigation Systems: Interface Characteristics and Industry Trends,
Rockville, MD, USA, in Driving Assessment 2003, 2nd International Driving Symposium on Human
Factors in Driver Assessment.
[McBa70] – W. McBain, Arousal, monotony, and accidents in line driving, in J. Appl. Phsycology no.
54, 1970, pp 509‐519.
[Mei06] – L. Meillaud, Quand la voiture anticipe sur les accidents, in ViaMichelin, 2006, seen on
2007/05/17 at http://www.viamichelin.com/viamichelin/fra/tpl/mag4/art20060115/htm/tech‐pre‐
crash‐system.htm.
68
[Mot05] – BMW adds super‐vision to night driving, 2005, seen on 2007/05/14 at
http://motoring.co.za/index.php?fArticleId=2621784.
[Murr01] – Interface Concerns Stall The In‐Car PC, in techweb.com, seen on 2007/06/26 at
http://www.techweb.com/wire/story/TWB20010117S0010 .
[Nels97] – T. Nelson, Fatigue, mindset and ecology in the hazard dominant environment, in Accident
Anal. Prevention 29, 1997, pp 409‐415.
[Newc07] – D. Newcomb, Technology Review: 2007 Jaguar XKR, in autos.msn.com, seen on
2007/07/17 at http://autos.msn.com/advice/article.aspx?contentid=4024652.
[Nie94] – J. Nielsen, (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability
Inspection Methods, John Wiley & Sons, New York, NY.
[Ozk05] – Ö. Özkurt, Pronto? I’m almost there, Thesis report, Interaction Design Institute Ivrea, 2005.
http://people.interaction‐ivrea.it/o.ozkurt/.
[Pete06] – T. Peterson, The New S550: Sportier, Sexier, More Expensive, in BusinessWeek, 2006, seen
at http://www.businessweek.com//autos/content/may2006/bw20060510_812584.htm on
2007/05/14.
[Por06] – A. Porta Nova, Sistema Integrado de Comandos Auxiliares e Navegação Rodoviária,
Relatório de Trabalho Final de Curso em Engenharia Informática e de Computadores, Instituto
Superior Técnico, 2006.
[Porsche] – Comfort ‐ Cayenne S in Detail, in Porsche.com.uk, seen on 2007/07/17 at
http://www.porsche.com/uk/models/cayenne/cayenne‐s/indetail/comfort/.
[Prot97] – J. Prothero et al, Do Visual Background Manipulations Reduce Simulator Sickness?, 1997,
seen on 2007/05/10 at http://www.hitl.washington.edu/publications/r‐97‐12/.
[SD04] – D. Strayer and F. Drews, Profiles in Driver Distraction: Effects of Cell Phone Conversations on
Younger and Older Drivers, in Human Factors vol. 46, No. 4, Winter 2004, pp. 640‐649.
[Solo98] – J. Solomon, Are You Sick of Games?, 1998, seen on 2007/05/10 at
http://www.loonygames.com/content/1.2/feat/.
[ST70] – R. Shor and R. Thackray, A program of research in highway hypnosys: a preliminary report, in
Accident Anal. Prevention 2, 1970, pp. 103‐109.
[Stee04] – T. Steele, T. Cutmore, D. James e A. Rakotonirainy, An investigation into peripheral
physiological markers that predict monotony, in Road Safety Research, Policing and Education
Conference Proceedings, 2004.
69
[TB03] – P. Thiffault and J. Bergeron, Monotony of road environment and driver fatigue: a simulator
study, in Accident Analysis and Prevention 35 (2003), pp. 381–391.
[TB03b] – P. Thiffault and J. Bergeron, Fatigue and individual differences in monotonous simulated
driving, in Personality and Individual Differences 34 (2003), pp. 159–176.
[Time07] – The 50 Worst Cars of All Time, in Time Magazine, seen on 2007/09/10 at
http://www.time.com/time/specials/2007/article/0,28804,1658545_1658544_1658541,00.html.
[TJT05] – A. Thatcher, J. James and A. Todd, Multifunctional systems in vehicles: a usability
evaluation, in Proceedings of CybErg 2005, the Fourth International Cyberspace Conference on
Ergonomics, Johannesburg, South Africa.
[Ward07] – C. Wardlaw, Mercedes vaults to the head of the luxury sedan class, in autobytel.com
(2007), seen on 2007/05/10 at http://www.autobytel.com/content/shared/articles/
templates/index.cfm/article_page_order_int/1/article_id_int/2064.
[Wert91] – A. Wertheim, Explaining highway hypnosis: a theoretical analysis, in Vision in Vehicle III,
1991, pp 467‐472.
70
Glossary Attention flaws ...................................... 50, 59, 64
Attention:
Automatic vs. Controlled ............................. 16
Sustained ..................................................... 15
Cognitive skills ....................................... 10, 17, 63
Comfort devices, see Comfort systems
Comfort systems .................. 10, 13, 17, 19, 25‐33
Interfaces, see Interfaces, For comfort systems
Distraction ............................................. 11, 13, 17
When using comfort systems ...................... 19
Driving assisting devices .................................... 25
Driving Without Attention Mode ................ 11, 16
DWAM, see Driving Without Attention Mode
Fatigue ............................................................... 14
Haptic:
Feedback ...................................................... 20
Feedback, combined with graphic feedback 20
Switches ....................................................... 20
Highway hypnosis ........................................ 10, 16
In‐car telematics, see Comfort systems
Interfaces:
Differences between types .......................... 25
For comfort systems ............................... 25‐33
Integrated .................................................... 25
Traditional .................................................... 25
Usability .................................................. 19‐23
Monotonous:
Road environment ............................ 13, 17, 42
Task ............................................................. 15
Monotony
Behavior while in ......................................... 13
Dimensions of .............................................. 13
In a task ....................................................... 15
Internal state of ........................................... 14
Side deviation monotony ............................ 51
Speed monotony ......................................... 51
Predictability ..................................................... 13
Simulator:
Partial driving simulators............................. 40
Pros & cons of using simulators .................. 34
Used in this work .............................. 39, 42‐44
With car bodies ........................................... 36
Stimuli, shift from internal to external ............. 15
Task:
Errors ................................................ 17, 47, 62
Automatic vs. Controlled ............................. 19
Usability of interfaces, see Interfaces, Usability
Vigilance ....................................................... 13‐15
Vision, need when using comfort systems ....... 19
Voice control and comfort systems .................. 20
71
Annex A. Changes to the simulator
A.1. Introduction
The simulator used in this work is an expansion of the simulator used in [Por06]. It introduces some
changes to make it adequate to the work at hands, including the use of a new scenario, changes to
the behavior of the vehicle and the creation of new scenario elements for simplicity and added
flexibility in defining the course for the usability tests. This annex is the technical documentation of
the changes made to the simulator, and does not intend to replace the previously technical manual.
For more details on the simulator, including features that remain unchanged please refer to Annex B
in [Por06] (in Portuguese). For better comprehension, a brief presentation of the simulator is made in
the following sections.
Certain parts of this technical manual require basic to medium knowledge of certain mathematical
(like vector and quaternion mathematics) and computer science and engineering subjects (like
software architecture and UML) as well as minimum understanding on the fundamentals of OpenGL.
A.1.1. Platform
The simulator was developed on the Microsoft Windows XP platform, using Microsoft’s Visual Studio
2005 development environment. It’s a graphical 3D application built on the OpenGL graphics norm,
with source code in C++, based on the AVTGL 2.4 API, which is used at IST by two courses, AVT –
Animação e Visualização Tridimensional (3D Visualization and Animation) and CV – Complementos de
Visualização (Visualization Complements). Interaction with the input devices (joystick and steering
wheel) is made through the Microsoft DirectInput 9.0 API.
The application runs on a single computer using, in addition to the usual input (mouse, keyboard)
and output devices (display), two joystick devices (a steering wheel and a joystick itself). A touch
72
screen is used, but the input interface is built on top of the mouse input layer. The application’s
installation diagram is shown in figure A.1.
Figure A.1. UML instalation diagram for the simulator.
A.1.2. Architecture
The simulator follows the typical 3D game architecture of the update draw cycle: in the update
phase, changes to the inner state of the application are processed, as consequence of outside events
like user input, the passing of time, object collision, etc.; in the draw phase, the scene is drawn on
screen using the graphics norm, according to the inner state of the application. A simplified state
diagram is shown in figure A.2.
Figure A.2. Simplified state diagram for the simulator.
Simulator
gl tga
ImageLib
MicrosoftDirectInput
Scew XML Parser
GLUT
AVTGL
Computer
«device»Joystick
«device»SteeringWheel
«device»Keyboard
«device»Mouse
73
A.2. Changes to scenario definitions
The scenario for the simulation is loaded from a XML file from a predefined location, using a supplied
class XMLConfig for parsing (using to the Scew library, as referred in the original documentation).
Changes in the scenario definitions include the creation of two new ways to define roads (road
stretches and road curves), the possibility to create billboards from the XML (previously, billboards
had to be inserted directly in the source code) and the ability to pre‐load textures which can be used
by other elements (namely the new added ones).
A.2.1. Assumptions made on the scenario
When creating the simulator some assumptions were made on the scenario. Firstly, the entire scene
is planar, which means the vehicle travels along the scenario with a constant elevation (implying that
the lower Y coordinate of every object is constant, in this case 0). Also, considering the OpenGL
defaults, it was defined that, regarding the initial camera position, the X axis runs from right to left,
the Y axis in the upright direction, and the Z axis runs towards the inside of the monitor. These are
the same assumptions that were made in the previous version of the simulator, as most of the
elements in the scenario remain the same. As before, the scenario is reticulated in a grid of 45x45
OpenGL units, and the correspondence between OpenGL units and real world metrics is of 0.5
meters per OpenGL unit. The elements which are not mentioned in this annex were not changed, and
readers must refer to [Por06] for reference (in Portuguese). The following sections describe the
changes made to the simulator for this work.
A.2.2. Road stretches
Road stretches correspond to stretches of road in a straight line in a given direction and with a given
length. In the previous version of the simulator, considering the use of a given grid dimension N x N,
the creation of a straight road with a given length L implied the declaration of L road elements, one
for each unit of the grid. Road stretches were created to prevent this need and adding an extra
feature, the possibility to use a texture for road shoulders (e.g. simulating vegetation) as well as
defining which sides of the road actually use this texture.
Road stretches are implemented as a separate class named RoadStretches and are placed under the
group TrechosEstrada in the definition file. As with the road elements in which they are based, road
stretches are declared in a group with several instances, in which the position is defined in multiples
of the defined grid dimension. An example of a road stretch definition is provided below, with a
graphical scheme for better comprehension.
74
Figure A.3. Example placement of 2 road stretches according to the specified format. The black lines along the road stretches represent the shoulders and the arrows the direction span of the stretches.
The sample image displayed above can be declared like this:
Figure A.4. XML source code corresponding to the scheme in figure A.3.
The declaration of Road1 includes the declaration of the texture file in the tag tgaFile, the grid
dimension in the parameters width and height, shoulderTexName and shoulderHeight are
respectively the name of the texture to use in the shoulders (previously defined in the texture pre‐
loading module explained later) and the height of the shoulder in OpenGL dimensions. In each
instance, declared by means of a Instancia tag, one declares the position in which the starting
element is placed (in the image, in lighter green/red), the direction in which road spans is given by
the rotation parameter (in the image, an arrow shows the road span direction), length is defined in
multiples of the grid dimensions. The parameter shoulderSide defines whether the shoulder is to be
drawn on all 2 sides, on either the left or the right side, or on none of them. The mirror
parameter defines texture mirroring options: if mirror has the value 1, the texture will be drawn
mirrored. All three parameters length, shoulderSide and mirror are optional, being their default
values respectively 1, all and 0.
<RoadStretches> <Road1 tgaFile="road1.tga" width="45" height="45" shoulderTexName="shoulder1" shoulderHeight="7"> <Instancia position="3,0,0" rotation="0" length="3" shoulderSide=”right” mirror=”1”/> <Instancia position="-2,0,3" rotation="90" length="3" shoulderSide=”both”/>
</Road1> </RoadStretches>
75
A.2.3. Road curves
Road curves correspond to stretches of road spanning along 90° curves. The previous version of the
simulator did not allow for the definition of curves in a scenario and defaulted to the use of textures
to create curves. This element allows for the creation of curves according to several parameters such
as the curve radius (given in grid coordinates) and its placement in the scenario.
Road curves are implemented in a separate class named RoadCurves and are placed under the group
CurvasEstrada in the definitions file. As with road stretches, road curves are declared in a group with
several instances, in which the position is defined in multiples of the defined grid dimension. An
example of a road curve definition is shown below.
Figure A.5. Example placement of 2 road curves according to the specified format. The black lines along the road stretches represent the shoulders and the arrows the direction span of the curves.
The sample image displayed above can be declared like this:
Figure A.6. XML source code corresponding to the scheme in figure A.5.
The declaration of Curve1 includes the declaration of the texture file in the tgaFile tag, the grid
dimension in the parameters width and height, shoulderTexName and shoulderHeight are
<RoadCurve> <Curve1 tgaFile="road1.tga" width="45" height="45" shoulderTexName="shoulder1" shoulderHeight="7"> <Instancia position="-2,0,2" rotation="0" radius="3" shoulderSide=”left”/> <Instancia position="2,0,1" rotation="90" radius="3"/>
</Curve1> </RoadCurve>
76
respectively the name of the texture to use in the shoulders (previously defined in the texture pre‐
loading module explained later) and the height of the shoulder in OpenGL dimensions. In each
instance, declared by means of a Instancia tag, one declares the position in which the starting
element is placed (in the image, in lighter green/red), the direction in which road spans is given by
the rotation parameter (in the image, an arrow shows the road span direction), radius is defined in
multiples of the grid dimensions. The parameter shoulderSide defines whether the shoulder is to be
drawn on all 2 sides, on either the left or the right side, or on none of them. The mirror
parameter defines texture mirroring options: if mirror has the value 1, the texture will be drawn
mirrored. All three parameters length, shoulderSide and mirror are optional, being their default
values respectively 1, all and 0.
Curves are always drawn with a positive 90° angle; if a curve with a negative 90° angle is desired, it
must be drawn with an adequate rotation angle and starting point as to describe a positive 90° angle
relatively to its starting point and orientation.
A.2.4. Billboards
In the context of computer graphics and simulations, billboards are objects that are constantly
directed towards a given object or direction, typically the camera. Billboards are typically used to cut
back on the number of polygons for objects which have the same aspect regardless of the direction
from where they are looked at (trees are typical examples of objects benefiting from this technique).
Billboards consist essentially of textured polygons (typically rectangles) which are rotated at each
frame so that they always face the desired object. For further details on the billboarding technique
please refer to [Fernandes], on which both this introduction and the source code for the billboards
on this simulator are based.
Billboards were already available in the previous version of the simulator (in fact, they come with the
AVTGL framework on which the simulator was built), but the need for further usage pushed the need
to define these objects in the scenario definitions file. This required a change to the AVTBillboard
class, as well as the creation of a new group BillBoards for their declaration.
Unlike other elements, the declaration of billboards is done in absolute OpenGL coordinates. An
example of a billboard declaration group is given below.
Figure A.7. XML sample code of a billboard declaration group.
<BillBoards> <Billboard1 texName="texture1" type="CYLINDRICAL_MATRIX" position="0,0,0" width="5" height="10" centered="0"/> </BillBoards>
77
All billboards are declared inside the BillBoards group. This particular billboard is named
Billboard1 and uses the texture named texture1 (previously defined in the texture pre‐loading
module explained later). The type parameter defines the type of billboarding desired (it can be
either SPHERICAL_MATRIX, for rotation on all 3 axis, or CYLINDRICAL_MATRIX, which limits the
rotation around the vertical Y axis (only the X and Z values are changed). The location and dimensions
in OpenGL coordinates are respectively defined in the position parameter and in the pair of
parameters width and height. The centered parameters defines the placement of the center point
for spherical billboarding, as well as placement options, in the following manner: if centered has
value 1, then the center point for billboarding is the center of the rectangle, and that point
corresponds to the position coordinate (meaning that, given a height of 10, the Y coordinate of the
billboard will vary between ‐5 and 5); if centered has the value 0, then the center point for
billboarding is in the center of the side of the rectangle which has the lowest Y value (meaning that,
given a height of 10, the Y coordinate will vary between 0 and 10). Typically spherical billboards will
use centered with value 1, and cylindrical billboards will use centered with value 0.
A.2.5. Texture preloading
There are situations in which the same texture is used in elements of different types. For example,
one could wish to use the same texture for creating a billboard and as a shoulder in a road stretch.
This allows for better graphics memory usage besides other advantages.
Texture pre‐loading was already available on the simulator (through the classes AVTTextureManager
and AVTLogicalTexture, both from the AVTGL framework) and can now be achieved through
declaration in the XML definitions file, and these textures can be used in other elements (such as
billboards or shoulders for road stretches and road curves). Textures are declared in the Texturas
group. An example of a texture pre‐loading block is given in the figure below.
Figure A.8. XML sample code of a texture pre‐loading declaration group.
In the example above, there are 2 textures, named tex1 and tex2, respectively corresponding to the
files texture1.tga and texture2.tga which are defined by the tgaFile parameter. The following 2
parameters define which loader is used: if special is 0 the IL texture loader (from the DevIL object
loader) is used, if special is 1 the GL_TGA texture loader is used instead. In the latter case, one can
<Texturas> <Texture1 name="tex1" tgaFile="texture1.tga" special="1" tgaMode="GL_RGBA"/> <Texture2 name="tex2" tgaFile="texture2.tga" special="0"/>
</Texturas>
78
define the desired mode (either GL_RGBA, GL_RGB, or default). For further details on modes, please
consult the GL_TGA documentation.
A.2.6. Transparency modes
Images must be loaded in TGA format, either with 3 channels (RGB) or 4 channels (RGB plus alpha
channel). Transparency in TGA files must be created using their alpha channel, rather than a specific
palette color (as with GIF files). For details on how to create alpha channels on TGA, please refer to
the manual on your favorite image editor.
A.3. New logging behavior
The usability tests intended for this work made it necessary for a reformulated logging module,
allowing that some logging parameters were defined in a definitions file (so they could be changed
from test to test and for increased flexibility). Also, some features were added for comfort and better
modularization. The changes to the logging behavior include different log data, a new way to define
the log options, the concept of log stretches and the possibility to log only parts of the course, which
are explained in detail afterwards. Also, for convenience sake, file creation behavior was changed
and now every execution of the application produces a different file, numbered sequentially; as
before, different sessions of the simulator are possible if the simulation is started multiple times
without exiting the application. The actual data to be logged is still source‐code dependent, and is
specified in the Vehicle update routine.
A.3.1. Log definitions
Some logging definitions are now made on XML, in a file logDefs.xml placed under the data folder. A
sample logging definitions file is shown in figure A.9.
Figure A.9. Sample XML source code in a logDefs.xml file.
The file consists of a LogDefs base tag with 2 groups in it: the Logger definitions and the Stretches
group, which are used to define the stretches in the scenario in which logging occurs. More details on
log stretches follow in the next section. As for the Logger tag, it has 4 parameters: logFolder
specifies the folder in which the log files are to be stored (relative path from the folder containing
the executable file), logFileName specifies the prefix to the log file name (to which sequential
<LogDefs> <Logger logFolder="logs/" logFileName="log" logExtension=".txt" timeBetweenLogs="1000"/> <Stretches> <Stretch number="1" tileSize="45" entryPoint="3,0,0" exitPoint="-2,0,4"/>
</Stretches> </LogDefs>
79
numbering is added by the application), logExtension specifies the suffix for the log file name
(typically the file extension). In the given example, log files will be named log0000.txt,
log0001.txt, … Finally, timeBetweenLogs specifies the time in milliseconds between log entries.
A.3.2. Log stretches
Log stretches are the parts of the course which are to be logged. A log stretch is defined in multiples
of a given grid dimension, having an entry point which triggers the beginning of the log session and
an exit point triggering the end of the log session. In this manner, tileSize defines, in OpenGL units,
the dimension of the tiles (a square grid is assumed), entryPoint defines the entry point and
exitPoint the exit point, both in grid coordinates.
Figure A.10. Graphic scheme of the stretch defined in figure A.9. Whatever path is described by the vehicle (in purple), logging will begin when it enters the red circle and end when it enters the green circle.
The meaning of the entry and exit points is as follows: when the vehicle approaches the entry points,
logging starts; when the vehicle approaches the exit point, logging ends; approaching means the
vehicle is inside the circle inscribed in the tile where the corresponding entry or exit points is located.
The entry and exit of a given stretch is registered on the log file with an appropriate message. The
logger makes no assumptions on the path connecting the entry and exit points for a given stretch, as
it works on the basis of proximity to a given point in the scenario. Also, the vehicle can be inside
multiple stretches at a given time, in which case it will log the data as if it was inside a single stretch
(there is only one log file and repeated log entries are not written). If it is intended that the whole
course is logged it is necessary to create a log stretch beginning in the vehicle’s start position and
ending at a place where the vehicle will never pass.
80
A.4. Other minor changes
A.4.1. Changes to vehicle behavior
The behavior of the vehicle was changed for more realistic reactions to both steering wheel and
pedal movements, with changes to the meaning of the parameters on the vehicle declaration in the
XML definitions file.
The new behavior of the vehicle follows mathematical formulas which vary according to gearbox
definitions and current speed (which can be seen in the comments in the source code) and produce
the change of speed in terms of parameters such as current speed, the amount of pressure on the
accelerator and brake pedals, which are multiplied respectively by the parameters maxAcceleration
and maxBreak in the vehicle definition to obtain the influence of these pedals in the vehicle’s
behavior.
A.4.2. Changing the comfort systems interface during the simulation
Changing the comfort systems interface used is now possible on‐the‐fly while the simulation runs,
avoiding the need to exit the course and re‐starting. To change the simulator interface, the user must
press the 1 key (change to the traditional interface) or 2 key (change to the integrated interface). This
change implied slight changes in the menu loading module, which now allows for multiple interface
definition files to be provided. For details please consult the source code, as the changes are minimal
(mostly to the AVTScenegraph class, including a handler block for the relevant key presses, and the
Menu class for handling the multiple interface definition files).
A.4.3. New course
A new course was designed for the simulator, using old and newly available primitives. Taking the
goals for the work into account, and the consequent change in fog definitions, the flat shadows
functionality was disabled for coherence.
A.4.4. Minor bugs
Some minor bugs to the code were also corrected, the most important ones being the non‐drawing
of billboards on rearview mirrors (because of the reflection transformation the normal vectors were
wrong – this was corrected by changing the cullface behavior when drawing rearview mirrors) and
the vehicle’s crashing behavior which led to some situations in which the vehicle would cross some of
the obstacles. Also, some bugs related to misreading of parameters from XML files were also
corrected (some parameters were being ignored in the vehicle definitions, and some parameters
were being wrongly parsed as integers rather than floating point numbers).
81
A.5. Acknowledgements
The simulator uses the AVTGL framework, made by Bruno Araújo for use in the course Animação e
Visualização Tridimensional (3D Animation and Visualization) at Instituto Superior Técnico; this
framework uses the following libraries:
• GLM, by Nate Robins (http://www.pobox.com/~nate);
• DevIL, available at http://openil.sourceforge.net ;
• GL_TGA, by Nate Miller ([email protected]);
• STurboCD, by Mauro Figueiredo ([email protected]).
Parts of the menu structure, as well as some of the vehicle control logic was inspired on the
OmegaSpeeder2 project, developed by the author and by João Proença and Nuno Cruces.
Street textures on the urban part of the course were made by the author based on textures available
from http://www.turbosquid.com/FullPreview/Index.cfm/ID/220910.
Road textures on the rural part of the course were made by the author based on tarmac textures
available from http://dundee.cs.queensu.ca/wiki/index.php/Will's_Notes.
Stone ground and grass textures are based on the textures available from
http://www.lunerouge.org/.
3D objects from the free object collection of http://www.max‐realms.com/ .
Traffic sign textures are either based on the images available from www.highwaycode.gov.uk or
made by the author.
The skybox texture used is the Example Skybox Texture Set from SkyMatter, freely available for non‐
commercial use from http://skymatter.thegamecreators.com/?f=sample.
All other unidentified resources were created by the author.
82
Annex B. User’s Manual This annex intends to explain briefly the simulator usage, describing the set‐up for its use, the
sequence of steps to start a simulator session, and possible user options during the simulation. This
annex is the translation to English of the Annex C in [Por06], with slight changes to accommodate the
modifications introduced in the simulator.
B.1. Material
In order to use the simulator it is necessary, in addition to the software application, to have the
following:
• One joystick (in this simulator a Logitech Force 3D Force Feedback Joystick is used);
• One gaming set of steering wheel and pedals (in this simulator a Thrustmaster Ferrari GT 2‐
in‐1 is used).
The following instructions assume the usage of the indicated devices. When using other devices,
some adjustments are required.
Figure B.1. Screen sequence for activating the centering spring (from top to bottom).
83
B.1.1. Device installation
The first step is to install the input devices on the computer, using the drivers provided. During the
installation the default options can be assumed.
Afterwards, it is necessary to configure the joystick to enable the centering spring function. This can
be done in the Control Panel, in the Game Controllers option. In this screen, press the «Settings»
button; next, activate the «Enable Centering Spring in Force Feedback Games» option, and set the
«Centering Spring Strength» to its maximum value (150%). After all is done, press «OK» on every
screen until every screen is closed.
B.2. Running the simulator
To run the simulator, start the batch file Simulador.bat, which can be found on the Simulador-
Executavel folder. This folder should be copied to a temporary location on the hard disk drive with
write permission so that the log file can be written and all the files needed by the underlying
framework can be created.
Upon entrance, the application shows some menu options. Selection of the wanted option in menus
is made using the arrow keys (up and down); activation of the selected option is made with the
space key. On the application menu, the user has the option of starting the simulation or exiting the
simulator. In the following menu, the user can choose between the (only) course available or going
back to the previous menu.
B.2.1. Driving the vehicle
The vehicle is controlled by the steering wheel and pedals, just like any automobile: steering turns
the vehicle to either side, the left pedal is the brake and the right pedal is the accelerator. The
paddles on the back of the steering wheel control the direction in which the car goes: pressing the
left paddle (steering wheel button 9) puts the car in reverse driving; pressing the right paddle
(steering wheel button 10) puts the car back in forward drive. Changing the car direction can only be
made with the vehicle at full stop.
Alternatively, for debugging purposes, the arrow keys can be used to control the vehicle: the up
arrow works as the accelerator, the down arrow as the brake, and the left and right arrows steer the
vehicle. If wanted, a cruise control option is available. It can be activated by pressing the cruise
control button (steering wheel button 11) while none of the pedals is pressed. To deactivate cruise
control, simply press one of the pedals or press the cruise control button again. Cruise control was
not used in the test procedure in this work, but is available from the previous version of the
simulator.
84
B.2.2. Comfort systems – traditional interface
Control of the comfort systems through the traditional interface is done by pressing the adequate
button on the touch screen (or alternatively using a mouse). Steering wheel buttons are also
available but not used in the test procedure for this work. The usage of the system is similar to the
use of a production vehicle comfort system: for better comprehension the figure below displays the
interfaces and the function of each button.
Figure B.2. Integrated interface controls.
B.2.3. Comfort systems – integrated interface
The joystick is used to control the integrated system by navigating through the menu structure.
There are 4 basic movements: pushing the joystick left, right, forward or backwards. There is also a
button that can be pressed (the trigger button). None of the other buttons are used here.
Options are selected by pushing the joystick towards the appropriate direction (according to the
graphical representation on the screen) and activated by pressing the trigger button. On every
screen where effective manipulation of parameters is done (e.g. changing the volume) no activation
is required: the change happens on selection. Some options require the user to repeatedly push the
joystick in the appropriate direction, then back to the center and then again back to the appropriate
direction, as to navigate along the sequence of options (e.g. in the air flow options screen).
85
Nonetheless, to exit those options, upon pushing the joystick backwards, it is also necessary to press
the trigger button. Two screen examples are shown in the following figure.
Figure B.3. Two example screen for the integrated interface: the top level menu of the climate control (left) and
the volume control menu for the sound system (right).
On the left screen of the above figure, pushing the joystick in each of the 4 directions selects the
respective option (left selects «Fan Speed», forward selects «Temperature Setting», right selects «Air
Flow Options», back selects «Main Menu»). Activation happens when the user presses the trigger
button. On the right screen, pushing the joystick right increases the sound volume and pushing the
joystick left decreases; however, to return to «Radio Options», the user must first select the option
and then activate it.
86
Annex C. Quiz for the usability tests
Highway hypnosis and in‐car telematics ‐ Influence in driving and safety Mestrado em Engenharia Informática e de Computadores
Acácio Carreira Porta Nova
Introdução
Este questionário diz respeito a um trabalho de mestrado, em desenvolvimento, relacionado com interfaces para os comandos de conforto de um automóvel. Concretamente, pretende‐se estudar a ligação entre o uso dos sistemas de conforto de um automóvel e a condução em ambiente monótono. Para esse fim, foi desenvolvido um simulador, com o objectivo de levar os utilizadores a realizar um percurso predefinido durante o qual os utilizadores têm de realizar certas tarefas usando os sistemas de conforto disponíveis.
O que lhe pedimos é que, depois de ter interagido com o sistema, responda a este breve questionário, relatando a sua experiência. Todos os dados são confidenciais e serão usados, única e exclusivamente, para análise estatística no âmbito do trabalho em curso.
Informação estatística
Idade: anos
Sexo: Masculino Feminino
É titular de uma carta de condução? Sim Não
Se sim, há quanto tempo?
Perguntas sobre o percurso
1. Durante a simulação, teve a sensação de que o percurso era monótono / repetitivo / aborrecido?
Sim Não Não sei
2. Como considera o seu estado de atenção durante a realização do percurso (apreciação geral)?
Elevado Médio Baixo
3. Comparando o seu estado de atenção em dois períodos (período em que se limitou a conduzir o veículo e período em que desempenhou tarefas com os sistemas de conforto), acha que estava?...
Estava mais atento no período em que me limitei a conduzir
Estava mais atento no período em que desempenhei tarefas com os sistemas de conforto
Estava igualmente atento em ambos os períodos
87
4. Classifique, de 1 (mau) a 5 (excelente) o seu grau de atenção ao percurso nas seguintes fases:
Enquanto só conduzia
Enquanto conduzia e realizava tarefas recorrendo ao sistema tradicional
Enquanto conduzia e realizava tarefas recorrendo ao sistema integrado
5. Durante o percurso foi‐lhe pedido que identificasse, quando os avistasse, certos elementos característicos – árvores, obstáculos, …
5.1. Considera que, durante o percurso, houve alguma situação em que não se apercebeu da aparição de certos elementos, ou só se apercebeu da sua aparição passado algum tempo?
Sim Não
5.2. Se respondeu sim à pergunta anterior, descrimine a sua resposta relativamente a 3 partes do percurso. Para este efeito, classifique da seguinte forma:
‐ Atribua 0 à(s) parte(s) em que julga ter‐se apercebido da aparição de todos os elementos; ‐ Para o(s) troço(s) em que julga ter deixado escapar algum elemento, classifique de 1 (deixou escapar menos) a 3 (deixou escapar mais).
Troço em que só conduzia
Troço em que conduzia e realizava tarefas recorrendo ao sistema tradicional
Troço em que conduzia e realizava tarefas recorrendo ao sistema integrado
6. Qual a sua percepção do tempo que levou a desempenhar as tarefas com os sistemas de conforto tradicional e integrado?
Demorei mais tempo com o sistema tradicional
Demorei mais tempo com o sistema integrado
Demorei mais ou menos o mesmo tempo com ambos os sistemas
7. Classifique, de 1 (muita) a 5 (pouca) a necessidade de se concentrar ao usar a interface dos sistemas de conforto para realizar tarefas:
Recorrendo ao sistema tradicional
Recorrendo ao sistema integrado
Outros comentários.
Fim do questionário.
Muito obrigado pelo seu tempo
88
Annex D. Examiner form
Troço 0: Perguntas aleatórias para introduzir o tipo de perguntas possíveis.
Troço 1: Segmento 0: Cruzamento: Para onde era a viragem? Esquerda. Ao fim de alguns minutos: O perfil da estrada mudou desde o cruzamento? Não. Segmento 1: Depois do S: A curva foi esq‐dir ou dir‐esq? Esq‐dir. Primeiro conjunto de árvores: Viste a árvore de cor diferente? Verde, à esquerda, 1. Cruzamento: Viste a árvore? Árvore verde à esquerda, 1 Segundo conjunto de árvores: Havia árvores verdes dos dois lados, esq ou dir? Dos 2, 1 em cada lado. Alargamento: Havia um sinal a indicar o alargamento do outro lado? Não. Obstáculo 1: IGNORAR. Obstáculo 2: O obstáculo era para desviar do quê? Árvores, 3, vermelhas. Cruzamento: Direcção? Esquerda.
Troço 2: Segmento 0: Erros sem tarefas Fim da curva: Curva sempre na mesma direcção ou mudou a meio? Mudou Tipo A Tipo B Ao fim de alguns minutos: Muda o rádio para a pré‐sintonia 5. Estava ali um 40 ou eu vi mal? Vi mal.
Segmento 1: Erros tradicional Depois do S: Reparaste que a curva à esq era apertada e a à dir gradual? Sim. Tipo A Tipo B Alargamento: IGNORAR. Sinais: Muda o som do rádio. Reparaste na árvore junto ao sinal da direita? Sim, verde, 1. Curva / contra curva: Mete a ventoinha no máximo. Qual era o perfil da estrada durante a curva? 2+2 Estreitamento A/C para corpo e pés Viste o sinal a avisar do estreitamento? Não existia. Árvores: Rádio na frequência N abaixo da actual. Havia árvores do lado esquerdo da estrada? Não. Obstáculo: Mete a temperatura a 30°. Quantas árvores haviam no obstáculo? 3. Depois do estreitamento: Muda para pré‐sintonia 1. Antes de estreitar, o traço contínuo era simples ou duplo? Duplo.
89
Troço 3:
Segmento 0: Erros sem tarefas Fim da curva: Qual foi maior, a curva esq ou a curva dir? Esq. Tipo A Tipo B Ao fim de alguns minutos: Muda o rádio para a pré‐sintonia 5. Viste a árvore do lado esquerdo? Não existia.
Segmento 1: Erros integrado Depois da curva: Que tipo de traço tinha a curva? Descontinuo. Tipo A Tipo B Alargamento: IGNORAR. Sinais: Muda o som do rádio. Quantas árvores havia junto aos sinais? 2, 1 verde esq e 1 vermelho dir. Curva / contra curva: Mete a ventoinha no máximo. Não havia um sinal de trânsito a avisar da curva? Não. Estreitamento: A/C para corpo e pés. Antes do estreitamento, quantas faixas havia em sentido oposto? 2. Árvores: Rádio na frequência N abaixo da actual. Quantas árvores verdes? 3. Obstáculo: Mete a temperatura a 30°. Viste a árvore verde? Não existia. Depois do estreitamento: Muda para pré‐sintonia 1. Havia um sinal de trânsito do lado oposto? Não.