IT for Error Remediation And Trapping Emergencies … · The document is divided into three main...

Deliverable No. 6.1. Dissemination Level (PU) Grant Agreement

Number: 218496

ITERATE

IT for Error Remediation And Trapping Emergencies

D6.1 System Specifications and Guidelines for

implementation

Deliverable No. (use the number indicated

on technical annex) D6.1

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) Aladino Amantini

Status (F: Final; ECS: EC Submission; RC:

Review Copy: D: draft): EC

Reviewed and approved for submission

(name and date) Björn Peters, VTI 2010/09/09

EUROPEAN COMMISSION DG RESEARCH

A FP7 Collaborative Project

Work programme: Sustainable Surface Transport

SST.2007.4.1.2: Human physical and behavioural components

Deliverable No. 6.1 Dissemination Level (PU) Grant Agreement

Number: 218496

ii

Document History Table

Version

No. Date Details

V0.1 2010/07/20 First draft

V1.0 2010/08/30 Final

V1.1 2010/09/09 Reviewed version, EC submission


Number: 218496

iii

List of abbreviations

DoW Description of Work

DVESim Driver, Vehicle and Environment Simulator

GUI Graphical User Interface

HF Human Factors

SiMUD Simulator of Model of Unified Driver

UMD Unified Model of Driver


Number: 218496

iv

Table of Contents

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

2. Project interactions ....................................................................................................... 2

3. System Specifications .................................................................................................... 3

3.1 Software overview .......................................................................................................... 3

3.2 Software users................................................................................................................. 4

3.3 Software functionalities .................................................................................................. 5

4. Guidelines for Implementation ...................................................................................... 7

4.1 Software architecture ..................................................................................................... 7

4.2 Runtime behaviour .......................................................................................................... 7

4.3 UMD ................................................................................................................................ 9

4.4 Language and environment .......................................................................................... 10

5. Conclusions ................................................................................................................. 11

6. References................................................................................................................... 12


Number: 218496

v

List of Figures

Figure 1: ITERATE UMD Behaviour .......................................................................................................... 2

Figure 2: DVESim Use Case ...................................................................................................................... 4

Figure 3: Configuration file hierarchy ...................................................................................................... 5

Figure 4: Architecture of DVESim and its components ........................................................................... 7

Figure 5: DVE loop ................................................................................................................................... 8

Figure 6: SiMUD drivers ........................................................................................................................... 9

Figure 7: SiMUD interactions .................................................................................................................. 9


Number: 218496

vi

EXECUTIVE SUMMARY

WP6, “Model development and tuning” deals with the implementation of the Unified Model of

Driver (UMD). Such a model will be derived form the theoretical architecture developed in WP1 and

the analysis of experimental data performed in WP5.

Outcome of WP6 is a software representation of the model able to perform numerical simulation

and computing driver performances and driving profiles. The software will be used in WP7 to validate

the UMD comparing simulations with experimental data and verifying the correctness of the

developed model.

In order to implement in the most effective way the UMD and the simulator a clear view of the

requirements and specification have to be defined, including software architecture, functionalities

and runtime behaviour. For this purpose the document explains the design assumptions and goals as

well as the implementation plan. The deliverable will drive subsequent activities of the WP, namely

the development of the software and the tuning of the implemented model according to

experiments and data analysis.


Number: 218496

Page 1 of 18

1. INTRODUCTION

The document is divided into three main sections.

The first one, Project Interactions describes how the development of the UMD depends on the other

tasks of the project, in particular on how the previous activities have derived a set of requirements

for the model.

The second one, System Specifications, provides a description of what are the goals of the software

and how it is expected to be used. Specific subsections detail that is intended as the final user, how

the user is expected to use the software and what tasks the simulator will support.

The third one, Guidelines for Implementation, adopts a more technically oriented approach and

provides descriptions of the implementation principles and of the expected behaviour at runtime of

the software.

Finally conclusions and considerations on subsequent activities are presented.


Number: 218496

Page 2 of 18

2. PROJECT INTERACTIONS

