Chapter 1 - ERTICO.com

Global System for
Telematics
Release DEL_RSQ_3_1
Architecture and
Interface Specifications
Author(s) Alessandro Murro - WP3 Manager (Mizar Automazione SpA)
Date Contractual: 6/27/2005 Actual: 3/23/2006
SP Manager Rasmus D. Lindholm
ERTICO-ITS EUROPE
Tel: +32 2 400 07 30
E-Mail: r.lindholm@mail.ertico.com
IP Manager Peter Van der Perre
ERTICO-ITS EUROPE
Tel: +32 2 400 07 36
E-Mail: p.vanderperre@mail.ertico.com
Abstract This is the first deliverable in WP3 - Architecture and Interface
Specifications for the RSQ sub-project in GST.
Keyword list RSQ sub-project, Architecture and Interface Specifications.
Nature of
deliverable
Deliverable
Number
Version
Number
Report
DEL_RSQ_3_1
2.0
Dissemination PP
Project financially supported by
Project number FP6-2002-IST-1-507033
European Union
DG INFSO

Version
number
DEL_RSQ_3_1 Architecture and Interface Specifications
Control Sheet
Version history
Date Main author Summary of
changes
0.1 15.11.2004 Alessandro Murro First Draft - System
Overview
0.2 13.12.2004 Alessandro Murro Update and Review
0.3 25.1.2005 Alessandro Murro Update
0.4 15.2.2005 Alessandro Murro Review on the basis
of GF remarks
0.5 14.3.2005 Alessandro Murro Review and Update
0.6 22.3.2005 Alessandro Murro Review on the basis
of GF remarks
0.7 18.5.2005 Alessandro Murro Review and Update
on the basis of
Synch Meeting
0.8 29.6.2005 Alessandro Murro Review and Update
with partner’s
contribution
0.9 15.8.2005 Alessandro Murro Review and Update
with partner’s
contribution
1.0 29.09.2005 Alessandro Murro Final Review and
Release Version
2.0 21.03.2006 Amaury Denoo Review and 2 nd
Approval
Release Version
Name Date
Prepared Alessandro Murro 21.03.2006
Reviewed Rasmus Lindholm 22.03.2006
Authorised Rasmus Lindholm 22.03.2006
Circulation
Recipient Date of submission
Project partners 23.03.2006
European Commission 23.03.2006
3/23/2006 II Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Table of Contents
PART 1 - INTRODUCTION AND ENTERPRISE VIEW................................. 18
CHAPTER 1 - INTRODUCTION..................................................................... 19
1.1 Intended Audience .........................................................................................19
1.2 Organisation ...................................................................................................19
1.3 Conventions ....................................................................................................20
1.4 Typographic Conventions .............................................................................20
1.5 Objectives........................................................................................................20
CHAPTER 2 - EXECUTIVE SUMMARY ........................................................ 22
CHAPTER 3 - METHODOLOGY FOR THE DELIVERABLE........................ 23
3.1 Introduction....................................................................................................23
3.2 Architecture Documents................................................................................23
3.2.1 Content of the IP-level Deliverables........................................................24
3.2.2 Content of the SP-level Deliverables.......................................................24
3.3 The Viewpoint Approach of RM-ODP [1]...................................................24
3.4 The Unified Modelling Language (UML) [2] ..............................................24
3.5 Structure of this Document...........................................................................25
3.6 Consistency with IP-level Deliverables ........................................................26
CHAPTER 4 - SYSTEM OVERVIEW............................................................. 27
4.1 Introduction....................................................................................................27
4.2 PSAP1, PSAP2 and Telco Roles ...................................................................29
4.3 Use Cases and Collaborations for RESCUE ...............................................30
4.4 Architecture Elements ...................................................................................37
4.5 Short Description per Element .....................................................................39
PART 2 - LOGICAL VIEW ............................................................................. 59
3/23/2006 3 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
CHAPTER 5 - LOGICAL VIEW PART STRUCTURE ................................... 60
5.1 Introduction....................................................................................................60
5.2 Organisation of the Logical View Part Chapters........................................60
5.3 RESCUE Collaborations overview...............................................................62
5.3.1 UC RSQ 001 – Triggers Automatic Calls Collaborations .......................63
5.3.2 UC RSQ 002 – PSAP1 Collaborations ...................................................64
5.3.3 UC RSQ 003 – PSAP2 Collaborations ....................................................64
5.3.4 UC RSQ 004 – Data to Vehicle Collaborations.......................................65
5.3.5 UC RSQ 005 – Route Guidance Collaborations......................................66
5.3.6 UC RSQ 006 – Blue Wave Collaborations..............................................67
5.3.7 UC RSQ 007 – Virtual Cones Collaborations .........................................68
5.3.8 UC RSQ 008 – Value Added Data Collaborations..................................69
5.4 Relationship between Work Items and Liaisons.........................................70
5.5 Logical View Work Focusing........................................................................71
5.6 Reading Specifications...................................................................................82
CHAPTER 6 - VEHICLE ECALL.................................................................... 84
6.1 UC RSQ 001 - PV - ECALL Activation (Manual/Automatic)...................84
6.1.1 Introduction..............................................................................................84
6.1.2 Use Case Diagram....................................................................................84
6.1.3 Interfaces..................................................................................................85
6.1.4 API Specification.....................................................................................85
6.1.5 Interactions...............................................................................................86
6.1.6 Lifecycles.................................................................................................88
6.2 UC RSQ 001 – PV - ECALL Manual Cancelling........................................89
6.2.1 Introduction..............................................................................................89
6.2.2 Use Case Diagram....................................................................................89
6.2.3 Interfaces..................................................................................................90
6.2.4 API Specification.....................................................................................91
6.2.5 Interactions...............................................................................................92
6.2.6 Lifecycles.................................................................................................93
6.3 UC RSQ 001 - PV - Emergency Data Handling..........................................94
6.3.1 Introduction..............................................................................................94
6.3.2 Use Case Diagram....................................................................................95
6.3.3 Interfaces..................................................................................................96
6.3.4 API Specification.....................................................................................96
6.3.5 Interactions...............................................................................................97
6.3.6 Lifecycles.................................................................................................98
6.4 UC RSQ 001 - PV - Emergency Data Message Sending.............................99
6.4.1 Introduction..............................................................................................99
3/23/2006 4 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
6.4.2 Use Case Diagram..................................................................................100
6.4.3 Interfaces................................................................................................101
6.4.4 Protocol Stack and Specification ...........................................................102
6.4.5 Message Structure..................................................................................109
6.4.6 API Specification...................................................................................116
6.4.7 Interactions.............................................................................................117
6.4.8 Lifecycles...............................................................................................118
CHAPTER 7 - PSAP ECALL ....................................................................... 119
7.1 UC RSQ 002 – UC RSQ 003 – PSAP – Emergency Data Visualisation..119
7.1.1 Introduction............................................................................................119
7.1.2 Use Case Diagram..................................................................................119
7.1.3 Interfaces................................................................................................120
7.1.4 API Specification...................................................................................121
7.1.5 Interactions.............................................................................................122
7.1.6 Lifecycles...............................................................................................123
7.2 UC RSQ 002 – PSAP - Emergency Data Handling...................................124
7.2.1 Introduction............................................................................................124
7.2.2 Use Case Diagram..................................................................................124
7.2.3 Interfaces................................................................................................125
7.2.4 API Specification...................................................................................125
7.2.5 Interactions.............................................................................................126
7.2.6 Lifecycles...............................................................................................128
7.3 UC RSQ 003 – PSAP2 - Emergency Data Retrieving from PSAP1 ........129
7.3.1 Introduction............................................................................................129
7.3.2 Use Case Diagram..................................................................................129
7.3.3 Interfaces................................................................................................130
7.3.4 Protocol Stack and Specification ...........................................................130
7.3.5 Message Structure..................................................................................131
7.3.6 API Specification...................................................................................134
7.3.7 Interactions.............................................................................................135
7.3.8 Lifecycles...............................................................................................136
7.4 UC RSQ 002 – PSAP1 – EOS......................................................................137
7.4.1 Introduction............................................................................................137
7.4.2 Use Case Diagram..................................................................................137
7.4.3 Interfaces................................................................................................138
7.4.4 Protocol Stack and Specification ...........................................................138
7.4.5 Message Structure..................................................................................140
7.4.6 API Specification...................................................................................140
7.4.7 Interactions.............................................................................................141
7.4.8 Lifecycles...............................................................................................142
CHAPTER 8 - PSAP RESCUE MANAGEMENT......................................... 143
8.1 UC RSQ 003 - Transmission of Data..........................................................143
3/23/2006 5 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
8.1.1 Introduction............................................................................................143
8.1.2 Use Case Diagram..................................................................................143
8.1.3 Interfaces................................................................................................144
8.1.4 Protocol Stack and Specification ...........................................................144
8.1.5 Message Structure..................................................................................145
8.1.6 API Specification...................................................................................147
8.1.7 Interactions.............................................................................................149
8.1.8 Lifecycles...............................................................................................150
8.2 UC RSQ 003 – ESV - Emergency Handling Closure................................151
8.2.1 Introduction............................................................................................151
8.2.2 Use Case Diagram..................................................................................151
8.2.3 Interfaces................................................................................................152
8.2.4 Protocol Stack and Specification ...........................................................152
8.2.5 Message Structure..................................................................................153
8.2.6 API Specification...................................................................................155
8.2.7 Interactions.............................................................................................156
8.2.8 Lifecycles...............................................................................................158
CHAPTER 9 - PSAP TO VEHICLE COMMUNICATION ............................. 159
9.1 UC RSQ 004 - ESV - Emergency Data Receipt from PSAP2 ..................159
9.1.1 Introduction............................................................................................159
9.1.2 Use Case Diagram..................................................................................159
9.1.3 Interfaces................................................................................................160
9.1.4 Protocol Stack and Specification ...........................................................160
9.1.5 Message Structure..................................................................................161
9.1.6 API Specification...................................................................................164
9.1.7 Interactions.............................................................................................167
9.1.8 Lifecycles...............................................................................................169
CHAPTER 10 - ESV RESCUE MANAGEMENT.......................................... 170
10.1 UC RSQ 004 - ESV - Emergency Data Visualisation ...............................170
10.1.1 Introduction............................................................................................170
10.1.2 Use Case Diagram..................................................................................170
10.1.3 Interfaces................................................................................................171
10.1.4 API Specification...................................................................................171
10.1.5 Interactions.............................................................................................173
10.1.6 Lifecycles...............................................................................................175
10.2 UC RSQ 004 - ESV - Accept Deployment..................................................176
10.2.1 Introduction............................................................................................176
10.2.2 Use Case Diagram..................................................................................176
10.2.3 Interfaces................................................................................................177
10.2.4 Protocol Stack and Specification ...........................................................177
10.2.5 Message Structure..................................................................................178
10.2.6 API Specification...................................................................................179
10.2.7 Interactions.............................................................................................180
3/23/2006 6 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
10.2.8 Lifecycles...............................................................................................182
CHAPTER 11 - ESV DRIVER SUPPORT.................................................... 183
11.1 UC RSQ 005 – ESV - Calculate Route Options ........................................183
11.1.1 Introduction............................................................................................183
11.1.2 Use Case Diagram..................................................................................183
11.1.3 Interfaces................................................................................................184
11.1.4 Protocol Stack and Specification ...........................................................185
11.1.5 Message Structure..................................................................................186
11.1.6 API Specification...................................................................................198
11.1.7 Interactions.............................................................................................201
11.1.8 Lifecycles...............................................................................................202
11.2 UC RSQ 005 – ESV - Display Route Options............................................204
11.2.1 Introduction............................................................................................204
11.2.2 Use Case Diagram..................................................................................204
11.2.3 Interfaces................................................................................................205
11.2.4 API Specification...................................................................................205
11.2.5 Interactions.............................................................................................206
11.2.6 Lifecycles...............................................................................................208
11.3 UC RSQ 005 – ESV - Target Information Reception...............................210
11.3.1 Introduction............................................................................................210
11.3.2 Use Case Diagram..................................................................................210
11.3.3 Interfaces................................................................................................210
11.3.4 Protocol Stack and Specification ...........................................................212
11.3.5 Message Structure..................................................................................213
11.3.6 API Specification...................................................................................216
11.3.7 Interactions.............................................................................................218
11.3.8 Lifecycles...............................................................................................220
CHAPTER 12 - VEHICLE TO VEHICLE COMMUNICATION ..................... 221
12.1 UC RSQ 006 & 007– ESV – Activate Warning Messages........................221
12.1.1 Introduction............................................................................................221
12.1.2 Use Case Diagram..................................................................................221
12.1.3 Interfaces................................................................................................222
12.1.4 API Specification...................................................................................222
12.1.5 Interactions.............................................................................................223
12.1.6 Lifecycles...............................................................................................224
12.2 UC RSQ 006 & 007– ESV – Reset Transmission......................................224
12.2.1 Introduction............................................................................................224
12.2.2 Use Case Diagram..................................................................................225
12.2.3 Interfaces................................................................................................226
12.2.4 API Specification...................................................................................226
12.2.5 Interactions.............................................................................................228
12.2.6 Lifecycles...............................................................................................229
3/23/2006 7 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
12.3 UC RSQ 006 & 007– ESV – Send Warning Message ...............................230
12.3.1 Introduction............................................................................................230
12.3.2 Use Case Diagram..................................................................................230
12.3.3 Interfaces................................................................................................231
12.3.4 Protocol Stack and Specification ...........................................................231
12.3.5 Message Structure..................................................................................232
12.3.6 API Specification...................................................................................233
12.3.7 Interactions.............................................................................................235
12.3.8 Lifecycles...............................................................................................237
12.4 UC RSQ 006 & 007– PV – Interpret Warning Message ..........................238
12.4.1 Introduction............................................................................................238
12.4.2 Use Case Diagram..................................................................................238
12.4.3 Interfaces................................................................................................239
12.4.4 API Specification...................................................................................239
12.4.5 Interactions.............................................................................................241
12.4.6 Lifecycles...............................................................................................243
12.5 UC RSQ 006 & 007– PV – Receive Warning Message .............................244
12.5.1 Introduction............................................................................................244
12.5.2 Use Case Diagram..................................................................................244
12.5.3 Interfaces................................................................................................245
12.5.4 API Specification...................................................................................245
12.5.5 Interactions.............................................................................................246
12.5.6 Lifecycles...............................................................................................247
CHAPTER 13 - PUBLIC VEHICLE DRIVER SUPPORT............................. 248
13.1 UC RSQ 006 - PV - Reset Warning Message ............................................248
13.1.1 Introduction............................................................................................248
13.1.2 Use Case Diagram..................................................................................248
13.1.3 Interfaces................................................................................................249
13.1.4 API Specification...................................................................................249
13.1.5 Interactions.............................................................................................250
13.1.6 Lifecycles...............................................................................................252
CHAPTER 14 - VEHICLE TO CENTRE COMMUNICATION...................... 253
14.1 UC RSQ 008 – Transmission of Data.........................................................253
14.1.1 Introduction............................................................................................253
14.1.2 Use Case Diagram..................................................................................253
14.1.3 Interfaces................................................................................................254
14.1.4 Protocol Stack and Specification ...........................................................254
14.1.5 Message Structure..................................................................................255
14.1.6 API Specification...................................................................................258
14.1.7 Interactions.............................................................................................261
14.1.8 Lifecycles...............................................................................................266
14.2 UC RSQ 008 – Processing of Data..............................................................267
3/23/2006 8 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
14.2.1 Introduction............................................................................................267
14.2.2 Use Case Diagram..................................................................................267
14.2.3 Interfaces................................................................................................268
14.2.4 API Specification...................................................................................269
14.2.5 Interactions.............................................................................................270
14.2.6 Lifecycles...............................................................................................271
14.3 UC RSQ 008 – Collation of Data ................................................................271
14.3.1 Introduction............................................................................................271
14.3.2 Use Case Diagram..................................................................................272
14.3.3 Interfaces................................................................................................273
14.3.4 API Specification...................................................................................273
14.3.5 Interactions.............................................................................................275
14.3.6 Lifecycles...............................................................................................276
14.4 UC RSQ 008 – ESV – Receive Data ...........................................................276
14.4.1 Introduction............................................................................................276
14.4.2 Use Case Diagram..................................................................................277
14.4.3 Interfaces................................................................................................278
14.4.4 Protocol Stack and Specification ...........................................................278
14.4.5 Message Structure..................................................................................279
14.4.6 API Specification...................................................................................282
14.4.7 Interactions.............................................................................................284
14.4.8 Lifecycles...............................................................................................287
14.5 UC RSQ 008 – ESV – Data Transferred....................................................287
14.5.1 Introduction............................................................................................287
14.5.2 Use Case Diagram..................................................................................288
14.5.3 Interfaces................................................................................................289
14.5.4 API Specification...................................................................................289
14.5.5 Interactions.............................................................................................291
14.5.6 Lifecycles...............................................................................................292
CHAPTER 15 - SECURITY .......................................................................... 293
15.1 Check Security Authorisation.....................................................................293
15.1.1 Introduction............................................................................................293
CHAPTER 16 - SYSTEM MANAGEMENT .................................................. 294
16.1 Introduction..................................................................................................294
16.2 UC RSQ 001 - PV - Acknowledge of Data Sent.........................................294
16.2.1 Introduction............................................................................................294
16.2.2 Use Case Diagram..................................................................................295
16.2.3 Interfaces................................................................................................296
16.2.4 Protocol Stack and Specification ...........................................................296
16.2.5 Message Structure.................................... Error! Bookmark not defined.
16.2.6 Message Structure..................................................................................298
16.2.7 API Specification...................................................................................298
3/23/2006 9 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
16.2.8 Interactions.............................................................................................299
16.2.9 Lifecycles...............................................................................................300
16.3 System Management Liaisons.....................................................................300
PART 3 - IMPLEMENTATION VIEW AND CONCLUSIONS ...................... 302
CHAPTER 17 - IMPLEMENTATION VIEW PART STRUCTURE ............... 303
17.1 Introduction..................................................................................................303
17.2 Organisation of the Implementation View Part Chapters .......................303
CHAPTER 18 - REFERENCE IMPLEMENTATION .................................... 305
18.1 Vehicle ECALL ............................................................................................305
18.1.1 Components ...........................................................................................305
18.1.2 Nodes .....................................................................................................306
18.2 PSAP ECALL...............................................................................................308
18.2.1 Components ...........................................................................................308
18.2.2 Nodes .....................................................................................................310
18.3 PSAP Rescue Management .........................................................................311
18.3.1 Components ...........................................................................................311
18.3.2 Nodes .....................................................................................................313
18.4 PSAP to Vehicle Communication...............................................................314
18.4.1 Components ...........................................................................................314
18.4.2 Nodes .....................................................................................................315
18.5 ESV Rescue Management ...........................................................................316
18.5.1 Components ...........................................................................................316
18.5.2 Nodes .....................................................................................................317
18.6 ESV Driver Support ....................................................................................319
18.6.1 Components ...........................................................................................319
18.6.2 Nodes .....................................................................................................322
18.7 Vehicle to Vehicle Communication ............................................................324
18.7.1 Components ...........................................................................................324
18.7.2 Nodes .....................................................................................................326
18.8 Public Vehicle Driver Support....................................................................328
18.8.1 Components ...........................................................................................328
18.8.2 Nodes .....................................................................................................329
18.9 Vehicle to Centre Communication .............................................................331
18.9.1 Components ...........................................................................................331
18.9.2 Nodes .....................................................................................................332
3/23/2006 10 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
18.10 Security .....................................................................................................333
18.11 System Management................................................................................333
CHAPTER 19 - ARCHITECTURAL ISSUES AND DECISIONS ................. 334
19.1 Vehicle sensors to be triggered ...................................................................334
19.1.1 Objectives ..............................................................................................334
19.1.2 Triggers ..................................................................................................334
19.1.3 Thresholds..............................................................................................336
19.1.4 Source Document...................................................................................336
19.2 eCall service Messages.................................................................................336
19.2.1 Problem identification............................................................................336
19.2.2 Decision .................................................................................................337
19.2.3 Source Document...................................................................................338
19.3 How to transmit MSD from Vehicle to PSAP1 – USSD Protocol............339
19.3.1 Description.............................................................................................339
19.3.2 Definition ...............................................................................................339
19.3.3 Reference Normative .............................................................................340
19.3.4 Deployment:...........................................................................................340
19.3.5 Source Document...................................................................................341
19.4 Guidelines for Emergency Data Visualisation at PSAP Operator ..........341
19.4.1 Problem identification............................................................................341
19.4.2 Decision .................................................................................................341
19.4.3 Arguments..............................................................................................342
19.4.4 Source Document...................................................................................342
19.5 Human Factors Guidelines for Route Navigation System .......................342
19.5.1 Problem identification............................................................................342
19.5.2 List of Alternative Solutions..................................................................343
19.5.3 Decision .................................................................................................343
19.6 HMI considerations for the use of the Blue Wave / Virtual Cones
application in an Emergency Services Vehicle......................................................344
19.6.1 Problem identification............................................................................344
19.6.2 List of Alternative Solutions..................................................................344
19.6.3 Decision .................................................................................................345
19.7 HMI considerations for the presentation of Blue Wave / Virtual Cones
information in a Public Vehicle ..............................................................................345
19.7.1 Problem identification............................................................................345
19.7.2 List of Alternative Solutions..................................................................345
19.7.3 Decision .................................................................................................345
19.8 Value Added Data Application Suite .........................................................346
19.8.1 Problem identification............................................................................346
19.8.2 Possible Scenarios..................................................................................347
3/23/2006 11 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
19.8.3 Decisions................................................................................................349
19.9 Value Added Data Streaming .....................................................................350
19.9.1 Problem identification............................................................................350
19.9.2 List of Alternative Solutions..................................................................353
19.9.3 Decision .................................................................................................353
19.9.4 Arguments..............................................................................................354
19.9.5 Source Document...................................................................................360
19.10 Test and Certification of the eCall protocol at the level of new
implementations .......................................................................................................360
19.10.1 Problem identification........................................................................360
19.10.2 List of Alternative Solutions..............................................................361
19.10.3 Decision .............................................................................................363
19.10.4 Consequences of the decision ............................................................363
19.10.5 Source Document...............................................................................363
19.11 eCall timing issues....................................................................................363
19.11.1 Definitions..........................................................................................363
19.11.2 Legal Issues........................................................................................365
19.11.3 Legal Liabilities .................................................................................366
19.11.4 Network Security ...............................................................................367
19.11.5 Source Document...............................................................................367
19.12 HMI Design Recommendations for eCall system .................................367
19.12.1 Introduction........................................................................................367
19.12.2 Problem identification........................................................................367
19.12.3 Ease of Use ........................................................................................368
19.12.4 Feedback from the system .................................................................369
19.12.5 Driver distraction prevention .............................................................369
19.12.6 Reducing the number of accidental/false calls...................................369
19.12.7 Source Document...............................................................................370
CHAPTER 20 - CONCLUSIONS AND NEXT STEPS ................................. 371
20.1 Conclusions...................................................................................................371
20.2 GST RESCUE Specifications Assessment .................................................372
20.3 Compliance Matrix ......................................................................................373
PART 4 - APPENDIX SECTION .................................................................. 407
APPENDIX A - TERMS AND ABBREVIATIONS ........................................ 408
APPENDIX B - REFERENCES.................................................................... 410
APPENDIX C - CODE SECTION ................................................................. 412
3/23/2006 12 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Table of Figures
Figure 1 - Sub-project Components.............................................................................22
Figure 2 - RESCUE concept overview ........................................................................28
Figure 3 – Collaborations of UC RSQ 001 – Triggers Automatic Call......................30
Figure 4 – Collaborations of UC RSQ 002 – PSAP1 .................................................31
Figure 5 – Collaborations of UC RSQ 003 – PSAP2 .................................................32
Figure 6 – Collaborations of UC RSQ 004 – Data to Vehicle....................................33
Figure 7 – Collaborations of UC RSQ 005 – Route Guidance...................................34
Figure 8 – Collaborations of UC RSQ 006 – Blue Wave...........................................35
Figure 9 – Collaborations of UC RSQ 007 – Virtual Cones.......................................36
Figure 10 – Collaborations of UC RSQ 008 – Value Added Data .............................37
Figure 11 - System Overview and Reference Points for the RSQ Sub-Project ...........38
Figure 12 - Collaborations for the RSQ Sub-Project ...................................................39
Figure 13 – GST and OSI Protocol Layers comparison ..............................................61
Figure 14 – Collaboration – PV - ECALL Activation (entities involved)...................84
Figure 15 - PV - ECALL Activation (Manual/Automatic)..........................................84
Figure 16 - Class Diagram for ECALL Activation (Manual/Automatic)....................85
Figure 17 - Sequence Diagram showing start of an ECALL Activation
(Manual/Automatic).............................................................................................86
Figure 18 - State Chart Diagram for ECALL Activation (Manual/Automatic)...........88
Figure 19 - Activity Diagram for ECALL Activation (Manual/Automatic) ...............88
Figure 20 – Collaboration PV ECALL Manual Cancelling.........................................89
Figure 21 - PV ECALL Manual Cancelling ................................................................90
Figure 22 - Class Diagram for PV ECALL Manual Cancelling..................................90
Figure 23 - Sequence Diagram showing PV ECALL Manual Cancelling ..................92
Figure 24 - State Chart Diagram showing PV ECALL Manual Cancelling................93
Figure 25 - Activity Diagram showing PV ECALL Manual Cancelling.....................94
Figure 26 – Collaboration PV - Emergency Data Handling .......................................95
Figure 27 - PV – Emergency Data Handling ...............................................................95
Figure 28 - Class Diagram for PV - Emergency Data Handling .................................96
Figure 29 - Sequence Diagram showing PV - Emergency Data Handling..................97
Figure 30 - State Chart Diagram for PV - Emergency Data Handling ........................98
Figure 31 - Activity Diagram for PV - Emergency Data Handling.............................99
Figure 32 – Collaboration PV - Emergency Data Message Sending........................100
Figure 33 – Use Case PV - Emergency Data Message Sending...............................100
Figure 34 - Class Diagram for PV - Emergency Data Message Sending .................101
Figure 35 – Protocol Stack - PV - Emergency Data Message Sending ....................102
Figure 36 – eCall transaction .....................................................................................106
Figure 37 - Sequence Diagram showing PV - Emergency Data Message Sending..117
Figure 38 - State Chart Diagram showing PV - Emergency Data Message Sending118
Figure 39 – Collaboration – PSAP Emergency Data Visualisation...........................119
Figure 40 – Use Case – PSAP Emergency Data Visualisation..................................120
Figure 41 - Class Diagram PSAP Emergency Data Visualisation.............................120
Figure 42 - Sequence Diagram showing PSAP Emergency Data Visualisation .......122
Figure 43 - Activity Diagram showing PSAP Emergency Data Visualisation..........123
Figure 44 – Collaboration – PSAP - Emergency Data Handling...............................124
3/23/2006 13 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 45 – Use Case – PSAP - Emergency Data Handling......................................124
Figure 46 - Class Diagram PSAP - Emergency Data Handling.................................125
Figure 47 - Sequence Diagram showing PSAP - Emergency Data Handling ...........126
Figure 48 - Activity Diagram showing PSAP - Emergency Data Handling..............128
Figure 49 – Collaboration – PSAP2 - Emergency Data Retrieving from PSAP1 .....129
Figure 50 – Use Case – PSAP2 - Emergency Data Retrieving from PSAP1 ............130
Figure 51 - Class Diagram PSAP2 - Emergency Data Retrieving from PSAP1 .......130
Figure 52 – Protocol Stack - PSAP2 - Emergency Data Retrieving from PSAP1 ....131
Figure 53 - Sequence Diagram showing PSAP2 - Emergency Data Retrieving from
PSAP1................................................................................................................135
Figure 54 - Activity Diagram showing PSAP2 - Emergency Data Retrieving from
PSAP1................................................................................................................136
Figure 55 – Collaboration – PSAP1 - EOS................................................................137
Figure 56 – Use Case – PSAP1 – EOS......................................................................137
Figure 57 - Class Diagram for PSAP1 – EOS ...........................................................138
Figure 58 – Protocol Stack – PSAP1 - EOS ..............................................................139
Figure 59 - Sequence Diagram showing PSAP1 – EOS............................................141
Figure 60 - State Chart Diagram showing PSAP1 – EOS .........................................142
Figure 61 –Transmission of Data (entities involved) ................................................143
Figure 62 - Transmission of Data ..............................................................................143
Figure 63 - Class Diagram for Transmission of Data................................................144
Figure 64 – Protocol Stack – Transmission of Data ..................................................145
Figure 65 - Sequence Diagram showing Transmission of Data ................................149
Figure 66 - State Chart Diagram showing Transmission of Data..............................150
Figure 67 – Collaboration – ESV - Emergency Handling Closure............................151
Figure 68 – Use Case – ESV - Emergency Handling Closure...................................151
Figure 69 - Class Diagram ESV - Emergency Handling Closure..............................152
Figure 70 – Protocol Stack - ESV - Emergency Handling Closure...........................153
Figure 71 – Message Structure ..................................................................................154
Figure 72 - Sequence Diagram showing ESV - Emergency Handling Closure ........156
Figure 73 - Activity Diagram showing ESV - Emergency Handling Closure...........158
Figure 74 – Collaboration – ESV – Emergency Data Receipt from PSAP2 .............159
Figure 75 – Use Case - ESV – Emergency Data Receipt from PSAP2.....................159
Figure 76 - Class Diagram for ESV – Emergency Data Receipt from PSAP2..........160
Figure 77 – Protocol Stack – ESV – Emergency Data Receipt from PSAP2............161
Figure 78 – Message Structure ..................................................................................162
Figure 79 - Sequence Diagram showing ESV – Emergency Data Receipt from PSAP2
............................................................................................................................167
Figure 80 - State Chart Diagram showing ESV – Emergency Data Receipt from
PSAP2................................................................................................................169
Figure 81 – Collaboration – ESV – Emergency Data Visualisation..........................170
Figure 82 – Use Case – ESV – Emergency Data Visualisation.................................170
Figure 83 - Class Diagram for ESV – Emergency Data Visualisation ......................171
Figure 84 - Sequence Diagram showing ESV – Emergency Data Visualisation ......173
Figure 85 - State Chart Diagram showing ESV – Emergency Data Visualisation....175
Figure 86 – Collaboration – ESV – Accept Deployment ..........................................176
Figure 87 - ESV – Accept Deployment .....................................................................176
Figure 88 - Class Diagram for ESV – Accept Deployment.......................................177
Figure 89 – Protocol Stack - ESV – Accept Deployment..........................................178
3/23/2006 14 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 90 - Sequence Diagram showing ESV – Accept Deployment .......................180
Figure 91 - State Chart Diagram showing ESV – Accept Deployment.....................182
Figure 92 – Collaboration ESV Calculate Route Options .........................................183
Figure 93 - ESV Calculate Route Options.................................................................183
Figure 94 - Class Diagram for ESV Calculate Route Options...................................184
Figure 95 – Protocol Stack – ESV – Calculate Route Options..................................185
Figure 96: Map and route visualisation sample .........................................................198
Figure 97 - Sequence Diagram showing ESV Calculate Route Options ...................201
Figure 98 - State Chart Diagram showing ESV Calculate Route Options ................203
Figure 99 – Collaboration Display Route Options ....................................................204
Figure 100 – ESV Display Route Options.................................................................204
Figure 101 - Class Diagram for ESV Display Route Options ...................................205
Figure 102 - Sequence Diagram showing ESV Display Route Options....................206
Figure 103 - State Chart Diagram showing ESV Display Route Options .................208
Figure 104 - Activity Diagram showing ESV Display Route Options......................209
Figure 105 – Collaboration Target Information Reception .......................................210
Figure 106 – ESV Target Information Reception......................................................210
Figure 107 - Class Diagram for ESV Target Information Reception ........................211
Figure 108 – Protocol Stack - ESV Target Information Reception ...........................213
Figure 109 - Sequence Diagram showing ESV Target Information Reception.........218
Figure 110 - State Chart Diagram showing ESV Target Information Reception ......220
Figure 111 – Collaboration - ESV Activate Warning Messages ...............................221
Figure 112 – Use Case - ESV Activate Warning Messages ......................................221
Figure 113 - Class Diagram for ESV Activate Warning Messages...........................222
Figure 114 - Sequence Diagram showing ESV Activate Warning Messages ...........223
Figure 115 - Activity Diagram showing ESV Activate Warning Messages .............224
Figure 116 – Collaboration - ESV Reset Transmission.............................................225
Figure 117 – Use Case – ESV Reset Transmission ...................................................225
Figure 118 - Class Diagram for ESV Reset Transmission ........................................226
Figure 119 - Sequence Diagram showing ESV Reset Transmission.........................228
Figure 120 - Activity Diagram showing ESV Reset Transmission ...........................229
Figure 121 – Collaboration - ESV Send Warning Message ......................................230
Figure 122 – Use Case – ESV Send Warning Message.............................................230
Figure 123 - Class Diagram for ESV Send Warning Message..................................231
Figure 124 – Protocol Stack - ESV Send Warning Message.....................................232
Figure 125 - Sequence Diagram showing ESV Send Warning Message ..................235
Figure 126 - Activity Diagram showing ESV Send Warning Message.....................237
Figure 127 – Collaboration – PV Interpret Warning Message ..................................238
Figure 128 – Use Case – PV Interpret Warning Message .........................................238
Figure 129 - Class Diagram for PV Interpret Warning Message...............................239
Figure 130 - Sequence Diagram showing PV Interpret Warning Message...............241
Figure 131 - Activity Diagram showing PV Interpret Warning Message .................243
Figure 132 – Collaboration - PV Receive Warning Message....................................244
Figure 133 – Use Case – PV Receive Warning Message ..........................................244
Figure 134 - Class Diagram for PV Receive Warning Message ...............................245
Figure 135 - Sequence Diagram showing PV Receive Warning Message................246
Figure 136 - Activity Diagram showing PV Receive Warning Message ..................247
Figure 137 – Collaboration – PV - Reset Warning Message.....................................248
Figure 138 – Use Case – PV - Reset Warning Message............................................248
3/23/2006 15 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 139 - Class Diagram for PV - Reset Warning Message .................................249
Figure 140 - Sequence Diagram showing PV - Reset Warning Message..................250
Figure 141 - State Chart Diagram showing PV - Reset Warning Message...............252
Figure 142 - Transmission of Data (entities involved) ..............................................253
Figure 143 - Transmission of Data ............................................................................253
Figure 144 - Class Diagram for Transmission of Data..............................................254
Figure 145 – Protocol Stack – Transmission of Data ................................................255
Figure 146 - Sequence Diagram showing Transmission of Data – PUSH Case .......261
Figure 147 – Sequence Diagram showing Transmission of Data – PUSH Case to
PSAP2................................................................................................................262
Figure 148 - Sequence Diagram showing Transmission of Data – PULL Case........262
Figure 149 - Sequence Diagram showing Transmission of Live VAD .....................265
Figure 150 - Activity Diagram showing Transmission of Data.................................267
Figure 151 – Processing of Data (entities involved)..................................................267
Figure 152 - Processing of Data.................................................................................268
Figure 153 - Class Diagram for Processing of Data ..................................................268
Figure 154 - Sequence Diagram showing Processing of Data...................................270
Figure 155 - State Chart Diagram showing Processing of Data ................................271
Figure 156 – Collation of Data (entities involved) ....................................................272
Figure 157 - Collation of Data...................................................................................272
Figure 158 - Class Diagram for Collation of Data.....................................................273
Figure 159 - Sequence Diagram showing Collation of Data .....................................275
Figure 160 - State Chart Diagram showing Collation of Data...................................276
Figure 161 – ESV – Receive Data (entities involved)...............................................277
Figure 162 - ESV – Receive Data..............................................................................277
Figure 163 - Class Diagram for ESV – Receive Data ...............................................278
Figure 164 – Protocol Stack – ESV – Receive Data..................................................279
Figure 165 - Sequence Diagram showing ESV – Receive Data – PUSH Case.........284
Figure 166 - Sequence Diagram showing ESV – Receive Data – PULL Case .........285
Figure 167 - State Chart Diagram showing ESV – Receive Data .............................287
Figure 168 – ESV – Data Transferred (entities involved) .........................................288
Figure 169 - ESV – Data Transferred ........................................................................288
Figure 170 - Class Diagram for ESV – Data Transferred..........................................289
Figure 171 - Sequence Diagram showing ESV – Data Transferred ..........................291
Figure 172 - State Chart Diagram showing ESV – Data Transferred........................292
Figure 173 – UC RSQ 001 – PV – Acknowledge of Data Sent (entities involved) ..295
Figure 174 - UC RSQ 001 – PV – Acknowledge of Data Sent .................................295
Figure 175 - Class Diagram for UC RSQ 001 – PV – Acknowledge of Data Sent...296
Figure 176 – Protocol Stack - PV – Acknowledge of Data Sent ...............................297
Figure 177 - Sequence Diagram showing UC RSQ 001 – PV – Acknowledge of Data
Sent ....................................................................................................................299
Figure 178 - State Chart Diagram showing UC RSQ 001 – PV – Acknowledge of
Data Sent............................................................................................................300
Figure 179 - Component Diagram for Vehicle ECALL work Item...........................305
Figure 180 - Deployment Diagram for Vehicle ECALL work item..........................307
Figure 181 - Component Diagram for PSAP ECALL work item..............................308
Figure 182 - Deployment Diagram for PSAP ECALL work item.............................310
Figure 183 - Component Diagram for PSAP Rescue Management work item .........311
Figure 184 - Deployment Diagram for PSAP Rescue Management work item........313
3/23/2006 16 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 185 - Component Diagram for PSAP to Vehicle Communication work item314
Figure 186 - Deployment Diagram for PSAP to Vehicle Communication work item
............................................................................................................................315
Figure 187 - Component Diagram for ESV Rescue Management work item ...........316
Figure 188 - Deployment Diagram for ESV Rescue Management work item..........317
Figure 189 - Component Diagram for ESV Driver Support work item ....................319
Figure 190 - Deployment Diagram for ESV Driver Support work item ...................322
Figure 191 - Component Diagram for Vehicle to Vehicle Communication work item
............................................................................................................................324
Figure 192 - Deployment Diagram for Vehicle to Vehicle Communication work item
............................................................................................................................326
Figure 193 - Component Diagram for Public Vehicle Driver Support work item ....328
Figure 194 - Deployment Diagram for Public Vehicle Driver Support work item ...329
Figure 195 - Component Diagram for Vehicle to Centre Communication work item
............................................................................................................................331
Figure 196 - Deployment Diagram for Vehicle to Centre Communication work item
............................................................................................................................332
Figure 197 - Representation of sequence events........................................................337
Figure 198 – eCall Service Messages ........................................................................338
Figure 199 – USSD service architecture (extract from CEPT ECC)........................340
Figure 200 – PSAP Operator Work Station...............................................................342
Figure 201 – Value Added Data Streaming - PUSH CASE ......................................347
Figure 202 – Value Added Data Streaming - PULL CASE ......................................348
Figure 203 – Value Added Data Streaming - PUSH CASE to PSAP2 .....................349
Figure 204 – ND-CS Protocol Stack [19]..................................................................349
Figure 205 – Video Streaming System ......................................................................352
Figure 206 – RTSP Operation....................................................................................355
Figure 207 – RTSP Protocol States ...........................................................................360
Figure 208 – Example of a test MSD message processing by PSAP1 IS..................362
Figure 209 – Time scheme of eCall process [9] ........................................................365
3/23/2006 17 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
PART 1 - INTRODUCTION AND
ENTERPRISE VIEW
3/23/2006 18 Version 2.0

Chapter 1 - INTRODUCTION
1.1 Intended Audience
DEL_RSQ_3_1 Architecture and Interface Specifications
This document is primarily written for the members of the SP. Some versions of the
document will be circulated to IPWP3MT, CT and CAG for IP-level co-ordination
purposes. The final version will be sent to GA.
1.2 Organisation
This document consists of the following sections:
• Introduction and Enterprise View
o Introduction – this chapter.
o Executive Summary – provides a high level overview of information
provided by this document. Read this chapter if you only need a basic
understanding of the architecture and design options documented by this
deliverable.
o Methodology for the Deliverable – in order to achieve an optimal result, the
definition of the GST RESCUE architecture is supported by a light but
efficient methodology. The information provided by this chapter will help
you in understanding the different steps taken whilst developing this
deliverable and rationale behind some of the document result.
o System Overview – this chapter connects the architecture and design
exercise accomplished by WP3 to the results promoted by the GST
RESCUE 2.1 deliverable [8].
• Logical View – the logical view contains the actual specification. This section is
mainly divided into different work items which link all the GST RESCUE
functionalities with specific technology domains.
o Vehicle ECALL – this section contains the GST RESCUE specific elements
related to the automatically or manually generated eCall by the vehicle.
o PSAP ECALL – this section deals with eCALL handling process at PSAP1.
o PSAP Rescue Management – this section contains specific elements related
to the incident assessment and to the support provided for decision to be
taken in order to organize the most appropriate rescue needed on site.
o PSAP to Vehicle Communication – this section contains specific elements
related to the emergency details transmission directly on-board of the
emergency service vehicle.
o ESV 1 Rescue Management – this section deals with the emergency data
handling at the ESV side.
o ESV Driver Support – this section contains specific elements related to the
optimised navigation system to guide the ESV to the incident point as fast
and safe as possible.
1 ESV stands for Emergency Service Vehicle
3/23/2006 19 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
o Vehicle to Vehicle Communication – this section contains the GST
RESCUE specification for the safety related inter-vehicular communication
needed for rescue deployment support.
o Public Vehicle Driver Support – this section is mainly related to the safety
related information to handled by the public vehicle client system when a
rescue management procedure is ongoing.
o Vehicle to Centre Communication – this section contains specific elements
for incident data enrichment directly on site by the emergency service
personnel.
o Security – this section deals with all the security issues (e.g. authentication
and user authorization) impacting on the GST RSQ system.
o System Management – this section deals with all the specific aspects related
to the GST RESCUE system management from a hardware and software
point of view (e.g. error detection, error reporting, remote upgrade). These
aspects represents also one of the main contribution which RESCUE
provides to the technology SPs.
• Implementation View and Conclusions – this chapter provides a link to the 3.2
deliverable, specifying the GST RESCUE reference implementation.
o Reference Implementation – provides the component and deployment
diagrams which define the reference implementation itself.
o Conclusions and Next Steps – read this chapter to understand some of the
open issues and topics, which will be researched by the different GST test
sites.
1.3 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL"
[20] in this document are to be interpreted as described in [RFC2119].
1.4 Typographic Conventions
The following typographic conventions are used in this document:
A word starting with a capital letter Indicates a specific term explained by the
appendix Terms and abbreviations
Code Examples Code examples are printed in a courier font
C:\Project\MyCode.c Filenames are represented in a courier italic font.
Locales Words that have a specific meaning are printed
in an italic bold font
[1] Numbers in-between square brackets are
references to publications mentioned in the
appendix References.
1.5 Objectives
The objectives of this document are:
3/23/2006 20 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• To document the RESCUE sub-project SP architecture and interface
specifications
• To establish a link to the IP-level system architecture.
3/23/2006 21 Version 2.0

Chapter 2 - EXECUTIVE SUMMARY
DEL_RSQ_3_1 Architecture and Interface Specifications
This document presents the interim results of Work Package 3 “Architecture and
Interface Specifications” for the RSQ sub-project.
Use cases &
system requirements
WP1
Architecture &
interface specifications
Project management
Dissemination and
exploitation
To and from all WPs
WP2 WP3 WP4 WP5 WP6
WP7
Prototype
development
To and from all WPs
Field trials
Figure 1 - Sub-project Components
Validation
WP Manager
WP Participants
After a short chapter on methodology, the real starting point for the deliverable is the
system overview for the sub-project. This system overview describes the key subsystems,
reference points and collaborations for the sub-project, and serves as an index
to the remaining chapters.
In these chapters, the functionality that the RSQ sub-project seeks to offer for each
collaboration is further developed, starting from a high-level (with the uses cases and
requirements that have emerged from WP2) that is gradually refined until the level of a
specification.
Note
The RSQ sub-project collaborates with 6 other sub-projects within GST, that represent different
competence domains and may develop specifications on which the RSQ sub-project relies. To understand
the overall system in which RSQ operates as well as possible links with other sub-projects, this document
must be read together with the current version of the IP-level architecture deliverable.
3/23/2006 22 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 3 - METHODOLOGY FOR THE DELIVERABLE
3.1 Introduction
The methodology for this deliverable is based on RM-ODP (viewpoint approach) [1] and
UML (UML diagrams) [2]. Some key elements of the methodology are described in this
chapter. More details of the methodology can be found in [3].
3.2 Architecture Documents
The overall objectives of WP3 are allocated to WP3 deliverables as follows:
Deliverable Code Deliverable Title Deliverable Objectives
DEL_GST_3_1 [3] GST High-level Architecture To develop a common highlevel
architecture for the IP as a
starting point for WP3.
To develop an appropriate
methodology for the
architecture and specifications
development.
DEL_RSQ_3_1
(this document)
RSQ Architecture and interface
specifications
DEL_GST_3_2 [4] GST Framework Architecture
and interface specifications
DEL_RSQ_3_2 RSQ Reference
Implementations
Table 1 - WP3 Documents in GST
To develop the architecture for
the sub-project.
To develop the specifications
for interfaces prioritised and
agreed at IP level.
To consolidate the results of
the sub-projects into an overall
architecture and specifications
document.
Note that this deliverable further
develops DEL_GST_3_1. The
documents have been split merely for
practical and contractual reasons.
To develop a reference
implementation for common
use at the test sites.
Note that this deliverable further
develops DEL_RSQ_3_1 (and in
particular the code section in
Appendix C) by bundling the source
codes in the appropriate formats.
3/23/2006 23 Version 2.0

3.2.1 Content of the IP-level Deliverables
These documents contain:
• Architectural methodology
• GST-wide architectural decisions
DEL_RSQ_3_1 Architecture and Interface Specifications
• Tables cross-connecting the IP-level and SP-level documents.
The IP-level documents essentially serve as an overview of the architectural elements of
GST as well as an index indicating in which sub-project deliverables the architectural
element is fully described.
The architectural elements presented in the IP-level deliverables are so-called invariants
meaning that across the project all SPs will carry out the architectural element in the
same way.
3.2.2 Content of the SP-level Deliverables
These documents contain:
• Sub-project architecture (architectural elements)
• Detailed specifications for interfaces and modules (technical specifications)
• Tables cross-connecting the IP-level and SP-level documents.
3.3 The Viewpoint Approach of RM-ODP [1]
Rather than attempting to deal with the full complexity of distributed systems, the RM-
ODP considers the system from different viewpoints or projections, each of which is
chosen to reflect one set of design concerns. Each viewpoint represents a different
abstraction of the original distributed system, without the need to create one large model
describing it.
GST has selected the following viewpoints:
Viewpoint Meaning
Enterprise Functional description of the systems
Logical Informational and computational model, blocks of
functionality and the relation between those blocks
Implementation Actual technical implementation of the system
Table 2 - GST Viewpoints
3.4 The Unified Modelling Language (UML) [2]
The GST project elaborates these viewpoints by means of different Unified Modelling
Language (UML) diagrams. The UML provides a suitable communication language to
explain the GST architecture concepts to the final implementers of the reference
implementation and (a little bit further down the line) to the prototype implementers.
3/23/2006 24 Version 2.0

GST has selected the following UML diagrams:
DEL_RSQ_3_1 Architecture and Interface Specifications
Viewpoint UML Diagrams
Enterprise Use Case diagrams + collaborations
Logical Class diagrams (documenting structural aspects)
Sequence diagrams (documenting behavioural aspects)
State-chart diagrams (documenting behavioural aspects)
Implementation Component diagrams
Deployment diagrams
Table 3 - Principal UML Diagrams used in GST
Note that the architectural artefacts are also described in textual format, supplementing
the summary information presented in the UML diagrams either in the form of
background information or in the form of a technical specification (describing how the
GST system should work in terms of the MAYs, SHOULDs and MUSTs).
3.5 Structure of this Document
The next chapter provides a system overview for the sub-project, essentially describing
the main sub-systems, reference points (candidate interfaces) and collaborations for the
sub-project.
The remainder of the document is then organised as follows:
(for each) Interfaces Class Diagram
Collaboration
Reference
Implementation
Protocol Stack and
Specifications
Message Structure
Interface Descriptions
Key Interactions Sequence Diagram
Key Lifecycles State Charts
Interaction Descriptions
Lifecycle Descriptions
Components Component Diagram
Component Descriptions
Nodes Deployment Diagram
Node Descriptions
Table 4 - Structure of this Document
3/23/2006 25 Version 2.0

3.6 Consistency with IP-level Deliverables
DEL_RSQ_3_1 Architecture and Interface Specifications
Any information that refers to an IP-level deliverable but that is not yet incorporated by
this IP-level deliverable is indicated in “Track Changes/Highlight Changes” format. In
the absence of this format, this SP-level deliverable can be assumed to be fully consistent
with the IP-level deliverable to which it refers.
This is the version of the IP-level deliverable that this deliverable refers to:
• DEL_GST_3_1_v4.2.doc.
or (at a later stage)
• DEL_GST_3_2_v1.2.doc.
All the diagrams included within this deliverable refers to:
• MOD_GST_RSQ_v2.0.EAP
3/23/2006 26 Version 2.0

Chapter 4 - SYSTEM OVERVIEW
4.1 Introduction
The RESCUE project goals [8] are listed below;
DEL_RSQ_3_1 Architecture and Interface Specifications
° identify requirements of users, manufacturers, operators and emergency services for
RESCUE application, information exchanges and services;
° achieve a Europe-wide consensus on a single harmonised RESCUE system based on
adaptation of existing and new technology and systems;
° define operational procedures and arrangements for all stages of the RESCUE
functionalities;
° develop prototypes at the UK stakeholders and closely follow the developments in
the GST Open Systems and GST test sites relevant for RESCUE;
° trial the system in a dedicated UK RESCUE test site and in addition trial the system
in different scenarios at currently two GST test sites in Europe (Italy and Germany);
° validate the system via simulated tests and real life testing in the UK site and gather
information from the GST test sites relevant to RESCUE;
° work towards ensuring the take-up of the RESCUE solution in non-participating
countries via a project Forum. It is the visionary goal of the consortia that all public
and commercial organisations providing RESCUE services adapt to the RESCUE
related specifications.
GST allows the construction of the totally integrated incident response chain, which will
ensures the fastest and most effective response to a incident – including availability of
incident data at all levels in the emergency chain, ensuring a fast and safe route to the
incident and ensuring the interaction between emergency vehicles and other road users
and the exchange of information between rescue units and control rooms for e.g. medical
intervention.
3/23/2006 27 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 2 - RESCUE concept overview
The figure above shows the total emergency call and response chain, which will be
included in RESCUE and the GST test sites with RESCUE functionalities. Focus will be
on the in-vehicle originated emergency calls where this subproject will ensure that the invehicle
data transmitted to the different levels of Public Service Access Points reach the
rescue vehicles in order to provide a faster and more effective emergency response. The
in-vehicle data will be defined taking into account contributions from the eSafety
working group on e-call, E-MERGE and AIDER projects. The transfer of data will be
initiated by the embedded expert system. The sub-project will study the ad equation of
the ECALL structure to support an Emergency situation occurring in an automotive
context and will propose necessary adaptations [8].
Another equally important focus of the RESCUE sub-project concentrates on the
efficiency of the rescue operations where the sub-project will aim to optimise the security
and speed for the emergency vehicles to reach the scene of the incident this includes a
hybrid navigation solution, vehicle to vehicle and vehicle to control centre
communications. Furthermore, it will aim at improving the management and the data
exchange among control units and rescue units and between rescue units and care taking
facilities e.g. hospitals.
Starting from the results carried out by the WP2, in the following, this system overview is
given in detail, defining the main architecture elements for GST RESCUE SP in terms of
entities, reference points and collaborations.
3/23/2006 28 Version 2.0

4.2 PSAP1, PSAP2 and Telco Roles
DEL_RSQ_3_1 Architecture and Interface Specifications
For a better comprehension of the RESCUE concept, it is important to clarify the role
that each entity involved in the Emergency Call Management complete chain could
cover. In order to do that and to avoid any possible misunderstanding it is important to
underline the level of abstraction used for the RESCUE Architecture definition which
should not be mixed with the real world.
Following this purpose it is important to give a definition of PSAP1, PSAP2 and
Telecom Operator in the Emergency Call Management complete chain.
• PSAP1: A Public Safety Answering Point 1 st Level is a physical location where
emergency calls are received. This may be a public authority, or a
telecommunications operator, responsible also for ordinary voice calls landline
and mobile.
• PSAP2: A Public Safety Answering Point 2 nd Level is the agency responsible for
dealing with the call and managing the most appropriate response (e.g.
dispatching vehicles, providing rescue service, …).
• Telco: A Telecom Operator is the responsible for handling the eCalls and for
their delivery to the most appropriate PSAP1.
Considering these entities as an aggregate of functionalities it is possible to allocate
functions, roles and responsibilities to several different agencies, or centres or actors and
it is possible to assume that many different system configurations could be designed.
Currently the eCall Management Chain through the European country could assume
many different possible configurations depending by national laws and regulation. In the
following table some example are given illustrating the different possible configurations:
Telco
PSAP1
PSAP2
X X X
Configuration
Telco +
PSAP1
X X
PSAP1 +
PSAP2
X X
Telco +
PSAP1 +
PSAP2
Example
UK, where BT is actually working as
Telco and PSAP1 as well.
Sweden, where a national service provider
(SOS Alarm) is in charge to handle 112
call by law.
Italy, where, due to the fact that E-112
and PSAP role are not defined yet, an
Emergency Authority (Carabinieri) is
handling 112.
Table 5 – Telco, PSAP1 and PSAP2 configuration
Concluding, it is possible to assume that the eCall Management physical scenarios related
to the system architecture are country specific, therefore it is important to abstract roles
and functionalities in order to consolidate the GST approach.
3/23/2006 29 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
4.3 Use Cases and Collaborations for RESCUE
The next figures show an overview of the key collaborations identified as WP2 results for
the RSQ sub-project. The illustrated collaborations have been mapped on each use cases
dealt and described by WP2 deliverable [8].
The meaning of each illustrated collaboration is described in the Table 8.
Figure 3 – Collaborations of UC RSQ 001 – Triggers Automatic Call
3/23/2006 30 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 4 – Collaborations of UC RSQ 002 – PSAP1
3/23/2006 31 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 5 – Collaborations of UC RSQ 003 – PSAP2
3/23/2006 32 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 6 – Collaborations of UC RSQ 004 – Data to Vehicle
3/23/2006 33 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 7 – Collaborations of UC RSQ 005 – Route Guidance
3/23/2006 34 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 8 – Collaborations of UC RSQ 006 – Blue Wave
3/23/2006 35 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 9 – Collaborations of UC RSQ 007 – Virtual Cones
3/23/2006 36 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 10 – Collaborations of UC RSQ 008 – Value Added Data
4.4 Architecture Elements
Figure 11 and 12 show an overview of the system indicating the reference points and –
for each reference point – the key collaborations for the RSQ sub-project.
Key collaborations have been mapped on a generalised illustration which show the main
entities involved considering the role covered (e.g. public vehicle, emergency vehicle, …).
3/23/2006 37 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 11 - System Overview and Reference Points for the RSQ Sub-Project
3/23/2006 38 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 12 - Collaborations for the RSQ Sub-Project
4.5 Short Description per Element
An explanation of the columns of the tables used in this chapter is given in Table 6.
Title Explanation
Entity Name Each entity must be given a short name written in a short
manner so that the meaning is clear (as in Error! Reference
3/23/2006 39 Version 2.0

source not found.)
DEL_RSQ_3_1 Architecture and Interface Specifications
Entity Description This provides more information for a better understanding of
the entity.
Decomposition of? If the entity is a decomposition of another entity, this field
provides the Entity Name of the parent entity (otherwise it is
empty).
IP-level? This field is crossed (X) if the item corresponds to the item
defined as “invariant” (common for all sub-projects) at IPlevel
(in [3]or - for later versions - [4]).
Additional explanation may be added when required.
Reference Point Name Indicates the entities defining the reference point (e.g. “client
system - control centre”).
Reference Point SP
Contribution
This indicates to what extent the SP will need to develop the
required functionality - if existing standards or specifications
can be used they will be mentioned by name and the remaining
development effort will be described.
Reference Point This can either be:
Criticality
• Must
• Should
• May
Collaboration Name Each collaboration must be given a short name written in a
short manner so that the meaning is clear.
Collaboration
Description
This provides more information for a better understanding of
the collaboration.
Table 6 - Definition of Terms Used when Presenting the System Overview
3/23/2006 40 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Entity Name Decomposition of? Entity Description IP-level?
Authentication &
Authorisation (AA)
Public Vehicle Client
System (CS-PV)
Emergency Vehicle
Client System (CS-
ESV)
Control Centre (CC) It is responsible for authentication and authorisation; it contains a DB
with user credentials for authentication
The Public Vehicle Client System is the physical device running one or
more Service Platforms for executing applications. Public Vehicle
Client System includes Public Vehicle GST RSQ Telematic Control
Units, Service Platforms, Service Application and I/O Devices.
The Public Vehicle Client System is able to provide the basic public
functionalities related to emergencies such as ECALL generation, Blue
Wave and Virtual Cones Messages reception.
The Emergency Vehicle Client System is the physical device running
one or more Service Platforms for executing specific applications
related to rescue operations. Emergency Vehicle Client System includes
Emergency Vehicle GST RSQ Telematic Control Units, Service
Platforms, Service Application and I/O Devices.
The Emergency Vehicle Client System is able to provide functionalities
related to rescue services deployment such as Blue Wave and Virtual
Cones Messages Transmission, Route Guidance, Data Exchange with
Emergency Centres. Basic functionalities described for CS-PV are
already available.
Control Centre (CC) A Control Centre manages multiple Client Systems and End-Users. It is
responsible for registration of Client Systems, authentication, service
provisioning, subscription and the subsequent download of service
applications, service updates, remote administration and all other
3/23/2006 41 Version 2.0
X
Authentication &
Authorisation (AA)
X
Client System (CS)
X
Client System (CS)
X
Control Centre
(CC)

DEL_RSQ_3_1 Architecture and Interface Specifications
needed management procedures on a Client System
I/O Device (IOD) Client System (CS) An I/O Device is the physical input/output device that is part of the
GST environment inside of the vehicle.
Telematic Control
Unit (TCU)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 2 (PSAP2)
Client System (CS) The Telematic Control Unit hosts one or more Service Platforms. It
can be equipped with very specialized hardware suited for a specific
application domain.
The Public Service Access Point 1 is the back-end infrastructure that a
Service Provider constructs, deploys, and operates additionally to the
Service Application.
PSAP1 is the Service Centre responsible for ECALLs handling and the
most appropriate rescue identification.
Due to the different network architectures acted by the telecom
operators overall in Europe the role of PSAP1 could be taken by the
Telco itself (e.g. BT in UK), or by a Service Centre (e.g. SOS Alarm in
Sweden).
The Public Service Access Point 2 is the back-end infrastructure that a
Service Provider constructs, deploys, and operates additionally to the
Service Application.
PSAP2 is responsible of Emergency Vehicles and Rescue Management
for the whole emergency handling life cycle.
Due to the fact that the PSAP2 is a Rescue Management Centre which
have Control on a specific fleet of rescue vehicles (e.g. ambulances, or
fire brigades), the PSAP2 is an aggregation of both Service and Control
Centre capabilities.
3/23/2006 42 Version 2.0
X
I/O Device (IOD)
X
Telematic Control
Unit (TCU)
X
Service Centre (SC)
X
Service Centre (SC)
Control Centre
(CC)
Third Party (3rdP) Third Party is the back-end infrastructure that a Service Provider X

Emergency Service
Vehicle (ESV)
DEL_RSQ_3_1 Architecture and Interface Specifications
constructs, deploys, and operates additionally to the Service
Application.
3rdP Entity identifies each Service (and Control) Centre which have the
capability of value added data exchange with the other entities involved
in the Emergency Management and Rescue Operations (e.g. hospitals).
3rdP is an aggregation of both Service and Control Centre capabilities.
An Emergency Service Vehicle is a vehicle in charge to carry Rescue
team up to the accident point. In the context of GST the ESV contains
the appropriate vehicle sensors and the Vehicle Client System and is
able to communicate with the external world.
Public Vehicle (PV) A Public Vehicle is a means of carrying or transporting actors which
require rescue support (e.g. driver or passengers or both of them which
have been involved in an accident). In the context of GST the PV
contains the appropriate vehicle sensors and the Vehicle Client System
and is able to communicate with the external world.
OEM Device Vehicle (Vehicle) Refer to ESV and PV Entities.
Sensors Vehicle (Vehicle) Refer to ESV and PV Entities.
Vehicle Location
Device
Communication
Device
Vehicle (Vehicle) Refer to ESV and PV Entities.
Vehicle (Vehicle) Refer to ESV and PV Entities.
Mobile Device A mobile device is a means of a data and information collector. It is an
external device (e.g. PDA, Mobile Data Terminal) which allows to the
Emergency Service Personnel to collect incident information even if
they are not on the vehicle, but directly on site.
Table 7 - Entities for the RSQ Sub-Project
3/23/2006 43 Version 2.0
Service Centre (SC)
Control Centre
(CC)
(External entity)
Vehicle (Vehicle)
(External entity)
Vehicle (Vehicle)
(External entity)

Reference Point
Name
RP-RSQ-001
I/O Device
Interface (IOD-I)
DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Reference Point SP Contribution Reference Point
Criticality
• PV – ECALL Activation
• PV – ECALL Manual Cancelling
• PV – Emergency Data Handling
• ESV – Emergency Data Receipt
from PSAP2
• ESV – Accept Deployment
• ESV – Emergency Handling
Closure
• ESV – Incident Data Update
• ESV – Advise at Arrival Scene
• ESV – Reset Transmission
• ESV – Send Warning Message
• PV – Interpret Warning Message
• PV – Reset Warning Message
• Collation of Data
• Display Destination Options
• ESV – Data Interpreted
• Processing of Data
• ESV – Check Security
Authorisation
• PV – Acknowledge of Data Sent
• PV – Report Receiving Device
Fault
• ESV – Advice Device Status
• The TCU receives input data coming
from the input devices (e.g. buttons,
touch screen) and can output data to
the output devices (e.g. screen or
sound system). The TCU can also
read data (e.g. car velocity, position)
from the vehicle sensors.
• The I/O Device interacts with the
Telematics Control Unit present on
both Public and Emergency Service
Vehicles for data exchange from the
on board data collectors devices and
the TCU for data processing.
• More specifically this link is also
needed to enable the on board
functionality related to route guidance
up to the incident scene available on
the Emergency Service Vehicle.
3/23/2006 44 Version 2.0
IP-level?
MUST X

Reference Point
Name
RP-RSQ-002
Vehicle Interface
(V-I)
DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Reference Point SP Contribution Reference Point
Criticality
• ESV – Report Device Fault
• ESV – Disable Device
• PV – Emergency Data Handling
• PV – ECALL Activation
• ESV – Get Emergency Data
• The Client System has to identify the
vehicle in which it is installed to
provide this information to the CC and
to determine the vehicle profile. The
Client System also interacts with the
vehicle, reads information from the
vehicle sensors etc. The existing
standard interfaces to these vehicle
systems have to be investigated and a
suitable standard may be fixed as a
part of the GST standard.
• The Client System interacts with the
vehicle, reads information from the
vehicle sensors, vehicle location
device etc. However, it should not be
expected that the Client System will
have a permanent one-to-one
connection to the sensors of the
Vehicle - if the Client System is
portable this is not the case.
• The existing standard interfaces to
these vehicle systems have to be
investigated and a suitable standard
may be fixed as a part of the GST
standard.
3/23/2006 45 Version 2.0
IP-level?
MUST X

Reference Point
Name
RP-RSQ-003
Vehicle-to-
Vehicle Interface
(VV-I)
RP-RSQ-004
IODEnd-
User
DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Reference Point SP Contribution Reference Point
Criticality
• ESV – Send Warning Message
• PV – Receive Warning Message
• PV – ECALL Manual Cancelling
• PSAP1 - EOS
• ESV – Emergency Data Receipt
from PSAP2
• ESV – Emergency Data
Visualisation
• ESV – Display Route Options
• ESV – Accept Route Option
• ESV – Advise at Arrival Scene
• ESV – Activate Warning Message
Option
• ESV – Activate Warning
Messages
• ESV – Reset Transmission
• Two Vehicles can communicate with
each other to exchange traffic, safety
and other kind of information, using a
bearer-independent protocol.
• This link is needed for enabling Data
Message Exchange between
Emergency Vehicle and Public
Vehicle
• This link is necessary for Blue Wave
and Virtual Cones use cases.
• The communication between vehicles
is covered by PREVENT project
• The Emergency Vehicle Person
interacts with the Client System.
• Although it is not the intention of the
GST project to define the HMI used in
this interaction, certain restrictions and
requirements have to be defined and
required from the manufacturers of
GST-compliant automotive systems.
• On the other hand for RSQ project
HMI specifications consists of a
fundamental issue to be considered.
3/23/2006 46 Version 2.0
IP-level?
MUST X
MUST X

Reference Point
Name
RP-RSQ-005
Service
Authorisation
Interface (SA-I)
DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Reference Point SP Contribution Reference Point
Criticality
• ESV – Customise Screen Options
• PV – Interpret Warning Message
• PV – Present Language
Independent Message
• PV – Present Thank You
• PV – Repeat with Increasing
Notification
• PV – Reset Warning Message
• PV – Acknowledge of Data Sent
• ESV – Advise Device Status
• ESV – Disable Device
• ESV – Check Security
Authorisation
• The Service Centre needs to
authenticate the End-User in order to
use the Single Sign-On (SSO).
• This link is needed since PSAP2 must
to authenticate and to authorise
Emergency Service Vehicles which
needs to access to Remote Route
Calculation Function for Route
Guidance Use Case.
• Moreover Third Parties needs to
authenticate and to authorise the
Emergency Vehicle from which some
kind of request is incoming such as the
number of available beds.
3/23/2006 47 Version 2.0
IP-level?
SHOULD X
RP-RSQ-006 • ESV – Check Security • The Client System communicates over SHOULD X

Reference Point
Name
User
Authorisation
Interface (UA-I)
DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Reference Point SP Contribution Reference Point
Criticality
Authorisation a secure protocol to the Authentication
& Authorization System in the
Backend in order to authenticate itself
and the End-User using it. The chosen
standard has to allow: offline logging
in the Client System if there is no
connection to the CC; forwarding of
the authentication information to other
entities (e.g. Service Centres) in order
to have Single Sign-On.
• The Client System on Emergency
Vehicle needs to authenticate and to
authorise the Emergency Vehicle
Personnel for Emergency
functionalities access and activation
(e.g. Blue Wave, Virtual Cones, Route
Guidance)
Table 8 - Reference Points for the RSQ Sub-Project
Collaboration Name Collaboration Description SP Use Case IP-level?
PV - ECALL Activation
(Manual/Automatic)
PV - ECALL Manual
Cancelling
It provides the capability to generate an emergency call by
pushing a SOS button (manual activation) or automatically by
sensors data triggering.
It provides the capability of manually cancelling an emergency
call in order to minimise false calls.
3/23/2006 48 Version 2.0
° UC RSQ 001
° UC RSQ 001
IP-level?

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
PV - Emergency Data
Handling
PV - Emergency Data
Message Sending
PV - Voice Link
Establishment
PSAP1 - Incoming ECALL
Handling
PSAP - Emergency Data
Handling
It provides the capability to retrieve all data needed to be sent
to the PSAP1 and to prepare the data message in the
appropriate format. Data (the E-MERGE Minimum Set of
Data at least.) to be sent must be formatted in the GST-E-
MERGE protocol.
It provides the capability to transmit the MSD message to the
PSAP1.
This collaboration could be extended by:
° PV - Additional Data Sending to SP, providing the capability
to transmit when required and possible a Full Set of Data
Message to a SP which the driver is a subscriber of.
° PV - Acknowledge of Data Sent, providing the capability to
acknowledge the driver of a member of a vehicle that
Emergency Data Message has been sent.
It provides the capability to connect via a voice link the PSAP1
operator which has received Emergency Data Message, with
the vehicle involved in the incident.
It provides the capability to detect and alert the operator of an
incoming ECALL and to establish automatically the voice link
with the vehicle.
It provides the capability to handle and to interpret the
received Emergency Data Message in a workable format for
the PSAP Operator.
This collaboration could be extended by:
3/23/2006 49 Version 2.0
° UC RSQ 001
° UC RSQ 001
° UC RSQ 001
° UC RSQ 002
° UC RSQ 002
° UC RSQ 003

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
PSAP - Emergency Data
Visualisation
PSAP 1 - PSAP 2
Identification
PSAP 1 - Route the Voice
Call to PSAP2
PSAP 1 - Emergency Data
Available for PSAP2
° PSAP1 - Additional Data Retrieving from SP, following E-
MERGE specifications the Emergency Data Message
received at PSAP 1 contains the information related to the
possible subscription status of the vehicle owner. In this
case the PSAP 1 system is able to retrieve additional
information from the Service Provider via a XML/SOAP
request to the Service Provider Server.
On the basis on CGALIES recommendations and E-MERGE
specifications received data are visualised at the PSAP
Operator workstation showing the vehicle location on a map
support.
On the basis of the information available it provides the
capability to identify the most appropriate rescue needed and
the PSAP 2 available in the incident area in order to organise
the rescue and to route the ECALL to the correct rescue
centre/s.
It provides the capability to route the ECALL to the
appropriate PSAP 2, by establishing a Conference Call between
the entities involved in the process. The same collaboration
allows, when the PSAP1 operator recognise by the incoming
Emergency Data that the driver is coming from a foreign
country, he needs language assistance and that he is a Service
Provider subscriber, to establish a Conference Call with the SP
as well, for language assistance services.
Emergency Data are made available for the PSAP 2 which
request for these information. It provides the capability to
update the PSAP DB making data available via a XML/SOAP
3/23/2006 50 Version 2.0
° UC RSQ 002
° UC RSQ 003
° UC RSQ 002
° UC RSQ 002
° UC RSQ 002

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
request made to the PSAP Server.
PSAP 1 - EOS When PSAP1 operator close the voice communication link
with the PV driver, the PSAP1 system, automatically send an
EOS (End Of Service) message to the public vehicle.
At the same time, when the PV Client System receives that
kind of Message the communication link with the PSAP1 is
closed and message is displayed for the driver.
PSAP 2 - Emergency Data
Retrieving from PSAP 1
PSAP 2 – Locate, Assess
and Identify the incident
PSAP 2 - Rescue Resources
Assignment
When PSAP2 operator receives the routed voice call from
PSAP1 operator, he receives also the instruction to retrieve the
Emergency Data made available from the PSAP1.
This collaboration provides the capability to retrieve
emergency data from the PSAP 1 via a XML/SOAP request to
the Server, using the same data exchange protocol defined by
E-MERGE specifications and described for PSAP1 - Additional
Data Retrieving from SP collaboration.
It provides the capability to locate, assess and identify the
incident.
It provides the capability to identify available rescue resources
and to assign them to a particular rescue.
Transmission of Data Provide the capability to transmit emergency data on board to
the emergency vehicles in order to provide as much
information is possible to the Emergency Service Personnel.
ESV – Emergency Handling
Closure
It provides the capability to “close” a rescue handling by
storing all the information available, also coming directly from
the incident point and releasing rescue resources.
3/23/2006 51 Version 2.0
° UC RSQ 002
° UC RSQ 003
° UC RSQ 003
° UC RSQ 003
° UC RSQ 003
° UC RSQ 003
° UC RSQ 004

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
ESV – Emergency Data
Receipt from PSAP 2
ESV – Acknowledge
Receipt of Data
ESV – Emergency Data
Visualisation
This collaboration includes:
° Rescue Resources Released, which consists of the capability to
identify new free resources and to make them available for
other rescue services.
It provides the capability to detect and alert the Emergency
Service Personnel of an incoming Data Message from the
PSAP 2 and to establish automatically the voice link with the
vehicle.
It also provides the capability to handle and to interpret the
received Emergency Data Message.
It provides the capability to acknowledge the PSAP 2 that Data
Message has been received and processed.
It provides the capability to display on board the emergency
data related to the incident, also in terms of location and type,
and to the rescue needed.
ESV – Accept Deployment It provides the capability to the Emergency Service Personnel
to accept the rescue service to be provided on site.
ESV – Incident Data
Update
EV – Target Information
Reception
It provides the capability to the Emergency Service Personnel
to update incident information with data collected at the
incident point in order to make them available lately for the
PSAP 2.
It provides the capability to receive and interpret location
information related to the incident point and to start route
guidance system processing.
3/23/2006 52 Version 2.0
° UC RSQ 004
° UC RSQ 004
° UC RSQ 004
° UC RSQ 004
° UC RSQ 004
° UC RSQ 005

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
ESV – Accept Route
Option
ESV – Recalculate Route
Options
This collaboration is partially included in EV – Emergency Data
Receipt from PSAP 2.
It provides the capability for the Emergency Service Personnel
to access, to set parameters and to calculate route to reach the
incident point.
This collaborations includes:
° ESV - Check Security Authorisation, to ensure the access to
the route guidance functionalities only to authorised
personnel. This collaboration will be dealt within GST SEC
SP.
° ESV - Display Route Options, to allow the choice of route
parameters and settings via the device HMI.
° ESV - Get latest environmental info, to get informations related
to traffic, works on progress, … to be considered during
the route calculations.
° ESV - Calculate Route Option, to calculate the best trip to be
covered to reach the incident point as faster as possible.
It provides the capability to recalculate the planned trip and
suggest a better route updated with new environmental info.
This collaborations includes:
° Advise driver if better alternative route, to advise the driver about
the availability of a new best route.
° Update Trip Progress.
3/23/2006 53 Version 2.0
° UC RSQ 005
° UC RSQ 005

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
ESV – Advise at arrival
scene
It provides the capability to alert the driver of the Emergency
Service Vehicle when it is getting close to the incident site.
ESV – Remote upgrade It provides the capability to update the Service Application
(SApp) running on the Client System (CS) installed on an
Emergency Service Vehicle via a remote connection with the
Control Centre (CC).
This collaboration will be dealt within GST OS SP.
PV – Remote upgrade It provides the capability to update the Service Application
(SApp) running on the Client System (CS) installed on an
Public Vehicle via a remote connection with the Control
Centre (CC).
This collaboration will be dealt within GST OS SP.
ESV – Disable Device It provides the capability to disable the Client System
functionalities.
This collaboration will be dealt within GST OS SP.
ESV – Reset Navigation
System
ESV – Customise
Presentation Options
It provides the capability to reset the Navigation System
functionalities.
This collaboration will be dealt within GST OS SP.
It provides the capability to show on a Client System HMI the
possibilities of Visualisation Customisation.
3/23/2006 54 Version 2.0
° UC RSQ 005
° UC RSQ 005
° UC RSQ 006
° UC RSQ 007
° UC RSQ 008
° UC RSQ 006
° UC RSQ 007
° UC RSQ 005
° UC RSQ 006
° UC RSQ 007
° UC RSQ 008
° UC RSQ 005
° UC RSQ 005
° UC RSQ 006

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
ESV – Advice Device Status It provides the capability to alert the members of a vehicle
about the status of the Client System installed on an
Emergency Service Vehicle.
This collaboration will be dealt within GST OS SP.
ESV – Report Device Fault It provides the capability to log detected faults to make these
information available for any further analysis on an Emergency
Service Vehicle.
This collaboration will be dealt within GST OS SP.
PV – Advice Device Status It provides the capability to alert the members of a vehicle
about the status of the Client System installed on an Public
Vehicle.
This collaboration will be dealt within GST OS SP.
PV – Report Device Fault It provides the capability to log detected faults to make these
information available for any further analysis on an Public
Vehicle.
This collaboration will be dealt within GST OS SP.
ESV – Reset Transmission It provides the capability to reset warning messages
transmission (e.g. Blue Wave, Virtual Cones).
3/23/2006 55 Version 2.0
° UC RSQ 007
° UC RSQ 005
° UC RSQ 006
° UC RSQ 007
° UC RSQ 008
° UC RSQ 005
° UC RSQ 006
° UC RSQ 007
° UC RSQ 008
° UC RSQ 006
° UC RSQ 007
° UC RSQ 006
° UC RSQ 007
° UC RSQ 006
° UC RSQ 007
ESV – Activate Warning It provides the capability to activate a warning message ° UC RSQ 006

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
Messages broadcast transmission.
This collaborations includes:
ESV – Send Warning
Message
PV – Receive Warning
Message
° ESV - Check Security Authorisation, to ensure the access to
the route guidance functionalities only to authorised
personnel. This collaboration will be dealt within GST SEC
SP.
° ESV - Activate Warning Message Options, to allow the choice
of warning message to be transmitted via the device HMI.
It provides the capability to prepare data message using the
selected transmission protocol and it gives the possibility to
“enlarge” the set of information to be sent out, including:
° ESV - Get Emergency Data.
This collaboration related to V2V communication will be dealt
within PREVENT Project.
This collaboration could be extended by selecting the
destination of the message options:
° ESV - Send to TCCs.
° ESV - Send to EFCD. This collaboration will be dealt
within GST EFCD SP.
It provides the capability to receive, to handle and to interpret
a warning message coming from an Emergency Service
Vehicle.
This collaboration includes:
3/23/2006 56 Version 2.0
° UC RSQ 007
° UC RSQ 006
° UC RSQ 007
° UC RSQ 006
° UC RSQ 007

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
PV – Reset Warning
Message
V – External Device
Support
° PV - Interpret Warning Message, to show on a readable format
the warning and to make the meaning of message
comprehensible to the members of the vehicle.
° PV - Present Language Independent Message. This last
collaboration could be also extended by PV - Repeat message
with increasing notification.
It provides the capability to reset warning notifications on
board.
This collaborations includes:
° PV - Present Thank You, to acknowledge the driver for the
co-operation.
It provides the capability to link the Client System with other
devices (e.g. PDA, Mobile Data Terminal) and to transfer
information to be stored previously on board and to be lately
sent to the Control Centre.
This collaboration will be dealt within GST OS SP.
Transmission of Data It provides the capability to transmit information or to send a
request from the Client System to a Control Centre.
This collaboration includes:
° Collation of Data.
° Processing of Data.
° Display Destination options.
3/23/2006 57 Version 2.0
° UC RSQ 006
° UC RSQ 007
° UC RSQ 008
° UC RSQ 008

DEL_RSQ_3_1 Architecture and Interface Specifications
Collaboration Name Collaboration Description SP Use Case IP-level?
° Establish communication link.
This collaboration will be dealt within GST OS SP.
ESV – Receive Data It provides the capability to handle and interpret messages and
data received from an authorised Third Party involved in the
rescue management (e.g. hospital).
This collaboration includes:
° ESV - Check Security Authorisation, to ensure the access to
the functionalities only to authorised personnel. This
collaboration will be dealt within GST SEC SP.
° ESV - Data transferred.
° ESV - Data interpreted.
° ESV - Acknowledge Receipt Data.
Table 9 - Descriptions of Collaborations for the RSQ Sub-project
3/23/2006 58 Version 2.0
° UC RSQ 008

DEL_RSQ_3_1 Architecture and Interface Specifications
PART 2 - LOGICAL VIEW
3/23/2006 59 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 5 - LOGICAL VIEW PART STRUCTURE
5.1 Introduction
This part of the document is called logical view. It will give more detailed information
and facts on the collaborations defined previously.
5.2 Organisation of the Logical View Part Chapters
Every following chapters dealing with a work item will have the same organisational
structure. This will be briefly explained here. The sections related to each collaboration
will have eight sections:
1. Introduction
In this section a description of the respective collaboration will be given.
2. Use Case Diagram
The collaboration will be mapped on a use case diagram in this section. A decomposition
into several sub-collaborations and therefore several sub-use case diagrams
is possible. The diagrams will be made with the Enterprise Architect Software.
If the collaboration described in this chapter is a composite collaboration (ie, it can be
broken down in several sub-collaborations) it is suggested that the paragraphs below
become repeating blocks under each sub-collaboration.
3. Interfaces
In this section class diagrams will be given to explain the interface definitions for the
collaboration. In addition a textural description of the interfaces will be given in a table.
An explanation of the columns of the tables used in this section is given in Table 10.
Title Explanation
Interface Name Each interface must be given a short name written in a short
manner so that the meaning is clear.
Interface Description This provides more information for a better understanding of
the interface.
IP-level? This field is crossed (X) if the item corresponds to the item
defined as “invariant” (common for all sub-projects) at IPlevel
(in [3]or - for later versions - [4]).
Comments Explanatory notes showing how an interface contributes to the
realisation of a collaboration.
Table 10 - Definition of Terms Used when Describing Interfaces
3/23/2006 60 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
4. Protocol Stack and Specification
For the purpose of GST [14] the original 7-layer OSI model is simplified in two
arbitrarily layers: a payload and a transport layer. The payload layer contains those
protocols who are not involved in the routing functionality of the protocol stack but
rather contain all necessary features to identify the upper layer message type. The
transport layer lists those protocols involved in the routing of the messages.
The following picture shows the relation between those two stacks.
Figure 13 – GST and OSI Protocol Layers comparison
The protocol definition is part of the GST Core specifications and as such mandatory to
GST implementations. This proposal specifies the protocol technology used for each of
the payload and transport layers per protocol type (Client System to Control Centre,
Client System to Service Centre etc.). It however does not provide any details on the
application level message definitions.
All GST specifications for the protocol – both Payload and Transport layer – are
specified with formalised language, so that all GST protocol implementation could be
certified.
Moreover, specifications related to how the protocol stack shall be used for messages
exchange will be given as well.
5. Message Structure
In this section the content and the structure of each exchanged message will be given.
6. API Specification
In this section the specifications for API implementation will be given by describing for
each class and objects the following items:
3/23/2006 61 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• Connections with objects or entity already defined for the GST RESCUE
architecture;
• Attributes and implemented Methods.
7. Interactions
In this section sequence diagrams will be given to explain the interactions occur-ring with
this collaboration coherently. In addition the interactions will be described in a table. An
explanation of the columns of the tables used in this section is given in the following
Table.
Title Explanation
Lifecycle Name Each lifecycle must be given a short name written in a short
manner so that the meaning is clear.
Lifecycle Description This provides more information for a better understanding of
the lifecycle.
IP-level? This field is crossed (X) if the item corresponds to the item
defined as “invariant” (common for all sub-projects) at IPlevel
(in [3]or - for later versions - [4]).
Table 11 - Definition of Terms Used when Describing Lifecycles
5.3 RESCUE Collaborations overview
With reference to the scoping table document:
• WOR_GST_RSQ_Scoping_Table_v6.xls
the following sub-paragraphs give an overview of the collaborations considered within
RESCUE SP, illustrating the “work item”, in other words the domain the collaboration
belongs to, the relevance for the SP, the standardisation value that the collaboration
could provide to GST and dependencies or liaisons.
The main purpose of the following sub-paragraph is to prioritise the work to be dealt
within RESCUE SP and to define and to establish the appropriate co-operation with
other SPs or Projects needed to carry out RESCUE specifications.
Each one of the following sub-paragraphs covers a specific use case.
An explanation of the columns of the tables used in this section is given in Table 12.
Title Explanation
Collaboration Name of the Collaboration as defined in Table 8.
Work Item It represents a “Super Collaboration” this Collaboration
belongs to. A Work Item has two main purposes:
• Allocate a set of “logical related” Use Cases –
Collaborations to the Domain Experts
3/23/2006 62 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• Arrange the perhaps many collaborations in the logical
view.
Relevance This is a number from 1 to 3 with the following meaning:
1 – This is a very critical Use Case, without it the Sub-Project
does not exist.
2 – This Use Case is necessary, without it the Sub Project has
no real value.
3 – These are Use Cases, which are nice to have, but the Sub
Project can live without it.
Standardisation Value Indicate if the Use Case has any value for an eventual
standardisation. 0 means: no-value for standardisation, 1
means value for standardisation.
Dependencies/Liaisons This determines the dependency to another Use Case. If the
Use Case is dependent on the realisation of another Use Case
the effort value will possibly be 3. Moreover it indicates
liaisons with external projects to which a link must be
established or from which input are incoming.
Summarising in this column are listed in the appropriate order:
Reference
Implementation
• GST_RSQ Use Cases which already cover the
collaboration;
• Other GST SPs to which the collaboration should make
reference or it is expected that the SP covers the
collaboration as well;
• Other Projects, Groups or Forums to which a link should
be established or from which inputs are incoming.
What will be the implementation result in the reference
implementation for this Use Case.
Table 12 - Definition of Terms Used when describing Collaborations Organisation
5.3.1 UC RSQ 001 – Triggers Automatic Calls Collaborations
An overview of the UC RSQ 001 Collaborations is given in Table 13.
Collaboration Work Item Relevance
PV – ECALL Activation
(Manual/ Automatic)
PV – ECALL Manual
Cancelling
PV – Emergency Data
Handling
Standardisation
Value
Dependencies
/Liaisons
Vehicle ECALL 1 1 E-MERGE
Vehicle ECALL 2 1 E-MERGE
Vehicle ECALL 1 1 E-MERGE
3/23/2006 63 Version 2.0

PV – Voice Link
Establishment
PV – Emergency Data
Message Sending
PV – Additional Data
Sending to SP
PV – Acknowledge of
Data Sent
DEL_RSQ_3_1 Architecture and Interface Specifications
Vehicle ECALL 1 0 E-MERGE
Vehicle ECALL 1 0
Vehicle ECALL 3 0
System
Management
3 0
Table 13 – UC RSQ 001 Collaboration Overview
5.3.2 UC RSQ 002 – PSAP1 Collaborations
An overview of the UC RSQ 002 Collaborations is given in Table 14.
Collaboration Work Item Relevance
PSAP1 – Incoming
ECALL
PSAP – Emergency
Data Handling
PSAP1 – Additional
Data Retrieving from SP
PSAP – Emergency
Data Visualisation
PSAP1 – PSAP2
Identification
PSAP1 – Route the
ECALL to PSAP2
PSAP1 – Emergency
Data Available for
PSAP2
Standardisation
Value
E-MERGE,
eCall Driving
Group
GST_OS, E-
MERGE
GST_OS, E-
MERGE
Dependencies
/Liaisons
PSAP ECALL 2 0 E-MERGE
PSAP ECALL 1 1 E-MERGE
PSAP ECALL 3 0
PSAP ECALL 1 0
PSAP ECALL 1 0
PSAP ECALL 2 0
PSAP ECALL 3 0
PSAP1 – EOS PSAP ECALL 1 1
Table 14 – UC RSQ 002 Collaboration Overview
5.3.3 UC RSQ 003 – PSAP2 Collaborations
An overview of the UC RSQ 003 Collaborations is given in Table 15.
Collaboration Work Item Relevance
Standardisation
Value
GST_OS, E-
MERGE
E-MERGE,
CGALIES
GST_OS, E-
MERGE
GST_OS, E-
MERGE
Dependencies
/Liaisons
3/23/2006 64 Version 2.0

PSAP2 – Emergency
Data Retrieving from
PSAP1
PSAP – Emergency
Data Handling
PSAP – Emergency
Data Visualisation
PSAP2 – Locate, Assess
and Identify the incident
PSAP2 – Rescue
Resources Assignment
Transmission of Data
ESV – Emergency
Handling Closure
Rescue Resources
Released
DEL_RSQ_3_1 Architecture and Interface Specifications
PSAP ECALL 3 0
PSAP ECALL 1 1
PSAP ECALL 1 0
PSAP ECALL 3 0
PSAP Rescue
Management
PSAP Rescue
Management
PSAP Rescue
Management
PSAP Rescue
Management
1 0
1 1
2 0
2 0
Table 15 – UC RSQ 003 Collaboration Overview
5.3.4 UC RSQ 004 – Data to Vehicle Collaborations
An overview of the UC RSQ 004 Collaborations is given in Table 16.
Collaboration Work Item Relevance
ESV – Emergency Data
Receipt from PSAP2
ESV – Acknowledge
Receipt of Data
ESV – Emergency Data
Visualisation
ESV – Accept
Deployment
ESV – Incident Data
Update
ESV – Emergency
Handling Closure
Rescue Resources
Released
PSAP to Vehicle
Communication
System
Management
ESV Rescue
Management
ESV Rescue
Management
ESV Rescue
Management
ESV Rescue
Management
ESV Rescue
Management
Standardisation
Value
1 1
GST_OS, E-
MERGE
UC RSQ 002,
E-MERGE
UC RSQ 002,
E-MERGE,
CGALIES
GST_OS,
GST_SEC
Dependencies
/Liaisons
GST_OS,
GST_SEC
2 1 GST_OS
1 0
GST_OS,
AIDE
2 1 GST_OS
3 1
Table 16 – UC RSQ 004 Collaboration Overview
GST_OS,
GST_SEC
2 0 UC RSQ 003
2 0 UC RSQ 003
3/23/2006 65 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
5.3.5 UC RSQ 005 – Route Guidance Collaborations
An overview of the UC RSQ 005 Collaborations is given in Table 17.
Collaboration Work Item Relevance
ESV – Target
Information Reception
ESV – Provide Target
Location
ESV – Accept Route
Option
ESV – Check Security
Authorisation
ESV – Display Route
Options
ESV – Get latest Traffic
and Weather Info
ESV – Calculate Route
Options
ESV – Recalculate
Route Options
ESV – Advise driver if
better alternative route
ESV – Update Trip
Progress
ESV – Advice at Arrival
Scene
ESV – Remote Upgrade
ESV – Disable Device
ESV – Reset Navigation
System
ESV – Customise
Presentation Options
ESV – Report Device
Faults
ESV – Advice Device
Status
ESV Driver
Support
ESV Driver
Support
ESV Driver
Support
Standardisation
Value
Dependencies
/Liaisons
1 1 GST_OS
3 0
2 1
Security 3 1 GST_SEC
ESV Driver
Support
ESV Driver
Support
ESV Driver
Support
ESV Driver
Support
ESV Driver
Support
ESV Driver
Support
ESV Driver
Support
System
Management
System
Management
ESV Driver
Support
ESV Driver
Support
System
Management
System
Management
1 1
GST_OS,
AIDE
3 0 GST_EFCD
1 0
3 0
3 0
2 0
2 1 AIDE
3 1 GST_OS
3 1 GST_OS
2 0
3 0 AIDE
3 1 GST_OS
3 1
Table 17 – UC RSQ 005 Collaboration Overview
GST_OS,
AIDE
3/23/2006 66 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
5.3.6 UC RSQ 006 – Blue Wave Collaborations
An overview of the UC RSQ 006 Collaborations is given in Table 18.
Collaboration Work Item Relevance
ESV – Activate Warning
Messages
ESV – Activate Warning
Message Options
ESV – Check Security
Authorisation
ESV – Disable Device
ESV – Report
Transmission Faults
ESV – Remote Upgrade
ESV – Advice Device
Status
ESV – Send Warning
Message
ESV – Get Emergency
Data
ESV – Send to TCCs
ESV – Send to EFCD
ESV – Reset
Transmission
ESV – Customise
Screen Options
PV – Receive Warning
Message
PV – Interpret Warning
Message
PV – Present Language
Independent Message
PV – Repeat with
Increasing Notification
PV – Remote Upgrade
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Standardisation
Value
1 1
Security 3 1
System
Management
System
Management
System
Management
System
Management
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Vehicle to Centre
Communication
Vehicle to Centre
Communication
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Public Vehicle
Driver Support
Public Vehicle
Driver Support
System
Management
2 Car To Car Communication Consortium
Dependencies
/Liaisons
PReVENT,
C2CC 2
2 0 AIDE
UC RSQ 005,
GST_SEC
3 1 GST_OS
3 1 GST_OS
3 1
3 1
1 1
2 0
UC RSQ 005,
GST_OS
UC RSQ 005,
GST_OS,
AIDE
PReVENT,
C2CC
3 1 GST_EFCD
3 1 GST_EFCD
1 0
3 0 AIDE
1 1
1 1
PReVENT,
C2CC
2 1 AIDE
3 0
3 1
UC RSQ 005,
GST_OS
3/23/2006 67 Version 2.0

PV – Advise Device
Status
PV – Report Receiving
Device Faults
PV – Reset Warning
Message
PV – Present Thank you
System
Management
System
Management
Public Vehicle
Driver Support
Public Vehicle
Driver Support
DEL_RSQ_3_1 Architecture and Interface Specifications
3 1
UC RSQ 005,
GST_OS,
AIDE
3 1 GST_OS
1 1
Table 18 – UC RSQ 006 Collaboration Overview
3 1 AIDE
5.3.7 UC RSQ 007 – Virtual Cones Collaborations
An overview of the UC RSQ 007 Collaborations is given in Table 19.
Collaboration Work Item Relevance
ESV – Activate Warning
Messages
ESV – Activate Warning
Message Options
ESV – Check Security
Authorisation
ESV – Disable Device
ESV – Report
Transmission Faults
ESV – Remote Upgrade
ESV – Advice Device
Status
ESV – Send Warning
Message
ESV – Get Emergency
Data
ESV – Send to TCCs
ESV – Send to EFCD
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Standardisation
Value
1 1
2 0
Security 3 1
System
Management
System
Management
System
Management
System
Management
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Vehicle to Centre
Communication
Vehicle to Centre
Communication
3 1
3 1
3 1
3 1
1 1
Dependencies
/Liaisons
UC RSQ 006,
PReVENT,
C2CC
UC RSQ 006,
AIDE
UC RSQ 005,
UC RSQ 006,
GST_SEC
UC RSQ 006,
GST_OS
UC RSQ 006,
GST_OS
UC RSQ 005,
UC RSQ 006,
GST_OS
UC RSQ 005,
UC RSQ 006,
GST_OS,
AIDE
UC RSQ 006,
PReVENT,
C2CC
2 0 UC RSQ 006
3 1
3 1
UC RSQ 006,
GST_EFCD
UC RSQ 006,
GST_EFCD
3/23/2006 68 Version 2.0

ESV – Reset
Transmission
ESV – Customise
Screen Options
PV – Receive Warning
Message
PV – Interpret Warning
Message
PV – Present Language
Independent Message
PV – Repeat with
Increasing Notification
PV – Remote Upgrade
PV – Advise Device
Status
PV – Report Receiving
Device Faults
PV – Reset Warning
Message
PV – Present Thank you
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Vehicle to Vehicle
Communication
Public Vehicle
Driver Support
Public Vehicle
Driver Support
System
Management
System
Management
System
Management
Public Vehicle
Driver Support
Public Vehicle
Driver Support
DEL_RSQ_3_1 Architecture and Interface Specifications
1 0 UC RSQ 006
3 0
1 1
UC RSQ 006,
AIDE
UC RSQ 006,
PReVENT,
C2CC
1 1 UC RSQ 006
2 1
UC RSQ 006,
AIDE
3 0 UC RSQ 006
3 1
3 1
3 1
UC RSQ 005,
UC RSQ 006,
GST_OS
UC RSQ 005,
UC RSQ 006,
GST_OS,
AIDE
UC RSQ 006,
GST_OS
1 1 UC RSQ 006
3 1
Table 19 – UC RSQ 007 Collaboration Overview
5.3.8 UC RSQ 008 – Value Added Data Collaborations
An overview of the UC RSQ 008 Collaborations is given in Table 20.
Collaboration Work Item Relevance
ESV – Disable Device
V – External Device
Support
Transmission of Data
Collation of Data
Processing of Data
System
Management
System
Management
Vehicle to Centre
Communication
Vehicle to Centre
Communication
Vehicle to Centre
Communication
Standardisation
Value
UC RSQ 006,
AIDE
Dependencies
/Liaisons
3 1 GST_OS
2 0 GST_OS
1 1 GST_OS
2 1
1 0
3/23/2006 69 Version 2.0

Display Destination
Options
Establish
Communication link
ESV – Receive Data
ESV – Acknowledge
Receipt of Data
ESV – Check Security
Authorisation
ESV – Data Transferred
ESV – Data Interpreted
ESV – Advise Device
Status
ESV – Report Device
Faults
ESV – Remote Upgrade
Vehicle to Centre
Communication
Vehicle to Centre
Communication
Vehicle to Centre
Communication
System
Management
DEL_RSQ_3_1 Architecture and Interface Specifications
2 0
1 1 GST_OS
2 1
Security 3 1
Vehicle to Centre
Communication
Vehicle to Centre
Communication
System
Management
System
Management
System
Management
GST_OS,
GST_SEC
3 1 GST_OS
3 0
1 0
3 1
3 1
3 1
Table 20 – UC RSQ 008 Collaboration Overview
5.4 Relationship between Work Items and Liaisons
UC RSQ 005,
GST_SEC
UC RSQ 005,
GST_OS,
AIDE
UC RSQ 005,
GST_OS
UC RSQ 005,
GST_OS
The previous sub-paragraph highlighted the relationship between RESCUE
Collaborations and Work Items or Domain. At the same time internal RESCUE
Collaborations dependencies and liaisons with external Projects and GST SPs are
defined.
The following table summarises the relationship between the work items (identified as
operative domains) and liaisons.
Work Item Main Liaisons
Vehicle ECALL E-MERGE
PSAP ECALL E-MERGE, CGALIES
PSAP to Vehicle Communication
PSAP Rescue Management
ESV Driver Support AIDE
Vehicle to Vehicle Communication PReVENT, C2CC
ESV Rescue Management
Public Driver Support AIDE
3/23/2006 70 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Vehicle to Centre Communication GST_OS, GST_SEC
System Management GST_OS
Security GST_SEC
Table 21 – Relationship between Work Items and Liaisons
Moreover, every collaboration for which HMI design is foreseen a specific liaisons
between RESCUE and AIDE [12] has been specified since HMI design guidelines
should be delivered from the “Adaptive Integrated Driver-vehicle Interface” IP-Project.
5.5 Logical View Work Focusing
On the basis of what has been defined in terms of relevance and standardisation value
provided by the RSQ Collaborations definition in the previous paragraph, it is possible to
select those collaboration which must be handled during the Logical View definition.
The Logical View work will prioritise those collaborations which have a high relevance
value and at the same time will provide a standardisation added value to the GST project.
Moreover another criteria has been considered during the prioritisation process of the
work: the fulfilment of the eCall Management Chain. This criteria has been used to select
those collaborations that are needed to complete the chain and, at the same time, enable
the performance evaluation of the eCall Management Chain itself.
The following table lists all the collaborations which will be described and developed in
the next chapters during the Logical View definition phase. The same collaborations will
be subject to Implementation View definition in order to easily migrate towards the
reference implementation. The last column represents what RESCUE SP is going to
provide as Reference Implementation at the end of the work. Moreover, always
considering the added value which each collaboration development tends to give to the
GST project, the last column is used to explain the reasons to take out of the
development work those collaborations which GST RESCUE does not deal with.
In order to allow a better comprehension about exactly what will be provided by GST
RESCUE as reference implementation to the test sites a colour coding of the content has
been adopted within the following table.
Yellow marked collaborations mean a highly relevance for the project and a great added
value in terms of standardisation and innovation.
Blue marked collaborations mean that their implementation is left for further
development or no added value is expected.
Use Case Collaboration Reference Implementation/Comments
UC RSQ 001
PV – ECALL Activation
(Manual/ Automatic)
This collaboration is highly relevant for GST
RSQ. The reference implementation for this
collaboration will consist of a “Thresholds
Handler”.
3/23/2006 71 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
PV – ECALL Manual
Cancelling
PV – Emergency Data
Handling
PV – Voice Link
Establishment
PV – Emergency Data
Message Sending
PV – Additional Data
Sending to SP
PV – Acknowledge of Data
Sent
This collaboration provides a medium value
added for the project, but it represents a useful
feature for tests conduction. For this reason it is
already included into the implementation guide.
This collaboration provides the capability to
retrieve all data needed to be sent to the PSAP1
and to prepare the data message in the
appropriate format. Data (the E-MERGE
Minimum Set of Data at least.) to be sent must be
formatted in the GST-E-MERGE protocol.
The reference implementation will consist of a
“MSD Encoder”.
Since it is strictly related to the communication
device HW to be used, no particular
standardisation value is expected from the
development of this collaboration so its
implementation is left for further development.
This collaboration should be analysed on the basis
of two different aspects. Since it is strictly related
to the communication device HW to be used, no
particular standardisation value is expected from
the development of a transmitter component. On
the other hand a key aspect is represented by the
eCALL protocol handling on which will be
focused the implementation.
This is an optional collaboration.
This collaboration provides the capability to
retrieve all data needed to be sent to the Service
Provider and to prepare the data message in the
appropriate format. Data (the E-MERGE Full Set
of Data.) to be sent must be formatted in the E-
MERGE protocol.
This collaboration is not put under further
development.
This collaboration is strictly related to the
“System Management” domain, but, at the same
time it has a high standardisation value and
relevance for the GST RESCUE SP.
ACK Message to be sent by the PSAP1 must be
formatted in the GST-E-MERGE protocol.
The “ACK Message Decoder” will be though
provided as reference implementation.
3/23/2006 72 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
UC RSQ 002
PSAP1 – Incoming ECALL
PSAP – Emergency Data
Handling
PSAP1 – Additional Data
Retrieving from SP
PSAP – Emergency Data
Visualisation
PSAP1 – PSAP2
Identification
This collaboration provides the capability to
detect and alert the operator of an incoming
ECALL and to establish automatically the voice
link with the vehicle.
The process could be decomposed as follows:
1 Detecting ECALL;
2 Alert the operator;
3 Establish the voice link..
However the related implementation is strictly
related to the PSAP1 system configuration and
this collaboration is left for further development.
This collaboration provides the capability to
retrieve from the MSD message all information
needed at the PSAP1 and to prepare the data
message in the appropriate format. Data (the E-
MERGE Minimum Set of Data at least.) to be
received must be formatted in the GST-E-
MERGE protocol.
At the same time when data are correctly received
the PSAP1 system acknowledge the Vehicle
System with an ACK message to be sent
formatted in the GST-E-MERGE protocol.
The reference implementation will consist of a
“MSD Decoder” and an “ACK Encoder”.
This is an optional collaboration which extend the
PSAP1 capability to collect and enrich the
available information related to an incident if the
driver is a Service Provider subscriber.
Specifications for this collaboration are already
available from E-MERGE project.
This collaboration is not put under further
development.
On the basis on CGALIES recommendations and
E-MERGE specifications received data are
visualised at the PSAP Operator workstation
showing the vehicle location on a map support.
The reference implementation will consist of a
“XML Data Part Handler” to be put under a
PSAP1 XML Viewer.
This collaboration describes a procedure to
identify the PSAP2 which is responsible for the
rescue action. The identification is dependent on
geographical breakdown and territorial allocation.
This collaboration is very specific for PSAP1 and
for the region and is not put under further
development.
3/23/2006 73 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
UC RSQ 003
PSAP1 – Route the ECALL
to PSAP2
PSAP1 – Emergency Data
Available for PSAP2
PSAP1 – EOS
PSAP2 – Emergency Data
Retrieving from PSAP1
PSAP – Emergency Data
Handling
PSAP – Emergency Data
Visualisation
PSAP2 – Locate, Assess and
Identify the incident
This collaboration provides the capability to route
the voice call to the PSAP2, which could be
realised by setting up a conference call with the
centres depending by the Phone Call Management
System at the PSAP1.
This collaboration is not put under further
development.
This collaboration provides the capability to store
the emergency data to make them available for
authorised requests. Since it is strictly related to a
data storage problem, no value added is expected
by the development of this collaboration.
This collaboration is not put under further
development.
EOS Message to be sent by the PSAP1 must be
formatted in the GST-E-MERGE protocol.
The “EOS Message Encoder” will be though
provided as reference implementation.
The capability to retrieve emergency information
in a standardised way overall in Europe cover one
of the key aspects for GST RSQ.
The reference implementation will consist of a
SOAP based web service.
The capability to handle the retrieved emergency
information in a standardised way overall in
Europe cover one of the key aspects for GST
RSQ.
The reference implementation will consist of a
SOAP Message handler.
On the basis on CGALIES recommendations and
E-MERGE specifications received data are
visualised at the PSAP Operator workstation
showing the vehicle location on a map support.
The reference implementation will consist of a
“XML Data Part Handler” to be put under a
PSAP1 XML Viewer.
This collaboration provides the capability to store
the emergency data to locate, assess and identify
the incident in order to provide the most
appropriate rescue needed.. Since it is strictly
related to PSAP2 emergency handling procedures,
no value added is expected by the development of
this collaboration.
This collaboration is not put under further
development.
3/23/2006 74 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
UC RSQ 004
PSAP2 – Rescue Resources
Assignment
Transmission of Data
ESV – Emergency Handling
Closure
Rescue Resources Released
ESV – Emergency Data
Receipt from PSAP2
ESV – Acknowledge Receipt
of Data
This collaboration provides the capability to store
the assign the most appropriate rescue resources
to an emergency management.. Since it is strictly
related to PSAP2 emergency handling procedures,
no value added is expected by the development of
this collaboration.
This collaboration is not put under further
development.
The capability to transmit emergency information
directly to the ESV in a standardised way provides
a high value added to the project.
No HW interface is considered for this
collaboration.
The reference implementation will consist of a
SOAP Message handler.
This collaboration provides the capability to close
an emergency management process which allows
the ESV personnel to notify the emergency
handling closure to the PSAP2.
The reference implementation will consist of a
SOAP Message handler.
This collaboration provides the capability to
release the assign rescue resources in order to
make them available for another rescue. Since it is
strictly related to PSAP2 emergency handling
procedures, no value added is expected by the
development of this collaboration.
This collaboration is not put under further
development.
This collaboration provides the capability to
detect and alert the Emergency Service Personnel
of an incoming Data Message from the PSAP 2
and to establish automatically the voice link with
the vehicle. It also provides the capability to
handle and to interpret the received Emergency
Data Message.
The reference implementation will consists of a
SOAP Message Handler.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
3/23/2006 75 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
UC RSQ 005
ESV – Emergency Data
Visualisation
ESV – Accept Deployment
ESV – Incident Data Update
ESV – Emergency Handling
Closure
Rescue Resources Released
ESV – Target Information
Reception
ESV – Provide Target
Location
ESV – Accept Route Option
ESV – Check Security
Authorisation
This collaboration provides the capability to
display on board the emergency data related to
the incident, also in terms of location and type,
and to the rescue needed.
The reference implementation will consists of the
XML Data Parser which stands behind the
Viewer.
This collaboration provides the capability to
acknowledge the PSAP2 if the ESV is taking up
the rescue process for a specific incident..
The reference implementation will consists of the
SOAP message handler..
This collaboration represents a subset of UC RSQ
008 functionalities. For this reason reference
implementation will focus on the last one.
This collaboration is strictly related to the ESV
management, but it is not representing a key issue
for GST RESCUE. For this reason its
development if left for further at test sites level.
This collaboration is strictly related to the ESV
management, but it is not representing a key issue
for GST RESCUE. For this reason its
development if left for further at test sites level.
This collaboration describes the capability of the
ESV of receiving target information by PSAP2.
The target information are represented by:
• Target location
The reference implementation will consist of the
Location Data Handler that will allow the ESV to
receive from PSAP2. This is a SOAP clientserver.
This collaboration describes the capability of
PSAP2 of providing the target information to
ESV.
Its development if left for further at test sites level
This collaboration describes the capability of the
ESV to accept the route that has been calculated
off board by the PSAP2.
Its development if left for further at test sites level
This collaboration is dealt within GST SEC sub
project. For more information refer to [15] –
Chapter 6.
3/23/2006 76 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
ESV – Display Route
Options
ESV – Get latest Traffic and
Weather Info
ESV – Calculate Route
Options
ESV – Recalculate Route
Options
ESV – Advise driver if
better alternative route
ESV – Update Trip Progress
ESV – Advice at Arrival
Scene
ESV – Remote Upgrade
ESV – Disable Device
This collaboration describes the capability of the
ESV to display the routes calculated by the
PSAP2.
Its development if left for further at test sites level
This collaboration describes the capability of the
PSAP2 of connecting to a service for gathering
traffic and weather info to use them form more
efficient route calculation.
Its development if left for further at test sites level
This collaboration describes the capability of the
PSAP2 of calculating best route option given
incident target and ESV starting location, GIS
data and traffic/weather data.
The reference implementation will consist in the
Location Data Handler that will support the
following functions:
• To ask for a route (ESV side)
• To receive a route (PSAP2 side)
The actual route calculation is not provided as
reference implementation.
This collaboration describes the capability of the
PSAP2 of re-calculating best route option when a
first calculated option has been refused by ESV or
when ESV is out of track.
Its development if left for further at test sites level
This collaboration describes the capability of the
PSAP2 of advice ESV of a better available route.
Its development if left for further at test sites level
This collaboration describes the capability of the
PSAP2 to track the ESV trip real time.
Its development if left for further at test sites level
This collaboration describes the capability of the
ESV to advise emergency personnel that the
target location has been reached.
Its development if left for further at test sites level
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
Its development if left for further at test sites level
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
Its development if left for further at test sites level
3/23/2006 77 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
UC RSQ 006
– UC RSQ
007
ESV – Reset Navigation
System
ESV – Customise
Presentation Options
ESV – Report Device Faults
ESV – Advice Device Status
ESV – Activate Warning
Messages
ESV – Activate Warning
Message Options
ESV – Check Security
Authorisation
ESV – Disable Device
ESV – Report Transmission
Faults
ESV – Remote Upgrade
ESV – Advice Device Status
This collaboration describes the capability of the
ESV to reset the navigation system.
Its development if left for further at test sites level
This collaboration describes the capability of the
ESV to let the emergency personnel to customize
the way the route guidance information will be
presented.
Its development if left for further at test sites level
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
Its development if left for further at test sites level
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
Its development if left for further at test sites level
This collaboration provides the capability to
activate a warning message broadcast
transmission.
The reference implementation will consist of a
ESV Blue Wave / Virtual Cones Service.
This collaboration provides a medium value
added for the project, and relates to the
availability of a choice of warning messages
available to the actors in the Emergency Services
Vehicle.
This collaboration is not put under further
development.
This collaboration is dealt within GST SEC sub
project. For more information refer to [15] –
Chapter 6.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
3/23/2006 78 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
ESV – Send Warning
Message
ESV – Get Emergency Data
ESV – Send to TCCs
ESV – Send to EFCD
ESV – Reset Transmission
ESV – Customise Screen
Options
PV – Receive Warning
Message
PV – Interpret Warning
Message
This collaboration provides the capability to
prepare and despatch a data message using the
selected transmission protocol.
The reference implementation will consist of a
ESV Blue Wave / Virtual Cones Service.
This collaboration provides a medium value
added for the project and is not put under further
development.
This is an optional collaboration that extends
receipt of the warning message transmission to
Traffic Control Centres.
This collaboration is not put under further
development.
This is an optional collaboration that extends
receipt of the warning message transmission to
EFCD.
This collaboration is not put under further
development.
This collaboration provides the capability to reset
warning transmission on board the Emergency
Services Vehicle.
The reference implementation will consist of a
ESV Blue Wave / Virtual Cones Service.
This is an optional collaboration that provides
actors in the Emergency Services Vehicle to
customise any HMI components on the basis of
personal preferences.
This collaboration is not put under further
development.
This collaboration provides the capability to
receive, to handle and to interpret a warning
message coming from an Emergency Services
Vehicle.
The reference implementation will consist of a
PV Blue Wave / Virtual Cones Listener Service.
This collaboration enables the received warning
message to be formatted in such a way as to be
comprehensible to the actors in the Public
Vehicle.
The reference implementation will consist of a
PV Blue Wave / Virtual Cones Listener Service.
3/23/2006 79 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
UC RSQ 008
PV – Present Language
Independent Message
PV – Repeat with Increasing
Notification
PV – Remote Upgrade
PV – Advise Device Status
PV – Report Receiving
Device Faults
PV – Reset Warning
Message
PV – Present Thank you
ESV – Disable Device
V – External Device
Support
Transmission of Data
This collaboration provides a medium value
added for the project, and raises the need for the
message to be communicated in an
understandable format to the actors in the
Emergency Services Vehicle.
This collaboration is not put under further
development.
This is an optional collaboration that repeats any
warning message activation with increased
notification in order to exact a response from the
Public Vehicle Driver.
This collaboration is not put under further
development.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration provides the capability to reset
warning notifications on board the Public
Vehicle.
The reference implementation will consist of a
PV Blue Wave / Virtual Cones Listener Service.
This is an optional collaboration that recognises
and acknowledges the do-operation of the Public
Vehicle Driver.
This collaboration is not put under further
development.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration provides the capability to
transmit information or to send a request from
the Client System to a Third Party.
The reference implementation will consist of a
SOAP upload request message.
3/23/2006 80 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
Collation of Data
Processing of Data
Display Destination Options
Establish Communication
link
ESV – Receive Data
ESV – Acknowledge Receipt
of Data
ESV – Check Security
Authorisation
ESV – Data Transferred
This collaboration provides the capability to put
together the VAD and to relate them to the
specific incident.
The reference implementation will consists of a
“File Marker” Component.
This collaboration provides the capability to
process the information to be exchanged with any
authorised third party. It allows the ESV
personnel to select the VAD to be sent to the
third party.
The reference implementation will consists of a
“Files Selection” component.
This collaboration provides the capability for the
ESV Personnel to select a destination for VAD
from a list of authorised third parties (including
PSAP2).
No particular value added is expected from the
development of this collaboration so its
implementation is left for further development..
Since it is strictly related to the communication
device HW to be used, no particular
standardisation value is expected from the
development of this collaboration so its
implementation is left for further development.
This collaboration provides the capability to
handle and interpret messages and data received
from an authorised Third Party involved in the
rescue management (e.g. hospital).
The reference implementation will consist of a
SOAP download request message integrated with
a Data Downloader.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is dealt within GST SEC sub
project. For more information refer to [15] –
Chapter 6.
This collaboration provides the capability to alert
the ESV personnel that new data are available on
board.
The reference implementation will consist of a
Alert Message Handler to be displayed on board
through the HMI.
3/23/2006 81 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Reference Implementation/Comments
ESV – Data Interpreted
ESV – Advise Device Status
ESV – Report Device Faults
ESV – Remote Upgrade
5.6 Reading Specifications
This collaboration provides the capability to
process and visualise onboard the data incoming
from authorised third parties.
Since this collaboration is mainly related to HMI
aspects, its implementation is left for further
development.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
This collaboration is strictly related to the
“System Management” domain. For this reason it
is dealt within GST OS sub project.
Table 22 – Logical View Focusing
Each one of the “yellow marked” collaborations illustrated in the previous table is dealt
in the following chapters. In order to help the reader in finding and more easily
understanding GST RESCUE specifications the following table illustrates in which
paragraph the related specifications may be found.
Collaboration
UC RSQ 001 - PV – ECALL Activation (Manual/
Automatic)
Specifications can
be found at
par. 6.1
UC RSQ 001 - PV – ECALL Manual Cancelling par. 6.2
UC RSQ 001 - PV – Emergency Data Handling par. 6.3
Please also
refer to
par. 19.1
par. 19.12
UC RSQ 001 - PV – Emergency Data Message Sending par. 6.4
par. 19.2
par. 19.3
par. 19.10
UC RSQ 001 - PV – Acknowledge of Data Sent par. 16.2 par. 19.2
UC RSQ 002 - PSAP – Emergency Data Handling par. 7.2
UC RSQ 002 - PSAP – Emergency Data Visualisation par. 7.1 par. 19.4
UC RSQ 002 - PSAP1 – EOS par. 7.4 par. 19.2
UC RSQ 003 - PSAP2 – Emergency Data Retrieving from
PSAP1
par. 7.3
UC RSQ 003 - PSAP – Emergency Data Handling par. 7.2
UC RSQ 003 - PSAP – Emergency Data Visualisation par. 7.1 par. 19.4
UC RSQ 003 - Transmission of Data par. 8.1
3/23/2006 82 Version 2.0

Collaboration
DEL_RSQ_3_1 Architecture and Interface Specifications
Specifications can
be found at
Please also
refer to
UC RSQ 003 - ESV – Emergency Handling Closure par. 8.2
UC RSQ 004 - ESV – Emergency Data Receipt from
par. 9.1
PSAP2
UC RSQ 004 - ESV – Emergency Data Visualisation par. 10.1
UC RSQ 004 - ESV – Accept Deployment par. 10.2
UC RSQ 005 - ESV – Calculate Route Options par. 11.1
UC RSQ 005 - ESV – Display Route Options par. 11.2 Par. 19.5
UC RSQ 005 - ESV - Target Information Reception par. 11.3
UC RSQ 006 – UC RSQ 007 - ESV – Activate Warning
Messages
par. 12.1
UC RSQ 006 – UC RSQ 007 - ESV – Send Warning
Message
par. 12.3
UC RSQ 006 – UC RSQ 007 - ESV – Reset Transmission par. 12.2
UC RSQ 006 – UC RSQ 007 - PV – Receive Warning
Message
par. 12.5
UC RSQ 006 – UC RSQ 007 - PV – Interpret Warning
Message
par. 12.4
UC RSQ 006 – UC RSQ 007 - PV – Reset Warning
par. 13.1
Message
UC RSQ 008 - Transmission of Data par. 14.1
par. 19.8
par. 19.9
UC RSQ 008 - Collation of Data par. 14.3
UC RSQ 008 - Processing of Data par. 14.2
UC RSQ 008 - ESV – Receive Data par. 14.4 par. 19.8
UC RSQ 008 - ESV – Data Transferred par. 14.5
Table 23 – Specifications Organisation
3/23/2006 83 Version 2.0

Chapter 6 - VEHICLE ECALL
DEL_RSQ_3_1 Architecture and Interface Specifications
6.1 UC RSQ 001 - PV - ECALL Activation (Manual/Automatic)
6.1.1 Introduction
The collaboration describes the how an automatic or manual eCall could be started.
Figure 14 – Collaboration – PV - ECALL Activation (entities involved)
6.1.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 15 - PV - ECALL Activation (Manual/Automatic)
3/23/2006 84 Version 2.0

6.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 16 - Class Diagram for ECALL Activation (Manual/Automatic)
Interface Name Interface Description IP-level?
V-PV-Interface This interface provides the capabilities to get vehicle
related data. For this collaboration mostly triggering
sensor data is of interest.
IOD-PV-Interface This interface provides the possibilities to interact
with the HMI. For this collaboration mostly button
press for eCall is of interest.
Table 24 - Descriptions of Interfaces for ECALL Activation (Manual/Automatic)
6.1.4 API Specification
Class Diagrams Elements::IOD-PV-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object I/O Device (IOD-PV)
Class Diagrams Elements::IOD-PV-Interface Interfaces
Method Type Notes
ECallButtonPressed () public: void
CancelButtonPressed () public: void
Class Diagrams Elements::V-PV-Interface
Type: public abstract «interface» Interface
3/23/2006 85 Version 2.0

Package: Class Diagrams Elements
Connections
• Association link from object Vehicle
Class Diagrams Elements::V-PV-Interface Interfaces
Method Type Notes
GetLocationData () public: void
GetSensorData () public: void
GetOtherCarData () public: void
6.1.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 17 - Sequence Diagram showing start of an ECALL Activation (Manual/Automatic)
Interaction Name Interaction Description IP-level?
ECALL Activation
(Manual/Automatic)
This interaction diagram describes the
start of an eCall. Either by user pressing
the eCall button or two sensors gets
3/23/2006 86 Version 2.0

activated.
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 25 - Descriptions of Interactions for ECALL Activation (Manual/Automatic)
ID Message From Object To Object Notes
1 a) PushButton Member of
Public Person
2 b) CarCrash Member of
Public Vehicle
3 eCallButtonPre
ssed
I/O Device
(IOD-PV)
4 GetSensorData Telematics
Control Unit
(TCU-PV)
I/O Device
(IOD-PV)
Vehicle
Telematics
Control Unit
(TCU-PV)
Vehicle
5 Vehicle Telematics
Control Unit
(TCU-PV)
6 ProcessSensor
Data
Telematics
Control Unit
(TCU-PV)
7 MakeDecision Telematics
Control Unit
(TCU-PV)
8 StartECall Telematics
Control Unit
(TCU-PV)
Telematics
Control Unit
(TCU-PV)
Telematics
Control Unit
(TCU-PV)
Telematics
Control Unit
(TCU-PV)
Table 26 - ECALL Activation (Manual/Automatic) Messages
3/23/2006 87 Version 2.0

6.1.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 18 - State Chart Diagram for ECALL Activation (Manual/Automatic)
Figure 19 - Activity Diagram for ECALL Activation (Manual/Automatic)
3/23/2006 88 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Lifecycle Name Lifecycle Description IP-level?
PV - ECALL Activation
(Manual/Automatic)
The lifecycle shows the various states an
eCall could be in from start of the system
to shutdown.
Table 27 - Descriptions of Lifecycles for ECALL Activation (Manual/Automatic)
6.2 UC RSQ 001 – PV - ECALL Manual Cancelling
6.2.1 Introduction
This collaboration illustrates the modality for manually cancelling an already generated
eCall.
Figure 20 – Collaboration PV ECALL Manual Cancelling
6.2.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
3/23/2006 89 Version 2.0

6.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 21 - PV ECALL Manual Cancelling
Figure 22 - Class Diagram for PV ECALL Manual Cancelling
Interface Name Interface Description IP-level?
IOD-PV-Interface This interface provides the possibilities to interact
with the HMI. For this collaboration mostly
button press for eCall is of interest. This interface
provides the way to cancel an already generated
ECALL. Interface realised by the Public Vehicle
Client System of the Public Service Vehicle.
CI-PV-Interface This interface provides the possibilities to
communicate with GSM network. For this
collaboration this mostly cancelling of data and
voice call are used.
Table 28 - Descriptions of Interfaces for PV ECALL Manual Cancelling
3/23/2006 90 Version 2.0

6.2.4 API Specification
Class Diagrams Elements::CI-PV-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link to object Communication Infrastructure PV
Class Diagrams Elements::CI-PV-Interface Interfaces
Method Type Notes
EstablishVoiceCall () public: void
SendData () public: void
DisconnectVoiceCall () public: void
CheckIfDataHasBeenSent () public: void
CheckConnectionStatus () public: void
CloseDataCall () public: void
Class Diagrams Elements::IOD-PV-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object I/O Device (IOD-PV)
Class Diagrams Elements::IOD-PV-Interface Interfaces
Method Type Notes
ECallButtonPressed () public: void
CancelButtonPressed () public: void
3/23/2006 91 Version 2.0

6.2.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 23 - Sequence Diagram showing PV ECALL Manual Cancelling
Interaction Name Interaction Description IP-level?
ECALL Manual Cancelling This interaction describes the steps which
allow the Public Vehicle Person to cancel an
already generated ECALL via the HMI. The
HMI will allow this functionality with a
specific button to be pushed by a member of
the Public Vehicle.
Table 29 - Descriptions of Interactions for PV ECALL Manual Cancelling
ID Message From Object To Object Notes
1 CancelButtonPush
ed
2 StartECALLCancel
ling
Member of Public
Person
I/O Device (IOD-
PV)
I/O Device (IOD-
PV)
Telematics Control
Unit (TCU-PV)
3 CheckConnectionS Telematics Control Communication
3/23/2006 92 Version 2.0

tatus Unit (TCU-PV) Device
4 ConnectionStatus Communication
Device
5 DisconnectVoiceC
all
Telematics Control
Unit (TCU-PV)
6 CloseDataCall Telematics Control
Unit (TCU-PV)
7 ReleaseStoredData Telematics Control
Unit (TCU-PV)
8 NotifyUser Telematics Control
Unit (TCU-PV)
9 ECALLCancelled I/O Device (IOD-
PV)
6.2.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Telematics Control
Unit (TCU-PV)
Communication
Device
Communication
Device
Telematics Control
Unit (TCU-PV)
I/O Device (IOD-
PV)
Member of Public
Person
Table 30 - PV ECALL Manual Cancelling Messages
Figure 24 - State Chart Diagram showing PV ECALL Manual Cancelling
To release
memory which
contains data
sent as MSD
3/23/2006 93 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 25 - Activity Diagram showing PV ECALL Manual Cancelling
Lifecycle Name Lifecycle Description IP-level?
ECALL Manual Cancelling The lifecycle shows the various states an eCall
could be in from start of the system to
shutdown.
Table 31 - Descriptions of Lifecycles for PV ECALL Manual Cancelling
6.3 UC RSQ 001 - PV - Emergency Data Handling
6.3.1 Introduction
The collaboration describes the how data is collected for an eCall.
3/23/2006 94 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 26 – Collaboration PV - Emergency Data Handling
6.3.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 27 - PV – Emergency Data Handling
3/23/2006 95 Version 2.0

6.3.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 28 - Class Diagram for PV - Emergency Data Handling
Interface Name Interface Description IP-level?
V-PV-Interface This interface provides the capabilities to get
vehicle related data. For this collaboration
almost the complete interface is used.
Table 32 - Descriptions of Interfaces for PV - Emergency Data Handling
6.3.4 API Specification
Class Diagrams Elements::V-PV-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object Telematics Control Unit (TCU-PV)
Class Diagrams Elements::V-PV-Interface Interfaces
Method Type Notes
GetLocationData () public: float[]
GetSensorData () public: float[]
GetOtherCarData () public: float[]
3/23/2006 96 Version 2.0

6.3.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 29 - Sequence Diagram showing PV - Emergency Data Handling
Interaction Name Interaction Description IP-level?
PV – Emergency Data
Handling
This interaction diagram describes how
vehicle data is collected for an eCall.
Table 33 - Descriptions of Interactions for PV - Emergency Data Handling
ID Message From Object To Object Notes
1 GetLocationData Telematics Control
Unit (TCU-PV)
Vehicle
2 Vehicle Telematics Control
Unit (TCU-PV)
3 GetSensorData Telematics Control
Unit (TCU-PV)
Vehicle
4 Vehicle Telematics Control
Unit (TCU-PV)
5 GetOtherCarData Telematics Control
Unit (TCU-PV)
Vehicle
3/23/2006 97 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
6 Vehicle Telematics Control
Unit (TCU-PV)
7 PrepareAndFormatD
ata
Telematics Control
Unit (TCU-PV)
8 Store Vehicle Data Telematics Control
Unit (TCU-PV)
6.3.6 Lifecycles
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Table 34 - PV - Emergency Data Handling Messages
Figure 30 - State Chart Diagram for PV - Emergency Data Handling
3/23/2006 98 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 31 - Activity Diagram for PV - Emergency Data Handling
Lifecycle Name Lifecycle Description IP-level?
PV – Emergency Data
Handling
The lifecycle shows the various states
collection of eCall data could be in from
start of the system to shutdown.
Table 35 - Descriptions of Lifecycles for PV - Emergency Data Handling
6.4 UC RSQ 001 - PV - Emergency Data Message Sending
6.4.1 Introduction
The collaboration describes the how the Minimum Set of Data is transmitted to PSAP1.
3/23/2006 99 Version 2.0

ud UC RSQ 001 - PV - Emergency Data Message Sending
DEL_RSQ_3_1 Architecture and Interface Specifications
PV - Emergency Data Message Sending
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
RP
Communication
Infrastructure PV
(from Entities.RSQ)
(from Collaborations Package.RSQ)
Figure 32 – Collaboration PV - Emergency Data Message Sending
6.4.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
ud UC RSQ 001 - PV - Emergency Data Message Sending
UC RSQ 001 -
Triggers Automatic
Call
(from Use Cases Package.RSQ)
«realize»
PV - Emergency
Data Message
Sending
(from Collaborations Package.RSQ)
Figure 33 – Use Case PV - Emergency Data Message Sending
3/23/2006 100 Version 2.0

6.4.3 Interfaces
cd UC RSQ 001 - PV - Emergency Data Message Sending
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
RP
DEL_RSQ_3_1 Architecture and Interface Specifications
Communication
Infrastructure PV
(from Entities.RSQ)
«interface»
Class Diagrams Elements::CI-PV-Interface
+ EstablishVoiceCall() : void
+ SendData() : void
+ DisconnectVoiceCall() : void
+ CheckIfDataHasBeenSent() : void
+ CheckConnectionStatus() : void
+ CloseDataCall() : void
Figure 34 - Class Diagram for PV - Emergency Data Message Sending
Interface Name Interface Description IP-level?
V-PV-Interface This interface provides the capabilities to
prepare the message containing the MSD to
the PSAP through a “Communication device”
entity included into the Vehicle entity.
Table 36 - Descriptions of Interfaces for PV - Emergency Data Message Sending
3/23/2006 101 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
6.4.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-PSAP communications
protocol stack. The following picture illustrates the protocol stack adopted for the “PV –
Emergency Data Message Sending” Message exchange.
Technical background
Figure 35 – Protocol Stack - PV - Emergency Data Message Sending
• GSM: Global system for Mobile (PAN-European network)
• USSD: Unstructured Supplementary Services Data (part of GSM)
USSD allows bi-directional and half-duplex connections between a handset
and a USSD application server, exchanging plain text messages with each other.
USSD offers session-oriented connections. Each USSD message can contain
up to 182 user characters and is completely transparent for the handset and the
mobile network. USSD is borne by the SDCCH channel on the signalling radio
interface (GSM).
• ASN.1: Abstract Syntax Notation number one allows defining messages and
encoding them in the Tag Length Value (TLV) binary format. This notation
offers the following features:
1. no ambiguity;
2. makes validation easier, at low cost;
3/23/2006 102 Version 2.0

3. reduces the time-to-market;
4. readable by experts of the application domains;
5. easily understandable by implementers;
6. translates easily into any programming language;
7. supports XML notation.
8.
DEL_RSQ_3_1 Architecture and Interface Specifications
• TCAP : The overall objective of Transaction Capabilities (TC, which comprises
TCAP and the underlying ISP) is to provide the means for the transfer of
information between nodes, and to provide generic services to applications, while
being independent of any of these. TCAP itself is structured itself into 2
sublayers: the component sublayer, which deals with individual actions or data
like the MSD, called components and the transaction sublayer, which deals with
the exchange of messages containing components between two TC-users which
are here the IVS and the PSAPs.
Transaction
• OTID
• DTID
• InvokeID
TCAP Message
Component
• Component type
• Operation code
• Component
T1 C1 C2 Cn
Protocol stack overview
The protocol stack described above is based on the GSM standards which is the most
appropriate candidate to allow a PAN–European emergency call service. The USSD is
used to have a session-oriented connection to cope with the real-time & network
acknowledgement needs and allow a fast deployment across Europe.
The transport and the payload are done by a transaction-component message encoded
with the Abstract Syntax Notation (ASN.1). The transaction identifies the
communication between the vehicle and the PSAP at the transport level. The component
identifies the payload information which is related to minimum set of data (MSD) and its
acknowledgement (ACK, EOS) at the application level.
The “eCAll app” handles transaction-component messages on both sides (vehicle –
PSAP). The implementation of the “eCALL app” on each side could be completely
different but MUST respect the eCallMsg as defined by the ASN.1. This allows different
encoder-decoders which can support background compatibility and extensibility on both
sides.
3/23/2006 103 Version 2.0

eCall operation overview
DEL_RSQ_3_1 Architecture and Interface Specifications
A TCAP transaction is initialised between the PSAP & the IVS during the eCall process
in order to identify clearly the eCall dialogue operations : sendMSD, ackMSD, eosMSD
into an PAN European USSD session supported by the GSM & 3GPP. This TCAP
transaction is specific to RESCUE at application level and has no relation with
the USSD TCAP transaction.
The sendMSD operation uses the component part of the TCAP protocol to send the
minimum set of data (MSD) to the PSAP.
The ackMSD & eosMSD operations are simple acknowledgement of the eCall process
without component part sent from the PSAP to the IVS in the same transaction of the
sendMSD operation.
ASN.1 ECALLMsg overview
The header of the eCallMsg in his abstract notation (ASN.1) form is represented below:
-- ********************************************************
-- * ASN.1 Emergency CALL DATA GST RESCUE
-- ********************************************************
ECALLMsg DEFINITIONS -- OID to be associated --
AUTOMATIC TAGS ::=
BEGIN
IMPORTS
Begin, End, Continue, Abort
FROM TCAPMessages {itu-t recommendation q 773 modules(2)
messages(1) version3(3)};
-- defined in ITU-T Rec. Q.773 (06/1997) (For reference only)
-- Transaction PDUs (Transport)
ECALLMsgType ::= CHOICE {
begin [APPLICATION 2] Begin{Invokable,Returnable},
end [APPLICATION 4] End{Invokable,Returnable},
continue [APPLICATION 5] Continue{Invokable,Returnable}
}
-- invokable operation table: MSD,FSD,...
Invokable OPERATION ::= {sendMSD, ... -- extensible --}
-- returnable operation table: ackMSD,eosMSD,...
Returnable OPERATION ::= {ackMSD | eosMSD, ... -- extensible --}
END
Class of services
There are four classes of service in the transaction-component messages defined above:
Class 1 - Both success and failure are reported
3/23/2006 104 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Class 2 - Only failures are reported
Class 3 - Only success is reported.
Class 4 - Nothing is reported
The eCallMsg Abstract Syntax Notation described here handles these four classes.
The eCALL definition and implementation in the GST RESCUE copes with Class 3
corresponding to E-Merge messages definition & conclusions. The TCAP
ECALLMsgType in RESCUE implementation use only the [Begin, End, Continue]
transactions to allow a thin PAYLOAD layer.
Transaction PDU description
The transaction handles the dialogue between parties (Vehicle – PSAP) by exchanging a
set of components which can be for example the MSD. The Transaction part is the
essential part of the RESCUE protocol because it allows an unique identification of an
eCALL message.
The IVS (in-vehicle system) is referenced here as the producer of the data emergency
call. The IVS then initiates the transaction with an “origin transaction ID” (OTID) and
the consumer which is the PSAP replies to the IVS transaction with a “destination
transaction ID” (DTID).
A transaction ID is an identifier composed as the following set of elements in order to
have a unique transaction ID for the producer and for the consumer. In that sense, the
eCall message is unique.
The “ENTITY_TYPE” identify the type of producer or consumer. There are operational
“ENTITY_TYPE” : (“O”) and test “ENTITY_TYPE” (“T”).
Element
Producer = In vehicle system (IVS)
Value
ENTITY_TYPE - car (“O”)
- truck (“O”)
- public transport (“O”)
- carTest (“T”)
- …
ENTITY_INSTANCE - subpart of the VIN
- IMEI
TRANSACTION_NUMBER Unique number (0..127)
Consumer = PSAP
Element Value
3/23/2006 105 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
ENTITY_TYPE - PSAP 1(“O”)
- EA (“O”)
- EATest (“T”)
ENTITY_INSTANCE
…
- PSAP ID
- Fixed Phone number
TRANSACTION_NUMBER - Unique number (0..127)
Table 37 – Transaction ID elements
There is one transaction per eCall process. The eCall messages (SendMSD, AckMSD,
EosMSD) are part of the same transaction which is identify by the couple (OTID,DTID)
The dialogue flow of the one eCall process for sending the minimum set of data (MSD) ,
waiting the acknowledgement & the end of service between IVS & PSAP is represented
below:
IVS PSAP
MSD:BeginTrans (otid=k)
ContinueTrans (otid=j, dtid=k):ACK
End Trans (otid=j, dtid=k): EOS
• “Begin trans” begins the dialogue:
The MSD is sent.
• During the dialogues
“ContinueTrans” are sent in both
directions: PSAP acknowledgement
to Vehicle
• End message closes the dialogue:
EOS is sent to IVS by PSAP
• OTID identifies the dialogue for the
producer of the transaction (IVS)
• DTID identifies the consumer
(PSAP)
Figure 36 – eCall transaction
The transaction container for the eCALLmsg is represented in the table [d1] below :
3/23/2006 106 Version 2.0

Field Name Description Value
OrigTransactionID Origin Transaction ID :
producer of the
transaction (OTID)
DestTransactionID Destination Transaction
ID: consumer of the
transaction
(DTID)
eCALLMsgType Operations
BEGIN,
CONTINUE
END
DEL_RSQ_3_1 Architecture and Interface Specifications
Entity Type +
Entity instance +
Unique number
Entity Type +
Entity instance +
Unique number
sendMSD
ackMSD
eosMSD
Table 38 – Transaction container
Component PDU description
The TCAP component is specified in the ECALLMsgType . Corresponding to the eCall
dialogue, an invoke specify the type of the component : MSD, FSD by the IVS
(producer). The PSAP or service provider replies with a returnable component: ACK,
EOS in order to acknowledge the invoke sended by the IVS. Intermediary results are set
with returnable “ResultNotLast” component. The normal termination stand for a
returnable “ResultLast” component which inform the IVS of the “end of service”.
Field Name Description Value
Component This is the component Invoke
operation
returnable.
invokable,
returnResult
returnResultNotLast
Invokable: sendMSD, sendFSD,…
Returnable: ackMSD, eosMSD
Operation sendMSD To send the MSD from ARGUMENT MSD
the IVS to the PSAP
RETURN RESULT FALSE
CODE local:0
Operation ackMSD To acknowledge the CODE local:1
MSD to the IVS
Operation eosMSD To acknowledge the
“end of service” to the
IVS
Table 39 – PDU Component
CODE local:2
3/23/2006 107 Version 2.0

Service access point between GSM and USSD
DEL_RSQ_3_1 Architecture and Interface Specifications
The service is handle by an AT command on handset side (GSM phase 2+ compliant).
Primitive Description
AT+CUSD [=n [,str [,dcs]]]
0: disable...
1: enable...
... unsolicited USSD string
result code
2: cancel session
cell broadcast data coding scheme
(see GSM 03.38 section 4)
Service access point between USSD and transaction part
The service is handled by the eCALLapp application by describing these primitives.
Primitive Description
Primitive Description
TR-Begin Request – Indication
Initiate the dialogue with a new transaction OTID
TR-Continue Request – Indication
3/23/2006 108 Version 2.0

TR-End Request – Indication
Close the transaction
DEL_RSQ_3_1 Architecture and Interface Specifications
Service access point between transaction part and component part
The service is handled by the eCALLapp application by describing these primitives.
Primitive Description
Primitive Description
CP-attach Attach the component to the initiated transaction.
The component is build in separate abstraction in
order to allow extension like SAML authentication
CP-detach Detach the component from the selected transaction
in order to retrieve component fields and present
them into the appropriate format like XML
6.4.5 Message Structure
The specification of the minimum set of data was created by the emergency agencies that
participated in the E-MERGE project [16]. These specifications were set on the basis of
the information the emergency agencies would need to make a correct response and to
speed up the response time. The definition of the MSD was made in close co-operation
with the vehicle makers. The minimum set of data has been coded using the Abstract
Syntax Notation of the eCallMsg protocol. The minimum set of data consists of the
following information that will be forwarded, together with the voice call, to the PSAP
operator when receiving an in-vehicle eCall:
• "When" via time stamp;
• "Where" via precise locations (e.g. satellite positions including the direction of
driving);
• “Who" via vehicle description (caller line identification [CLI], colour, make and
model including, if possible the vehicle identification number, VIN);
• "Where to obtain more information" via service provider identifier (IP address,
including for example telephone number and country code); and
• "How severe" via eCall qualifier (source of the trigger – manual or automatic
including what type of sensors or, if available, the number of sensors).
The minimum set of data makes it possible for the PSAP operator to respond to the
eCall even without the voice connection. It was requested by the PSAP operators that at
least two sensors should be activated and send information to the PSAP before they deal
with the call as a silent call. The minimum set of data is critical for supplying the correct
service to the crash-site and to speed up the response. It is generally expected by the
PSAPs that the response time can be improved by 5-10% when this information is
available at the PSAP immediately after the crash.
3/23/2006 109 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Minimum Set of Data
This sub-paragraph describes the minimum set of data [9] that must be sent from the
vehicle in case of an emergency call. This data is to be sent from the vehicle via the
Telecom operator using different data transmission ways to the PSAP. The information
elements in the minimum set of data have been selected on the basis of their relevance in
an emergency rescue situation.
The following information elements are of interest in an emergency situation. These
information elements are specified in the component part of the eCallMsg Abstract
Syntax Notation according to the GST OS RESCUE protocol stack definition.
The field “parameter” of the component part of the eCallMsg defines the information
elements described below.
Information Element Description
EntityType
CLI
Unit 3 Not Applicable
Description
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 4 1Character
Unit Not Applicable
Description
3 As it is used by ASN.1
4 The actual length will be calculated dynamically by ASN.1
Type of the Entity : Car, Test_Car,
EA, Test_EA...
SIZE (1) ENUMERATED
car(0), public vehicle
truck(1), truck
publicTransport(2), Public
transport
ev(3), Emergency vehicle
psap1(4), Public safety answering
point
ea(5), Emergency service
pS(6), Private Service
car_test(7), simulated crash
ea_test(8), simulated Emergency
service
..., extensible
Phone Number without the
beginning “+” character (E164
address)
3/23/2006 110 Version 2.0

Information Element Description
CCID
GPS Position Latitude
GPS Position Longitude
Direction of travel
(heading versus)
Triggers activated
DEL_RSQ_3_1 Architecture and Interface Specifications
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 16 Characters
Unit Not Applicable
(SIZE (2..15)) (FROM
("0".."9"|".")
Description Sim Card Identification Code
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 25 Bytes
Unit milliarcseconds
(SIZE(1..25))(FROM("0".."9")|("
A".."Z"))
Description WGS84 5 - accuracy 0.03 meter
Source ASN.1 type INTEGER
Source ASN.1 range
or defined values
Length upper bound 4 Bytes
-324,000,000..324,000,000
Unit milliarcseconds
Description WGS84 - accuracy 0.03 meter
Source ASN.1 type INTEGER
Source ASN.1 range
or defined values
Length upper bound 4 Bytes
Unit degrees / 15
Description
5 Encoding taken from GTP Specifications
Source ASN.1 type INTEGER
Source ASN.1 range
or defined values
-648,000,000..648,000,000
Average of latest 3 GPS positions,
accuracy 15 degrees
0..360
Length upper bound 1 Byte
Unit Not Applicable
Description Number of triggers activated
Source ASN.1 type INTEGER
3/23/2006 111 Version 2.0

Information Element Description
VIN number
Vehicle Make
Vehicle Model
Vehicle Colour
Which triggers are
activated
DEL_RSQ_3_1 Architecture and Interface Specifications
Source ASN.1 range
0..31
or defined values
Length upper bound 1 Byte
Unit Not Applicable
Description Vehicle Identification Number
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 17 Bytes
Unit Not Applicable
SIZE (17) (FROM
("0".."9"|"A".."Z"))
Description Vehicle Manufacturer
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 20 Bytes
Unit Not Applicable
(SIZE(1..20))(FROM("0".."9")|("
A".."Z")|(” “))
Description Vehicle Model Descriptor
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 20 Bytes
Unit Not Applicable
(SIZE(1..20))(FROM("0".."9")|("
A".."Z")|(” “))
Description Colour of the vehicle
Source ASN.1 type IA5string
Source ASN.1 range
or defined values
Length upper bound 20 Bytes
Unit Not Applicable
Description
Source ASN.1 type SEQUENCE
(SIZE(1..20))(FROM("0".."9")|("
A".."Z")|(” “))
Which sensors have reached
threshold value and activated its
trigger
3/23/2006 112 Version 2.0

Information Element Description
Timestamp
Service Provider toll free
number (optional)
Service Provider IP
Address (optional)
Source ASN.1 range
or defined values
DEL_RSQ_3_1 Architecture and Interface Specifications
Length upper bound 18 Bytes
Unit Seconds
Description
Source ASN.1 type INTEGER
Source ASN.1 range
or defined values
Length upper bound 4 Bytes
SIZE (0..6) OF TriggerType
ENUMERATED{
fc1(0), -- Front crash sensor 1
fc2(1), -- Front crash sensor 2
rc(2), -- Rear crash sensor
sc(3), -- Side crash sensor
srs(4), -- Airbag sensor
ke(5), -- Kinetic energy
absorbed by the impacted vehicle
ro(6) – Rollover sensor
... -- extensible
Timestamp of incident event,
UTC time. Seconds since 1970.
(This means that this data type is
valid until approximately year
2100)
0.. 4294967295
Unit Not Applicable
Description
Source ASN.1 type IA5String
Source ASN.1 range
or defined values
Length upper bound 16 Bytes
Unit Not Applicable
Description
Source ASN.1 type SEQUENCE
Phone Number of the Service
Provider (if the driver is a
subscriber) without the beginning
“+” character, for language
assistance services
(SIZE(2..15)) (FROM ("0".."9"))
OPTIONAL
Service Provider IP Address to
allows the PSAP1 to request
Additional Data from the Service
Provider itself
3/23/2006 113 Version 2.0

Information Element Description
User Country Code
(optional)
Source ASN.1 range
or defined values
DEL_RSQ_3_1 Architecture and Interface Specifications
Length upper bound 12 Bytes
Unit Not Applicable
Description
Source ASN.1 type IA5String
Source ASN.1 range
or defined values
Length upper bound 2 Bytes
SIZE(4) OF INTEGER (0..999))
OPTIONAL
2 letter country code of the vehicle
base on ISO-3166
(SIZE (2)) (“A”..”Z”)
OPTIONAL
Table 40 – Minimum Set of Data – Information Elements Definition
Abbreviated trigger Full trigger name
FC1 Front crash sensor 1
FC2 Front crash sensor 2
RC Rear crash sensor
SC Side crash sensor
SRS Airbag sensor
KE Kinetic energy absorbed by the impacted vehicle
Table 41 – Different triggers Definition
Priority
Depending on the carrier (SMS, GPRS etc) used for sending the information elements
the available amount of data will vary and hence there is a need for prioritisation between
the information elements to make sure that the most important data is sent. When the
data limit is reached the remaining information elements will not be considered. The
priority of the data decided by the E-MERGE [9] consortium is as follows:
1. GPS Position
2. Direction of travel
3. Number of triggers of the call
4. Colour, make, model of the vehicle
5. Which sensors are triggered: airbag, roll-over, front crash, side crash or rear crash
sensor
6. Time stamp of the event
3/23/2006 114 Version 2.0

MSD component part of the sendMSD invokable operation
DEL_RSQ_3_1 Architecture and Interface Specifications
The following information is an abstract of ASN.1 script which describes the sendMSD
operation with the MSD component:
Invokable OPERATION ::= {sendMSD, ... -- extensible --} --
invokable operation table: MSD,...
-- invokable OPERATION
sendMSD OPERATION ::= { -- Invoke done by the public vehicle to the
emergency service
ARGUMENT MSD -- Minimum set of data component
RETURN RESULT FALSE
CODE local:0 -- MSD Invoke operation
}
MSD ::= SEQUENCE {
-- Year + Month + DAY + Hour + Minutes + Seconds in E-MERGE MSD
timestamp Timestamp,
-- WGS84-POSITION definition for Current best available position
wgs84-position SEQUENCE {
longitude INTEGER, -- range :-
648,000,000..648,000,000
latitude INTEGER, -- range :-
324,000,000..324,000,000
direction-of-travel INTEGER, -- range : 0..360
... -- extensible for further
needs like GALILEO
},
ccid IA5String(SIZE (25)) (FROM ("0".."9"|"A".."Z"))
OPTIONAL,
triggers-activated INTEGER, -- range 0..31
-- Vehicule description
vin-number IA5String(SIZE (17)) (FROM
("0".."9"|"A".."Z")|(” “)) OPTIONAL,
vehicle-make IA5String(SIZE (20)) (FROM
("0".."9"|"A".."Z")|(” “)) OPTIONAL,
vehicle-model IA5String(SIZE (20)) (FROM
("0".."9"|"A".."Z")|(” “)) OPTIONAL,
vehicle-colour IA5String(SIZE (20)) (FROM
("0".."9"|"A".."Z")|(” “)) OPTIONAL,
-- activated triggers list
activated-triggers SEQUENCE SIZE (0..6) OF TriggerType,
-- Service provider informations
sp-toll-free-number IA5String(SIZE(2..15)) (FROM ("0".."9")), --
toll free phone number
sp-IP-address SEQUENCE SIZE(4) OF INTEGER (0..999) OPTIONAL,
-- User country code information
user-country-code IA5String(SIZE(2))(FROM ("A".."Z")) OPTIONAL,
-- MSD extensible for futur information elements
3/23/2006 115 Version 2.0

}
...
Timestamp ::= INTEGER(0..4294967295)
DEL_RSQ_3_1 Architecture and Interface Specifications
TriggerType ::= ENUMERATED{
fc1(0), -- Front crash sensor 1
fc2(1), -- Front crash sensor 2
rc(2), -- Rear crash sensor
sc(3), -- Side crash sensor
srs(4), -- Airbag sensor
ke(5), -- Kinetic energy absorbed by the impacted
vehicle
...
}
ackMSD & eosMSD returnable operation
The following information is an abstract of ASN.1 script which describes the ackMSD &
eosMSD operation
-- returnable operation table: ackMSD,eosMSD,...
Returnable OPERATION ::= {ackMSD | eosMSD, ... -- extensible --}
-- ackMSD Response done by emergency service to the public vehicle
ackMSD OPERATION ::= {
CODE local:1 -- MSD
acknowledgement code
}
-- eosMSD Response done by emergency service to the public vehicle
eosMSD OPERATION ::= {
CODE local:2 -- End of
service code for MSD transaction
}
6.4.6 API Specification
Class Diagrams Elements::CI-PV-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link to object Communication Infrastructure PV
Class Diagrams Elements::CI-PV-Interface Interfaces
Method Type Notes
EstablishVoiceCall () public: void
3/23/2006 116 Version 2.0

SendData () public: void
DisconnectVoiceCall () public: void
CheckIfDataHasBeenSent () public: void
CheckConnectionStatus () public: void
CloseDataCall () public: void
6.4.7 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
sd UC RSQ 001 - PV - Emergency Data Message Sending
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
SendData
Communication
Infrastructure PV
(from Entities.RSQ)
Figure 37 - Sequence Diagram showing PV - Emergency Data Message Sending
Interaction Name Interaction Description IP-level?
PV – Emergency Data
Message Sending
This interaction describes
how MSD are sent to the
PSAP1 for an eCall.
Table 42 - Descriptions of Interactions for PV - Emergency Data Message Sending
ID Message From Object To Object Notes
1 SendData Telematics
Control Unit
(TCU-PV)
2 Communicatio
n Infrastructure
PV
Communicatio
n Infrastructure
PV
Telematics
Control Unit
(TCU-PV)
Table 43 - PV - Emergency Data Message Sending Messages
3/23/2006 117 Version 2.0

6.4.8 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 38 - State Chart Diagram showing PV - Emergency Data Message Sending
Lifecycle Name Lifecycle Description IP-level?
PV – Emergency Data
Message Sending
This lifecycle shows the
MSD sending from the
Public Vehicle to the
PSAP1.
Table 44 - Descriptions of Lifecycles for PV - Emergency Data Message Sending
3/23/2006 118 Version 2.0

Chapter 7 - PSAP ECALL
DEL_RSQ_3_1 Architecture and Interface Specifications
7.1 UC RSQ 002 – UC RSQ 003 – PSAP – Emergency Data
Visualisation
7.1.1 Introduction
This collaboration illustrates the process of visualisation of Emergency Data at PSAP1 or
PSAP2. Guidelines for data visualisation at PSAP1 operator side are provided at
paragraph 19.4.
Figure 39 – Collaboration – PSAP Emergency Data Visualisation
7.1.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
3/23/2006 119 Version 2.0

7.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 40 – Use Case – PSAP Emergency Data Visualisation
Figure 41 - Class Diagram PSAP Emergency Data Visualisation
3/23/2006 120 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Interface Name Interface Description IP-level?
I-
PSAPEmergencyDataVisualisatio
n
This interface provides to capability to
format and show all relevant incident
data and the location on a map to the
operator at PSAP1 or PSAP2
Table 45 - Descriptions of Interfaces for PSAP Emergency Data Visualisation
7.1.4 API Specification
Class Diagram Elements::I-PSAPEmergencyDataVisualisation
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
• Association link to object Public Service Access Point 1 (PSAP1)
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagram Elements::I-PSAPEmergencyDataVisualisation Interfaces
Method Type Notes
setIncidentLocation () public: void
setPriorPosition () public: void
setDeadReckoningPosition () public: void
buildNewMap () public: void
ProcessXMLMessageWithStyleSheet () public: void
StartXMLViewer () public: void
StartMapViewer () public: void
3/23/2006 121 Version 2.0

7.1.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 42 - Sequence Diagram showing PSAP Emergency Data Visualisation
Interaction Name Interaction Description IP-level?
PSAP – Emergency Data
Visualisation
This diagram describes the process of
decoding and formatting the received e-Call
Data and then start a Data Viewer and a Map
Viewer
Table 46 - Descriptions of Interactions for PSAP Emergency Data Visualisation
ID Message From Object To Object Notes
1 decode ECALL Data Public Service Access
Point 1 (PSAP1)
2 Extract ECALL
Position
3 convert coordinates
to map coordinates
4 Merge Location Map
and Incident
coordinates
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
5 Start XML-Viewer Public Service Access
Point 1 (PSAP1)
6 start MAP-Viewer
with composed map
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
PSAP1 Operator
PSAP1 Operator
3/23/2006 122 Version 2.0

7.1.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 47 - PSAP Emergency Data Visualisation Messages
Figure 43 - Activity Diagram showing PSAP Emergency Data Visualisation
Lifecycle Name Lifecycle Description IP-level?
PSAP Emergency Data
Visualisation
This lifecycle shows the different states of the
almost linear process of showing e-Call data
to the operator.
3/23/2006 123 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Table 48 - Descriptions of Lifecycles for PSAP Emergency Data Visualisation
7.2 UC RSQ 002 – PSAP - Emergency Data Handling
7.2.1 Introduction
This collaboration illustrates the process of handling (parsing, recognizing, …) of
Emergency Data at PSAP1 or PSAP2.
Figure 44 – Collaboration – PSAP - Emergency Data Handling
7.2.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 45 – Use Case – PSAP - Emergency Data Handling
3/23/2006 124 Version 2.0

7.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 46 - Class Diagram PSAP - Emergency Data Handling
Interface Name Interface Description IP-level?
I- Emergency Data Handling This internal interface provides the
capability to convert the coded eCall
Message to a readable, parseable or
processable format.
Table 49 - Descriptions of Interfaces for PSAP - Emergency Data Handling
7.2.4 API Specification
Class Diagram Elements::I-EmergencyDataHandler
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
• Association link from object Public Service Access Point 1 (PSAP1)
Class Diagram Elements::I-EmergencyDataHandler Interfaces
Method Type Notes
3/23/2006 125 Version 2.0

getPosition () public: void
decodeMSD () public: void
getVehicle () public: void
getIncidentDetails () public: void
getDriverDetails () public: void
7.2.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 47 - Sequence Diagram showing PSAP - Emergency Data Handling
Interaction Name Interaction Description IP-level?
PSAP - Emergency Data
Handling
This interaction diagram shows all the
necessary steps to decode the binary MSD
data and format it in a usable format.
Table 50 - Descriptions of Interactions for PSAP - Emergency Data Handling
3/23/2006 126 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
ID Message From Object To Object Notes
1 Check Header Public Service Access
Point 1 (PSAP1)
2 Check Length Public Service Access
Point 1 (PSAP1)
3 Check Checksum Public Service Access
Point 1 (PSAP1)
4 GetMessageFlags Public Service Access
Point 1 (PSAP1)
5 GetVehicleData Public Service Access
Point 1 (PSAP1)
6 GetPosition Public Service Access
Point 1 (PSAP1)
7 GetVehicleFlags Public Service Access
Point 1 (PSAP1)
8 GetPearlChain Public Service Access
Point 1 (PSAP1)
9 GetAdditionalData Public Service Access
Point 1 (PSAP1)
10 FormatXML Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Table 51 - PSAP - Emergency Data Handling Messages
3/23/2006 127 Version 2.0

7.2.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 48 - Activity Diagram showing PSAP - Emergency Data Handling
3/23/2006 128 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Lifecycle Name Lifecycle Description IP-level?
PSAP - Emergency Data
Handling
This lifecycle shows the different states of the
almost linear process of processing all the
relevant data fields.
Table 52 - Descriptions of Lifecycles for PSAP - Emergency Data Handling
7.3 UC RSQ 003 – PSAP2 - Emergency Data Retrieving from
PSAP1
7.3.1 Introduction
This collaboration illustrates the process of retrieving the already prepared incident data
from PSAP1 in order to start following actions with the incident.
Figure 49 – Collaboration – PSAP2 - Emergency Data Retrieving from PSAP1
7.3.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
3/23/2006 129 Version 2.0

7.3.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 50 – Use Case – PSAP2 - Emergency Data Retrieving from PSAP1
Figure 51 - Class Diagram PSAP2 - Emergency Data Retrieving from PSAP1
Interface Name Interface Description IP-level?
I-ECALLDataStorage This interface provides the capability to
store the e-Call data at both PSAP1 and
PSAP2 sides.
I-
PSAP2ToPSAP1Communication
This interface provides the capability to
retrieve the e-Call data from the PSAP1
after alerting the PSAP2
Table 53 - Descriptions of Interfaces for PSAP2 - Emergency Data Retrieving from PSAP1
7.3.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended B2B communications protocol stack.
The following picture illustrates the protocol stack adopted for the “PSAP2 – Emergency
Data Retrieving from PSAP1” Message exchange.
3/23/2006 130 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 52 – Protocol Stack - PSAP2 - Emergency Data Retrieving from PSAP1
7.3.5 Message Structure
Accordingly with GST RESCUE requirements defined into [8] the PSAP 2 MUST
receive at least the same amount of data received by PSAP1 plus any possible
information that the PSAP1 operator kept by the voice discussion with the driver (if he is
able to speak).
If the driver is a subscriber of a Service Provider, which has the capability to make the
FSD available for the PSAP1, these data SHOULD enrich the amount of information to
be received by the PSAP2 as well.
Moreover if any other additional information is available at PSAP1, also these data
SHOULD be sent to the PSAP2.
The structure of the message to sent on board MUST reflects these possibilities, by
defining elements sections in the “Body” of the SOAP message which include the
information to be sent.
These sections are:
• Incident Info: which contains elements related to the PSAP2 rescue handling
procedures, such as a unique incident identifier of the “rescue file”. It is
MANDATORY.
3/23/2006 131 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• MSD: which contains the Minimum Set of Data received by PSAP1 (please see
par. 6.4.5). For the usage to be made by the Emergency Service Personnel the
priority assigned to each information element included in the MSD is a little bit
different. For instance when a PSAP has the capability to access DB for getting
vehicle information the VIN number becomes an important data to have, whilst
it is quietly incomprehensible for the ESV personnel, unlike of make, model and
colour information. MSD element is MANDATORY.
• FSD: which contains any available information provided by the related Service
Provider. It is OPTIONAL.
• AddInfo: which contains any possible extra information added by the PSAP2
operator to the “incident file”. It is OPTIONAL.
The following table describes the structure of the SOAP Body Element of the message.
Element Sub-Element Description Data Type
IncidentInfo
MSD
IncidentID
MsgTimestamp
CLI
GPS Position
Latitude
GPS Position
Longitude
MANDATORY - Unique identifier
of the Incident process
string
MANDATORY - Timestamp of
when data have been sent to the ESV datetime
MANDATORY - Phone Number of
the caller
MANDATORY - WGS84 Latitude
Value * 10 7
MANDATORY - WGS84 Longitude
Value * 10 7
string
integer
integer
Direction MANDATORY - Direction of travel integer
Triggers Activated
VIN
Vehicle Make
Vehicle Model
Vehicle Colour
Which triggers
activated
Timestamp
MANDATORY - Numbers of
activated triggers
OPTIONAL - Vehicle Identification
Number
MANDATORY - Vehicle
Manufacturer
MANDATORY - Vehicle Model
Descriptor
MANDATORY - Colour of the
Vehicle
This element includes the list of the
triggered sensors formatted as subelements,
following this scheme:
value
MANDATORY - Timestamp of the
incident event
integer
string
string
string
string
string
datetime
3/23/2006 132 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Element Sub-Element Description Data Type
SP toll free
number
SP IP Address
AddInfo AddInfoRaw
OPTIONAL - Phone number of the
Service Provider
OPTIONAL - SP IP Address for
FSD access
OPTIONAL – Since the additional
those could be added by the PSAP2
operator are extremely variable, the
Additional Information are sent as a
free text (it is also possible to send
XML parsed Additional information).
Table 54 – SOAP Body Element structure
string
string
string
Additional Information that could be included within the message could be very vary,
since this information element could contain additional information kept by the PSAP1
operator during the voice call with the driver, or FSD retrieved by the reference Service
Provider.
The additional information retrieved by the SP could contain:
• Bio-medical data of the driver (e.g. blood group, particular diseases, …)
• A more detailed situation about the status of the sensors (which airbags are
activated, the number of the occupants, …)
• Any possible other useful information about the vehicle (e.g. the fuel type)
• …
Message Encoding
The SOAP 1.2 encoded message is represented as follows.
value
value
value
value
value
value
value
value
value
value
value
3/23/2006 133 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
value
value
value
value
value
value
text
7.3.6 API Specification
Class Diagram Elements::I-ECALLDataStorage
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
• Association link from object Public Service Access Point 1 (PSAP1)
Class Diagram Elements::I-ECALLDataStorage Interfaces
Method Type Notes
insertIncidentInDB () public: void
StoreAdditionalPSAPData () public: void
StoreAdditionalSPData () public: void
getIncidentDataFromDB () public: void
Class Diagram Elements::I-PSAP2ToPSAP1Communication
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagram Elements::I-PSAP2ToPSAP1Communication Interfaces
Method Type Notes
requestECALLData (int) public: void param: CLI [ int - in ]
3/23/2006 134 Version 2.0

finishIncident (int, int) public: void
7.3.7 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
param: status [ int - in ]
param: CLI [ int - in ]
Figure 53 - Sequence Diagram showing PSAP2 - Emergency Data Retrieving from PSAP1
Interaction Name Interaction Description IP-level?
Emergency Data Retrieving
from PSAP1
This interaction diagram show the general
process of alerting the PSAP2 about a new
incident and the requesting of the e-Call data
from the PSAP1
Table 55 - Descriptions of Interactions for PSAP2 - Emergency Data Retrieving from PSAP1
ID Message From Object To Object Notes
1 diverted emergency
Voice Call
Public Service Access
Point 1 (PSAP1)
2 extract CLI Public Service Access
Point 2 (PSAP2)
3 Request ECALL-Data
from PSAP1
4 return ECALL Data
from PSAP1
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 2 (PSAP2)
Table 56 - PSAP2 - Emergency Data Retrieving from PSAP1 Messages
3/23/2006 135 Version 2.0

7.3.8 Lifecycles
ad PSAP2 Emergency Data retrieving from PSAP1
Start of Process
PSAP2 alerted by
PSAP1
Requesting eCall Data
from PSAP1
Data available?
no
No eCall Data available
yes
DEL_RSQ_3_1 Architecture and Interface Specifications
Retrieve Data from PSAP1 validate e-Call data
no
maximum number of retries reached?
Data valid?
Emergency Data Available at PSAP2
Figure 54 - Activity Diagram showing PSAP2 - Emergency Data Retrieving from PSAP1
Lifecycle Name Lifecycle Description IP-level?
Emergency Data Retrieving
from PSAP1
3/23/2006 136 Version 2.0
no
yes
This diagram show the different workflows
for retrieving e-Call data from PSAP1 to
PSAP2
Table 57 - Descriptions of Lifecycles for PSAP2 - Emergency Data Retrieving from PSAP1

7.4 UC RSQ 002 – PSAP1 – EOS
DEL_RSQ_3_1 Architecture and Interface Specifications
7.4.1 Introduction
When PSAP1 operator close the voice communication link with the PV driver, the
PSAP1 system, automatically send an EOS (End Of Service) message to the public
vehicle.
At the same time, when the PV Client System receives that kind of Message the
communication link with the PSAP1 is closed and message is displayed for the driver.
Figure 55 – Collaboration – PSAP1 - EOS
7.4.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 56 – Use Case – PSAP1 – EOS
3/23/2006 137 Version 2.0

7.4.3 Interfaces
cd EOS
DEL_RSQ_3_1 Architecture and Interface Specifications
Public Service
Access Point 1
(PSAP1)
(from Entities.RSQ)
«interface»
Class Diagramm Elements::I-SendEOS
+ sendEOSMessage(char) : void
Figure 57 - Class Diagram for PSAP1 – EOS
Interface Name Interface Description IP-level?
SendEOS This interface provides the capability to send
and End-Of-Service from the PSAP1 to the
Vehicle
Table 58 - Descriptions of Interfaces for PSAP1 – EOS
7.4.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-PSAP communications
protocol stack. The following picture illustrates the protocol stack adopted for the
“PSAP1 – EOS” Message exchange.
3/23/2006 138 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 58 – Protocol Stack – PSAP1 - EOS
As introduced (see par. 6.4.4), a TCAP transaction is initialised between the PSAP & the
IVS during the eCall process in order to identify clearly the eCall dialogue operations :
sendMSD, ackMSD, eosMSD into an PAN European USSD session supported by the
GSM & 3GPP. The sendMSD operation uses the component part of the TCAP protocol
to send the minimum set of data (MSD) to the PSAP.
The ackMSD & eosMSD operations are simple acknowledgement of the eCall process
without component part sent from the PSAP to the IVS in the same transaction of the
sendMSD operation.
More information can be found at paragraph 6.4.4.
The transaction container for the eCALLmsg is represented in the table [d2] below :
Field Name Description Value
OrigTransactionID Origin Transaction Entity Type +
ID : producer of the
Entity instance +
transaction (OTID)
Unique number
DestTransactionID Destination Entity Type +
Transaction ID:
Entity instance +
consumer of the
transaction
Unique number
(DTID)
Transaction Container
3/23/2006 139 Version 2.0

PDU
Component
eCALLMsgType Operations
BEGIN,
CONTINUE
END
DEL_RSQ_3_1 Architecture and Interface Specifications
sendMSD
ackMSD
eosMSD
Table 59 – Transaction container and PDU Component
7.4.5 Message Structure
eosMSD returnable operation
The following information is an abstract of ASN.1 script which describes the eosMSD
operation.
-- returnable operation table: ackMSD,eosMSD,...
Returnable OPERATION ::= {ackMSD | eosMSD, ... -- extensible --}
-- eosMSD Response done by emergency service to the public vehicle
eosMSD OPERATION ::= {
CODE local:2
-- End of service code for MSD transaction
}
7.4.6 API Specification
Class Diagram Elements::I-SendEOS
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
Operation eosMSD
• Association link from object Public Service Access Point 1 (PSAP1)
Class Diagram Elements::I-ECALLDataStorage Interfaces
Method Type Notes
SendEOSMessage (char) public: void
to complete and
conclude the eCall
Transaction
CODE local:2
3/23/2006 140 Version 2.0

7.4.7 Interactions
sd EOS
Public Service
Access Point 1
(PSAP1)
(from Entities.RSQ)
DEL_RSQ_3_1 Architecture and Interface Specifications
EndOfServices
Vehicle
(from Entities.RSQ)
Figure 59 - Sequence Diagram showing PSAP1 – EOS
Interaction Name Interaction Description IP-level?
EOS This sequence shows the process of sending
an End-Of-Service Message to the Vehicle
Table 60 - Descriptions of Interactions for PSAP1 – EOS
ID Message From Object To Object Notes
1 EndOfServices Public Service Access Point 1
(PSAP1)
Table 61 - PSAP1 – EOS Messages
Vehicle
3/23/2006 141 Version 2.0

7.4.8 Lifecycles
ad EOS
e.Call Data retrieved successfully
Vehicle: finish send of
e-Call Data
e-Cal l Data T ransmission
finished at Vehicle
DEL_RSQ_3_1 Architecture and Interface Specifications
Send End-Of-Service to
Vehicle
Data retrieval
finished at PSAP1
Figure 60 - State Chart Diagram showing PSAP1 – EOS
Lifecycle Name Lifecycle Description IP-level?
EOS This diagram shows the process of sending an
end of Service Message from the Vehicle to
the PSAP
Table 62 - Descriptions of Lifecycles for PSAP1 – EOS
3/23/2006 142 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 8 - PSAP RESCUE MANAGEMENT
8.1 UC RSQ 003 - Transmission of Data
8.1.1 Introduction
This collaboration provides the capability to transmit emergency data on board to the
emergency vehicles in order to provide as much information is possible to the
Emergency Service Personnel.
Figure 61 –Transmission of Data (entities involved)
8.1.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 62 - Transmission of Data
3/23/2006 143 Version 2.0

8.1.3 Interfaces
cd UC RSQ 003 - Transmission of Data
Public Service
Access Point 2
(PSAP2)
(from Entities.RSQ)
«interface»
DataTransmssionToEV
+ sendDataToEV() : void
DEL_RSQ_3_1 Architecture and Interface Specifications
Emergency
Vehicle Client
System (CS-EV)
(from Entities.RSQ)
«interface»
DataRetrievalFromPSAP2
+ validatePSAPData() : void
+ sendAcknowledgeToPSAP2() : void
Figure 63 - Class Diagram for Transmission of Data
Interface Name Interface Description IP-level?
DataTransmissionToEV This interface provides the capability to send
a RSQ Message to the EV
DataRetrievalFromPSAP2 This interface provides the capability to
receive a RSQ message from the PSAP2 and
send the acknowledgement
Table 63 - Descriptions of Interfaces for Transmission of Data
8.1.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Service Centre
communications protocol stack. The following picture illustrates the protocol stack
adopted for the “Transmission of Data” Message exchange.
3/23/2006 144 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 64 – Protocol Stack – Transmission of Data
8.1.5 Message Structure
Accordingly with GST RESCUE requirements defined into [8] the ESV MUST receive at
least the same amount of data received by PSAP1 that means that the minimum of
information which could be received by the ESV is represented by the MSD.
If the driver is a subscriber of a Service Provider which has the capability to make the
FSD available for the PSAP1, these data SHOULD enrich the amount of information to
be received by the PSAP2 and ESV as well.
Moreover if any other additional information are available at PSAP2, also these data
SHOULD be sent to the ESV.
The structure of the message to sent on board MUST reflects these possibilities, by
defining elements sections in the “Body” of the SOAP message which include the
information to be sent.
These sections are:
• IncidentInfo: which contains elements related to the PSAP2 rescue handling
procedures, such as a unique incident identifier of the “rescue file”. It is
MANDATORY.
• MSD: which contains the Minimum Set of Data received by PSAP1 (please see
par. 6.4.5). For the usage to be made by the Emergency Service Personnel the
priority assigned to each information element included in the MSD is a little bit
different. For instance when a PSAP has the capability to access DB for getting
vehicle information the VIN number becomes an important data to have, whilst
it is quietly incomprehensible for the ESV personnel, unlike of make, model and
colour information. MSD element is MANDATORY.
3/23/2006 145 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• FSD: which contains any available information provided by the related Service
Provider. It is OPTIONAL.
• AddInfo: which contains any possible extra information added by the PSAP2
operator to the “incident file”. It is OPTIONAL.
The following table describes the structure of the SOAP Body Element of the message.
Element Sub-Element Description Data Type
IncidentInfo
MSD
IncidentID
MsgTimestamp
CLI
GPS Position
Latitude
GPS Position
Longitude
MANDATORY - Unique identifier
of the Incident process
string
MANDATORY - Timestamp of
when data have been sent to the ESV datetime
MANDATORY - Phone Number of
the caller
MANDATORY - WGS84 Latitude
Value * 10 7
MANDATORY - WGS84 Longitude
Value * 10 7
string
integer
integer
Direction MANDATORY - Direction of travel integer
Triggers Activated
VIN
Vehicle Make
Vehicle Model
Vehicle Colour
Which triggers
activated
Timestamp
SP toll free
number
SP IP Address
FSD FSDRaw
MANDATORY - Numbers of
activated triggers
OPTIONAL - Vehicle Identification
Number
MANDATORY - Vehicle
Manufacturer
MANDATORY - Vehicle Model
Descriptor
MANDATORY - Colour of the
Vehicle
This element includes the list of the
triggered sensors formatted as subelements,
following this scheme:
value
MANDATORY - Timestamp of the
incident event
OPTIONAL - Phone number of the
Service Provider
OPTIONAL - SP IP Address for
FSD access
OPTIONAL - Since the Full Set of
Data [9] is extremely variable and it is
strictly dependant by the related
integer
string
string
string
string
string
datetime
string
string
string
3/23/2006 146 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Element Sub-Element Description Data Type
AddInfo AddInfoRaw
Service Provider, FSD are sent as a
free text.
OPTIONAL – Since the additional
those could be added by the PSAP2
operator are extremely variable, the
Additional Information are sent as a
free text (it is also possible to send
XML parsed Additional information).
Table 64 – SOAP Body Element structure
Message Encoding
The SOAP 1.2 encoded message is represented as follows.
string
value
value
value
value
value
value
value
value
value
value
value
value
value
value
value
value
value
text
text
8.1.6 API Specification
Class Diagram Elements::DataTransmssionToEV
3/23/2006 147 Version 2.0

Type: public abstract «interface» Interface
Package : Class Diagram Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagramm Elements::DataTransmssionToEV Interfaces
Method Type Notes
sendDataToEV () public: void
Class Diagram Elements::DataRetrievalFromPSAP2
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
• Association link from object Emergency Vehicle Client System (CS-EV)
Class Diagramm Elements::DataRetrievalFromPSAP2 Interfaces
Method Type Notes
validatePSAPData () public: void
sendAcknowledgeToPSAP2 () public: void
3/23/2006 148 Version 2.0

8.1.7 Interactions
sd UC RSQ 003 - Data Transmission
Public Service
Access Point 2
(PSAP2)
(from Entities.RSQ)
send Data to Rescue Vehicle(data)
send Acknowlegdement
DEL_RSQ_3_1 Architecture and Interface Specifications
Emergency
Vehicle Client
System (CS-EV)
(from Entities.RSQ)
decode Data
Validate data
Figure 65 - Sequence Diagram showing Transmission of Data
Interaction Name Interaction Description IP-level?
Transmission of Data This diagram shows the common process of
sending e-Call Data to the RSQ vehicle
Table 65 - Descriptions of Interactions for Transmission of Data
ID Message From Object To Object Notes
1 send Data to Rescue
Vehicle
Public Service Access
Point 2 (PSAP2)
2 decode Data Emergency Vehicle
Client System (CS-
EV)
3 Validate data Emergency Vehicle
Client System (CS-
EV)
4 send
Acknowlegdement
Emergency Vehicle
Client System (CS-
EV)
Table 66 - Transmission of Data Messages
Emergency Vehicle
Client System (CS-
EV)
Emergency Vehicle
Client System (CS-
EV)
Emergency Vehicle
Client System (CS-
EV)
Public Service Access
Point 2 (PSAP2)
3/23/2006 149 Version 2.0

8.1.8 Lifecycles
ad Data Transmission
Start Sending Data to the RSQ Vehicle
PSAP2: connecting RSQ
Vehicle
Connection successful?
PSAP2: Sending Data
RSQ Vehicle: Retriev ing
Data
RSQ: Vehicle: validate
Data
Data valid?
no
End of Transmission
DEL_RSQ_3_1 Architecture and Interface Specifications
yes
RSQ Vehicle: send
Acknpowledgement back
to PSAP2
Figure 66 - State Chart Diagram showing Transmission of Data
Lifecycle Name Lifecycle Description IP-level?
Transmission of Data This diagram shows the interactions between
the involved parties during a data
3/23/2006 150 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
transmission from PSAP2 to RSQ Vehicle
Table 67 - Descriptions of Lifecycles for Transmission of Data
8.2 UC RSQ 003 – ESV - Emergency Handling Closure
8.2.1 Introduction
This collaboration illustrates the process of finalising the incident handling by sending a
closure message back from the emergency vehicle to the PSAP2.
Figure 67 – Collaboration – ESV - Emergency Handling Closure
8.2.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 68 – Use Case – ESV - Emergency Handling Closure
3/23/2006 151 Version 2.0

8.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 69 - Class Diagram ESV - Emergency Handling Closure
Interface Name Interface Description IP-level?
ESV - Emergency Handling
Closure
This interface describes the capability to
finalise the incident activities at PSAP2
and it is based on a Information Message
from the rescue vehicle back to the
PSAP2
Table 68 - Descriptions of Interfaces for ESV - Emergency Handling Closure
8.2.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Service Centre
communications protocol stack. The following picture illustrates the protocol stack
adopted for the “ESV – Emergency Handling Closure” Message exchange.
3/23/2006 152 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 70 – Protocol Stack - ESV - Emergency Handling Closure
8.2.5 Message Structure
Accordingly with GST RESCUE requirements defined into [8] the ESV MUST
communicate to the PSAP2 the closure of an emergency handling rescue procedure, in
order to let the PSAP2 to allocate the rescue resource to another service.
The structure of the message to sent to the PSAP2 MUST reflects these needs, by
defining elements sections in the “Body” of the SOAP message which include the
information to be sent.
These sections are:
• IncidentInfo: which contains elements related to the PSAP2 rescue handling
procedures, such as a unique incident identifier of the “rescue file” and the
message generation timestamp. It is MANDATORY.
• StatusInfo: which contains information related to the current status of the rescue
procedure (this element, defined as StatusCode is MANDATORY) plus any
other possible message to be included. This last element is OPTIONAL.
The following figure illustrates the structure of the SOAP message.
3/23/2006 153 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 71 – Message Structure
The following table describes the structure of the SOAP Body Element of the message.
Element Sub-Element Description Data Type
IncidentInfo
StatusInfo
IncidentID
MsgTimestamp
StatusCode
StatusMessage
MANDATORY - Unique identifier
of the Incident process
string
MANDATORY - Timestamp of
when data have been sent to the ESV datetime
MANDATORY – Code of an
successful or unsuccessful
completion of the incident
OPTIONAL – a text description of
the status code.
Table 69 – SOAP Body Element structure
Message Encoding
The SOAP 1.2 encoded message is represented as follows.
integer
string
value
value
value
text
3/23/2006 154 Version 2.0

8.2.6 API Specification
Class Diagram Elements::I-PSAP2Communicator
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object Emergency Vehicle Client System (CS-EV)
Class Diagram Elements::I-PSAP2Communicator Interfaces
Method Type Notes
sendMessageToPSAP2 (char) public: void
Class Diagram Elements::I-VehicleManager
Type: public abstract «interface» Interface
Package: Class Diagram Elements
Connections
• Association link to object RSQVehicle
param: XMLMessage [ char - in ]
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagram Elements::I-VehicleManager Interfaces
Method Type Notes
sendMessageToRSQVehicle
(char, int)
public: void
setStatusOfVehicle (int, int) public: void
getAvailableVehicles () public: void
RSQVehicle
Type: public Object
Package: Class Diagram Elements
Connections
param: XMLMessage [ char - in ]
param: VehicleID [ int - in ]
param: StatusID [ int - in ]
param: VehicleID [ int - in ]
3/23/2006 155 Version 2.0

• Association link from interface I-VehicleManager
RSQVehicle Attributes
Attribute Type Notes
status
RSQVehicle Methods
private :
Method Type Notes
DEL_RSQ_3_1 Architecture and Interface Specifications
setVehicleStatus (int) public: void param: status [ int - in ]
getVehicleStatus () public: int
8.2.7 Interactions
Figure 72 - Sequence Diagram showing ESV - Emergency Handling Closure
Interaction Name Interaction Description IP-level?
Emergency Handling
Closure
This interaction show the possible activities at
the PSAP2 after the rescue action has finished
Table 70 - Descriptions of Interactions for ESV - Emergency Handling Closure
3/23/2006 156 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
ID Message From Object To Object Notes
1 Press Button "End of
Incident"
2 send EndOfIncident-
Message
Emergency Service
Person
Emergency Vehicle
Client System (CS-
EV)
3 return Acknowlegde Public Service Access
Point 2 (PSAP2)
4 display Acknowlegde Emergency Vehicle
Client System (CS-
EV)
5 Request Route to
"Home Location"
6 return Route to
"Home Location"
7 Start Routing to
Home-Location
Emergency Vehicle
Client System (CS-
EV)
Public Service Access
Point 2 (PSAP2)
Emergency Vehicle
Client System (CS-
EV)
Emergency Vehicle
Client System (CS-
EV)
Public Service Access
Point 2 (PSAP2)
Emergency Vehicle
Client System (CS-
EV)
Emergency Service
Person
Public Service Access
Point 2 (PSAP2)
Emergency Vehicle
Client System (CS-
EV)
Emergency Vehicle
Client System (CS-
EV)
Table 71 - ESV - Emergency Handling Closure Messages
3/23/2006 157 Version 2.0

8.2.8 Lifecycles
ad Activ ity Diagrams.RSQ
End of rescue action reached
RSQ Vehicle sends
Closure Message to
PSAP2
PSAP2 releases
resources
base station for RSQ vehicle known?
no
yes
DEL_RSQ_3_1 Architecture and Interface Specifications
send route to base station
back to RSQ v ehicle
Start Route guidance and
RSQ Vehicle
Release Rescue Vehilce
and ressourceds
End of rescue action at RSQ Vehicle End of rescue action at PSAP2
Figure 73 - Activity Diagram showing ESV - Emergency Handling Closure
Lifecycle Name Lifecycle Description IP-level?
Emergency Handling
Closure
This diagram shows the process of closing
and finishing the rescue action at PSAP2 and
the RSQ vehicle
Table 72 - Descriptions of Lifecycles for ESV - Emergency Handling Closure
3/23/2006 158 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 9 - PSAP TO VEHICLE COMMUNICATION
9.1 UC RSQ 004 - ESV - Emergency Data Receipt from
PSAP2
9.1.1 Introduction
This collaboration illustrates the process related to the emergency data reception by the
Emergency Service Personnel directly on-board from the PSAP2.
Figure 74 – Collaboration – ESV – Emergency Data Receipt from PSAP2
9.1.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 75 – Use Case - ESV – Emergency Data Receipt from PSAP2
3/23/2006 159 Version 2.0

9.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 76 - Class Diagram for ESV – Emergency Data Receipt from PSAP2
Interface Name Interface Description IP-level?
ITCU-
EVIncomingDataMessage
Detector
IIOD-
EVEmergencyServicePerso
nnelAlert
This interface allows the detecting of an
incoming emergency data message from the
PSAP2 for lately handling.
This interface allows the system to alert the
Emergency Service Personnel onboard of an
incoming emergency data message.
ITCU-EVSetUpVoiceLink This interface provides the capability to
automatically set up a voice connection
between the ESV personnel and the PSAP2
Operator.
Table 73 - Descriptions of Interfaces for ESV – Emergency Data Receipt from PSAP2
9.1.4 Protocol Stack and Specification
The following picture shows the protocol stack for ESV – Emergency Data Receipt from
PSAP2.
3/23/2006 160 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 77 – Protocol Stack – ESV – Emergency Data Receipt from PSAP2
9.1.5 Message Structure
Accordingly with GST RESCUE requirements defined into [8] the ESV MUST receive at
least the same amount of data received by PSAP1 that means that the minimum of
information which could be received by the ESV is represented by the MSD.
If the driver is a subscriber of a Service Provider which has the capability to make the
FSD available for the PSAP1, these data SHOULD enrich the amount of information to
be received by the PSAP2 and ESV as well.
Moreover if any other additional information are available at PSAP2, also these data
SHOULD be sent to the ESV.
The structure of the message to sent on board MUST reflects these possibilities, by
defining elements sections in the “Body” of the SOAP message which include the
information to be sent.
These sections are:
• IncidentInfo: which contains elements related to the PSAP2 rescue handling
procedures, such as a unique incident identifier of the “rescue file”. It is
MANDATORY.
3/23/2006 161 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• MSD: which contains the Minimum Set of Data received by PSAP1 (please see
par. 6.4.5). For the usage to be made by the Emergency Service Personnel the
priority assigned to each information element included in the MSD is a little bit
different. For instance when a PSAP has the capability to access DB for getting
vehicle information the VIN number becomes an important data to have, whilst
it is quietly incomprehensible for the ESV personnel, unlike of make, model and
colour information. MSD element is MANDATORY.
• FSD: which contains any available information provided by the related Service
Provider. It is OPTIONAL.
• AddInfo: which contains any possible extra information added by the PSAP2
operator to the “incident file”. It is OPTIONAL.
The following figure illustrates the structure of the SOAP message.
Figure 78 – Message Structure
The following table describes the structure of the SOAP Body Element of the message.
Element Sub-Element Description Data Type
IncidentInfo
MSD
IncidentID
MsgTimestamp
CLI
GPS Position
Latitude
GPS Position
Longitude
MANDATORY - Unique identifier
of the Incident process
string
MANDATORY - Timestamp of
when data have been sent to the ESV datetime
MANDATORY - Phone Number of
the caller
MANDATORY - WGS84 Latitude
Value * 10 7
MANDATORY - WGS84 Longitude
Value * 10 7
string
integer
integer
Direction MANDATORY - Direction of travel integer
3/23/2006 162 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Element Sub-Element Description Data Type
Triggers Activated
VIN
Vehicle Make
Vehicle Model
Vehicle Colour
Which triggers
activated
Timestamp
SP toll free
number
SP IP Address
FSD FSDRaw
AddInfo AddInfoRaw
MANDATORY - Numbers of
activated triggers
OPTIONAL - Vehicle Identification
Number
MANDATORY - Vehicle
Manufacturer
MANDATORY - Vehicle Model
Descriptor
MANDATORY - Colour of the
Vehicle
This element includes the list of the
triggered sensors formatted as subelements,
following this scheme:
value
MANDATORY - Timestamp of the
incident event
OPTIONAL - Phone number of the
Service Provider
OPTIONAL - SP IP Address for
FSD access
OPTIONAL - Since the Full Set of
Data [9] is extremely variable and it is
strictly dependant by the related
Service Provider, FSD are sent as a
free text.
OPTIONAL – Since the additional
those could be added by the PSAP2
operator are extremely variable, the
Additional Information are sent as a
free text.
Table 74 – SOAP Body Element structure
Message Encoding
The SOAP 1.2 encoded message is represented as follows.
integer
string
string
string
string
string
datetime
string
string
string
string
value
value
3/23/2006 163 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
value
value
value
value
value
value
value
value
value
value
value
value
value
value
value
text
text
9.1.6 API Specification
Class Diagrams Elements.RSQ::CIOD-EVDataMessageParser
Type: public Class
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements.RSQ::CIOD-EVDataMessageParser Attributes
Attribute Type Notes
MSD private : binary
FSD private : binary
Class Diagrams Elements.RSQ::CIOD-EVDataMessageParser Methods
Method Type Notes
ParseIncidentLocation (float, float,
binary)
private: float
param: Longitude [ float - out ]
param: Latitude [ float - out ]
param: MSD [ binary - in ]
3/23/2006 164 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
ParseInvolvedVehicleData (binary) private: float param: MSD [ binary - in ]
ParseAdditionalVehicleData (float,
boolean, binary)
private: float
GenerateMSD_XML () public: void
GenerateFSD_XML () public: void
param: FSDArray [ float - out ]
param: FSDPresent [ boolean - in ]
param: FSD [ binary - in ]
Class Diagrams Elements.RSQ::CTCU-EVDataMessageValidator
Type: public Class
Package : Class Diagrams Elements.RSQ
Connections
• Association link to object Telematics Control Unit (TCU-EV)
Class Diagrams Elements.RSQ::CTCU-EVDataMessageValidator Methods
Method Type Notes
DataMessageValidator
(boolean, binary)
public: void
param: IsValid [ boolean - out ]
param: DataMessage [ binary - in ]
Class Diagrams Elements.RSQ::IIOD-EVEmergencyServicePersonnelAlert
Type: public abstract «interface» Interface
Package : Class Diagrams Elements.RSQ
Connections
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements.RSQ::IIOD-EVEmergencyServicePersonnelAlert
Attributes
Attribute Type Notes
DataMessageIsIncoming private static : boolean
Class Diagrams Elements.RSQ::IIOD-EVEmergencyServicePersonnelAlert
Interfaces
Method Type Notes
ActivateDisplayingAlert () public: void
ActivateAcousticalAlert () public: void
3/23/2006 165 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Class Diagrams Elements.RSQ::ITCU-EVIncomingDataMessageDetector
Type: public abstract «interface» Interface
Package : Class Diagrams Elements.RSQ
Connections
• Association link from object Telematics Control Unit (TCU-EV)
Class Diagrams Elements.RSQ::ITCU-EVIncomingDataMessageDetector
Interfaces
Method Type Notes
CheckIncomingDataMessage () public: void
Class Diagrams Elements.RSQ::ITCU-EVSetUpVoiceLink
Type: public abstract «interface» Interface
Package : Class Diagrams Elements.RSQ
Connections
• Association link to object Telematics Control Unit (TCU-EV)
Class Diagrams Elements.RSQ::ITCU-EVSetUpVoiceLink Attributes
Attribute Type Notes
DataMessageIsIncoming private static : boolean
PSAP2CommParameters private static : float
Class Diagrams Elements.RSQ::ITCU-EVSetUpVoiceLink Interfaces
Method Type Notes
SetUpVoiceLink () public: void
3/23/2006 166 Version 2.0

9.1.7 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 79 - Sequence Diagram showing ESV – Emergency Data Receipt from PSAP2
Interaction Name Interaction Description IP-level?
ESV – Emergency Data
Receipt from PSAP2
This interaction diagram shows how
Emergency Data are received and handled to
make them ready for visualisation through the
HMI
Table 75 - Descriptions of Interactions for ESV – Emergency Data Receipt from PSAP2
ID Message From Object To Object Notes
1 IncidentDataForwardi
ng
2 CheckIncomingData
Message
3 DataMessageIsIncomi
ng
4 CheckDataMessageVa
lidity
Public Service Access
Point 2 (PSAP2)
Telematics Control
Unit (TCU-EV)
Communication
Infrastructure EV
Telematics Control
Unit (TCU-EV)
Communication
Infrastructure EV
Communication
Infrastructure EV
Telematics Control
Unit (TCU-EV)
Telematics Control
Unit (TCU-EV)
3/23/2006 167 Version 2.0

5 NewDataMessageAva
liable
6 EmergencyServicePer
sonAlert
DEL_RSQ_3_1 Architecture and Interface Specifications
Telematics Control
Unit (TCU-EV)
I/O Device (IOD-
EV)
7 ParseDataMessage I/O Device (IOD-
EV)
8 IncidentDataDisplayi
ng
9 ReadyForVoiceConne
ction
10 EstablishVoiceLinkW
ithPSAP2
I/O Device (IOD-
EV)
I/O Device (IOD-
EV)
Telematics Control
Unit (TCU-EV)
11 PSAP2VoiceCall Communication
Infrastructure EV
I/O Device (IOD-
EV)
Emergency Service
Person
I/O Device (IOD-
EV)
Emergency Service
Person
Telematics Control
Unit (TCU-EV)
Communication
Infrastructure EV
Public Service Access
Point 2 (PSAP2)
Table 76 - ESV – Emergency Data Receipt from PSAP2 Messages
3/23/2006 168 Version 2.0

9.1.8 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 80 - State Chart Diagram showing ESV – Emergency Data Receipt from PSAP2
Lifecycle Name Lifecycle Description IP-level?
ESV – Emergency Data
Receipt from PSAP2
This lifecycle shows the main activities
due to handle the incoming Emergency
Data Message
Table 77 - Descriptions of Lifecycles for ESV – Emergency Data Receipt from PSAP2
3/23/2006 169 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 10 - ESV RESCUE MANAGEMENT
10.1 UC RSQ 004 - ESV - Emergency Data Visualisation
10.1.1 Introduction
This collaboration illustrates the how Emergency Data received by the ESV from the
PSAP2 are shown to the Emergency Service Personnel throughout the HMI.
Figure 81 – Collaboration – ESV – Emergency Data Visualisation
10.1.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 82 – Use Case – ESV – Emergency Data Visualisation
3/23/2006 170 Version 2.0

10.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 83 - Class Diagram for ESV – Emergency Data Visualisation
Interface Name Interface Description IP-level?
IIOD-
EVEmergencyDataDisplayer
This interface is responsible for
Emergency Data message parsing in order
to prepare the XML behind the viewer for
Emergency Data Visualisation to the
Emergency Service Personnel through the
HMI.
Table 78 - Descriptions of Interfaces for ESV – Emergency Data Visualisation
10.1.4 API Specification
Class Diagrams Elements.RSQ::CIOD-EVDataMessageParser
Type: public Class
3/23/2006 171 Version 2.0

Package: Class Diagrams Elements.RSQ
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements.RSQ::CIOD-EVDataMessageParser Attributes
Attribute Type Notes
MSD private : binary
FSD private : binary
Class Diagrams Elements.RSQ::CIOD-EVDataMessageParser Methods
Method Type Notes
ParseIncidentLocation
(float, float, binary)
ParseInvolvedVehicleDat
a (binary)
ParseAdditionalVehicleD
ata (float, boolean, binary)
private: float
param: Longitude [ float - out ]
param: Latitude [ float - out ]
param: MSD [ binary - in ]
private: float param: MSD [ binary - in ]
private: float
GenerateMSD_XML () public: void
GenerateFSD_XML () public: void
param: FSDArray [ float - out ]
param: FSDPresent [ boolean - in ]
param: FSD [ binary - in ]
Class Diagrams Elements.RSQ::IIOD-EVEmergencyDataDisplayer
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements.RSQ::IIOD-EVEmergencyDataDisplayer Attributes
Attribute Type Notes
MSD private static : MSD
FSD private static : FSD
3/23/2006 172 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Class Diagrams Elements.RSQ::IIOD-EVEmergencyDataDisplayer Interfaces
Method Type Notes
ShowAccidentOnMap () public: void
ShowMSD () public: void
ShowFSD () public: void
10.1.5 Interactions
Pre-condition: Functional
MapSupportAvailable
Figure 84 - Sequence Diagram showing ESV – Emergency Data Visualisation
Interaction Name Interaction Description IP-level?
ESV – Emergency Data
Visualisation
This interaction diagram shows how
Emergency Data are parsed for the on
board visualisation.
Table 79 - Descriptions of Interactions for ESV – Emergency Data Visualisation
ID Message From Object To Object Notes
3/23/2006 173 Version 2.0

1 EmergencyDataParsed I/O Device
(IOD-EV)
2 MSD_XML_Available I/O Device
(IOD-EV)
3 FSD_XMLAvailable I/O Device
(IOD-EV)
4 EmergencyLocationDispla
yedOnMap
DEL_RSQ_3_1 Architecture and Interface Specifications
I/O Device
(IOD-EV)
5 MSD_Displayed I/O Device
(IOD-EV)
6 FSD_Displayed I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
Emergency
Service Person
Emergency
Service Person
Emergency
Service Person
Table 80 - ESV – Emergency Data Visualisation Messages
3/23/2006 174 Version 2.0

10.1.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 85 - State Chart Diagram showing ESV – Emergency Data Visualisation
Lifecycle Name Lifecycle Description IP-level?
ESV – Emergency Data
Visualisation
This activity diagram shows the main threads
for Emergency Data Visualisation
Table 81 - Descriptions of Lifecycles for ESV – Emergency Data Visualisation
3/23/2006 175 Version 2.0

10.2 UC RSQ 004 - ESV - Accept Deployment
DEL_RSQ_3_1 Architecture and Interface Specifications
10.2.1 Introduction
This collaboration illustrates the how Emergency Service Personnel can acknowledge the
PSAP2 the acceptance for a rescue deployment.
Figure 86 – Collaboration – ESV – Accept Deployment
10.2.2 Use Case Diagram
Next figure shows the collaboration mapped on a use case diagram.
Figure 87 - ESV – Accept Deployment
3/23/2006 176 Version 2.0

10.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 88 - Class Diagram for ESV – Accept Deployment
Interface Name Interface Description IP-level?
HMI-IOD-Interface This interface is responsible for handling
the “Accept Deployment” message and to
send it to the PSAP2 through the
Communication Infrastructure.
ESV-PSAP2-Interface This interface, to be implemented at PSAP2
side, is responsible for incoming “Accept
Deployment” messages check. If the
deployment is not accepted, other available
resources are selected for the rescue
procedures.
Table 82 - Descriptions of Interfaces for ESV – Accept Deployment
10.2.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Service Centre
communications protocol stack. The following picture illustrates the protocol stack
adopted for the “ESV – Accept Deployment” Message exchange.
3/23/2006 177 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 89 – Protocol Stack - ESV – Accept Deployment
10.2.5 Message Structure
The structure of the message to sent by the ESV to the PSAP2 to communicate the
willingness of the ESV staff to provide the rescue at the incident point is very simple and
it contains the basic information needed by the PSAP2 to activate the ESV on the rescue
procedure or to find a different available ESV.
The following table describes the structure of the SOAP Body Element of the message.
Element Sub-Element Description Data Type
AcceptDeployment
ESVID
Timestamp
IncidentID
AcceptanceStatus
MANDATORY - Unique
identifier of the ESV
MANDATORY - Timestamp
of when the “Accept
Deployment” message has
been sent.
MANDATORY - Unique
identifier of the Incident
process
MANDATORY - Unique
identifier of the Incident
process (see table below for
values.
Table 83 – SOAP Body Element structure
string
datetime
string
boolean
3/23/2006 178 Version 2.0

The AcceptanceStatus element will consist of the following:
Value Definition
0 Not Accepted
1 Accepted
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 84 – AcceptanceStatus element values
Message Encoding
The SOAP 1.2 encoded message is represented as follows.
value
value
value
value
10.2.6 API Specification
Class Diagrams Elements.RSQ::ESV-PSAP2-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagrams Elements.RSQ::ESV-PSAP2-Interface Attributes
Attribute Type Notes
RescueDeploymentAccepted private static : boolean
Class Diagrams Elements.RSQ::ESV-PSAP2-Interface Interfaces
Method Type Notes
CheckForAcceptation () public: void
SearchOtherAvailableResource () public: void
Class Diagrams Elements.RSQ::HMI-IOD-Interface
3/23/2006 179 Version 2.0

Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements.RSQ::HMI-IOD-Interface Attributes
Attribute Type Notes
DeploymentAccepted private static : boolean
Class Diagrams Elements.RSQ::HMI-IOD-Interface Interfaces
Method Type Notes
AcceptDeployment () public: void
AcceptDeploymentMessageHandler () public: void
SendAcceptMessage () public: void
10.2.7 Interactions
Figure 90 - Sequence Diagram showing ESV – Accept Deployment
Interaction Name Interaction Description IP-level?
AcceptDeployment The interaction between ESV and the
3/23/2006 180 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
PSAP2 allows a message exchange
which let the PSAP2 to be
acknowledge if the ESV is taking up
the rescue procedure or if another
vehicle should be selected for that.
Table 85 - Descriptions of Interactions for ESV – Accept Deployment
ID Message From Object To Object Notes
1 DeploymentAcceptati
on
2 DeploymentAcceptati
on
3 CheckForDeploymen
tAcceptation
4 DeploymentAcceptati
onMessage
5 StartRemoteRescueSu
pportProcedure
Emergency Service
Person
I/O Device (IOD-
EV)
Public Service Access
Point 2 (PSAP2)
Telematics Control
Unit (TCU-EV)
Public Service Access
Point 2 (PSAP2)
Table 86 - ESV – Accept Deployment Messages
I/O Device (IOD-
EV)
Telematics Control
Unit (TCU-EV)
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 2 (PSAP2)
3/23/2006 181 Version 2.0

10.2.8 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 91 - State Chart Diagram showing ESV – Accept Deployment
Lifecycle Name Lifecycle Description IP-level?
Accept Deployment The lifecycle consists of a message
sending to the PSAP2.
Table 87 - Descriptions of Lifecycles for ESV – Accept Deployment
3/23/2006 182 Version 2.0

Chapter 11 - ESV DRIVER SUPPORT
DEL_RSQ_3_1 Architecture and Interface Specifications
11.1 UC RSQ 005 – ESV - Calculate Route Options
11.1.1 Introduction
This collaboration shows the way Public Service Access Point 2 (PSAP 2, deployed by
the Service Centre) and Emergency Service Vehicle (ESV) accomplish the task of
calculating the best trip to reach the incident point as faster as possible. The reference
implementation will cover only the route request/response functions.
The reference implementation of the rest of this collaboration (actual route calculation)
will not be provided.
Figure 92 – Collaboration ESV Calculate Route Options
11.1.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 93 - ESV Calculate Route Options
3/23/2006 183 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
11.1.3 Interfaces
It is assumed that all the route computations are made Server Side by the PSAP2. This
choice has been taken due to the following reasons:
1. It reflects the "Open System" philosophy of GST project, since it doesn't require any
particular powerful client system’s TCU.
2. It takes into account the complexity of route guidance calculation.
Figure 94 - Class Diagram for ESV Calculate Route Options
Interface Name Interface Description IP-level?
ITCUEVCalculate
RouteOption
IPSAP2Calculate
RouteOption
Provide the way to ask and find the best route to arrive to
the incident place. Interface realised by the Emergency
Vehicle Client System of the Emergency Service Vehicle.
Offers all the computational resources to calculate the
route, according to several parameters relative to the
incident and the environment, such as geographical
coordinates, road conditions, traffic regulations, as well as
the format, the language, the map’s width and accuracy
needed to codify the information to send back to the
Emergency Service Vehicle. Interface realized by the Public
Service Access Point 2 (PSAP2), deployed by the Service
Centre.
Table 88 - Descriptions of Interfaces for ESV Calculate Route Options
3/23/2006 184 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
11.1.4 Protocol Stack and Specification
The following picture shows the protocol stack for ESV – Calculate Route Options. The
protocol stack is used here to transfer to the ESV the result of the route calculation done
at PSAP side. The application layer is implemented using XML data representation: for
this specific application GML (Geographic Mark-up Language -
http://opengis.net/gml/) is chosen.
GML allows smart and flexible maps and other geographic data representation and is
standardized (OGC - Open Geospatial Consortium: OpenGIS® Geography Markup
Language (GML) Encoding Specification, current version is 3.0).
The GML data are accessed via SOAP sessions built on top of the classical internet
protocol stack (http/tcp/ip).
In the following sections are the descriptions of:
• Structure of the geographic layers for maps and route
• XSD for the layers compounding the maps and routes
• GML instantiation examples: actual GML instantiation depends on route
calculation system, geographic area, level of detail and level of information
required.
The transmission shall be as fast as possible (per RESCUE requirements), so the data
provided to the ESV are vector graphics only (as example no pictures of satellite image,
to have more realistic maps, will be given).
GML
Application
Figure 95 – Protocol Stack – ESV – Calculate Route Options
3/23/2006 185 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
11.1.5 Message Structure
Message structure is described by the following XML schemas (XSDs). The schemas
represent all the layers compounding the representation of maps, route, and other
geographic information; the list of the layers is:
• Motorways
• Motorways junctions
• Urban roads
• Roads
• Railways
• Stations
• Rivers
• Lakes (AREA, PERIMETER, NAME)
• Localities (AREA, PERIMETER, PROV_DISTR, LOCALNAME)
• Urban areas (AREA, TYPE)
• Streets names and house numbers (NUMBER, STR_ADDR, ZIPCODE, CITY)
• Airports
• State borders
• Hospitals and medical centres
• Fire Brigades
• Police
• Meteo conditions
• Traffic
• Route (LENGTH)
• Route directions (ACTION)
• ESV position (TIMESTAMP, TIMETARGET, DISTARGET)
• Incident (POINTTYPE, NUMVEHICLE, TIMESTAMP, NUMCASUALT)
Each layer uses a single basic graphical element (point, line, and polygon). For each layer
a set of attributes (or GML Properties) is defined.
The layers have a common header:
3/23/2006 186 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Here below is the XSD schema graphic representation for each layer. XSD samples can
be found in Appendix C.
ESV position [TIME_STAMP, TIME_TO_TARGET, DISTANCE_TO_TARGET]
Motorways
3/23/2006 187 Version 2.0

Motorways junctions
DEL_RSQ_3_1 Architecture and Interface Specifications
Roads: urban roads, rural roads, state roads, expressways
3/23/2006 188 Version 2.0

Railways
Stations
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 189 Version 2.0

Rivers
Lakes (AREA, PERIMETER, NAME)
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 190 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Localities (AREA, PERIMETER, PROV_DISTR, LOCALNAME)
Urban areas (AREA, TYPE)
Streets names and house numbers (NUMBER, STR_ADDR, ZIPCODE,
CITY)
3/23/2006 191 Version 2.0

Airports
Borders - other borders (province, region)
DEL_RSQ_3_1 Architecture and Interface Specifications
Hospitals and medical centres - Fire fighters - Police
3/23/2006 192 Version 2.0

Meteo conditions
Traffic
Worksites
Route (LENGTH)
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 193 Version 2.0

Route directions (ACTION)
DEL_RSQ_3_1 Architecture and Interface Specifications
Incident (POINT_TYPE, VEHICLES, TIME_STAMP, CASUALTIES)
Message Encoding
The following GML examples show how the schemas are used to encode the layers to
build a route that can be sent to ESV and displayed in the vehicle. The examples were
given to a GIS tool in order to have a graphical representation of what can be obtained.
• urban.gml
3/23/2006 194 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
386077.07552094985157.12366667
401953.2694996878.007
399030.40299999999,4996878.0070000002
399104.66100000002,4996677.193 399065.90000000002,4996662.8600000003
399030.78899999999,4996757.8099999996 399056.65600000002,4996767.375
399033.46899999998,4996830.0800000001
399008.74400000001,4996820.9380000001
398992.87199999997,4996863.8609999996
399030.40299999999,4996878.0070000002
F9031
0.00000
0
...
[other feature members]
• roads.gml
383643.31254983033
4064114998104
393338.0625,49
96841.0 393338.21875,4996851.0 393338.0625,4996874.5
393337.125,4996892.5 393337.75,4996902.0 393336.9375,4996918.0
393336,4996930
393336.0,4996935.5
F16704
94.604
0
0
3/23/2006 195 Version 2.0

0
0
...
[other feature members]
• emergencycenters.gml
DEL_RSQ_3_1 Architecture and Interface Specifications
119.473684210526420
393648.48049353264995920.236123296
393648.48049353261,4995920.2361232964,0
F3
HOSPITAL
Stadium
C.so xxyyzz
10
011-5555555
Torino
393648.48049353261,4995920.2361232964,0
• incident.gml

DEL_RSQ_3_1 Architecture and Interface Specifications
xmlns:ogr="http://ogr.maptools.org/"
xmlns:gml="http://www.opengis.net/gml">
71.05263157894736349.4736842105263
394040.07762620534996088.063465871
394040.07762620534,
4996088.0634658709,0
F3
TARGET
2
2005:08:31:15:45:10:00
4
393131.66675802239,
4994931.5718407985,0
F4
START
2
2005:08:31:15:45:10:00
4
• route.gml
393131.86731583264994933.668036257
3940564996073
393131.8673158
3264,4994933.6680362569 393675,4995317 393543,4995672
394056,4996073
F0
9.9
3/23/2006 197 Version 2.0

Map and route example representation
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 96: Map and route visualisation sample
11.1.6 API Specification
Class Diagrams Elements::ITCU-EV-CalculateRouteOption
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
The purpose of this interface is:
• Allows others objects to command the TCU-EV to request a route calculation.
• Allows TCU-EV to acquire the route option from an external source.
Connections
• Association link from object Telematics Control Unit (TCU-EV)
3/23/2006 198 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Class Diagrams Elements::ITCU-EV-CalculateRouteOption Interfaces
Method Type Notes
CalculateRoute () public: void
SetRoute (Route) public: void
Starts the route calculation process.
The starting location should be already
available to the TCU-EV via its own
positioning system.
The target location should have been
already received.
param: route [ Route - in ]
Class Diagrams Elements::I-PSAP2-CalculateRouteOptions
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Allows other objects to:
SetRoute is used by external objects to
give the TCU-EV the route data. The
route is provided as Route object.
• Request a route calculation for a (start, target) locations couple.
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagrams Elements::I-PSAP2-CalculateRouteOptions Interfaces
Method Type Notes
RequestRoute (Location,
Location, Format, Language,
DetailsLevel,
MapDimensions)
public: void
param: start [ Location - in ]
Start location
param: target [ Location - in ]
Target (desination) location
param: format [ Format - in ]
Data representation:
- XML file
- Bitmap
- Compressed image
- Voice tags
- Icons set
- Simple text
param: language [ Language - in ]
Language of choice
3/23/2006 199 Version 2.0

ProcessGeographicData
()
public: void
ProcessTrafficData () public: void
ProcessWeatherData () public: void
ElaborateRoute () public: void
FormatRouteData () public: void
DEL_RSQ_3_1 Architecture and Interface Specifications
param: detailsLevel [ DetailsLevel - in ]
Level of map scale
param: mapWidth [ MapDimensions - in
]
Map dimentions. Used when the
requested format is as a picture.
Dimensions are (height, width)
expressed in pixels.
Receives the command for a new route
calculation
This method calculates a first set of
possible routes that takes in account
only geographic data.
This method will filter a set of routes
with respect to traffic conditions.
This method filters a set of routes with
respect to weather conditions
This method builds the final route to be
returned as the result of a route
calculation request.
This method formats the calculated
route with respect to:
- Format: data representation
- Language
- Level of details
- Map dimensions
3/23/2006 200 Version 2.0

11.1.7 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 97 - Sequence Diagram showing ESV Calculate Route Options
Interaction Name Interaction Description IP-level?
Route Calculation This interaction describes the exchange of data
between the Emergency Service Vehicle and the
PSAP2 to calculate a route and/or the graphic
representation of the calculated route between
several points.
Table 89 - Descriptions of Interactions for ESV Calculate Route Options
3/23/2006 201 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
ID Message From Object To Object Notes
1 RequestRoute Telematics
Control Unit
(TCU-EV)
2 ProcessGeogra
phicData
3 ProcessTraffic
Data
4 ProcessWeathe
rData
5 ElaborateRout
e
6 FormatRouteD
ata
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
7 SetRoute Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Telematics
Control Unit
(TCU-EV)
Table 90 - ESV Calculate Route Options Messages
11.1.8 Lifecycles
In the following figure is illustrated the lifecycle involving the main functionalities of
ESV Calculate Route Options Collaboration.
3/23/2006 202 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 98 - State Chart Diagram showing ESV Calculate Route Options
Lifecycle Name Lifecycle Description IP-level?
Route Finding This lifecycle shows the various steps to find the
fastest trip to reach the incident place and to choose
the best data formatting, suitable for every specific
Emergency Vehicle Client System.
Table 91 - Descriptions of Lifecycles for ESV Calculate Route Options
3/23/2006 203 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
11.2 UC RSQ 005 – ESV - Display Route Options
11.2.1 Introduction
This collaboration explains the modality in which route parameters and settings can be
modified by the Emergency Service Personnel using the HMI of Emergency Service
Vehicle (IOD-EV). The choice of an innovative and appropriate HMI will reduce
response times to the incident and lessen driver distraction, trying to plan routes which
will increase safety and security for the drivers. The reference implementation of this
collaboration will not be provided.
Figure 99 – Collaboration Display Route Options
11.2.2 Use Case Diagram
Next Figure shows the collaboration mapped on the use case UC RSQ 005 – Route
Guidance.
Figure 100 – ESV Display Route Options
3/23/2006 204 Version 2.0

11.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 101 - Class Diagram for ESV Display Route Options
Interface Name Interface Description IP-level?
IIODEVDisplayRouteOptions
Provide the way to set or modify the main
characteristics and the attributes of the
route guidance system through the onboard
device User Interface. Interface
realised by the Emergency Vehicle Client
System of the Emergency Service Vehicle.
Table 92 - Descriptions of Interfaces for ESV Display Route Options
11.2.4 API Specification
Class Diagrams Elements::I-IOD-EV-DisplayRouteOptions
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements::I-IOD-EV-DisplayRouteOptions Interfaces
Method Type Notes
3/23/2006 205 Version 2.0

AccessRouteOptions () public: void
SetModality
(DisplayRouteMode)
DEL_RSQ_3_1 Architecture and Interface Specifications
public: void param: mode [ DisplayRouteMode - in ]
SetLanguage (Language) public: void param: language [ Language - in ]
SetDetailsLevel
(DisplayRouteDetailsLevel)
public: void
SetMapSize (int, int) public: void
SetFileFormat
(DisplayRouteFormat)
public: void
CheckParameters () public: void
ApplyHMISettings () public: void
11.2.5 Interactions
param: detailsLevel [
DisplayRouteDetailsLevel - in ]
param: lenght [ int - in ]
param: width [ int - in ]
param: format [ DisplayRouteFormat -
in ]
Figure 102 - Sequence Diagram showing ESV Display Route Options
3/23/2006 206 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Interaction Name Interaction Description IP-level?
Route Option Setting This interaction describes the steps which allow the
Public Vehicle Person to establish the best
representation (graphic, textual or vocal) of the
route to calculate, as well as to set several important
aspects relative to the User Interface. The HMI will
be developed to optimise and improve the benefits
for the emergency service drivers.
Table 93 - Descriptions of Interactions for ESV Display Route Options
ID Message From Object To Object Notes
1 AccessRouteO
ptions
Emergency
Service Person
2 SetModality Emergency
Service Person
3 SetLanguage Emergency
Service Person
4 SetDetailsLevel Emergency
Service Person
5 SetMapSize Emergency
Service Person
6 SetFileFormat Emergency
Service Person
7 CheckParamet
ers
8 ApplyHMISetti
ngs
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
9 I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
Emergency
Service Person
Table 94 - ESV Display Route Options Messages
3/23/2006 207 Version 2.0

11.2.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 103 - State Chart Diagram showing ESV Display Route Options
3/23/2006 208 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 104 - Activity Diagram showing ESV Display Route Options
Lifecycle Name Lifecycle Description IP-level?
Route Guidance
System Setting
This lifecycle shows the operation of the Route
Guidance System in the case that some settings and
parameters are modified by the Public Vehicle Person
via the HMI. The development of a standardised HMI
will require further study and examination.
Table 95 - Descriptions of Lifecycles for ESV Display Route Options
3/23/2006 209 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
11.3 UC RSQ 005 – ESV - Target Information Reception
11.3.1 Introduction
This collaboration explains the model for the reception by the Emergency Vehicle, from
the PSAP2, of information about a specified target.
Figure 105 – Collaboration Target Information Reception
11.3.2 Use Case Diagram
Next Figure shows the collaboration mapped on the use case UC RSQ 005 – Route
Guidance.
11.3.3 Interfaces
Figure 106 – ESV Target Information Reception
3/23/2006 210 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 107 - Class Diagram for ESV Target Information Reception
Interface Name Interface Description IP-level?
I-CS-EV-
TargetInformationReception
This interface provides the following
methods:
• NotifyNewIncidentData:
notification function that is called
by an external object to tell the EV
about the availability of new
incident data.
• DataFormatNegotiationResult:
notification function that is called
by an external object to send to
EV the result of data format
negotiation.
3/23/2006 211 Version 2.0

I-CS-PSAP2-
TargetInformationReception
DEL_RSQ_3_1 Architecture and Interface Specifications
• CheckReceivedIncidentData:
function used to start the validity
check operation on the received
incident data.
This interface provides the following
methods:
• NegotiatePreferredDataFormat:
this method is called by an external
object when it is needed a
negotiation for data format with
PSAP2.
• FormatIncidentDataAndSend: this
method is called when the PSAP2
is ready to format and send the
incident location data.
• IncidentLocationDataReceptionAc
knowledge: this notification
function is called by an external
object when the location data has
been successfully received.
Table 96 - Descriptions of Interfaces for ESV Target Information Reception
11.3.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Service Centre
communications protocol stack. The following picture illustrates the protocol stack
adopted for the “ESV – Target Information Reception” Message exchange.
3/23/2006 212 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 108 – Protocol Stack - ESV Target Information Reception
11.3.5 Message Structure
This section describes the SOAP structure for the request of target information and
related response.
Route request
HTTP/SOAP Request: from client-->server
POST /InStock HTTP/1.1
Host: www.gstproject.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
[ESV location
info]
[Target location
info]
GML
[Name of the requested layer (names are supposed to
be standard)]
[Language, string or
code?]
3/23/2006 213 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
[Map extent, GML bounding
box]
Route response
HTTP/SOAP Response: from server --> client
HTTP/1.1 200 OK
Content-Type: application/soap; charset=utf-8
Content-Length: nnn
[Map+Route+Environmental GML
layers]
[VersionMismatch/MustUnderstand/Client/Server]<
/soap:faultcode>
[Human readable explanation of the
fault]
[URI of the resource that caused the
fault]
[Any sequence of any element with any
attribute]
Message Encoding
This section describes the HTTP message used for the request of target information and
related response.
Route request
HTTP/SOAP Request: from client-->server
POST /InStock HTTP/1.1
Host: www.gstproject.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
407405,5048621,0
3/23/2006 214 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
407666,5048999,0
GML
roads
route
EN
client
HTTP/1.1 200 OK
Content-Type: application/soap; charset=utf-8
Content-Length: nnn
393131.86731583264994933.668036257
3940564996073
393131.8673158
3264,4994933.6680362569 393675,4995317 393543,4995672
394056,4996073
F0
9.9
3/23/2006 215 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
383643.31254983033
4064114998104
393338.0625,49
96841.0 393338.21875,4996851.0 393338.0625,4996874.5
393337.125,4996892.5 393337.75,4996902.0 393336.9375,4996918.0
393336,4996930
393336.0,4996935.5
F16704
94.604
0
0
0
0
11.3.6 API Specification
Class Diagrams Elements::I-CS-EV-TargetInformationReception
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object Emergency Vehicle Client System (CS-EV)
Class Diagrams Elements::I-CS-EV-TargetInformationReception Interfaces
Method Type Notes
NotifyNewIncidentData public: void
3/23/2006 216 Version 2.0

()
DataFormatNegotiationR
esult
(IncidentDataFormatNegotiat
ionResult)
CheckReceivedIncidentD
ata ()
public: void
public: void
DEL_RSQ_3_1 Architecture and Interface Specifications
param: resultInformation [
IncidentDataFormatNegotiationResult -
in ]
Class Diagrams Elements::I-CS-PSAP2-TargetInformationReception
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagrams Elements::I-CS-PSAP2-TargetInformationReception Interfaces
Method Type Notes
NegotiatePreferredDataF
ormat
(IncidentLocationDataFormat
)
FormatIncidentDataAndS
end (IncidentLocatioData)
IncidentLocationDataRec
eptionAcknowledge
(IncidentLocationDataRecepti
onResult)
public: void
param: format [
IncidentLocationDataFormat - in ]
public: void param: data [ IncidentLocatioData - in ]
public: void
param: result [
IncidentLocationDataReceptionResult -
in ]
3/23/2006 217 Version 2.0

11.3.7 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 109 - Sequence Diagram showing ESV Target Information Reception
Interaction Name Interaction Description IP-level?
Target Information
Reception
This interaction describes the steps that allow the
PSAP2 to notify and send incident location (target)
data to the EV.
Table 97 - Descriptions of Interactions for ESV Target Information Reception
ID Message From Object To Object Notes
1 NotifyNewInci
dentData
2 NegotiatePrefe
rredDataForm
Public Service
Access Point 2
(PSAP2)
Emergency
Vehicle Client
System (CS-
Emergency
Vehicle Client
System (CS-
EV)
Public Service
Access Point 2
Acknowledge the readiness
to receive data and specify
3/23/2006 218 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
at EV) (PSAP2) preferred format.
3 DataFormatNe
gotiationResult
4 FormatInciden
tDataAndSend
5 ReceiveInciden
tData
6 CheckReceived
IncidentData
7 IncidentLocati
onDataRecepti
onAknowledge
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Public Service
Access Point 2
(PSAP2)
Emergency
Vehicle Client
System (CS-
EV)
Emergency
Vehicle Client
System (CS-
EV)
Emergency
Vehicle Client
System (CS-
EV)
Public Service
Access Point 2
(PSAP2)
Emergency
Vehicle Client
System (CS-
EV)
Emergency
Vehicle Client
System (CS-
EV)
Public Service
Access Point 2
(PSAP2)
Table 98 - ESV Target Information Reception Messages
Acknowledge the data
format or refuse that.
Incoming incident data.
The CS-EV Acknowledge
message contains
information about the
success or failure of the
reception and the
correctness of data content.
3/23/2006 219 Version 2.0

11.3.8 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 110 - State Chart Diagram showing ESV Target Information Reception
Lifecycle Name Lifecycle Description IP-level?
Target
Information
Reception
This lifecycle shows the operation of the Route
Guidance System in the case that new incident location
data are available.
Table 99 - Descriptions of Lifecycles for ESV Target Information Reception
3/23/2006 220 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 12 - VEHICLE TO VEHICLE COMMUNICATION
12.1 UC RSQ 006 & 007– ESV – Activate Warning Messages
12.1.1 Introduction
This collaboration illustrates the modality for activating the Blue Wave/Virtual Cones
warning messages.
ud UC RSQ 006 - ESV - Activ ate Warning Messages
I/O Dev ice (IOD-
EV)
(from Entities.RSQ)
ESV - Activate Warning Messages
IODEnd-User
(from Collaborations Package.RSQ)
Emergency Serv ice
Person
(from Actors.RSQ)
Figure 111 – Collaboration - ESV Activate Warning Messages
12.1.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
ud UC RSQ 006 - ESV - Activate Warning Messages
ESV - Activate
Warning Messages
(from Collaborations Package.RSQ)
«realize»
UC RSQ 006 - Blue
Wav e
(from Use Cases Package.RSQ)
Figure 112 – Use Case - ESV Activate Warning Messages
Emergency Serv ice
Person
(from Actors.RSQ)
3/23/2006 221 Version 2.0

12.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
cd UC RSQ 006 - ESV - Activate Warning Messages
Emergency Serv ice
Person
(from Actors.RSQ)
«interface»
Class Diagrams Elements.RSQ::I-ESP-IOD-EV
+ StopWarningTransmission() : void
+ StartWarningTransmission() : void
Figure 113 - Class Diagram for ESV Activate Warning Messages
Interface Name Interface Description IP-level?
I-ESP-IOD-EV This interface provides the means for
the Emergency Services Person to
activate Blue Wave / Virtual Cones
warning messages on the IO Device of
the Emergency Services Vehicle.
Table 100 - Descriptions of Interfaces for ESV Activate Warning Messages
12.1.4 API Specification
Class Diagrams Elements.RSQ::I-ESP-IOD-EV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link to interface I-IOD-EV-TCU-EV
• Association link from actor Emergency Service Person
Class Diagrams Elements.RSQ::I-ESP-IOD-EV Interfaces
Method Type Notes
StopWarningTransmission () public: void
StartWarningTransmission () public: void
3/23/2006 222 Version 2.0

12.1.5 Interactions
sd UC RSQ 006 - ESV - Activate Warning Messages
Emergency Service Person
(from Actors.RSQ)
DEL_RSQ_3_1 Architecture and Interface Specifications
StartWarningTransmission
I/O Dev ice
(IOD-EV)
(from Entities.RSQ)
Figure 114 - Sequence Diagram showing ESV Activate Warning Messages
Interaction Name Interaction Description IP-level?
ESV – Activate Warning
Messages
This interaction describes the event actioned
by the Emergency Services Person to activate
the Blue Wave / Virtual Cones warning
messages via the HMI. The HMI will allow
this functionality with a specific button to be
pushed by an Emergency Services Person.
Table 101 - Descriptions of Interactions for ESV Activate Warning Messages
ID Message From Object To Object Notes
1 StartWarningT
ransmission
Emergency
Service Person
I/O Device
(IOD-EV)
Table 102 - ESV Activate Warning Messages Messages
This is a manual trigger to
be activated by pressing a
specific button of ESV
HMI.
3/23/2006 223 Version 2.0

12.1.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
ad UC RSQ 006 - ESV - Activate Warning Messages
ESV - Activate Warning Messages Start
(from Activity Diagrams Elements.RSQ)
Emergency Serv ices
Person starts Blue Wave /
Virtual Cones
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
ESV - Acti vate Warni ng M essages Fi ni sh
Figure 115 - Activity Diagram showing ESV Activate Warning Messages
Lifecycle Name Lifecycle Description IP-level?
ESV – Activate Warning
Messages
This interaction describes the steps which
allow the Emergency Services Person to
activate the Blue Wave / Virtual Cones
warning messages via the HMI. The HMI will
allow this functionality with a specific button
to be pushed by an Emergency Services
Person.
Table 103 - Descriptions of Lifecycles for ESV Activate Warning Messages
12.2 UC RSQ 006 & 007– ESV – Reset Transmission
12.2.1 Introduction
This collaboration illustrates the modality for the resetting of the Blue Wave / Virtual
Cones warning message transmission.
3/23/2006 224 Version 2.0

ud UC RSQ 006 - ESV - Reset Transmission
Telematics
Control Unit
(TCU-EV)
(from Entities.RSQ)
DEL_RSQ_3_1 Architecture and Interface Specifications
ESV - Reset Transmission
IO Device Interface (IOD-I) I/O Device (IOD- IODEnd-User
(from Entities.RSQ)
(from Collaborations Package.RSQ)
Figure 116 – Collaboration - ESV Reset Transmission
Emergency Service
Person
(from Actors.RSQ)
12.2.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
ud UC RSQ 006 - ESV - Reset Transmission
ESV - Reset
Transmission
(from Collaborations Package.RSQ)
«realize»
UC RSQ 006 - Blue
Wav e
(from Use Cases Package.RSQ)
Figure 117 – Use Case – ESV Reset Transmission
Emergency Serv ice
Person
(from Actors.RSQ)
3/23/2006 225 Version 2.0

12.2.3 Interfaces
cd UC RSQ 006 - ESV - Reset Transmission
DEL_RSQ_3_1 Architecture and Interface Specifications
Emergency Serv ice
Person
(from Actors.RSQ)
«interface»
Class Diagrams Elements.RSQ::I-ESP-IOD-EV
+ StopWarningTransmission() : void
+ StartWarningTransmission() : void
«interface»
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV
- WarningState: boolean
- WarningTransmitTime: int
- GetLocationData() : GPSData
+ SetWarningState(boolean) : void
+ GetWarningState() : boolean
- CheckWarningTransmitTime() : boolean
Figure 118 - Class Diagram for ESV Reset Transmission
Interface Name Interface Description IP-level?
I-ESP-IOD-EV This interface provides the means for
the Emergency Services Person to reset
Blue Wave / Virtual Cones warning
messages on the IO Device of the
Emergency Services Vehicle.
Table 104 - Descriptions of Interfaces for ESV Reset Transmission
12.2.4 API Specification
Class Diagrams Elements.RSQ::I-ESP-IOD-EV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link to interface I-IOD-EV-TCU-EV
3/23/2006 226 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from actor Emergency Service Person
Class Diagrams Elements.RSQ::I-ESP-IOD-EV Interfaces
Method Type Notes
StopWarningTransmission () public: void
StartWarningTransmission () public: void
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object I/O Device (IOD-EV)
• Association link to interface I-TCU-EV-CI-EV
• Association link from interface I-ESP-IOD-EV
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV Attributes
Attribute Type Notes
WarningState
WarningTransmitTime
private static :
boolean
private const
static :
int
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV Interfaces
Method Type Notes
GetLocationData () private: GPSData
SetWarningState (boolean) public: void
GetWarningState () public: boolean
CheckWarningTransmitTi
me ()
private: boolean
param: BWS [ boolean - in ]
3/23/2006 227 Version 2.0

12.2.5 Interactions
sd UC RSQ 006 - ESV - Reset Transmission
Emergency Service Person
(from Actors.RSQ)
StopWarningTransmission
DEL_RSQ_3_1 Architecture and Interface Specifications
I/O Dev ice
(IOD-EV)
(from Entities.RSQ)
SetWarningState(False)
Telematics
Control Unit
(TCU-EV)
(from Entities.RSQ)
Figure 119 - Sequence Diagram showing ESV Reset Transmission
Interaction Name Interaction Description IP-level?
ESV – Reset Transmission This interaction describes the sequence of
events taken to reset the Blue Wave / Virtual
Cones warning messages via the HMI. The
HMI will allow this functionality with a
specific button to be pushed by an
Emergency Services Person. This action then
sets a flag in the Telematics Control Unit
indicating that the Emergency Services
Vehicle is no longer in a warning state.
Table 105 - Descriptions of Interactions for ESV Reset Transmission
ID Message From Object To Object Notes
1 StopWarningT
ransmission
2 SetWarningStat
e
Emergency
Service Person
I/O Device
(IOD-EV)
I/O Device
(IOD-EV)
Telematics
Control Unit
(TCU-EV)
Table 106 - ESV Reset Transmission Messages
This is a manual trigger to
be activated by pressing a
specific button of ESV
HMI.
Call type message.
3/23/2006 228 Version 2.0

12.2.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
ad UC RSQ 006 - ESV - Reset Transmission
ESV - Reset Transmission Start
(from Activity Diagrams Elements.RSQ)
Emergency Serv ices
Person stops Blue Wave /
Virtual Cones
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
ESV - Reset T ransm i ssi on Stop
Figure 120 - Activity Diagram showing ESV Reset Transmission
Lifecycle Name Lifecycle Description IP-level?
ESV – Reset Transmission This interaction describes the steps which
allow the Emergency Services Person to reset
the Blue Wave / Virtual Cones warning
messages via the HMI. The HMI will allow
this functionality with a specific button to be
pushed by an Emergency Services Person.
Table 107 - Descriptions of Lifecycles for ESV Reset Transmission
3/23/2006 229 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
12.3 UC RSQ 006 & 007– ESV – Send Warning Message
12.3.1 Introduction
This collaboration illustrates the modality for the sending of Blue Wave / Virtual Cones
warning messages.
ud UC RSQ 006 - ESV - Send Warning Message
Communication
Infrastructure EV
(from Entities.RSQ)
RP
ESV - Send Warning Message
Telematics
Control Unit
(TCU-EV)
(from Entities.RSQ)
IO Device Interface (IOD-I)
(from Collaborations Package.RSQ)
Figure 121 – Collaboration - ESV Send Warning Message
I/O Dev ice (IOD-
EV)
(from Entities.RSQ)
12.3.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
ud UC RSQ 006 - ESV - Send Warning Message
ESV - Send
Warning Message
(from Collaborations Package.RSQ)
«realize»
UC RSQ 006 - Blue
Wav e
(from Use Cases Package.RSQ)
Emergency Serv ice
Vehicle
(from Actors.RSQ)
Figure 122 – Use Case – ESV Send Warning Message
3/23/2006 230 Version 2.0

12.3.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
cd UC RSQ 006 - ESV - Send Warning Message
«interface»
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV
- WarningState: boolean
- WarningTransmitTime: int
- GetLocationData() : GPSData
+ SetWarningState(boolean) : void
+ GetWarningState() : boolean
- CheckWarningTransmitTime() : boolean
«interface»
Class Diagrams Elements.RSQ::I-TCU-EV-CI-EV
+ TransmitWarning(WarningMsg) : void
Figure 123 - Class Diagram for ESV Send Warning Message
Interface Name Interface Description IP-level?
I-IOD-EV-TCU-EV This interface provides the means for
the IO Device to activate the sending of
the Blue Wave / Virtual Cones warning
messages from the Telematics Control
Unit of the Emergency Services Vehicle.
Table 108 - Descriptions of Interfaces for ESV Send Warning Message
12.3.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Vehicle communications
protocol stack. The following picture illustrates the protocol stack adopted for the “ESV
– Send Warning Message” Message exchange.
3/23/2006 231 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 124 – Protocol Stack - ESV Send Warning Message
12.3.5 Message Structure
The Vehicle-to-Vehicle Warning Message data will consist of the following:
Data Item Description Data Type
Date & Time UTC (Coordinated Universal Time) date and 4-byte binary
time that the warning message was initiated time-stamp
Location Current GPS location of the emergency vehicle 10-byte binary
encoded GPS
coordinates
Direction Current direction of travel of the emergency
vehicle
Speed Current speed of travel of the emergency
vehicle
2-byte compass
coordinate (0-360)
2-byte integer
speed value (m/s)
EV Identifier Emergency Vehicle identifier 4-byte binary ID
EV Type Emergency Vehicle type (e.g. police,
ambulance, etc.)
1-byte binary ID
Incident ID Unique incident identifier 4-byte binary ID
Warning Type Blue Wave or Virtual Cones 1-byte binary ID
Message Encoding
Table 109 – Vehicle-to-Vehicle Warning Message elements
3/23/2006 232 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
The Vehicle-to-Vehicle Warning Message data will consist of the following:
Message Element Description Value Type
Timestamp UTC (Coordinated Universal Time) date and
time that the warning message was initiated
Longitude Longitude of the Emergency Services Vehicle
in Radians
Latitude Latitude of the Emergency Services Vehicle in
Radians
Track Current direction of travel of the Emergency
Services Vehicle as a compass heading in
Radians
Speed Speed of the Emergency Services Vehicle in
Metres per second
Long
Double
Double
Double
Double
ESVIdentifier Emergency Vehicle identifier Long
ESVType Emergency Vehicle type (see table below for
values)
Byte
IncidentID Unique incident identifier Long
WarningType Warning message type (see table below for
values)
Byte
Table 110 – Vehicle-to-Vehicle Warning Message elements definition
The ESVType Warning Message element will consist of the following:
Value Definition
0 Police
1 Fire
2 Ambulance
Table 111 – ESVType element values
The WarningType Warning Message element will consist of the following:
Value Definition
0 Blue Wave
1 Virtual Cones
Table 112 – WarningType element values
12.3.6 API Specification
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV
3/23/2006 233 Version 2.0

Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object I/O Device (IOD-EV)
• Association link to interface I-TCU-EV-CI-EV
• Association link from interface I-ESP-IOD-EV
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV Attributes
Attribute Type Notes
WarningState
WarningTransmitTime
private static :
boolean
private const
static :
int
Class Diagrams Elements.RSQ::I-IOD-EV-TCU-EV Interfaces
Method Type Notes
GetLocationData () private: GPSData
SetWarningState (boolean) public: void
GetWarningState () public: boolean
CheckWarningTransmitTi
me ()
private: boolean
Class Diagrams Elements.RSQ::I-TCU-EV-CI-EV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
param: BWS [ boolean - in ]
• Association link from object Telematics Control Unit (TCU-EV)
• Association link from interface I-IOD-EV-TCU-EV
Class Diagrams Elements.RSQ::I-TCU-EV-CI-EV Interfaces
Method Type Notes
3/23/2006 234 Version 2.0

TransmitWarning
(WarningMsg)
12.3.7 Interactions
public: void
sd UC RSQ 006 - ESV - Send Warning Message
I/O Device
(IOD-EV)
(from Entities.RSQ)
SetWarningState(True)
Telematics
Control Unit
(TCU-EV)
(from Entities.RSQ)
DEL_RSQ_3_1 Architecture and Interface Specifications
param: WarningMsg [ WarningMsg - in ]
Vehicle Location
Dev ice
[WarningState = True]: GPSData:= GetLocationData
(from Entities.RSQ)
Communication
Infrastructure EV
[WarningState = True]: WarningMsg:= TransmitWarning
(from Entities.RSQ)
Figure 125 - Sequence Diagram showing ESV Send Warning Message
Interaction Name Interaction Description IP-level?
ESV – Send Warning
Message
This interaction describes the sequence of
events taken when Blue Wave / Virtual Cones
warning messages are sent from the
Telematics Control Unit in the Emergency
Services Vehicle as follows:
1. The IO Device sets a flag in the
Telematics Control Unit indicating
that the Emergency Services Vehicle
has entered a warning state.
2. The Telematics Control Unit
periodically checks whether the
Emergency Services Vehicle is in a
warning state and if it is, the following
events occur:
a. The real-time location of the
Emergency Services Vehicle
(GPS Data) is retrieved from
the Vehicle Location Device.
b. The Blue Wave / Virtual
Cones warning message is
“constructed” using the GPS
Data.
c. The Blue Wave / Virtual
Cones warning message is
transmitted via the
3/23/2006 235 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Communication Infrastructure
of the Emergency Services
Vehicle.
Table 113 - Descriptions of Interactions for ESV Send Warning Message
ID Message From
Object
1 SetWarningState I/O
Device
(IOD-
EV)
2 GetLocationData Telematic
s Control
Unit
(TCU-
EV)
3 TransmitWarning Telematic
s Control
Unit
(TCU-
EV)
To Object Notes
Telematics
Control Unit
(TCU-EV)
Vehicle Location
Device
Communication
Infrastructure EV
Table 114 - ESV Send Warning Message Messages
3/23/2006 236 Version 2.0

12.3.8 Lifecycles
ad UC RSQ 006 - ESV - Send Warning Message
iterativ e
DEL_RSQ_3_1 Architecture and Interface Specifications
ESV - Send Warning Message Start
(from Activity Diagrams Elements.RSQ)
Send Warning Message
Get ESV location data
(from Activity Diagrams Elements.RSQ)
Transmit Blue Wave /
Virtual Cones Message
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
ESV - Send Warning Message Stop
Figure 126 - Activity Diagram showing ESV Send Warning Message
Lifecycle Name Lifecycle Description IP-level?
ESV – Send Warning
Message
This interaction describes the steps taken
when Blue Wave / Virtual Cones warning
messages are sent from the Telematics
Control Unit in the Emergency Services
Vehicle. Activation of the Telematics Control
Unit is via the IO Device in the Emergency
Services Vehicle.
Table 115 - Descriptions of Lifecycles for ESV Send Warning Message
3/23/2006 237 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
12.4 UC RSQ 006 & 007– PV – Interpret Warning Message
12.4.1 Introduction
This collaboration illustrates the modality for the interpreting of the Blue Wave / Virtual
Cones warning messages.
ud UC RSQ 006 - PV - Interpret Warning Message
IODEnd-
User
Member of Public
Person
(from Actors.RSQ)
PV - Interpret Warning Message
I/O Device (IOD-
PV)
(from Entities.RSQ)
IO Device Interface (IOD-I)
(from Collaborations Package.RSQ)
Figure 127 – Collaboration – PV Interpret Warning Message
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
12.4.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
ud UC RSQ 006 - PV - Interpret Warning Message
PV - Interpret
Warning Message
(from Collaborations Package.RSQ)
«include»
PV - Receive
Warning Message
(from Collaborations Package.RSQ)
«realize»
UC RSQ 006 - Blue
Wav e
(from Use Cases Package.RSQ)
Figure 128 – Use Case – PV Interpret Warning Message
Member of Public
Vehicle
(from Actors.RSQ)
3/23/2006 238 Version 2.0

12.4.3 Interfaces
cd UC RSQ 006 - PV - Interpret Warning Message
- TimeOutValue: int
DEL_RSQ_3_1 Architecture and Interface Specifications
«interface»
Class Diagrams Elements.RSQ::I-MPP-IOD-PV
+ ShowWarningTransmission() : void
+ HideWarningTransmission() : void
«interface»
Class Diagrams Elements.RSQ::I-IOD-PV-TCU-PV
- GetLocationData() : GPSData
- SetWarningTimer(TimeOutValue)
- InterpretWarningTransmission(GPSData, WarningMsg) : WarningData
+ CheckWarningTimer() : TimeRemaining
Figure 129 - Class Diagram for PV Interpret Warning Message
Interface Name Interface Description IP-level?
I-IOD-PV-TCU-PV This interface provides the means for all
received Blue Wave / Virtual Cones
warning messages to be interpreted in
order to facilitate clear and concise
presentation via the IO Device of the
Public Vehicle.
Table 116 - Descriptions of Interfaces for PV Interpret Warning Message
12.4.4 API Specification
Class Diagrams Elements.RSQ::I-IOD-PV-TCU-PV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object I/O Device (IOD-PV)
• Association link from interface I-MPP-IOD-PV
Class Diagrams Elements.RSQ::I-IOD-PV-TCU-PV Attributes
Attribute Type Notes
3/23/2006 239 Version 2.0

TimeOutValue
private static :
int
DEL_RSQ_3_1 Architecture and Interface Specifications
Class Diagrams Elements.RSQ::I-IOD-PV-TCU-PV Interfaces
Method Type Notes
GetLocationData () private: GPSData
SetWarningTimer
(TimeOutValue)
InterpretWarningTransmi
ssion (GPSData,
WarningMsg)
CheckWarningTimer ()
private:
private:
WarningData
public:
TimeRemaining
Class Diagrams Elements.RSQ::I-MPP-IOD-PV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link to interface I-IOD-PV-TCU-PV
• Association link to interface I-TCU-PV-IOD-PV
param: TimeOutValue [ TimeOutValue
- in ]
param: GPSData [ GPSData - in ]
param: WarningMsg [ WarningMsg - in ]
• Association link from actor Member of Public Person
Class Diagrams Elements.RSQ::I-MPP-IOD-PV Interfaces
Method Type Notes
ShowWarningTransmission () public: void
HideWarningTransmission () public: void
3/23/2006 240 Version 2.0

12.4.5 Interactions
sd UC RSQ 006 - PV - Interpret Warning Message
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
GPSData:= GetLocationData
Vehicle Location
Dev ice
WarningData:= InterpretWarningTransmission(WarningMsg,
GPSData)
[Warning NOT NULL]: DisplayWarning(WarningData)
(from Entities.RSQ)
DEL_RSQ_3_1 Architecture and Interface Specifications
I/O Device
(IOD-PV)
(from Entities.RSQ)
ShowWarningTransmission
Figure 130 - Sequence Diagram showing PV Interpret Warning Message
Member of Public Person
(from Actors.RSQ)
Interaction Name Interaction Description IP-level?
PV – Interpret Warning
Message
This interaction describes the sequence of
events taken following successful receipt of a
Blue Wave / Virtual Cones warning message:
1. The real-time location of the Public
Vehicle (GPS Data) is retrieved from
the Vehicle Location Device.
2. The content of the Blue Wave /
Virtual Cones warning message is
examined and the Emergency
Services Vehicle location (encoded as
part of the warning message) is
compared to the Public Vehicle
location.
3. If the Blue Wave / Virtual Cones
warning message is deemed relevant
to the Public Vehicle, the warning
message is presented to the Member
of Public Person via the HMI of the
IO Device of the Public Vehicle.
Table 117 - Descriptions of Interactions for PV Interpret Warning Message
3/23/2006 241 Version 2.0

ID Message From
Object
1 GetLocationData Telematics
Control
Unit (TCU-
PV)
2 InterpretWarning Telematics
Control
Unit (TCU-
PV)
3 DisplayWarning Telematics
Control
Unit (TCU-
PV)
4 ShowWarning I/O Device
(IOD-PV)
DEL_RSQ_3_1 Architecture and Interface Specifications
To Object Notes
Vehicle
Location
Device
Telematics
Control Unit
(TCU-PV)
I/O Device
(IOD-PV)
Member of
Public Person
Table 118 - PV Interpret Warning Message Messages
3/23/2006 242 Version 2.0

12.4.6 Lifecycles
ad UC RSQ 006 - PV - Interpret Warning Message
PV - Interpret Warning Message Start
(from Activity Diagrams Elements.RSQ)
iterative
Receive Warning Message
Get PV location data
(from Activity Diagrams Elements.RSQ)
Interpret Blue Wav e /
Virtual Cones message
in-conj unction w ith the PV
location data
(from Activity Diagrams Elements.RSQ)
YES
Display the Blue Wav e /
Virtual Cones message
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
PV - Interpret Warning Message Stop
DEL_RSQ_3_1 Architecture and Interface Specifications
Is the Blue Wave / Virtual Cones message relevant to the
Public Vehicle?
Figure 131 - Activity Diagram showing PV Interpret Warning Message
Lifecycle Name Lifecycle Description IP-level?
PV – Interpret Warning
Message
This interaction describes the steps taken
following successful receipt of a Blue Wave /
Virtual Cones warning message.
Table 119 - Descriptions of Lifecycles for PV Interpret Warning Message
3/23/2006 243 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
12.5 UC RSQ 006 & 007– PV – Receive Warning Message
12.5.1 Introduction
This collaboration illustrates the modality for receiving the Blue Wave/Virtual Cones
warning messages.
ud UC RSQ 006 - PV - Receive Warning Message
Communication
Infrastructure PV
(from Entities.RSQ)
PV - Receive Warning Message
RP
(from Collaborations Package.RSQ)
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
Figure 132 – Collaboration - PV Receive Warning Message
12.5.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
ud UC RSQ 006 - PV - Receive Warning Message
PV - Receive
Warning Message
(from Collaborations Package.RSQ)
«realize»
UC RSQ 006 - Blue
Wav e
(from Use Cases Package.RSQ)
Figure 133 – Use Case – PV Receive Warning Message
Member of Public
Vehicle
(from Actors.RSQ)
3/23/2006 244 Version 2.0

12.5.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
cd UC RSQ 006 - PV - Receive Warning Message
Communication
Infrastructure PV
(from Entities.RSQ)
«interface»
Class Diagrams Elements.RSQ::I-TCU-PV-CI-PV
+ ReceiveWarningTransmission(WarningMsg) : void
Figure 134 - Class Diagram for PV Receive Warning Message
Interface Name Interface Description IP-level?
I-TCU-PV-CI-PV This interface provides the means for
the receipt of Blue Wave / Virtual
Cones warning messages to the
Telematics Control Unit of the Public
Vehicle .
Table 120 - Descriptions of Interfaces for PV Receive Warning Message
12.5.4 API Specification
Class Diagrams Elements.RSQ::I-TCU-PV-CI-PV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object Communication Infrastructure PV
Class Diagrams Elements.RSQ::I-TCU-PV-CI-PV Interfaces
Method Type Notes
ReceiveWarningTransmis
sion (WarningMsg)
public: void
param: WarningMsg [ WarningMsg - in ]
3/23/2006 245 Version 2.0

12.5.5 Interactions
sd UC RSQ 006 - PV - Receive Warning Message
Communication
Infrastructure PV
(from Entities.RSQ)
ReceiveWarningTransmission(WarningMsg)
DEL_RSQ_3_1 Architecture and Interface Specifications
Telematics
Control Unit
(TCU-PV)
(from Entities.RSQ)
SetWarningTimer(TimeOutValue)
Figure 135 - Sequence Diagram showing PV Receive Warning Message
Interaction Name Interaction Description IP-level?
PV – Receive Warning
Message
This interaction describes the sequence of
events taken during the receipt of a Blue
Wave / Virtual Cones warning message. The
Telematics Control Unit in the Public Vehicle
receives the message and re-starts a timer.
The timer is used to ensure that Blue Wave /
Virtual Cones warning messages are not
displayed indefinitely. If the timer reaches a
predefined value before being re-started by
the receipt of a new warning message, the
current warning message presentation is
cancelled.
Table 121 - Descriptions of Interactions for PV Receive Warning Message
ID Message From Object To Object Notes
1 ReceiveWarnin
gTransmission
2 SetWarningTi
mer
Communication
Infrastructure PV
Telematics Control
Unit (TCU-PV)
Telematics
Control
Unit (TCU-
PV)
Telematics
Control
Unit (TCU-
PV)
Table 122 - PV Receive Warning Message Messages
3/23/2006 246 Version 2.0

12.5.6 Lifecycles
ad UC RSQ 006 - PV - Receive Warning Message
iterativ e
DEL_RSQ_3_1 Architecture and Interface Specifications
PV - Receive Warning Message Start
(from Activity Diagrams Elements.RSQ)
Receive Warning Message
Receive Blue Wave /
Virtual Cones Message
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
(from Activity Diagrams Elements.RSQ)
PV - Receive Warning Message Stop
Figure 136 - Activity Diagram showing PV Receive Warning Message
Lifecycle Name Lifecycle Description IP-level?
PV – Receive Warning
Message
This interaction describes the steps taken
upon receipt of a Blue Wave / Virtual Cones
warning message by the Telematics Unit in
the Public Vehicle.
Table 123 - Descriptions of Lifecycles for PV Receive Warning Message
3/23/2006 247 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 13 - PUBLIC VEHICLE DRIVER SUPPORT
13.1 UC RSQ 006 - PV - Reset Warning Message
13.1.1 Introduction
This collaboration illustrates how the warning message displaying on a PV is reset when
the system is longer receiving warning messages of interest to the driver.
Figure 137 – Collaboration – PV - Reset Warning Message
13.1.2 Use Case Diagram
Next Figure shows the collaboration mapped on a use case diagram.
Figure 138 – Use Case – PV - Reset Warning Message
3/23/2006 248 Version 2.0

13.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 139 - Class Diagram for PV - Reset Warning Message
Interface Name Interface Description IP-level?
I-MPP-IOD-PV This interface provides the means for the IO
Device to communicate to the Member of Public
Person, via the HMI, that a Blue Wave / Virtual
Cones warning message is no longer applicable.
The HMI will implement this functionality by
hiding the appropriate displayed warning.
Table 124 - Descriptions of Interfaces for PV - Reset Warning Message
13.1.4 API Specification
Class Diagrams Elements.RSQ::I-MPP-IOD-PV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link to interface I-IOD-PV-TCU-PV
3/23/2006 249 Version 2.0

• Association link to interface I-TCU-PV-IOD-PV
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from actor Member of Public Person
Class Diagrams Elements.RSQ::I-MPP-IOD-PV Interfaces
Method Type Notes
ShowWarningTransmission () public: void
HideWarningTransmission () public: void
Class Diagrams Elements.RSQ::I-TCU-PV-IOD-PV
Type: public abstract «interface» Interface
Package: Class Diagrams Elements.RSQ
Connections
• Association link from object Telematics Control Unit (TCU-PV)
• Association link from interface I-MPP-IOD-PV
Class Diagrams Elements.RSQ::I-TCU-PV-IOD-PV Interfaces
Method Type Notes
CancelWarning () public: void
DisplayWarning (WarningData) public: void param: WarningData [ WarningData - in ]
13.1.5 Interactions
Figure 140 - Sequence Diagram showing PV - Reset Warning Message
3/23/2006 250 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Interaction Name Interaction Description IP-level?
PV – Reset Warning
Message
This interaction describes the sequence of
events required in order to reset the warning
message presented to the Member of Public
Person:
1. A timer is used to time-out the warning
message presentation. If the timer is not
re-started by the receipt of a new and
valid warning message, it reaches a predefined
value.
2. Upon reaching the pre-determined
value, the IO Device cancels the display
of the appropriate warning message.
3. The Member of Public Person is made
aware that the danger is no longer valid
through a change in the HMI.
Table 125 - Descriptions of Interactions for PV - Reset Warning Message
ID Message From Object To Object Notes
1 CheckBlueWav
eTimer
2 CancelBlueWa
ve
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
3 HideBlueWave I/O Device (IOD-
PV)
Telematics Control
Unit (TCU-PV)
I/O Device (IOD-
PV)
Member of Public
Person
Table 126 - PV - Reset Warning Message Messages
3/23/2006 251 Version 2.0

13.1.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 141 - State Chart Diagram showing PV - Reset Warning Message
Lifecycle Name Lifecycle Description IP-level?
PV – Reset Warning
Message
This interface describes the steps taken
when a Blue Wave / Virtual Cones warning
message is no longer applicable for
communication to the Member of Public
Person, via the HMI
The HMI will implement this functionality
by hiding the appropriate displayed warning.
Table 127 - Descriptions of Lifecycles for PV - Reset Warning Message
3/23/2006 252 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 14 - VEHICLE TO CENTRE COMMUNICATION
14.1 UC RSQ 008 – Transmission of Data
14.1.1 Introduction
This collaboration provides the capability to transmit information or to send a request
from the Client System to a Third Party.
Figure 142 - Transmission of Data (entities involved)
14.1.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 143 - Transmission of Data
3/23/2006 253 Version 2.0

14.1.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 144 - Class Diagram for Transmission of Data
Interface Name Interface Description IP-level?
I-TCU-EV-VAD_Handler This interface allows to handle the VAD
transmission to any authorised Third Parties
I-IOD-EV-VideoDevice This interface allows video capturing,
encoding and storing on the TCU-EV by
interfacing with a connected video device.
I-3rdP-VAD_Handler This interface allows the capability to handle,
collate and store VAD files received from the
ESV.
I-PSAP2-TCU-EV-
LiveVAD
This interface is responsible for pulling and
decoding live VAD from the ESV.
Table 128 - Descriptions of Interfaces for Transmission of Data
14.1.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Service Centre
communications protocol stack. The following picture illustrates the protocol stack
adopted for the “Transmission of Data” Message exchange.
3/23/2006 254 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 145 – Protocol Stack – Transmission of Data
14.1.5 Message Structure
The process for Transmission of Data between the ESV and any authorised Third Party
consists mainly of a SOAP message exchange between the involved parties. Messages
exchanged are two:
• A REQUEST message which allows the Third Party to ask to the ESV if VAD
are available for the downloading.
• A RESPONSE message which answer to the Third Party if VAD are available
for a specific incident, the list of the available VAD files and where is possible to
pick up the information.
The request message MUST contains all the information needed by the ESV to identify
the required VAD files, such as the identification of the incident which the VAD files
refer to, whilst the response message MUST contains all the information needed by the
Third Party to interpret the VAD files and where is possible pick up these files.
On the basis of these consideration it is possible to define the REQUEST and the
RESPONSE messages structures. The following table describes the structure of the
SOAP Body Element of the messages. Note that all the identified information elements
identified as part of the “Body” element are MANDATORY.
Element Description Data Type
SOAP REQUEST – from Third Party to ESV
3rdP Is the unique identifier of the authorised string
3/23/2006 255 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Element Description Data Type
3rdPType
3rdP_IP
Third Party.
Is the type of the authorised Third Party
indicating the role which the Third Party
covers itself.
Element Values are encoded as follows:
Type Code Description
0 undefined
1 PSAP1
2 Hospital
3 Police
4 Fire Brigades
5 Service Provider
Is the IP Address of the Third authorised
Party.
3/23/2006 256 Version 2.0
int
string
Incident Is the unique identifier of the incident. string
TimeStamp
SOAP RESPONSE – from ESV to Third Party
ESV
Timestamp at which the request for VAD
message has been sent out by the Third
Party
Is the unique identifier of the Emergency
Service Vehicle.
datetime
string
Incident Is the unique identifier of the incident. string
GPSPositionLatitude
GPSPositionLongitude
TimeStamp
VADURL
WGS84 Latitude Value (milliarcseconds) *
10 7
WGS84 Longitude Value (milliarcseconds)
* 10 7
Timestamp at which the response for VAD
message has been sent out by the ESV
It is the URL at which it is possible to GET
the available VAD files (e.g.
http://172.0.8.32/download).
VADNumber It is the number of available VAD files Int
VADFile_X
It is the name defined as (see par. 19.8):
ESVID_IncidentID_FileType_FileID.Extension
Of the VAD file number X.
Table 129 – SOAP Body Element structure
Integer
integer
datetime
string
String

DEL_RSQ_3_1 Architecture and Interface Specifications
Message Encoding
The SOAP 1.2 encoded REQUEST message from the Third Party to the ESV is
represented as follows.
value
value
value
value
value
The SOAP 1.2 encoded RESPONSE message from the ESV to the Third Party is
represented as follows.
value
value
value
value
value
value
value
value
3/23/2006 257 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
value
value
value
14.1.6 API Specification
Class Diagrams Elements::I-3rdP-VAD_Handler
Type: public abstract «interface» Interface
Package : Class Diagrams Elements
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
• Association link from object Third Party (3rdP)
Class Diagrams Elements::I-3rdP-VAD_Handler Attributes
Attribute Type Notes
ESV_ID public static : char
Incident_ID public static : char
AvailableVADFilesList public static : char
Destination public static : char
Class Diagrams Elements::I-3rdP-VAD_Handler Interfaces
Method Type Notes
GetVADFileFromESV () public: void
RequestAvailableVAD () public: char
EstablishCommunicationLink () public: void
VADFileStoring (char, char, char) public: void param: Incident_ID [ char - in ]
param: ESV_ID [ char - in ]
param: VAD_File [ char - in ]
IncomingNewVADFileCheck () public: boolean
ActivateVADTransmission () public: void
3/23/2006 258 Version 2.0

GetAvailableVAD () public: void
SetDestination () public: void
GetCurrentDestination () public: char
Class Diagrams Elements::I-IOD-EV-VideoDevice
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements::I-IOD-EV-VideoDevice Attributes
Attribute Type Notes
VideoFileName public static : char
DestinationPath public static : char
Class Diagrams Elements::I-IOD-EV-VideoDevice Interfaces
Method Type Notes
ActivateVideoCapture () public: void
DeactivateVideoCapture () public: void
Analog2DigitalConversion () public: void
VideoStoring () public: void
VADEncoding () public: void
Class Diagrams Elements::I-PSAP2-TCU-EV-LiveVAD
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object Public Service Access Point 2 (PSAP2)
Class Diagrams Elements::I-PSAP2-TCU-EV-LiveVAD Attributes
Attribute Type Notes
ESV_ID public static : char
3/23/2006 259 Version 2.0

Incident_ID public static : char
Source_IP_Address public static : char
DEL_RSQ_3_1 Architecture and Interface Specifications
Class Diagrams Elements::I-PSAP2-TCU-EV-LiveVAD Interfaces
Method Type Notes
ActivateVADLiveStreaming () public: void
DeactivateVADLiveStreaming () public: void
EstablishCommunicationLink () public: void
LiveVADStoring () public: void
LiveVADDecoding () public: void
LiveVADDisplaying () public: void
Class Diagrams Elements::I-TCU-EV-VAD_Handler
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link to object Telematics Control Unit (TCU-EV)
Class Diagrams Elements::I-TCU-EV-VAD_Handler Attributes
Attribute Type Notes
Destination public static : char
MarkedFilesList public static : char
Incident_ID public static : char
Class Diagrams Elements::I-TCU-EV-VAD_Handler Interfaces
Method Type Notes
GetAvailableVAD () public: char It returns the list of VAD Marked
Files
ActivateVADTransmission () public: void It "makes" a request for VAD
Transmission of the Marked Files to
a 3rdParty
SetDestination () public: void It allows to set the destination of the
VAD files
GetCurrentDestination () public: char
3/23/2006 260 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
PushVADtoPSAP2 () public: void If the destination is the own PSAP2
VAD files are automatically pushed
via a FTP PUT way.
EstablishCommunicationLink () public: void Provided by GST_OS
GetVADFileFrom3rdParty () public: void It allows to get the available VAD
files from the 3rd Party
RequestAvailableVAD () public: void This method allows to ask to the 3rd
Party if any VAD file is available to
be downloaded.
VADFileStoring (char, char) public: void param: 3rd_Party_ID [ char - in ]
param: Incident_ID [ char - in ]
IncomingNewVADFileCheck () public: void
14.1.7 Interactions
In this context, it is possible to identify the two possible scenarios (see paragraph 19.8):
• The Emergency Service Personnel request for VAD uploading to the Centre
• The Centre request for VAD to Emergency Service Vehicle platform.
The first situation is a PUSH case whilst the second one represents the PULL case. In
both of these two case the process is very similar unless of a significant difference. Whilst
in the PUSH case the ESV-Client System asks to the Centre “Please download these files from
me”, in the PULL case the Centre requests to the ESV-Client System “which files can I
download from you?”.
Even if it is a PUSH or a PULL case, the VAD transmission happens as a GET request
over HTTP.
The following pictures show these possible scenarios.
Figure 146 - Sequence Diagram showing Transmission of Data – PUSH Case
3/23/2006 261 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
It is important to note that there is a particular case in which it is possible to
automatically send the VAD files to a Centre without a request. It is the situation in
which the ESV transmits its information to its own PSAP2. In this case the sequence of
actions or exchanged information becomes more simple as illustrated in the following
figure.
Figure 147 – Sequence Diagram showing Transmission of Data – PUSH Case to PSAP2
Figure 148 - Sequence Diagram showing Transmission of Data – PULL Case
3/23/2006 262 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Interaction Name Interaction Description IP-level?
Transmission of Data –
PUSH Case
Transmission of Data –
PUSH Case to PSAP2
Transmission of Data –
PULL Case
This type of interaction provide the capability
to the Emergency Service Personnel to
request for VAD uploading to the authorised
third party.
This type of interaction provide the capability
to the Emergency Service Personnel to
automatically send VAD files to its own
reference PSAP2.
This type of interaction provide the capability
to the authorised third party to request for
VAD to Emergency Service Vehicle Client
System.
Table 130 - Descriptions of Interactions for Transmission of Data
ID Message From Object To Object Notes
1 Request Transmission Emergency Service
Person
2 Request for VAD
Transmission
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
3 Get File Third Party (3rdP) Telematics Control
Unit (TCU-PV)
4 Marked File
Download
5 File Storing and Data
Collation
Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
Third Party (3rdP) Third Party (3rdP)
Table 131 - Transmission of Data – PUSH Case Messages
ID Message From Object To Object Notes
1 Request Transmission Emergency Service
Person
2 VADTransfer Telematics Control
Unit (TCU-PV)
3 File Storing and Data
Collation
Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
Third Party (3rdP) Third Party (3rdP)
Table 132 - Transmission of Data – PUSH Case to PSAP2 Messages
ID Message From Object To Object Notes
1 Request Available Third Party (3rdP) Telematics Control
3/23/2006 263 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Data Unit (TCU-PV)
2 Request for VAD
Transmission
Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
3 Get File Third Party (3rdP) Telematics Control
Unit (TCU-PV)
4 Marked File
Download
5 File Storing and Data
Collation
Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
Third Party (3rdP) Third Party (3rdP)
Table 133 - Transmission of Data – PULL Case Messages
A particular situation is due to Value Added Live Data such as streaming video from the
incident point to the PSAP2 (or any other authorised Third Parties) Centre. In this
situation it is possible to simplify the video-streaming process as follows.
• The Emergency Service Personnel in the ESV starts the video streaming
application which:
o Establishes a GST communication link back to PSAP2.
o Starts the Encoding Component which encodes real time video from a
connected camera.
• One or more operators in the PSAP2 start an instance of the Decoding
Component which:
o Establishes an IP link to the appropriate vehicle.
o Pulls the video stream from the ESV.
o Decodes and displays the video stream on the operators screen.
This kind of interaction is shown in the next figure.
3/23/2006 264 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 149 - Sequence Diagram showing Transmission of Live VAD
ID Message From Object To Object Notes
1 ActivateVideoStreami
ngApplication
Emergency Service
Person
2 VideoCapture I/O Device (IOD-
EV)
3 Conversion to Digital I/O Device (IOD-
EV)
4 VideoFileStoring I/O Device (IOD-
EV)
5 VideoEncoding I/O Device (IOD-
EV)
6 ActivateVADLiveStre
aming
7 Establish
Communication Link
8 Pull Video-stream
from ESV
I/O Device (IOD-
EV)
I/O Device (IOD-
EV)
I/O Device (IOD-
EV)
I/O Device (IOD-
EV)
I/O Device (IOD-
EV)
PSAP2 Operator Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 2 (PSAP2)
Telematics Control
Unit (TCU-EV)
Telematics Control
Unit (TCU-EV)
3/23/2006 265 Version 2.0

9 Telematics Control
Unit (TCU-EV)
10 DecodeLiveVideostream
DEL_RSQ_3_1 Architecture and Interface Specifications
Public Service Access
Point 2 (PSAP2)
11 Display Video Public Service Access
Point 2 (PSAP2)
12 DeactivateVADLiveS
treaming
13 DeactivateVideoStrea
mingApplication
14.1.8 Lifecycles
Public Service Access
Point 2 (PSAP2)
Public Service Access
Point 2 (PSAP2)
PSAP2 Operator
PSAP2 Operator Public Service Access
Point 2 (PSAP2)
Emergency Service
Person
I/O Device (IOD-
EV)
Table 134 - Transmission of Data – Live VAD Messages
3/23/2006 266 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 150 - Activity Diagram showing Transmission of Data
Lifecycle Name Lifecycle Description IP-level?
Transmission of Data This lifecycle describes how a request for
transmission is handled at both ESV and
Third Party sides. If one of the available VAD
files is a live type, streaming application is
activated at 3 rd Party side, whilst is the
destination of the VAD file (or files) is the
PSAP2 data are automatically pushed to the
centre.
Table 135 - Descriptions of Lifecycles for Transmission of Data
14.2 UC RSQ 008 – Processing of Data
14.2.1 Introduction
This collaboration provides the capability to process the information to be exchanged
with any authorised third party. It allows the ESV personnel to select the VAD to be sent
to the third party.
Figure 151 – Processing of Data (entities involved)
14.2.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
3/23/2006 267 Version 2.0

14.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 152 - Processing of Data
Figure 153 - Class Diagram for Processing of Data
Interface Name Interface Description IP-level?
FilesExplorer This interface is responsible for the discovery
of the files present in the File System to be
selected for the transmission.
SelectedFilesListHandler This class is responsible for handling the list
of selected files which constitute the VAD to
be lately exchanged.
Table 136 - Descriptions of Interfaces for Processing of Data
3/23/2006 268 Version 2.0

14.2.4 API Specification
Class Diagrams Elements::SelectedFilesListHandler
Type: public Class
Package: Class Diagrams Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object Telematics Control Unit (TCU-EV)
Class Diagrams Elements::SelectedFilesListHandler Methods
Method Type Notes
AddNewFileToTheList () public: void
RemoveFileToTheList () public: void
GetFilesList () public: char
ClearFileList () public: void
Class Diagrams Elements::FilesExplorer
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements::FilesExplorer Interfaces
Method Type Notes
StartSelection () public: void
FileSystemExplorer () public: char This method return the list of the files
present under a certain folder whilst
the user browse the FileSystem. This
list MUST be visualised through the
HMI in order to allow the selection.
SelectFile () public: void
DeselectFile () public: void
CloseSelection () public: void
3/23/2006 269 Version 2.0

14.2.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 154 - Sequence Diagram showing Processing of Data
Interaction Name Interaction Description IP-level?
Processing of Data This interaction allows the Emergency Service
Personnel to select the VAD to be lately
exchanged with the authorised Third Party.
Table 137 - Descriptions of Interactions for Processing of Data
ID Message From Object To Object Notes
1 Files Preparation Emergency Service
Person
Mobile Device
2 Files Transfer Mobile Device Telematics Control
Unit (TCU-PV)
3 Select Files to be
transmitted
Emergency Service
Person
Table 138 - Processing of Data Messages
Telematics Control
Unit (TCU-PV)
3/23/2006 270 Version 2.0

14.2.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 155 - State Chart Diagram showing Processing of Data
Lifecycle Name Lifecycle Description IP-level?
Processing of Data This lifecycle diagram describe the process for
discovering and selecting the VAD files
available for a data exchange with an
authorised Third Party.
Table 139 - Descriptions of Lifecycles for Processing of Data
14.3 UC RSQ 008 – Collation of Data
14.3.1 Introduction
This collaboration provides the capability to put together the VAD and to relate them to
the specific incident.
3/23/2006 271 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 156 – Collation of Data (entities involved)
14.3.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 157 - Collation of Data
3/23/2006 272 Version 2.0

14.3.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 158 - Class Diagram for Collation of Data
Interface Name Interface Description IP-level?
I-IOD-TCU-EV-DataCollator This interface is responsible for the VAD
Files Marking.
VADFileMarker This class is responsible for handling the
Marker.
Table 140 - Descriptions of Interfaces for Collation of Data
14.3.4 API Specification
Class Diagrams Elements::VADFileMarker
Type: public Class
Package: Class Diagrams Elements
Connections
• Association link from object Telematics Control Unit (TCU-EV)
Class Diagrams Elements::VADFileMarker Attributes
Attribute Type Notes
ESV_ID public : char
Incident_ID public : long
VADFileName public : char
3/23/2006 273 Version 2.0

VADMarkedFileName public : char
FileType private : char
Class Diagrams Elements::VADFileMarker Methods
Method Type Notes
GetVADMarkedFileName
(char, char, long, char)
GetVADNonMarkedFileN
ame (char)
DEL_RSQ_3_1 Architecture and Interface Specifications
public: char param: FileType [ char - in ]
param: VADFileName [ char - in ]
param: Incident_ID [ long - in ]
param: ESV_ID [ char - in ]
public: char param: VADMarkedFileName [ char - in ]
Class Diagrams Elements::I-IOD-TCU-EV-DataCollator
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object Telematics Control Unit (TCU-EV)
Class Diagrams Elements::I-IOD-TCU-EV-DataCollator Interfaces
Method Type Notes
ActivateVADFileMarking () public: void
GetVADMarkedFileList () public: char
ResetVADMarkedFileList () public: void
3/23/2006 274 Version 2.0

14.3.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 159 - Sequence Diagram showing Collation of Data
Interaction Name Interaction Description IP-level?
Collation of Data This interaction allows to automatically mark
the selected files to be lately exchanged
between the ESV-CS and the authorised
Third Party.
Table 141 - Descriptions of Interactions for Collation of Data
ID Message From Object To Object Notes
1 Request Files
Marking
Emergency
Service Person
2 Files Marking Telematics
Control Unit
(TCU-PV)
3 Files Marked Telematics
Control Unit
(TCU-PV)
Telematics Control Unit (TCU-PV)
Telematics Control Unit (TCU-PV)
Emergency Service Person
Table 142 - Collation of Data Messages
3/23/2006 275 Version 2.0

14.3.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 160 - State Chart Diagram showing Collation of Data
Lifecycle Name Lifecycle Description IP-level?
UC RSQ 008 – Collation of
Data
This lifecycle diagram describes how the
selected files to be lately exchanged between
the ESV-CS and the authorised Third Party
are automatically marked.
Table 143 - Descriptions of Lifecycles for Collation of Data
14.4 UC RSQ 008 – ESV – Receive Data
14.4.1 Introduction
This collaboration provides the capability to handle and interpret messages and data
received from an authorised Third Party involved in the rescue management (e.g.
hospital).
3/23/2006 276 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 161 – ESV – Receive Data (entities involved)
14.4.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 162 - ESV – Receive Data
3/23/2006 277 Version 2.0

14.4.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 163 - Class Diagram for ESV – Receive Data
Interface Name Interface Description IP-level?
I-TCU-EV-VAD_Handler This interface allows the capability to handle,
collate and store VAD files received from any
authorised Third Party.
I-3rdP-VAD_Handler This interface allows to handle the VAD
transmission to any ESV.
Table 144 - Descriptions of Interfaces for ESV – Receive Data
14.4.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-Service Centre
communications protocol stack. The following picture illustrates the protocol stack
adopted for the “ESV – Receive Data” Message exchange.
3/23/2006 278 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 164 – Protocol Stack – ESV – Receive Data
14.4.5 Message Structure
The process for Receiving Data by the ESV from any authorised Third Party consists
mainly of a SOAP message exchange between the involved parties. Messages exchanged
are two:
• A REQUEST message which allows the ESV to ask to the Third Party if VAD
are available for the downloading.
• A RESPONSE message which answer to the ESV if VAD are available for a
specific incident, the list of the available VAD files and where is possible to pick
up the information.
The request message MUST contains all the information needed by the Third Party to
identify the required VAD files, such as the identification of the incident which the VAD
files refer to, whilst the response message MUST contains all the information needed by
the ESV to interpret the VAD files and where is possible pick up these files.
On the basis of these considerations it is possible to define the REQUEST and the
RESPONSE messages structures. The following table describes the structure of the
SOAP Body Element of the messages. Note that all the identified information elements
identified as part of the “Body” element are MANDATORY.
Element Description Data Type
SOAP REQUEST – from ESV to Third Party
ESV Is the unique identifier of the Emergency string
3/23/2006 279 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Element Description Data Type
ESVType
Service Vehicle.
Is the type of the ESV indicating the role which
the ESV covers itself.
Element Values are encoded as follows:
Type Code Description
0 undefined
1 Ambulance
2 Police
3 Fire Brigades
ESV_IP Is the IP Address of the ESV. string
Incident Is the unique identifier of the incident. string
GPSPositionLatitude WGS84 Latitude Value (milliarcseconds) * 10 7
GPSPositionLongitude
TimeStamp
SOAP RESPONSE – from Third Party to ESV
3rdP
WGS84 Longitude Value (milliarcseconds) *
10 7
Timestamp at which the request for VAD
message has been sent out by the Third Party
Is the unique identifier of the authorised Third
Party.
3/23/2006 280 Version 2.0
int
Integer
integer
datetime
string
Incident Is the unique identifier of the incident. string
TimeStamp
VADURL
Timestamp at which the response for VAD
message has been sent out by the Third Party
It is the URL at which it is possible to GET
the available VAD files (e.g.
http://www.gstproject.org/gstrescue).
VADNumber It is the number of available VAD files Int
VADFile_X
It is the name defined as (see par. 19.8):
3rdPartyID_IncidentID_FileType_FileID.Extension
Of the VAD file number X.
Table 145 – SOAP Body Element structure
datetime
string
String
Message Encoding
The SOAP 1.2 encoded REQUEST message from the ESV to the Third Party is
represented as follows.

DEL_RSQ_3_1 Architecture and Interface Specifications
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
value
value
value
value
value
value
value
The SOAP 1.2 encoded RESPONSE message from the Third Party to the ESV is
represented as follows.
value
value
value
value
value
value
value
value
value
3/23/2006 281 Version 2.0

14.4.6 API Specification
Class Diagrams Elements::I-3rdP-VAD_Handler
Type: public abstract «interface» Interface
Package : Class Diagrams Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link from object Public Service Access Point 2 (PSAP2)
• Association link from object Third Party (3rdP)
Class Diagrams Elements::I-3rdP-VAD_Handler Attributes
Attribute Type Notes
ESV_ID public static : char Unique ESV identifier (it could be a
number or a code depending by
PSAP2 organisation)
Incident_ID public static : char Unique incident identifier (it MUST
be the same at each stage of the eCall
management chain, from PSAP1
down to hospital)
AvailableVADFilesList public static : char Array of available VAD files
Destination public static : char IP Address of the VAD files
destination point
Class Diagrams Elements::I-3rdP-VAD_Handler Interfaces
Method Type Notes
GetVADFileFromESV () public: void
RequestAvailableVAD () public: char
EstablishCommunicationLink () public: void
VADFileStoring (char, char, char) public: void param: Incident_ID [ char - in ]
param: ESV_ID [ char - in ]
param: VAD_File [ char - in ]
IncomingNewVADFileCheck () public: boolean
ActivateVADTransmission () public: void
GetAvailableVAD () public: void
3/23/2006 282 Version 2.0

SetDestination () public: void
GetCurrentDestination () public: char
Class Diagrams Elements::I-TCU-EV-VAD_Handler
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
DEL_RSQ_3_1 Architecture and Interface Specifications
• Association link to object Telematics Control Unit (TCU-EV)
Class Diagrams Elements::I-TCU-EV-VAD_Handler Attributes
Attribute Type Notes
Destination public static : char
MarkedFilesList public static : char
Incident_ID public static : char
Class Diagrams Elements::I-TCU-EV-VAD_Handler Interfaces
Method Type Notes
GetAvailableVAD () public: char It returns the list of VAD Marked
Files
ActivateVADTransmission () public: void It "makes" a request for VAD
Transmission of the Marked Files to
a 3rdParty
SetDestination () public: void It allows to set the destination of the
VAD files
GetCurrentDestination () public: char
PushVADtoPSAP2 () public: void If the destination is the own PSAP2
VAD files are automatically pushed
via a FTP PUT way.
EstablishCommunicationLink () public: void Provided by GST_OS
GetVADFileFrom3rdParty () public: void It allows to get the available VAD
files from the 3rd Party
RequestAvailableVAD () public: void This method allows to ask to the 3rd
Party if any VAD file is available to
be downloaded.
VADFileStoring (char, char) public: void param: 3rd_Party_ID [ char - in ]
param: Incident_ID [ char - in ]
3/23/2006 283 Version 2.0

IncomingNewVADFileCheck () public: void
DEL_RSQ_3_1 Architecture and Interface Specifications
14.4.7 Interactions
As it has been done for UC RSQ 008 – Transmission of Data, in this context, it is also
possible to identify two possible scenarios complementary to the previous collaboration:
• The authorised Third Party request for VAD uploading to the Emergency Service
Vehicle
• The Emergency Service Personnel request for VAD uploading to the authorised
Third Party
The first situation is a PUSH case whilst the second one represents the PULL case. In
both of these two case the process is very similar unless of a significant difference. Whilst
in the PUSH case the asks to ESV-Client System the “Please download these files from me”, in
the PULL case the ESV-Client System requests to the authorised Third Party “which files
can I download from you?”.
Even if it is a PUSH or a PULL case, the VAD transmission happens as a GET request
over HTTP.
The following pictures show these possible scenarios. It is important to note that the
PUSH case represents a subset of the PULL one.
Figure 165 - Sequence Diagram showing ESV – Receive Data – PUSH Case
3/23/2006 284 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 166 - Sequence Diagram showing ESV – Receive Data – PULL Case
Interaction Name Interaction Description IP-level?
ESV - Receive Data –
PUSH Case
ESV - Receive Data –
PULL Case
This type of interaction provides the
capability to the authorised Third Party
request for VAD uploading to the Emergency
Service Vehicle.
This type of interaction provides the
capability to the Emergency Service Personnel
request for VAD uploading to the authorised
Third Party.
Table 146 - Descriptions of Interactions for ESV – Receive Data
3/23/2006 285 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
ID Message From Object To Object Notes
1 Request for VAD
Transmission
2 Get File Telematics Control
Unit (TCU-PV)
3 Marked File
Download
4 File Storing and
Processing
5 Show Available Files
from 3rd Party
Third Party (3rdP) Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
Third Party (3rdP) Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Emergency Service
Person
Table 147 - ESV – Receive Data – PUSH Case Messages
ID Message From Object To Object Notes
1 Request Available
Data to 3rd Party
2 RequestForAvailable
Data
3 Request for VAD
Transmission
Emergency Service
Person
Telematics Control
Unit (TCU-PV)
4 Get File Telematics Control
Unit (TCU-PV)
5 Marked File
Download
6 File Storing and
Processing
7 Show Available Files
from 3rd Party
Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
Third Party (3rdP) Telematics Control
Unit (TCU-PV)
Third Party (3rdP)
Third Party (3rdP) Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Telematics Control
Unit (TCU-PV)
Emergency Service
Person
Table 148 - ESV – Receive Data – PULL Case Messages
3/23/2006 286 Version 2.0

14.4.8 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 167 - State Chart Diagram showing ESV – Receive Data
Lifecycle Name Lifecycle Description IP-level?
ESV – Receive Data This lifecycle describes how VAD are
received from the Third Party. This lifecycle
illustrates the PULL case since the PUSH one
represents a subset of the shown activities.
Table 149 - Descriptions of Lifecycles for ESV – Receive Data
14.5 UC RSQ 008 – ESV – Data Transferred
14.5.1 Introduction
This collaboration provides the capability to alert the ESV personnel that new data are
available on board.
3/23/2006 287 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 168 – ESV – Data Transferred (entities involved)
14.5.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 169 - ESV – Data Transferred
3/23/2006 288 Version 2.0

14.5.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 170 - Class Diagram for ESV – Data Transferred
Interface Name Interface Description IP-level?
I-TCU-EV-Comm-
IncomingFilesCheck
I-IOD-EV-HMI-
AlertHandler
This interface allows to check if new
incoming files are present on board. In
positive case an acoustical and/or visual alert
is activated.
This interface is responsible for the
Emergency Service Personnel alert handling.
Table 150 - Descriptions of Interfaces for ESV – Data Transferred
14.5.4 API Specification
Class Diagrams Elements::I-IOD-EV-HMI-AlertHandler
Type: public abstract «interface» Interface
Package : Class Diagrams Elements
Connections
• Association link from object I/O Device (IOD-EV)
Class Diagrams Elements::I-IOD-EV-HMI-AlertHandler Attributes
Attribute Type Notes
3/23/2006 289 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
AcousticalAlertStatus public static : boolean 0 = Deactivated
1 = Activated
VisualAlertStatus public static : boolean 0 = Deactivated
1 = Activated
Class Diagrams Elements::I-IOD-EV-HMI-AlertHandler Interfaces
Method Type Notes
ActivateAcousticalAlert () public: void
StopAcousticalAlert () public: void
ActivateVisualAlert () public: void
StopVisualAlert () public: void
GetAcousticalAlertStatus () public: boolean It returns:
0 = Deactivated
1 = Activated
GetVisualAlertStatus () public: boolean It returns:
0 = Deactivated
1 = Activated
Class Diagrams Elements::I-TCU-EV-Comm-IncomingFilesCheck
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
• Association link from object Telematics Control Unit (TCU-EV)
Class Diagrams Elements::I-TCU-EV-Comm-IncomingFilesCheck Interfaces
Method Type Notes
CheckIncomingFiles () public: boolean It returns:
0 = No New Incoming Files found
1 = New Incoming Files found
3/23/2006 290 Version 2.0

14.5.5 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 171 - Sequence Diagram showing ESV – Data Transferred
Interaction Name Interaction Description IP-level?
ESV – Data Transferred This interaction describes how the
Emergency Service Personnel is alerted of a
new incoming VAD from an authorised Third
Party.
Table 151 - Descriptions of Interactions for ESV – Data Transferred
ID Message From Object To Object Notes
1 CheckForNewIncomi
ngFiles
2 ActivateNewFilesAco
usticalAlert
Telematics Control
Unit (TCU-EV)
Telematics Control
Unit (TCU-EV)
3 AcousticalAlert I/O Device (IOD-
EV)
4 ActivateNewFilesVisu
alAlert
Telematics Control
Unit (TCU-EV)
5 VisualAlert I/O Device (IOD-
EV)
Table 152 - ESV – Data Transferred Messages
Telematics Control
Unit (TCU-EV)
I/O Device (IOD-
EV)
Emergency Service
Person
I/O Device (IOD-
EV)
Emergency Service
Person
3/23/2006 291 Version 2.0

14.5.6 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 172 - State Chart Diagram showing ESV – Data Transferred
Lifecycle Name Lifecycle Description IP-level?
ESV – Data Transferred This lifecycle describes the process always
running for checking if a new incoming file is
available on the ESV. If a new file is found
acoustical and/or visual alert are activated.
Table 153 - Descriptions of Lifecycles for ESV – Data Transferred
3/23/2006 292 Version 2.0

Chapter 15 - SECURITY
15.1 Check Security Authorisation
DEL_RSQ_3_1 Architecture and Interface Specifications
15.1.1 Introduction
This collaboration is related to UC RSQ 005, 006, 007 and 008. This collaboration is to
ensure the access to the particular functionalities only to authorised personnel.
This collaboration will be dealt within GST SEC SP. For more information, see [15] –
Chapter 6.
3/23/2006 293 Version 2.0

Chapter 16 - SYSTEM MANAGEMENT
16.1 Introduction
DEL_RSQ_3_1 Architecture and Interface Specifications
As it has been anticipated previously this work item mainly deals with the aspects related
to basic functionalities which have to be available on the GST platform independently by
the application which is running on.
Since the GST Client System is interfacing several vehicle devices (e.g. sensors, GPS
acquisition, communication device), it is important to foresee some diagnostics and selfcheck
capabilities in the system.
With particular reference to the logical view work focusing activity done (please see
paragraph 5.5) the collaborations identified within GST RESCUE underline the need of
the following main capabilities:
• Faults and errors handling (both as logged information either advising to the
personnel on board);
• Remote upgrade of the application running on the platform;
• Enabling/disabling of devices;
• Interfacing capability with external devices (e.g. Nomadic Device);
• Acknowledgement of any data transmission.
Unless of one specific collaboration, all these basic functionalities are provided by GST
OS.
16.2 UC RSQ 001 - PV - Acknowledge of Data Sent
16.2.1 Introduction
This collaboration provides the capability to acknowledge the correct reception of
emergency data (MSD) to the PV by the PSAP1. This acknowledge must be intended as
a logic acknowledge, in other words, once the MSD have been received, handled and
correctly visualised at PSAP operator side, a specific ACK message [9] is sent to the PV –
Client System. Background information can be found in paragraph 19.2.
3/23/2006 294 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 173 – UC RSQ 001 – PV – Acknowledge of Data Sent (entities involved)
16.2.2 Use Case Diagram
The following figure shows the collaboration mapped on a use case diagram.
Figure 174 - UC RSQ 001 – PV – Acknowledge of Data Sent
3/23/2006 295 Version 2.0

16.2.3 Interfaces
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 175 - Class Diagram for UC RSQ 001 – PV – Acknowledge of Data Sent
Interface Name Interface Description IP-level?
CI-PV-Interface This interface is responsible for checking if
Emergency Data have been sent and they
have been correctly received by the PSAP1 by
handling the ACK message.
Table 154 - Descriptions of Interfaces for UC RSQ 001 – PV – Acknowledge of Data Sent
16.2.4 Protocol Stack and Specification
This collaboration uses the CAG-recommended Vehicle-to-PSAP communications
protocol stack. The following picture illustrates the protocol stack adopted for the
“PSAP – Emergency Data Handling” Message exchange. When the Data Handling
process is successfully terminated, in other words, data are correctly received, an
acknowledgement message (the ACK message) is sent to the vehicle by the PSAP1
system.
3/23/2006 296 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 176 – Protocol Stack - PV – Acknowledge of Data Sent
As introduced (see par. 6.4.4), a TCAP transaction is initialised between the PSAP & the
IVS during the eCall process in order to identify clearly the eCall dialogue operations :
sendMSD, ackMSD, eosMSD into an PAN European USSD session supported by the
GSM & 3GPP. The sendMSD operation uses the component part of the TCAP protocol
to send the minimum set of data (MSD) to the PSAP.
The ackMSD & eosMSD operations are simple acknowledgement of the eCall process
without component part sent from the PSAP to the IVS in the same transaction of the
sendMSD operation.
More information can be found at paragraph 6.4.4.
The transaction container for the eCALLmsg is represented in the table [d3] below :
Field Name Description Value
OrigTransactionID Origin Transaction Entity Type +
ID : producer of the
Entity instance +
transaction (OTID)
Unique number
DestTransactionID Destination Entity Type +
Transaction ID:
Entity instance +
consumer of the
transaction
Unique number
(DTID)
Transaction Container
3/23/2006 297 Version 2.0

PDU
Component
eCALLMsgType Operations
BEGIN,
CONTINUE
END
DEL_RSQ_3_1 Architecture and Interface Specifications
sendMSD
ackMSD
eosMSD
Table 155 – Transaction container and PDU Component
16.2.5 Message Structure
ackMSD returnable operation
The following information is an abstract of ASN.1 script which describes the ackMSD
operation.
-- returnable operation table: ackMSD,eosMSD,...
Returnable OPERATION ::= {ackMSD | eosMSD, ... -- extensible --}
-- ackMSD Response done by emergency service to the public vehicle
ackMSD OPERATION ::= {
CODE local:1 -- MSD acknowledgement code
}
16.2.6 API Specification
Class Diagrams Elements::CI-PV-Interface
Type: public abstract «interface» Interface
Package: Class Diagrams Elements
Connections
Operation ackMSD
• Association link to object Communication Infrastructure PV
Class Diagrams Elements::CI-PV-Interface Interfaces
Method Type Notes
EstablishVoiceCall () public: void
SendData () public: void
DisconnectVoiceCall () public: void
To acknowledge the
MSD to the IVS
CODE local:1
3/23/2006 298 Version 2.0

CheckIfDataHasBeenSent () public: void
CheckConnectionStatus () public: void
CloseDataCall () public: void
16.2.7 Interactions
DEL_RSQ_3_1 Architecture and Interface Specifications
If ACK is not received within a
certain time window MSD message is
sent again.
Figure 177 - Sequence Diagram showing UC RSQ 001 – PV – Acknowledge of Data Sent
Interaction Name Interaction Description IP-level?
PV – Acknowledge of Data
Sent
This interaction describes the process for
which if MSD are correctly received and
handled at PSAP1 side, an ACK message is
sent to the PV-CS.
Table 156 - Descriptions of Interactions for UC RSQ 001 – PV – Acknowledge of Data Sent
ID Message From Object To Object Notes
1 CheckIfMSDareCorre
ctlyProcessed
Public Service Access
Point 1 (PSAP1)
2 ACK Public Service Access
Point 1 (PSAP1)
Public Service Access
Point 1 (PSAP1)
Telematics Control
Unit (TCU-PV)
Table 157 - UC RSQ 001 – PV – Acknowledge of Data Sent Messages
3/23/2006 299 Version 2.0

16.2.8 Lifecycles
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 178 - State Chart Diagram showing UC RSQ 001 – PV – Acknowledge of Data Sent
Lifecycle Name Lifecycle Description IP-level?
PV – Acknowledge of Data
Sent
This lifecycle describes how if MSD are
correctly received at PSAP1, an ACK message
is sent to the PV-CS. If no ACK is received at
PV-CS side, MSD message is sent once again.
Table 158 - Descriptions of Lifecycles for UC RSQ 001 – PV – Acknowledge of Data Sent
16.3 System Management Liaisons
As introduced GST RESCUE project as Service Oriented project aims at providing and
deploy a particular service architecture built on the GST Platform. The meaning of this is
that GST RESCUE contribute to the GST Technology Oriented sub-projects providing
its specific technology requirements to them to allow an effective development of the
GST Platform. For this reason all the “System Management” Collaborations impacting
on GST RESCUE are dealt within GST OS SP.
The following table provides the references to GST OS Specifications in order to better
define the completeness of the GST RESCUE proposed solution.
3/23/2006 300 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Use Case Collaboration Specific reference in [19]
UC RSQ 005
UC RSQ 006
– UC RSQ
007
UC RSQ 008
ESV - Remote Upgrade Chapter 9 – Deployment and Provisioning
ESV - Disable Device Chapter 6 – Application Runtime Environment
ESV - Report Device Faults Chapter 6 – Application Runtime Environment
ESV - Advice Device Status Chapter 6 – Application Runtime Environment
ESV – Disable Device Chapter 6 – Application Runtime Environment
ESV – Report Transmission
Faults
Chapter 6 – Application Runtime Environment
ESV – Remote Upgrade Chapter 9 – Deployment and Provisioning
ESV – Advice Device Status Chapter 6 – Application Runtime Environment
PV – Remote Upgrade Chapter 9 – Deployment and Provisioning
PV – Advise Device Status Chapter 6 – Application Runtime Environment
PV – Report Receiving
Device Faults
Chapter 6 – Application Runtime Environment
ESV – Disable Device Chapter 6 – Application Runtime Environment
V – External Device
Support
Chapter 11 – Nomadic Device Integration
ESV – Advise Device Status Chapter 6 – Application Runtime Environment
ESV – Report Device Faults Chapter 6 – Application Runtime Environment
ESV – Remote Upgrade Chapter 9 – Deployment and Provisioning
Table 159 – GST OS Liaisons Table
3/23/2006 301 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
PART 3 - IMPLEMENTATION VIEW AND
CONCLUSIONS
3/23/2006 302 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 17 - IMPLEMENTATION VIEW PART
STRUCTURE
17.1 Introduction
This part of the document is called implementation view and deals with the Reference
Implementation, in order to present a “physical” view of the model.
The Reference Implementation definition is:
Executable source code, which implements specific features of core specifications.
It will give more detailed information and facts on the collaborations defined previously,
by defining the way to move from the defined abstract models to the deployment of the
same functionalities into the “real world”.
17.2 Organisation of the Implementation View Part Chapters
Every following paragraphs dealing with a specific work item will have the same
organisational structure. This will be briefly explained here. The sections related to each
collaboration will have two sections:
• Components
In this section all the software components which implement the functionalities foreseen
for the work item. An explanation of the columns of the tables used in this section is
given in the following Table.
Title Explanation
Component Name Each component must be given a short name written in a
short manner so that the meaning is clear. Moreover also the
reference to the “WP3-WP4 Component Matrix” document is
highlighted.
Component
Description
This provides more information for a better understanding of
the component.
Interfaces Implemented This provides a list and an explanation of all the interfaces
(defined by the Class Diagrams of the Logical View) which are
implemented by the specific software component.
IP-level? This field is crossed (X) if the item corresponds to the item
defined as “invariant” (common for all sub-projects) at IPlevel
(in [3]or - for later versions - [4]).
Table 160 - Definition of Terms Used when Describing Components
3/23/2006 303 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Moreover, in order to appropriately migrating from WP3 to WP4, each component to be
provided as reference implementation to the test site for integration, implementation or
further customisation, has been identified (in terms of unique ID) and characterised in a
separate document [33]. For this reason all the components, or part of them, are also
appropriately referenced to the “WP3-WP4 Component Matrix” document.
• Nodes
In this section the most physical overview for the GST RESCUE architecture is
provided, by identifying all the hardware nodes which realise the system. An explanation
of the columns of the tables used in this section is given in the following Table.
Title Explanation
Node Name Each node must be given a short name written in a short
manner so that the meaning is clear.
Node Description This provides more information for a better understanding of
the node.
Components
Implemented
This provides a list and an explanation of all the software
components which are working on the specific hardware node.
IP-level? This field is crossed (X) if the item corresponds to the item
defined as “invariant” (common for all sub-projects) at IPlevel
(in [3]or - for later versions - [4]).
Table 161 - Definition of Terms Used when Describing Nodes
3/23/2006 304 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 18 - REFERENCE IMPLEMENTATION
18.1 Vehicle ECALL
18.1.1 Components
Figure 179 - Component Diagram for Vehicle ECALL work Item
Component Name Component
Description
IO_Handler Input and output
component that
handles the
interpretation of e.g
key pad
HMI_Handler A component that
handles display
signals
ServiceHandler
[CP-RSQ-1.0]
The component that
evaluates processes
from com handler,
data collector and
Interfaces
Implemented
IOD-PV-Interface
[PROVIDED]
V-PV-Interface
[REQUIRED]
IP-level?
3/23/2006 305 Version 2.0

CommunicationHandler
[CP-RSQ-13.0, CP-RSQ-
14.0]
HMI handler.
The component that
handles the MSD
with sending and
receiving system
messages
DataCollector The component that
collects and stores
data from sensor
handler and location
handler.
SensorHandler The component that
receives data from
sensors.
LocationHandler The component that
receives data from
location handler e.g
GPS.
18.1.2 Nodes
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 162 - Descriptions of Components
CI-PV_interface
[PROVIDED]
V-PV-Interface
[REQUIRED]
V-PV-Interface
[PROVIDED]
V-PV-Interface
[REQUIRED]
3/23/2006 306 Version 2.0
X
X

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 180 - Deployment Diagram for Vehicle ECALL work item
Node Name Node Description Components
Implemented
IOD-PV Input output and HMI
device for the personal
vehicle.
TCU-PV Telematics control unit
functions that handles
decisions with input
from IODevice-PV
and Vehicle.
Vehicle Node that is supplying
TCU-PV with sensor
and location data.
Table 163 - Descriptions of Nodes
• HMI_Handler
• IO_Handler
• ServiceHandler
• Communicatio
nHandler
• DataCollector
• LocationHandl
er
• SensorHandler
IP-level?
3/23/2006 307 Version 2.0
X
X
X

18.2 PSAP ECALL
18.2.1 Components
id PSAP ECALL .RSQ
IncomingECallDetector
Component
Diagramm
Elements::MSD
Decoder
DEL_RSQ_3_1 Architecture and Interface Specifications
Component
Diagramm
Elements::MSD
Receiver
Component
Diagramm
Elements::ECall
Handler
Component
Diagramm
Elements::RSQ
Message
Encoder Component
Diagramm
Elements::
PSAP2 Identifer
PSAP2Alert
Component
Diagramm
Elements::PSAP
Data Viewer
Component
Diagramm
Elements::PSAP
Map Mapper
Figure 181 - Component Diagram for PSAP ECALL work item
Component Name Component
Description
MSD Receiver Receives the MSD
from the Network
Infrastructure
PSAP2 Identifier Selects the rights
PSAP2 using
geographical and
political attributes
Interfaces
Implemented
IncomingECallDetecto
r (Listen to the
Network for incoming
calls to raise events for
further eCall handling)
PSAP2Alert (Using for
availability Test of
PSAP2 and start
alerting to PSAP2)
IP-level?
3/23/2006 308 Version 2.0

E-Call Handler
[CP-RSQ-15.0, CP-
RSQ-16.0]
Handles all the eCall
activities and follow
ups to select and send
the data to PSAP2
Map Mapper Uses the coordinates of
the incident and shows
them on a map to use
by the PSAP1 operator
Data Viewer
[CP-RSQ-2.0]
MSD Decoder
[CP-RSQ-17.0]
RSQ Message Encoder
[CP-RSQ-3.0]
Shows the MSD Data
and additional
Information as a
readable XML
document
Decodes the MSD
message coming from
the vehicle
Encodes the RSQ
related XML Message
for the PSAP2
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 164 - Descriptions of Components
3/23/2006 309 Version 2.0
X
X
X
X

18.2.2 Nodes
dd Deployment Diagrams.RSQ
Deployment Diagram Elements::PSAP1 User Interface
Component
Diagramm
Elements::MSD
Decoder
Component
Diagramm
Elements::MSD
Receiver
Component
Diagramm
Elements::PSAP
Data Viewer
DEL_RSQ_3_1 Architecture and Interface Specifications
Component
Diagramm
Elements::PSAP
Map Mapper
PSAP1 ECall Handler
Component
Diagramm
Elements::ECall
Handler
Component
Diagramm
Elements::RSQ
Message
Encoder
Component
Diagramm
Elements::
PSAP2 Identifer
Figure 182 - Deployment Diagram for PSAP ECALL work item
Node Name Node Description Components
Implemented
PSAP1 Ecall Handler Background service to
realize an automated
eCall data extraction
and eCall handling
PSAP1 User Interface Show the incoming
eCall to the PSAP1
• PSAP2
Identifier
• MSD Receiver
• ECall Handler
• MSD Decoder
RSQ Message Encoder
• PSAP Data
Viewer
IP-level?
3/23/2006 310 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Operator PSAP Map Mapper
Table 165 - Descriptions of Nodes
18.3 PSAP Rescue Management
18.3.1 Components
cd PSAP Rescue Management
PSAP1DataLink
Component
Diagram
Elements::RSQ
Message
Receiver
Component
Diagramm
Elements::PSAP
Map Mapper
Component Diagram
Elements::ESVehicle
Selector
Component
Diagram
Elements::
PSAP2 eCall
Handler
Component
Diagramm
Elements::PSAP
Data Viewer
i-VehicleManager
Component Diagram
Elements::
PSAP2_DeploymentHandler
ESV-PSAP2-Interface
Figure 183 - Component Diagram for PSAP Rescue Management work item
Component Name Component
Description
RSQ Message Receiver Receives the RSQ”
message
PSAP1
from the
Map Mapper Uses the coordinates of
the incident and shows
them on a map to use
by the PSAP1 operator
Data Viewer
[CP-RSQ-4.0]
Shows the MSD Data
and additional
Information as a
Interfaces
Implemented
IP-level?
PSAP1DataLink X
3/23/2006 311 Version 2.0
X

eadable XML
document
E-Call Handler Handles all the eCall
activities and follow
ups to select and send
the data to ESV
PSAP2_DeploymentH
andler
ESVehicle Selector
[CP-RSQ-5.0]
This component
provide the capability
to detect the “Accept
Deployment” Message
and, if it is the case, to
search for another
available ESV.
Give an advise of
available rescue
vehicles to the PSAP2
operator and let him
choose the right one to
inform about the
incident.
DEL_RSQ_3_1 Architecture and Interface Specifications
• HMI-IOD-
Interface
[PROVIDED]
I-VehicleManager
[REQUIRED]
Table 166 - Descriptions of Components
3/23/2006 312 Version 2.0
X

18.3.2 Nodes
dd Deployment Diagrams.RSQ
Component
Diagramm
Elements::PSAP
Data Viewer
Component
Diagram
Elements::RSQ
Message
Receiver
DEL_RSQ_3_1 Architecture and Interface Specifications
Deployment Diagram Elements::PSAP2 User Interface
Component
Diagramm
Elements::PSAP
Map Mapper
Deployment Diagram Elements::PSAP2 ECall Handler
Component
Diagram
Elements::
PSAP2 eCall
Handler
Component Diagram
Elements::
PSAP2_DeploymentHandler
communicate
Deployment Diagram Elements::TCU-EV
Component Diagram
Elements::
EmergencyDataReceiver
Component
Diagram
Elements::
ESVehicle
Selector
Figure 184 - Deployment Diagram for PSAP Rescue Management work item
Node Name Node Description Components IP-level?
3/23/2006 313 Version 2.0

PSAP2 Ecall Handler Background service to
realize an automated
eCall data extraction
and eCall handling
PSAP2 User Interface Show the incoming
eCall to the PSAP2
Operator
TCU-EV This node implements
the capability to detect
and to handle the
received Emergency
Data Message.
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 167 - Descriptions of Nodes
18.4 PSAP to Vehicle Communication
18.4.1 Components
Implemented
• RSQ Message
Receiver
• ECall Handler
PSAP2_DeploymentH
andler
• PSAP Data
Viewer
• PSAP Map
Mapper
ESVehicle Selector
EmergencyDataReceiv
er
Figure 185 - Component Diagram for PSAP to Vehicle Communication work item
Component Name Component
Description
UserInterface This component is
responsible for
handling the HMI in
order to alert the ESV
Personnel of an
incoming Emergency
Interfaces
Implemented
• IIOD-
EVEmergencyServi
cePersonnelAlert
[PROVIDED]
3/23/2006 314 Version 2.0
X
X
IP-level?

EmergencyDataReceiv
er
[CP-RSQ-6.0]
18.4.2 Nodes
Data Message.
This component is
responsible for
detecting and handling
incoming Emergency
Data Messages and to
automatically set up a
voice link with the
PSAP2 operator.
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 168 - Descriptions of Components
• ITCU-
EVIncomingData
MessageDetector
[PROVIDED]
• ITCU-
EVSetUpVoiceLin
k [PROVIDED]
Figure 186 - Deployment Diagram for PSAP to Vehicle Communication work item
Node Name Node Description Components
Implemented
IP-level?
IOD-EV This node implements
the capability to alert
the ESV personnel of
• UserInterface X
an incoming
Emergency Data
Message through the
HMI.
TCU-EV This node implements
the capability to detect
and to handle the
received Emergency
Data Message.
Table 169 - Descriptions of Nodes
• EmergencyDat
aReceiver
3/23/2006 315 Version 2.0
X

18.5 ESV Rescue Management
18.5.1 Components
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 187 - Component Diagram for ESV Rescue Management work item
Component Name Component Description Interfaces
Implemented
EmergencyDataHandl
er
[CP-RSQ-7.0]
This component is
responsible for the
onboard received
emergency data handling.
It also interact with the
HMI for the Emergency
Data Visualisation.
UserInterface This component provides
the capability to detect if
the HMI button has been
pressed by the ESV
personnel.
ESV_DeploymentHa
ndler
This component provides
the capability to send an
“Accept Deployment”
message to the PSAP2, by
pressing a button made
available by the HMI.
PSAP2_Deployment This component provide
the capability to detect the
• IIOD-
EVEmergencyData
Displayer
[PROVIDED]
• ITCU-
EVIncomingData
MessageDetector
[REQUIRED]
• HMI-IOD-
Interface
[PROVIDED]
• I-
PSAP2Communica
tor [REQUIRED]
• HMI-IOD-
Interface
IP-level?
3/23/2006 316 Version 2.0

Handler “Accept Deployment”
Message and, if it is the
case, to search for another
available ESV.
18.5.2 Nodes
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 170 - Descriptions of Components
[PROVIDED]
• I-VehicleManager
[REQUIRED]
Figure 188 - Deployment Diagram for ESV Rescue Management work item
Node Name Node Description Components
Implemented
IP-level?
IOD-EV This node implements
the capability of the
• User Interface X
GST platform to
handle HMI “Accept
Deployment” button.
TCU-EV This node implements
the capabilities to
display Emergency
Data received from
• EmergencyDat
aHandler
• ESV_Deploym
3/23/2006 317 Version 2.0
X

PSAP2 and to
acknowledge the
PSAP2 the acceptance
for the rescue
deployment.
PSAP2 This node implements
the capability to detect
and to handle the
“Accept Deployment”
Message.
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 171 - Descriptions of Nodes
entHandler
• PSAP2_Deploy
mentHandler
3/23/2006 318 Version 2.0

18.6 ESV Driver Support
18.6.1 Components
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 189 - Component Diagram for ESV Driver Support work item
Component Name Component
Description
SOAP Client Client residing in the
ESV and implementing
the SOAP Layer to
issue requests to
PSAP2
Interfaces
Implemented
RouteRequest
SOAP server Server residing in the RouteRequest
IP-level?
3/23/2006 319 Version 2.0

PSAP2 and
implementing the
SOAP Layer to
respond to requests
ESV
EV-TCU Telematic Control
Unit. Is the computing
platform inside the
ESV
EVPositioningDevice GPS positioning
device. Gives the ESV
coordinates.
Keypad Input device
TouchScreen Input device
Display Output device
GraphicRendering Libraries for graphic
rendering
PhysicalWarning Component able to
warn (visual and audio
alarms) the user for
every relevant event
related to Navigation
system
IncidentDataServer Component residing in
the PSAP2 and
devoted to provide
incident data (route,
maps, environmental
data, incident location)
TextToSpeechRenderi
ng
TTS component
PSAP2 Service centre
connected to the ESV
RouteManagement
[CP-RSQ-8.0]
Is the component that
deals with the route
management:
• ESV position
• Route request
• Maps
• Display
preparation
User commands
DEL_RSQ_3_1 Architecture and Interface Specifications
Response
I-PSAP2-
CalculateRouteOptions
3/23/2006 320 Version 2.0

HMIDriver User interface for the
ESV crew
NavigatorDriver Provide the layer to
transparently
communicate with the
Navigation System.
This component will
implement a general
interface to the OEM
navigator of choice.
OEM Navigator OEM navigation
system (off board)
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 172 - Descriptions of Components
I-IOD-EV-
DisplayRouteOptions
I-IOD-EV-
AcceptRouteOption
3/23/2006 321 Version 2.0

18.6.2 Nodes
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 190 - Deployment Diagram for ESV Driver Support work item
3/23/2006 322 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Node Name Node Description Components Implemented IP-level?
PSAP2 Service centre IncidentDataServer
PSAP2
TCU-EV TCU of the
emergency service
vehicle
IO_EV Input/output
system
EV-PositioningDevice
EV-TCU
RouteManagement
GraphicRendering
Keypad
PhysicalWarning
TouchScreen
Display
TestToSpeechRendering
HMIDriver
Table 173 - Descriptions of Nodes
3/23/2006 323 Version 2.0

18.7 Vehicle to Vehicle Communication
18.7.1 Components
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 191 - Component Diagram for Vehicle to Vehicle Communication work item
Component Name Component
Description
GPSData This component is
responsible for retrieving
location data from the
Vehicle Location Device
EmergencyInfo This component is
responsible for retrieving
the emergency vehicle
information (e.g. vehicle
type)
InfoRetriever This component is
responsible for collating
data from GPSData and
EmergencyInfo
Interfaces Implemented IP-level?
3/23/2006 324 Version 2.0
X

Component Name Component
Description
UserInterface The UserInterface is
responsible for providing
HMI to allow control of
the system
MessageSender
MessageEncoder
[CP-RSQ-9.0]
The MessageSender is
responsible for managing
the collation and
encoding of data by other
components
The MessageEncoder is
responsible for
constructing the warning
message
DataTransmitter The DataTransmitter is
responsible for
transmitting the warning
message
WarningMessage The WarningMessage is
used to encapsulate data
as it is encoded by the
MessageEncoder
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 174 - Descriptions of Components
Interfaces Implemented IP-level?
I-ESP-IOD-EV
I-IOD-EV-TCU-EV
I-TCU-EV-CI-EV
3/23/2006 325 Version 2.0

18.7.2 Nodes
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 192 - Deployment Diagram for Vehicle to Vehicle Communication work item
Node Name Node Description Components
Implemented
IP-level?
3/23/2006 326 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Node Name Node Description Components
Implemented
Vehicle Location Device The Vehicle Location
Device represents the
hardware device used
to retrieve GPS
location data.
Comms Infrastructure
ESV
The Comms
Infrastructure ESV
represents the
protocols, connection
management, etc. used
during the transmission
of the warning
messages
IOD-ESV The IOD-ESV
represents the HMI
used to control the
service running on the
TCU-ESV.
TCU-ESV The TCU-ESV
represents the main
processor unit running
the core software.
Table 175 - Descriptions of Nodes
To be provided by Open
Systems
To be provided by Open
Systems
User Interface
NOTE: This will not be
developed as a reference
implementation
ESV Blue Wave / Virtual
Cones Service
IP-level?
3/23/2006 327 Version 2.0
X
X

18.8 Public Vehicle Driver Support
18.8.1 Components
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 193 - Component Diagram for Public Vehicle Driver Support work item
Component
Name
Component
Description
Interfaces Implemented IP-level?
DataReceiver DataReceiver This component is responsible for
receiving the warming message
MessageReceiver MessageReceiver This component is responsible for
collating data from GPSData and
DataReceiver
GPSData GPSData This component is responsible for
retrieving location data from the
Vehicle Location Device
MessageDecoder
[CP-RSQ-10.0]
MessageDecoder The MessageDecoder is
responsible for de-constructing the
warning message and calculating
whether it is suitable for display to
the user
WarningMessage WarningMessage The WarningMessage is used to
manage data as it is decoded by the
I-TCU-
PV-CI-
PV
I-IOD-
PV-TCU-
PV
3/23/2006 328 Version 2.0

Component
Name
Component
Description
DEL_RSQ_3_1 Architecture and Interface Specifications
Interfaces Implemented IP-level?
MessageDecoder
UserInterface UserInterface The UserInterface is responsible
for providing HMI to allow a
means of display and user input for
the system
18.8.2 Nodes
Table 176 - Descriptions of Components
Figure 194 - Deployment Diagram for Public Vehicle Driver Support work item
I-MP-
IOD-PV
3/23/2006 329 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Node Name Node Description Components
Implemented
IOD-PV The IOD-PV
represents the HMI
used to display
warnings from the
service running on the
TCU-PV.
Vehicle Location
Device
The Vehicle Location
Device represents the
hardware device used
to retrieve GPS
location data.
TCU-PV The TCU-PV
represents the main
processor unit running
the core software.
Comms Infrastructure
PV
The Communication
Infrastructure PV
represents the
protocols, connection
management, etc. used
when receiving the
warning messages
Table 177 - Descriptions of Nodes
User Interface
NOTE: This will not
be developed as a
reference
implementation
To be provided by
Open Systems
PV Blue Wave /
Virtual Cones Listener
Service
To be provided by
Open Systems
IP-level?
3/23/2006 330 Version 2.0
X
X

18.9 Vehicle to Centre Communication
18.9.1 Components
Component
Name
ESV-IOD-
DeviceManager
ESV-IOD-HMI-
Component
ESV-TCU-VAD-
Handler
[CP-RSQ-12.0]
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 195 - Component Diagram for Vehicle to Centre Communication work item
Component Description Interfaces
Implemented
This component is responsible
for handling and interfacing
external devices such as video
device, mobile data terminal or
PDA.
This component allows the
VAD files browsing capability
to the Emergency Service
Personnel and it handle the
alert (visual and/or acoustical)
system.
This component is responsible
for VAD handling and
transmission at ESV side.
• I-IOD-EV-
VideoDevice
[PROVIDED]
• FilesExplorer
[PROVIDED]
• I-IOD-EV-HMI-
AlertHandler
[PROVIDED]
• IOD-TCU-EV-
DataCollator
[PROVIDED]
• TCU-EV-Comm-
IncomingFilesChe
IP-level?
3/23/2006 331 Version 2.0

3rdP-VAD-
Handler
[CP-RSQ-11.0]
PSAP2-
LiveVAD_Handl
er
18.9.2 Nodes
This component is responsible
for VAD handling and
transmission at any authorised
Third Party side.
This component allows the
PSAP2 operator to
automatically set up and run a
video streaming link between
the ESV which acts as a Video
Server and the PSAP2 which
acts as a Client.
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 178 - Descriptions of Components
ck [PROVIDED]
• I-TCU-EV-
VAD_Handler
[PROVIDED]
• I-3rdP-
VAD_Handler
[PROVIDED]
• I-PSAP2-TCU-
EV-LiveVAD
[PROVIDED]
Figure 196 - Deployment Diagram for Vehicle to Centre Communication work item
Node Name Node Description Components Implemented IP-level?
IO-EV This node implements the
capability of handling
HMI and interfacing
external devices.
TCU-EV This node implements the
capabilities for VAD
handling and transmission
• ESV-IOD-
DeviceManager
• ESV-IOD-HMI-
Component
• ESV-TCU-VAD-
Handler
3/23/2006 332 Version 2.0
X
X

at ESV side.
Third Party This node implements the
capabilities for VAD
handling and transmission
at Third Party side.
PSAP2 This node implements the
capability to automatically
set up and run a video
streaming link between
the ESV and the PSAP2
itself.
18.10 Security
DEL_RSQ_3_1 Architecture and Interface Specifications
Table 179 - Descriptions of Nodes
• 3rdP-VAD-Handler
• PSAP2-
LiveVAD_Handler
No reference implementation is expected for this work item within GST RESCUE. This
work item will be dealt within GST SEC SP. For more information, see DEL_SEC_3_1
Architecture and interface specifications [15].
18.11 System Management
No reference implementation is expected for this work item within GST RESCUE. This
work item will be dealt within GST OS SP. For more information, see DEL_OS_3_1
Architecture and interface specifications [19].
3/23/2006 333 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 19 - ARCHITECTURAL ISSUES AND DECISIONS
This chapter describes all the issues related to non-functional and physical specifications
for the RSQ subproject, as well as the analysis performed and the resolution, when
applicable.
19.1 Vehicle sensors to be triggered
19.1.1 Objectives
The objectives of this investigation are:
• To investigate the triggers which activate an in-vehicle e-call.
• To investigate the thresholds which activate an in-vehicle e-call.
• To establish a common terminology for the RESCUE SP and for GST.
This study is only describing the triggers and thresholds for e-calls, complete in-vehicle ecall
system design recommendations and e-call handling are specified in E-MERGE D3.0
Specifications of the European in-vehicle emergency call (IST-2001-34061) [9]. In the
above mentioned specification, recommendations for the following can be found:
minimum set of data (MSD), full set of data (FSD), HMI, good Samaritan calls, false
calls, data storage, redundancy, transport protocol and communication flow.
19.1.2 Triggers
Definition of a sensor
A sensor in this document is a mechanical or electrical device for the collection of
numeric values e.g. accelerometer. A sensor is also a device for collection of status
information e.g. door lock and the status can e.g. be locked or unlocked.
Definition of a trigger
A trigger as defined in this GST RESCUE document is a signal from either one sensor or
a set of sensors that has reached a threshold value. The sensors and threshold values are
also shown in paragraph 19.1.3.
Sensors to be used as the e-call trigger
The triggers in the list below can be used to trigger an automatic emergency call. An
absolute minimum of two triggers are required to start the call.
• Front crash sensor 1
• Front crash sensor 2
• Rear crash sensor
• Side crash sensor
• SRS airbag sensor
• Roll over / vehicle inclination sensor
Extended information sensors
3/23/2006 334 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Information from the following sensors will help the emergency service to determine
which response to give to an accident but are not required for an automatic e-call. In
addition to this it is recommended to send information about all sensors that triggered.
These are listed here as an example of information that should be sent to the service
provider.
• In door temp sensor
• Accelerator sensor
• Driver seatbelt buckle sensor
• Passenger seatbelt buckle sensor
• Pedestrian protection contact sensor
• Vehicle speed sensor
• Tire pressure sensor
• Seat status:
o Number of passengers and their location.
o Passenger’s seat belt status.
o Passenger’s airbag status.
• Vehicle’s velocity (pre-impact, at impact time).
• Lights status – status and failure indications of the vehicle’s different lamps and
lights.
• Brake status – status indication of different brake system components.\
• Fuel level
• Vehicle’s external conditions:
o External temperature.
o Indication of ice on road.
o Rain sensor.
o External light sensor.
o Rain wiper status.
• Crash Position
• Crash Severity
• X acceleration – peak value
• Y acceleration – peak value
• Z acceleration – peak value
• X acceleration – mean value
• Y acceleration – mean value
• Z acceleration – mean value
3/23/2006 335 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• Time to acceleration peak
19.1.3 Thresholds
Thresholds for the e-call triggers
There are two types of thresholds for the triggers, where one is a numerical value and
one is a state either triggered or not triggered. The following tables show the value or the
different states of each trigger.
Sensor State
Front crash sensor 1 Triggered / Not triggered
Front crash sensor 2 Triggered / Not triggered
Rear crash sensor Triggered / Not triggered
Side crash sensor Triggered / Not triggered
SRS airbag sensor Triggered / Not triggered
Value
Roll over / vehicle inclination sensor 50 degrees angle
Time between triggers
Table 180 - List of thresholds for the e-call triggers
The maximum time between two independent triggers to be used is 5 seconds.
Key position
An automatic e-call can only be triggered when the key is in position 1 or 2. Key
positions are 0, 1, 2 and 3. Where 0 is voltage off, 1 is voltage on, 2 engine on and 3 is
cranking.
19.1.4 Source Document
• Triggers and Thresholds for in-vehicle e-call - v 1.0
[DOC_GST_RSQ_Triggers_v1_0.doc]
19.2 eCall service Messages
19.2.1 Problem identification
Keeping up the out coming results from the E-MERGE project, GST RESCUE defines
a special set of data which should be sent by the IVS to the PSAP, by adopting the main
concepts and results already defined by E-MERGE. These set of data is characterised by
some information regarding vehicle status, position and parameters for unique
identification.
3/23/2006 336 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
The data are acquired by the Client System from the Public Vehicle sensors who is also
responsible to code the Data Message. Being one of the most important conceptual
assumption of GST that the Public Vehicle is an external entity which contains the
appropriate vehicle sensors and the Vehicle Client System and is able to communicate
with the external world, the transmission management is out of the scope.
However, the strategy to manage the messages exchange between the PV Client System
and the PSAP1 represents one of the key issue for the project and for the eCall service.
19.2.2 Decision
The eCall service use case is based on the existence of two main actors which are:
• the terminal (in GST RESCUE SP is the CS-PV – Public Vehicle Client System)
and
• the PSAP1
and the interaction among them is composed by 4 phases:
• Emergency request;
• Emergency reply;
• Voice call;
• Emergency terminate message.
The eCall service messages are:
Figure 197 - Representation of sequence events
3/23/2006 337 Version 2.0

ID Message From Object To Object Notes
1 MSD A Public Vehicle
Client System
(CS-PV)
2 MSD B Public Service
Access Point 1
(PSAP1)
3 MSD C Public Service
Access Point 1
(PSAP1)
DEL_RSQ_3_1 Architecture and Interface Specifications
Public Service
Access Point 1
(PSAP1)
Public Vehicle
Client System
(CS-PV)
Public Vehicle
Client System
(CS-PV)
Figure 198 – eCall Service Messages
It is the Emergency Call Request
message (also referred to as
“minimum set of data” or MSD)
It is the Emergency Call Reply
message (acknowledgement that
data has been correctly received at
the PSAP1 side, also referred to
as ACK)
It is the Emergency Call
Terminate message (tells the CS-
PV that service is ended at PSAP1
side, hang up by operator, also
referred to as “End Of Service”.
shortening “EOS”)
MSD A, MSD B (also ACK), MSD C (also EOS) refers to the order of communication
in which they occur.
19.2.3 Source Document
• E-MERGE D4.0 “The E-MERGE developed system”
3/23/2006 338 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
19.3 How to transmit MSD from Vehicle to PSAP1 – USSD
Protocol
19.3.1 Description
Most of mobile users have already typed some codes on mobile device, looking like
"*#06#" or "*#92702689# "? These codes are part of a general services plan.
But not all the codes (typed on a mobile phone) are used the same way:
• Some of the codes are used directly by the mobile terminal or by the SIM
card (e.g.: changing the PIN code, getting the terminal identification
number (IMEI)). The unused codes are forwarded to the MSC⁄VLR.
• Some of the codes can be used by the MSC⁄VLR. The unused codes are
forwarded to the HLR.
• Some of the codes are then used by the HLR. These codes are called
"standard GSM supplementary services" codes (e.g.: call barring, call
forwarding). The unused codes are forwarded to the USSD Centre.
• The USSD centre analyses the received codes, and forwards each code to
the appropriate USSD application server. There is no restriction on the
possible uses of USSD.
USSD is server oriented.
19.3.2 Definition
USSD (Unstructured Supplementary Services Data) allows bi-directional and half-duplex
connections between a handset and a USSD application server, exchanging plain text
messages with each other. Contrary to SMS, USSD offers session-oriented connections.
Each USSD message can contain up to 182 user characters (only 160 for SMS) and is
completely transparent for the handset and the mobile network. USSD is borne by the
SDCCH channel on the signalling radio interface.
USSD services are available on standard networks GSM⁄GPRS⁄UMTS (ETSI, 3GPP),
they function in connected mode.
There are two implementation level:
• USSD phase 1: In this stage, initially defined in GSM specifications, USSD offers
a connection to the network initiated by the handset. The USSD service platform
sends a response and the session is closed. So, only one request and its response
are exchanged per session in USSD Phase 1.
• USSD phase 2: Specified more recently, USSD phase 2 offers a session that may
be opened either by the handset or by the USSD application server. A session in
USSD Phase 2 may be composed of many USSD messages (request and response
messages). USSD Phase 2 can provide interactive services with a user-friendly
ergonomic interface.
USSD services rely mainly on a USSD Center (USSD-C) which routes USSD messages
from handsets to USSD application servers and vice-versa. USSD-C may be part of the
intelligent network server (IN). A synthetic architecture is defined below:
3/23/2006 339 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 199 – USSD service architecture (extract from CEPT ECC)
USSD traffic is routed from/to HLRs to USSD-C through STP (Signalling Transfer
Point) elements. Thus SS7 links (timeslots, signalling link codes and link sets), MTP
(Message transfer Part) routes and SCCP (Signalling Connection Control Part) points
should be configured in USSD-C.
19.3.3 Reference Normative
From a normative point of view, messages USSD are based on channel SDCCH on the
interface of radio indication. Reference specification can be found in the following
documents:
• 3G TS 22.090 v4.0.0 Unstructured Supplementary Service Data Stage 1 (Release
4)
• 3G TS 23.090 v4.0.0 Unstructured Supplementary Service Data Stage 2 (Release
4)
• 3G TS 24.090 v4.0.0 Unstructured Supplementary Service Data Stage 3 (Release
4)
19.3.4 Deployment:
Three European countries - Austria, Finland and Ireland - regulate the use of numbers
for these services suggested in the mobile networks. Into all the other countries of
Europe, the provisions concerning the use of resources of classification described above
were introduced without any consultation nor explicit authorization of the proper
authorities.
In a roaming situation, some USSD codes are forwarded to the home network of the
subscribers (HPLMN: Home Public Land Mobile Network); some are forwarded to the
visited network (VPLMN: Visitor Public Land Mobile Network) according to their
syntax. This allows implementing services used by visiting clients.
Orange France with the Ussd-c platform supports transactions USSD-1 & USSD-2
initiated by the Mobile.
USSD is supported by the network and it is largely deployed in the terminals. No
software to be added.
3/23/2006 340 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
19.3.5 Source Document
• GST Application Protocol stack for Emergency call in the RESCUE sub project -
USSD description - v 1.0 [050325_GST_CAG_App_Protocol_USSD_V1.doc]
19.4 Guidelines for Emergency Data Visualisation at PSAP
Operator
19.4.1 Problem identification
The PSAP technical requirements collected by CGALIES project, and lately taken up by
E-MERGE, state that the accuracy of location information related to an incident should
not be constrained by the operational systems in use by the EA. These include mapping
displays, GIS and incident management systems [11]. At present, not all EAs make use of
digital maps, and continue to rely upon text based systems and displays.
• Text display: Showing the latitude and longitude to the operator of a text display is
meaningless. Instead, one would need to convert the information into an
understandable frame of reference such as a street name or an area that could be
easily recognised by the operator.
• Digital map display: The display of fixed call location 6 is relatively straightforward
since the location will be referred to a specific billing or installation address.
Provided that the digital display is supported by an appropriate gazetteer, then
such an address may be readily displayed.
Moreover, E-MERGE addressed that the following operator infrastructures are
mandatory in addition to the normal PSAP operator Infrastructures for handling an eCall
[9].
Additional operational infrastructures are:
• Software to receive and visualise Minimum set of E-MERGE data.
• Maps for the visualisation of the accurate position, preferably Digital mapping
software.
• Browser software to log into an internet address. If the communication over
internet is secured, security software is also needed.
• Software to send case data to the Service Provider.
19.4.2 Decision
Focusing on what MUST be visualised to the PSAP Operator, CGALIES addressed the
choice for a double display work station at PSAP for the operators which could display
on two coupled screen the emergency information kept by the caller (even if
automatically sent) and the incident location on a digital map support.
Following the guidelines provided by CGALIES and E-MERGE, GST RESCUE
confirm the adoption of the same approach for Emergency Data Visualisation at PSAP
Operator.
6
CGALIES project focused on location information for Emergency Services, so both fixed and mobile
emergency calls are considered.
3/23/2006 341 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 200 – PSAP Operator Work Station
19.4.3 Arguments
Since the same guidelines are valid for both PSAP 1 st and 2 nd stage, the map support
system should visualise on the same map also other traffic related information like traffic
conditions, weather conditions, works in progress, etc. in order to complete the overview
about the environment of the incident point.
It needs a strong synergy with EFCD project.
Moreover, at PSAP2 level the operator should also visualise the current position of all
the controlled ESV available (and involved in an already rescue process) on the network.
19.4.4 Source Document
• E-MERGE D3.0 “Specifications of the European in-vehicle emergency call”
• CGALIES “Final Report”
19.5 Human Factors Guidelines for Route Navigation System
19.5.1 Problem identification
Human factors guidelines are useful in the interface aspects of the design. Selection of
font size is an example. The main issues related to human factors guidelines to be
considered during HMI design for the Route Guidance System (see Use Case 005) are
represented by:
1. Map Orientation (heading up vs. north up).
2. Map Presentation vs. "Guidance" Information Displays (e.g., turn arrows).
3. Dynamic Map Scaling.
4. Dynamic Labelling Techniques.
5. Adaptive Displays.
6. Fail-Safe Design.
7. 2D vs. 3D maps rendering
8. Voice guidance (voice rendering of route path)
9. Usability
3/23/2006 342 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
10. Distraction: how to meet a “drive-safely” approach
11. Additional information about route to give to the user; for example: Target is
identified by the system with GPS location coordinates format: the user would
like to have this location also translated to a human readable street address.
Quantity and quality of that additional information must be carefully designed.
12. Traffic and other environmental information should be represented with respect
of the available route, but this can compromise the readability of the other
information (see previous bullet)
19.5.2 List of Alternative Solutions
For each previous bullet a consideration/solution is described:
1. Heading up is a better solution. It is widely used and shows the route with
respect to the actual vehicle direction
2. To support system openness the design shall allow scalability and adaptation.
Map presentation is usually present in more expensive hardware while the
other alternative is mostly used with reduced-capability devices.
3. Scale shall be selected by the user depending on its previous knowledge of
the proposed route. A scale default is difficult to fix due to subjective user
perception considerations.
4. N/A
5. Adaptive interface can be achieved with XML description of the GUI. The
description is the interpreted depending on the environment (display size,
graphical capabilities, audio support and so on).
6. N/A
7. 3D visualization is top of current technology, but 2D shall be supported as
well for scalability reasons
8. Adoption of a text to speech module to “read” each route segment
description. For test site purpose free of charge tools are usually available
through universities (as example: http://festvox.org/ )
9. Reduce and rationalize the functions available to the user. Specific study is
needed here.
10. Select appropriate set of additional information and define user profiles
standards for RSQ to know when and how to provide that information to the
user.
11. See bullet 10.
19.5.3 Decision
Maps, routes and other geographic data are given in GML format that allows great
flexibility for the user interface. With this kind of data representation the following
solutions are achievable with limited effort (numbers refers to the list in the previous
section): 2, 3, 5, 10, 11.
The decision for the other listed aspects is not impacted by the data representation
available to the ESV navigation user interface:
3/23/2006 343 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• (1) Head up rendering of the route is the solution that shall be adopted; the user
interface shall rotate the route graphics with respect to the vehicle head-up.
• (7) 2D representation only will be provided.
• (8) The GML representation contains “directions” directives for the user, this
may be used by a TTS module. Test Site may wants to experiment this, but the
TTS adoption looks not achievable with current project resources.
• (9) Specific study may be accomplished in Test Sites
19.6 HMI considerations for the use of the Blue Wave / Virtual
Cones application in an Emergency Services Vehicle
19.6.1 Problem identification
The fundamental problem is how to provide the information required by the emergencyservices
vehicle driver concisely and ergonomically so that it does not distract the driver.
Many of the emergency-services vehicle HMI issues are the same as those for the public
vehicle discussed below.
1. Ease of use. It must be possible for the emergency-services driver to quickly
and easily activate the warning message.
2. Feedback. The driver should be notified that the warning message has been
successfully transmitted, and should be periodically reminded that the
message is still being sent.
3. Distraction. As the driver is likely to use the system during an emergency
incident that will require his full concentration, it is important that the Blue
Wave / Virtual Cones application does not distract the driver from his
primary task.
4. Mode of communication with the driver. This could be audio or visual, or
a combination of both.
5. Interaction. If the driver is required to interact with the system (e.g. accept a
warning message or silence an alarm) then he is more likely to be distracted.
19.6.2 List of Alternative Solutions
1. If a visual display is to be used then this should be positioned as close as
possible to the driver’s normal line of sight.
2. If driver interaction is required then the HMI should not require long and
uninterruptible sequences of interactions.
3. The HMI may be able to use universally understood graphical symbols rather
than text so that it is language independent.
4. Only relevant, timely and accurate data should be displayed so that the driver
is not distracted by unnecessary and irrelevant information.
5. It is possible that the system could be connected to the existing activation
controls for the flashing lights and siren so that no further activation is
required.
3/23/2006 344 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
19.6.3 Decision
A final decision about the HMI considerations can only be taken after prototyping, and
consultation with vehicle manufacturers, emergency services, and other related projects
(e.g. AIDE, e-Safety WG-HMI).
19.7 HMI considerations for the presentation of Blue Wave /
Virtual Cones information in a Public Vehicle
19.7.1 Problem identification
The fundamental problem is how to provide the information required by the publicvehicle
driver concisely and ergonomically so that it does not distract the driver. There
are several different aspects to this problem:
1. Conciseness.
2. Clarity and unambiguity. The aim must be to provide warning information
which can be easily understood without any conscious effort by the driver to
interpret the information.
3. Language independence.
4. Distraction. Neither the process employed to alert the driver nor the effort
required to interpret and act on the data should distract the driver’s attention
from his primary task of driving safely.
5. Mode of communication with the driver. This could be audio or visual, or
a combination of both.
6. Interaction. If the driver is required to interact with the system (e.g. accept a
warning message or silence an alarm) then he is more likely to be distracted.
19.7.2 List of Alternative Solutions
1. If a visual display is to be used then this should be positioned as close as
possible to the driver’s normal line of sight.
2. If driver interaction is required then the HMI should not require long and
uninterruptible sequences of interactions.
3. The HMI may be able to use universally understood graphical symbols rather
than text so that it is language independent.
4. Only relevant, timely and accurate data should be displayed so that the driver
is not distracted by unnecessary and irrelevant information.
19.7.3 Decision
A final decision about the HMI considerations can only be taken after prototyping, and
consultation with vehicle manufacturers, relevant user groups, and other related projects
(e.g. AIDE, e-Safety WG-HMI).
3/23/2006 345 Version 2.0

19.8 Value Added Data Application Suite
DEL_RSQ_3_1 Architecture and Interface Specifications
19.8.1 Problem identification
The fundamental problem is how to allow the possibility to transmit or receive any
possible (emergency related) information to or from a Public Service Access Point,
another Emergency Service Device or an Authorised Third party.
Step wise description for the process [8] as it has been defined by GST RESCUE WP2 is
as follows.
1. Emergency Service Vehicle deployed to or at an incident
2. Has a requirement to Transmit/Receive Data including
• Picture
• Voice
• Other Data
3. To or from a Public Service Access Point, another Emergency Service Device or
an Authorised Third party.
4. Emergency Service Device communicates via GST to a communication device
RECEIVES
5. Data sent by an authorised third party or Emergency service Source or direct
Emergency Service Vehicle to Emergency Service Vehicle if allowed
6. Communication device receives the data and acknowledges the receipt and
transmits the data to the Emergency Service device
7. The Emergency Service Device interprets the data
8. Data visualised on a display screen
TRANSMIT
9. Data for transmission is compiled
10. Data prepared for transmission
11. Location (Destination) for transmission is identified
12. Data sent via communication device to an authorised third party or to
Emergency service Source or direct Emergency Service Vehicle to Emergency
Service Vehicle if allowed
13. Data received
14. Data interpreted
15. Acknowledgement received from receivers
16. Link for transmission terminates if not required.
In other words, the Value Added Data application suite is aimed at improving the
efficiency of emergency services personnel when deployed at the scene of an emergency
incident, such as a road traffic accident.
The Value Added Data application suite provides a secure communications layer for twoway
data exchange between the PSAP Control Centre and Emergency Services Vehicles.
3/23/2006 346 Version 2.0

The system consists of the following major components:
DEL_RSQ_3_1 Architecture and Interface Specifications
• The client application, installed in the emergency services vehicle, provides a vital
link between in-field equipment, such as medical monitors or fingerprint
scanners, and the GST telematics unit. The client application also provides a
means of visualising data sent back from the Control Centre.
• The “backoffice” server application is provided at the PSAP (Public Service
Access Point) Control Centre to allow the collation, storage, visualisation and
management of data from one or more deployed emergency services vehicles.
19.8.2 Possible Scenarios
In this context it is important to identify the two possible scenarios:
• The Emergency Service Personnel request for VAD uploading to the Centre
• The Centre request for VAD to Emergency Service Vehicle platform.
The first situation is a PUSH case whilst the second one represents the PULL case.
These two scenarios are illustrated by the following two pictures.
Figure 201 – Value Added Data Streaming - PUSH CASE
3/23/2006 347 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 202 – Value Added Data Streaming - PULL CASE
In both of these two case the process is very similar unless of a significant difference.
Whilst in the PUSH case the ESV-Client System asks to the Centre “Please download these
files from me”, in the PULL case the Centre requests to the ESV-Client System “which files
can I download from you?”.
The common parts of the scenarios are related to the VAD preparation and to the VAD
transmission.
Once that VAD are collected on site via a Mobile Data Terminal, these are transmitted to
the ESV Client System as File Transfer, then the Emergency Service Personnel is allowed
to select the files to be made available for a VAD transmission and to mark these files in
order to make them easily associated to the incident and to the rescue provided.
Even if it is a PUSH or a PULL case, the VAD transmission happens as a GET request
over HTTP.
It is important to note that there is a particular case in which it is possible to
automatically send the VAD files to a Centre without a request. It is the situation in
which the ESV transmits its information to its own PSAP2. In this case the sequence of
actions or exchanged information becomes more simple as illustrated in the following
figure.
3/23/2006 348 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 203 – Value Added Data Streaming - PUSH CASE to PSAP2
The same principles are valid for the transmission of VAD from the authorised Third
Party to the ESV-CS.
19.8.3 Decisions
The decision related to the protocol stack to be used for the files transmission from
MDT to ESV-CS has been driven by GST OS sub project. The protocol stack SHOULD
be the same as for the Nomadic Device Integration with the Client System.
This protocol stack supports the close range communication between so called nomadic
devices and built in Client Systems such as in-vehicle TCUs [14]. In general this
communication happens either over a short-range Bluetooth connection (BT) or a wired
USB link.
The selected protocol stack looks as depicted by the following figure.
Figure 204 – ND-CS Protocol Stack [19]
More specifically, VAD Application Suite deals with File Transfer which is already
supported by one of the available Bluetooth profiles.
3/23/2006 349 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
However it is not one of the scopes of GST RESCUE to deal with Client System
Management and for this reason it is left to GST OS.
Files marking represents another key issue of the VAD problem, not only for the
identification of the files to be exchanged between the involved parties, but also to allow
an easy data collation at Third Party side.
The most sensible information related to this problem are:
• The ESV ID (Emergency Service Vehicle Identificator) to identify the source of
the data.
• The Incident ID, to relate the VAD to the specific incident and rescue provided.
• The File Type, to identify which kind of data it is dealing with (e.g. movie,
picture, text, …). The following abbreviations are proposed to be used:
File Type File extensions Abbreviation
Movie .mov, mpg, … MOV
Generic File Type .*(?) GEN
Audio .mp3, .wav, … AUD
Picture .bmp, .jpg, … PIC
Text .txt, .xml, … TXT
Live data (video, medical data, …) .* LIV
• The File ID, to uniquely distinguish the data of the same type. It is an integer
number encoded on a three characters basis.
It is suggested to mark VAD files by renaming them applying the following rule:
Filename.Extension → ESVID_IncidentID_FileType_FileID.Extension
19.9 Value Added Data Streaming
19.9.1 Problem identification
A particular use case which stands behind the VAD exchange between the involved
parties, is related to the handling of such called live digital data such as a video feed from
a camera or serial data from a medical monitor which have to be transmitted in real-time.
Streaming is the process of playing a file while it is still downloading. Streaming
technology, also known as streaming media, lets a user view and hear digitised content —
video, sound and animation — as it is being downloaded. Using a World Wide Web
browser plug-in, streamed sounds and images can arrive within seconds of a user's click
as general other data formats can be processed as well.
Streaming video, for instance, is a sequence of "moving images" that are sent in
compressed form over the Internet and are seen by the viewer as they arrive.
3/23/2006 350 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
A complete video-streaming system involves all of the basic elements of creating,
delivering, and ultimately playing the video content. The main components of a complete
video streaming system used to accomplish this—Encoding Station, Video Server,
Network Infrastructure, and Playback Client— are illustrated in the following diagram.
The process could be described by the following steps.
Step 1. CAPTURE
As the diagram shows, the first step in the process of creating streaming video is to
"capture" the video from an analog source such as a camcorder or VHS tape, digitize it
(or directly from a digital source such as digital video camcorders which can be captured
straight to disk with a "Firewire" capture board without the analog-to-digital conversion
step) and store it to disk. This is usually accomplished with an add-in analog video
capture card and the appropriate capture software and it is strictly dependant from the
used device. The capture card may also support the delivery of “live” video in addition to
“stored” video.
Step 2. EDIT/AUTHOR
Once the video is converted to digital and is stored on disk it can be edited using a
variety of non-linear editing tools. At this stage, as described below, an authoring tool
may also be used to integrate the video with other multimedia into a presentation,
entertainment, or training format.
Step 3. ENCODE
After the video is edited and is integrated with other media it may be encoded to the
appropriate streaming file format. This generally involves using the encoding software
from the video-streaming vendor and specifying the desired output resolution, frame
rate, and data rate for the streaming video file. When multiple data rates need to be
supported, multiple files may be produced corresponding to each data rate. As an
alternative, newer video streaming technologies create one file that has "dynamic
bandwidth adjustment" to the needed client data rate.
Step 4. SERVE
The video server manages the delivery of video to clients using the appropriate network
transport protocols over the network connection. The video server consists of a
hardware platform that has been optimally configured for the delivery of real-time video
plus video server software that runs under an operating system that acts as a "traffic cop"
for the delivery of video streams. Video server software is generally licensed by the
"number of streams." If more streams are requested than the server is licensed for, the
software rejects the request.
3/23/2006 351 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 205 – Video Streaming System
Step 5. PLAY
Finally, at the client station the video player receives and buffers the video stream and
plays it in the appropriate size window using a VCR-like user interface. The player
generally supports such functions as play, pause, stop, rewind, seek, and fast forward.
Client players can run stand-alone or can be ActiveX controls or browser plug-ins. They
can decode video using software or using hardware add-in decoder boards.
GST RESCUE approach
The same concepts could be mapped on the GST RSQ Architecture by allocating video
server capabilities to the ESV and the client capabilities to the PSAP2 centre. In this way
it is possible to simplify the video-streaming process as follows.
• The Emergency Service Personnel in the ESV starts the video streaming
application which:
o Establishes a GST communication link back to PSAP2.
o Starts the Encoding Component which encodes real time video from a
connected camera.
• One or more operators in the PSAP2 start an instance of the Decoding
Component which:
o Establishes an IP link to the appropriate vehicle.
3/23/2006 352 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
o Pulls the video stream from the ESV.
o Decodes and displays the video stream on the operators screen.
19.9.2 List of Alternative Solutions
Protocols Used in Streaming Technology are used to carry message packets, and
communication takes place only through them. Some of the protocols used in streaming
technology are:
Session Description Protocol (SDP)
A media description format intended for describing multimedia sessions for the purposes
of session announcement, session invitation, and other forms of multimedia session
initiation.
Real Time Transport Protocol (RTP)
A UDP packet format and set of conventions that provides end-to-end network
transport functions suitable for applications transmitting real-time data, such as audio,
video or simulation data, over multicast or unicast network services.
Real-time Control Protocol (RTCP)
RTCP is the control protocol that works in conjunction with RTP. RTCP control
packets are periodically transmitted by each participant in an RTP session to all other
participants. RTCP is used to control performance and for diagnostic purposes.
Hypertext Transfer Protocol (HTTP)
An application-level protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, object-oriented protocol that can be used for many
tasks, such as name servers and distributed object management systems, through
extension of its request methods.
Real Time Streaming Protocol (RTSP)
An application-level protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable controlled, on-demand
delivery of real-time data, such as audio and video, using the Transmission Control
Protocol (TCP) or the User Data Protocol (UDP).
19.9.3 Decision
The main protocol that is used in Streaming is RTSP Protocol.
Real-time Streaming Protocol is an application-level protocol that aims to provide a
robust protocol for streaming multimedia in one-to-many applications over unicast and
multicast, and to support interoperability between clients and servers from different
vendors. RTSP is considered more of a framework than a protocol. RTSP is designed to
work on top of RTP to both control and deliver real-time content.
RTSP takes advantage of streaming which breaks data into packets sized according to the
bandwidth available between client and server. When the client has received enough
packets, the user's software can be playing one packet, decompressing another, and
downloading the third. This enables the user to listen or view the real-time file almost
immediately, and without downloading the entire media file. This applies to live data
feeds as well as stored clips.
3/23/2006 353 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
RTSP represents the most suitable way for GST RSQ implementations since its set of
functions:
• Provides for on-demand access of multimedia items such as stored real-time
audio/video files, live real-time feeds, or stored non-real-time items.
• Allows interoperability between client-server multimedia products from multiple
vendors.
• Provides for control and delivery of real-time media and associated events
between a media server and large numbers of media clients.
• Addresses key concerns of Internet content-providers and users - quality of
service, efficiency of delivery, rights management, and measurement. It also
provides a underpinning for developing the richest possible streaming multimedia
applications.
Differences from HTTP are:
• An RTSP server needs to maintain state by default in almost all case.
• Both an RTSP server and client can issue requests.
• The Request-URI always contains the absolute URI.
19.9.4 Arguments
RTSP Data Packet Formats
For sending media data to an RTSP client, Server uses RTP (Standard Real Time Transport
Protocol ) protocol. RTSP Specifications are available at the following URL:
http://www.ietf.org/rfc/rfc2326.txt [32].
RTSP Methods
RTSP methods are listed in the following table.
Method Description
Options Get available methods
SETUP Establish transport
ANNOUNCE Change description of media object
DESCRIBE Get description of media object
PLAY Start playback, reposition
RECORD Start recording
REDIRECT Redirect client to new server
PAUSE Halt delivery, but keep state
SET-PARAMETER Device or encoding control
RTSP Operation
Table 181 – RTSP Methods
3/23/2006 354 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 206 – RTSP Operation
Putting all the methods together, to send a control request, the client constructs a line
consisting of the method, the request URL, and the protocol version number. Then, the
client includes a general header, a request header and possibly an entity header, as for the
http protocol. This is sent to the server, which executes the request if possible. It then
returns a response containing a status-line and general response and entity headers. The
status line contains the protocol version, the numeric status code, and a textual
description. The media streams are left unspecified by RTSP. These are RTP streams.
RTSP only specifies the control and its up to the client and server software to maintain
the mapping between the control channel and the media streams.
3/23/2006 355 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
A key concept in RTSP is the notion of a session. RTSP works by first requesting a
presentation to be started by a server, receiving in return a session identifier which it then
uses in all subsequent controls. Eventually, the client can request the teardown of
session, which releases the associated resources. The session identifier represents the
shared state between the client and server. If the state is lost, for example through one of
the machines being rebooted, then the protocol relies on the transport of the media
stopping automatically, e.g. through not receiving RTCP messages when using RTP, or
the implementation using the GET_PARAMETER method below as a keep-alive.
The control requests and responses are sent over TCP (UDP is also supported). Since
the order of the requests matters, the requests are sequenced, so if any requests are lost,
they must be retransmitted.
The most obvious additions to the request header fields are a Cseq field to contain the
sequence numbers of requests generated by the client, and a Session field to both the
request and response headers to identify the session. Session identifiers are generated in
response to a SETUP request, and must be used in all stateful methods. The Transport
field allows the client and server to negotiate and set parameters for the sending of the
media stream. In particular, it allows the client and server to set ports and multicast
addresses for the RTP streams.
RTSP Request
A request message from a client to a server or vice versa includes, within the first line of
that message, the method to be applied to the resource, the identifier of the resource, and
the protocol version in use.
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Request = Request-Line *(general-header | request-header | entityheader
)
CRLF [ message-body ]
Method = "DESCRIBE" | "ANNOUNCE" | "GET_PARAMETER" |
"OPTIONS" | "PAUSE" | "PLAY" | "RECORD" | "REDIRECT" |
SETUP" | "SET_PARAMETER" | "TEARDOWN” | extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
RTSP Response
After receiving and interpreting a request message, the recipient responds with an RTSP
response message.
Response = Status-Line *( general-header | response-header | entityheader
)
CRLF [ message-body ]
The first line of a Response message is the Status-Line, consisting of the protocol version
followed by a numeric status code; and the textual phrase associated with the status code,
with each element separated by SP characters. No CR or LF is allowed except in the final
CRLF sequence.
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
3/23/2006 356 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
The Status-Code element is a 3-digit integer result code of the attempt to understand and
satisfy the request. The Reason-Phrase is intended to give a short textual description of
the Status-Code. The Status-Code is intended for use by automata and the Reason-
Phrase is intended for the human user. The client is not required to examine or display
the Reason-Phrase.
RTSP Methods Description
In this section, the most important RTSP methods are described.
DESCRIBE
The DESCRIBE method retrieves the description of a presentation or media object
identified by the request URL from a server. The DESCRIBE reply-response pair
constitutes the media initialisation phase of RTSP.
Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
SETUP
The SETUP request for a URI specifies the transport mechanism to be used for the
streamed media. The Transport header specifies the transport parameters acceptable to
the client for data transmission; the response will contain the transport parameters
selected by the server.
Example:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
3/23/2006 357 Version 2.0

client_port=4588-4589;server_port=6256-6257
DEL_RSQ_3_1 Architecture and Interface Specifications
PLAY
The PLAY method tells the server to start sending data via the mechanism specified in
SETUP. A client MUST NOT issue a PLAY request until any outstanding SETUP
requests have been acknowledged as successful. The PLAY request positions the normal
play time to the beginning of the range specified and delivers stream data until the end of
the range is reached.
Example:
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z
S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
PAUSE
The PAUSE request causes the stream delivery to be interrupted (halted) temporarily. If
the request URL names a stream, only playback and recording of that stream is halted.
For example, for audio, this is equivalent to muting. If the request URL names a
presentation or group of streams, delivery of all currently active streams within the
presentation or group is halted. After resuming playback or recording, synchronization of
the tracks MUST be maintained. Any server resources are kept, though servers MAY
close the session and free resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message.
Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
TEARDOWN
The TEARDOWN request stops the stream delivery for the given URI, freeing the
resources associated with it. If the URI is the presentation URI for this presentation, any
RTSP session identifier associated with the session is no longer valid. Unless all transport
parameters are defined by the session description, a SETUP request has to be issued
before the session can be played again.
Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
3/23/2006 358 Version 2.0

S->C: RTSP/1.0 200 OK
CSeq: 892
Request Headers in RTSP
RTSP Request Headers are listed in the following table.
Header Description
DEL_RSQ_3_1 Architecture and Interface Specifications
ACCEPT Media description format
ACCEPT-ENCODING Encoding of media format
ACCEPT-LANGUAGE Human language
AUTHORIZATION Authentication
BANDWIDTH Client bandwidth available
CONFERENCE Conference identifier
FROM Name of requestor
If-Modified since Conditional retrieval
RANGE Time range to play
Referrer how did we get here?
SPEED Speed-up Delivery
User Agent Software
Table 182 – RTSP Request Headers
Response Headers of RTSP
RTSP Response Headers are listed in the following table.
Header Description
Location Redirection
Proxy Authentication Authenticate to proxy
Public Methods supported
Retry-After Busy, comeback later
Server Server software
Vary Cache
Www-authenticate Request authorization
Protocol States
Table 183 – RTSP Response Headers
3/23/2006 359 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Unlike HTTP, RTSP does have a certain amount of state associated with it. Here is a
simple state machine that describes the minimal state in RTSP.
Figure 207 – RTSP Protocol States
19.9.5 Source Document
http://www.live.com/
http://www.cswl.com/
http://streamingmedialand.com/
http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/iwsem.html
http://www.realnetworks.com/
http://www.rtsp.org/
http://www.ietf.org/rfc/rfc2326.txt
19.10 Test and Certification of the eCall protocol at the level of
new implementations
19.10.1 Problem identification
Two categories of protocols tests have to be achieved for the certification of eCall
implementations:
• Protocols conformance tests allowing to certify that a given eCall implementation
is conforming to the SLA (Service Level Agreement) and SLS (System Level
Specification) associated to the eCall service. In such case, the considered
implementation is tested against a Qualified Reference Implementation (A PSAP
Reference Implementation for the test of an In-Vehicle eCall system
implementation, An In-Vehicle eCall system Reference Implementation for the
test of a PSAP System implementation).
• Protocols Interoperability tests allowing to certify that two complementary
conforming implementations are fully interoperable. This second category of test
requires that the test be complete (test of the behaviour of the two
implementations under different circumstances and with different MSD values)
and be achieved in a real operational environment. If this is not the case, it would
not be possible to certify the interoperability of the two considered
implementations so leading to a risk of problems when the complete system will
be put in operation.
Practically, we will be facing the necessity to test the interoperability of a new
implementation with an existing operational one. This will be the case in the following
contexts:
3/23/2006 360 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
• When an equipment provider will introduce on the market a new eCall device for
the after sales market (to be mounted in In-Service cars).
• When a car manufacturer will introduce on the market a new car equipped with a
new In-Vehicle eCall system. In such case, the existing PSAP eCall system will
have also to be up-dated with the new car model reference and with the possible
colours of the car model (new consistency checks which could be achieved on
received data by the PSAP system).
• When a new version of the eCall protocol is released. A new version will be
necessary when some fields (elements of information) of the MSD will be
modified (e.g. Replacement of GPS by GALILEO, replacement of IPv4
addressing scheme by IPv6, evolution of the crash detection capabilities,
evolution of the vehicle identification scheme,...etc.). This last case is particularly
important since we will be using the same operational calling number (E112) to
support two different versions of the eCall protocol (one operational and a new
one supposed to be operational).
It has to be noticed that the long life cycle of cars (in an average 15 years, in a worse case
more than 20 years) several versions of the eCall protocols will have to cohabit and be
handled by the operational PSAPs.
19.10.2 List of Alternative Solutions
CERTECS proposal
It is proposed by CERTECS to RESCUE to add an information element (One byte) in
the eCall MSD allowing to specify the “life cycle phase” of the MSD message. Two life
cycle phases are important to be considered :
• The operational phase indicating that the received MSD is corresponding to an
actual eCall and so requires the organization of the adapted emergency
assistance. In such case, the “life cycle phase” information element will take the
value “O” as “Operational”.
• The Testing / Certification phase indicating that the received MSD is
corresponding to a test/simulation eCall and shall be processed as such by the
PSAP. The processing of a test eCall can be processed automatically by the PSAP
Information System (according to some pre-programmed logic) and this
transparently to the PSAP Human operators. In such case, the “life cycle phase”
information element will take the value “T” as “Testing”.
The following figure give an example of the automatic processing of this information
element by a PSAP1 information system.
3/23/2006 361 Version 2.0

ACK Response
DEL_RSQ_3_1 Architecture and Interface Specifications
At the PSAP
Information System Level
Reception and Analysis of
the MSD Message
Yes
Check of the Message
Consistency
Consitency OK?
Test Message ?
3/23/2006 362 Version 2.0
Yes
No
Alert PSAP Operator
and provide Information
No
NACK Response
Figure 208 – Example of a test MSD message processing by PSAP1 IS
In this algorithm, the received MSD messages are analyzed, a consistency check is
achieved to establish the validity of each message (checking that all information elements
have a possible value). Then, if it is a consistent message (operational or test), an
acknowledgement is immediately returned to the In-Vehicle Telematic system (some
other operations could be locally achieved according to the PSAP processing logic). If it
is a consistent, operational MSD message, the PSAP Information System executes the
programmed operational logic. In case of the detection of an inconsistency, a NACK
message (including some information about the problem) is returned to the In-Vehicle
Telematic system.
It is clear that such mechanism must be used carefully with the complete agreement of
PSAP. This agreement which can be an element of the Service Level Agreement can be
set on a National basis. That is to say that each National PSAP may have the possibility
to define its own logic for the use of this facility (e.g. can be used for the commissioning
of a new PSAP information system, or for the training of the PSAP call centre
operators).
Moreover, one element of risk (risk assessment study) could be related to the capability
of a given PSAP implementation to handle a certain number of simultaneous eCall (e.g.
in case where a certain number of vehicles are involved in an accident). In order to test
that a given PSAP implementation has the capability to handle such situation properly, it
could be useful to simulate it by simultaneously triggering the transmission of a certain
number of eCalls. This capability to handle a simultaneity of eCalls shall be characterised
in the Service Level Agreement according to some existing statistics.
RESCUE Analysis
RESCUE protocol stack for eCall is based on a subset of TCAP which is Transaction
Component approach encoded into ASN.1.

DEL_RSQ_3_1 Architecture and Interface Specifications
To foresee an additional information element into the MSD is technically possible using
ASN.1 encoding scheme, but different options are available in order to do that.
Option 1
An "interoperability tests" information could be a specific component: MSD_TEST
component for example.
This first option allows to completly separate the test case from the running case scheme,
but, on the other hand, it needs to implement new encoder-decoder, by changing
encoding scheme (BER,DER, XER ...).
Option 2
An "interoperability tests" information could be a part of the MSD component as an
OPTIONAL data.
The advantages of this option are to include it into the MSD and to allow a detection at
the PSAP side when decoding the MSD, but in that case an update of the eCall process is
needed in order to include this functionality because it add a switch case in the eCall
process as well: MSD running or test?
Option 3
An "interoperability tests" information could be an extension of the MSD component as
an OPTIONAL data with the extensible property of ASN.1.
The advantage of the last option is to have no impact on the running case for PSAPs
which are not involved in the test case. Only PSAPs involved in the test case have to
update their decoder in order to detect this additional information.
19.10.3 Decision
GST RESCUE SP supports the third option which is the one representing the lowest
impact on the whole solution, even if some adaptations are needed to the protocol
handler at both PSAP1 and Vehicle sides.
19.10.4 Consequences of the decision
As main consequence of this decision a new information element is added to MSD as
OPTIONAL, but it allows, due to the encoding structure, PSAP1 with existing systems
to still comply with the MSD and to be able to handle it. An update for the additional
information handling at PSAP1 is required only for centres which implements testing
capabilities.
19.10.5 Source Document
Contribution CERTECS 01 by Gérard Ségarra, Renault SAS, on behalf of the CERTECS
subproject, the 16th august 2005
19.11 eCall timing issues
19.11.1 Definitions
Public Safety Answering Point (PSAP)
A physical location where emergency calls and eCalls are received. This may be a public
authority, possibly a public/private partnership or a telecommunications operator
licensed by a public authority. It is be responsible for ordinary 112 voice calls via landline
and mobile networks. The PSAP is responsible for informing the Emergency Authorities.
3/23/2006 363 Version 2.0

Critical sensor
DEL_RSQ_3_1 Architecture and Interface Specifications
A critical sensor within both E-MERGE and GST RESCUE projects is defined as an invehicular
sensor, which is designed to monitor critical events within a vehicle
immediately before, during or after a collision. The PSAP requirement for an automated
activation of the emergency system is that no less than 2 of these defined sensors will
have activated.
Timing
In case of a manual activation of the eCall, the PSAP1 operator should answer the call
Within 2 seconds. Upon answering the call, the operator should learn as much
information (What? Where? What is needed?) From the driver as he possibly can in 5
seconds.
Just before the voice call is initiated, the minimum set of data is made available using the
voice channel to send the data as “data in the voice”. This is then visualised by the Public
Service Access Point. It should be done within 7 seconds.
Based on the information from the voice call and the Minimum set of data, the Public
Service Access Point 1 st Level contacts the PSAP2 (i.e. Emergency Authorities) who have
5 seconds to answer the call.
The PSAP1 has 6 seconds to hand over the first information about the incident to the
PSAP2.
Slightly later than the minimum data set and voice, the Public Service Access Point pull
the full set of data from the Service Provider (SP). This information should be available
at the SP in less than 10 seconds after the initiation of the voice call to the Public Service
Access Point. In less than 4 seconds, the SP should process the SMS. Then, the SP
should be able to make the SP data available to the Public Service Access Point and the
Emergency operators in less than 2 seconds.
In case of an automatic activation by the critical sensors, the procedure is very similar.
The Public Service Access Point 1 st Level operator has 5 seconds to try and establish
contact with the vehicle driver via the automatically initiated voice call. After those 5
seconds, the procedure continues without any voice information from the driver.
The time scheme where the eCall process work by is displayed in the following diagram.
3/23/2006 364 Version 2.0

19.11.2 Legal Issues
Data protection issues
DEL_RSQ_3_1 Architecture and Interface Specifications
Figure 209 – Time scheme of eCall process [9]
The data protection issue with regard to the expanded areas of the rescue chain are not
within the protection granted by the 112-call area (Universal Service Directive
2002/22/EC, Directive on Privacy and Electronic Communications 2002/58/EC), as
they do not form part of the immediate call for assistance.
As such there would need to be an agreement from the person from whom the data is
generated that the service provider has permission to store, use and forward that data to
the Public Service Access Points in case of an accident.
The organisation storing the data would have a requirement to ensure accuracy.
As there is a value of the data, ownership needs to be determined.
Directive 2002/22/EC requires public telephone operators to forward caller location
information to authorities handling emergencies, to the extent technically feasible, for all
calls made to the single European emergency call number 112.
3/23/2006 365 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Directive 2002/58/EC establishes the conditions for use of location data by emergency
services. Member States should ensure that there are transparent procedures governing
the way in which a provider of a public telecommunications network and/or a publicly
available electronic communications service may override the elimination of the
presentation of calling line identification and the temporary denial or absence of consent
of a subscriber or user for the processing of data, on a per-line basis for organisations
dealing with emergency calls and recognised as such by a Member State, including law
enforcement agencies, ambulance services and fire brigades, for the purpose of
responding to such calls.
Directive 95/46/EC on the protection of individuals with regard to the processing of
personal data and the free movement of such data stipulates that personal data may be
processed where the processing is necessary in order to protect the vital interest of the
data subject.
19.11.3 Legal Liabilities
Accuracy
The owner of the database would need to have a partnership with the person for whom
the data was generated to assure accuracy. In other words, the customer is obliged to
report changes to his personal situation and answer regular up-date letters.
There needs to be an indemnity on behalf of the PSAP and the emergency services when
they carry out any action (or not) as a result of receiving inaccurate information.
Failure of communication
A malfunction of the system may imply a manufacturer’s liability. The Public Service
Access Point and/or the Home Call Centre and the Central Database Host might need
to compensate the customer for the non-receipt of information due to failure of the
communication chain (other than telecommunication network) resulting in the worsening
of the emergency situation.
There is also a need for the PSAP2 to deal with such a situation.
Incorrect information
The Public Service Access Point and emergency authorities need to be compensated
when actions have been executed based on incorrect (false) information. Incorrect
information can result from misuse (HMI issue), intentional misleading the authorities
(criminal offence), technical defects (software issue) and incorrect data provided by the
customer or storage mistakes.
Contractual aspects
According to Article 26 of the Universal Service Directive, calls to the single European
emergency number, 112, including location enhanced E112 must be provided free of
charge for all end users of publicly available telephone services, including users of public
payphones.
Human rights
Emergency service proposals have been audited for “Human Rights Compliance” and
were found effected by Articles 1, 2 and 8 of the First Protocol of the “Human Rights
Convention”.
3/23/2006 366 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
There is also an issue with relation to the “Osman Ruling”, which expands the duty of
care for public authorities, and how they respond to a known risk for a member of the
public.
19.11.4 Network Security
Especially in situations where personal and confidential data is transported over the
internet, security becomes of the utmost importance. Communication between the
different parties involved in an eCall should assure a complete protection against any
infringements or security violations. The data transport architecture described should as a
minimum requirement support the following aspects involved in a secure Virtual Private
Network:
• Data confidentiality - A third party should not be able to decrypt confidential
information sent between two parties.
• Authentication - The communicating parties should be sure about the identity of
their correspondent.
• Authorisation- A partner in the network should be either allowed or prevented
from using resources made available in a network.
• Access control - In no way should it be possible for third parties to enter the
system without proper authorisation.
These are by no means the only security breaches a system could witness, and that a
secure system should at least protect against. This specification effort provides a minimal
set of features a secure network should support. This does not exclude any additional
features, but those features depend greatly on the actual implementation of the system,
and on the facilities provided by a third party security authority.
19.11.5 Source Document
E-MERGE D3.0 “Specifications of the European in-vehicle emergency call”
19.12 HMI Design Recommendations for eCall system
19.12.1 Introduction
HMI design is not one of the main scope of GST IP, but at the same time it represents a
key issue for safety related systems, even considering the existing regulation (on
December 21, 1999, the Commission of the European Communities issued a
recommendation “on safe and efficient in-vehicle information and communication systems: A
European statement of principles on human machine interface’ to its member states”).
The present sub-chapter aims at providing guidelines and principles for HMI design with
specific reference to the level of interaction represented by the IP Level Reference Point
IOD-End User, between the driver (or a passenger of the vehicle) and the Public Vehicle
Client System.
19.12.2 Problem identification
To allow a vehicle driver or passenger to activate an emergency call manually, buttons are
required. Currently, most in-vehicle systems offer a minimum of two assistance buttons,
one for activating an emergency call, and another one for requesting vehicle breakdown
assistance.
3/23/2006 367 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
In order to maximise the benefits of the eCall system, the eCall HMI must be as much
user-friendly as possible. The ease of interaction with the unit as well as the design of
button location and function must be considered critical factors for the usability of the
system.
The eCall system usability requirements can be broken down into several HMI
characteristics:
- Ease of use
- System Feedback to the user
- Prevention of false activation
- Prevention of driver distraction
19.12.3 Ease of Use
The eCall button should be placed in a location that the driver and front seat passenger
can reach to activate the button, without having to leave their seats.
To assist new users that may be unfamiliar with a vehicle, the eCall Button should have a
similar look-and-feel across different vehicle types and brands. The eCall system lookand-feel
should be similar to help the user recognise the system, but it does not have to
be identical in each vehicle.
Such a look-and-feel includes the following aspects:
- Position
- Size
- Colour
- Feel
- Shape
- Night-time button illumination
The lack of experimentation in real-life conditions prevents the specification of an eCall
HMI standard. On the other hand, it is possible to provide a number of logically sound
recommendations as those listed in the paragraphs below.
Position
The eCall button should be positioned in a distinct location so as to prevent the driver
and other vehicle occupants from pushing the button accidentally. This position can be
located in the rear mirror area, which can be reached by both front seat passengers
without leaving their seats. Some vehicle manufacturers locate the E-call button on the
dashboard, which can also be reached easily. In this position the eCall button needs to
differ with the warning button in several aspects, so that an error from the driver can be
avoided.
Colour
Most of the car manufacturers choose the red colour for the eCall button. The red colour
is generally considered to indicate danger, so it is easy for the user to identify this button
as an eCall button.
3/23/2006 368 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
However, the user should not be able to confuse the eCall button with other warning
buttons of the same colour. This can be achieved by using different shapes to distinguish
between the buttons.
Size, Feel and Shape
These features largely depend on the interior design, but should allow the driver to easily
identify the eCall button.
19.12.4 Feedback from the system
The system could offer either auditory or visual feedback to the user. Multimode
feedback could help to assure the vehicle passengers that the system is activated.
Audio feedback
Auditory feedback could be achieved with a tone, or with a voice communication from
the alarm centre.
Visual feedback
Visual feedback can be offered to the user via a display, a blinking light or with some
icon on the instrument cluster. This kind of feedback is not always possible, especially in
those accidents where the vehicle is severely damaged. If the feedback is provided via the
display, the passengers must be able to understand the information quickly and easily.
19.12.5 Driver distraction prevention
In order to minimise the distraction of the driver the following recommendations are
made.
• The eCall system should allow for hands-free operation after activation.
• The driver should be able to locate the E-call Button easily, without having to
take his eyes off the road for more than two seconds.
• The E-call button should provide visual or audible confirmation that a message
has been sent, to reassure the driver, and to allow the driver to continue
concentrating on his / her primary task of driving.
• Any warnings of activation should be designed so as to prevent the driver from
being started or distracted.
19.12.6 Reducing the number of accidental/false calls
The reduction of the number of false or accidental calls is essential if emergency services
are not to be deployed inappropriately. If an emergency service is sent to an incident
where they are not required or to respond to a false call, they may not be available to
respond to a genuine call which may put lives at risk. Because of these facts it is
necessary to give some requirements on this problem.
False calls can be due to different factors, some related to the user (e.g. accidental
activation because of a non adequate HMI) and some other related to the system itself
(the failure of one or more sensors inside the vehicle).
Minimising the number of false or accidental activations of the system is vital if the unit
is to have credibility, and to make effective use of the emergency service response. While
the emergency services are responding to a false or accidental activation, they will not be
available for a genuine emergency. This may result in loss of life or more serious injury.
3/23/2006 369 Version 2.0

To minimise false or accidental activations:
DEL_RSQ_3_1 Architecture and Interface Specifications
• The E-call button should be positioned where accidental pressing is unlikely.
• The E-call button should alert the driver either visually or audibly that it has been
activated.
• The E-call button should be held down for 2 seconds before activation is
confirmed.
• Any other Service call button should be located sufficiently far away from the E
Call button to prevent a false or mistaken activation.
• The E-call system should have the ability to cancel a call within 6 seconds to
undo an accidental activation.
• The E-call system should alert the driver if it has been automatically activated by
vehicle sensors.
To prevent or minimise the occurrence of false calls caused by the failure of a sensor:
• The eCall should only be generated automatically if one or more sensors is
activated (see par. 19.1).
• The eCall system should alert the driver if an attached sensor fails (see par. 16.3).
19.12.7 Source Document
E-MERGE D3.0 “Specifications of the European in-vehicle emergency call”
3/23/2006 370 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Chapter 20 - CONCLUSIONS AND NEXT STEPS
20.1 Conclusions
GST RESCUE is a Service Oriented SP which aims at effective and reliable safety and
rescue capabilities by providing a set of GST specific “services” deployed upon the GST
Platform.
The proposed architecture is designed on the basis of the GST overall approach an it has
several points of contacts with the High Level GST Architecture. It is in fact possible to
map all the GST RESCUE defined entity on the reference ones and at the same time the
result is achieved by considering the defined reference points.
Even if it has been maintained the overall GST approach, the rationale behind the design
is strictly dependant by the operating environment in which GST RESCUE will work
and the proposed solution has been reached considering, together with system
requirements, legal and performance issues which represent a key aspect in the real
world.
The main dealt issues are represented by:
- data protection;
- data accuracy;
- contractual aspects;
- failures facing and error handling;
- the eCall timing scheme at each stage of the eCall management chain.
At the same time, WP3 work started by the results achieved by previous projects such as
E-MERGE and CGALIES, even considering the current activities on Safety which are
ongoing around GST, such as the eCall DG.
This set of input has represented a huge impact on specification work addressing several
design decisions taken as illustrated at Chapter 19.
The most important taken decisions are:
- the definition of which sensors and thresholds must be handled and processed in
order to trigger an eCall;
- adopted protocol stacks have been addressed at IPWP3MT Level;
- USSD has been selected as protocol for the eCall protocol application. Contrary
to SMS, USSD offers session-oriented connections which meet the general key
requirement to have data and voice delivered at the same PSAP1 within the same
session and allow data flows back to the Vehicle Client System (e.g.
Acknowledgement and EOS messages). Moreover USSD offers no limits to the
data message size (more messages could be linked together within the same
transaction) and a rate for transmission which is up to 5 times faster then SMS.
3/23/2006 371 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
- MSD message has been structured in order to meet a specific requirement from
CERTECS of having an extra information to distinguish Test/Certification and
Operational eCalls (see par. 19.10).
- VAD application suite has been specified in order to allow a bi-directional data
and messages exchange between the Emergency Service Vehicle and any
authorized Third Party. Moreover specifications cover live data streaming from
the ESV to the Third Party and RTSP has been selected as protocol for
streaming real-time media data.
HMI design is not one of the main scope of GST IP, but at the same time it represents a
key issue for safety related systems, even considering the existing regulation (on
December 21, 1999, the Commission of the European Communities issued a
recommendation “on safe and efficient in-vehicle information and communication systems: A
European statement of principles on human machine interface’ to its member states”).
Starting from reliability and effectiveness considerations and considering liaisons with
external projects (e.g. AIDE IP), GST RESCUE SP, in addiction to system
specifications, provides guidelines and principles for HMIs design at the main levels of
interaction between the Client System and the End Users. HMI related guidelines and
recommendations are provided for the following interfaces:
- Member of Public Vehicle – Public Vehicle Client System
o eCall Manual Activation/Canceling (see par. 19.12)
o Blue Wave/Virtual Cones Application on PV (see par. 19.7)
- PSAP Operator – PSAP
o Emergency Data Visualisation (see par. 19.4)
- Member of Emergency Service Vehicle – Emergency Service Vehicle Client
System
o Route Navigation System (see par. 19.5)
o Blue Wave/Virtual Cones Application on ESV (see par. 19.6)
20.2 GST RESCUE Specifications Assessment
With specific reference to the next paragraph, which shows the compliancy matrix of
how the requirements defined within WP2 are met by WP3 specifications, this section
aims at assessing the specifications through an analysis of the matrix itself.
Conducting a pragmatic statistical analysis it is possible to carry out that about 70% of
WP2 requirements are totally covered by GST RESCUE WP3 specifications, but some
considerations related to the remaining 30% must be taken in order to better explain the
achieved result. In fact it is possible to group these requirements into specific related
domains and to provide the reasons for this apparent lack. Domains are:
- Communications (device and infrastructure);
- HMI;
- Security;
3/23/2006 372 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
- System Management.
In the context of GST communication infrastructure and devices are proper of the
external world since the GST platform is built upon the Vehicle intended as a means of
carrying or transporting actors which require rescue support and which contains the
appropriate vehicle sensors and the Vehicle Client System and is able to communicate
with the external world. For this reason specifications related to information and data
exchange have been defined above an already existing communication capability
provided by the vehicle itself.
As anticipated, HMI design represents a key issue for safety related systems and the
amount of requirements related to the interaction between humans and the applications
to be run on the GST platform confirms the sensibility of the problem. Nevertheless
GST IP is not dealing with HMI, GST RESCUE provided guidelines and principles for
HMI design as well, covering a significant part of the requirement.
Security and System Management (e.g. error handling, enabling/disabling of the
device, …) related requirements are not covered by GST RESCUE since system
specifications are addressed by Technology Oriented SPs such as GST SEC and GST
OS. Although GST RESCUE provides the appropriate references to those SPs to ensure
a complete facing of the problem.
20.3 Compliance Matrix
The intention of this paragraph is to trace, which requirements identified in WP 2 are
covered by the specification and which status (in, out, optional) they have, indicating how
each requirement is covered by the design. In cases requirements are not covered the
reason is given in the following table in the “Notes” column. Additional explanations of
the requirements can be found in [8].
ID (short) Definition Additional explanation
System Requirements
RQ RSQ
001
UN RSQ
0028
RQ RSQ
002
UN RSQ
0031
The user shall require that
the data shall at least be
received according to the
minimum performance
criteria set out in Project
Emerge.
The user requires that
where an emergency
service is capable of
transmitting data to its
vehicles. The user (Public
Service Access Point)
shall be able to choose the
communication medium
to transmit the data to
Link AR RSQ 0022
Minimum set of eMerge
Data to be received no
longer than two seconds
after voice call
Full Emerge data set
available to PSAP 18
seconds after voice call
Link Ancillary
Requirement
AR RSQ 25
The Emergency Service
should be able to choose
whether to use their own
system, GST or TETRA
or another commercially
provided system.
Covered by
specification
paragraph(s)
Status
3/23/2006 373 Version 2.0
6.4
7.2
8.1
9.1
In
X
X
Out
Optional
Notes

ID (short) Definition Additional explanation
RS RSQ
003
UN RSQ
0032
RQ RSQ
004
UN RSQ
0033
RQ RSQ
005
UN RSQ
0034
RQ RSQ
006
UN RSQ
0035
UN RSQ
007
UN RSQ
0036
emergency service
vehicles.
The user shall require that
the systems for the
transmission of data
between Public Service
Access Point’s, authorised
third parties and to/from
and between emergency
services vehicles shall
utilise transmissions
mediums that are, timely
secure and provide good
coverage of the area.
The user shall require that
the system for the
transmission of data to
the emergency service
vehicles and GST Rescue
Emergency Service
Devices shall employ a
Data “Light weight”
method of
communication.
The user shall require that
the transmission of data
shall be two-way between
the Public Service Access
Point or authorised third
parties and the emergency
service vehicle or GST
Rescue Emergency
Service Device.
The user shall require that
the GST system and/or
the GST Rescue
Emergency Service
Device log and retain
every transaction carried
out in the transmission
and reception of data to
and from the emergency
service vehicle.
The user shall require that
the GST system and/or
the GST Rescue
Emergency Service
Device shall acknowledge
the transmission and
reception of each data
DEL_RSQ_3_1 Architecture and Interface Specifications
Where there is no data
capability, the
communication could be
by radio, TETRA or
VHF/UHF or GSM
equivalent.
Note this may be via GST
communications or by
emergency service secure
communications, e.g.
Tetra
Security IP
Aim to keep transmission
costs down
Data Light means: The
smallest amount of data
communicated to achieve
the desired functionality
Link Ancillary
Requirement AR RSQ
0026
Link to Ancillary
Requirement
AR RSQ 0027
Link to Ancillary
Requirement
AR RSQ 0028
Covered by
specification
paragraph(s)
Status
3/23/2006 374 Version 2.0
8.1
9.1
14.1
14.4
8.1
9.1
14.1
14.4
In
X
X
Out
X
16.3 X
16.2 X
Optional
Notes
This requirement is
left outside of GST
RESCUE since
Communication
device interfacing is
external of GST
world.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
RQ RSQ
008
UN RSQ
0040
RQ RSQ
009
UN RSQ
0042
RQ RSQ
010
UN RSQ
0051
RQ RSQ
011
UN RSQ
0053
transmission to and from
the Public Service Access
Point.
The user shall require that
the display terminal in the
emergency service
vehicles shall be
compatible with a
keyboard to allow the
emergency service
personnel to input data or
to communicate with
PSAP or other third party
via the data medium.
The user shall require that
the display screen fitted to
the emergency service
vehicle be capable of
touch screen operation.
The user shall require that
the mobile data terminal
fitted to the emergency
service vehicle be capable
of communicating with
other data terminals from
other emergency services
vehicles if fitted.
The user shall require that
target location
(destination) shall be
capable of being input:
• Manually via a
human input
device
• Automatically
from a Mobile
Data Terminal
where fitted,
once an incident
together with a
location has
been accepted by
emergency
DEL_RSQ_3_1 Architecture and Interface Specifications
This includes in vehicle
(Fitted from new by
manufacturer) display
terminals where a bespoke
emergency service
terminal is not fitted.
Link to Ancillary
Requirement
AR RSQ 0032
Link to Ancillary
Requirement
AR RSQ 0034
It is envisaged that this
would be a data
transmission. The system
should indicate which
emergency service
vehicles are signed onto
the network.
To allow different
emergency services to
communicate to each
other through
middleware, for otherwise
non-compatible systems.
Link to Ancillary
Requirement
AR RSQ 0043
In cases where the route
guidance system, or
components of it are
OEM vehicle fit or if the
route guidance system is
an application that can be
downloaded through the
GST platform.
Link to Ancillary
Requirement
AR RSQ 0045
Covered by
specification
paragraph(s)
Status
3/23/2006 375 Version 2.0
In
Out
X
X
16.3 X
14.1 X
Optional
Notes
This requirement
has been kept out
since HMI is out of
the scope of GST IP
project
This requirement
has been kept out
since HMI is out of
the scope of GST IP
project
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
Par. 14.1 provides
specifications for
data exchange
between ESV and
authorised Third
Parties. The same
principles are valid
for communication
between ESVs.

ID (short) Definition Additional explanation
RQ RSQ
012
UN RSQ
0054
RQ RSQ
013
UN RSQ
0055
RQ RSQ
014
UN RSQ
0057
RQ RSQ
015
service
personnel, or
Automatically directly
from an authorised third
party one accepted by the
emergency service
personnel.
The User shall require
that where components
(screens, navigation
systems etc) are fitted as
standard (By OEMs) to
emergency service
vehicles, that through the
middleware of GST they
are capable of being
utilised for emergency
service purposes, to
include GST Rescue and
other emergency service
devices when authorised
to do so.
The User shall require
that the route guidance
system shall identify the
location where the
emergency service vehicle
is automatically.
The User shall require
that the route guidance
system shall take account
of traffic and other
environmental conditions
at the time of preparing
route options and during
the route continue to
assess the route selected,
advising the emergency
service personnel where
adjustments to a route are
advisable in a way that is
cognisant of HMI.
The user shall require that
the route guidance system
should notify the Public
Service Access Point
DEL_RSQ_3_1 Architecture and Interface Specifications
This means that where
data screens or route
guidance systems are
fitted through GST they
are capable of being
utilised for the use cases
in RESCUE
Link to Ancillary
Requirement
AR RSQ 0046
This is a GST system
requirement if the vehicle
location system is an
OEM vehicle fit and the
Route guidance is an
emergency services
bespoke system as this
will require the two to
communicate.
Link to Ancillary
Requirement
AR RSQ 0047
This includes weather
conditions. This will
require the route guidance
system to obtain
information in real time
either from floating
vehicle data or from a
Service Provider
Link to Ancillary
Requirement
AR RSQ 0049
. This should/could be
done through GST
platform and then it
Covered by
specification
paragraph(s)
Status
3/23/2006 376 Version 2.0
In
Out
16.3 X
11.1 X
11.1 X
19.5 X
Optional
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
It is important to
note that this
requirement is
strictly related to

ID (short) Definition Additional explanation
UN RSQ
0069
RQ RSQ
016
UN RSQ
0070
RQ RSQ
017
UN RSQ
0080
RQ RSQ
018
UN RSQ
0081
RQ RSQ
019
UN RSQ
0082
operator when the vehicle
is at the scene.
The user shall require that
the route guidance system
shall give the emergency
service driver/passenger
the distance and
approximate travel time to
the scene of the incident
taking account of traffic
and other conditions.
This will be regularly
updated whilst en route.
The user shall require that
the Blue Wave/Virtual
Cones transmission
device shall offer a range
of messages to the
emergency service
personnel
The user shall require that
the range/coverage of the
Blue Wave/Virtual Cones
transmission should be
automatically adjustable
by speed and location of
the emergency service
vehicle.
The user shall require that
only people that are on
the road ahead and on
connecting roads ahead
and to the side of the
emergency service vehicle,
on its route and within a
prescribed distance
should receive the
warning from the Blue
Wave transmission.
DEL_RSQ_3_1 Architecture and Interface Specifications
becomes a GTS system
requirement.
Link to Ancillary
Requirement
AR RSQ 0061
This requires the device to
communicate with outside
systems and react to the
information.
Link to Ancillary
Requirement
AR RSQ 0062
This is required to
provide different
warnings to the other
drivers and to cater for a
range of operational
situations
Link to Ancillary
Requirement
AR RSQ 0069
As speed increases the
range should increase.
The range should also be
assessed by type of road,
so that approaching
junctions the range to the
sides would increase.
Link to Ancillary
Requirement
AR RSQ 0070
This needs to work in
conjunction with virtual
cones that may need to be
broadcast at the same
time.
Link to Ancillary
Requirement
AR RSQ 0071
This has been widened
from vehicles to people to
include other devices such
as mobile phones.
Covered by
specification
paragraph(s)
Status
3/23/2006 377 Version 2.0
In
11.1 X
12.3 X
12.3 X
12.4
12.5
X
Out
Optional
Notes
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.

ID (short) Definition Additional explanation
RQ RSQ
020
UN RSQ
0087
RQ RSQ
021
UN RSQ
0093
RQ RSQ
022
UN RSQ
0094
RQ RSQ
023
UN RSQ
0095
RQ RSQ
024
UN RSQ
The user shall require that
the Blue Wave/Virtual
Cones device shall be
designed to be capable of
on transmitting, being
received by any vehicle or
other authorised device,
equipped with a receiving
device, no matter from
where the vehicle or
authorised device is from.
(Roaming).
The user shall require that
the Blue Wave/Virtual
Cones warning shall
inform the vehicle
occupants the type of
emergency service
vehicles approaching or
present in a way that is
cognisant of HMI
The user shall require that
the Blue Wave/Virtual
Cones device shall warn
the person or vehicle
occupants from which
direction the emergency
vehicle is approaching in a
way that is cognisant of
HMI.
The user shall require that
the Blue Wave device
shall warn the person or
vehicle occupants the
number of emergency
service vehicles that are
approaching.
The user shall require that
the Blue Wave/Virtual
Cones device should
provide advice as to what
DEL_RSQ_3_1 Architecture and Interface Specifications
This is key for
interoperability.
Link to Ancillary
Requirement
AR RSQ 0076
Examples of other
authorised devices could
include mobile phones
This is key to recognition
of the hazard
Link to Ancillary
Requirement
AR RSQ 0082
Direction again is critical
in order that driver can
prepare to react to the
emergency service vehicle.
This element will provide
a vital part of increasing
safety by removing the
startling effect of
suddenly hearing the
sirens.
Link to Ancillary
Requirement
AR RSQ 0083
This again is key as often
the driver reacts to the
first emergency service
vehicle, but misses the
second one following
close behind resulting in
risks to safety.
Link to Ancillary
Requirement
AR RSQ 0084
The Device could provide
information to the driver
as to which direction the
Covered by
specification
paragraph(s)
Status
3/23/2006 378 Version 2.0
12.3
12.5
In
X
12.4 X
12.4 X
12.4 X
12.4 X
Out
Optional
Notes

ID (short) Definition Additional explanation
0096
RQ RSQ
025
UN RSQ
0098
RQ RSQ
026
UN RSQ
0100
RQ RSQ
027
UN RSQ
0101
RQ RSQ
028
UN RSQ
0103
RQ RSQ
029
action they should take. Emergency Service
vehicle was coming from.
i.e. from behind pull over
and stop.
Link to Ancillary
Requirement
AR RSQ 0085
The user shall require that
Where a Blue
Wave/Virtual Cones
receiving device is fitted
to an emergency service
vehicle, it shall warn the
emergency vehicle
occupants of other
emergency vehicles
approaching and the
direction in a way that is
cognisant of HMI for
vehicles used in
emergency service driving.
The user shall require that
if a Blue Wave/Virtual
Cones receiving device is
not working (Defective) it
shall notify the person or
vehicle occupants
The user shall require that
only vehicles on the road
to the rear and linked
roads to the side of the
emergency vehicle and
within a prescribed
distance should display
the warning from the
Virtual Cones
transmission
The user shall require that
the Virtual Cones device
shall warn the vehicle
occupants what type and
how far the incident is
ahead in a way that is
cognisant of HMI.
The user shall require that
the GST system within
the emergency service
DEL_RSQ_3_1 Architecture and Interface Specifications
This is aimed at providing
warnings to other
emergency service
vehicles, who may be
attending the same
incident or a different
incident, but who’s routes
will cross
Link to Ancillary
Requirement
AR RSQ 0087
Link to Ancillary
Requirement
AR RSQ 0088
This needs to work in
conjunction with Blue
Wave, which may need to
be broadcast at the same
time, but with a different
message.
Link to ancillary
Requirement
AR RSQ 0089
Distance again is critical
in order that driver can
prepare to react to the
incident.
Link to Ancillary
Requirement
AR RSQ 0091
This is required to allow
communication between
data terminals of different
Covered by
specification
paragraph(s)
Status
3/23/2006 379 Version 2.0
In
12.4 X
Out
16.3 X
12.4
12.5
X
12.4 X
16.3 X
Optional
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
This requirement is
dealt outside of
RESCUE since it is

ID (short) Definition Additional explanation
UN RSQ
0105
RQ RSQ
030
UN RSQ
0106
RQ RSQ
031
UN RSQ
0107
RQ RSQ
032
UN RSQ
0108
RQ RSQ
033
vehicle shall be capable of
recognising and
communicating (receiving
and transmitting data)
with any emergency
service authorised digital
input device.
The user shall require that
the communication
between the input device
and the GST system
within the emergency
service vehicle shall be
secure.
The user shall require that
the GST system within
the emergency service
vehicle shall be capable of
dealing with all digital
mediums received and
sent from an authorised
emergency service input
device including voice,
image and data in both
terms of capacity and
speed as required for
emergency service
operations.
The user shall require that
GST Rescue Emergency
Service Device shall
where necessary employ
methods of data
compression for the
transmission of data from
and to authorised third
parties or devices within
the emergency service
vehicle.
The user shall require that
the GST Rescue
Emergency Service
Device within the
DEL_RSQ_3_1 Architecture and Interface Specifications
emergency service
vehicles operating on
different hardware and
software platforms. It is
also required for
communication with
other input devices such
as cameras, PDA,
keyboards, and other
emergency service
equipment (medical, lap
tops etc)
The requirement for
security is fundamental
for the emergency
services as the content of
transmission may be
classified or confidential
This establishes
performance criteria and
thresholds for the
operation of GST for this
purpose. The
transmission of medical
data or the streaming of
video or still pictures will
become increasingly key
to emergency service
operations in the future.
However the timely
transmission and cost of
such operations must
meet the emergency
service operational
requirements.
The need for data
compression is both for
speed and cost. However
quality to ensure adequacy
of service remains critical
This reflects the need for
accurate and timely
information to affect a
rescue or resolve an
Covered by
specification
paragraph(s)
Status
3/23/2006 380 Version 2.0
In
Out
15.1 X
14.1
19.9
14.1
14.4
X
X
Optional
X
Notes
strictly related to
“System
Management”
domain.
This requirement is
dealt within GST
SEC since it is
strictly related to
“Security” domain.

ID (short) Definition Additional explanation
UN RSQ
0109
RQ RSQ
034
UN RSQ
0110
RQ RSQ
035
UN RSQ
0111
RQ RSQ
036
UN RSQ
0112
RQ RSQ
037
UN RSQ
0115
emergency service vehicle
shall be capable of a realtime
two ways
transmission of data
where necessary to and
from authorised third
parties.
The user shall require that
the data transmission
between the GST Rescue
Emergency Service device
within the emergency
service vehicle and the
Public Service Access
Point or to/from an
authorised third party
shall be secure.
The user shall require
that the GST device
within the emergency
service vehicle shall be
able to transmit/Receive
two channels of
communication from/to
the authorised emergency
service input device.
The user shall require that
the GST Rescue
Emergency service device
in one emergency service
vehicle is capable of
communication with
another GST Emergency
Service device where
fitted to a different
emergency service vehicle,
where no direct form of
communication currently
exists.
The users shall require the
GST system and/or the
GST Rescue Emergency
Service Device to log and
retain every transaction
carried out in the
transmission and
reception of data to and
from the emergency
service vehicle or
authorised third party.
DEL_RSQ_3_1 Architecture and Interface Specifications
incident in what can be
life-threatening situations.
This requirement is based
on the need to be able to
send or receive voice and
data (image or other data)
simultaneously.
This is required to allow
communication between
data terminals of different
emergency service
vehicles operating on
different hardware and
software platforms. It is
also required for
communication with
other input devices such
as cameras, PDA,
keyboards, and other
emergency service
equipment (medical, lap
tops etc)
Links to 42 but in vehicle
Covered by
specification
paragraph(s)
Status
3/23/2006 381 Version 2.0
In
Out
15.1 X
14.1
14.4
X
16.3 X
16.3 X
Optional
Notes
This requirement is
dealt within GST
SEC since it is
strictly related to
“Security” domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
RQ RSQ
038
UN RSQ
0116
RQ RSQ
039
UN RSQ
0117
RQ RSQ
040
UN RSQ
0125
RQ RSQ
041
UN RSQ
0126
The user shall require the
GST system to
acknowledge the
transmission and
reception of each
transmission.
The user shall require that
the GST Rescue
Emergency Service device
be capable of receiving
and transmitting data
whilst stationary or
moving.
The user shall require that
where the GST Rescue
Emergency Service device
shall enable emergency
post-rescue, that the
reports be sent to the
appropriate public service
access point or authorised
third party in a form that
they can be automatically
downloaded to the third
party system
The user shall require that
where authorised by the
Emergency Services, the
Emergency Services or an
authorised third party can
send to an authorised
private vehicle or
authorised device
information relating to an
incident.
DEL_RSQ_3_1 Architecture and Interface Specifications
Link to Ancillary
Requirement
AR RSQ 0095
When the Emergency
Service Vehicle arrives at
the incident and starts
rescue operations the
rescue personnel shall be
able to report about the
incident details.
The requirement is that
once these are completed
and sent, the method of
sending should not alter
there content in a way
that prevents
downloading by the
authorised third party,
otherwise the purpose for
doing so is lost.
Link to Ancillary
Requirement AR RSQ
102
Examples include the
hospital could send to the
Doctors in their
authorised private vehicles
the medical information
relating to a person
involved in the incident
and advice to adopt a
particular operation
procedure for the rescue
Link to Ancillary
Requirement AR RSQ
Covered by
specification
paragraph(s)
Status
3/23/2006 382 Version 2.0
In
Out
16.3 X
8.1
9.1
10.2
12.3
14.1
14.4
X
14.1 X
14.4 X
Optional
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
RQ RSQ
042
UN RSQ
127
RQ RSQ
043
UN RSQ
128
RQ RSQ
044
UN RSQ
0130
RQ RSQ
045
UN RSQ
0132
The user shall require that
all the received data (at
UN RSQ 0126) shall be
interpreted and visualised
on a readable and
workable format by the
Authorised Vehicle or
device where no
specialised GST Rescue
Emergency service device
is available.
The user shall require that
the Blue Wave/Virtual
Cone transmission shall
be continuous until
cancelled by the
emergency service
personnel.
The User shall require
that if a waning message
from Virtual Cones or
Blue Wave Device is not
acted upon by the driver
of the vehicle, that the
warning is repeated with
increased notification
The user shall require that
where a route option is
selected by an emergency
service personnel, that the
distance to the route and
journey time is regularly
recalculated and that this
information is displayed
in the vehicle and sent to
DEL_RSQ_3_1 Architecture and Interface Specifications
Covered by
specification
paragraph(s)
Status
3/23/2006 383 Version 2.0
103
A doctor/police officer in
his private vehicle has no
GST Rescue Emergency
service device fitted.
He/She is sent to or
comes across an incident,
which requires e.g.
medical assistance to be
given.
Medical information is
sent to the display screen
of an authorised vehicle
utilising GST capabilities
and if authorised
transmitted back to the
authorised third party.
Link to Ancillary
Requirement AR RSQ
104
Link to Ancillary
Requirement 105
Where the warning
message is to slow down,
where a driver fails to do
so, this could create a
danger to both the driver
and the incident ahead
and the message should
be repeated and the
notification should be
increased, i.e. louder,
brighter etc.
Link to Ancillary
Requirement
AR RSQ 107
This is required so that
Emergency service
personnel can have
accurate information
As to journey time to the
incident
Authorised third parties
could include e.g. rail
operators to keep
In
14.2 X
12.2 X
Out
Optional
12.5 X
11.1 X
Notes

ID (short) Definition Additional explanation
the mobile data terminal
so that it can be
automatically updated on
the command and control
system or to authorised
third parties.
Ancillary System Requirements
AR RSQ
0001
UN RSQ
0002
AR RSQ
0002
UN RSQ
0003
AR RSQ
0003
UN RSQ
0004
AR RSQ
0004
UN RSQ
0005
AR RSQ
0005
UN RSQ
0006
AR RSQ
0006
UN RSQ
0008
The user shall require a
system (the eCall device
described at UN RSQ 1)
that is designed in a way
to minimise false calls.
The user shall require a
system (the eCall device
described at UN RSQ 1)
that is reliable.
The user shall require a
system (the eCall device
described at UN RSQ 1)
that works in all weathers
and situations.
The user shall require a
system (the eCall device
described at UN RSQ 1)
that warns the driver if
the system should fail, in a
manner cognisant with
HMI.
The user shall require a
system (the eCall device
described at UN RSQ 1)
where the thresholds for
activation are set in a way,
which will ensure correct
activation but also prevent
false calls.
The user shall require that
the system (described at
UN RSQ 1) shall not be
automatically activated
until a minimum of two
event inputs are recorded.
DEL_RSQ_3_1 Architecture and Interface Specifications
crossings open
Link to Ancillary
Requirement AR RSQ
109
Link RSQ7 28
Links to UN RSQ 07/08
This is to prevent false
calls even if two or more
sensors deployed.
This may require an
intelligent function to
compare and rationalise
event inputs to minimise
the risk of false calls
Links to UN RSQ 06/07
Covered by
specification
paragraph(s)
Status
3/23/2006 384 Version 2.0
6.1
19.1
6.4
19.2
6.1
6.2
6.3
6.4
In
X
X
X
Out
16.3 X
6.1
19.1
6.1
19.1
X
X
Optional
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain, moreover it
is important to note
that even if error
detection is dealt
within GST OS SP,
HMI is not a scope
of GST IP.

ID (short) Definition Additional explanation
AR RSQ
0007
UN RSQ
0009
AR RSQ
0008
UN RSQ
0010
AR RSQ
0009
UN RSQ
0011
AR RSQ
0010
UN RSQ
0012
AR RSQ
0011
UN RSQ
0013
The user shall require
upon activation that the
system (the eCall device
described at UN RSQ 1)
initiate an automated
eCall (112 voice and data
call).
The user shall require the
automated eCall to roam
to the appropriate Public
Service Access Point 1 no
matter in which country
the vehicle is located.
The user shall require the
system (the eCall device
described at UN RSQ 1)
to transmit as a minimum,
the data pertaining to the
vehicle, incident and its
location as part of the
eCall (as defined in the
minimum set of data by
Project eMERGE).
The user shall require that
upon manual activation,
an eCall voice and data
call to roam to the
appropriate Public Service
Access Point 1 no matter
in which country the
vehicle is located.
The user shall require that
if the eCall data or voice
transmission should fail in
any way, the system shall
continue to transmit until
the acknowledgement of
the reception of the eCall
and the data.
DEL_RSQ_3_1 Architecture and Interface Specifications
Emerge Minimum Set
of data
Privilege – authority level
Version Element – unique
ID system
Time stamp
Location
Direction
Vehicle Description
Model Year
Vehicle Colour
Vehicle model
E call status
Breakdown source –
sensors activated
Breakdown recognition
flag – Fuel type alarm
type
Service provider
Identification
Service Provider
Telephone number
Country Code
Covered by
specification
paragraph(s)
Status
3/23/2006 385 Version 2.0
In
6.1 X
19.3 X
6.4 X
6.4
19.2
19.3
Link RSQ2 (10 & 11) 16.2 X
X
Out
Optional
Notes

ID (short) Definition Additional explanation
AR RSQ
0012
UN RSQ
0015
AR RSQ
0013
UN RSQ
0016
AR RSQ
0014
UN RSQ
0017
AR RSQ
0015
UN RSQ
0018
AR RSQ
0016
UN RSQ
0019
AR RSQ
0017
UN RSQ
0021
AR RSQ
0018
UN RSQ
0022
AR RSQ
0019
The user shall require that
once the eCall has been
successfully completed,
including the transfer of
data, the system should
automatically reset to the
ready state.
The user shall require that
following activation after
an incident all eCall data
and voice transmissions
shall be stored and held
securely in the vehicle.
The user shall require that
the data (referred to at
UN RSQ 16) shall be
capable of being be
retrieved only by
authorised agencies.
The user shall require a
system that informs and
confirms to the vehicle
occupants that an eCall
voice or data is being
transmitted while he’s
waiting for help.
The user (Driver
Passenger) shall be able to
remain connected to the
eCall voice call in order to
receive verbal assistance.
DEL_RSQ_3_1 Architecture and Interface Specifications
Covered by
specification
paragraph(s)
Status
3/23/2006 386 Version 2.0
In
Link RSQ 2 (8) 6.4 X
There is a legal
requirement to secure and
preserve all potential
evidence relating to an
incident.
Out
Optional
Link to Security SP X
The data may be
immediately sent to Public
Service Access Point1,
before the voice call and
the user should know that
data has been sent.
This will enable the
operator to give advice
depending on the need
(e.g. time of arrival,
medical advice or to
obtain further
information from a victim
or witness) whilst waiting
for the arrival of the
emergency services to the
incident.
6.4 X
The user shall require any
eCall data received to be
in the language of the
PSAP 1. Link to UN RSQ 22 X
The User shall require
that the eCall data shall be
received in the form that
the Public Service Access
Point 1 is capable of
receiving it.
The user shall require the
performance timing of the
eCall voice call shall be
Link to UN RSQ 21 7.2 X
Each Country has their
own performance criteria
for the receipt and
X
X
19.11 X
Notes
This requirement is
kept out since it is
strictly related to
HMI domain. Please
refer to AIDE IP
Project.
This requirement is
left for further since
its satisfaction does
not represent a high
value added for GST
IP Project.

ID (short) Definition Additional explanation
UN RSQ
0023
AR RSQ
0020
UN RSQ
0024
AR RSQ
0021
UN RSQ
0025
AR RSQ
0022
UN RSQ
0028
AR RSQ
0023
UN RSQ
0029
country specific.
The user shall require that
the Communication
system (the eCall device
described at UN RSQ 1)
shall automatically
provide confirmation that
the IVS system has
delivered the data to
Public Service Access
Point 1.
The user shall require that
Public Service Access
Point 2 shall be able to
receive the eCall voice
communication from the
Public Service Access
Point 1 by whatever form
of voice
telecommunication
chosen.
The user shall require that
the data shall
at least be received
according to the
minimum performance
criteria set out in Project
Emerge.
The user shall require that
the location data provided
by the eCall is sufficiently
accurate to enable first
resourcing decisions to be
made for the dispatch of
emergency service
vehicles by Public Service
Access Point 2.
DEL_RSQ_3_1 Architecture and Interface Specifications
handling of 112 calls. The
established performance
criteria adopted by the
EU is that of UK
This may be a GST
System Requirement
and/or a Rescue Ancillary
requirement dependant
on what system is used
Minimum set of eMerge
Data to be received no
longer than two seconds
after voice call
Full Emerge data set
available to PSAP 18
seconds after voice call
The level of position
accuracy requires to be
sufficient to identify
which carriageway the
vehicle is in.
Covered by
specification
paragraph(s)
Status
3/23/2006 387 Version 2.0
In
16.2 X
6.4
7.2
X
6.4 X
The user requires that the 7.3 X
Out
X
Optional
Notes
This requirement is
strictly related to
PSAP operational
procedure. No
standardisation vale
is expected by a
voice
communication
forwarding (e.g. a
conference call
establishment
between Vehicle,
PSAP1 and PSAP2)

ID (short) Definition Additional explanation
AR RSQ
0024
UN RSQ
0030
AR RSQ
0025
UN RSQ
0031
AR RSQ
0026
UN RSQ
0034
AR RSQ
0027
UN RSQ
0035
AR RSQ
0028
UN RSQ
0036
eCall data received by the
Public Service Access
Point shall be sufficient to
enable first resourcing
decisions to be made for
the dispatch of emergency
service vehicles.
The user requires that
where an emergency
service is capable of
transmitting data to its
vehicles. The user (Public
Service Access Point)
shall be able to choose the
communication medium
to transmit the data to
emergency service
vehicles.
The user shall require that
the transmission of data
shall be two-way between
the Public Service Access
Point or authorised third
parties and the emergency
service vehicle or GST
Rescue Emergency
Service Device.
The user shall require that
the GST system and/or
the GST Rescue
Emergency Service
Device log and retain
every transaction carried
out in the transmission
and reception of data to
and from the emergency
service vehicle.
The user shall require that
the GST system and/or
the GST Rescue
Emergency Service
Device shall acknowledge
the transmission and
reception of each data
DEL_RSQ_3_1 Architecture and Interface Specifications
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
The Emergency Service
should be able to choose
whether to use using their
own system, GST or
TETRA or another
commercially provided
system.
Where there is no data
capability, the
communication could be
by radio, TETRA or
VHF/UHF or GSM
equivalent.
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Link RSQ 8 (11)
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Link RSQ 8 (12)+ (31)
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Link RSQ 8 (112) & (31)
Covered by
specification
paragraph(s)
Status
3/23/2006 388 Version 2.0
8.1
9.1
8.1
9.1
14.1
14.4
In
X
X
Out
16.3 X
16.2 X
Optional
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
AR RSQ
0029
UN RSQ
0037
AR RSQ
0030
UN RSQ
0038
AR RSQ
0031
UN RSQ
0039
AR RSQ
0032
UN RSQ
0040
AR RSQ
0033
UN RSQ
0041
transmission to and from
the Public Service Access
Point.
The user shall require that
the Public Service Access
Point or authorised third
party transmitted data can
be visualised by way of a
display screen either
within an emergency
service vehicle or on an
emergency service mobile
device.
The user shall require the
display screen employed
for the visualisation of the
data from PSAP 2, or
other authorised third
party or other GST
Rescue Emergency
Service device be capable
of operating in the hostile
environment of a vehicle
and to the rigors of
emergency service usage.
The user shall require that
the incident location data
transmitted from Public
Service Access Point or
other authorised third
party is capable of
automatically updating the
target location
(Destination) of the route
guidance system in the
emergency service vehicle
if fitted.
The user shall require that
the display terminal in the
emergency service
vehicles shall be
compatible with a
keyboard to allow the
emergency service
personnel to input data or
to communicate with
PSAP or other third party
via the data medium.
The user shall require that
the mobile data terminal
automatically provides
updates of the emergency
service vehicle location
and when authorised to
DEL_RSQ_3_1 Architecture and Interface Specifications
Shall make use of existing
screens within the vehicle
if appropriate.
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This includes in vehicle
display terminals where a
bespoke terminal is not
fitted.
The requirement to
automatically update
location is essential for
Emergency service
deployment as the
Emergency service
Covered by
specification
paragraph(s)
Status
3/23/2006 389 Version 2.0
In
10.1 X
11.3 X
14.1
14.4
X
Out
X
X
Optional
Notes
This requirement is
kept out since it is
strictly related to
HMI domain.
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.
This requirement
has been kept out
since HMI is out of
the scope of GST IP
project

ID (short) Definition Additional explanation
AR RSQ
0034
UN RSQ
0042
AR RSQ
0035
UN RSQ
0043
AR RSQ
0036
UN RSQ
0044
AR RSQ
0037
UN RSQ
0045
AR RSQ
0038
UN RSQ
0046
do so by emergency
service personnel updates
of incident and other data
to the Public Service
Access Point command
and control system or
other authorised third
parties
The user shall require that
the display screen fitted to
the emergency service
vehicle be capable of
touch screen operation.
The user shall require that
the mobile data terminal
and other GST Rescue
Emergency Service
Devices installed in the
emergency service vehicle
shall comply with
legislation relating to the
fitment and activation of
display screens within
vehicles.
The user shall require the
due consideration of HMI
when operating the
mobile data terminal or
other GST Rescue
Emergency Service
Devices during emergency
service driving and usage.
The user shall require the
mobile data terminal and
other GST Rescue
Emergency Service
Devices and operating
systems to be suitable for
use when the vehicle is
single crewed in both
driving and other
operations.
The user shall require the
provision of an attack
alarm within the data
terminal to notify Public
Service Access Point
where the emergency
operators require
assistance. This shall be
designed in a way to
DEL_RSQ_3_1 Architecture and Interface Specifications
controllers need to know
where there vehicles are at
any given time. This
automatic vehicle location
functionality is required as
part of the Mobile Data
terminal Functionality
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Covered by
specification
paragraph(s)
Status
3/23/2006 390 Version 2.0
In
14.4 X
Out
X
X
X
X
Optional
Notes
This requirement
has been kept out
since HMI is out of
the scope of GST IP
project
This requirement
has been kept out
since HMI is out of
the scope of GST IP
project
This requirement
has been kept out
since HMI is out of
the scope of GST IP
project
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.

ID (short) Definition Additional explanation
AR RSQ
0039
UN RSQ
0047
AR RSQ
0040
UN RSQ
0048
AR RSQ
0041
UN RSQ
0049
AR RSQ
0042
UN RSQ
0050
AR RSQ
0043
UN RSQ
0051
prevent false activation.
The user shall require that
all Mobile Data
Terminals, GST Rescue
Emergency Service
Devices and GST data
transmission device in the
emergency service vehicle
shall be compatible will all
other emergency service
devices fitted to the
vehicle including speed
and distance recording
devices and image
capturing equipment, and
voice transmission
equipment.
The user shall require that
the Mobile data terminal
or other GST Rescue
Emergency Service
Device fitted to the
emergency service vehicle
shall be fitted with
security controls that only
permit authorised
personnel to operate the
equipment.
The user shall require that
the Public Service Access
Point be able to remotely
disable the mobile data
terminal or there
applicable GST Rescue
Emergency Service
Device in the event of the
emergency service vehicle
or equipment being used
by unauthorised
personnel.
The user shall require the
mobile data terminal to
automatically update the
Public Service Access
Point Command and
Control of arrival at a
predetermined distance
from the incident.
The user shall require that
the mobile data terminal
fitted to the emergency
service vehicle be capable
of communicating with
other data terminals from
DEL_RSQ_3_1 Architecture and Interface Specifications
Link to RSQ 6 (13) +
RSQ 7 (13)
To be synchronised with
Security Sub project.
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
It is envisaged that this
Covered by
specification
paragraph(s)
Status
3/23/2006 391 Version 2.0
In
Out
16.3 X
15.1 X
16.3 X
16.3 X
Optional
X
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“Security” domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System

ID (short) Definition Additional explanation
AR RSQ
0044
UN RSQ
0052
AR RSQ
0045
UN RSQ
0053
AR RSQ
0046
UN RSQ
0054
other emergency services
vehicles if fitted.
The user shall require that
the GST and other linked
systems (Includes GST
Rescue Emergency
Service Devices and other
authorised emergency
service devices) be
capable of additional
functionality or remote
upgrading.
The user shall require that
target location
(destination) shall be
capable of being input::
• Manually via a
human input
device
• Automatically
from a Mobile
Data Terminal
where fitted,
once an incident
together with a
location has
been accepted by
emergency
service
personnel, or
Automatically directly
from an authorised third
party one accepted by the
emergency service
personnel.
The User shall require
that where components
(screens, navigation
systems etc) are fitted as
standard (By OEMs) to
emergency service
vehicles, that through the
middleware of GST they
are capable of being
DEL_RSQ_3_1 Architecture and Interface Specifications
would be a data
transmission. The system
should indicate which
emergency service
vehicles are signed onto
the network.
To allow different
emergency services to
communicate to each
other through
middleware, for otherwise
non compatible systems.
To be synchronised
with the Open Systems
sub project
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
if the route guidance
system is an OEM vehicle
fit or if the route guidance
system is an application
that can be downloaded
through the GST
platform.
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This means that where
data screens or route
guidance systems are
fitted through GST they
Covered by
specification
paragraph(s)
Status
3/23/2006 392 Version 2.0
In
Out
16.3 X
11.1
14.1
X
16.3 X
Optional
Notes
Management”
domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
Par. 14.1 provides
specifications for
data exchange
between ESV and
authorised Third
Parties. The same
principles are valid
for communication
between ESVs.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
AR RSQ
0047
UN RSQ
0055
AR RSQ
0048
UN RSQ
0056
AR RSQ
0049
UN RSQ
0057
AR RSQ
0050
UN RSQ
0058
utilised for emergency
service purposes, to
include GST Rescue and
other emergency service
devices when authorised
to do so.
The User shall require
that the route guidance
system shall identify the
location where the
emergency service vehicle
is automatically.
The user shall require that
the route guidance system
shall compute the fastest
route to the incident and
provide alternative routes
as options.
The User shall require
that the route guidance
system shall take account
of traffic and other
environmental conditions
at the time of preparing
route options and during
the route continue to
assess the route selected,
advising the emergency
service personnel where
adjustments to a route are
advisable in a way that is
cognisant of HMI.
The user shall require that
the route guidance system
shall offer the emergency
service personnel the
route options if available.
DEL_RSQ_3_1 Architecture and Interface Specifications
are capable of being
utilised for the use cases
in RESCUE
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This is a GST system
requirement if the vehicle
location system is an
OEM vehicle fit and the
Route guidance is an
emergency services
bespoke system as this
will require the two to
communicate.
Covered by
specification
paragraph(s)
Status
3/23/2006 393 Version 2.0
In
11.1 X
Link to RSQ 8 (21) 11.1 X
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This includes weather
conditions
11.1 X
11.2 X
Out
Optional
Notes

ID (short) Definition Additional explanation
AR RSQ
0051
UN RSQ
0059
AR RSQ
0052
UN RSQ
0060
AR RSQ
0053
UN RSQ
0061
AR RSQ
0054
UN RSQ
0062
AR RSQ
0055
UN RSQ
0063
AR RSQ
0056
UN RSQ
The user shall require that
the selection of options
from the route guidance
or other GST Rescue
Emergency Service
Device shall be by one
command selection in a
way that is cognisant of
the needs for HMI.
The User shall require
that the route guidance
system shall be capable of
being customised
manually by authorised
emergency service
personnel.
The user shall require that
route guidance system
shall be capable of giving
voice commands as to
route.
The user shall require that
the voice commands shall
be capable of being
switched on/off.
The user shall require that
the voice commands and
route guidance
information shall be
sufficiently accurate to
cater for all speeds that an
emergency service vehicle
will operate at.
The user shall require that
the route guidance system
and all other GST Rescue
Emergency Service
Devices shall work in
DEL_RSQ_3_1 Architecture and Interface Specifications
This will allow the route
guidance system to be
customised to individual
preferences, however this
may be limited by the
emergency service
Covered by
specification
paragraph(s)
Status
3/23/2006 394 Version 2.0
In
11.2 X
19.5 X
19.5 X
19.5 X
Out
X
X
Optional
Notes
It is important to
note that this
requirement is
strictly related to
HMI.
It is important to
note that this
requirement is
strictly related to
HMI.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.
It represents a
general System
Requirement. This is
considered by
Technology oriented

ID (short) Definition Additional explanation
0064
AR RSQ
0057
UN RSQ
0065
AR RSQ
0058
UN RSQ
0066
AR RSQ
0059
UN RSQ
0067
AR RSQ
0060
UN RSQ
0068
AR RSQ
0061
UN RSQ
0069
rural, urban and inter
urban environments.
The user shall require that
the route guidance system
shall provide detail down
to individual house and
field level
The user shall require that
the route guidance system
shall provide levels of
geographic coverage as
defined by the user.
The user shall require that
the route guidance system
shall offer alternative
routes if the driver
deviates from the route.
The user shall require that
the route guidance system
shall provide the
emergency service
personnel information of
approaching
environmental conditions,
road conditions and
hazards in a way that is
cognisant of the need for
Human Machine Interface
under the conditions of
emergency service driving.
The user shall require that
the route guidance system
should notify the Public
Service Access Point
operator when the vehicle
is at the scene.
DEL_RSQ_3_1 Architecture and Interface Specifications
This would assist
emergency service drivers
get to the incident more
quickly and safely. It
could be further enhanced
with links to floating
vehicle data and
information to predict
speed over the ground
and known driving
conditions
(Lights/Wipers on) gear
selected tyre grip sensors.
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Link to 51 and 71
. This should be done
through GST platform
and then it becomes a
GTS system requirement.
Covered by
specification
paragraph(s)
Status
3/23/2006 395 Version 2.0
In
19.5 X
19.5 X
11.1 X
19.5 X
19.5 X
Out
Optional
SPs.
Notes
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.

ID (short) Definition Additional explanation
AR RSQ
0062
UN RSQ
0070
AR RSQ
0063
UN RSQ
0071
AR RSQ
0064
UN RSQ
0072
AR RSQ
0065
UN RSQ
0073
AR RSQ
0066
UN RSQ
0076
The user shall require that
the route guidance system
shall give the emergency
service driver/passenger
the distance and
approximate travel time to
the scene of the incident
taking account of traffic
and other conditions.
This will be regularly
updated whilst en route.
The user shall require that
the route guidance system
and other GST Rescue
Emergency service
Devices shall be reliable.
The user shall require that
the route guidance system
and other GST Rescue
Emergency Services
Devices shall be capable
of being remotely updated
without the vehicle being
taken out of service.
The user shall require that
all the maps and guidance
shall be displayed in a way
that is cognisant of HMI
under the conditions of
emergency service use.
The user shall require that
the Blue Wave/Virtual
Cones transmission
device shall identify what
type of emergency service
vehicle it is fitted to.
DEL_RSQ_3_1 Architecture and Interface Specifications
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Link to 51
This requires the device to
communicate with outside
systems and react to the
information.
This includes all software,
data and for route
guidance maps and
updates.
There is a clear
requirement to identify
what type of emergency
service vehicle is coming
to: Assist drivers in
identifying the hazard
To assist drivers when
they receive multiple
messages of emergency
service vehicles coming
through.
To assist other emergency
services identifying other
emergency service
vehicles that may be
approaching them Link
RSQ 7 (3)
Covered by
specification
paragraph(s)
Status
3/23/2006 396 Version 2.0
In
11.1 X
Out
X
16.3 X
19.5 X
12.3 X
Optional
Notes
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance
System Design.

ID (short) Definition Additional explanation
AR RSQ
0067
UN RSQ
0078
AR RSQ
0068
UN RSQ
0079
AR RSQ
0069
UN RSQ
0080
AR RSQ
0070
UN RSQ
0081
AR RSQ
0071
UN RSQ
0082
The user shall require that
the Blue Wave/Virtual
Cones transmission
device shall only function
when activated by the
emergency service
personnel.
The user shall require that
the on activation the Blue
Wave/Virtual Cones
transmission device shall
send out a message, to
warn of the approach or
presence of an emergency
service vehicle.
The user shall require that
the Blue Wave/Virtual
Cones transmission
device shall offer a range
of messages to the
emergency service
personnel
The user shall require that
the range/coverage of the
Blue Wave/Virtual Cones
transmission should be
automatically adjustable
by speed and location of
the emergency service
vehicle.
The user shall require that
only people that are on
the road ahead and on
connecting roads ahead
and to the side of the
emergency service vehicle,
on its route and within a
prescribed distance
should receive the
warning from the Blue
Wave transmission.
DEL_RSQ_3_1 Architecture and Interface Specifications
This again is essential as
there will be occasions
when emergency service
personnel do not wish to
warn other drivers of their
approach RSQ 7 (5)
To be synchronised
with the security Sub
Project
To examine the link
with the PReVENT IP
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This is required to
provide different
warnings to the other
drivers and to cater for a
range of operational
situations Link RSQ 7 (7)
This may be a GST
System and/or a Rescue
Ancillary depending on
method chosen As speed
increases the range should
increase. The range
should also be assessed by
type of road, so that
approaching junctions the
range to the sides would
increase. Link RSQ 7 (8)
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This needs to work in
conjunction with virtual
cones which may need to
be broadcast at the same
time.
To be synchronised
with the PReVENT IP
This has been widened
from vehicles to people to
Covered by
specification
paragraph(s)
Status
3/23/2006 397 Version 2.0
In
12.1 X
12.1
12.3
X
12.3 X
12.3 X
12.4
12.5
X
Out
Optional
Notes

ID (short) Definition Additional explanation
AR RSQ
0072
UN RSQ
0083
AR RSQ
0073
UN RSQ
0084
AR RSQ
0074
UN RSQ
0085
AR RSQ
0075
UN RSQ
The user shall require that
the Blue Wave/Virtual
Cones transmitting device
shall be capable of being
activated on a one touch
approach or in
combination with other
warning instruments
The user shall require that
the activation of the Blue
Wave/Virtual Cones
device shall be
customisable to the
requirements of the
emergency service
personnel as individuals
and with preset functions.
The user shall require that
the Blue Wave/Virtual
Cones transmitting device
shall not interfere with
any other components of
the emergency service
vehicle.
The user shall require that
the Blue Wave/Virtual
Cones transmitting and
receiving device shall be
designed to be cognisant
DEL_RSQ_3_1 Architecture and Interface Specifications
include other devices such
as mobile phones.
Ease of activation and
combination with other
warning instruments is a
key criteria for
deployment in emergency
service vehicles where
space and speed of
response is critical. It is
key for a single crewed
vehicle for the drivers
attention to be focussed
on driving and other
actions reduced to the
minimum
Link RSQ 7 (10)
The ways in which
warning instruments are
used are very much
governed by the driver’s
preference and the
situation they are
responding to. Recent
advances in technology to
activate warning
instruments build on this
by providing a range of
options for the driver or
the emergency service to
preset. This device needs
to provide this flexibility
in activation and use.
Link RSQ 7 (11)
Covered by
specification
paragraph(s)
Status
3/23/2006 398 Version 2.0
In
12.1 X
12.1 X
Out
Link to RSQ 7 (12) X
Links to RSQ 7 (14)
19.6
19.7
X
Optional
Notes
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.
It is important to
note that this
requirement is
strictly related to
HMI, but GST

ID (short) Definition Additional explanation
0086
AR RSQ
0076
UN RSQ
0087
AR RSQ
0077
UN RSQ
0088
AR RSQ
0078
UN RSQ
0089
AR RSQ
0079
UN RSQ
0090
AR RSQ
DEL_RSQ_3_1 Architecture and Interface Specifications
Covered by
specification
paragraph(s)
Status
3/23/2006 399 Version 2.0
In
Out
Optional
Notes
of HMI. RESCUE is already
providing guidelines
for Blue
Wave/Virtual Cones
System Design.
The user shall require that
the Blue Wave/Virtual
Cones device shall be
designed to be capable of
on transmitting, being
received by any vehicle or
other authorised device,
equipped with a receiving
device, no matter from
where the vehicle or
authorised device is from.
(roaming).
The user shall require that
when activated the Blue
Wave/Virtual Cones or
other GST Rescue
Emergency Service
Device shall warn the
emergency service vehicle
occupants that it has been
activated in a way that is
cognisant of HMI.
The user shall require that
the Blue Wave/Virtual
Cones or other GST
Rescue Emergency
Service
transmitting/receiving
device shall inform the
occupants of the
emergency service vehicle
if it is not working
(defective), whether it is
activated or not.
The user shall require that
the Blue Wave/Virtual
Cones
transmission/receiving
device shall work in all
weathers and conditions
that are applicable in its
area of operation.
The user shall require that
the Blue Wave/Virtual
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This is key for
interoperability. Link RSQ
7 (15)
Examples of other
authorised devices could
include mobile phones
This is both for
confirmation that the
device is activated, and
also a warning should the
device be accidentally
activated
Link RSQ 7 (16)
This is a key requirement
for health and safety as
knowledge that it is not
working needs to be
considered when
responding to a call.
Link RSQ 7 (17)
Link to RSQ 7 (18)
12.3
12.5
19.6
19.7
X
X
16.3 X
16.3 X
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Blue
Wave/Virtual Cones
System Design.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.
X It represents a
general System

ID (short) Definition Additional explanation
0080
UN RSQ
0091
AR RSQ
0081
UN RSQ
0092
AR RSQ
0082
UN RSQ
0093
AR RSQ
0083
UN RSQ
0094
AR RSQ
0084
UN RSQ
0095
Cones
transmitting/receiving
device shall be designed
so that it is robust and
reliable.
The user shall require that
the Blue Wave/Virtual
Cones receiving device
shall receive and interpret
such a message and where
appropriate provide the
warning to the vehicle
occupants or to the
person in cases of other
authorised devices in a
language independent
form.
The user shall require that
the Blue Wave/Virtual
Cones warning shall
inform the vehicle
occupants the type of
emergency service
vehicles approaching or
present in a way that is
cognisant of HMI
The user shall require that
the Blue Wave/Virtual
Cones device shall warn
the person or vehicle
occupants from which
direction the emergency
vehicle is approaching in a
way that is cognisant of
HMI.
The user shall require that
the Blue Wave device
shall warn the person or
vehicle occupants the
number of emergency
service vehicles that are
DEL_RSQ_3_1 Architecture and Interface Specifications
Covered by
specification
paragraph(s)
Status
3/23/2006 400 Version 2.0
In
Out
Optional
Notes
Link to RSQ 7 (19) Requirement. This is
considered by
Technology oriented
SPs.
The requirement for
language independent
warnings is key for cross
border traffic and hire
vehicles. We may also
need to consider drivers
that are deaf. Consider
visual Link RSQ 7 (20)
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This is key to recognition
of the hazard
Link RSQ 7 (21)
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Direction again is critical
in order that driver can
prepare to react to the
emergency service vehicle.
This element will provide
a vital part of increasing
safety by removing the
startling effect of
suddenly hearing the
sirens.
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This again is key as often
the driver reacts to the
first emergency service
12.4 X
12.4 X
12.4 X
12.4 X

ID (short) Definition Additional explanation
AR RSQ
0085
UN RSQ
0096
AR RSQ
0086
UN RSQ
0097
AR RSQ
0087
UN RSQ
0098
AR RSQ
0088
UN RSQ
0100
AR RSQ
0089
approaching. vehicle, but misses the
second one following
close behind resulting in
risks to safety.
The user shall require that
the Blue Wave/Virtual
Cones device should
provide advice as to what
action they should take.
The user shall require that
the Blue Wave/Virtual
Cones device shall when it
no longer receives a
warning, reset and give a
thank you message to the
person or driver
The user shall require that
Where a Blue
Wave/Virtual Cones
receiving device is fitted
to an emergency service
vehicle, it shall warn the
emergency vehicle
occupants of other
emergency vehicles
approaching and the
direction in a way that is
cognisant of HMI for
vehicles used in
emergency service driving.
The user shall require that
if a Blue Wave/Virtual
Cones receiving device is
not working (Defective) it
shall notify the person or
vehicle occupants
The user shall require that
only vehicles on the road
DEL_RSQ_3_1 Architecture and Interface Specifications
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Link RSQ 7 (23) The
Device could provide
information to the driver
as to which direction the
Emergency Service
vehicle was coming from.
i.e. from behind pull over
and stop.
link to RSQ 7 (24)
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This is aimed at providing
warnings to other
emergency service
vehicles, who may be
attending the same
incident or a different
incident, but who’s routes
will cross
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
This May be GST System
and/or a Rescue Ancillary
Covered by
specification
paragraph(s)
Status
3/23/2006 401 Version 2.0
In
12.4 X
13.1 X
12.4 X
Out
16.3 X
12.4 X
Optional
Notes
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
UN RSQ
0101
AR RSQ
0090
UN RSQ
0102
AR RSQ
0091
UN RSQ
0103
AR RSQ
0092
UN RSQ
0104
AR RSQ
0093
UN RSQ
0113
AR RSQ
to the rear and linked
roads to the side of the
emergency vehicle and
within a prescribed
distance should display
the warning from the
Virtual Cones
transmission
The user shall require that
the Blue Wave/Virtual
Cones or other GST
Rescue Emergency
Service Device
transmitting device shall
not interfere with any
other emergency service
equipment, including
radio, and all forms of
detection equipment
The user shall require that
the Virtual Cones device
shall warn the vehicle
occupants what type and
how far the incident is
ahead in a way that is
cognisant of HMI.
The user shall require that
the Messages with virtual
cones to be routed to
Traffic Management
centres and EFCD
control centres as well.
The user shall require that
the GST Rescue
emergency service device
shall be capable of
operating within the
environment of an
emergency service vehicle
and emergency service
operation if removed
from the vehicle.
The user shall require that
the emergency service
DEL_RSQ_3_1 Architecture and Interface Specifications
depending on method
chosen
This needs to work in
conjunction with Blue
Wave which may need to
be broadcast at the same
time, but with a different
message. To be
synchronised with
PReVENT
Covered by
specification
paragraph(s)
Status
3/23/2006 402 Version 2.0
12.5
In
Out
Link to 85 and 48 X
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
Distance again is critical
in order that driver can
prepare to react to the
incident.
To be synchronized
with EFCD and Safety
Channel Sub projects.
This will allow up to date
traffic information to be
made available to other
drivers.
12.4 X
X
X
Optional
Notes
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.
This requirement is
strictly dependant by
EFCD SP which
specify the interface
for getting data from
the external world,
GST RESCUE
included.
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.
19.8 X It is important to
note that this

ID (short) Definition Additional explanation
0094
UN RSQ
0114
AR RSQ
0095
UN RSQ
0117
AR RSQ
0096
UN RSQ
0118
AR RSQ
0097
UN RSQ
0119
AR RSQ
0098
UN RSQ
0120
AR RSQ
0099
UN RSQ
0121
AR RSQ
0100
UN RSQ
Input device shall take
into consideration HMI in
relation to emergency
service usage including
single occupancy usage.
The user shall require that
the GST Rescue
Emergency Service device
be capable of receiving
and transmitting data
whilst stationary or
moving.
The user shall require that
the GST Rescue
Emergency Services
device be capable of
storing and retrieving data
to the onboard unit.
The user shall require that
the GST Rescue
Emergency services
Device onboard storage
device be capable of
deleting data stored on
command
The user shall require that
the storage and retrieval
and deletion of data
stored on the GST
Rescue Emergency
Service Device be subject
to an audit trail
The user shall require a
way to stop transmission
of data from any GST
Rescue Emergency service
Device if accidentally
sent.
The user shall require that
the GST Rescue
Emergency Service device
shall be able to receive
DEL_RSQ_3_1 Architecture and Interface Specifications
This May be GST System
and/or a Rescue Ancillary
depending on method
chosen
To be synchronised
with the Security Sub
Project
When the Emergency
Service Vehicle receives
the signal that an incident
occurred and the Vehicle
Covered by
specification
paragraph(s)
Status
3/23/2006 403 Version 2.0
8.1
9.1
10.2
12.3
14.1
14.4
14.2
14.3
19.8
19.9
14.2
14.3
19.8
19.9
19.8
19.9
In
X
X
X
Out
X
16.3 X
9.1
10.1
X
Optional
Notes
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for VAD System
Design.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for VAD System
Design.
This requirement is
dealt outside of
RESCUE since it is
strictly related to
“System
Management”
domain.

ID (short) Definition Additional explanation
0122
AR RSQ
101
UN
RSQ 0124
AR RSQ
102
UN RSQ
0125
AR RSQ
0103
UN RSQ
0126
AR RSQ
0104
and visualise as much
information as possible or
appropriate from Public
Service Access Point or
other authorised third
party before starting
emergency rescue
operations.
The user shall require that
when approaching the
incident location the
emergency service
personnel shall be able to
establish a
communication link
between the emergency
service vehicle or
emergency service device
and an authorised third
party in order to allow
rapid receipt or
transmission of data to or
from the scene of the
incident.
The user shall require that
where the GST Rescue
Emergency Service device
shall enable emergency
post-rescue, that the
reports be sent to the
appropriate public service
access point or authorised
third party in a form that
they can be automatically
downloaded to the third
party system
The user shall require that
where authorised by the
Emergency Services, the
Emergency Services or an
authorised third party can
send to an authorised
private vehicle or an
authorised device
information relating to an
incident.
The user shall require that
all the received data (at
DEL_RSQ_3_1 Architecture and Interface Specifications
has to reach the incident
point, the request has to
be completed with much
information as possible
available at Public Service
Access Point2 (E-
MERGE MSD at least).
The setting up of such
communication links
prior to arrival means that
the emergency service
personnel can concentrate
on providing assistance at
the scene on arrival.
When the Emergency
Service Vehicle arrives at
the incident and starts
rescue operations the
rescue personnel shall be
able to report about the
incident details.
The requirement is that
once these are completed
and sent, the method of
sending should not alter
there content in a way
that prevents
downloading by the
authorised third party,
otherwise the purpose for
doing so is lost.
Examples include the
hospital could send to the
Doctors in their
authorised private vehicles
the medical information
relating to a person
involved in the incident
and advice to adopt a
particular operation
procedure for the rescue
Medical instrument are
ready to be interfaced by a
Covered by
specification
paragraph(s)
Status
3/23/2006 404 Version 2.0
14.4
14.1
14.4
In
X
14.1 X
14.4 X
14.2 X
Out
Optional
Notes

ID (short) Definition Additional explanation
UN RSQ
0127
AR RSQ
0105
UN RSQ
128
AR RSQ
0106
UN RSQ
0129
AR RSQ
0107
UN RSQ
0130
AR RSQ
0108
UN RSQ
0131
UN RSQ 0126) shall be
interpreted and visualised
on a readable and
workable format by the
Authorised Vehicle or
device where no
specialised GST Rescue
Emergency service device
is available.
The user shall require that
the Blue Wave/Virtual
Cone transmission shall
be continuous until
cancelled by the
emergency service
personnel.
The user shall require that
the GST Rescue
Emergency Service
Device fitted to an
emergency service vehicle
shall be capable of being
removed or permanently
disabled when the vehicle
is sold or no longer used
by the emergency services
The User shall require
that if a waning message
from Virtual Cones or
Blue Wave Device is not
acted upon by the driver
of the vehicle, that the
warning is repeated with
increased notification
The user shall require that
where options for routes
are provided on a route
guidance system, one of
the options shall always
be a map only option with
the vehicle and
destination being shown
which is updated as the
DEL_RSQ_3_1 Architecture and Interface Specifications
PC. The output file from
the in vehicle device can
be loaded as input file
from the in hospital
device. This is / could be
the simplest way to let the
two operators working
with the same
information, same GUI,
same parameter, …. The
same is also required for
GIS systems and access to
third party information
systems and specialised
emergency service
equipment, CCTV,
Fingerprints etc.
Ancillary System
Requirement
This is required for Blue
Wave Virtual cones and
all other GST Rescue
Devices that have security
or other emergency
service restrictions
Where the warning
message is to slow down,
where a driver fails to do
so, this could create a
danger to both the driver
and the incident ahead
and the message should
be repeated and the
notification should be
increased, i.e. louder,
brighter etc.
Covered by
specification
paragraph(s)
Status
3/23/2006 405 Version 2.0
In
12.2 X
Out
X
Optional
12.5 X
19.5 X
Notes
It represents a
general System
Requirement. This is
considered by
Technology oriented
SPs.
It is important to
note that this
requirement is
strictly related to
HMI, but GST
RESCUE is already
providing guidelines
for Route Guidance

ID (short) Definition Additional explanation
AR RSQ
0109
UN RSQ
0132
emergency vehicle travels
to the destination
The user shall require that
where a route option is
selected by an emergency
service personnel, that the
distance to the route and
journey time is regularly
recalculated and that this
information is displayed
in the vehicle and sent to
the mobile data terminal
so that it can be
automatically updated on
the command and control
system or to authorised
third parties.
DEL_RSQ_3_1 Architecture and Interface Specifications
This is required so that
Emergency service
personnel can have
accurate information
As to journey time to the
incident
Authorised third parties
could include e.g. rail
operators to keep
crossings open
Covered by
specification
paragraph(s)
Status
3/23/2006 406 Version 2.0
In
11.1 X
Table 184 – Compliance Matrix – Requirements versus Specifications
Out
Optional
Notes
System Design.

DEL_RSQ_3_1 Architecture and Interface Specifications
PART 4 - APPENDIX SECTION
3/23/2006 407 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
APPENDIX A - TERMS AND ABBREVIATIONS
ACK Acknowledgement
AIDE Adaptive Integrated Driver-vehicle InterfacE
BT Bluetooth
CGALIES Co-ordination Group on Access to Location Information for
Emergency Services
C2CC Car To Car Consortium
CT Core Team
DG INFSO Directorate-General Information Society
E-112 EU enhanced 112 services
EA Emergency Authority
EC European Commission
ECALL Emergency Call based on E-112 (it is composed by Emergency
Data, Location at least, and voice)
EOS End Of Service
ESV Emergency Service Vehicle
FP6 Framework Programme 6
FSD Full Set of Data
GA General Assembly
GIS Geographical Information System
GML Geography Markup Language
HMI Human Machine Interface
HTTP Hypertext Transfer Protocol
IP Integrated Project
IPM Integrated Project Management
IPWPM Integrated Project Work Package Manager (e.g. IPWP3M)
IPWPMT Integrated
IPWP3MT)
Project Work Package Managers Team (e.g.
MSD Minimum Set of Data
OCT On-line Collaboration Tool
PReVENT PReVENTive and Active Safety Applications
PV Public Vehicle
QP Quality Plan
RTCP Real Time Control Protocol
RTP Real Time Transport Protocol
3/23/2006 408 Version 2.0

RTSP Real Time Streaming Protocol
SC Steering Committee
SDP Session Description Protocol
SP Sub-Project
TCP Transmission Control Protocol
TS Test Site
UDP User Data Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
VAD Value Added Data
WP Work Package
XML Extensible Markup Language
XSD XML Schema Definition
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 409 Version 2.0

APPENDIX B - REFERENCES
DEL_RSQ_3_1 Architecture and Interface Specifications
[1] ISO/IEC 10746-1/3/5 Information Technology – Open Distributed Processing –
Basic Reference Model of Open Distributed Processing, RM – ODP
[2] The Unified Modeling Language, Grady Booch, James Rumbaugh, Ivar Jacobson
[3] DEL_GST_3_1 GST Architecture and Interface Specifications
[4] DEL_GST_3_2 GST Framework Architecture and interface specifications
[5] Object Oriented Software Engineering, Ivar Jacobson
[6] Describing a system from multiple viewpoints – using ISO/RM-ODP with Ooram
role modelling and UML, Lasse Bjerde, Arne-Jorgen Berre, Jon Oldevik.
[7] A template for documenting Software and Firmware Architectures, Michael A.
Ogush, Derek Coleman, Dorothea Beringer, HP, Ver 1.3 Mar 2000
[8] DEL_GST_RSQ_2_1 GST RESCUE “Use Cases and System Requirements”
[9] E-MERGE D3.0 “Specifications of the European in-vehicle emergency call”
[10] E-MERGE D4.0 “The E-MERGE developed system”
[11] CGALIES “Finale Report”
[12] http://www.prevent-ip.org/
[13] http://www.aide-eu.org/
[14] WOR_GST_OS_DEV_3_Protocol_Proposal
[15] DEL_SEC_3_1 Architecture and interface specifications
[16] E-MERGE D1.2 “Final Report”
[17] DEL_GST_RSQ_Triggers_v1_0 “Triggers and Thresholds for in-vehicle e-call”
[18] 050325_GST_CAG_App_Protocol_USSD_V1 GST Application Protocol stack for
Emergency call in the RESCUE sub project - USSD description - v 1.0
[19] DEL_OS_3_1 Architecture and interface specifications
[20] http://rfc.net/rfc2119.html
[21] http://www.w3.org/TR/soap12-part1/
[22] E-MERGE “E-Merge FSD Request”
[23] http://www.tpeg.org/
[24] http://opengis.net/gml/
[25] http://www.rtsp.org/
[26] http://www.live.com/
[27] http://www.cswl.com/
[28] http://streamingmedialand.com/
[29] http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/iwsem.html
[30] http://www.realnetworks.com/
[31] http://www.rtsp.org/
3/23/2006 410 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
[32] http://www.ietf.org/rfc/rfc2326.txt
[33] DOC_GST_WP3_WP4_Component_Matrix_RSQ_v0.3.xls
3/23/2006 411 Version 2.0

APPENDIX C - CODE SECTION
DEL_RSQ_3_1 Architecture and Interface Specifications
UC RSQ 005 – ESV Calculate Route Options XML Message Layers
Message structure of UC RSQ 005 – ESV Calculate Route Options (see par. 11.1) is
described by the following XML schemas (XSDs). The schemas represent all the layers
compounding the representation of maps, route, and other geographic information; the
list of the layers is:
• Motorways
• Motorways junctions
• Urban roads
• Roads
• Railways
• Stations
• Rivers
• Lakes (AREA, PERIMETER, NAME)
• Localities (AREA, PERIMETER, PROV_DISTR, LOCALNAME)
• Urban areas (AREA, TYPE)
• Streets names and house numbers (NUMBER, STR_ADDR, ZIPCODE, CITY)
• Airports
• State borders
• Hospitals and medical centres
• Fire Brigades
• Police
• Meteo conditions
• Traffic
• Route (LENGTH)
• Route directions (ACTION)
• ESV position (TIMESTAMP, TIMETARGET, DISTARGET)
• Incident (POINTTYPE, NUMVEHICLE, TIMESTAMP, NUMCASUALT)
Here below is the XSD schema for each layer.
ESV position [TIME_STAMP, TIME_TO_TARGET, DISTANCE_TO_TARGET]
3/23/2006 412 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Motorways
3/23/2006 413 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 414 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Motorways junctions
3/23/2006 415 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Roads: urban roads, rural roads, state roads, expressways
3/23/2006 416 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 417 Version 2.0

Railways
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 418 Version 2.0

Stations
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 419 Version 2.0

Rivers
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 420 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Lakes (AREA, PERIMETER, NAME)
3/23/2006 421 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Localities (AREA, PERIMETER, PROV_DISTR, LOCALNAME)
3/23/2006 422 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Urban areas (AREA, TYPE)
3/23/2006 423 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Streets names and house numbers (NUMBER, STR_ADDR, ZIPCODE,
CITY)
3/23/2006 424 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Airports
3/23/2006 425 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 426 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Borders - other borders (province, region)
3/23/2006 427 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Hospitals and medical centres - Fire fighters - Police
3/23/2006 428 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Meteo conditions

DEL_RSQ_3_1 Architecture and Interface Specifications
Traffic
3/23/2006 430 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Worksites
3/23/2006 431 Version 2.0

Route (LENGTH)
DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 432 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Route directions (ACTION)
3/23/2006 433 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
Incident (POINT_TYPE, VEHICLES, TIME_STAMP, CASUALTIES)
3/23/2006 434 Version 2.0

DEL_RSQ_3_1 Architecture and Interface Specifications
3/23/2006 435 Version 2.0