IT for Error Remediation And Trapping Emergencies … · In this document the term “driver” is...

Deliverable No. 6.2 Dissemination Level (PU) Grant Agreement Number: 218496

ITERATE IT for Error Remediation And Trapping Emergencies

D6.2 User Manual Description

Deliverable No. (use the number indicated on technical annex) D6.2

Workpackage No. WP6

Workpackage Title Model numerical development and tuning

Editor (Editor/Main responsible for D incl. contact details) Aladino Amantini [email protected]

Authors (per company) A. Amantini, P. C. Cacciabue M. Cassani,

Status (F: Final; ECS: EC Submission; RC: Review Copy: D: draft): F

Reviewed and approved for submission (name and date) KITE, 2011/04/01

EUROPEAN COMMISSION DG RESEARCH

A FP7 Collaborative Project Work programme: Sustainable Surface Transport SST.2007.4.1.2: Human physical and behavioural components


ii


iii

Document History Table Version

No. Date Details

V0.1 2011/03/01 TOC V1 2011/04/10 First version V1.1 2011/04/18 Second version V1.2 2011/04/28 Minor corrections


iv

List of abbreviations ATT Attitude CULT Culture DVE Driver Vehicle Environment DS Driver State DVESim Driver Vehicle Environment Simulator EXP Experience FCW Frontal Collision Warning IPS Information Processing System ISA Intelligent Speed Adaptation ITERATE IT for Error Remediation And Trapping Emergencies PIPE Perception, Interpretation, Planning and Execution SiMUD Simulator for Model of Unified Driver SRK Skill-Rule-Knowledge TD Task Demand UMD Unified Model of Driver


v

Table of Contents

Executive Summary ........................................................................................................................ viii

1. Introduction ............................................................................................................................ 1

2. Simulation of Driver Vehicle Environment ............................................................................. 2 2.1 Background ..................................................................................................................... 2 2.2 Driver Simulation and DVE Interaction process ............................................................. 3

2.2.1 The Unified Model of Driver ................................................................................. 3 2.2.2 Dynamic Cognitive Functions and Processes ....................................................... 4 2.2.3 Dynamic DVE Interaction ...................................................................................... 6 2.2.4 Parameters and Driver behaviour ........................................................................ 7 2.2.5 Intentions and decision making ......................................................................... 10 2.2.6 Driver Task Analysis ............................................................................................ 10 2.2.7 Normative driver behaviour ............................................................................... 11 2.2.8 Descriptive driver behaviour .............................................................................. 12 2.2.9 Car Driver steering and acceleration behaviour ................................................ 12 2.2.10 Train driver braking and acceleration behaviour ............................................... 16

2.3 Vehicle Simulation ........................................................................................................ 20 2.3.1 Car ....................................................................................................................... 20 2.3.2 Train .................................................................................................................... 23

2.4 Environment Simulation ............................................................................................... 25

3. Quick User Guide .................................................................................................................. 28 3.1 Software aim and generalities ...................................................................................... 28 3.2 HW/SW specifications and requirements .................................................................... 29 3.3 Installation .................................................................................................................... 29

3.3.1 Folders content ................................................................................................... 29 3.4 Simulation Setup and Data Entry .................................................................................. 30

4. Execution ............................................................................................................................... 36

5. Case Studies .......................................................................................................................... 38 5.1 Scenario ........................................................................................................................ 38 5.2 Driver Conditions .......................................................................................................... 39 5.3 Results ........................................................................................................................... 40

5.3.1 Case A ................................................................................................................. 41 5.3.2 Case B ................................................................................................................. 43 5.3.3 Case C ................................................................................................................. 45

6. Final Considerations .............................................................................................................. 47

References .................................................................................................................................. 48

Annex I – Configuration files .......................................................................................................... 49


vi

List of Tables

Table I: Driver functions, parameters and coefficients ................................................................................. 8 Table II: Parameters of Driver ....................................................................................................................... 9 Table III: DVESim configuration file structure ............................................................................................ 30 Table IV: UMD Car Driver configuration file structure ................................................................................ 31 Table V: UMD Train driver configuration file structure .............................................................................. 31 Table VI: UMD Car Vehicle configuration file data structure...................................................................... 32 Table VII: UMD Train Vehicle configuration file data structure .................................................................. 32 Table VIII: UMD Car Environment configuration file structure ................................................................... 33 Table IX: UMD Train Environment configuration file structure .................................................................. 34 Table X: Environment parameters for case studies .................................................................................... 38 Table XI: Vehicle parameters for case studies ............................................................................................ 39 Table XII: Driver parameter configurations for case studies ...................................................................... 39 Table XIII: Results for driver configuration A .............................................................................................. 41 Table XIV: Results for driver configuration B .............................................................................................. 43 Table XV: Results for driver configuration C ............................................................................................... 45


vii

List of Figures

Figure 1: The proposed ITERATE model ........................................................................................................ 3 Figure 2: Logical interplay of Parameters, Variables and DVE model ........................................................... 4 Figure 3: The UMD in the DVE Architecture ................................................................................................. 5 Figure 4: The Driver-Vehicle-Environment (DVE) system. ............................................................................ 6 Figure 5: Flow-chart of SUM-UM per Δt. ...................................................................................................... 7 Figure 6: Schematic representation of steering process. ........................................................................... 13 Figure 7: Train and signal ............................................................................................................................ 17 Figure 8: Effects of reaction distance on braking ....................................................................................... 18 Figure 9: Car speeds for different gas pedal positions ............................................................................... 19 Figure 10: Train speeds for different accelerator control position ............................................................. 19 Figure 11: Simple model of vehicle kinematics ........................................................................................... 21 Figure 12: Forces acting on a vehicle. ......................................................................................................... 22 Figure 13: Forces acting on the train .......................................................................................................... 23 Figure 14: Force generation by the train engine ........................................................................................ 24 Figure 15: FCW road.................................................................................................................................... 26 Figure 16: ISA Road ..................................................................................................................................... 27 Figure 17: Test railway ................................................................................................................................ 27 Figure 18: Simulator structure .................................................................................................................... 28 Figure 19: Configuration file hierarchy ...................................................................................................... 30 Figure 20: Modules interaction and I/O ...................................................................................................... 37 Figure 21: Plot of configuration A, F=0.625 ................................................................................................ 42 Figure 22: Plot of configuration A, F=0.815 ................................................................................................ 42 Figure 23: Plot of configuration A, F=1 ....................................................................................................... 42 Figure 24: Plot of configuration B, F=0.75 .................................................................................................. 44 Figure 25: Plot of configuration B, F=0.938 ................................................................................................ 44 Figure 26: Plot of configuration B, F=1.125 ................................................................................................ 44 Figure 27: Plot of configuration C, F=1 ....................................................................................................... 46 Figure 28: Plot of configuration C, F=1.25 .................................................................................................. 46 Figure 29: Plot of configuration C, F=1.5 .................................................................................................... 46


viii

EXECUTIVE SUMMARY

This deliverable presents the software simulation platform implementing the UMD: DVESim and SiMUD models.

It presents the theoretical concepts behind the model design and discusses their implementation within the simulator framework. Mathematical correlations are presented and the meaning of their parameters is discussed.

Together with the driver model also the physical models of vehicles and environments, and their interactions with the driver are discussed.

The description of the software usage and the interactions with the user are then provided: its behaviour at runtime, the configuration means and the output generation are detailed.

Finally some case studies, where an exhaustive set of simulations were performed, are presented and the results discussed.


Page 1 of 64

1. INTRODUCTION

The software simulator of the UMD (Unified Model of Driver) is the main outcome of WP 6. It has been developed on the basis of the theoretical background of WP 1 and will be finalised according to the analysis of experiment data that is being performed in WP 5.

The software output, i.e., data files describing the simulated driver performances and driving profiles, will be compared with the results of WP 7 in order to validate the theoretical model.

This document is structured as follows:

• Chapter 1 - Introduction: describes the structure of the document

• Chapter 2 - Simulation of Driver Vehicle Environment: describes preliminary theoretical concepts including the description of correlations and the vehicles physical models.

• Chapter 3 - Quick User Guide: describes the developed software tool, with particular focus on the modules’ configuration.

• Chapter 4 - Execution: describes how to execute the software and its behaviour at runtime.

• Chapter 5 - Case Studies: presents some typical cases of simulation executions and compares the different results.

• Chapter 6 - Final Considerations: presents the steps that will be performed in the next tasks of WP6.

• Annex I – Configuration files: includes some examples of the modules configuration file used to perform the simulations.

In this document the term “driver” is very frequently utilised and refers to the generic human being in the position of operator of the vehicle. According to the goals of the Project ITERATE the terms “driver” refers to the car driver, train driver or ship helmsman/captain governing the vehicle.

When certain specific aspects of the control of the vehicle or special tasks are considered, then a specific discussion will be performed. Typical example of these type of tasks is the “overtaking task” which is specific to the automotive domain, and to a certain extent to the ship domain.


Page 2 of 64

2. SIMULATION OF DRIVER VEHICLE ENVIRONMENT

The overall model of the Driver, Vehicle and Environment (DVE Model) is based on the concept of the “joint” cognitive system, where the dynamic interactions between driver, vehicle and environment are represented in a harmonized and integrated manner. The model aims to represent the interaction between Driver-Vehicle-Environment in a simple and fast running way, which retains the essential correlations between the independent variables and enables to predict driver behaviour in dynamic and rapidly changing conditions.

Moreover, the model focuses on the Driver cognitive and behavioural performances. Therefore, the other two models of the joint DVE system, i.e., Environment and Vehicle, are relatively less dynamic. This is particularly true for the Environment as it is not completely affected by the Driver behaviour, at least in the present modelling configuration, and can not fully contribute to the dynamic evolution of situations.

The overall Unified Model of Driver (UMD), developed in D1.2 (Oppenheim, et al., 2010) is governed by the concept of parameters which enable the consideration of dynamic behaviour and interaction between the three components of the DVE system, as well as the simulation of the error making process.

Five parameters are considered as the basic elements affecting behaviour. They are evaluated on the basis of observable/calculated variables at each time interval of the DVE interaction. The use of analytical correlations is discussed hereafter, whereas the evaluation of the coefficients expressing the weight of each variable in relation to the proposed correlations is being performed within WP 5 of ITERATE and will be reported in Deliverable D 5.1.

From the simulation point of view, the correlations that link parameters with observable variables are open.

2.1 Background Modelling systems requires knowledge of theories and conservation principles, which must be combined with imagination and vision about ways to manage the resulting formulations and equations in such a way that they are solvable enabling to predict dynamic behaviour, given certain boundary and initial conditions. In many cases, the equations and correlations resulting from the theoretical definition of a system can not be solved analytically, even after having made simplifications of various nature, e.g., by linearising dependencies of coefficients, or making strong assumptions about the overall behaviour of components.

Simulation is the process by which a model is further reduced in terms of complexity, transforming the equations and correlations into numerical algorithms, which are then implemented in a computerised formulation that is used to actually predict system dynamic behaviour.

