Global System for Telematics - EUROPA - TRIMIS

GGlloobbaall SSyysstteemm ffoorr TTeelleemmaattiiccss

Release DEL_GST_6_1

Validation Plan

Author(s) Paul van Koningsbruggen (TNO) / Allard Zoutendijk (TNO)

Date Contractual: 01/09/2005 Actual: 17/07/2006

IP Manager Peter Van der Perre ERTICO-ITS EUROPE

Tel: +32 2 400 07 36 E-Mail: [email protected]

Abstract This is the first, official deliverable in WP6 ‘Validation’ on IP-level in

GST. This document describes the so-called ‘invariable’ validation objectives and methods for GST for the first phase in the over-all Validation of GST

Keyword list GST IP-level validation plan, invariable, Assessment Objectives, Indicators, reference cases, measurement methods

Nature of deliverable

Report

Report number

DEL_GST_6_1

Dissemination PP

Version no 3.0

Project financially supported by

European Union DG INFSO

Project number FP6-2002-IST-1-507033

GST Validation Plan

22/03/2006 II Version 3.0

Control sheet

Version history

Version number

Date Main author Summary of changes

0.1 2005/09/20 Paul van Koningsbruggen

Selection of invariables


First draft plan


Final version, input from SPs included

1.1 2006/02/15 Allard Zoutendijk Update as result of progress in WP6

1.2 2006/03/07 Allard Zoutendijk Update questionnaires

2.0 2006/03/22 Allard Zoutendijk Update review comments,

Update submitted to EC

3.0 2006/07/17 Allard Zoutendijk Update questionnaires Final version

Approval

Name Date

Prepared Paul van Koningsbruggen / Allard Zoutendijk 20/03/2006

Reviewed Erwin Vermassen 21/03/2006

Authorized Peter Van der Perre 22/03/2006

Circulation

Recipient Date of submission

Project partners 30/09/2005 , final 18/07/2006

European Commission 30/09/2005 , final 18/07/2006

GST Validation Plan

22/03/2006 3 Version 3.0

Table of contents

Chapter 1 - Introduction ..................................................................................... 5 1.1 Intended audience .............................................................................................5 1.2 Organisation .................................................................................................5 1.3 Typographic conventions...............................................................................5 1.4 Objectives .....................................................................................................6

Chapter 2 - Executive summary.......................................................................... 7

Chapter 3 - Overview of Validation Approach ..................................................... 9 3.1 Nomenclature ...............................................................................................9 3.2 Verification activities .................................................................................9 3.3 Validation activities..................................................................................10 3.4 Relationships between deliverables.......................................................11 3.5 Methodology ...............................................................................................13 3.6 Assessment Objectives.................................................................................13 3.7 Indicators ....................................................................................................14 3.8 Definition of Success and accompanying Reference Cases............................14 3.9 Test Cases ...................................................................................................15

Chapter 4 - Assessment Objectives ................................................................... 16 4.1 Collection and presentation of Assessment Objectives ..................................16 4.2 Identification of Assessment Objectives .......................................................17

Chapter 5 - Indicators....................................................................................... 20 5.1 Collection and presentation of results...........................................................20 5.2 Identification of Indicators ..........................................................................21

Chapter 6 - Test Cases...................................................................................... 25 6.1 Collection of Test Cases...............................................................................25 6.2 Identification of the Verification Test Cases .................................................26

Chapter 7 - Validation at Test Sites................................................................... 46

Chapter 8 - Questionnaires ............................................................................... 52

Literature list ................................................................................................... 54

Terms and abbreviations .................................................................................. 55

Non-Familiar Questionnaire ............................................................................ 56

GST Validation Plan

22/03/2006 4 Version 3.0

Familiar Questionnaire .................................................................................... 62

Table of figures

Figure 1: Flow diagram for validation process GST.........................................................7 Figure 2: Overview of different types of assessment activities .........................................9 Figure 3: Relationship between SP-level deliverables .....................................................12 Figure 4: Relationship between TS and IP-level deliverables..........................................12 Figure 5: Intended openness of GST.............................................................................46

Table of Tables

Table 1: Synopsis of the Test Cases (and related Assessment Objectives and Indicators) for the technical validation of GST on IP-level. ......................................................8

Table 2: Overview of Test Sites that are testing SP reference implementations..............10 Table 3: Overview WP6 deliverables .............................................................................11 Table 4: Definition of terms used when collecting Assessment Objectives ....................16 Table 5: Assessment Objectives for the GST-project ....................................................19 Table 6: Definition of terms used when collecting Indicators ........................................20 Table 7: Indicators for the GST-project ........................................................................24 Table 8: Definition of terms used when collecting Test Cases .......................................25 Table 9: Identification of Test Cases for the GST-project .............................................45 Table 10: Definition of terms used when IP-Level Validation Questions.......................46 Table 11 Overview of IP-Level validation questions and related Test Site Test Cases....51

GST Validation Plan

22/03/2006 5 Version 3.0

Chapter 1 - INTRODUCTION

1.1 Intended audience This document is primarily written for the GST-validators. The document contains a subset of the validation objectives of the Sub-Projects, i.e. the set that addresses the kernel of GST (and is in this way invariant for a specific implementation). Mature versions of the document will be circulated to the Work Package 6 partners in GST (IPWP6MT), the Core Architecture Group (CAG) and the Core Team (CT) for IP-level co-ordination purposes. The final version will be sent to the European Commission (EC) and the General Assembly (GA).

1.2 Organisation This document consists of the following sections:

• Executive summary;

• Validation methodology and approach;

• Assessment Objectives;

• Indicators;

• Test Cases, and

• Next steps

1.3 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

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

GST Validation Plan

22/03/2006 6 Version 3.0

1.4 Objectives Assessment whether GST has met her objectives will be done by verifying the completeness and feasibility of the specifications (by testing the reference implementations) and by validating the openness of GST and the technical operations of the services to be brought to the market (via the tests on the Test Sites).

This validation plan is focussed on the first phase (verification1); the objective of this plan is to:

• Capture the subset of SP-level test cases that (together with subsets of the other SPs) addresses the kernel of GST and therefore is most relevant for the final success of GST.

• Enable a transparent method of Verification of the reference implementations and in this way of the specifications of GST in a real-life situation. Verifying the reference implementations in a real-life situation is an important step in the development phase of the GST system, both forward (guarantee a certain level of quality of the reference implementations (WP 3.2) before starting the validation tests of GST (WP5 and 6)) and backwards (check the completeness and feasibility of the architecture and interface specifications (WP3.1)).

1 See chapter 3 for a definition of phase 1 and phase 2

GST Validation Plan

22/03/2006 7 Version 3.0

Chapter 2 - EXECUTIVE SUMMARY

This document presents for GST on IP-level the method ‘how to verify the completeness and feasibility of the specifications (by testing the interaction between the reference implementations)’ and the method ‘how to validate the openness of GST and the technical operations of the services (via the tests on the Test Sites)’.

WP2 WP3 WP4 WP5

WP7WP ManagerWP Participants

Use cases &system requirements

Project management

Architecture &Interface specifications Field TrialsPrototype

development

Dissemination and exploitation

To and from all WPs

To and from all WPs

WP1

WP6

Validation

<check testability> <carry out verification> <carry out validation>

Figure 1: Flow diagram for validation process GST

A proper technical validation2 of GST implies carrying out the Test Cases, as outlined in Table 1:

2 See chapter 3 for a definition of this term

GST Validation Plan

22/03/2006 8 Version 3.0

Assessment Objective Indicator Test Case

Service Deployment

A certified Service Provider can deploy services via a Control Centre.

Deployment of services

Provisioning of Services Service Fulfilment

A certified Control Centre can provide services to a Client System. Updating (parts of the)

Services

Connection management

Retrieve data from vehicle sensors

Service Consumption

Client System is open for service applications developed by different Service Providers.

Interaction between in-vehicle Client Systems

Reliability of Application Execution

Vehicle Interface Authorization

Billing Centre – Service Centre communication

Billing Agent - Billing Centre Communication

End-User Authentication

Secure Communication for Security Classes

Service Deployment – Fulfilment -Consumption

Prevention of Masquerading

Secure Communication for Heterogeneous Secure Communication for Security Classes Protection against

Eavesdropping Secure Communication for Heterogeneous Secure Communication for Security Classes Detection of Tampering

Secure Communication for Heterogeneous Single Sign On

Authorization for service activation

Access Control


Table 1: Synopsis of the Test Cases (and related Assessment Objectives and Indicators) for the technical

validation of GST on IP-level.

GST Validation Plan

22/03/2006 9 Version 3.0

Chapter 3 - OVERVIEW OF VALIDATION APPROACH

3.1 Nomenclature GST Work Package 6 (WP6) is responsible for Verification and Validation. Figure 2. contains an overview of the assessment activities, which will be carried out in WP6 and the terms as used in the Work Package. The four columns will be explained a bit more in the following sections.

Technical

Single

Laboratory

Non-technical

SP test cases*

TS test cases*

* Some of these also « elevated » to IP-level

Verifi-cation

Valida-tion Question-naires

Objective

Responsibility in the GST-

projectNature Time line

Multiple

LaboratoriesSingle Test SiteMultiple Test

Sites

Figure 2: Overview of different types of assessment activities

3.2 Verification activities Verification activities aim to assess the reference implementations as developed in the various sub-projects. The results help to answer questions like:

• Does the reference implementation comply with the specifications?

• Do the specifications meet the system requirements?

The Verification activities are captured in a set of Test Cases, that will be described in DEL-SP-6.1. These Test Cases have a more technical nature, as they verify the correct functioning of the code and check the quality of the reference implementation. Verification Test Cases are conducted at two levels:

• Single laboratory tests: testing of the compliance of a component with the specification in a controlled environment by a single organisation; and

• Multiple laboratory tests: testing of the compliance of 2 components with the specifications in a controlled environment by different organisations implementing the component, based on the interaction between these components (interoperability).

GST Validation Plan

22/03/2006 10 Version 3.0

The Verification Test Cases will be supported by a more or less formalized Test Suite. This deliverable DEL-SP-6.2 captures the so-called Abstract Test Suite (ATS), which contains a Test Case overview, pre-conditions for the Test Cases, Test Case step activities and interactions among reference implementations (in textual and graphic descriptions), as well as the expected results (post-conditions). Based upon the ATS the so-called Executable Test Suite (ETS) will be developed consisting of the code of the test applications, the emulated data sets and the logging functionality for the actual testing.

The Verification Test Cases will be conducted both by those that are responsible for developing the reference implementations and those Test Sites that are assigned to a sub-project. Table 2 gives an overview of the relationships between Test Sites and sub-projects.

When a cell in Table 3 is grey this means that the TS uses interface specifications or Reference Implementations as generated by the corresponding SP. In DEL-TS-5.1 this is further detailed.

Ope

n Sy

stem

s

Secu

rity

Serv

ice

Paym

ent

Certe

cs

Enh

ance

d FC

D

Resc

ue

Safe

ty C

hann

el

Aachen-Rüsselsheim

Gothenborg

Munich

Paris

UK

Stuttgart

Torino

Table 2: Overview of Test Sites that are testing SP reference implementations

The results of the verification process are reported in a SP-level deliverable DEL-SP-6.3.

3.3 Validation activities Validation activities aim to assess the prototypes as developed in the various Test Sites. The results help to answer questions like:

• Do the GST Test Cases at the seven Test Sites (captured in [4]) meet the end-user needs?

• Are the overall GST objectives realised?

GST Validation Plan

22/03/2006 11 Version 3.0

• Does the GST prototype, as developed on multiple reference implementations as delivered by the sub-projects, work in real-life conditions?

