SAFESPOT Project SP1 Meeting 3 rd – 4 th April, Berlin 1 Integrated Project Co-operative Systems for Road Safety “Smart Vehicles on Smart Roads” Debra

1SAFESPOT Project SP1 Meeting3rd – 4th April, Berlin

Integrated ProjectIntegrated Project

Co-operative Systems for Road Safety Co-operative Systems for Road Safety

““Smart Vehicles on Smart Roads”Smart Vehicles on Smart Roads”

Debra Topham, David Ward

MIRA Ltd (UK) {debra.topham, david.ward}@mira.co.uk

T1.2.1 Leader

SAFESPOTSAFESPOTSAFESPOTSAFESPOT


Objectives for this meeting

• Agree a common approach to Use Cases

– taking into consideration needs of other SPs (SP2, SP3, …)

• …


Presentation Plan

• T1.2.1 aim

• Use case background

• Approaches to representing use cases

• Pros and cons of representation

• Proposed use case

• Use case titles

• Classification by area

• Collection of further use cases

• Planning of next steps


Approaches to Use Case definition

1. “We have a sensor, what could we use the data for”?

2. “What driving scenarios exist, within which we could collect data to support co-operative functions?”

• Chosen (Suggested? Recommended??) approach in T1.2.1

• Define use cases as event-driven driving scenarios

– These have safety related implications

• To be able to extract essential information from the spatial and temporal situation of the scenario from which the “System under Design” is able to provide warning messages to the Driver, Other Vehicles or the Infrastructure


T1.2.1 View Point of Use Cases

To define event driven use case driving scenarios that have safety related implications in order to extract essential information from the spatial/temporal situation of the scenario from which the “SuD” is able to provide warning messages to the Driver, Other Vehicles or the Infrastructure in order to minimise road traffic

incidents.


Use Case Terminology

• Use case definition: A use case captures the systems response under various conditions as it responds to a request from a primary actor

• Stake holders:

• Actor definition:

• Boundary Diagram:


Boundary Diagram

Safeprobe

platform


Use Case Representation

• Template

Textual step wise description of the interaction an actor has with the system

• UML

Graphical representation of the interaction an actor has with the system using standard semantics


Pro’s and Cons of use case representation

•Template

– Easy to read

– No knowledge of tool required

– Contains detailed data about use case data

–Data easily accessible

–No tools required to implement use case

•UML

– Knowledge of programming tool and semantics required

– Each partner requires software

–Does not show detail

–Interaction diagrams

–Can get difficult to follow


Choice of Use Case Representation

Choice: Textual step wise approach

– Why

• Template contains more detail and flexibility

• No knowledge of semantics required

• No tool required

• UML representation can be included in the deliverable for “selected” scenarios

• However, definitions must be consistent and accurate


Proposed Use Case Template

Case Name <Insert the name of the use case. The name should be the gaol as a short verb>

Case ID <Follow use case ID number convention SP1_UC#ID_partnerID#_v1.#>

Status <insert scenario completion status – draft for comment, completed for comment, finalised>

Goal <Insert a brief description of the goal of the scenario>

Level <Level of use case>

Driving environment <Insert the road type – see list of road types>

Vehicle probe type <Insert the type of the vehicle which this use case applies to e.g. all, car probe, truck probe, motorcycle probe>

Successful end condition <Insert the situation when the scenario is achieved successfully>

Failed end condition <Insert the situation when the goal is abandoned>

Trigger <Insert the action/event on the system which triggers this use case>

Frequency of occurrence <Insert how often this expected to occur>

Primary Actor <Insert a role or name description for the primary actor. The primary actor asks the system under design to deliver service or meet the goal of the scenario. See list of actors>

Secondary Actor(s) <Insert name role description of any other actors involved in this scenario. See list of actors>


Scenario Description Step Action

1 <Insert the steps of the scenario from triggering event to goal delivery>

2

3

Extensions Step Action

<insert step altered e.g. 1a>

< Insert extensions, one at a time, each referring to the step of the main scenario. Insert the condition(s) under which the system takes a different behaviour from the main scenario. Then insert the actions which are taken for this condition as steps. The particular condition may result in a failure, include this as the step. The condition may require a different use case to be called, if this is true insert the name of the use case as the step><condition> : <action or sub.use case><1a.1……><1a.2…..>

2a <condition>:<action>

Super ordinates <Insert name of any use case(s) that includes this one>

Subordinates <Insert name of any use case(s) used by this one>

Open issues <Insert any issues which require discussion affecting this use case>


Actor List

•Probe vehicle

•Other vehicle (s)

•Bridge/tunnel infrastructure

•Ambient environment infrastructure

•Roadside infrastructure

•Pedestrian VRU

•Cyclist VRU

•PTW rider VRU

•Vehicle sensors

•Positioning source

•Other roadside sensors

•Roadside actuators

•Local roadside unit

•Central control unit


Triggering Event

Actors triggering probe vehicle scenario:

Roadside infrastructure I2V

Probe vehicles (V2V)

Vehicle sensors


Driving Scenario Attributes

Road types•Motorway/highway

•Urban

•Suburban

•Rural

Weather Conditions•Fog

•Rain

•Wind

•Snow

Road segment•Tunnel

•Bridge

•Curved road

•Straight road

•Intersection/junction

•Roundabout

•Pedestrian crossing–Signalled

–Unsignalled

Diurnal cycle•Night

•Day


Use Case Names (1)

Vulnerable road user warning• Pedestrian in the road• Motorcycle overtaking• Pedestrian on the Zebra crossing• Pedestrian using pelican crossing

Hazard warning• Obstacle detected in the road• Vehicle travelling in the wrong direction• Emergency breaking• Driver braking erratically• Vehicle being driven erratically• Emergency vehicle approaching• Accident warning• Stolen vehicle warning• Lane departure support• Weather conditions• Environmental Effects• Vehicle has run a red light• Road works• Lane restrictions• Dangerous goods being transported• Train approaching road crossing


Use case Names (2)

Driving support• Vehicle exceeding advisory speed limit

• Traffic lights about to change

• Lane departure support

• Road works

• Heavy goods vehicle

• Uneven road surface

Cooperative driving

• Lane merge • Lane change

• Traffic beyond range of ADAS sensors slowing down


Plan of work

• Work with SP2 to define “overlap” use cases

• Allocate T1.2.1 partners to define specific use cases

• Compile use cases

• Create draft deliverable for SP1 comment

• Finalise deliverable

• Deliverable goes for review


Discussion

• Use case groupings

• Triggering actors

• Permutations of use cases given the different attributes for each scenario

• Ideas for further use cases

Documents

SAFESPOT Project SP1 Meeting 3 rd – 4 th April, Berlin 1 Integrated Project Co-operative Systems for Road Safety “Smart Vehicles on Smart Roads” Debra