The Description of Work (DoW) specifies the two main sources of input for the WP6:

• The theoretical framework developed in WP1

• The analysis of driving performances performed on the basis of the experiments carried out

in WP4 and WP5

The theoretical framework has been fully described in D1.2, in which the driver parameters, which

describe its state and are responsible for its behaviour, have been presented and formalised.

Figure 1 shows the structure of UMD and of its interdependencies.

Figure 1: ITERATE UMD Behaviour

Five main variables have been identified: Culture, Attitudes/Personality, Experience, Driver State and

Task Demand/Workload. Their values are determined by mutual relationships as well as exogenous

environmental factors (Traffic, Road and Visibility).

Both parameters and relationships will be considered into implementation phase and their numeric

values will be determined on the basis of the experimental results, performed on real driver

according to the specification provided in D3.1, and their analysis.

The theoretical framework provides also requirements not only for the driver but also for the

interactions between the driver model and the other components of the scenarios, such as vehicle,

systems, environment, and the final outputs of the model, such as Error propensity, Reaction Time,

Projection to risky situations.


Number: 218496

Page 3 of 18

3. SYSTEM SPECIFICATIONS

3.1 Software overview

The goal of WP6 is to implement the UMD and a simulator to execute it. Although this could be

achieved by a single monolithic program the approach followed in the project was in favour of a

modular solution, able to manage different behaviours according to different assumptions.

There are many reasons that have motivated such a choice:

• A modular approach increases extensibility of the software supporting on one side the

development of other possible components and features and on the other the reuse of the

code in future applications.

• Code is kept separated following a rationale that reflects maintenance needs and

architectural choices.

• Although the outcome of the project is a single model of the driver/operator, different

models are needed to perform the simulation, such as models of the different kind of

vehicles and environments which are mutually exclusive during the execution of the

simulation. Developing them in dedicated modules is a choice that meets both logical and

functionality requirements.

• For each simulation running, only the chosen modules are loaded and executed, avoiding

the wasting of memory by unneeded instructions and data.

However, the usage of modules implies some particular issues that are worth of consideration:

• The software will show a greater degree of complexity and will have to manage typical issues

and problems of module integration both during coding and at runtime (dependencies,

compatibility, dynamic loading and unloading…)

• In order to be correctly loaded and executed, modules must provide their functionalities

through a well-defined single interface common for all. The interface must be defined in the

early stage of design and a lot of attention has to be dedicated to this task since further

modification to the interface might have strong repercussions on the rest of the program

and large modification to the code might be needed.

According to what has just been described the final simulator will include two main conceptual

components:

• DVESim (Driver, Vehicle, Environment Simulator): which is the main engine of the simulator

and will supervise its execution.

• SiMUD (Simulator of Model of Unified Driver): which is a suite of modules that will be used

by DVESim to perform simulations of the UMD.

A complete description of the software architecture, including DVESim and SiMUD interactions, will

be provided in section 4.1.

As declared in the DoW the primary aim of the software is to implement the theoretical concepts

into a running tool able to perform fast and reliable representations of Driver Vehicle and

Environment interactions and to predict the Driver behavior. However the platform can be also used

for other purposes:


Number: 218496

Page 4 of 18

• Developing and testing new models of drivers, or extending UMD with new features

• Appling new models of vehicles (cars, trains, ships)

• Appling new models of environment (road map, track geometry, courses or environmental

condition)

• Defining and studying different scenarios to investigate driving performances.

3.2 Software users

Two different types of end user are supposed to make use of the software: Model Developers and

Human Factor Experts (HF Experts). Such roles are not meant to be absolutely disparate, since a user

can have both roles.

Model developer

Model developers are programmers implementing driver, vehicle or environment models to be used

by DVESim. They enrich the platform with modules providing different behaviours and features.

Within ITERATE Model developers will be responsible for the implementation of SiMUD modules.

HF expert

HF experts will execute the DVESim to perform simulations, defining scenarios and using models

created by Model developers. They will analyse the generated output to verify assumptions and

derive conclusions.