The Validation activities have both a technical and non-technical nature. The non-technical Validation activities focus will be on issues as user acceptance and impact assessment. A questionnaire is used as a supportive tool.

The technical Validation activities are conducted at two levels:

• Single Test Site tests: testing of the compliance of the interaction and cooperation between 2 or more components (implemented by different organisations) with the user needs (and valid system requirements) in a real-world environment on one Test Site; and

• Multiple Test Site tests: testing of the compliance of the interaction and cooperation between 2 or more components of different Test Sites (implemented by different organisations) with the user needs (and valid system requirements) in a real-world environment on the corresponding Test Sites.

The results of the Validation Test Cases will be reported by means of a Test Suite portal and will be reported in DEL-TS-5.2. The results will be used to answer a set of essential questions to validate GST.

The GST IP-level validation results will be reported in DEL-GST-6.2

3.4 Relationships between deliverables As described in the “Description of Work” Work Package 6 will deliver the following set of Deliverables:

IP-level SP-level

Deliverable No Deliverable title Deliverable No Deliverable title

D.GST.6.1 Validation Plan D.SP.6.1 Validation Plan

D.GST.6.2 Validation results D.SP.6.2 Test Suite description

D.SP.6.3 Validation results

Table 3: Overview WP6 deliverables

D.SP.6.1 describes the Assessment objectives, Indicators and Test Cases to verify the GST reference implementations as described in D.SP.3.2. The described Test Cases will be performed both at a SP-level and TS-level. To facilitate the testing Test Suites will be defined (D.SP.6.2). The test results will be reported inside D.SP.6.3. The relationship between Deliverables is presented inside Figure 3.

GST Validation Plan

22/03/2006 12 Version 3.0

Figure 3: Relationship between SP-level deliverables

D.GST.6.1 describes Assessment objectives, Indicators and Test Cases of all sub-projects. Moreover, a list of essential questions to validate the GST system is described. These questions can be answered making use of the test results as defined by a set of Test Site Test Cases (D.TS.5.1). Figure 4 displays the relationship between IP and SP-level deliverables

Figure 4: Relationship between TS and IP-level deliverables

D . SP . 3.2 Reference

Implementations

D.SP.6.2 Test Suite

D . SP . 6 . 3 Validation Results

D.GST.6.1 Validation Plan

D.SP.6.1Validation Plan

D . TS. 5 . 1 Description of the

Test Site

D. TS.5.2 Test Site results

D. GST . 6 . 1 Validation Plan

D.GST.6.2 Validation Results

GST Validation Plan

22/03/2006 13 Version 3.0

3.5 Methodology The validation methodology is based on the CONVERGE Guidelines [1], however the methodology is modified to enable validation of an architecture/concept like GST. Some key elements of the methodology are described in this paragraph.

Based on the CONVERGE approach two stages are distinguished:

• Test Cases

• Test Suites

The technical verification and validation are carried out on the basis of and monitored via Test Cases.

First of all, the SP-level verification Test Cases have the intention to assess if the GST specifications are complete and feasible. Therefore two questions have to be answered after having carried out the SP-level verification Test Cases:

• Is a specific reference implementation build according to the specifications? The aim is not so much to carry out a full conformance test on the reference implementation itself, since we know that this is a prototype, but to test whether the specification is feasible;

• Does the reference implementation contain functions that are not captured in the specifications but that can not be missed for an appropriate operation of the reference implementation? The aim is to verify whether the specification is complete.

Secondly, the TS-level validation Test Cases have the intention to assess whether it is possible to realize and operate an open telematics platform and to deploy services on this platform. To structure the verification, Assessment Objectives, Indicators and Definitions of Success are needed. These terms are explained in the next three paragraphs.

3.6 Assessment Objectives In the overall Validation of GST the Assessment Objectives will be derived according to the following categories:

• Technical assessment (system performance, system impact);

• Non-Technical assessment:

− Impact assessment (safety, environment, transport efficiency, user behaviour, etc.);

− User acceptance assessment (users’ opinions, preferences, willingness to pay);

− Socio-economic evaluation (benefits and costs of system implementation);

− Market assessment (demand and supply); and

− Financial assessment (initial and running costs, rate of return, payback period). The SP-Level Verification focuses on the Assessment Objectives that belong to the category ‘technical assessment’

GST Validation Plan

22/03/2006 14 Version 3.0

IP-level Validation of GST is done by performing tests on the Test Sites that shall generate answers on IP-level questions described in paragraph Chapter 7 - of this document. This TS-Level Validation also focuses on the Assessment Objectives that belong to the category ‘technical assessment’

The non-technical assessment is done by means of questionnaires, described further in paragraph Chapter 8 - of this document.

The identification of Assessment Objectives is primarily based on the definition of user needs, use cases and system requirements as identified by WP2. In WP2 the characteristics of an open telematics platform and the services to be deployed on this platform have been described from a stakeholder point of view.

To be up-to-date, the Verification will consider only (the user needs, use cases and) system requirements that are still valid after the scoping and advancing understandings in Work Package 3 (WP3).

3.7 Indicators Within the Validation process, Indicators are used to measure the performance or estimate the impact (depending on the assessment category) of the system or service to be validated. Their primary goal is to measure whether or not the Assessment Objectives are achieved.

Two basic requirements must be taken into account when the Indicators are defined:

• They must be able to clearly reflect the related performance or impact;

• They must be suitable for a reliable assessment, using the chosen experimental tools and measurement methods. (This asks for a further refinement of the Indicators in parallel with the definition of the test suite, see chapter 8).

In order to:

• enable a GST-wide technical assessment and be able to compare test sites results;

• increase the statistical basis for validation by having validation results that can be consolidated/accumulated;

• enhance objectivity in the validation approach taken by the test sites and SPs

, it is necessary to define a set of equivalent Indicators and to determine those Indicators in a comparable way for the different sub-projects. This will enable generalisation at IP-level of the results that will be provided by the individual SPs (‘will it be technically possible to realize and operate an open telematics platform and to deploy services on this platform’).

3.8 Definition of Success and accompanying Reference Cases Linking an Assessment Objective with overall definition(s) of success for its related Indicator(s) is a fundamental step in the design of the technical Validation. Practice of success/failure testing means that the minimum desired ‘performance’ or ‘impact’ of an Indicator is determined before the testing is started.

GST Validation Plan

22/03/2006 15 Version 3.0

The definition of success can be defined referring to a so-called reference case. For the GST project, we consider two reference cases:

• For the verification, the reference case will be:

− The specifications of GST (does the reference implementation comply to the specifications?);

− The system requirements, use cases and user needs (which are still valid after WP3) (is it technically possible to realize and operate an open telematics platform and to deploy services on this platform?);

• For the non-technical assessment, the reference case will be the current, existing situation and the intended change (as WP2 started to express in the Operational Concept Description).

3.9 Test Cases The Assessment Objectives, Indicators and definitions of success have to be translated in Test Cases. In the end the implementation of a Test Case should prove that: 1. a pre-defined impact will be realised or a pre-defined performance will be achieved

(derived from the related Indicator); 2. with a pre-defined success (derived from the related criterion of success); 3. so that a pre-defined GST-objective can really be fulfilled (derived from the related

Assessment Objective);

In general, a sub-project is responsible for the analyses of its own Test Cases .As the specifications and RI’s generated by the SP’s are used – either directly or as example – for the development of GST prototypes, the same SP-level Test Cases are repeated at Test Sites (see Table 2). Furthermore at the Test Sites more complex test cases are defined (described in DEL-TS-5.1) to put the prototypes to the test and to generate answers on the IP-level validation questions.

GST Validation Plan

22/03/2006 16 Version 3.0

Chapter 4 - ASSESSMENT OBJECTIVES

4.1 Collection and presentation of Assessment Objectives The sources of information for collecting the GST-project Assessment Objectives for the Validation Plan are the system requirements, use cases and user needs, which are still valid after the scoping and advanced understandings in WP3.

The Assessment Objectives of GST-project are outlined in Table 5. An explanation of the columns of the tables used in this chapter is given in Table 4.

Title Explanation

Assessment category Technical (since for the phase 1 validation plan the focus is on technical Assessment Objectives)

(Assessment Objective) ID Each Assessment Objective has a unique ID number to allow traceability. The format used is as follows: AO-[sub-project name]-[sequence number], where the GST-project name is:

• GST And in addition, the sub-project name is:

• EFCD·

• CERTECS·

• SEC·

• OS·

• RSQ

• SAF-CHAN·

• S-PAY

Where sequence number is:·

• 4 digits: 0001, 0002, … 9999 (short) Definition Each Assessment Objective is written out in a short

precise manner so that the precise objective is clear. Additional explanation This provides more information for a better

understanding of the needs / purpose behind the Assessment Objective.

Link to user need Link to user needs of WP2

Table 4: Definition of terms used when collecting Assessment Objectives

GST Validation Plan

22/03/2006 17 Version 3.0

4.2 Identification of Assessment Objectives The Assessment Objectives identified for the GST-project are presented in Table 5:

Assessment Objective

ID (short) Definition Additional explanation Link to user case3 Assessment category

Technical Only AO-GST-0001 Service Deployment

The Service Centre User delivers the service application from the Service Centre to the Control Centre according to the chosen business model between the Service Centre User and the Control Centre User The Service Centre User makes all necessary configuration changes in the Control Centre. The Control Centre makes the service application available to appropriate provisioned Service Platforms.

UC-GST-0001

3 In the SP-level validation plans a reference is made to the user needs. On IP (GST) level there are no user needs defined in WP2, so a reference is made here to the use cases.

GST Validation Plan

22/03/2006 18 Version 3.0

AO-GST-0002 Service Fulfilment

The actions associated the delivery of the operational services to a End User

UC-GST-0004: • UC-GST-0011 • UC-GST-0012 • UC-GST-0013 • UC-GST-0014 • UC-GST-0015 • UC-GST-0016

UC-GST-0005, UC-GST-0007, UC-GST-0009, UC-GST-0010, UC-GST-0021, UC-GST-0022:

• UC-GST-0011 • UC-GST-0012 • UC-GST-0017 • UC-GST-0018 • UC-GST-0026

UC-GST-0023 UC-GST-0024 UC-GST-0025:

• UC-GST-0026 • UC-GST-0027 • UC-GST-0028 • UC-GST-0029

GST Validation Plan

22/03/2006 19 Version 3.0

AO-GST-0003 Service Consumption

The act of making use of a service on a Service Platform.

Preconditions : • the End-user is

authenticated on the Client System;

• The End-User uses the service application;

• The service application contacts the Service Centre directly or through the Control Centre to get content if needed;

• A backup of the end user data is done if needed.

UC-GST-0008: • UC-GST-0002 • UC-GST-0003 • UC-GST-0016

Table 5: Assessment Objectives for the GST-project

Note: GST-Use case UC-GST-0030 ‘Service Certification’ is covered by the CERTECS SP-Validation Plan.

GST Validation Plan

22/03/2006 20 Version 3.0

Chapter 5 - INDICATORS

5.1 Collection and presentation of results The sources of information for collecting the GST-project Indicators for the Validation Plan are the work items from WP3, which express how the system requirements of WP2 will be met by the system or service.

The Indicators of the GST-project are outlined in Table 7. An explanation of the columns of the tables used in this chapter is given in Table 6.

Title Explanation

Indicator ID Each Indicator must have a unique ID number to allow traceability. The format used is as follows: IN-[sub-project name]-[sequence number], where the GST-project name is:


• EFCD

• CERTECS·

• SEC

• OS

• RSQ

• SAF-CHAN

• S-PAY

Where Sequence number is:

• 4 digits: 0001, 0002, … 9999

(Indicator) Definition Each Indicator is written out in a short precise manner so that the intended performance or impact of GST is clear.