These two steps of development, i.e., modelling and simulation, are necessary in order to obtain a final formulation that preserves the essential elements of the theory, while enabling to predict and calculate system behaviour in a reasonable amount of time and computer power. In many cases, modelling and simulation are not two separate sequential processes, but a certain amount of iteration is necessary between them. This ensures that an adequate balance is kept between the need to capture the essential behavioural characteristics of a systems and the need to calculate in a simple and fast running way the dynamic evolution given boundary and initial conditions.

There is a crucial step in the process of modelling and simulation that consists of the identification of the parameters and correlations that are most relevant and enable to combine model variables with real behaviour of the system. These correlations are essential for the validation of the model as they


Page 3 of 64

enable the model to describe, usually in simple terms, the performances of a system. These correlations are normally developed from extensive number of experiments and field tests of various nature, and appropriate and accurate data analyses.

In the case of the UMD discussed in WP 1 of the ITERATE Project, the choice of the modeller has been to develop a theoretical formulation that is sufficiently simple and generic to capture the fundamental theories for each of the elements of the DVE system, especially with respect to the “Driver” model (D 1.2). The overall simulation approach has been called SiMUD (Simulation for Model of Universal Driver) and aims at combining the simple nature of the UMD associated with equally detailed simulation of vehicle and environment models.

With respect to the associated correlations between certain parameters and observable variables, the choice has been to implement very generic and flexible formulations which are then formalised in accordance to experimental evidence, resulting from the activity of WP 4 of ITERATE. 2.2 Driver Simulation and DVE Interaction process

2.2.1 The Unified Model of Driver

The DVE model has been discussed in detail in Deliverable D 1.2. Therefore, only a brief summary and description is reported hereafter. The UMD aims at representing the dynamic interactions between driver, vehicle and environment (Figure 1). This model must be able to predict performance / behaviour of the joint DVE system and the consequences of such DVE interaction. Also, it must be able to account for multiple, simultaneous activities, like the ones concerning the typical activity of a driver.

Figure 1: The proposed ITERATE model

The UMD takes into account a set of variables that enable the performance of the DVE interaction in dynamic conditions and the parameters that influence the individual behaviour of the three components of the DVE system, namely the Driver, the Vehicle and the Environment.

In order to establish the actual performance of the Driver, it is necessary to identify the main procedures that are required during a DVE interaction, enabling the consideration of sets or groups of actions that are performed in order to reach specific goals. There are two relevant aspects to consider in order to structure driver activity and interaction with vehicle and environment:


Page 4 of 64

• the analysis of the tasks that are carried out and

• the consideration for possible human inadequate performances or errors (Error Propensity in Figure 1). This second aspect is not part of the current development and will no longer be discussed. However, the possibility to include human error in the simulation of the DVE interaction, using the UMD approach, is an option that can be easily explored and included in the simulation and software development.

Thus, in order to correlate the interplay of the three components of the DVE system, it is necessary that the parameters governing driver performance are calculated at each time interval of the simulation on the basis of the variables that are measured, or calculated, from the other modules and the driver model itself (Figure 2).

Figure 2: Logical interplay of Parameters, Variables and DVE model

In the current implementation of the simulator only one parameter, the Task Demand, changes during time, according to the definition of the intended scenario.

2.2.2 Dynamic Cognitive Functions and Processes

In order to implement the UMD in a simulation of DVE interaction it is necessary that the cognitive processes that generate the actions of the driver are represented. To this purpose, the “classical” Information Processing System (IPS) paradigm (Neisser, 1967; Newell and Simon, 1972) is applied. The most known examples of the IPS paradigms are: the Skill-Rule-Knowledge (SRK) model of Rasmussen (1983, and 1986) and, specific for the domain of automotive transport, the Michon’s (1985) scheme, where the (primary) driving task can be described on different levels of abstraction, namely strategic, tactical and operational.

The way in which the various cognitive functions and processes of the model are implemented in the simulation is quite simple and straightforward, and depends on two possible types of modelling architecture: the simple and linear normative driver behaviour or the complex and more realistic descriptive driver behaviour. By normative behaviour it is meant that the driver follows closely the regulations and norms of driving, respecting limits and boundaries defined by road traffic rules. By descriptive behaviour it meant that the driver is affected by personal attitudes, motivational aspects, adaptation etc.

The most suitable approach for representing driver behaviour during the performance of normative and descriptive activities is to apply a simple “Task Analysis” (Kirwan and Ainsworth, 1992). The detail of accuracy of the analysis and description of the tasks that are performed by the driver defines also the granularity of the simulation (Michon, 1985). By carrying out a driving Task Analysis,


Page 5 of 64

the performance of a driver can be formalised and structured in a sequence of actions and goals that are carried out during the interaction with the vehicle and environment.

The overall requirements of the simulation associated to the driver model are that of being predictive, simple and fast running, accounting for dynamic interactions, human errors, and adaptive behaviour. A very simple model that respects the principles of the IPS paradigm, and enables the consideration of these requirements is the PIPE (Perception, Interpretation, Planning and Execution) model (Cacciabue, 1998). The PIPE model is fully focused on four basic functions that govern the IPS mechanisms. These are (Figure 3):

1) Perception of sensorial inputs (signals) generated by the Vehicle and Environment.

2) Interpretation of relative information.

3) Formulation of goals and intentions and/or selection of tasks to be carried out (Planning).

4) Performance of actions.

Figure 3: The UMD in the DVE Architecture

In order to account, even though in a simplified form, for the cognitive processes that affect human beings in consideration of the parameters affecting behaviour and underpinned by the UMD model, the SiMUD simulation implements the critical process of intention and decision making and structures the driver performances in accordance to tasks. Both decisional processes and tasks are implemented in two different ways, namely:

• Normative behaviour. This behaviour can be characterised by a driver where no motivational or adaptive behaviour is accounted for and thus no filtering occurs. “Normative behaviour” is defined as the behaviour of a driver that respects the rules and regulations, such as speed limits etc.

• Descriptive behaviour considers motivational or adaptive filtering is applied, and it is more related to actual driving attitudes and habits, which includes deviations from respect of rules and norms, especially with reference to speed limitation and safety distances.


Page 6 of 64

The overall simulation dynamic is governed by the time unfolding and generation of intentions and decisions of the driver model. This is another crucial aspect of the model, from the theoretical viewpoint, as it impacts on the validity of the overall approach and is correlated to an enormous amount of research that has been performed and is still developed, in association with human attitudes, characteristics, personality, individual and social aspects, etc. The literature on this matter dates many decades and is rich of many different theoretical stands and formulations.

The set of defaults conditions existing in the simulation are now discussed. These are simple correlations that govern primarily development of intentions and decision making, and error generation.

2.2.3 Dynamic DVE Interaction

The simulation of DVE interaction is implemented according to the flow-chart shown in Figure 4. The simulation is based on the interaction of the three components Driver, Vehicle and Environment, governed by a fourth component called Simulation Manager.

Vehicle Dynamic

Simulation Manager

Environment

Obstacles Environmental

Parameters

Driver Parameters Driver

Task analysis & Driver

Decisions/Actions

Figure 4: The Driver-Vehicle-Environment (DVE) system.

The simulation in Figure 5 shows the flow-chart that has been implemented for the dynamic SIM-UD interaction. It contains the development of intentions (upper part of the model) in terms only of selection of an intended speed and lateral position and “Execution” of actions (lower end of the model structure). The execution is performed according to a typical skill-based approach, governed by the dynamic definition of the intended speed and lateral position (input to this section), and calculates the actions in terms of steering, braking force and acceleration.

The detailed evaluation of the tasks that are selected and carried out by the driver during the DVE interaction will be described in the next sections. The general principle that is followed in order to implement the decision making process and the execution of actions is that the driver decides and


Page 7 of 64

selects and performs tasks, according to the theoretical UMD model and in consideration of contextual conditions. However, when an emergency situation is encountered or an imminent hazard is perceived, then an evasive manoeuvre is implemented. These evasive manoeuvres are associated to special tasks that are permanently examined by the simulation every time step of the driver simulation.

The generic output of the driver simulation is eventually described in terms of steering, braking or accelerating, according to the task under execution and its associated goals.

Driver Model

Intention development => identify Active Task: 1. Previous task is continued.

2. New task started.

Driver Vehicle

Environment

Permanent tasks require evasive manoeuvre

Y

N Carry out permanent tasks

at t = ti

Vehicle & Environment

Perception of signals and signs

Intention development => Evasive Manoeuvre (Active Task)

Execute actions according to Active task

Interpretation of signs and signals.

Intended speed & lateral position

• Steering • Brake force • Acceleration

Simulation Manager

TDt = Task Demand DSt = Driver State

Figure 5: Flow-chart of SUM-UM per Δt.

2.2.4 Parameters and Driver behaviour

In general, various driving modes can be simulated according to the choice and execution of different tasks. These vary from vehicle to vehicle, i.e., car, train or ship, and can be summarized in the following 4 main tasks:

1. Cruise


Page 8 of 64

2. Overtake / Lane change

3. Follow

4. Start / Stop

The choice and execution of these tasks is determined by the “driver” behaviour and attitudes which will affect interaction with the “vehicle” controls. Such aspects are modelled by means of several variables and functions, which are summarised and briefly introduced in the following Table I and will be discussed in detail in the remaining sections of this document.

Table I: Driver functions, parameters and coefficients

ATT Parameter describing the driver Attitude EXP Parameter describing the driver Experience DS Parameter describing the Driver State TD Parameter describing the Task Demand CULT Parameter describing the driver culture F i Generic function computing the driver performances when performing the ith operation f Function computing the contribution of ATT and EXP for F i g Function computing the contribution of DS for F i h Function computing the contribution of TD for F i Ki CULT dependent constant contribution of F i αi CULT dependent coefficient of function f β i CULT dependent coefficient of function h γ i CULT dependent coefficient of function g ∆t Time step of the simulation vint Intended speed vmax Maximum speed vleadingvehicle Speed of the leading vehicle pcurve Intended speed coefficient Sint Intended distance from leading vehicle gas Position of gas pedal gr Gas pedal pressing ratio brake Position of brake pedal br Brake pedal pressing ratio XW Distance from train to warning signal XL Distance from warning signal to speed limit signal X Distance from train to speed limit signal Xreact Distance from signal at which the driver starts to react Visibility Distance at which a signal is seen by the driver test Time spent by train to reach the speed limit signal if speed remains constant tint Time spent by train to reach the speed limit signal if speed properly decreases

The model of Driver behaviour has been further simplified in order to capture the basic effects of the factors or parameters affecting behaviour, which have been identified in Culture (CULT), Experience (EXP), Fatigue (DS), Task Demand (TD) and Attitude (ATT).


Page 9 of 64

In the SiMUD the values associated to the parameters are associated with discrete quantities. These have been selected in such a way to enable the association the essential variables of driver behaviour, such as speed, distance, acceleration and braking mode, with reasonably expected values. Tuning of the simulation according to the results of the experiments carried out in the “iterating” simulator, will enable differentiate between different types of drivers and cultures.

The following discrete values of the parameters will be associated to different types of driver characteristics and contextual and personal conditions (Table II) :