Within ITERATE HF experts will be responsible for the validation of the UMD.

If responsibility for the model is shared by different people, a certain level of interaction must be

considered since Model developers will design and implement the modules according to the

specifications of HF experts.

Figure 2: DVESim Use Case


Number: 218496

Page 5 of 18

In Figure 2 a representation of the interactions between users and software components is shown.

3.3 Software functionalities

The functionalities of the simulator will be presented according to the different phases of the

software usage, namely the configuration, the execution and the management of the output.

Configuration

DVESim is configured by a XML file.

Its syntax will be defined by a proper XSD file. The file has a very simple structure and will include

two kind of information:

• Global parameters of the simulation, such as length and time step interval.

• Modules to load and path of their configuration files.

In fact modules have distinct configuration files and their specific behaviour is not defined in the

main configuration file of DVESim. Instead their parameterization and starting conditions are coded

in their own configuration files.

Figure 3: Configuration file hierarchy


Number: 218496

Page 6 of 18

This approach determines a sort of hierarchy of configuration files of which an example is shown in

Figure 3. It is worth to note that even configuration files can too rely on other files, for instance in

SiMUD the environment model for a car based simulation can include an OpenDrive[1] definition of

the road geometry in a .xodr file.

Configuration files of the modules are not forced to be xml files and Model Developers can define

whatever syntax they want according to their needs and preferences. However the firs alternative

should be encouraged and preferred in order to maintain a coherent syntax and structure in the

different configuration files and SiMUD modules will adopt this choice.

Definition of the scenarios is performed editing the configuration files and setting the desired values

to corresponding parameters. No tool or function is provided to perform this task, but being xml files

in plain text format any text editor can be used for this purpose.

Execution

DVESim is executed from a command line. It does not depend on a Graphical User Interface (GUI) to

manage the simulation or to show results. It executes a purely computational task, so it will not

show windows or expect any kind of input from the user. The rationale is to speed up computation

and time of the simulation in order to make possible the automation of execution and the

generation of data corresponding to a wide range of scenarios having different starting conditions.

Possibly a basic visualization of the trends of the main variables will be provided to support

developing and debugging phases.

Output management

The results of a simulation will be stored in log files in text format. DVESim is not intended to show

results of single or aggregated simulations. Instead its goal is to provide data in a simple and

standard format that could be easily used as input by other applications of various type scope which

might include:

• Graphical rendering of the simulation

• Computation of the generated data

• Plotting of graphics

• Comparison with results of other tests


Number: 218496

Page 7 of 18

4. GUIDELINES FOR IMPLEMENTATION

4.1 Software architecture

Figure 4 provides a synthetic view of the software components and of their interactions.

Figure 4: Architecture of DVESim and its components

Three main types of components can be identified as follows:

Main executable

It includes the main engine of the simulator (DVESim), in green in the figure. It is responsible for the

correct behaviour of the simulation and for the interaction of the models.

Dynamic libraries

They are loaded at runtime and include the models that need to be instantiated, shown in orange in

Figure 3. Several modules could be implemented and make available for HF Expert during simulation,

but within ITERATE only those needed for the project (i.e. SiMUD modules) will be developed and

used.

Static libraries

Both the executable and the modules rely on some libraries, shown in yellow in Figure 3. They

provide basic functions and common data types that can be shared among all the components such

as DVELib or just in some particular components such as UMDLib used in SiMUD modules and

ODRLib, used to represent the road.

4.2 Runtime behaviour

At runtime the steps executed by the program are as follows:

1. DVESim parses its configuration file and detects what modules must be loaded and the path

of their configuration files.


Number: 218496

Page 8 of 18

2. Modules are loaded and models instantiated.

3. Configuration files of the modules are parsed and the models are initialised accordingly.

4. Models are linked together so they can interact.

5. The simulation loop is started.

6. The simulation loop is performed until end conditions are met.

7. Modules are unloaded.

8. The simulation ends.

Points 5 and 6 mention the simulation loop (Figure 5), which is an iterative step that advances the

simulation.

Figure 5: DVE loop