(Indicator) Additional explanation

This provides more information for a better understanding of the needs / purpose behind the Indicator.

Definition of success Success criterion / criteria for the Indicator Link to system requirements Link to system requirements of WP2 that are still valid, or to new

system requirements that belong a part of the specifications in WP3. Link to Assessment Objectives Link to Assessment Objectives Table 5

Table 6: Definition of terms used when collecting Indicators

GST Validation Plan

22/03/2006 21 Version 3.0

5.2 Identification of Indicators The Indicators identified by the GST-project are presented in Table 7:

ID (short) Definition Additional explanation Definition of success

Link to system requirements

Link to Assessment Objective

IN-GST-0001 A certified Service Provider can deploy services via a Control Centre.

A certified Service Provider can offer services to any GST-compliant vehicle via a GST compliant Control Centre.

Vice versa, a GST compliant Control Centre can collect services from any certified Service Provider.

Deployed Applications can be discovered by matching Client Systems with an acceptable failure rate.

DEL-GST-3-2-Chapter 6

See OS AO-GST-0001

IN-GST-0002 A certified Control Centre can provide services to a Client System.

A GST compliant Control Centre can provide services to every End-user in a GST-compliant vehicle.

Vice versa, an End-User can select services available for his/her vehicle.

Provisioned and updated Applications are operational on the Client System with an acceptable failure rate.


See OS AO-GST-0002

IN-GST-0003 Client System is open for service applications developed by different

Client System is open for service applications developed by different Service Providers,

Service Centre receives set of messages as

See OS AO-GST-0003

GST Validation Plan

22/03/2006 22 Version 3.0

Service Providers. by offering an application runtime environment and a set of standardised APIs for the access to the communication channels, localisation device, in-vehicle sensors

generates by Application operational on the Client System with an acceptable failure rate.


Applications operational on the Client System receive regular updates of sensor data from the selected subset of vehicle sensors (if they register for it) with an acceptable failure rate.


See OS

IN-GST-0004 Prevention of Masquerading All GST entities have to be authenticated

Use of false Identity in the system is not possible. DEL-GST-3-2-Chapter 7

See SEC AO-GST-0001, AO-GST-0002, AO-GST-0003

GST Validation Plan

22/03/2006 23 Version 3.0

IN-GST-0005 Protection against Eavesdropping

Data Encryption to ensure the confidentiality of the data

Access to confidential data not possible DEL-GST-3-2-Chapter 7

AO-GST-0001, AO-GST-0002, AO-GST-0003

IN-GST-0006 Detection of Tampering The security system ensure the integrity of the data

All data manipulation will be detected DEL-GST-3-2-Chapter 7


IN-GST-0007 Access Control The security system controls the access on all entities and functions

No access for unauthorized Users and Entities DEL-GST-3-2-Chapter 7


IN-GST-0008 Reliability of Application Execution

Applications, running on GST Entities, have to be controlled from the security system to avoid unreliability of the running system (cp. Java Sandbox)

Access to security operation from application level is controlled DEL-GST-3-2-Chapter 7

See SEC AO-GST-0003

IN-GST-0009 Billing Centre – Service Centre communication

The user should be able to pay for consumed services using multiple payment methods

The failure rate of Billing Centre – Service Centre communication

DEL-GST-3-2-

See SEC AO-GST-0003

GST Validation Plan

22/03/2006 24 Version 3.0

Chapter 8

Table 7: Indicators for the GST-project

GST Validation Plan

22/03/2006 25 Version 3.0

Chapter 6 - TEST CASES

6.1 Collection of Test Cases The Test Cases the GST-project are derived from the Assessment Objectives, Indicators and definitions of success.

The Test Cases of the GST-project are outlined in Table 9. An explanation of the columns of the tables used in this chapter is given in Table 8.

Title Explanation

Test Case ID Each Test Case has a unique ID number to allow traceability. The format used is as follows: TC-[sub-project name]-[sequence number], where the GST-project name is:


• EFCD·

• CERTECS·

• SEC·

• OS·

• RSQ

• SAF-CHAN·

• S-PAY

Where Sequence number is:·

• digits: 0001, 0002, … 9999 Name Short name of Test Case for easy reference

Objective The objective of the Test Case Motivation This provides more information for a better

understanding of the Test Case Steps The steps to be followed and checked of each Test Case

Expected results (measurable) This provides the expected result (measurable) of each step

Test location (where carried out) Test location of the Test Case Links Link to Indicators Table 7

IP-Level Test Case That is part of the sub-set of IP-level Test Cases

Table 8: Definition of terms used when collecting Test Cases

GST Validation Plan

22/03/2006 26 Version 3.0

6.2 Identification of the Verification Test Cases The SP-Level Verification Test Cases identified by the GST-project are presented in Table 9. These Test Cases will be further detailed in the corresponding SP-Level Validation Plan (DEL-SP-6.1). The last column in the table tells to what SP-level Test Case the GST level Test Case is allocated to.

Description ID

Name Objective Motivation

Steps Expected results (measurable)

Test location (where carried out)

Links to Indicators

SP-level Test Case

(allocated to)

TC-GST-0001

Connection management

To assess whether any service application can get access to the communication channels in an flexible and open way

A service application should be able to send messages to a SC or other CS at any time. These messages should be send

Start appropriate test scenario → specific communication channel and start Connectivity Test Application

Active Communication Channel and Running Connectivity Test Application

OS::Connection Manager GST Protocol Stacks::CS↔SC

IN-GST-0003

OS (TC-OS-0002)

GST Validation Plan

22/03/2006 27 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

Connectivity Test Application acquires a connection using the Connector Service

Connectivity Test Application has a connection to a communication channel

Connectivity Test Application generates and sends set of prioritised messages to SC

SC receives set of messages as generates by Connectivity Test Application

To assess whether the TCU is capable to select to most appropriate communication channel To assess whether the communication manager (SOAP connection factory) is capable to prioritise the messages coming from the S Apps and then send the messages in prioritized order.

via the most appropriate communication channel.

Add dynamically a new Connection Factory application with a new scheme (more suitable for Sapp)

New Connection Factory Application available on CS

GST Validation Plan

22/03/2006 28 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

The Connectivity Test application is notified that there is a new and better communication channel available

Connectivity Test Application is aware of availability of new and better communication channel

Test CC-V and bi-SC-V protocols.

Connectivity Test Application acquires a connection to the new and better communication channel using the Connector Service

Connectivity Test Application has a connection to the new communication channel

GST Validation Plan

22/03/2006 29 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

Connectivity Test Application generates and sends a new set of prioritised messages to SC

SC receives set of messages as generates by Connectivity Test Application

Positioning Test App requests for position

Positioning Test App has received actual position CS

Positioning Test App registers itself for receiving regular updates of the position (events)

Positioning Test App receives regular updates of actual position CS

TC-GST-0002

Retrieve data from vehicle sensors

Assess the capability of any service application on the Client System (local)

Service applications running on the CS (local) or at the SC (remote) should be able

Start appropriate test scenario → Start Vehicle Sensor Test Application

Running Vehicle Sensor Test Application

OS::Vehicle Sensor Interface

IN-GST-0003

OS (TC-OS-0006)

GST Validation Plan

22/03/2006 30 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

Vehicle Sensor Test Application introspects the status elements

Vehicle Sensor Test Application reports the available sensors in the vehicle

Vehicle Sensor Test Application retrieves data from each of the available sensors

Vehicle Sensor Test Application has received data from each of the available sensors

and at a Service Centre (remote) to retrieve data from the in-vehicle sensors in an flexible and open way Test the in-vehicle interface

to build a model of the vehicle condition, driver's behaviour and the world around the vehicle using data from the in-vehicle sensors.

Vehicle Sensor Test Application selects subset of available vehicle sensors for which it wants to receive updates of the data

Vehicle Sensor Test Application has selected a subset of available vehicle sensors

GST Validation Plan

22/03/2006 31 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

Vehicle Sensor Test Application registers itself at the selected subset of vehicle sensors for receiving regular updates of the sensor data

Vehicle Sensor Test Application receives regular updates of the sensor data from the selected subset of vehicle sensors

SC packages the necessary components for the Deployment Test Application

Deployment package is available at SC

TC-GST-0003

Deployment of services

Assess the capability for a service centre to deploy services by submitting the service applications from the SCs to CCs and by making it possible for a CS to

A service provider should be able to deploy its services via his service centre to any CS independent from OEM-er

SC submits the Deployment package to the CC

Deployment package is successfully unpacked and stored at CC

OS::Deployment Server OS::Provisioning Client OS::Provisioning Server GST Protocol Stacks::CS↔CC

IN-GST-0001

OS (TC-OS-0007)

GST Validation Plan

22/03/2006 32 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

discover these services Test SC-CC protocol

CC makes the Deployment Test Application available for matching CSs

Deployment Test Application can be discovered by matching CSs

End-User logs on to the CS

End-User is logged on.

Provisioning Client synchronises with the Provisioning Server

List of available services is up to date on CS

TC-GST-0004

Provisioning of Services

Assess the capability of an end-user to discover services and to subscribe to a specific service via the CS Assess the capability of a CC to provide the service application to the CS

An end-user should be able to discover the available services supported by his/her CS, to subscribe to these services and to consume the services

End-User selects the Provisioning Test Service

Provisioning Client is aware it needs to provision the Provisioning Test Service

OS::Provisioning Client OS::Provisioning Server GST Protocol Stacks::CS↔CC

IN-GST-0002

OS (TC-OS-0008)

GST Validation Plan

22/03/2006 33 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

Test CC-V protocol

Provisioning Client provisions the Provisioning Test Aplication

Provisioning Test Application is operational on the CS

End-user logs on to the CS

End-User is logged on

Provisioning Client synchronises with the Provisioning Server

Provisioning Client discovers that the Updating Test Application needs to be updated

TC-GST-0005

Updating (parts of the) Services

Assess the capability of a CS and CC to update (parts of) the service application

A service provider should be able to keep the service applications out in the field up to date. In the same way should an end-user be able to keep the services he/she is consuming up-to-date.

Provisioning Client updates the Updating Test Application

Updated Updating Test Application is operational on the CS

OS::Provisioning Client OS::Provisioning Server GST Protocol Stacks::CS↔CC

IN-GST-0002

OS (TC-OS-0009)

GST Validation Plan

22/03/2006 34 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

Start appropriate test scenario → specific communication channel and start V-V Test Application

Active Communication Channel and Running V-V Test Application

TC-GST-0006

Interaction between in-vehicle Client Systems

Assess the capability of a service application on one vehicle bound CS to exchange events with a service application on another vehicle bound CS Test V-V protocol

Vehicles should be able to warn each other for traffic related events (e.g. accidents, slippery road surface, traffic jam tails) so that vehicle drivers can react just-in-time.

V-V Test Application acquires a connection to the vehicle-vehicle communication channel using the Connector Service

Connectivity Test Application has a connection to the vehicle-vehicle communication channel

GST protocol Stack::V↔V

IN-GST-0003

OS (TC-OS-0010)

GST Validation Plan

22/03/2006 35 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

V-V Test Application generates and sends set of prioritised messages to the CS of the other vehicle

CS of the other vehicle receives set of messages as generates by V-V Test Application

TC-GST-0007

End-User Authentication

Online and Offline Authentication, Impact of CRLs, Focus on Authentication Process, Independency from technology

Mandatory to identify the user for GST Services

tbd tbd TUM (SEC:: End-User Authentication)

IN-GST-0004

SEC (TC-SEC-01)

TC-GST-0008

