Dissertacao Final [071] - fenix.tecnico.ulisboa.pt · 1 Acknowledgements I would like to thank...

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)


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)


Stretch 21


‐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)


Stretch 21


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)


Stretch 31


‐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)


Stretch 31


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


Best when using integrated

Num

ber o

f users


02468

10

Best when using traditional


Best when using integrated

Num

ber o

f users


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.

Dissertacao Final [071] - fenix.tecnico.ulisboa.pt · 1 Acknowledgements I would like to thank...

Documents

Transcript of Dissertacao Final [071] - fenix.tecnico.ulisboa.pt · 1 Acknowledgements I would like to thank...