Table II: Parameters of Driver

ATT 0 (Prudent)

1/8 (Sensation seeker)

EXP -1/8 (Novice)

1/8 (Experienced)

DS 1/8 (Alert)

-1/8 (Fatigued)

TD 1/8 (Low)

0 (Medium)

-1/8 (High)

CULT is considered separately and is not intended to have a numeric value, but is instead used to identify the nationality of the driver.

A generic expression combining these factors has been developed and will be utilized throughout the simulation in different occasions:

)(*)()(*)(),(*)()( TDhCULTDSgCULTEXPATTfCULTCULTKF iiiii βγα +++= EQ ( 1 )

Where:

TDTDhDSDSg

EXPEXPATTfATTEXPATTfATT

==

=⇒==⇒=

)()(

),(04/1),(8/1

EQ ( 2 )

The value of the three parameters α i , β i , and γ i and of the constant Ki will be determined according to the results of the analysis of the data collected during experiments (WP4 and WP5) and their values are expected to vary according to the different countries in which they were performed.


Page 10 of 64

2.2.5 Intentions and decision making

The generation of intentions is simulated by means of a very simple correlation that enables the dynamic identification and implementation of tasks and elementary functions and the development of new intentions and goals, as the overall DVE interaction progresses and new traffic conditions are met (Figure 5).

At default level, the correlation that has been chosen is very simple and it is based on the driver assessment of the cost-benefit of the minimum time to reach the objective, i.e., going from the starting point of the journey to its destination in the minimum allowable time. In other words, the vehicle is “driven” at the highest “intended” speed which is, in general, a function of the “maximum” allowed speed vmax, depending on the rules and regulations and contextual conditions, i.e., for the automotive environment, speed limits and traffic/road conditions.

The meaning of maximum speed varies according to the application domain and can depend on:

• Driver parameters

• Speed limits

• Vehicle characteristics

• Time Scheduling

The general equation to compute the desired speed, vint, is as follows:

vFvv maxint = EQ ( 3 ) The decision making process concerning the direction of the vehicle is not affected by the F function and the driver parameters. There is not a direct decision making process concerning the direction of the vehicle. In fact it is an optimal one: the angle (Δφ) is a direct consequence of the meta-goal that rules all the simulation architecture (Task Analysis and Parameters calculation). In order to satisfy the objective of reaching a destination in the minimum allowable time, the simulator will have to calculate the position of the vehicle and the direction change in order to maintain the path, to avoid obstacles and, if necessary, to go past other vehicle.

Moreover the decision of the vehicle direction can also be missing: for instance in the case of the train, where the driver can only control the speed of the vehicle.

The consequent dynamic unfolding of tasks, depends on this simple process of decision making associated with the intention of the driver to select and maintain the intended speed, as the limits change along the path.

2.2.6 Driver Task Analysis

The most suitable approach for representing driver behaviour during the performance of activities, is based on “Task Analysis” approach. In order to represent the set of Tasks that are carried during driving a number of basic elements have been identified, namely:

• Elementary Functions, which represent the basic activity that can not be further subdivided into simpler components; examples of elementary functions are: Perceive warnings, Steer, Accelerate, Brake, Change gear, etc.


Page 11 of 64

• Elementary Tasks, which are Tasks made of Elementary functions only; example of elementary tasks are: Attain lower/higher speed, Stop vehicle, Change lane, etc.

• Complex Tasks, which are Tasks made of a combination of several Elementary Tasks and Elementary Functions; examples of complex tasks are: Turn left, Turn right, Pass Vehicle, Overtake.

The following Tasks are foreseen in the simulation, although not all yet implemented: Stop vehicle, Reverse vehicle, Turn left, Turn right, Change lane, Pass Vehicle, Overtake, Keep lateral safety margins, Keep longitudinal safety margins, Maintain speed, Give way at intersection, Emergency manoeuvre.

A fundamental characteristic of the model is the consideration for the hierarchy between tasks. Two hierarchical levels are assigned: permanent tasks and normal tasks. Permanent Tasks are identified by the fact that they are permanently carried out during a DVE interaction and do not require specific pre-conditions to be launched. These are stereotypes of what may be called “skill-based behaviour” in the modelling architecture based on a Skill-Rule-Knowledge (Rasmussen, 1983). Two tasks are considered permanent in the present simulation approach, namely: Keep lateral safety margins, Keep longitudinal safety margins. The concept of permanent tasks is quite straightforward, as it is associated with the fact that drivers “normally” keep, with no specific effort and cognitive demand, the vehicle within lane margins and do not hit vehicles or obstacles in front. The same applies when they perform simple control actions to reach a clear goal, once a certain task is launched, such as stopping the vehicle at a red traffic light. Consequently, these two tasks are permanently active in the DVE loop and are always launched and performed every time the Driver has “decided” or “selected” what to do next in order to attain the desired values of speed and steering of the vehicle.

In practice, every time the driver simulation is activated in the DVE loop, a check is made on whether a permanent task is required (Figure 5). They aim of the permanent tasks are to keeping the vehicle under control with respect to longitudinal and lateral coordinates of the driving environment (road and traffic). If a permanent task is required, then the relevant activities are launched in priority and executed. Otherwise the driver continues with the ongoing task or selects a new task according to the dynamic DVE interaction (Figure 4).

2.2.7 Normative driver behaviour

In normal conditions, i.e., when the driver has a very low or zero level of impairment and no behavioural adaptation occur, the simulation covers what may be called normative driver behaviour. This is a merely theoretical condition which is not reflected in realistic behaviours. However, from the simulation point of view it is necessary that these formal aspects of driver behaviour are represented and stored in the overall simulation tool.

The following sequence of steps is performed:

1. All signals and signs that are produced inside and outside the vehicle are perceived.

2. Interpretation is conform with the meaning associated with signs and signals.

3. Intentions are formulated in relation to the ongoing task and the information perceived and interpreted. A task is then either continued or newly started.

4. Actions are carried out according to the “active” task.


Page 12 of 64

The key step in normative behaviour is the process of formulation of intentions. In the simulation a very simple approach has been selected that is based on cost/benefit rule for prioritizing tasks. The rule implies that the driver minimizes cognitive efforts and time for reaching indented location by applying the following principles:

5. Assess whether permanent tasks require a change of task or function (conditional activity).

6. In the case of conditional activity, then adapt to demands of permanent task.

7. Otherwise continue the process.

8. The ongoing task is terminated before starting a new task.

9. Tasks are started only when and if all pre-conditions are satisfied.

10. Speed is kept at the intended one, in relation to signals and traffic, obstacles etc..

2.2.8 Descriptive driver behaviour

In non-normal conditions, i.e., when the level of impairment is such that an “error” may occur, or when behavioural adaptation becomes a relevant factor, then the simulation covers what is called descriptive driver behaviour. In this case, the sequence of steps remains unchanged as far as the information processing is concerned. However, before entering the IPS loop, the parameters governing adaptation and error must be evaluated. This may lead to modifying any of the cognitive functions and possibly to error making. Task selection and performance is also affected by behavioural adaptation. This type of simulation is much more realistic with respect to actual driver behaviour. However, the level of complexity from the simulation viewpoint is much higher and requires some degree of simplification and linearization.

Descriptive driver behaviour is identified by the parameters deified by the UMD model and these enable to modify and adapt the way in which cognitive functions are selected, during the phases of perception, interpretation and intention development, and are performed during the execution of actions.

2.2.9 Car Driver steering and acceleration behaviour

In order to test what has been implemented so far, a basic model of driver has been prepared. Although consolidated this is not “yet” the UMD, but just a simple model performing predefined steering and acceleration tasks.

The following set of correlations shows in condense format the way in which the driver model is implemented in the simulation software called SiMUD. The basic correlations that are utilised in SiMUD are substantiated by means of the analysis of result of the experiments.

2.2.9.1 Steering The driver projects the position of the car in the future (0.5 seconds; this is a parameter of the simulation that can be modified) under the assumption that the speed will remain constant (with no consideration for acceleration, braking or friction). It computes what its final position would be and how much this differs from the desired one (middle of the desired lane). The driver then steers in order to reach the desired position (Figure 6).


Page 13 of 64

Y

Lane centre-line

Carriage middle line

yt

Lane width

vy

vx

α V Position of vehicle forecasted

by visual anticipation

x xt

Figure 6: Schematic representation of steering process.

2.2.9.2 Intended Speed The way in which the intended distance is computed differs according to the task currently performed by the driver. The most general and interesting case is the one of the cruise task, in which the intend speed is:

[ ])(*)()(*)(),(*)()(maxmaxint TDhCULTDSgCULTEXPATTfCULTCULTKvFvv vvvvv βγα +++∗== EQ ( 4 )

According to the values that the constant Kv and the parameters kv, αv, βv and γv assume the intended speed may vary between a maximum and a minimum value. In the case of equal weighing of the parameters, i.e., setting Kv=αv = βv = γv = 1.

max vint = 3/2 * vmax

min vint = 5/8 * vmax

In cruising conditions, the value assumed for vmax is the speed limit of the specific road type. As an example, on a motorway in Italy the standard speed limit is 130 Km/h, and on a rural road is 90 Km/h. Consequently, according to this assumption, in cruise mode:

typeroadmitlispeedv −= _max EQ ( 5 )

If instead the driver is performing a follow task, the goal is to maintain the same speed of a leading vehicle and to avoid collision. For this reason intended is just:


Page 14 of 64

icleleadingvehv

v

icleleadingveh

vFvvF

vv

===

=

*1

maxint

max

EQ ( 6 )

The intended speed of the driver can be modified due to the reaction to signals on the road and to warning systems of the vehicle. In the simulation, in the case of a signal of dangerous curve, the driver reduces the intended speed. To handle this a multiplicative factor pcurve is introduced. It is applied only when dangerous curve signals are present. The following correlation applies:

vcurve Fspvv *)(*maxint = EQ ( 7 )

Where vmax is computed according to the previous EQ (5), and pcurve(s) is equal to 1 if no signal is present, otherwise its value will range from 0 to 1 and will be determined by the analysis of the data collected in the experiments.

2.2.9.3 Intended distance Another value which is constantly computed by the driver is the intended distance sint form a possible leading vehicle. This variable is computed even if the leading vehicle is very far from the ego vehicle or if it is not present at all. It depends only on the current speed of the driven vehicle and it is expressed as:

)(*)()(*)(),(*)()()(*6.1)(*6.1

int TDhCULTDSgCULTEXPATTfCULTCULTKtv

Ftvs

sssss βγα +++==

EQ ( 8 )

Te value v(t) represents the current speed of the vehicle expressed in km/h. The constant Ks and the coefficients αs, βs and γs are determined by the analysis of the experimental data.

The two variables vint and sint are used to:

1. select what task to perform; and to

2. compute the acceleration and braking profiles.

The selection of the task occurs in the following way:

• If the distance from the leading vehicle is minor of 2.5 times the intended distance (s < 2.5*sint) then perform follow task.

• If the distance from the leading vehicle is greater or equal of the intended one (s ≥ 2.5*sint) then perform cruise task.

When the driver approaches a leading vehicle, the transition from a cruise task to a follow task may occur. The following rule is applied for the computation of the intended speed:

• If the distance from the leading vehicle is minor of the intend one (s<sint), then the intended speed is set to the average of the speed of the leading vehicle and the intended speed, as calculated by the general equation EQ (4).


Page 15 of 64

2.2.9.4 Acceleration and braking

General Rules

Gas and braking pedal positions depend on the task being performed. They may assume values between 0 and 1, where the two limit values represent respectively no or full acceleration or braking pedal position.

The gas or brake pedal positions are directly computed according to the following equations:

EQ ( 9 )

Where gr(t) and br(t) are the ratio of the gas and brake pedals, and ∆t is the simulation step.

Car Cruise Mode

In cruise mode, the driver accelerates until the desired speed is reached. Once the desired speed is reached the driver no longer accelerates and, if the car speed becomes higher than 105% of the intended speed, then braking takes place. The pressure on the pedal is proportional to the difference between intended and actual speed.

The following rules apply:

Gas:

• If v(t)≤vint(t) then

))(*)()(*)(),(*)()((*)(

)(1)(

)(1)(intint

TDhCULTDSgCULTEXPATTfCULTCULTKtv

tvFtv

tvtg gggggr βγα +++

−=

−=

EQ ( 10 )

• else

0)( =tgas

Brake:

• If v(t)>vint(t)*105/100 then

))(*)()(*)(),(*)()((*)()(1

)()(1)( intint TDhCULTDSgCULTEXPATTfCULTCULTK

tvtvF

tvtvtb bbbbbr βγα +++

−=

−=

EQ ( 11 )

• else

0)( =tbrake

)()()()()()(

ttbrakettbtbrakettgasttgtgas

r

r

∆−+∆=∆−+∆=


Page 16 of 64

Car Follow Mode

In follow mode, the driver accelerates if two conditions are simultaneously met:

1. the speed of the car is smaller of the intended one; and

2. the car is not too close to the leading vehicle (s(t)>= sint(t)/2).

Conversely braking action occurs if one of the following conditions is verified

1. the speed of the car is 5% greater than the intended speed; and

2. the car is too close to the leading vehicle (s(t)< sint(t)/2)

This is translated in the following rules:

Gas:

• If s(t)>= sint(t)/2 and v(t)≤vint(t) then EQ (10) applies:

gr Ftv

tvtg

−=

)()(1)(

int

• else

0)( =tgas

Brake:

• If s(t)< sint(t)/2

))(*)()(*)(),(*)()((*)(

)(1)(

)(1)(intint

TDhCULTDSgCULTEXPATTfCULTCULTKts

tsFts

tstb bbbbbr βγα +++

−=

−=

EQ ( 12 )

• else if v(t)>vint(t) *105/100, then EQ (11 ) applies:

br Ftvtvtb

−=

)()(1)( int

• else

0)( =tbrake

2.2.10 Train driver braking and acceleration behaviour

Preliminary correlations for the train driver have been studied and formulated. They are currently being tested and, possibly, some modifications and improvements will be introduced in the next phase of research activity. However, their current formulation is sufficiently complete for implementation of the SiMUD software tool.


Page 17 of 64

The correlation for the intended speed of the train driver is the same as the one utilised to represent the intended speed of the car driver.

However, as no other trains are present on the track utilised for the experiments no follow task will be considered and the intended distance will not be used in correlations.

2.2.10.1 Behaviour in view Warning Signals One important task and associated operation that train drivers perform with particular care and attention is the reaction to warning signals, that anticipate and are pre-indications of incoming speed limits. A typical scenario is shown in Figure 7, where a train approaching a new speed limit (red circle) meets a warning signal (yellow triangle) providing the following information about:

• the new speed; and

• the distance between the warning signal and the position at which the new speed limit will actually occur.

Figure 7: Train and signal

In Figure 7, the letters have the following meaning:

• XW: distance between the train to the warning signal

• XL: distance between the warning signal to the speed limit signal.

• X (=XW+XL): distance between the train and the speed limit signal

XW is used to determine when the train driver starts to react to the signals he meets. If XW is greater than the “reaction distance” (Xreact) the driver will normally perform the cruise task. Otherwise, deceleration should start with the aim to adapt to the new speed limit.

• If XW < Xreact

– react to speed limit

• If XW <0 (signal passed)

– perform cruise task

The reaction distance is a variable depending on driver parameters and environmental conditions, namely on the distance at which a signal is visible to the driver:

reactFVisibility /X react =

EQ ( 13 )

Train

x w x L

x

Speed lim. signal


Page 18 of 64

The default value of Visibility, which was used also for the experiments, is 250 m. The reaction distance, Xreact, is expected to impact on the overall simulation in terms of timing and intensity of braking manoeuvres (Figure 8).

Xreact

SPEED

Xreact

Prudent

SSeeker

Figure 8: Effects of reaction distance on braking

This approach will equally be included in the car driver model so as to capture different braking and reaction behaviour.

To perform the reaction to signals two other variables are initially required:

• test, i.e., the time the train would take to reach the speed limit signal, maintaining its current speed; and

• tint, i.e., the time the train would take to reach the speed limit, if the driver would decelerate in order to reach the signal with the right speed.

Assuming that the dynamic of a material point can be applied in this case, the equations to compute test and tint are quite simply derived as:

)(2

)21

21()(

21)(

21

21

)()()(

maxint

maxintintmaxint2

intint

maxint

2intint

int

max

vvxt

vvvttvvvttt

vvvtatvtx

tvva

tvtxttest

+=

−+=−+=−

+=+=

−=

=

EQ ( 14 )

It is worth noting that a, v, tint and x are time dependent and they should have been expressed as a(t), v(t), tint(t), x(t). However, this choice would have made the equations less clear to read.

Contrary to the car driver, the correlations for the train driver do not compute the ratio of accelerator and braking, but they are used to directly compute the value of the controller position.


Page 19 of 64

The reason is that for car the position of accelerator determines the final speed of the vehicle and the ratio of the accelerator determines the acceleration. On the train instead the position of the accelerator determines the force pushing the vehicle and, consequently the acceleration. See § 2.3.2 for the detail vehicle model. In Figure 9 and Figure 10 the evolution of speeds for car and train, for different position of the acceleration controller (1 in red, 0.75 in green, 0.5 in blue and 0.25 in violet) are shown.

Figure 9: Car speeds for different gas pedal positions

Figure 10: Train speeds for different accelerator control position

When a train driver wants to reach the desired speed, then the following equation apply for the acceleration profile, in a way similar to the car driver.


Page 20 of 64

For the acceleration to reach an intended speed higher that the current speed:

traingtrain Ftv

tvtacc −

−=

)()(1)(

int EQ ( 15 )

When braking, e.g., when a speed limit is approaching, the braking profile is:

trainbtrainbtrainbest

train Ftv

tvvFtvvtx

tvtxFtttttbrake −−−

+−=

+

−=

−=

)(2)(1

))(()(2)()(1

)()(1)( max

maxint EQ ( 16 )

It is noticeable that the dependencies with time and space disappear and the correlation depends again only on speeds.

Preliminary tests have shown the need of introducing a minimum acceleration quantities value of 10 % of the accelerator to ensure that the train reaches the intended speed.

Concerning the process associated with the approach for signal reaction will be proved effective, then it will be utilised also for the car driver while approaching speed limit indicators.

2.3 Vehicle Simulation

2.3.1 Car

The simulation of the automobile has been based on the so called “bicycle model” (Figure 11). Overall and lateral dynamics of the vehicle have been inserted in the model in parallel to the control part (governed by the Driver model) in order to carry out the appropriate correction to the inclination of the steering wheel, derived from the frontal and rear wheel cornering. Numerous equations have been implemented with the aim to reproduce a vehicle with six degrees of freedom namely:

• X

• Y

• Speed

• Acceleration

• Braking

• Steering

Inside the lateral dynamics of the vehicle there are also the equations that govern longitudinal dynamics, as it is possible to consider the lateral dynamics as an expansion of the model of longitudinal dynamics.


Page 21 of 64

Y

X

y x

realδ

Figure 11: Simple model of vehicle kinematics

The equations that govern the simulation of lateral dynamics consider seven subsets:

• Motion equations

• Engine

• Aerodynamic forces

• Forces on the tires

• Transfer of forces to rolling,

• Cornering and drift.

• The equations of the forces acting on the vehicle are as follows (Figure 12):

Centrifugal Force = wheelbase

steeringspeedmass )tan(**2

Lateral Resistance = lateralgmass µ**

Air Resistance = coefficentdragsurfacespeedmass _*****21 2ρ

Rolling Resistance = 2** µgmass

Braking Friction = 1*_** µcoeffbrakinggmass

Braking Friction is the force determined by the effect of the braking action performed by the driver. Its intensity is linearly dependent with the braking coefficient, a value between 0 and 1 which describes how much the braking pedal is pushed.


Page 22 of 64

Figure 12: Forces acting on a vehicle.

To explain the traction force some more steps are required.

It is assumed that all the power generated by the engine is transmitted to the wheels. The maximum torque and force applied to the wheels are:

Max Torque = RPMWheel

PowerMax_*2

_*60π

Max Force= RadiusWheel

TorqueMax_

_

The actual force applied to the engine depends on the gas pedal position:

F= tCoefficienPedalGasForceMax __*_

To compute the movement of the car the following steps are performed:

1. Firstly, the contribution of the longitudinal forces is computed

Acc= MassCar

ForcesalLongitudin_

)_(Σ

Delta Speed= dtAcc *

Next Speed= SpeedDeltaSpeedCurrent __ +

Delta_Space (Delta_S) = dtSpeedNext *_

Where dt is the simulation step. During the current simulation, dt value was 0.05s. dt is a parameter of the simulation that can be specified


Page 23 of 64

2. After having computed the value of Delta_S it is possible to compute the new coordinates of the car:

dx= )cos(_ hdgSDelta ∗

dy= )sin(*_ hdgSDelta

where hdg is the heading angle of the vehicle.

3. Then the contribution of lateral forces is calculated:

Lateral Forces= FrictionLateralForcelCentrifuga __ −

Delta T= 2*__ dtMassCarForcesLateral

Lateral dx= l_hdg)cos(latera*elta_TD

Lateral dy= l_hdg)sin(latera*elta_TD

where lateral_hdg is the angle transversal to the final heading of the car (towards the external of the curve).

2.3.2 Train

Train model presents some differences with respect to the car. For train no lateral control and steering task are required and the only controls available to driver are acceleration and brake levers.

The forces acting on the vehicle are the following:

• Traction: motion force determined by the engine of the train

• Braking: force determined by the braking device of the train

• Rolling resistance: force determined by the friction wit the railway

• Air resistance: force determined by the friction with the air

• Curve resistance: force which occurs only in non rectilinear portions of the railway determined by the adaptation of the rigid structure of the train to curvilinear paths.

In Figure 13: Forces acting on the train it is possible to see how the forces apply to the train model

Figure 13: Forces acting on the train

Traction and braking forces are determined by the engine of the train and they depend on the current speed at which the train travels.


Page 24 of 64

Beyond the current speed there are three parameters that determine the amount of the force (traction or braking) generated by the engine:

• The maximum power of the engine

• The maximum force (traction or braking) generable by the engine

• The maximum speed reachable by the train

In Figure 14 it is possible to see how the value of the forces is determined

Figure 14: Force generation by the train engine

Initially, the force is set to a percentage of the maximum determined by the position of the corresponding lever.

Traction= tCoefficienLeverAccTractionMax __*_

Braking= tCoefficienLeverBrakeBrakingMax __*_

If the product between the force and the current speed is less than the maximum nothing happens, otherwise the actual value of the force is reduced according to the laws:

Traction=Speed

PowerMax _


Page 25 of 64

Braking=Speed

PowerMax _

The formulas for the resistances are:

Rolling Resistance=

)21(*_ *SpeedccMassTrain +

Air Resistance=

peed*Length)*Sc(q*Speedcl*Length)ction*(cpy*Cross_SeAir_Densit 0*5.0 2 +++

Curve Resistance=

55_*_

−RadiusCurverCurvefactoMassTrain

The formula of the Curve Resistance is valid for values of Curve_Radius > 150 m, which is a realistic assumption. The Curvefactor parameter is a value that depends on the technologies used on the train. More precisely it is equal to 2 if “radial-steering” technology is used, 6.5 otherwise.

The movement of the train along the path is computed in the same way used for the car:

Acc= MassTrain

ForcesalLongitudin_

)_(Σ

Delta Speed= dtAcc *

Next Speed= SpeedDeltaSpeedCurrent __ +

Delta_Space (Delta_S) = dtSpeedNext *_

Since no lateral forces are considered no other calculus are performed

2.4 Environment Simulation The simulation of the environment presents a limited dynamic behaviour for train and car systems. Few differences occur between the types of environment.

The main purpose of the environment is to provide a set of values, generally physical constants, describing the characteristics of the surrounding world. This includes, in our case, gravity and air density, which are used by the vehicle model to compute forces.

The environment affects the execution of the task currently performed and the choices of the driver. For instance in car domain different kind of roads (urban or rural) have different speed limits, number of lanes and regulations. The same applies also in the ship domain where different areas


Page 26 of 64

(harbour, coastal or open sea) affect the decisions in terms of speed, route and distance to other ships.

The environment defines also the traffic and the characteristics of other vehicles along the path. When present traffic is actually the only dynamic component of the environment, since position and speed of vehicles can change during time.

Finally, the most important aspect of the environment is the definition of the path that the vehicle will follow. Its characteristics will vary according to the current domain and also the specification language used to describe them. For instance, if we consider a road we have to take into account the width of the road in order to evaluate the lateral position of the car with respect to the carriage middle lane, while this feature is not required by the railway description. The description of the road is provided in the open drive format, while for the railway an ad hoc solution has been chosen. A couple of road tracks are used in the DVESim are presented in Figure 15 and Figure 16. They are the road used during the experiments of WP4 for FCW and ISA scenarios.

Figure 13 shows a simplified railway that was used to perform preliminary tests.

Figure 15: FCW road


Page 27 of 64

Figure 16: ISA Road

Figure 17: Test railway


Page 28 of 64

3. QUICK USER GUIDE

3.1 Software aim and generalities The structure of DVESim can be summarised in the following components (Figure 18):

• Main executable responsible for the management of simulation.

• Several available modules among which to choose the driver, vehicle and environment to load in the simulation. SiMUD is a collection of such modules.

• Some static libraries used by both the simulator and the modules.

Input and output management is performed by means of plain text files:

• Input files are specified according to proper xml formats. Different files are used to specify the configuration of the driver, the vehicle and the environment.

• The output of the simulator consists in log files describing the behaviour of the models during the simulation time.

Figure 18: Simulator structure

DVESim provides a general architecture use to de test and validate different models of Drivers, Vehicles and Environments, enabling comparison of results and performances.

The tool can be used to run simulations in two main ways:

• Maintaining the built-in, or default, correlations of models and simply reconfiguring their parameters, e. g., modifying driver behaviour by changing its parameters CULT, EXP, ATT, DS and TD.

• Defining and implementing ad-hoc models for specific cases. e. g., a new model of driver to study behaviour on a pre-defined scenario or a new model of environment to design a new scenario.

The purpose of the original modelling approach of DVE and, in particular, of the driver model is not to obtain a simulation of the highest possible fidelity, but to provide a flexible and durable instrument that can be easily reconfigured and expanded, especially in consideration of the fact that the model and simulation have to be comprehensive of road, railway and eventually maritime transportation systems.


Page 29 of 64

This document will focus on SiMUD modules which provide the implementation of the UMD model defined in the ITERATE project.

3.2 HW/SW specifications and requirements DVESim is a software developed in C++ for MS Windows OS. It is designed to have limited dependencies with other software but to be easily integrated and expanded. It does not require a GUI environment and can be executed by command line.

It was developed and tested using medium-to-high- performance hardware and should provide good performances on the majority of hardware. For a more general overview we provide the profile of the machine used to develop and test the simulator:

3.3 Installation The installation of the simulator does not require special skills. There is no installer as the application runs simply by copying it on any disc on a PC that has the basic requirements listed in HW/SW specifications and requirements section (Chapter 3.2).

3.3.1 Folders content

DVESim In the main folder a batch file dvesim.bat is provided. It launches the real executable passing a predefined configuration file to examine. It is not required to start the simulation in this way but it can be useful if the user does not intend to use a terminal prompt.

DVESim\bin In the bin folder all the executable files are included:

1. DVESimulator.exe: the main executable

2. Dynamic libraries: dll files providing the implementation of the driver, vehicle and environment models

DVESim\bin\config The config directory includes all the files needed to define the behaviour of the simulator and of its modules. Such files are usually defined in xml format and can be modified using any text editor. Each module defined by a dll in the main folder has a corresponding configuration file in the config directory.

DVESim\ext The ext folder includes files not required by DVESim and which do not affect the simulator execution. They can be however useful resources in subsequent activities for instance to visualise and analyse the output of the simulation. Some scripts launching gnuplot to draw graphics using the logfiles as input are provided. It is worth to not that the gnuplot software is not provided with

• CPU: Intel Core 2 Duo E6750 @2.66GHz

• RAM: 2GB @2.66GHz

• OS: Microsoft Windows XP Professional 2002 Service Pack 3


Page 30 of 64

DVESim. If the user intend to use the scripts he will have to download and install the software by himself. Some further actions, such as editing the script file, might also be necessary.

3.4 Simulation Setup and Data Entry Configuration files are organised according to a hierarchical structure, as already declared in D6.1 and shown in Figure 19. The reason of this choice was a natural consequence of the modular approach adopted in DVESim design: using a single configuration file would have implied to define its structure for all the possible modules that could be implemented. This would have obviously been impossible since requirements of future modules would have been impossible do determine.

Figure 19: Configuration file hierarchy

When executed DVESim looks for a configuration file providing the main parameters of the simulation. Such file is an xml file defined by a proper xsd and its structure is shown in Error! Reference source not found..

Table III: DVESim configuration file structure

Tag Parent Attribute Meaning <DVESim> Starting tag <time> <DVESim> Define the time parameters of the simulation dt The length of a single simulation step [s] simulation_length The maximum duration of the simulation [s] <driver> <DVESim> Declares the driver model used in the

simulation library_path The path of the driver dll to load


Page 31 of 64

config_file The path of the driver configuration file <vehicle> <DVESim> Declares the vehicle model used in the

simulation library_path The path of the vehicle dll to load config_file The path of the vehicle configuration file <environment> <DVESim> Declares the vehicle model used in the

simulation library_path The path of the environment dll to load config_file The path of the environment configuration file The basic role of the file is to provide the simulator the following information:

• Which models, i.e., dll files, will be loaded.

• Where their configuration files are.

Generally speaking each module has its own configuration file, whose syntax is independent of the others. It could even not use xml format. For SiMUD models, however, this choice has been kept and the structure of the files is similar.

Table IV: UMD Car Driver configuration file structure

Tag Parent Attribute Meaning <cardriver> Starting tag <driver_params> <cardriver> Human Factor parameters of the driver projection_time How far in the future the driver projects its

position when he has to perform decision making [s]

CULT Culture/Nationality of the driver (FR, IS, IT, SE or UK)

EXP Experience of the driver (Experienced or Novice)

DS Driver State of the driver (Fatigued or Alert) ATT Attitude of the driver (Prudent or SSeeking) <wl> <cardriver> How Work Load changes on the road <wl_change> <wl> Change of the driver Work Load value Value of the Work Load(Low, Medium or High) s Position on the road [m] <log> <cardriver> Log file parameters logfile Full path of the output file Separator String separator for the values of the columns

of the log file

Table V: UMD Train driver configuration file structure

Tag Parent Attribute Meaning <traindriver> Starting tag <driver_params> <cardriver> Human Factor parameters of the driver


Page 32 of 64

projection_time How far in the future the driver projects its position when he has to perform decision making [s]

CULT Culture/Nationality of the driver (FR, IS, IT, SE or UK)

EXP Experience of the driver (Experienced or Novice)

DS Driver State of the driver (Fatigued or Alert) ATT Attitude of the driver (Prudent or SSeeking) <wl> <cardriver> How Work Load changes on the railway <wl_change> <wl> Change of the driver Work Load value Value of the Work Load(Low, Medium or High) s Position on the railway [m] <log> <cardriver> Log file parameters logfile Full path of the output file separator String separator for the values of the columns

of the log file Although Work Load is one of the parameter of the driver it can change during the simulation according to the distance covered by the vehicle.

Table VI: UMD Car Vehicle configuration file data structure

Tag Parent Attribute Meaning <carvehicle> Starting tag <vehicle_params> <carvehicle> Parameters of the physical model of the

vehicle mass Mass of the vehicle [kg] wheelbase Wheelbase of the vehicle [m] front_surface Front surface of the vehicle [m2] drag_coefficient Drag coefficient [] mu_1 Braking resistance coefficient [] mu_2 Rolling resistance coefficient [] mu_lateral Lateral friction coefficient [] max_power Max power of the vehicle engine [W] rpm Vehicle rpm [1/min] wheel_radius Wheel radius [mm] <start_position> <carvehicle> Initial position of the vehicle S_0 Initial curvilinear abscissa of the vehicle [m] T_0 Initial lateral distance of the vehicle [m] <log> <carvehicle> Log file parameters logfile Full path of the output file separator String separator for the values of the

columns of the log file

Table VII: UMD Train Vehicle configuration file data structure


Page 33 of 64

Tag Parent Attribute Meaning <trainvehicle> Starting tag <vehicle_params> <trainvehicle> Parameters of the physical model of

the vehicle mass Mass of the vehicle [kg] max_power Max power of the vehicle engine [W] max_traction Max traction of the vehicle engine [N] max_speed Max speed of the vehicle [m/s] rolling_resistance_c1 Parameter c1 to compute rolling

resistance [m/s2] rolling_resistance_c2 Parameter c2 to compute rolling

resistance [1/s] cross_section Cross section of the vehicle [m2] length Length of the vehicle [m] air_resistance_cp Parameter cp to compute air

resistance [] air_resistance_c1 Parameter c1 to compute air

resistance [1/m] air_resistance_q Parameter q to compute air resistance air_resistance_c0 Parameter c0 to compute air

resistance [1/s] max_braking_friction Max braking friction of the vehicle [N] radial_braking If radial braking is present (1, true) or

not (0, false) on the vehicle <start_position> <trainvehicle> Initial position of the vehicle S_0 Initial curvilinear abscissa of the

vehicle [m] <log> <trainvehicle> Log file parameters logfile Full path of the output file separator String separator for the values of the

columns of the log file

Table VIII: UMD Car Environment configuration file structure

Tag Parent Attribute Meaning <carenv> Starting tag <environment_params> <carenv> Parameters of the environment gravity Gravity acceleration [m/s2] air_density Density of the air [kg/m3] visibility Distance at which the driver sees signals [m] <log> <carenv> Log file parameters logfile Full path of the output file separator String separator for the values of the columns

of the log file <limits> <carenv> Limits of the road speed Speed limit [m/s] <road> <carenv> Road on which the vehicle will travel file Path to the open drive file describing the road


Page 34 of 64

topology <traffic> <carenv> Other cars and obstacle travelling on the road <fixed_obstacle> <traffic> Obstacle which does not move id Id of the obstacle s Curvilinear abscissa [m] lane Index of the lane on which the obstacle is <moving_obstacle> <traffic> Obstacle travelling at constant speed id Id of the obstacle s Initial curvilinear abscissa [m] lane Index of the lane on which the obstacle is speed Travelling speed of the obstacle [m/s] <braking_obstacle> <traffic> Obstacle travelling at constant speed and then

decelerating with constant deceleration when a given position is reached

id Id of the obstacle s Initial curvilinear abscissa [m] lane Index of the lane on which the obstacle is speed Initial travelling speed of the obstacle [m/s] s_braking Curvilinear abscissa where it starts to brake [m] deceleration Decelerarion of the vehicle [m/s] For the environment of the car the traffic is defined in terms of obstacles on the road. Three are three kind of obstacles:

• Fixed obstacles: they do not move and stay on a given position

• Moving obstacles: they travel on a given lane at a given constant speed

• Braking obstacles: like Moving obstacles, but when they reach a given position on the road they start to decelerate at a constant rate ‘till they are stationary

The road file is in the open drive format to which we refer for further details of the specification (http://www.opendrive.org/).

Table IX: UMD Train Environment configuration file structure

Tag Parent Attribute Meaning <trainenv> Starting tag <environment_params> <trainenv> Parameters of the environment gravity Gravity acceleration [m/s2] air_density Density of the air [kg/m3] visibility Distance at which the driver sees signals

[m] <log> <trainenv> Log file parameters logfile Full path of the output file separator String separator for the values of the

columns of the log file <limits> <trainenv> Limits of the road speed Speed limit [m/s] <railway> <trainenv> Railway on which the vehicle will travel

http://www.opendrive.org/


Page 35 of 64

length Length oh the railway [m] <straight> <railway> Straight line part of the railway s_0 Initial position [m] length Length of the straight line part [m] <arc> <railway> Arc part of the railway, having constant

curvature. s_0 Initial position [m] length Length of the arc part [m] curvature Curvature of arc part [1/m] <spiral> <railway> Spiral part of the railway, with curvature

changing linearly. s_0 Initial position [m] length Length of the spiral part [m] initial_curvature Initial curvature of spiral part [1/m] end_curvature Final curvature of spiral part [1/m] In the train environment the railway is not described in a separate file using a predefined format. Instead it is defined in the train environment configuration file. To provide a better understanding of the configuration the xsd files and examples of xml files are provided as Annexes.


Page 36 of 64

4. EXECUTION

DVESim is executed from command line. The path of the configuration file is passed as parameter. If no configuration file is specified a default file, named dvesim.conf.xml, is searched.

DVESimulator.exe config\dvesim.conf_d.xml When DVESim starts the following steps are executed:

1. Reading of the configuration file

2. Initialisation of the simulator parameters

3. Searching for the dll files of the driver, vehicle and environment models

4. Loading of the files

5. Creation of the new instances of the models are

6. Searching for the configuration files of the models

7. Initialisation of the components according to their own configuration filesare also read and used to initialise the components of the simulation. SiMUD modules have log files in which they’ll store the values of their variables during the simulation. Such file are created during their initialisation and prepared for writing.

8. Linking together of the three models, in order to allow their mutual interaction.

After the initialisation step is completed the real simulation process is started. In this phase the program enters an infinite loop in which the status of the system evolves according to the constant interaction among the vehicle, the driver and the environment. At each simulation step the current status of the models is used to compute the next one. Each model has access to the state of the others and can read the values of their variables.

The following states are computed in the following order:

• Driver

• Vehicle

• Environment

However, the order does not affect the final outcome of the process as, to compute the following state, each model uses the current state values and quantities.

After the computation has been accomplished the values of the variables are updated and the order in which the models are updated is the same of the computation task. The time step of the simulation is constant and is defined in the configuration file of DVESim. SiMUD modules write in their log files the new values of their variables, adding a new record.

The program remains in the compute and update loop until one of the ending conditions is met. Such conditions are:

• Maximum simulation time reached

• End of the path reached

• Vehicle deviate from its path (e. g. the car skids and runs out of the road)

In these cases the software exits the loop, unloads the modules and exits the program. When unloaded SiMUD modules close the log files on which they were writing.


Page 37 of 64

For all executions of the simulation no intervention from the user is required. The only way in which the user can affect the results of the simulation is by modifying the configuration files changing the values of the models variables and defining new scenarios.

Figure 20: Modules interaction and I/O


Page 38 of 64

5. CASE STUDIES

To provide a complete overview of the software capabilities a number of case studies are presented.

The focus is on the Car simulation for which a scenario has been defined and executed for different configuration of the driver parameters. The results allow us to confirm the effectiveness of the adopted simulator approach.

5.1 Scenario The purpose of the case studies was to evaluate the differences in performances for different typologies of driver. Focus was put on two main issues of the driving task:

• Choice of the intended speed of the vehicle

• Choice of the intended distance from leading vehicle

For this reason it was necessary to prepare a scenario including both cruise and follow tasks.

The selected scenario consists in the ego vehicle position at the beginning of the road and starting to drive in cruise mode. In the initial section no vehicle is present so intended speed is computed only on the basis of speed limits and driver parameters. When the driver reaches the other car he starts to decelerate and the intended speed is set to the speed of the leading vehicle.

The leading vehicle travel at constant speed from its position. Both speed and position were chosen in order to satisfy the following two condition for every configuration of the driver parameters:

1. Leading vehicle speed is inferior to the one of ego vehicle, so the ego vehicle will reach it and switch to follow mode

2. Leading vehicle initial position is far enough from the ego vehicle in order to permit it to reach its intended speed

The road used to perform the simulation is the one that was used for the ISA experiments and was previously shown in Figure 16. It presents a variety of curves and straight trait that constitute a realistic and non trivial road topology.

Other parameters of the environment are listed in Table X.

Table X: Environment parameters for case studies

Gravity 9.81 [m/s2] Air density 1.1455 [kg/m3] Speed limit 30.55 [m/s] Leading vehicle starting s 500 [m] Leading vehicle starting speed 20 [m/s] The car model is an implementation of the one presented in Chapter 2.3.1. Its configuration is provided in Table XI where its parameters are listed.


Page 39 of 64

Table XI: Vehicle parameters for case studies

Mass 1742.2 [kg] Wheelbase 2.705 [m] Front surface 2.24 [m] Drag coefficient (air resistance) 0.31 [] mu_1 (road friction) 0.25 [] mu_2 (road friction) 0.0137 [] mu_lateral (lateral friction) 0.85 [] Maximum power 128650 [W] Wheel rpm 1000 [1/min] Wheel radius 289 [mm] Initial s 0 [m] Initial t -2 [m] 5.2 Driver Conditions Three different configurations of the driver have been chosen to perform the simulations, each them corresponding to different values of the driver parameters.

Configuration A reflects the most prudent behaviour respectful of the road regulation (speed limits),

Configuration B represents an intermediate driver in terms parameters values.

Configuration C aims at reproducing the most aggressive and self confident driver.

The CULT parameter has not been considered in these simulations and it will not affect the outputs of the F function, even if a more relevant effect of this parameter is expected from the experimental observations.

Table XII: Driver parameter configurations for case studies

Configuration

Parameters A B C

EXP -1/8 1/8 1/8 DS -1/8 -1/8 1/8 TD -1/8 1/8 1/8 ATT 0 0 1/8 To have a complete definition of the driver, however, the values of the parameters k, α, β, and γ are still required, in order to characterize the behaviour of the F functions. These values will be identified from the studies of the experiments carried out utilizing the ITERATE mobile simulator and performed as part of WP5. At present, arbitrary values for these coefficients are applied with no correspondence with experimental data.

Several instances of the F functions are included in the model and contribute to define the driver behaviour, namely, Fv for speed, Fs for distance, Fb for braking behaviour etc. To better understand the impact of k, α, β, and γ, it was chosen to focus only on a single function, in particular Fs responsible for determining the desired distance from the leading vehicle, namely Sint, according to the equation:


Page 40 of 64

sFtvs )(*6.1

int =

It was also chosen to select three set of values ks, αs, βs, and γs in the interval [0, 1], so as to generate three different values of Fs:

• Upper bound

• Lower bound

• Intermediate value

In this way, three different conditions for each of the initial configuration of the driver parameters could be generated leading to a total of nine simulations case studies.

For all the other Fs of the driver, only one value of the coefficients k, α, β, and γ in order to make the simulation as simple as possible, given the demonstration goals of the present simulation runs which do not aim at describing real behavior shown during the experiments, but rather the simulation ability of the SiMUD and DVESim tools. The following values were associated to the coefficients:

• kv, αv, βv, γv, kg, αg, βg and γg, respectively used to compute the intended speed and the gas ratio, were set to 0.5.

• Kb, αb, βb and γb used to compute the braking behaviour were set to 1.

The reason of the choice was to reduce speed and acceleration in favor of braking action because preliminary tests showed the criticality of this issue.

Following this approach it was possible to:

• evaluate the effects of driver parameters, EXP, DS, TD, ATT on driver behaviour; and to

• evaluate the effects of coefficients k, α, β, and γ on a single F function avoiding mutual influences among sets of coefficient of different Fs

5.3 Results The dependent variables and quantities considered during the simulations are:

• Final distance from the leading vehicle

• Minimum distance from the leading vehicle

• Time to reach the final speed.

These values will be shown in the next figures with the following keys:

• Green: desired speed, left y-axis

• Red: actual speed, left y-axis

• Violet: desired distance from leading vehicle, right y-axis

• Blue: actual distance from leading vehicle, right y-axis

Results for the driver configurations A, B and C are respectively listed in Table XIII, Table XIV and Table XV.


Page 41 of 64

5.3.1 Case A

For configuration A the values of the final distance show clear differences ranging from 53.34 m, the maximum for all the performed simulations, to 31.20 m. There are more than 20 meters of difference among the three values. The minimum distance is always equal to the final one because the car slowly reduces the distance with the leading vehicle until it reaches the desired distance. Small fluctuations of intended and final distances occur at regime but they are acceptable. This is also true for the final speed, in this case change in speed is particularly emphasized for F=1. Finally the time needed to reach the desired distance is very close for the three cases, in particular for F=1 and F=0.815. Even if this time interval is quite long, especially if compared with the other Cases B and C, one has to consider that in this simulation the vehicle approaches to the leading vehicle very slowly, as it is possible to see in Figure 21, Figure 22 and Figure 23.

Table XIII: Results for driver configuration A

F Final Distance [m] Minimum Distance [m] Time [s] 0.625 53.34 53.34 353.77 0.815 42.85 42.85 343.04 1 31.20 31.20 342.47 It is worth noting that, at the end of the simulation the actual speed (in red) levels at a value different than the desired speed (in green). This is the logic consequence of the driving mode at which the vehicle is established, i.e., the follow mode. The ego-vehicle travels at a distance close to the desired one with respect to the leading vehicle and its position has small fluctuations. When it becomes greater than the desired distance the (desired) speed increases, as previously discussed. The final result is that the speed and distances are stabilised at desired values, with the former value corresponding to the speed of the leading vehicle. The same applies for all the simulations.

It is equally noticeable that the three figures are very similar and the differences are not observable on the current scales, especially for the distances between ego and leading vehicle. However, as shown in the table of results shown above, there are 20 meters of difference between the lower bond and upper bound case. Moreover, these similarities are also due to the fact the only one function F was adopted for the desired speed (Fv), in cruising more, and for the acceleration mode (Fa). Consequently the maximum speed at which the driver aims to drive (vint) during the first 50 seconds of simulation, and the acceleration profile (gr) are exactly the same for the three case studies. Whereas, adopting more realistic intended speed values and acceleration profiles, these figures would have shown more consistent differences.


Page 42 of 64

Figure 21: Plot of configuration A, F=0.625

Figure 22: Plot of configuration A, F=0.815

Figure 23: Plot of configuration A, F=1


Page 43 of 64

5.3.2 Case B

For configuration B, the vehicle always passes the desired distance and then slows down. The behaviour of the three cases (lower bound, intimidate bound, upper bound) is pretty similar, as it is possible to see in Figure 24 , Figure 25 and Figure 26. It spends from 20 to 40 seconds, depending on the values of F. The time spent to reach the final desired distance is considerably reduced with respect to the configuration A. In fact it is almost the 100-150 seconds less.

The time required to reach the final distance is not the same of the first case. In particular for F=0.938 a little bit longer time is required. This is due to the topology of the road and the curves and specially to the fact that the maximum speed reached by the ego vehicle before beginning the follow mode associated to the presence of a leading vehicle, is in this configuration B, much higher than the speed reached in configuration A, under the same conditions.

Table XIV: Results for driver configuration B

F Final Distance [m] Minimum Distance [m] Time [s] 0.75 43.54 39.85 191.78 0.938 34.39 28.46 203.73 1.125 28.52 19.98 191.86 As expected values of Final and minimum distances are inferior to the one obtained from the first configuration A: they range respectively from 43.54 to 28.542and from 39.85.87 to 19.98.

The fluctuations of the final speed have a width inferior to those of configuration A.

As in the previous set of simulations, the overall values describing behaviour in terms if acceleration and intended speed are not significant as they have been evaluated assuming only one set of values for the Fs concerning speed and acceleration.


Page 44 of 64

Figure 24: Plot of configuration B, F=0.75




Page 45 of 64

5.3.3 Case C

In the last configuration, values for time and distances decrease even further, as expected. The final distance ranges from 32.24 to 21.46 meters and the minimum distances range from 20.97 to 4.15 meters, at a speed of about 20 m/sec (more than 70 km/h). The time necessary to reach the final distance is maximum for F=1.5. This is again due to initial higher fluctuations because of the road topology and speed, as already noticed before. The intensity of braking is much higher than the other two configuration and it is delayed until the last moment.

Table XV: Results for driver configuration C

F Final Distance [m] Minimum Distance [m] Time [s] 1 32.24 20.97 172.50 1.25 25.78 11.86 161.49 1.5 21.46 4.15 195.46 As in the previous cases, Configurations A and B, the profiles for speed and acceleration are similar and therefore the behaviour during the first 50 seconds of simulation between the three cases are irrelevant (not existing). In this Configuration however, the process of stabilising the distance between ego and leading vehicle shows quite consistent differences even in a large scale as the one utilised in the current graphs. This is due to the fact that the driving behaviour simulated, especially in correspondence with function F = 1,5, the final distance (stabilised) is overpasses quite substantially up to 1/5 of the expected value and initiates a process of decelerations and accelerations that lasts some periods before establishing to the correct values of distances and speed. This last case is particularly encouraging, as it shows the potentiality of the proposed simulation algorithms. When the overall behavioural performances will be included, by utilising different values of the function F for different behaviours, like braking and acceleration behaviours, it is expected that an even larger variety of situations and difference in performances will be captured by the simulation. On the other side, the overall simulation architecture and the original model have been kept essentially simple and easy to master. Therefore, it is hoped that the inclusion in the overall simulation of aspects typical of the ships “driver” will be similarly simple and manageable.


Page 46 of 64

Figure 27: Plot of configuration C, F=1

Figure 28: Plot of configuration C, F=1.25

Figure 29: Plot of configuration C, F=1.5


Page 47 of 64

6. FINAL CONSIDERATIONS

DVESim and SiMUD modules provide a suitable implementation of the UMD enabling the user to define different driver’s profiles, to run simulations on customised scenarios and to compare results.

The current stage of SiMUD still requires some additional work in order to complete the software with all the functionalities of the model. In particular the parameters of the F functions will be finalised according to the final outcomes of WP5 where experimental data will be analysed.

Other simulation correlations and certain aspects of the acceleration behaviour are still under scrutiny with the aim to refine the process simulation and attainment of desired speed and acceleration profiles. However, these are considered, at present, as secondary order contributors to the simulation tool, which is consistently running in a very fast mode and with simple user interface.

Train driver model is currently being designed and its implementation is going to be implemented as soon as correlation will be decided. Also the modules for ships are still pending and requires discussions and analysis.

It is not excluded, moreover, that new features, such as changes in interfaces or functionalities, could be introduced if required by results of the analysis of data collected within WP 5 and the subsequent activities carried out in WP 7, where SiMUD and the results of further field observation will be used to validate the UMD model. Any change that will be introduced will be presented and documented in the next deliverables of the project.

Despite possible future improvements DVESim infrastructure is yet enough stable and complete to perform simulations and provide preliminary results.

Its modular structure moreover allows its use for possible activities also outside the scope of the project and not necessarily related with the UMD.


Page 48 of 64

REFERENCES

Ayers, A. J., (1979). Sensory Integration and the Child, Western Psychological Services.

Banuls, R. & al. (1997). Different emotional responses in novice and professional drivers. Traffic and Transport Psychology.

Bruni, S. (2002). Appunti di Meccanica del Veicolo. Milano

Cacciabue P.C. (1998). Modelling and Simulation of Human Behaviour in System Control. Springer-Verlag, London, UK.

Cacciabue, P.C., Re, C., and Macchi, (2007). Simple Simulation of Driver Performance for Prediction and Design Analysis. In P.C. Cacciabue (Ed.), Modelling Driver Behaviour in Automotive Environments. Springer-Verlag, London, pp. 346-378.

Carsten, O., (2007). From driver models to modelling the driver: What do we really need to know about the driver? In P.C. Cacciabue (Ed.), Modelling Driver Behaviour in Automotive Environments. Springer-Verlag, London, pp. 106-122.

Kirwan, B. and, L. K. Ainsworth (1992). Guide to task analysis. Taylor and Francis, London.

Oppenheim, I. et. Al. (2010) “Description of Unified Model of Driver behaviour (UMD) and definition of key parameters for specific application to different surface transport domains of application”. Deliverable D1.2. ITERATE Project. FWP VII, Contract N. 218496.

Michon, J.A. (1985). A critical review of driver behaviour models: What do we know? what should we do? In L.A Evans and R.C. Schwing (Eds.) Human Behaviour AND Traffic Safety. (pp. 487-525). New York: Plenum Press.

Neisser, U. (1967). Cognitive Psychology. Appleton-Century-Crofts, New York.

Newell, A., and H. A. Simon (1972). Human Problem Solving. Prentice-Hall, Englewood Cliffs, N.Y.

Oregon State University, Portland State University, University of Idaho (2007). Transportation Engineering. On line Lab Manual. http://www.webs1.uidaho.edu/niatt%5Flabmanual/

Pueboobpaphan R. and B. van Arem (2010). Driver and Vehicle Characteristics and Platoon and Traffic Flow Stability

Rasmussen J., (1983). Skills, Rules and Knowledge : signals, signs and symbols; and other distinctions in human performance model. IEEE-SMC, 13, 3, pp. 257-267.

Rasmussen, J. (1986). Information processes and human-machine interaction. An approach to cognitive engineering. North Holland. Oxford.

Tapani, A. (2005). Versatile Model for Simulation of Rural Road Traffic. Transportation Research Record: Journal of the Transportation Research Board, No. 1934, Transportation Research Board of the National Academies, Washington, D.C., 2005, pp. 169–178

Treiber, M., A. Hennecke, D. Helbing, (2000). Congested traffic states in empirical observations and microscopic simulations.

Treiber, M., A. Kesting, D. Helbing (2005). Delays, inaccuracies and anticipation in microscopic traffic models

Ungoren, A.Y., and Peng, H., (2005). An Adaptive Lateral Preview Driver Model. Vehicle System Dynamics, 43, 4, pp. 245-259.

Wall E. (2006). Physical modelling of railway vehicles for real time simulation


Page 49 of 64

ANNEX I – CONFIGURATION FILES

Dvesim.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="dvesim" targetNamespace="urn:dvesim:config:simmanager" elementFormDefault="qualified" xmlns="urn:dvesim:config:simmanager" xmlns:mstns="urn:dvesim:config:simmanager" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="dvesim"> <xs:complexType> <xs:sequence> <xs:element name="time" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="dt" type="xs:float" use="required"/> <xs:attribute name="simulation_length" type="xs:positiveInteger" use="required"/> </xs:complexType> </xs:element> <xs:element name="driver" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="library_path" type="xs:string" use="required"/> <xs:attribute name="config_file" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="vehicle" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="library_path" type="xs:string" use="required"/> <xs:attribute name="config_file" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="environment" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="library_path" type="xs:string" use="required"/> <xs:attribute name="config_file" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> iterate_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <dvesim xmlns="urn:dvesim:config:simmanager"> <time dt="0.005" simulation_length="1000"/> <driver library_path="UMDTrainDriver_d.dll" config_file="config/iterate_train_driver_conf_d.xml"/> <vehicle library_path="UMDTrainVehicle_d.dll" config_file="config /iterate_train_vehicle_conf_d.xml"/> <environment library_path="UMDTrainEnvironment_d.dll" config_file="config/iterate_train_env_conf_d.xml"/> </dvesim> iterate_car_driver.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="cardriver" targetNamespace="urn:umd:config:cardriver"


Page 50 of 64

elementFormDefault="qualified" xmlns="urn:umd:config:cardriver" xmlns:mstns="urn:umd:config:cardriver" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="cardriver"> <xs:complexType> <xs:sequence> <xs:element name="driver_params" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="projection_time" type="xs:double" use="required"/> <xs:attribute name="CULT" type="xs:string" use="required"/> <xs:attribute name="EXP" type="xs:string" use="required"/> <xs:attribute name="DS" type="xs:string" use="required"/> <xs:attribute name="ATT" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="wl" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="wl_change" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="value" type="xs:string"/> <xs:attribute name="s" type="xs:double"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="logfile" type="xs:string" use="required"/> <xs:attribute name="separator" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

iterate_car_driver_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <cardriver xmlns="urn:umd:config:cardriver"> <driver_params projection_time="0.5" CULT="IT" EXP="Experienced" DS="Fatigued" ATT="SSeeking"/> <wl> <wl_change value="Low" s="0"/> <wl_change value="Medium" s="100"/> <wl_change value="High" s="200"/> </wl> <log logfile="car_driver_d.log" separator=";"/> </cardriver>

iterate_train_driver.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="cardriver" targetNamespace="urn:umd:config:traindriver" elementFormDefault="qualified" xmlns="urn:umd:config:traindriver" xmlns:mstns="urn:umd:config:traindriver" xmlns:xs="http://www.w3.org/2001/XMLSchema" >


Page 51 of 64

<xs:element name="traindriver"> <xs:complexType> <xs:sequence> <xs:element name="driver_params" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="projection_time" type="xs:double" use="required"/> <xs:attribute name="CULT" type="xs:string" use="required"/> <xs:attribute name="EXP" type="xs:string" use="required"/> <xs:attribute name="DS" type="xs:string" use="required"/> <xs:attribute name="ATT" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="wl" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="wl_change" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="value" type="xs:string"/> <xs:attribute name="s" type="xs:double"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="logfile" type="xs:string" use="required"/> <xs:attribute name="separator" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> iterate_train_driver_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <traindriver xmlns="urn:umd:config:traindriver"> <driver_params projection_time="0.5" CULT="IT" EXP="Experienced" DS="Fatigued" ATT="SSeeking"/> <wl> <wl_change value="Low" s="0"/> <wl_change value="Medium" s="100"/> <wl_change value="High" s="200"/> </wl> <log logfile="train_driver_d.log" separator=";"/> </traindriver> iterate_car_vehicle.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="carvehicle" targetNamespace="urn:umd:config:carvehicle" elementFormDefault="qualified" xmlns="urn:umd:config:carvehicle" xmlns:mstns="urn:umd:config:carvehicle" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="carvehicle"> <xs:complexType> <xs:sequence> <xs:element name="vehicle_params" minOccurs="1" maxOccurs="1">


Page 52 of 64

<xs:complexType> <xs:attribute name="mass" type="xs:double" use="required"/> <xs:attribute name="wheelbase" type="xs:double" use="required"/> <xs:attribute name="front_surface" type="xs:double" use="required"/> <xs:attribute name="drag_coefficient" type="xs:double" use="required"/> <xs:attribute name="mu_1" type="xs:double" use="required"/> <xs:attribute name="mu_2" type="xs:double" use="required"/> <xs:attribute name="mu_lateral" type="xs:double" use="required"/> <xs:attribute name="max_power" type="xs:double" use="required"/> <xs:attribute name="rpm" type="xs:double" use="required"/> <xs:attribute name="wheel_radius" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="start_position" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="S_0" type="xs:double" use="required"/> <xs:attribute name="T_0" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="logfile" type="xs:string" use="required"/> <xs:attribute name="separator" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

iterate_car_vehicle_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <carvehicle xmlns="urn:umd:config:carvehicle"> <vehicle_params mass="1742.2" wheelbase="2.705" front_surface="2.24" drag_coefficient="0.31" mu_1="0.25" mu_2="0.0137" mu_lateral="0.85" max_power="143000" wheel_rpm="6800" wheel_radius="289"/> <start_position S_0="0" T_0="-2"/> <log logfile="car_vehicle_d.log" separator=";"/> </carvehicle> iterate_train_vehicle.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="trainvehicle" targetNamespace="urn:umd:config:trainvehicle" elementFormDefault="qualified" xmlns="urn:umd:config:trainvehicle" xmlns:mstns="urn:umd:config:trainvehicle" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="trainvehicle"> <xs:complexType> <xs:sequence> <xs:element name="vehicle_params" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="mass" type="xs:double" use="required"/> <xs:attribute name="length" type="xs:double" use="required"/> <xs:attribute name="max_power" type="xs:double" use="required"/> <xs:attribute name="max_traction" type="xs:double" use="required"/>


Page 53 of 64

<xs:attribute name="max_speed" type="xs:double" use="required"/> <xs:attribute name="rolling_resistance_c1" type="xs:double" use="required"/> <xs:attribute name="rolling_resistance_c2" type="xs:double" use="required"/> <xs:attribute name="cross_section" type="xs:double" use="required"/> <xs:attribute name="air_resistance_cp" type="xs:double" use="required"/> <xs:attribute name="air_resistance_cl" type="xs:double" use="required"/> <xs:attribute name="air_resistance_q" type="xs:double" use="required"/> <xs:attribute name="air_resistance_c0" type="xs:double" use="required"/> <xs:attribute name="max_braking_friction" type="xs:double" use="required"/> <xs:attribute name="radial_braking" type="xs:boolean" use="required"/> </xs:complexType> </xs:element> <xs:element name="start_position" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="S_0" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="logfile" type="xs:string" use="required"/> <xs:attribute name="separator" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> Iterate_train_vehicle_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <trainvehicle xmlns="urn:umd:config:trainvehicle"> <vehicle_params mass="60000" max_power="1665000" max_traction="114000" max_speed="55" rolling_resistance_c1="0.015" rolling_resistance_c2="0.0002" cross_section="12" length="53.9" air_resistance_cp="0.5" air_resistance_cl="0.008" air_resistance_q="0" air_resistance_c0="0.4" max_braking_friction="0.15" radial_braking="false"/> <start_position S_0="0"/> <log logfile="train_vehicle_d.log" separator=";"/> </trainvehicle> iterate_car_env.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="carenv" targetNamespace="urn:umd:config:carenv" elementFormDefault="qualified" xmlns="urn:umd:config:carenv" xmlns:mstns="urn:umd:config:carenv" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:complexType name="fixed_obstacle_type"> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="s" type="xs:double" use="required"/> <xs:attribute name="lane" type="xs:int" use="required"/> </xs:complexType> <xs:complexType name="moving_obstacle_type"> <xs:complexContent>


Page 54 of 64

<xs:extension base="fixed_obstacle_type"> <xs:attribute name="speed" type="xs:string" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="braking_obstacle_type"> <xs:complexContent> <xs:extension base="moving_obstacle_type"> <xs:attribute name="s_braking" type="xs:double" use="required"/> <xs:attribute name="deceleration" type="xs:double" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="carenv"> <xs:complexType> <xs:sequence> <xs:element name="environment_params" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="gravity" type="xs:double" use="required"/> <xs:attribute name="air_density" type="xs:double" use="required"/> <xs:attribute name="visibility" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="logfile" type="xs:string" use="required"/> <xs:attribute name="separator" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="limits" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="speed" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="road" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="file" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="traffic" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="fixed_obstacle" type="fixed_obstacle_type"/> <xs:element name="moving_obstacle" type="moving_obstacle_type"/> <xs:element name="braking_obstacle" type="braking_obstacle_type"/> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

iterate_car_env_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <carenv xmlns="urn:umd:config:carenv"> <environment_params gravity="9.81" air_density="1.1455

visibility="250""/> <log logfile="car_env_d.log" separator=";"/> <limits speed="30.55"/> <road file="../umdcarenvironment/SpeedWarningMain_uk.xodr"></road> <traffic> <moving_obstacle


Page 55 of 64

id="moving_01" s="500" lane="-1" speed="20"/> </traffic> </carenv>

iterate_train_env.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="carenv" targetNamespace="urn:umd:config:trainenv" elementFormDefault="qualified" xmlns="urn:umd:config:trainenv" xmlns:mstns="urn:umd:config:trainenv" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="trainenv"> <xs:complexType> <xs:sequence> <xs:element name="environment_params" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="gravity" type="xs:double" use="required"/> <xs:attribute name="air_density" type="xs:double" use="required"/> <xs:attribute name="visibility" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="log" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:attribute name="logfile" type="xs:string" use="required"/> <xs:attribute name="separator" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="limits" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:attribute name="speed" type="xs:double" use="required"/> </xs:complexType> </xs:element> <xs:element name="railway" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="straight" type="straight_type"/> <xs:element name="arc" type="arc_type"/> <xs:element name="spiral" type="spiral_type"/> </xs:choice> <xs:attribute name="length" type="xs:double"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> iterate_train_env_conf_d.xml <?xml version="1.0" encoding="utf-8"?> <trainenv xmlns="urn:umd:config:trainenv"> <environment_params gravity="9.81" air_density="1.1455"

visibility="250"/> <log logfile="train_env_d.log" separator=";"/> <limits speed="30"/> <railway length="48113.27412287183456"> <straight s_0="0" length="8800"/> <arc s_0="8800" length="314.15926535897932" curvature="-0.005"/> <straight s_0="9114.15926535897932" length="4000"/> <arc s_0="13114.15926535897932" length="314.15926535897932" curvature="-0.005"/>


Page 56 of 64

<straight s_0="13428.31853071795864" length="6000"/> <arc s_0="19428.31853071795864" length="314.15926535897932" curvature="0.005"/> <straight s_0="19742.47779607693796" length="6000"/> <arc s_0="25742.47779607693796" length="314.15926535897932" curvature="-0.005"/> <arc s_0="26056.63706143591728" length="314.15926535897932" curvature="0.005"/> <straight s_0="26370.7963267948966" length="4000"/> <arc s_0="30370.79632679489" length="314.15926535897932" curvature="-0.005"/> <straight s_0="30684.95559215387592" length="2000"/> <arc s_0="32684.95559215387592" length="314.15926535897932" curvature="-0.005"/> <straight s_0="32999.11485751285524" length="14800"/> <arc s_0="47799.11485751285524" length="314.15926535897932" curvature="-0.005"/> </railway> </trainenv>

IT for Error Remediation And Trapping Emergencies … · In this document the term “driver” is...

Documents

Transcript of IT for Error Remediation And Trapping Emergencies … · In this document the term “driver” is...