Single Sign On Using SSO for Car Portal and Client System (TCU, Nomadic

Authentication in a multiple Stakeholders Environment

User login at Aggregator Portal (e.g. username/pwd)

User is authenticated at the Control Centre of the Aggregator

TUM (SEC:: Authentication Handler)

IN-GST-0007

SEC (TC-SEC-03)

GST Validation Plan

22/03/2006 36 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

user selects a service offered by Provider X (member in the Circle of Trust of the Aggregator)

access rights are checked and SAML Assertion for user is generated by SAML Authority of Aggregator and is redirected (e.g. via http/SOAP) to portal of Provider X

RSA (SEC:: Assertion Authority)

Device), Access to several services.

Provider X validates presented assertion via a assertion consumer component

Access to services is granted

TUM (SEC:: Assertion Consumer)

GST Validation Plan

22/03/2006 37 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

vehicle login (using token data) at Aggregator portal

user is authenticated at the Control Centre of the Aggregator, assertion containing service access rights is created and provided to vehicle

TUM (SEC:: Authentication Handler)

Corresponding to the access rights the user selects a service he is offered by Provider X (member in the Circle of Trust of the Aggregator)

service access request is processed by Service Provider X using an assertion consumer component and successful validation response is sent to vehicle

TUM (SEC:: Assertion Consumer)

User access to the service

Access is successful

-

GST Validation Plan

22/03/2006 38 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

1. Client System starts services

1. Client System requests service authorization

-

2. Aggregator handles request

2. Aggregator looks up subscribed services of the respective user and generates an assertion

RSA (SEC:: Assertion Authority)

3. Client System handles assertion

3. Client System receives assertion generated by the Aggregator and performs the policy enforcement

-

TC-GST-0009

Authorization for service activation

User is authorized to the right list of Services

Authorization in a multiple Stakeholders Environment

4. Service authorization

4. All authorized services start and are usable

-

IN-GST-0007

SEC (TC-SEC-04)

TC-GST-0010


Access Control for vehicle data depending on

Crucial Policy Enforcement Point for

S App initiate access at Vehicle Adapter

IN-GST-0007, 0008

SEC (TC-SEC-

GST Validation Plan

22/03/2006 39 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

PEP receive request

Access controlled

Trialog (SEC::local PDP, SEC::PEP)

PEP retrieve authentication

see TC-SEC-08 Trialog (SEC::Entity Authentication)

PDP apply local policy

Policy decision Trialog (SEC::local PDP, SEC::PEP)

PEP returns result to Vehicle Adapter

Access granted or denied

Trialog (SEC::local PDP, SEC::PEP)

user and service application

OEMs!!!

S App returned data or access denial

-

07)

TC-GST-0011

Secure Communication for Security Classes

Provide the four GST Security Classes (in-secure, confidential, authenticated,

Mandatory for security in distributed systems (as GST)

1. Send insecure message in passive attacker environment

Passive attacker is able to read the contents of the sent message and its source address

KUL (SEC:: Secure Communication Engine)

IN-GST-0004, 0005, 0006

SEC (TC-SEC-09)

GST Validation Plan

22/03/2006 40 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

2. Send insecure message in active attacker environment

Active attacker is able to modify the contents of the sent message and spoof the message source address without detection

KUL (SEC:: Secure Communication Engine)

secure)

3. Send authenticated message in passive attacker environment

Passive attacker is able to read the contents of the sent message and its source address

KUL (SEC:: Secure Communication Engine, SEC::Security Module)

GST Validation Plan

22/03/2006 41 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

4. Send authenticated message in active attacker environment

Active attacker is able to modify the contents of the sent message without detection, but spoofing the message source address is detected by the destination


5. Send confidential message in passive attacker environment

Passive attacker is not able to read the contents of the sent message, while it can read its source address


GST Validation Plan

22/03/2006 42 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

6. Send confidential message in active attacker environment

Active attacker is not able to modify the contents of the sent message without detection, while it can spoof the message source address without detection


7. Send secure message in passive attacker environment

Passive attacker is not able to read the contents of the sent message, while it can read its source address


GST Validation Plan

22/03/2006 43 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

8. Send secure message in active attacker environment

Active attacker is not able to modify the contents of the sent message and spoofing the message source address is detected by the destination


TC-GST-0012

Secure Communication for Heterogeneous

Security not compromised when using different security mechanisms in the communication chain

GST is a distributed, heterogeneous system

1. Send secure message to destination via intermediate entity(ies) in passive attacker environment

Passive attacker monitoring all point-to-point communication links is not able to read the contents of the sent message, while it can read its source address


IN-GST-0004, 0005, 0006

SEC (TC-SEC-10)

GST Validation Plan

22/03/2006 44 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

2. Send secure message to destination via intermediate entity(ies) in active attacker environment

Active attacker having access to all point-to-point communication links is not able to modify the contents of the sent message and spoofing the message address is detected by the destination


GST Validation Plan

22/03/2006 45 Version 3.0

Description ID




Links to Indicators

SP-level Test Case

(allocated to)

The Billing Agent creates the report of the collected info to the Billing Centre and fires log events to the Billing Centre containing the messages sent to and received from the Communication Manager

Billing Centre receives collected usage info

Prosyst (S-PAY::Billing Centre)

TC-GST-0013

Billing Agent - Billing Centre Communication

To check the correctness of the communication between the Billing Agent and the Billing Centre

The collected billing information on the Client System by the Billing Agent should be aggregated by the Billing Centre in order to prepare the bill statement at the end of the billing period

The Billing Centre reports changes in the subscription status or the number of pre-paid billing units

Changes are reported

Prosyst (S-PAY::Billing Centre)

IN-GST-0009

S-PAY

(TC-S-PAY-0006)

Table 9: Identification of Test Cases for the GST-project

GST Validation Plan

22/03/2006 46 Version 3.0

Chapter 7 - VALIDATION AT TEST SITES

The intended openness of GST is illustrated in Figure 5.

Open Telematics Market

End User End User End Us er

Service Provider

Service Provider

Service Provider

Ease of Market AccessFreedom of choice in service consumption

Avoid unduly high barriers of market entry

Ease of Market Access

Figure 5: Intended openness of GST

The validation of GST - by testing prototypes at the Test Sites - is focused on the assessment that above openness is feasible. The validation process starts with the formulation of IP-level questions and assigning those questions to Test Site, meaning that the Test Site should runs test to enable the generation of an answer to the question. The IP-Level Validation questions are described in. In Table 10 it is explained how the table should be interpreted.

Title Explanation

IP-Level Validation Question Each Validation Question has a unique ID number to allow traceability. The format used is as follows: IP-