For each time step three actions are performed:

1. Each model computes its next status

2. Each model updates its current status

3. Time is increased

When computing its next status a model can read the status of other models. For examples:

• To compute the steering angle vehicle reads the desired steering angle of the driver

• To compute the desired speed the driver reads the visibility of the environment

• To compute the speed the vehicle reads the friction environment

For this reason each model has access to the status of the other models, but of course only in

reading. From a logical point of view the driver is the main actor who collects data from the vehicle

and the environment and actively performs actions to change his own and the vehicle status, for

instance deciding to undertake a different task or pressing the accelerator pedal of the vehicle.

However, in the simulator, each model is responsible for updating its own state and does not

provide interfaces to other models for updating itself. This choice has been made in order to support

the modular architecture of the DVESim in a synchronous simulation process.

End conditions, that determines the conclusion of the simulation, can include elapsed time, covered

distance or position of the vehicle.


Number: 218496

Page 9 of 18

4.3 UMD

As defined in the DoW, the aim of UMD is to be “applicable to and validate for all the surface

transport modes”. However even if a single theoretical model can be applied to different domains,

from an implementation point of view it will not be enough. Different domains imply different

actions that can be performed, dependencies among variables, interactions among the components

of the simulation. In sum, they imply different interfaces. For instance a car driver has to be able to

steer, while this is not required by a train driver, even if they share the same behavioural model.

For this reason different modules will be actually implemented, each one of which will adapt the

generic UMD to a different environment.

Figure 7 shows how this choice will be accomplished during the development phase. A general

model of the driver will be implemented. It will include all the logic of the driver and common

aspects shared by more specific drivers. This includes parameters representing the mental status of

the driver and the reciprocal correlations affecting their values.

Figure 6: SiMUD drivers

Figure 7: SiMUD interactions


Number: 218496

Page 10 of 18

At a lower level specific models of drivers, defining specific behaviours for distinct domains will be

provided. They will be differentiated because of the input they will accept, the output they will

provide and the tasks they will be able to perform.

A similar approach is going to be adopted for the other models of the simulations. In Figure 7 the full

hierarchy of the models is shown, where dashed arrows represents the interactions between the

three topmost level models (in red) and between the train related models (in green).

4.4 Language and environment

DVESim is designed for the Windows XP operating system.

Considering the hierarchical approach introduced in Section 4.3, the adoption of an object-oriented

programming language, able to exploit inheritance mechanisms, is a natural choice. For this reason

DVESim will be coded in C++, using Microsoft Visual Studio 9 (2008).

The recourse to third party software or tools should be avoided and minimized. However when

needed free and open-source solutions should be preferred. For instance Xerces-C++ [2] libraries

have been used to implement the parsers of the configuration files for both DVESim and SiMUD and

free software libraries can be used also for the runtime visualization of the simulation.


Number: 218496

Page 11 of 18

5. CONCLUSIONS

DVESim simulator tool has been designed to validate the UMD according to the experiments that will

be performed. Particular attention has been posed on the extendibility of the software and on the

need to face different application domains.

The designed infrastructure aims at being as flexible as possible in order to support the

implementation of unexpected behaviours and interactions, but also to allow the modelling

environment to be extended with new functionalities and modules.

DVESim has been designed to be an autonomous tool with very few dependencies on third party

tools and solutions. This is however restricted to its behaviour concerning simulation execution. In

fact other software can use the output generated by DVESim to perform any other task.

In the subsequent developing phase attention should be paid to the input and output exchanged by

the different models in order to ensure a proper dynamic interaction.


Number: 218496

Page 12 of 18

6. REFERENCES

[1] Marius Dupuis, OpenDRIVE® Format Specification, Rev. 1.1 (2007), VIRES Simulationstechnologie

GmbH, http://www.opendrive.org/

[2] Xerces-C++ XML Parser, http://xerces.apache.org/xerces-c/

IT for Error Remediation And Trapping Emergencies … · The document is divided into three main...

Documents

Transcript of IT for Error Remediation And Trapping Emergencies … · The document is divided into three main...