VAL-[sequence number Where Sequence number is:·

• digits: 0001, 0002, … 9999 Underlying Question The IP-Level basic question to be answered

Name Translation of the underlying question into a short technical description

Objective The objective Motivation This provides more information for a better

understanding of the Test Case Test Sites These columns indicate what Test Sites should perform

tests to validate that the question can be answered satisfactorily (i.e. the GST prototype does function as

the question implies).

Note: In these columns Test Cases are identified explicitly (i.e. have a sequence number), but this is

preliminary. Final sequence numbers will be described in DEL-TS-5.1 and/or DEL-TS-5.2.

Table 10: Definition of terms used when IP-Level Validation Questions

GST Validation Plan

22/03/2006 47 Version 3.0

ID Underlying question Name Objective Motivation München Aachen-Rüsselheim Stuttgart Paris UK Goteburg TorinoIP-VAL-1 TC-Munich-005

IP-VAL-2

TC-Munich-002 TC-AC/R-0001 TC-Paris-0001

TC-Gothenburg-0001

TC-Paris-0002

(TC-Gothenburg-0004)

TC-Paris-0007

IP-VAL-3 TC-Munich-004 TC-AC/R-0008 TC-Paris-0009 TC-Torino-0008TC-Paris-0013 TC-Torino-0009

IP-VAL-4 TC-Munich-006 TC-Paris-0005

An End-User should have secure and standardized access to services (part of GST mission statement)

GST should have the capability to enable user specific service consumption on different client systems

Authentication, Authorization and Single Sign on

An End-User is authenticated once against an Aggregator (hosts a Control Centre) and is enabled to use services in a Circle of Trust.

Demonstrate separation of service access infrastructure from authentication infrastructure via using a standardized and open protocol (SAML)

Service consumption based upon profile update (e.g. user and vehicle profile).

To assess that service characteristics of an existing service are changed and synchronized based on general GST service provisioning process (both at the Client System and at the Control Cenre hosted by the Aggregator) once the user changes the service characteristics of a existing / operational service

To assess that an End-User is enabled to subscribe to services using a Client System (on a PC, nomadic device or in a vehicle) and to activate the Service Applications (immediately) using a in-vehicle Client System

Service Portability (siging on seperatly)

To assess that an End-User can switch between vehicles -more generic: between Client Systems- maintaining an synchronized user profile

GST should enable flexible adaption of services to actual user profile via a standardized service provisioning process

Service access and activation (once signed on)

Ease of market access → Freedom of choice in service consumption

Can I access different services from different Service Providers once logged in?

Can I select and subscribe to these services once logged in, and activate and use them ?

Can I use my services when I switch from one vehicle to another or to a nomadic device (and vice versa)

Can I change the characteristics of a running service to my new needs?

GST Validation Plan

22/03/2006 48 Version 3.0

ID Underlying question Name Objective Motivation München Aachen-Rüsselheim Stuttgart Paris UK Goteburg TorinoIP-VAL-5 TC-XSITE-003 TC-XSITE-003

IP-VAL-6

TC-Munich-011

TC-Gothenburg-0002

IP-VAL-7 TC-Munich-015 TC-AC/R-0007

IP-VAL-8 TC-Munich-012

IP-VAL-9 ?TC-Munich-012?

Can I collaborate with a Service Provider in another region to make my service more attractive?

Can I add my Service Centre to the circle of trust?

Can I bring my service via different Service Aggregators to the market?

Can I operate a service independent from the telecom operator?

Is my service independent of the implementation of the Control Centre (based on the same specification)?

GST should have a flexible infrastructure with respect to federated service providers and aggregators

GST should have a flexible infrastructure enabling handing over between service providers

Federated service operation with two Aggregators

GST should demonstrate flexibility and openness of infrastructure with respect to authenthication and service access : a Service Centre can allow service access without knowing authentication technologies and processes used by an Aggregator (separation of service access from authentication)

To assess that a service can be accessed using different Aggregators for authentication

Adding Service Centres To assess that Service Centres can be dynamically added to or removed from a Circle of Trust with respect to generation and use of SAML assertions. (Circle of Trust management). Note: adding a service centre completely requires additional steps (e.g. service registration at Aggregator), steps that are not part of the most critical testcases.

Provision interoperability

To asses that Synchronisation Protocol (SynchML) provides interoperability: SynchML Client remains unchanged; SynchML server implementations of a given spec are different

Exchanging Service Centres

To assess that a Service Centre S_1 offering a service can hand over the service operations dynamically to Service Centre S_2 offering the same service.

GST should have the capability to provide interoperable synchronisation protocols (part of an open and standardized infrastructure)

Ease of market access → avoid unduly high barriers of market entry

Roaming between telecom operators

To assess that a service can be operational independent from the telecom operator.

GST should have the capability to allow standarized service consumption in an open infrastructure, wether roaming between telecom operators is required or not.

GST Validation Plan

22/03/2006 49 Version 3.0

IP-VAL-10 TC-Munich-007 TC-AC/R-0005 TC-Paris-0012

IP-VAL-11 TC-Gothenburg-0007TC-Gothenburg-0009

IP-VAL-12 TC-Torino-0014

IP-VAL-13

Acces to in-vehicle devices

Collaborating Service Applications

Can I have my Service Application to use information from other Service Applications of other Service Providers?

Do I have access to in-vehicle devices needed for the operations of my service?

Can I have the End-User to pay for the usage of my service?

To assess that a Service Application can acces in-vehicle devices and abstract data from them.

GST should have capability to grant a Service Application acces to in-vehicle devices in a standardised way.

GST should have capability to have the End-User to pay for the usage of services in a standardized way

Service Payment To assess that a Service Provider can have the End-User to pay for the usage of his service

State dependent actuation of services

To assess the operations of a resident service, i.e. a service for which the Service Applications monitors the state of the vehicle and becomes fully operational autonomously once it receives

GST should enable the state dependent actuation of services

Can I offer resident services, which should be activated on the right moment only?

To assess the collaboration between Service Applications (even from different Service Providers) running on the same Client System

GST should enable collaboration between Service Application, and thereby support the dynamic construction of even more user friendly services

GST Validation Plan

22/03/2006 50 Version 3.0

ID Underlying question Name Objective Motivation München Aachen-Rüsselheim Stuttgart Paris UK Goteburg TorinoIP-VAL-14 TC-Munich-009 TC-Paris-0011

IP-VAL-15 TC-Munich-017TC-Munich-018

TC-XSITE-004TC-AC/R-0006 --> TC-XSITE-004

IP-VAL-16

TC-Munich-009 TC-AC/R-0004

TC-Gothenburg-0006

GST should have the capability to discover an operational Safety Channel Service and then activate the Safety Channel Service Application

Activation of a discovered Safety Channel Service

To asses that a Client System dynamically activates the Safety Channel Service Application as subscribed for, once it discovers a Safety Channel Service

Reception of safety related messages

Reception of standardized safety channel messages over different bearers (DVB-T,DAB,...), flexible use of a Safety Channel infrastructure

Services that are expected to be brought to the market in a few years → Safety Channel

Broadcast of safety related messages

Broadcast of standardized safety channel messages over different bearers (DVB-T,DAB,...), flexible use of a Safety Channel infrastructure

Can an activated Safety Channel Application receive the broadcasted , safety related messages?

Can a Client System activate the Safety Channel Application once its discovers the service (and vice versa)?

A GST Client System should enable the Safety Channel Application to receive standardized safety messages over different bearers and flexible and standaridzed deployment of new

GST should have the capability to transmitt standardized safety messages over different bearers and flexible and standaridzed deployment of new

Can I broadcast safety related messages?

GST Validation Plan

22/03/2006 51 Version 3.0

ID Underlying question Name Objective Motivation München Aachen-Rüsselheim Stuttgart Paris UK Goteburg TorinoIP-VAL-17 TC-Munich-008

IP-VAL-18

TC-Munich-015 TC-AC/R-0003 TC-UK-0001 TC-Torino-0017TC-Munich-012 TC-UK-0002 TC-Torino-0018

TC-UK-0003TC-UK-0006

IP-VAL-19 TC-Munich-016

Services that are expected to be brought to the market in a few years → Emergency Call

GST should have the capability to operate e-Assists services

E-Call service selection, activation and operation.

To assess thtat s is possble to select and activate an eCall application on a Client System anywhere in Europe

GST should have the capability to enable emergency calls services throughout Europe in a standardized way

GST should have the capability to allow standarized service consumption in an open infrastructure (e.g. emergency calls). An ecall must be possible, whether roaming is required or not, and must deliver an eCall in time at the nearest PSAP1 regarding the current location.

eCall to PSAP1 directly To asses that an emergency call is conducted in a standardized way using different telecommunication operators and different PSAP1s and with a pre-defined processing time

e-Assist service selection, activation and operation.

To assess the activation of an e-Assist Servcie Application in a vehicle, as an extended and individualised e-Call Service . A set of data (MSD + x) is communicated to a Service Provider, enhanced with additional data and sent to the nearest PSAP1

Can I select and activate an e-call service throughout the whole of Europe ?Can I send an e-call throughout the whole of Europe ?

Can I enrich the e-call service with an additonal individual assist?

ID Underlying question Name Objective Motivation München Aachen-Rüsselheim Stuttgart Paris UK Goteburg TorinoIP-VAL-20

TC-AC/R-0002 TC-Paris-0003

TC-Gothenburg-0009 TC-Torino-0001

TC-Torino-0002TC-Torino-0003TC-Torino-0004TC-Torino-0005TC-Torino-0006TC-Torino-0007

Services that are expected to be brought to the market in a few years → Enhanced Floating Car Data

Can I request a vehicle to send me specific floating car data basewd on data from in-vehicle sensors and on moments / locations where I need it?

EFCD-generation To assess the generation of floating car data using data from in-vehicle sensors and the sending of this data with predefined strategy to a EFCD Service Centre.

GST should have the capability to generate floating car data using data from in-vehicle sensors and to ask the Client System to send this data to the EFCD Sevcie Centre according to a dynamic strategy

Table 11 Overview of IP-Level validation questions and related Test Site Test Cases.

GST Validation Plan

22/03/2006 52 Version 3.0

Chapter 8 - QUESTIONNAIRES

The assessment of non-technical issues is done by means of questionnaires. There are two different questionnaires:

1. For people that are not familiar with GST

This questionnaire is for visitors to test sites, visitors to the GST internet site and visitors to the ITS World 2006, that do not have in-depth knowledge of GST. It is the responsibility of the Test Site managers to distribute this questionnaire amongst the visitors of the Test Sites and to report the results to the validation managers (i.e. WP6 managers).

2. For people that are familiar with GST (in-depth questionnaire)

This questionnaire will be distributed amongst GST partners and answers more in-depth non-technical questions.

It has been decided that the non-familiar questionnaire will be distributed amongst GST partners too, so partners need to fill in both questionnaires.

A web version of both questionnaires can be found at

• Non-familiar questionnaire: www.gstproject.org/questionnaire

• Familiar questionnaire: www.gstproject.org/familiar_questionnaire

The results of both questionnaires and with it the non-technical assessment will be reported in IP-Level deliverable DEL-GST-6.2.

The questionnaires can be found in

GST Validation Plan

GST Familiar Questionnaire v2.0 Page 53 of 93

Appendix Section

GST Validation Plan


LITERATURE LIST

[1] P. Kompfner et al., Guidebook for Assessment of Transport Telematics Applications: Updated Version, Framework IV Transport Telematics Project CONVERGE (TR1101), Deliverable 2.3.1, 1998

[2] D. Valtchev et al., Operational Concept Description (OCD), Framework VI Project GST, Deliverable WP2, 2004

[3] D. Valtchev et al., Use Cases and System Requirements , Framework VI Project GST, Deliverable WP2, 2004

[4] P. Gustafson, Architecture and Interface specifications, Framework VI Project GST, Deliverable DEL_GST-3_2, WP3, 2005

GST Validation Plan


TERMS AND ABBREVIATIONS

Terms

Assessment Objective Criteria which may be defined at different levels for making judgements

Indicator Parameters, directly measured or derived from measurements or modelling, indicating the performance or impacts of a candidate system

Test Case The test to be carried out to measure if the assessment objective is realised

Test Site The location the Test Case is carried out

Verification Verification is the process to check if the the system is build right

Validation Validation is the process to check if the right system is build

Abbreviations

AO Assessment Objective

CAG Core Architecture Group

CT Core Team

EC European Commission

EFCD Enhanced Floating Car data

GA General Assembly

GST Global System for Telematics

IN Indicator

IP Integrated Project

IPWP6MT Integrated Project Work Package 6 Managers Team

RSQ Rescue

SP Sub Project

TS Test Site

GST Validation Plan


NON-FAMILIAR QUESTIONNAIRE

Global System for Telematics Questionnaire Non-familiar Version 2.0

Thank you very much for your interest and for participating in this survey.

If possible, please use the electronic version, which can be found at the following Internet address:

http://www.gstproject.org/questionnaire

If you do not use the online version, please return your completed printed version by post to:

TNO Science and Industry Attn. Allard Zoutendijk

P.O. Box 155 2600 AD DELFT

THE NETHERLANDS

About the survey

The purpose of the survey is to assess user appreciation and acceptance of the GST concept and the type of GST services that may be offered. The results of this survey will be used to assess the validity of the GST concept and to identify possible improvements.

Survey conditions: • Your participation is entirely voluntary. • We guarantee full anonymity and compliance with international ethical standards. • The questionnaire has been designed to be easily completed. The pilot survey showed

that it takes approximately 15 minutes to complete the questionnaire. We would like to thank you very much for taking the time to complete this survey. Any enquires regarding this questionnaire should be sent by e-mail to: [email protected]

The structure of the questionnaire is as follows. After a short introduction you will find the following groups of questions.

1. About GST

- GST Services These questions are about possible GST services and how you value them. Understanding the services may help you to understand the GST concept, and will make it easier for you to answer the more specific questions relating to the GST concept.

- GST Features Questions about the features of GST.

- GST Payment methods Questions about different methods of payment for services.

- GST Acceptance Various questions concerning the acceptance of GST and conditions.

GST Validation Plan


2. About you

We would like to ask you some questions that are important for statistical and demographic analysis relating to this survey.

The total number of questions is 53.

GST Validation Plan


Introducing GST

The automotive and telematics industry is seeking to enhance your automotive experience in terms of safety, security, efficiency and comfort by making vehicles permanently online and by allowing in-vehicle systems to run a variety of services. The Global System for Telematics (GST) is a framework that enables vehicles to communicate with a service centre and with each other. GST can even provide the same services on your mobile phone, PDA and other nomadic devices.

Imagine that you are able to choose from a wide range of services in your car, for example: services that warn you about problems further ahead, services that send a message to rescue services in an emergency, services that help you to find a parking space or the nearest Indian restaurant and allow you to make a reservation – and even guide you to your destination after leaving your car. You can also select and programme your personal package of services at home, via a website, so that the configuration is loaded and you are ready to go as soon as you get into the car and activate your GST system.

You have freedom of choice and you can be sure that the services you subscribe to are always up-to-date, because GST allows online updates and upgrades. Furthermore, brand new services will be introduced, due to the fact that GST accesses and communicates information that was previously unavailable.

When you buy a GST-compatible car, an initial package of services may be offered. It will be possible to subscribe to an almost unlimited range of additional services during the lifetime of the vehicle, without the need for additional hardware. You can programme your service pack to meet your own needs, at any time.

GST Validation Plan


1. About GST GST Services GST allows you to choose from different classes of service, for example:

• Safety services (e.g. hazard warning, emergency call, stolen vehicle alert and tracking, etc.)

• Mobility services (e.g. enhanced navigation, find parking space, etc.) • Comfort services (e.g. infotainment, travel tips, restaurant reservation, etc.)

1.1 How would you value Safety Services?

High value Medium value Low value

1.2 How would you value Mobility Services?


1.3 How would you value Comfort Services?


1.4 What would be your order of priority?

Safety, Mobility, Comfort Safety, Comfort, Mobility Mobility, Safety, Comfort Mobility, Comfort, Safety Comfort, Mobility, Safety Comfort, Safety, Mobility

Imagine that your car is fitted with a system that allows you to reserve a guaranteed parking space before you arrive, and pay only for the time you actually use it. 1.5 Would you consider subscribing to such a service?

Yes, definitely Probably Perhaps Probably not Definitely not

Imagine that your car is fitted with a system that warns you when an emergency vehicle is approaching, so that you are able to react in good time.

GST Validation Plan


1.6 Would you appreciate such a system?


Imagine there is a system inside your car that allows you to view trailers of the films showing at your favourite cinema. The system enables you to buy tickets straightaway from your car, and the payment is debited from your bank account once you have approved the transaction. The tickets are downloaded to the car, and from there to your PDA via Bluetooth.

1.7 Would you consider using such a service?


1.8 Do you think it likely that such services will actually become reality?


GST Validation Plan


1.9 Which of the following services do you feel are most useful for your own situation?

How useful? Very Reasonably Not really Not at all Don’t know

Navigation Travel and traffic information Information on nearest hotels, petrol stations, supermarkets, etc.; information such as available rooms, pricing, booking …

Emergency call Warning of approaching emergency vehicles

Local hazard warning (i.e. black ice)

Public hazard warning (i.e. fog or ‘ghost drivers’)

Roadside assistance Remote vehicle diagnostics Parking availability, reservation and payment

Other, namely ______________________ ______________________

1.10 Would you be willing to pay for these services (e.g. amount per year)?

Service No Yes [Euros per year]

Navigation Travel and traffic information Dynamic access and booking for nearest hotels, golf, ferries, petrol stations, etc.

Emergency call Warning of approaching emergency vehicles Local hazard warning (i.e. black ice) Public hazard warning (i.e. fog or ‘ghost drivers’)

Roadside assistance Remote vehicle diagnostics Parking reservation and payment Other, namely ______________________ ______________________

1.11 Do you think that GST technology will be deployed by OEMs or after-market players?

OEM (i.e. car manufacturers) After-market players Others, namely ___

1.12 What will be the main market for GST technology?

GST Validation Plan


Automotive market Freight and fleet market Consumer market Telecom market Other, namely ___

1.13 How large would you expect this market to be in 5 to 10 years’ time? 2010 2015 What percentage of vehicles in this market will be equipped with telematics devices in Europe?

0 – 5%

5 – 10%

10 – 15%

15 – 20%

> 20%

0 – 10%

10 – 20%

20 – 30%

30 – 50%

> 50%

On average, how many services will people subscribe to in Europe?

1 2 - 3 4 -5 5 -10

> 10 1 2 – 3

4 – 5

5 – 10

> 10

1.14 How do you envisage your future GST telematics system?

Integrated and built into my car Based on a mobile nomadic device A combination of integrated and mobile elements Don’t know Other, namely ___________

GST Validation Plan


GST Features GST implements different features. We would like to know whether you would find these features useful. With GST, the same service will be offered by different providers. You can subscribe as you like to any service available. 1.15 Is it important for you to be able to choose between different service providers?

Yes, very important Probably Perhaps Probably not Definitely not Don’t know

With GST it is possible to subscribe to in-car services and to personalize your package of services from your car, at any time and wherever you are. 1.16 Would you appreciate the fact that you can personalize your service package from your car?

Yes, very much Probably Perhaps Probably not Definitely not Don’t know

With GST it is possible is to configure and personalize your package of services at home. 1.17 Would you like to be able to tune and configure your services at home?


With GST, your system is always up-to-date. Updates are automatic. 1.18 Would you find it useful to have remote, automatic updates?


GST Validation Plan


With GST it is easy to obtain service upgrades. This can also be done remotely. 1.19 Would you find remote upgrades useful?

Yes, very much Probably Perhaps Probably not Absolutely not Don’t know

With GST it is possible to have the same service in your car and on your nomadic devices (e.g. mobile phone, PDA). This would enable you to have door-to-door navigation, for example. 1.20 Would you like to have continuity between the services in your car and the services on your nomadic device?

Yes, very much Probably Maybe Probably not Absolutely not Don’t know

1.21 When you buy a car, which features are important to you? Please indicate your ‘Top 3’ features in the right-hand column (1 = most important)

Importance high medium low priority

Make of car Size of car Price Look Colour Engine, performance Safety features Total cost of ownership Mobility features (e.g. navigation system)

Comfort features (e.g. DVD player, airco)

Telematics services (e.g. location-based info)

1.22 If you could spend EUR 1,000 (GBP 694) on accessories for your new car, which ones would you prefer?

Telematics services (i.e. the services developed within the GST project) Safety (airbags, etc.) Comfort (cruise control) Design (metallic paint, spoilers, alloy wheels) Interior accessories (leather seats, radio) None of these. I would spend my EUR 1,000 on another engine None of these. I would spend my EUR 1,000 on another (bigger) car

GST Validation Plan


GST Payment Methods

We would like to know your opinion of the system described in the questions below. For each of the 8 situations, please indicate whether you would choose option 1 or option 2, if the conditions actually existed. Each situation is described in terms of payment methods for equipment and services, and the number of services available.

1.23 Option 1 Option 2 Equipment price included in vehicle price Equipment price included in vehicle price Pre-pay Pay per use All services offered Limited number of services

I prefer: Option 1 Option 2 Neither

1.24 Option 1 Option 2 Equipment price included in vehicle price Equipment price included in vehicle price Pay-per-use at end of month Pay standard charge Limited number of services All services offered


1.25 Option 1 Option 2 Equipment price is not included Equipment price is not included Pre-pay Pay per use Limited number of services All services offered


1.26 Option 1 Option 2 Equipment price is not included Equipment price is not included Pay-per-use at end of month Pay flat rate All services offered Limited number of services


1.27 Option 1 Option 2 Equipment bought in after-sales market Equipment bought in after-sales market Pre-pay Pay per use All services offered Limited number of services


1.28 Option 1 Option 2 Equipment bought in after-sales market Equipment bought in after-sales market Pay-per-use at end of month Pay flat rate Limited number of services All services offered


GST Validation Plan


1.29 Option 1 Option 2 Discount for after-sales equipment Discount for after-sales equipment Pre-pay per use Pay per use Limited number of services All services offered


1.30 Option 1 Option 2 Discount for after-sales equipment Discount for after-sales equipment Pay-per-use at end of month Pay flat rate All services offered Limited number of services


GST Validation Plan


GST Acceptance

Congestion could be avoided and the traffic flow improved if traffic managers could use cars as sensors. This means that your car would be equipped with floating car data algorithms, and transmit information anonymously to the managers about e.g. position, direction and speed. This is called Floating Car Data (FCD). Would you object to this? 1.31 Would you object if your car transmits data on position, speed and heading (FCD)

anonymously (e.g. to a traffic manager)?

Yes Perhaps No Don’t know

If you received rebates or free service enhancements (e.g. extra traffic information) in exchange for anonymous FCD, would this change your opinion? 1.32 Would you object to anonymous FCD transmission if you were given something in

return?

Yes Perhaps No Don’t know

It may be in the public interest that anonymous services such as FCD are made mandatory by the authorities. Do you think this is acceptable? 1.33 Do you think that anonymous mandatory services are acceptable when it is in the

public interest?

Yes, entirely acceptable Perhaps, under certain conditions (enter conditions under 1.29) No, totally unacceptable Don’t know

1.34 Under what conditions would mandatory anonymous services be acceptable to you? You may tick more than one box.

If anonymity is fully guaranteed (e.g. data is sent only to authorized and controlled bodies). If public safety is addressed (e.g. terrorist threats) If I am allowed to opt out Other, namely _______________

It may be in the public interest that services that also transmit private data (e.g. registration number, owner of car, colour of car, make of car, etc.) are made mandatory by the authorities. This could, for example, help rescue vehicles to find you in the event of an accident, or help to track witnesses. Do you think this is acceptable? 1.35 Do you think that it is acceptable for mandatory services to transmit private data when

it is in the public interest?

Yes, entirely acceptable Perhaps, under certain conditions (enter conditions under 1.31) No, totally unacceptable Don’t know

GST Validation Plan


1.36 Under what conditions would mandatory services that also communicate private data be acceptable to you? You may tick more than one box.

If used for emergency services only If it is guaranteed that records will be deleted (e.g. after 7 days) If it is guaranteed that records will be anonymous, i.e. personal details removed (e.g. after 24

hours) If public safety is addressed (e.g. terrorist threats) If I am allowed to opt out Other, namely _______________

GST Validation Plan


2. About you We would like to ask you some questions that are important for statistical and demographic analysis relating to this survey. 2.1 Where did you receive this questionnaire?

Test Site Munich Test Site Aachen/Russelsheim Test Site Stuttgart Test Site Paris Test Site London Test Site Gothenburg Test Site Torino

ITS World E-mail GST Forum site Other, namely

________________

2.2 Are you familiar with the GST project?

Fully (100%) Largely (75%) Fairly (50%) Hardly (25%) Not at all (0%)

2.3 Do you possess a car?

Yes, I have a car No, I don’t have a car, but I regularly drive a car No, I don’t have a car and I seldom drive one

2.4 In which year were you born?

19______ 2.5 Gender

Male Female

2.6 Where do you live?

Austria Belgium Cyprus Czech Republic Denmark Estonia Finland France Germany

Greece Hungary Ireland Italy Latvia Lithuania Luxembourg Malta Poland

Portugal Slovakia Slovenia Spain Sweden The Netherlands United Kingdom Other, namely _______

2.7 By what means do you travel the greatest distance every day?

As a car driver As a car passenger Motorcycle Bus Train

GST Validation Plan


Tram Underground/Metro On foot Scooter Bike Other, namely ___

2.8 What level of education do you have?

Primary education Lower vocational education, lower general secondary education, advanced elementary

education Intermediate vocational education, higher general secondary education, high school,

intermediate business education Higher vocational education, university

2.9 What is your profession?

__________________________________

2.10 How many adults are there in your household?

1 2 3 4 or more

2.11 How many children are there in your household?

0 1 2 3 or more

2.12 How many cars do you have in your household?

None 1 2 3 or more

2.13 What type(s) of car do you possess in your household?

Alfa Romeo Audi BMW Chevrolet Chrysler Citroen Daewoo Daihatsu Fiat Ford Honda Hyundai Jaguar

Jeep Kia Lancia Land Rover Lexus Mazda Mercedes-Benz MG Mini Mitsubishi Nissan Opel Peugeot

Renault Saab Seat Skoda Smart Subaru Suzuki Toyota Vauxhall Volkswagen Volvo Other, namely ___

GST Validation Plan


2.14 How often do you use your car?

Never Seldom Regularly Every day Don’t have a car

2.15 How many kilometres per year do you drive in your most frequently used car?

Less than 5,000 5,000 – 10,000 10,000 – 15,000 15,000 – 20,000 20,000 – 25,000 25,000 or more

2.16 Is your most frequently used car a private car or a company car?

Private car Company car

2.17 Do you have any comments regarding GST or this questionnaire?

Thank you for your co-operation! If you did not use the online version, please return your printed questionnaire by post to:

TNO Science and Industry Attn. Allard Zoutendijk / GST Questionnaire


THE NETHERLANDS

GST Validation Plan


FAMILIAR QUESTIONNAIRE

Global System for Telematics Questionnaire (familiar) Familiar Version 2.0

Thank you very much for your interest and, in advance, for your participation in this survey.

If possible, please use the electronic version, which can be found at the following Internet address:

http://www.gstproject.org/familiar_questionnaire

If you do not use the online version, please return your completed printed version by post to:

TNO Science and Industry Attn. Allard Zoutendijk


THE NETHERLANDS

Introduction

Now that the GST Sub-Projects have delivered their products and the Test Sites have implemented integrated GST prototypes, GST has reached a level of maturity that allows for a review of the concept based on actual experience.

This survey is distributed among GST partners and people that are familiar with GST (e.g. the GST Service Contest contestants), in other words people that can answer more in-depth questions about the GST concepts and results.

About the survey

The purpose of the survey is to assess the support for the use of the GST framework and implementations based on GST concepts and to get feedback on the Sub-Project products (i.e. specifications and reference implementations).

The results of this survey will be used to assess the validity of the GST concept and will be used to identify possible improvements.

Survey conditions

• Your participation is entirely voluntary. • We guarantee full anonymity and compliance with ethical standards. • The questionnaire has been designed to be easily completed. The pilot survey showed

that it takes approximately 25 minutes to complete the questionnaire. • The results will be made available in Subversion and can be send by e-mail upon request

GST Validation Plan


We would like to thank you very much for taking the time to complete this survey. Any enquires regarding this questionnaire should be sent by e-mail to: [email protected]

GST Validation Plan


Structure of survey

The structure of the questionnaire is as follows:

1. About you (13 questions)

We would like to ask you some questions that are important for the statistical and demographic analysis realting to this survey.

2. Generic GST questions (25 questions)

GST aims to support various features of which we would like to know how important they are for you and your business and to which extent GST contributes to enable these features

3. SP specific GST questions (58 questions)

Each Sub-Project has SP specific non-technical questions; the answers may help the SP’s to assess their products and to find future improvements. You are encouraged to answer all SP specific questions and not to restrict yourself to the SP’s in which you were involved.

You are kindly requested to fully complete section 1 and 2 as a minimum, and as much of section 3 as possible.

GST Validation Plan


1. About You

We would like to ask you some questions that are important for the statistical and demographic analysis relating to this survey. 1.1 Where did you receive this questionnaire

Test Site Munich Test Site Aachen/Russelsheim Test Site Stuttgart Test Site Paris Test Site London Test Site Gothenburg Test Site Torino

ITS World E-mail GST-Forum site Other, namely

________________

1.2 In which year were you born?

19______ 1.3 What is your gender?

Male Female

1.4 Where do you live?

Austria Belgium Cyprus Czech Republic Denmark Estonia Finland France Germany

Greece Hungary Ireland Italy Latvia Lithuania Luxembourg Malta Poland

Portugal Slovakia Slovenia Spain Sweden The Netherlands United Kingdom Other, namely _______

1.5 What level of education do you have?

Primary education Lower vocational education, lower general secondary education, advanced elementary

education Intermediate vocational education, higher general secondary education, high school,

intermediate business education Higher vocational education, university

1.6 How would you categorise your company?

Content Provider Content Aggregator Service Provider Service Aggregator Middleware Provider Control Centre Operator Network Access Provider Automotive Supplier

GST Validation Plan


Car maker Consumer Government Other

1.7 How would you classify your position at your company?

General Management Marketing & sales Technical Management Technical/Development Other, namely _______________

1.8 Are you familiar with the GST project?

Fully (100%) Largely (75%) Fairly (50%) Hardly (25%) Not at all (0%)

1.9 In what part of GST have you been involved? Tick all applicable

SP Open Systems SP Security SP Service Payment SP CERTECS SP Rescue SP Safety Channel SP EFCD

TS Munich TS Aachen/Russelsheim TS Stuttgart TS Paris TS London TS Gothenburg TS Torino

CAG IP/SP/WP Management Service Contest Other, namely

___________________

1.10 By what means do you travel the greatest distance every day?

As a car driver As a car passenger Motorcycle Bus Train Tram Underground/Metro On foot Scooter Bike Other, namely ___

1.11 How many adults are there in your household?

1 2 3 or more

1.12 How many children are there in your household?

0 1

GST Validation Plan


2 3 or more

1.13 How many cars do you have in your household?

None 1 2 3 or more

GST Validation Plan


2. Generic GST Questions

GST aims to support various features of which we would like to know how important you rate them and to which extent GST contributes to enable these features. Below you find a table that lists 26 primary features of systems using GST. For each feature, we would like you to answer two questions: A. To what extent do you think it is critical in the car-telematics market; how do you rate

the importance? The Criticality rating will be done with these these levels of rating: L = Low importance M = Medium importance C = Critical importance X = Cannot judge this feature

B. What is, to your best knowledge, the contribution of the GST project to enable this

feature? The GST contribution for this feature is rated as follows: 1 = Very small contribution 2 = Small contribution 3 = Medium contribution 4 = High contribution 5 = Very high contribution X = I do not know

GST Validation Plan


# Feature Criticality

rating (L, M or C)

GST contribution

(1-5) Room for comments

1

Extensible catalogue of services The GST Architecture intends to ease the development and deployment of services. This should result in a large amount of services being offered to the consumer.

2 Personal configuration of services The GST Architecture allows for personal customising of the services to which a consumer is subscribed.

3

Easy subscription to new services with instant gratification With new services easily being offered through the Control Centre, which is handling all the administration, it should be very easy for the consumer to subscribe to a new service. This could be done with instant gratification, so no waiting. This allows the users to personally configure their stack of services.

4

Remote control of terminal and services by control centre (zero local administration) With all the administration being handled by the Control Centre, there is no need for local administration. This also enables remote control at the Control Centre of the services in the personal profile and maybe even remote control of the terminal.

5

Lifetime upgradeability The conflict between the lifetime of the vehicle (plm. 10 years) and the lifetime of telematics equipment (2-3 years) should be solved for the consumer. Providing upgrades during the lifetime of the vehicle could be one solution for this conflict.

6

Exploit changes in pricing A distributed pricing policy could be implemented, which would allow for personalised pricing. This means that the user can interchange various things like thickness of the client and provided bandwidth, to establish his economically most viable combination.

GST Validation Plan



rating (L, M or C)

GST contribution


7

Increase number of service providers on the market With all the consumer handling being done at the Control Centre, a service provider can stick to his core business, and just provide the service. This will also exempt him from all associated operational issues (e.g. execution of service, administration, billing).

8

Experiencing services on a trial basis New services can be easily offered through the Control Centre, so this provides a nice marketing opportunity to attract the consumer with a free, short trial period to experience the telematics service.

9

Personal service profiles The Control Centre should keep a profile (or configuration files), so the consumer should be able to access his services from anywhere. This included other vehicles, like rental vehicles.

10

Ability to switch to different supermarkets / control centres The GST Architecture should make switching between various Control Centres (or supermarkets for telematics services) possible. This should enable competition at the level of price and quality of services.

11

Accommodate services from different companies at one terminal The terminal inside the vehicle interfaces with the Control Centre and can accommodate all services that are provisioned via the Control Centre. The services offered can be provided by different Service Providers and Service Centres.

12

Possibility to deploy services on a wide range of terminals Services (client applications) that are provided by the Service Provider via the Control Centres could be generic (Write Once, Run Anywhere philosophy).

13 Services submitted to different control centres/supermarkets The Service Provider is able to deliver his service to the Control Centres of his choosing.

GST Validation Plan



rating (L, M or C)

GST contribution


14

Possibility of reducing the time to market With part of the whole value chain already in place and fully operational, a service that has been developed will be introduced in the market in a much faster way with GST.

15

Use commonality in terminals for different vehicle configurations With the commonality of terminals or common elements of terminals, it should be possible to have common parts of the terminal used in various models of the same vehicle brand.

16 Reducing the operational costs associated with control centres By sharing the infrastructure between different vehicle brands, the net overall operational costs should be reduced (economy of scales).

17

Manage, change and perform version management over the air In order to use telematics services, the car will by default be equipped with a mobile communication system. This enables ‘maintenance’ of the services and equipment, like management and configuration control, to be executed ‘over the air’.

18

Development costs associated to new service offerings With all infrastructure for the telematics services already in place, the costs of developing the service will be limited to the development of the service itself only. Making the service GST compatible might enlarge the development cost for the service itself, but the costs for all the additional infrastructure development is non-existent, which brings the total costs down.

19

Reduction of total cost of ownership of in-vehicle terminals Although the development of a GST compatible terminal might be higher than for a dedicated terminal, the multiple use of that terminal brings the total cost of ownership down.

GST Validation Plan



rating (L, M or C)

GST contribution


20

Reduction of development costs Approaching costs on a more generic level. The development of the service itself might be slightly higher, but the distribution over various Control Centres and therefore various in-vehicle platforms brings the total development costs down.

21 Reduction of operational costs With participants in the value chain sharing a lot of operational resources, this brings the total of operational costs down.

22 Multi-channel service delivery The ability to access the same service from different terminal.

23

Potential for Customer Relationship Management The GST Architecture will allow for the capability to have the subscriber’s preference known to the Control Centre and Service Provider. This will enable personalised CRM.

24

Software download functionality The functionality to download the software from a remote location does enable to use this function not only for service subscription, but also for upgrading vehicle systems.

25 Profile variants and possibility for packaging services Use of a standard profile for specific categories of users (e.g. freak, pop, classic categories)

GST Validation Plan

3. SP Specific Questions

The following questions address different subjects within different subprojects in GST. These questions are presented in the following order: Open Systems, Security, Service Payment, CERTECS, Rescue, Enhanced Floating Car Data, and Safety Channel. Please rate the following statements by circling the appropriate number or giving the figures as requested. If an alternative rating system is used this is mentioned explicitly, in all other cases use rating system below.

1 2 3 4 5 X Strongly Disagree Disagree Neutral Agree Strongly

Agree Don’t know

Open Systems GST Open Systems is responsible for the fundamental GST framework interfaces and reference implementations to enable:

• Service deployment, provisioning and updating • Connection management • Retrieval of data of vehicle sensors • Retrieval of positioning data

Open Systems general 1. The Open Systems Architecture and Interface Specification is

clear, consistent and fulfils important needs of GST telematics system developers

1 2 3 4 5 X

2. The framework offered by GST Open Systems is a major step forward with respect to co-operative vehicle-infrastructure and vehicle-vehicle applications

1 2 3 4 5 X

Reference implementations added value 3. The Open Systems reference implementations are a good

starting point to help understand how to develop GST Service Centers.

1 2 3 4 5 X

4. The Open Systems reference implementations are a good starting point to help understand how to develop GST Control Centers.

1 2 3 4 5 X

5. The Open Systems reference implementations are a good starting point to help understand how to develop GST in-vehicle Client Systems

1 2 3 4 5 X

6. The functionality offered by the Open System reference implementations is correct

1 2 3 4 5 X

Security The GST Security sub-project addresses the following problems related to future security and trust infrastructures for ITS:

GST Validation Plan


• Security: The customer can expect that systems are resilient to attack, and that the confidentiality, integrity and availability of the system and its data are protected during data transmission and if stored persistently.

• Privacy: The customer and the vehicle are able to control data about themselves, and those using such data adhere to fair information principles.

• Reliability: The customer can depend on the product to fulfil its functions when required to do so.

User acceptance assessment (user’ opinion, preferences) 7. User privacy is a strong requirement in an telematics system 1 2 3 4 5 X 8. The User (e.g. vehicle driver) of a telematics system is not

willing to be administrator of the telematics security management (e.g. generating of security keys, …)

1 2 3 4 5 X

9. User authentication is needed for various issues, but the user should not handle more than one user account information for the various services

1 2 3 4 5 X

Regulated services (political, strategic) 10. There should be an OEM neutral Public Key Infrastructure for

telematics systems 1 2 3 4 5 X

11. The OEMs are responsible to build up the Public Key Infrastructure

1 2 3 4 5 X

Impact assessment (safety, environment, transport efficiency, user behaviour) 12. Authentication Tokens, used outside of the telematics world

(e.g., GSM SIM Authentication, Portal User account, Vehicle Key, …), should also be usable in the telematics system

1 2 3 4 5 X

13. The Security Management of the telematics system has to be worked autonomous (no or less interaction needed with the user)

1 2 3 4 5 X

Overall Security

Application Security

Service Security

Devices Security

Interconnectivity

HeterogeneousNetworks

incl. Adhoc networks

Service Deployment

Platforms

Operating System

User Point of View

Technology Point of View

GST Validation Plan


14. The User Management (Identity Management) is in the area of responsibility of the OEMs

1 2 3 4 5 X

Cost & effectiveness 15. The User is not willing to pay for the security of the telematics

system 1 2 3 4 5 X

16. The User is not willing to pay regular costs, instead the user prefers single time costs

1 2 3 4 5 X

17. The additional effort (costs, complexity) for building up secure telematics systems is justified

1 2 3 4 5 X

Reference implementations added value 18. The Security reference implementations are a good starting

point for the development of GST Service Centers. 1 2 3 4 5 X

19. The Security reference implementations are a good starting point for the development of GST Control Centers.

1 2 3 4 5 X

20. The Security reference implementations are a good starting point for the development of GST in-vehicle Client Systems

1 2 3 4 5 X

21. The functionality offered by the Security reference implementations is complete and correct

1 2 3 4 5 X

22. The documentation offered by the Security reference implementations is complete and correct

1 2 3 4 5 X

23. The presence of Security reference implementations speeds up the development and thus decreases development cost

1 2 3 4 5 X

Service Payment GST S-PAY main feature is to recommend a proven and tested payment and billing architecture, based on an intensive review of all aspects of the European payment & billing situation, which meets current and future telematics service requirements and is transparent, flexible and accepted by the whole chain of actors involved in telematics. As an efficient, standardized payment & billing system is a pre-requisite for charging telematics services at acceptable costs and therefore represents the basis for European deployment.

Please rate the Service Payment statements 24 - 27 by circling the appropriate number as described below.

1 2 3 4 5 Absolutely not Probably not Maybe Probably Yes, absolutely

24. Which method of payment would you use in case of paying services by means of an in-vehicle terminal?

Pre-pay per use 1 2 3 4 5 Pay per use 1 2 3 4 5 Pay per use at end of month 1 2 3 4 5 Pay standard charge 1 2 3 4 5

Other, namely ___ 1 2 3 4 5 25. Which payment system would you use in case of paying services by means of an in-vehicle terminal? Chip card 1 2 3 4 5

GST Validation Plan


Mobile integrated contactless (NFC) chip card solution 1 2 3 4 5 Debit card 1 2 3 4 5 Mobile integrated contactless (NFC) debit card solution 1 2 3 4 5 Credit card system 1 2 3 4 5 Mobile integrated contactless (NFC) credit card solution 1 2 3 4 5 Pre-paid solution 1 2 3 4 5 Mobile device based prepaid solution 1 2 3 4 5 Subscriptions to service 1 2 3 4 5 Mobile payment solution for content payment 1 2 3 4 5 Other, namely ___ 1 2 3 4 5

26. Which currencies should be accepted when purchasing on-line services? Euro 1 2 3 4 5 UK Pound Sterling 1 2 3 4 5 US Dollars 1 2 3 4 5 Swedish Krona 1 2 3 4 5 Danish Krone 1 2 3 4 5

Other, namely ___ 1 2 3 4 5 27. Do you need to support more than one payment transaction at the same time?

Yes, more than 10 1 2 3 4 5 Yes, between 5 and 10 1 2 3 4 5 Yes, between 2 and 5 1 2 3 4 5

No 1 2 3 4 5 CERTECS The objective of CERTECS is to specify and simulate the operation of an economically viable certification organisation and associated supporting technical environment for automobile telematics. Such certification environment shall be used for Open Global System for telematics implementation as for their incremental evolutions. 28. What do you expect from certification in the telematics area?

28.1 Quality of the product/service improves in terms of Safety 1 2 3 4 5 XSecurity 1 2 3 4 5 XPrivacy 1 2 3 4 5 XConformity to standards or SLA/SLS 1 2 3 4 5 XInteroperabilty 1 2 3 4 5 XReliability 1 2 3 4 5 X

Development process 1 2 3 4 5 X28.2 Cost reduction in terms of

"Outsourcing" of conformity and interoperability testing 1 2 3 4 5 XUsing standards instead of developing proprietary solutions 1 2 3 4 5 XMore standardised components available 1 2 3 4 5 X

More vendors/ suppliers available 1 2 3 4 5 X28.3 Increase costs because of

Additional formalism/documentation in the context of certification 1 2 3 4 5 XExternal service for testing and certification 1 2 3 4 5 X

Surveillance activities to maintain certificate validity 1 2 3 4 5 X28.4 Time to market for new product will become (tick one box)

shorter ○ longer ○

28.5 Benefits because

GST Validation Plan


Confidence of customers in the product/service increases 1 2 3 4 5 XCompetition increases due to common standards 1 2 3 4 5 XMarket increase 1 2 3 4 5 X

Operational standardisation 1 2 3 4 5 X29. What are you willing to pay for the certification services? (tick one box)

5% of development costs ○ 10% of development costs ○

20% of development costs ○ 30. What additional time is acceptable for certification the product/service? (tick one box)

1 month ○ 2 months ○

3 months ○ 31. What kind of certification service is desirable? (tick one box)

Certification of the final product ○ Certification as part of the product/service realisation process (chance to correct/improve at an early stage)?

○

Rescue The focus of the Rescue sub-project is to accurately assess the type of emergency and resources required to provide the appropriate response to a critical incident. Rescue ensures that information about the incident will be available in the emergency vehicles and that they are able to quickly and safely reach the incident scene. To ensure this, the sub-project has completed the in-vehicle emergency call chain, provide guidance to the emergency service to the scene of the incident by accurate locations, trial blue corridors and coning systems (vehicle-to-vehicle communication) thus warning other road users of the approach of the emergency services. In addition, the emergency response can greatly benefit from an exchange of information between the rescue units and control rooms (police, hospitals etc.).

Please rate the following statements by circling the appropriate number 32. How many people, in percentage value, do not know the emergency number? (for example

the ambulance number in Italy is 118 but some people dial 113) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 33. How often, in percentage value, is the caller able to provide the right information?

Location and distinguishing marks ___% Outside scenario (river, wood, landing area, particular special) ___% Injured severity ___% Accident dynamic ___% Involved vehicles number ___% Caller telephone number ___% Other, namely___ ___%

34. In particular, which is the mean time to understand the right accident location?

Mean time: ___ minutes 35. What is the elapsed time between SOS and ambulance dispatching? (needed mean time for

the control centre operator to acquire the necessary information about the accident) Mean time: ___ minutes

GST Validation Plan


36. What is the necessary time to reach the accident? (no traffic included)

(write down the minimum and maximum value, distinguishing between urban and inter-urban area)

Minimum time Maximum time Urban area ___ minutes ___ minutes Inter-urban area ___ minutes ___ minutes

37. In your opinion, how much, in percentage value, could eCall reduce the complete emergency

rescue chain time? 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Please rate the following statements by circling the appropriate number (standard rating) or giving the figures as requested.

GST Validation Plan


38. Compared to the current situation, do you think that the number of false calls will be reduced

at PSAP1 due to eCall? Yes, as it is possible to check if an incident really has happened 1 2 3 4 5 XYes, but more people will use the possibility to report an incident to PSAP1

1 2 3 4 5 X

Yes, but PSAP1 will receive automatic eCalls and manual voice calls as people do not trust the system

1 2 3 4 5 X

No, there will still be people who are reporting incidents that have not happened

1 2 3 4 5 X

39. Today, how often, in percent value, can you fulfil the “Golden hour principle”?

(The golden hour is the time span from the moment of accident until the injured arrives in the hospital. Statistic data shows that the first hour is the major factor for the reduction of accident aftermath)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 40. Today, how often, in percent value, can you fulfil the “Golden hour principle”?

(The golden hour is the time span from the moment of accident until the injured arrives in the hospital. Statistic data shows that the first hour is the major factor for the reduction of accident aftermath)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Please rate the following statements by circling the appropriate number

1 2 3 4 5 Absolutely Not useful

Probably Not useful

Maybe Useful

Probably Useful

Yes, absolutely Useful

41. How useful you think the following services are in your own situation?

Blue wave 1 2 3 4 5Virtual cones 1 2 3 4 5

eCall 1 2 3 4 5 Enhanced Floating Car Data The goal of EFCD is, in a long-term perspective, to increase the number of floating car sensors and to collect safety relevant content. The objective can only be achieved through the generation of FCD-data with high quality at reduced cost. The necessary technological developments need to be part of an open EFCD system framework, where different service concepts can coexist and complement each other towards comprehensive coverage and penetration.

42. What services can be developed if the vehicle itself can be used as a floating car sensor? 43. Which (sensor) data are mandatory and optional to offer the services as listed above?

GST Validation Plan


Mandatory sensor data

Optional sensor data

Why is the mandatory data required?

Why is the optional data required?

44. To offer the services, how many vehicles (%) should provide Floating Car Data to get a minimum quality level of the service? 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 45. How can be guaranteed that the quality level of the provided Floating Car Data is meeting a certain quality level? 46. To offer the service, is it necessary that a message gets priority differentiation

Yes No If yes, which (sensor data) should get high/normal/low priority?

If no, why is it not necessary?

47. Is it necessary that parameters and/or algorithms can be updated remotely to run the service correctly?

Yes No If yes, why is it necessary?

If no, why is it not necessary?

48. Which type of services need the GST EFCD proposal to split person related data and vehicle related data to overcome the privacy issue? 49. Under which circumstances are you willing to share Floating Car Data with third parties?

GST Validation Plan


50. Under which circumstances a pay-back mechanism is necessary to attract people to provide necessary data to develop FCD services? 51. Are there any circumstances in which you think it is necessary to have the option available to activate or deactivate the provisioning of Floating Car Data? Safety Channel The Safety Channel sub-project of the GST Integrated Project aims to develop and validate a “Safety Channel” concept for the priority communication of dynamic information and warnings relevant to traffic, road and weather conditions. The Safety Channel will support the generation, management and delivery of safety related information to drivers such as variable speed limits, hazard warnings, weather alerts and dynamic traffic information that will lead to improved road safety and mobility.

52. For which kind of transport system would you prefer to get safety related information when travelling?

Car 1 2 3 4 5 XTrain 1 2 3 4 5 XBus 1 2 3 4 5 XMetro 1 2 3 4 5 XBike 1 2 3 4 5 X

Walk 1 2 3 4 5 X

53. How do you expect to receive safety related information? Radio 1 2 3 4 5 XCar navigation system 1 2 3 4 5 XPedestrian navigation system 1 2 3 4 5 XMobile phone 1 2 3 4 5 XInternet 1 2 3 4 5 X

E-mail 1 2 3 4 5 X

54. When would you expect to receive safety related messages? By planning 1 2 3 4 5 XOn travel 1 2 3 4 5 X

Instant on day time 1 2 3 4 5 X

55. In which situation/travel context would you like to get more and better safety related information?

GST Validation Plan


56. How urgent it is to receive the following safety related information messages? Weather around zero degree Celsius 1 2 3 4 5 XSmog access, only for odd number plates 1 2 3 4 5 XSide wind, cause danger on street 1 2 3 4 5 XFog, visibility reduced 1 2 3 4 5 XGas leak, potential inflammable air 1 2 3 4 5 XSubsidence, potential damage on road 1 2 3 4 5 XTraffic congestion, average speed XX km/h 1 2 3 4 5 XHighspeed ambulance overtaking 1 2 3 4 5 XTraffic jam, sudden end of queue 1 2 3 4 5 XTraffic jam, queue in tunnel 1 2 3 4 5 XAquaplanning, reduce speed 1 2 3 4 5 XPolice checkpoint 1 2 3 4 5 XPeople on roadway 1 2 3 4 5 XTime delay at ferry port 1 2 3 4 5 X

Park and ride service not operating 1 2 3 4 5 X

57. Which other messages are worth being included in a safety related information message?

3.58 Do you have any comments with regard to GST or this questionnaire?

Thank you for your co-operation ! If you did not use the online version, please return your printed questionnaire by post to:

TNO Science and Industry Attn. Allard Zoutendijk / GST Questionnaire


THE NETHERLANDS

GST Validation Plan


Documents

Global System for Telematics - EUROPA - TRIMIS