SP7 – SCORE – SAFESPOT Core Architecture Conformance & … · 2010-10-26 · SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 9 of 109 SCORE EXECUTIVE SUMMARY This deliverable

Deliverable N. 7.4.4 Dissemination Level PU Copyright SAFESPOT

Contract N. IST-4-026963-IP

SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 1 o f 109 SCORE

SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP

DELIVERABLE

SP7 – SCORE – SAFESPOT Core Architecture

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

D7.4.4

SubProject No. SP7 SubProject Title SCORE

Workpackage No. WP4 Workpackage Title Exploitation Convergence & Certification

Task No. T7.4.3 Task Title C2C & C2I Test System Assessment

Authors (per company, if more than one company provide it together)

Main Authors:

A. Plaza, F.J. Nuñez, J. Baños (AT4 wireless)

Status (F: final; D: draft; RD: revised draft): F

Version No: 1.1

File Name: SF_D7.4.4_C&I Test System Mock-up_v1.1

Planned Date of submission according to TA: 31/07/2008

Issue Date: 01/12/2009

Project start date and duration 01 February 2006, 48 Months

Conformance & Interoperability Test System Mock-up Ready




Revision Log

Version Date Reason Name and Company

0.1 2008-05-29 First Draft A. Plaza, F J. Nuñez, J. Baños (AT4 wireless)

0.2 2008-06-11 Introducing Test System A. Plaza, F J. Nuñez, J. Baños (AT4 wireless)

0.3 2008-06-16 Added TL entity and Annexes. Revised test system

A. Plaza, F J. Nuñez, J. Baños (AT4 wireless)

0.4 2008-06-17 Validation procedure A. Plaza, F J. Nuñez, J. Baños (AT4 wireless)

0.5 2008-06-23 Annexes A. Plaza, F J. Nuñez, J. Baños (AT4 wireless)

0.9 2008-08-07 Complete version A. Plaza, F J. Nuñez, J. Baños (AT4 wireless)

1.0 2008-10-09 Final Version after Peer Review


1.1 2009-12-01 EU reviewers from 3rd review meeting included





Abbreviation List

API Application Programming Interface

ATCRF Automobile Telematics Certification Reference Framework

AT Attention

ATC Abstract Test Case

ATL Authorized Test Laboratory

ATM Abstract Test Method

ATS Abstract Test Suite

C2C – CC Car to Car Communication Consortium

C2I Car to Infrastructure

CA Certification Authority

CEN Comité Européen de Normalisation

CVIS Co-operative Vehicle-Infrastructure Systems (IP project, IST 027 293)

DLNA Digital Living Network Alliance

DSRC Dedicated Short Range Communications

EC European Commission

EITSFA European Intelligent Transport Systems Framework Architecture

ETS Executable Test System

ETSI European Telecommunications Standards Institute

GUI Graphical User Interface

ICS Implementation Conformance Statement

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

ISO International Organization for Standardization

ITS Intelligent Transportation Systems

ITU International Telecommunication Union

IUT Implementation Under Test

MTC Main Test Component

OSI Open System Interconnection

PA Platform Adaptor

PTC Parallel Test Component

PICS Protocol Implementation Conformance Statement

PIXIT Protocol Implementation eXtra Information for Testing

RP Reference Point

RQ Requirement Catalogue

RSU Road Side Unit




SA System Adaptor

SCORE SAFESPOT CORE architecture

SINTECH SAFESPOT Innovative Technologies

SP Sub Project

SUT System Under Test

SUUT SAFESPOT Unit Under Test

T3RTS TTCN-3 RunTime System

TCI TTCN-3 Control Interface

TCP Transport Control Protocol

TCRL Test Case Reference List

TE TTCN-3 Executable

TL Test Logging

TP Test Purpose

TRI TTCN-3 RunTime Interface

TS Test Suite

TSI Test System Interface

TSS Test Suite Structure

TTCN-3 Testing and Test Control Notation

TTL Telematic Test Laboratory

UDP User Data Protocol

UML Unified Modelling Language

V2I Vehicle to Infrastructure

V2V Vehicle to Vehicle

VANET Vehicle Ad Hoc Network

WP Work Package




Table of contents Revision Log....................................... ......................................... 2 Abbreviation List .................................. ....................................... 3 Table of contents.................................. ....................................... 5 List of Figures .................................... ......................................... 7 List of Tables ..................................... .......................................... 8 EXECUTIVE SUMMARY............................................................... 9 1. Introduction ....................................... ................................... 10

1.1. Contribution to the SAFESPOT Objectives ...................................10 1.2. Methodology .................................................................................10 1.3. Deliverable Structure.....................................................................11

2. Beaconing SAFESPOT Test Specification.............. ............ 12 2.1. Introduction ...................................................................................12 2.2. Beaconing Functionality ................................................................13 2.3. Requirement Catalogue ................................................................14 2.4. PICS..............................................................................................14 2.5. Test Suite Structure and Test Purposes .......................................15 2.6. Abstract Test Suite........................................................................15

3. SAFESPOT Test System Mock-up....................... ................ 16 3.1. Introduction ...................................................................................16 3.2. Test Management .........................................................................17 3.3. SAFESPOT TTCN-3 Test Executable...........................................18

3.3.1. TTCN-3 Test Configuration............................................................... 19 3.3.2. SAFESPOT TTCN-3 Test Suite........................................................ 20 3.3.3. TTCN-3 Test Cases Parameter List.................................................. 20

3.4. SAFESPOT Test System Adaptor.................................................22 3.4.1. System Adaptor (SA)........................................................................ 22 3.4.2. Platform Adaptor (PA)....................................................................... 25 3.4.3. CODECS (CD).................................................................................. 26 3.4.4. LOGS ............................................................................................... 31 3.4.5. TTCN-3 Test System Development .................................................. 35

4. SAFESPOT Test System Validation .................... ................ 37 4.1. Introduction ...................................................................................37 4.2. Interface Requirements.................................................................38 4.3. Reference Implementations ..........................................................38

4.3.1. Description of the API....................................................................... 39 4.3.2. Using the dummy application............................................................ 41

4.4. Validation Procedure.....................................................................42 4.4.1. Starting test manager ....................................................................... 42 4.4.2. PICS filling by test operator .............................................................. 43 4.4.3. General parameters filling by test operator ....................................... 44 4.4.4. Test cases selection to be run .......................................................... 45 4.4.5. Test case execution.......................................................................... 46 4.4.6. Test results....................................................................................... 46

4.5. Beaconing Validation ....................................................................47 5. Conclusions........................................ .................................. 53 6. References......................................... ................................... 54 Appendix A – TTCN-3 Documentation Template ......... ............ 55




Appendix B – SAFESPOT Beaconing Test Specifications ..... 59 B.1 Beaconing Requirement Catalogue ..............................................59 B.2. Beaconing ICS ..............................................................................65 B.3. Beaconing Test Purpose...............................................................67 B.4. Beaconing ATS .............................................................................71

Appendix C – Beaconing TTCN-3 Test Suite ........... ................ 78 Modules Suite .............................................................................................78 Groups Suite ...............................................................................................79 Types Suite .................................................................................................80

Simple Type Suite............................................................................................. 80 Structured Type Suite ....................................................................................... 81 Enumerated Type Suite .................................................................................... 83 Port Type Suite ................................................................................................. 84 Component Type Suite ..................................................................................... 84

Constants Suite...........................................................................................85 Structured Templates Suite.........................................................................85 Test Cases Suite.........................................................................................94

Appendix D – Detailed MSC Test Cases ............... ................... 99




List of Figures Figure 1. SAFESPOT Testing Methodology............................................................................ 11 Figure 2. Steps to generate SAFESPOT Test Specifications ................................................. 12 Figure 3. SAFESPOT elements.............................................................................................. 13 Figure 4. Beaconing MSC ....................................................................................................... 14 Figure 5. SAFESPOT TTCN-3 Test System Architecture....................................................... 17 Figure 6. TTCN-3 Test Configuration. ..................................................................................... 18 Figure 7. SAFESPOT TTCN-3 Test Suite and Test Configuration. ........................................ 19 Figure 8. SAFESPOT TTCN-3 Test Configuration.................................................................. 19 Figure 9. TTCN-3 Test System Architecture ........................................................................... 20 Figure 10. TTCN-3 Test System Architecture ......................................................................... 22 Figure 11. SA into TTCN-3 Test System................................................................................. 23 Figure 12. SUUT adaptor for Beaconing ................................................................................. 23 Figure 13. Communication with the SUT................................................................................. 24 Figure 14. Conventional and virtual tester............................................................................... 25 Figure 15. PA into TTCN-3 Test System................................................................................. 25 Figure 16. Beaconing PA behaviour........................................................................................ 26 Figure 17. CODECS into TTCN-3 Test System ...................................................................... 26 Figure 18. Beaconing coding procedure ................................................................................. 27 Figure 19. Beaconing data packet........................................................................................... 28 Figure 20. Decoder subsystem................................................................................................ 29 Figure 21. Lower decoder architecture for beaconing............................................................. 30 Figure 22. Upper decoder for Beaconing ................................................................................ 31 Figure 23. Test logging entity .................................................................................................. 31 Figure 24. Test logging behaviour ........................................................................................... 32 Figure 25. Test execution logs ................................................................................................ 33 Figure 26. Extended logs......................................................................................................... 34 Figure 27. Test System – Components Integration................................................................. 36 Figure 28. Beaconing API functionality ................................................................................... 39 Figure 29. Dummy Application GUI. ........................................................................................ 41 Figure 30. Test manager – Technology manager ................................................................... 42 Figure 31. Test manager – PICS filling ................................................................................... 43 Figure 32. Test manager – PIC detailed ................................................................................. 44 Figure 33. Test manager – General parameters ..................................................................... 44 Figure 34. Test manager – General parameters detailed ....................................................... 45 Figure 35. Test manager – Test case selection ...................................................................... 45 Figure 36. Test manager – Execution controller ..................................................................... 46 Figure 37. Test manager – Test results .................................................................................. 46 Figure 38. SAFESPOT beaconing controller GUI ................................................................... 47 Figure 39. Beaconing validation sample: TC_VANET_BC_BB_VEH_001 ............................. 48 Figure 40. Beaconing TC_VANET_BC_BB_VEH_001 test execution (I) ............................... 50 Figure 41. Beaconing TC_VANET_BC_BB_VEH_001 test execution (II) .............................. 51 Figure 42. Beaconing TC_VANET_BC_BB_VEH_001 test execution (III) ............................. 52 Figure 43. TC_VANET_BC_BB_GEN_001............................................................................. 71 Figure 44. TC_VANET_BC_BB_GEN_002............................................................................. 72 Figure 45. TC_VANET_BC_BB_GEN_003............................................................................. 72 Figure 46. TC_VANET_BC_BB_GEN_004............................................................................. 73 Figure 47. TC_VANET_BC_BB_VEH_001 ............................................................................. 73 Figure 48. TC_VANET_BC_BB_VEH_002 ............................................................................. 74 Figure 49. TC_VANET_BC_BB_VEH_003 ............................................................................. 74 Figure 50. TC_VANET_BC_BB_RSU_001 ............................................................................. 75 Figure 51. TC_VANET_BC_BB_RSU_002 ............................................................................. 75 Figure 52. TC_VANET_BC_TI_GEN_001 .............................................................................. 76 Figure 53. TC_VANET_BC_TI_GEN_002 .............................................................................. 77 Figure 54. Global Vision of the Beaconing TTCN-3 Test Suite............................................... 79




List of Tables Table 1. Test Case Parameters............................................................................................... 21 Table 2. TTCN-3 and TRI correlation ...................................................................................... 24 Table 3. Beaconing Framework............................................................................................... 28 Table 4. Extended logging events ........................................................................................... 34 Table 5. List of Test Cases implemented ................................................................................ 37 Table 6. startBeaconing function description .......................................................................... 39 Table 7. setBeaconingParameter function description............................................................ 40 Table 8. stopBeaconing function description........................................................................... 40 Table 9. TBeacon parameters description .............................................................................. 40 Table 10. TServerConf parameters description ...................................................................... 41 Table 11. List of validated test cases ...................................................................................... 48 Table 12. Group 1: Role .......................................................................................................... 65 Table 13. Group 2: Specs........................................................................................................ 65 Table 14. Group 3: Message format........................................................................................ 65 Table 15. Group 4: General Beaconing Behaviour ................................................................. 66 Table 16. Group 5: Vehicles .................................................................................................... 66 Table 17. Group 6: RSU .......................................................................................................... 66 Table 18. Group 7: Timing....................................................................................................... 66 Table 19. MSC - TC_VANET_BC_BB_GEN_001................................................................... 99 Table 20. MSC - TC_VANET_BC_BB_GEN_002................................................................. 100 Table 21. MSC - TC_VANET_BC_BB_GEN_003................................................................. 101 Table 22. MSC - TC_VANET_BC_BB_GEN_004................................................................. 102 Table 23. MSC - TC_VANET_BC_BB_VEH_001 ................................................................. 103 Table 24. MSC - TC_VANET_BC_BB_VEH_002 ................................................................. 104 Table 25. MSC - TC_VANET_BC_BB_VEH_003 ................................................................. 105 Table 26. MSC - TC_VANET_BC_BB_RSU_001 ................................................................. 106 Table 27. MSC - TC_VANET_BC_BB_RSU_002 ................................................................. 107 Table 28. MSC - TC_VANET_BC_TI_GEN_001 .................................................................. 108 Table 29. MSC - TC_VANET_BC_TI_GEN_002 .................................................................. 109




EXECUTIVE SUMMARY This deliverable is targeted to SAFESPOT partners as a description of the SAFESPOT Test System Mock-Up developed by AT4 wireless within the SP7 - SCORE. At the same time the distribution is extended to those SAFESPOT members involved in other SP. This deliverable presents the TTCN-3 code developed to complete the test specification for protocol conformance testing of the beaconing services; it describes the architecture, and requirements to build a test system; and it also describes the test system mock-up and its validation using a dummy application developed by AT4 wireless.

D7.4.3 – PartB [5] describes a methodology to extract the test specifications. Chapter 2 applies this methodology in order to extract the Beaconing Test Specification for SAFESPOT. The test specification is composed of Requirement Catalogue (RQ), Protocol Implementation Conformance Statement (PICS), Test Suite Structure and Test Purpose (TSS&TP) and finally the Abstract Test Suite (ATS).

The definition of ATS is divided into two phases. The first one is focused on the message exchanged using UML Language between the beaconing functionality and the Test System in order to identify the test procedure. The second one is the implementation of the ATS using TTCN-3 Language. TTCN-3 is a formal specification language recommended for protocol conformance testing specification as it provides a platform independent specification. The whole TTCN-3 code is available on the SAFESPOT web site (http://bscw.safespot-eu.org/bscw/bscw.cgi/177787)

Chapter 3 describes completely the TTCN-3 Test System mock-up for beaconing services. This description follows the next structure:

− TTCN-3 Test Suite Description

− Test Configuration

− Test System Description

In order to validate and detect different bugs, a dummy application of beaconing services developed by AT4 wireless has been used as samples to test and validate the test system mock-up. Nevertheless, a “real” beaconing implementation should be provided to the test laboratory in next phases of SAFESPOT in order to be used as a reference implementation to validate and enhance the Beacon Test System Mock-up.

Chapter 4 describes the validation process of the TTCN-3 Test System Mock-up. Initially, this chapter describes briefly this dummy application, the complete validation procedure and also includes a detailed analysis of the messages exchanged between the SUT and the tester for a number of selected test cases.

All test cases have been integrated in the mock-up test system and are up and running. Moreover, results of testing performed (chapter 4) are very promising. All of the test cases have been executed and a pass verdict has been obtained.



SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 10 of 109 SCORE

1. Introduction 1.1. Contribution to the SAFESPOT Objectives

SAFESPOT defines a complex and heterogeneous cooperative ITS (Intelligent Transport System) network in which many technologies and functionalities are involved to integrate and implement the objectives of the project.

In order to get full interoperability between SAFESPOT vehicles and SAFESPOT RSUs (Road Side Units) is mandatory to satisfy every requirement and functionality specified in the interface vehicle to vehicle (V2V) and vehicle to infrastructure (V2I).

This deliverable focus on the specification, development and validation of the test system mock-up to be used to certify SAFESPOT implementations those are compliant to its technical specifications.

1.2. Methodology

SAFESPOT D7.4.3 – Part B [5] defines a complete testing methodology divided into three phases (See Figure 1).

− Phase 1-SAFESPOT Elements to be tested / certified. This phase is based on ISO 10746-1 with the main objective to select the functionalities to be tested / certified in SAFESPOT

− Phase 2: SAFESPOT Test Specification. Once the functionalities to be tested / certified have been decided in phase 1, it is necessary to extract from the SAFESPOT deliverables the SAFESPOT test specification and to decide the test strategy to be applied for.

− Phase 3: SAFESPOT Test System. Finally, once the test specifications are specified, the next phase is the implementation and validation of the test system based on the test strategy decided.

The first phase was performed during the description of D7.4.3 [5], and finally, beaconing functionality specified in SP3-SINTECH was chosen to be tested. Next phases, phase 2 and 3, have been perform to define the content of this deliverable.




Figure 1. SAFESPOT Testing Methodology

1.3. Deliverable Structure

After this introductive part the deliverable starts by specifying the beaconing test specifications extracted from beaconing specifications (chapter 2).

Once the beaconing test specifications are described, an exhaustive description of the test system is done (chapter 3). The test system is based on TTCN-3 language which is a standardized testing language and test system architecture that is being used and accepted widely in the telecom industry.

Finally, the test system must be validated and the results of all test cases is made public (chapter 4). The validation process is described from a user point of view.

This deliverable ends with the list of references.

Phase 1: Elements to be tested / Certified

SAFESPOTArchitecture

Phase 2: SAFESPOT Test Specification

Phase 3: Beaconing Test System

Beaconing Specifications

Beaconing Implementations

Beaconing Test Specifications




2. Beaconing SAFESPOT Test Specification

2.1. Introduction

SAFESPOT D7.4.3 – Part B [5] phase 2 describes a set of steps in order to extract a complete test specifications from a formal point of view. One of the objectives of SAFESPOT is to develop a test system mock-up, and the input to start this development is the test specification.

Figure 2. Steps to generate SAFESPOT Test Specifica tions

Chapters 2.2 and following define each step of the test specification procedure. Test specification phase is performed to extract beaconing test specification from the following SAFESPOT technical specifications:

− D3.2.2 - SAFESPOT SP3-SINTECH User Needs [2]. This deliverable identifies and collects all the requirements for Vehicular Ad-hoc Networks (VANET), Positioning and Local Dynamic Map (LDM).

− D3.3.4 – SAFESPOT SP3-SINTECH VANET Specification [1]. This deliverable contains the basic specifications of the SAFESPOT VANET including interfaces, protocols and algorithms definition.

− User Data Format and Messages Document - SAFESPOT SP7-SCORE [3]. This deliverable is in charge of defining all the messages exchanged between SAFESPOT entities.

− D3.4.2 - SAFESPOT SP3-SINTECH Implementation Plan [4]. This document presents the implementation plan and the strategies of the main technologies considered in SINTECH.

Therefore, this section presents a brief introduction of beaconing functionality and then specifies the complete beaconing test specification extracted from technical specifications indicated above. The complete Beaconing Test




Specifications document is available on SAFESPOT web site (http://bscw.safespot-eu.org/bscw/bscw.cgi/163215)

2.2. Beaconing Functionality

The VANET (Vehicular Ad hoc network) offers a beaconing service. This service is a periodic transmission of network layer beacons (NL_BEACON).

Network layer beacons consist of three basic fields, header, payload and security. In this case, the test system is focused on analyzing beaconing functionality without payload or security in terms of beaconing messages exchanged and beaconing behaviour specified in V2V and V2I reference point (RP). Beacon message headers consist of twelve fields with a total length of 36 bytes. Figure 2 shows the different elements (RSUs and Vehicles) communicating on the desired interface.

Figure 3. SAFESPOT elements

The content of this message includes information about message type, sequence number, Node identifier, GPS position, Speed and priority.




Figure 4. Beaconing MSC

2.3. Requirement Catalogue

The objective of this document is to define the VANET – Beaconing Requirements Catalogue. VANET (Vehicular Ad hoc network) architecture is defined into the SAFESPOT SP3-SINTECH subproject in D3.3.4 [1].

Specifications and standards may be understood as a set of requirements related to the technology defined in these documents. For this reason, Requirements Catalogue Specification collects all features that are mandatory and optional for implementations conforming to the specification or standard to be used. This step is laborious and expensive, but it is an essential step in the whole testing process, because this catalogue is a summary of the specifications and standards and can help to understand them much better in order to achieve a well-defined test specifications.

Appendix B shows the Beaconing RQ document.

2.4. PICS

The objective of this document is to define the VANET – Beaconing PICS (Implementation Conformance Statement).

The PICS is derived from the Requirement Catalogue document [9] and provides a checklist of the capabilities supported by the IUT embedded in the SUT. It provides an overview of the features, capabilities, functionality and options that are implemented by a product under test. The PICS can be used to select and parameterize the test cases as an indicator for basic interoperability between different products. Consequently, the PICS must be filled in by the manufacturer.

Appendix B shows the Beaconing PICS document.




2.5. Test Suite Structure and Test Purposes

The objective of this document is to provide Test Suite Structure and Test Purposes (TSS&TP) of beaconing specifications based on the requirements defined in the requirements catalogue [9] and written according to the guidelines of [11], [10], [8] and [6]. The objective of the VANET test specification is to provide a high probability of interoperability between different VANET implementations focusing on beaconing functionality.

Appendix B shows the Beaconing TSS&TP document.

2.6. Abstract Test Suite

The objective of this document is to define the VANET – Beaconing Abstract Test Suite (ATS). The ATS development is derived from VANET – Beaconing Test Suite Structure and Test Purpose (TSS&TP) [12] and provides a formal language description of every test focusing on how it may be achieved. Language used to describe ATS itself is UML (Universal Modelling Language), which is a notation developed by ETSI (European Telecommunication Standard Institute) for expressing Test Cases in a formal way.

Appendix B shows the Beaconing ATS document.




3. SAFESPOT Test System Mock-up

3.1. Introduction

The test tool described is strictly based on Beaconing Specifications described in section 2. The test specification is addressed to cover Beaconing functionality. This section performs a complete description of the SAFESPOT Test System mock-up developed and all the modules that composed the test system, as well as some comments needed to understand the description.

The main purpose of this test system is to test beaconing functionality developed in SAFESPOT. The test system architecture selected is based on TTCN-3 Test System Architecture because this architecture makes testing available and independent of the mean of connection selected in the SUUT (SAFESPOT Unit Under Test).

TTCN-3 is a standardized testing language and test system architecture that is being used and accepted widely in the telecom industry. TTCN-3 is being successfully used in the certification of new challenging technologies such as IPv6 and WiMAX. Basically, TTCN-3 provides a common language used by many different people involved in testing.

Figure 5 shows the complete SAFESPOT mock-up Test System architecture composed of different modules which are described in the following sections.

− TTCN-3 Executable (TE): TE is the entity responsible for the interpretation or execution of the TTCN-3 test cases. Conceptually, the TE can be divided into two entities: Executable Test Suite handles the execution of test cases, the TTCN-3 Runtime System (T3RTS) performs all the actions necessary to execute correctly a test case; this entity interacts with the Test Management, SA and PA via TCI and TRI interfaces and manages Executable Test Suite.

− CODECS: the CODECS entity is responsible for encoding and decoding each data type exchanged between TE entity and SA and PA entities via TRI. An encoder function will be called when a value is sent to the SUT. A decoder function will be called whenever received data have to be converted into a TTCN-3 value.

− System Adaptor (SA): the SA adapts message and procedure based communication of the TTCN-3 test system with the SUT to the particular execution platform of the test system. It is responsible to propagate send requests and SUT action operations from the TTCN-3 Executable (TE) to the SUT, and to notify the TE of any received test events by appending them to the port queues of the TE. These capabilities are implemented through the TRI (TTCN-3 RunTime Interface) Interface.

− Platform adaptor (PA): the PA implements TTCN-3 external functions and provides a TTCN-3 test system with a single notion of time. In this entity, external functions are to be implemented as well as all timers. Notice that timer instances are created in the TE. The interface with the




TE enables the invocation of external functions and the starting, reading, and stopping of timers as well as the inquiring of the status of timers using their timer ID. The PA notifies the TE of expired timers. Finally, external functions are the main component of Platform Adaptor (PA). External functions are a powerful resources supported by TTCN-3 language. External function is a function declared at TTCN-3 level but implemented at native level. These capabilities are implemented through the TRI (TTCN-3 RunTime Interface) Interface.

− Test Management (TM): the TM entity is responsible for the overall management of a test system. The aim of this entity is to manage the execution control.

Figure 5. SAFESPOT TTCN-3 Test System Architecture

Next sections will describe in more detail the different components of the SAFESPOT Test System mock-up and the TTCN-3 Test System development.

3.2. Test Management

Test Management is responsible of testing execution control and testing event logging. For the test system mock-up this part of the system is implemented using a tool previously developed by AT4 wireless called Test Manager. The adaptation work has been completed within the scope of the project.




Below the functionalities of Test Manager are summarized:

− Test cases Projects Management.

− Samples Project Management,

− Test Parameters (PICS and PIXIT) edition and checking.

− Mapping Table and Static Conformance review generation.

− Execution Scripts Management.

− Execution Traces Viewer.

− Test Results Viewer.

− Result statistics.

3.3. SAFESPOT TTCN-3 Test Executable

TTCN-3 Test Executable is the entity responsible for the interpretation and execution of the TTCN-3 test cases

This module is composed mainly of two blocks, one of them is the TTCN-3 Test Configuration and the other one is the Test Suite. The Test configuration consists of a set of inter-connected test components with well-defined communications port and an explicit test system interface (TSI) which defines the borders of the test system. Within every configuration there shall be one (and only one) Main Test Component (MTC). Test components that are not MTCs are called parallel test components or PTCs. Figure 6 depicts a general overview of a TTCN-3 Test Configuration.

Figure 6. TTCN-3 Test Configuration.




TTCN-3 Test Suite is the collection of all Abstract Test Cases (ATC) from the Abstract Test Suite (ATS). All Test Cases, data types, components and so on are coded and implemented using the platform independent language TTCN-3. The whole implementation is called TTCN-3 Test Suite.

A complete TTCN-3 Test Suite has been written for designing and implementing the Beaconing test cases according to abstract test suite specification. To edit these test suite a wide set of TTCN-3 elements has been used. Emphasizing that all test cases are completely written in TTCN-3 and the whole TTCN-3 code is available on the web site (…). The lists of complete test suites edited in TTCN-3 are specified in section 3.3.2. This section shows a short overview of the TTCN-3 test suite and the test configurations for each application.

Figure 7. SAFESPOT TTCN-3 Test Suite and Test Confi guration.

3.3.1. TTCN-3 Test Configuration

TTCN-3 test configuration for beaconing service is shown on next figure.

Figure 8. SAFESPOT TTCN-3 Test Configuration

SAFESPOT TTCN-3 Test Configuration is only based on a MTC called tcp_mtc_LT. It communicates with the SAFESPOT System Under Test (SUUT) by the TSI interface.

The SUUT implements the beaconing functionality. It basically consists on sending data packets periodically from SUUT to the MTC.




Beaconing packets exchanged are captured by the TSI interface and routed to the defined MTC port. Beaconing service defines two ports, one of them for the MTC (pt_mtcBcPDU) and the other one for the Test System Interface (pt_tsiBcPDU). Both ports are defined as tpt_m_BcHeaderPDU type.

Each beaconing packet consists of 36 bytes because it is only considered Beacon Message Header and the associated functionality. These messages are only sent from the SUT to the MTC. Type of data exchanged is called dt_r_BcHeader. This type of data specifies the beaconing message header and using TTCN-3 language and it is described in section 3.3.2.

The MTC is responsible of:

- receiving Beacon Message Headers and extracting relevant information to be analyzed such as Beacon period, transmitted power, timestamps and so more.

- implementing test case behaviour based on ATS specification.

- determining the verdict of the test case.

3.3.2. SAFESPOT TTCN-3 Test Suite

The whole beaconing TTCN-3 Test Suite documentation has been developed according to the documentation template presented in Appendix A http://bscw.safespot-eu.org/bscw/bscw.cgi/177787). The whole description of all the types, components, ports, etc. of this Test Suite are described in Appendix C.

3.3.3. TTCN-3 Test Cases Parameter List

Several test cases need parameter to configure its behaviour. A set of parameters have been defined in order to configure the execution of the Test Cases.

Figure 9. TTCN-3 Test System Architecture




Next table groups the parameters for each test case listing the parameter name, the parameter type and comments.

Table 1. Test Case Parameters

Test Case Id. Parameter name Parameter type Units Comments

TC_BB_GEN_001 t_CtrlTimer float X.y seconds Timer to control timeouts.

t_CtrlTimer float X.y seconds Timer to control timeouts. TC_BB_GEN_002

v_NoID dt_i_NIdent ‘0xhhhhhhhhhhhhhhhh’ Node ID.





t_CtrlTimer float X.y seconds Timer to control timeouts.


v_PositionVeh dr_r_Pos {X º, Yº} Vehicle position. TC_BB_VEH_001

v_NewPositionVeh dt_r_Pos {X º, Yº} v_NewPositionVeh

t_CtrlTimer float X.y seconds t_CtrlTimer

v_NoID dt_i_NIdent ‘0xhhhhhhhhhhhhhhhh’ v_NoID

v_VelocityVeh dt_r_Spd {X.y m/s , X} v_VelocityVeh TC_BB_VEH_002

v_NewVelocityVeh dt_r_Spd {X.y m/s , X} v_NewVelocityVeh

t_CtrlTimer float X.y seconds t_CtrlTimer TC_BB_VEH_003


t_CtrlTimer float X.y seconds t_CtrlTimer TC_BB_RSU_001



v_NoID dt_i_NIdent ‘0xhhhhhhhhhhhhhhhh’ v_NoID TC_BB_RSU_002

v_PositionRSU dt_r_Pos {X º, Yº} v_PositionRSU


v_NoID dt_i_NIdent ‘0xhhhhhhhhhhhhhhhh’ v_NoID TC_TI_GEN_001

v_Tolerance float X.y % v_Tolerance


v_NoID dt_i_NIdent ‘0xhhhhhhhhhhhhhhhh’ v_NoID TC_TI_GEN_002

v_Tolerance float X.y % v_Tolerance




3.4. SAFESPOT Test System Adaptor

This section intends to present the general structure of the SAFESPOT TTCN-3 test system. This section focuses on explaining the four basic modules of the Test System. These modules are the followings:

� System Adapter (SA).

� Platform adapter (PA).

� Codecs (CD).

� Logging (TL).

Figure 10. TTCN-3 Test System Architecture

3.4.1. System Adaptor (SA)

This section focuses on describing SA subsystem onto the TTCN-3 Test System Architecture.




Figure 11. SA into TTCN-3 Test System

The SA adapts message and procedure based on communication of the TTCN-3 Test System with the SUUT to the particular execution platform of the test system. It is aware of the mapping of the TTCN-3 test component communication ports to test system interface ports and implements the real test system interface. It is responsible to propagate beaconing messages from the TTCN-3 Executable (TE) to the SUUT, and to notify the TE of any received beaconing messages by appending them to the port queues of the TE, in this case port pt_mtcBcPDU.

The TTCN-3 SA layer architecture for Beaconing application is presented below.

Figure 12. SUUT adaptor for Beaconing




The SA has a standardized interface with the TE, which is used to send SUUT messages to the SA and to exchange encoded test data between the two entities in communication operations with the SUUT. These capabilities are implemented through the TRI (TTCN-3 RunTime Interface) Interface.

The following table shows the TRI correlation between the TTCN-3 operation and the TRI routines called into TRI routines.

Table 2. TTCN-3 and TRI correlation

TTCN-3 Operation Name TRI Operation Name

Send triSend

Receive triEnqueueMessage

Start to execute a test case triExecuteTestCase

As communication technology and based on “Virtual Tester” concept, initially UDP/IP communication through socket technology has been used for the communication between Beaconing functionality embedded into SUUT and test system using virtual testing concepts. A “Virtual Tester” is a test system that replaces the communication layer by a virtual communication tunnel as Figure 14 shows.

This solution has been adapted due to the unfinished SAFESPOT communication platform. The abstraction offered by the TTCN-3 test system allows Test Cases to be the same and only that SA module must be adapted to the final communication interface between Test System and SUUT.

Figure 13. Communication with the SUT

The development of advanced protocols requires test to be done before implementation steps, therefore, testing equipment is needed. For instance, using wireless communication such as 802.11p, the test system must implement the radio communication channel to transport the test stimulus, in this case beaconing messages, to the SUUT and back. But, the SAFESPOT communication technology is not available yet.




Figure 14. Conventional and virtual tester

3.4.2. Platform Adaptor (PA)

This section focuses on describing PA subsystem onto the TTCN-3 Test System Architecture.

Figure 15. PA into TTCN-3 Test System

The main purpose of the PA module is to implement TTCN-3 external functions and provides a TTCN-3 test system with a single notion of time. Highlighting that timer instances are created in the TE. External functions are the main component of Platform Adaptor (PA). External functions are a powerful resources supported by TTCN-3 language. External function is a function declared at TTCN-3 level but implemented at native level. These capabilities are implemented through the TRI (TTCN-3 RunTime Interface) Interface.

The TTCN-3 PA layer architecture for Beaconing application is presented below. Beaconing PA consists on timers . The implementation of timers is based on Windows Operating System temporizations because the test system is developed and executed in this Operating System. Additional timing




configuration was needed over PA sublayer to get the required beaconing behaviour. No external functions are implemented.

Figure 16. Beaconing PA behaviour

The interface with the TE, also based on TRI interface, enables the invocation of external functions and the starting, reading, and stopping of timers as well as the inquiring of the status of timers using their timer ID. The PA notifies the TE of expired timers.

3.4.3. CODECS (CD)

This section focuses on describing CODECS subsystem onto the TTCN-3 Test System Architecture.

Figure 17. CODECS into TTCN-3 Test System




The CODECS entity is responsible for encoding and decoding each data type exchanged between TE entity and SA and PA entities via TRI, in this case beaconing message headers. A decoder function will be called whenever received data have to be converted into a TTCN-3 value. There are two main entities into the codecs subsystem, lower codecs and upper codecs. See section 3.4.3.1 and 3.4.3.2 for further information.

Codecs implementation is based on TCI interface. The integration method for including codecs in the test system requires a registration, initialization, configuration and implementation phase for each predefined or user-defined data type.

Due to the specific data types defined in the TTCN-3 for SAFESPOT VANET– Beaconing service, it is necessary to define a specific routine for the Beacon Message Header decoding.

That routine must receive a Beacon Message Header containing all the fields previously defined in the TTCN-3, extract the basic data type of each field and route it to the suitable encoder or decoder. Because of beaconing messages are only received from the SUUT and the test system does not have to generate any message, coding subsystem is not necessary to be included into the test system, and only decoding subsystem is implemented.

The procedure consists on extracting the bytes that conforms a field of the global structure, decode via the valid decoder, and go on with the next field till the end.

Figure 18. Beaconing coding procedure

Then, information exchanged between TTCN-3 and TRI pass through this CODECS subsystem. For Beaconing service, packets are Beacon Message Headers including all beaconing parameters. Since a Beacon Message Header always contains 36 bytes, it is possible to control the size of each field.

See figure 18 and table 3 to get further information about Beaconing data format and message based on [4].




Figure 19. Beaconing data packet

Beaconing message header consists on twelve fields of total length 36 bytes that must be correctly decoded by the implemented codecs subsystem.

Table 3. Beaconing Framework

Field number Field name Field size

1 Header version 1 byte

2 Message type 1 byte

3 Sequence number

2 bytes

4 Node ID 8 bytes

5 Node type 1 byte

6 Timestamp 6 bytes

7 Position 8 bytes

8 Position variance 2 bytes

9 Node speed 4 bytes

10 Beacon period 1 byte

11 Transmitted power

1 byte

12 Priority 1 byte

As previously defined, two main parts form the CODECS subsystem, the lower codecs and the upper codecs. The lower codecs are responsible of extracting Beacon Message Header fields from message received and converting these fields to built-in native data types. The upper codecs are in charge of the conversion to native built-in data types to TTCN-3 data types.

The next figure shows lower and upper codecs forming the decoder subsystem.

5 1 2 3 4 6 7 8 9 11 12 10

BEACON MESSAGE HEADER

36 bytes




Figure 20. Decoder subsystem

3.4.3.1. Lower codecs for Beaconing service

The lower codecs are responsible of conversion from Beacon Message Headers to built-in native data types such as C language. Typically, the codecs receive the complete Beacon Message Header and extract correctly the information of each field based on the structure of Beacon message defined in [4]. Next figure shows lower codecs architecture from the decoding point of view.




Figure 21. Lower decoder architecture for beaconing

3.4.3.2. Upper codecs for Beaconing service

Upper codecs are responsible of converting from native data types (C language) to TTCN-3 structured data types. The implementation is based on TCI-CD standard. All fields of a Beacon message header are implemented as integer types at C domain. However, at TTCN-3 there are different data types corresponding with each Beacon Message Header field. The following figures illustrate decoded upper codecs subsystem for the main types.




Figure 22. Upper decoder for Beaconing

3.4.4. LOGS

This section focuses on describing logging subsystem onto the TTCN-3 Test System Architecture.

Figure 23. Test logging entity

BcHeader from TTCN-3

Field Name Field Type

Header version integer Message type Enumerated

Sequence number integer Node ID Octetstring

Node type Enumerated

TimeStamp.seconds Unsigned integer

TimeStamp.milisec integer Position.Longitude integer Position.Latitude integer

PositionVar.x integer PositionVar.y integer

Speed.Direction integer Speed.Module float Beacon Period Integer

Priority Enumerated TxPower.Power integer

TxPower.Antenna Enumerated

Upper

decoder

TTCN-3 Context

Native types TTCN-3

Field Name Field Type

Header version int Message type int

Sequence number int Node ID int

Node type int TimeStamp.seconds int TimeStamp.milisec int Position.Longitude int Position.Latitude int

PositionVar.x int PositionVar.y int

Speed.Direction int Speed.Module int Beacon Period int

Priority int TxPower.Power int

TxPower.Antenna int

Native (C) Context




Logging mechanism is provided by Test Logging (TL) entity. The TL entity performs test event logging and presentation to the test system user. It provides the logging of information about the test execution such as which test components have been created, started and terminated, which data is sent to the SUT, received from the SUT and matched to TTCN-3 templates, which timers have been started, stopped or timed out, etc.

SAFESPOT TTCN-3 Test System mock-up provides two kinds of logs mechanism to the test operator: test execution logs and extended logs. Next figure shows the logging behaviour for both execution and extended logging events.

Figure 24. Test logging behaviour

All registered logs are previously received by test management entity. That entity implements the decision behaviour, routing each log to the required destination. Test operator visualizes registered logs by that entity.

Test execution logs contain only most important logs about test system behaviour and provide to the test operator relevant information about the progress and status of the test execution. Examples of test execution logs are the final verdict, message received or the name of the test case which is being tested. Test operator visualizes those logs through test management entity during test execution.




Figure 25. Test execution logs

In the previous figure there are different areas. Two of them are used to shown test execution traces. Here it is shown messages like the result of the matching mechanism, final verdict or when receiving a beacon message header. The other one is used to present the test case name and the result of the test execution. In the previous figure, a green circular confirmation picture says that the final verdict is ‘pass’.

Extended logs include more technical and specific information useful for the applications developers. A higher number of events are registered in that case to allow the understanding of test cases execution once it has finished. Examples of extended logs are the content of the beacons received, the result of the matching mechanisms, the mapped ports and so more. All events are stored into an .xml file.

That extended logs allows test operator to check the complete list of logged actions after test execution, not in real time like the other one.

For this reason, they are automatically stored into an .xml file when test execution ends. It allows to search any kind of errors appeared during test execution by easy following that test case execution. When visualizing that extended logs test operator can see detailed information about test case execution like specific value of each beacon message header received, result of each matching mechanism, etc.

Traces are shown here




Next table shows the complete list of extended logs:

Table 4. Extended logging events

Event Parameters shown

Test Case started Name of the Test Case

Test Case verdict Verdict(pass,fail,inconc,none)

Timer started Timer name and duration

Timer stopped Timer name

Timer timeout Timer name

Message received Port, length and value of each field

Template match begin Template name

Template match end Template name

Template match result Successful or Fail

Template match failed Template result, template value

Logs TTCN-3 Logs generated in the test Suite with

the “log” statement

Component started Component name

Alternative entered -----

Alternative left -----

Port mapped Both ports name

Port unmapped Both ports name

Figure 26. Extended logs

Received beacon value

Extended test

execution logs

Test

execution info.




In the previous figure there are three different parts. The right one is used to shown extended information about the specific value of received beacons message headers. On the upper left, there is information like technology type, verdict, test data, etc. The last one presents extended logs about test execution. For each one it is presented the related component, timestamp and a little summary.

3.4.5. TTCN-3 Test System Development

Test system development is divided into five phases (See Figure 27):

a. Test Architecture Definition: Abstract Test Method (ATM) and test configuration are derived to get the test system architecture based on TTCN-3 and external components.

b. TTCN-3 Test Suite Edition: All of Abstract Test Cases (ATC) from the Abstract Test Suite (ATS) are coded using the platform independent language TTCN-3. All test cases, data type, communication models and so on are implemented. The whole implementation is called TTCN-3 Test Suite.

c. Adaptors Development: Internal and external encoder and decoder, system under test adaptor (component needed in order to communicate test system and system under test) and platform under test (component needed in order to communicate test system and external reference elements) have to be developed to enable interworking between the high level language TTCN-3 dynamics and real elements in the test system mock-up. The adaptors are platform dependent and coded in native language (e.g., C1 or Java)

d. Components integration: TTCN-3 test cases are translated (using a commercial TTCN-3 compiler) to native code. Generated code and Adaptors are compiled and linked to produce the Executable Test System (ETS). (See figure below).

e. Test System Validation : to validate the TTCN-3 code, it is necessary to generate a test system mock-up. To achieve this purpose the mock-up must be connected to a reference system under test.

1 Adaptors in SAFESPOT mock-up are coding in C language.




Figure 27. Test System – Components Integration




4. SAFESPOT Test System Validation

4.1. Introduction

The list of beaconing test cases and their test purposes as documented in Appendix B. All test cases are edited in TTCN-3 and can be executed against a SUUT. All of test cases are detailed by means of the abstract UML diagram (Abstract Test Case) describing the high level purposes and abstract test method.

Table 5. List of Test Cases implemented

Test case ID Test purpose

TC_VANET_BC_BB_GEN_001 To verify correct Beacon Message Header format and size.

TC_VANET_BC_BB_GEN_002 To verify correct configuration settings for a Beacon Message Header.

TC_VANET_BC_BB_GEN_003 To verify the Sequence Number behaviour.

TC_VANET_BC_BB_GEN_004 To verify that the transmitted is in the valid range.

TC_VANET_BC_BB_VEH_001 To verify beaconing adaptation to vehicle movement.

TC_VANET_BC_BB_VEH_002 To verify beaconing adaptation to changes in vehicle speed.

TC_VANET_BC_BB_VEH_003 To verify beaconing adaptation when the SF vehicle is stopped.

TC_VANET_BC_BB_RSU_001 To verify correct operation of RSU Beacon Message header Speed field.

TC_VANET_BC_BB_RSU_002 To verify correct operation of RSU Beacon Message header Position field.

TC_VANET_BC_TI_GEN_001 To verify the correct Beaconing Interval performance.

TC_VANET_BC_TI_GEN_002 To verify the correct procedure changing the Beacon Period.

Detailed description of Test Cases MSC is presented in Appendix D. MSC is drawn according to TTCN-3 documentation.

The SUUT selected for validating the Beaconing mock-up developed is a dummy application with a GUI (Graphical User Interface) which allows to easily change the beaconing configuration when necessary. See chapter 4.2 for further information.




4.2. Interface Requirements

The objective of this section is to define the basic functionality required to a beaconing SAFESPOT Vehicle or a beaconing SAFESPOT RSU in order to perform the test cases previously defined.

In order to perform these tests, the SUUT has to provide the necessary configuration interface to the Test Management in order to:

1. Select if the SUUT has the role of vehicle or RSU.

2. Configure Node ID of SF Vehicles or SF RSU.

3. Configure vehicles Speed. It should be possible to emulate situations

like car accelerating or putting on the brakes.

4. Configure vehicles Position. It should be possible to emulate situations

like going ahead, taking a curve or going in reverse.

5. Configure Beacon Period interval. The value must comply with the valid

specified margin between 0.5 and 2 seconds. Allowed tolerance to this

range must be defined.

4.3. Reference Implementations

A reference implementation of the beaconing functionality based on D3.3.4 – SAFESPOT SP3-SINTECH VANET Specification [1] has been developed to make possible the validation of the test system at the first stages of this development because of SAFESPOT. The goal of this development has been the creation of a dummy application that provides a GUI (Graphical User Interface) in order to be able to set-up and modify the values of the parameters of the beaconing messages generated. This reference implementation is based on an API (Application Programming Interface) developed in C language.

The communication technology selected to send beacons message has been UDP/IP protocol. This solution has been adapted due to the unfinished SAFESPOT communication platform, as well as the Beacon Test System Mock-up is using this communication technology to receive beacon message.

The beaconing functionality has been implemented as a multithreaded library, on this way is possible to interact with the functions of the library without interrupting the process of sending, which run as an independent thread.

Once, SAFESPOT develops a “real” beaconing implementation, this implementation should be provided to the test lab in order to be used as a reference implementation to validate and enhance the Beacon Test System Mock-up.




4.3.1. Description of the API

In order to manage the beaconing process, an API has been specified and developed. This API provides an interface to easily control all the functionality related to the Beaconing behaviour and consists of three functions (StartBeaconing, SetBeaconingParameter and StopBeaconing) which provide with all the functionality needed.

Figure 28. Beaconing API functionality

Table 6. startBeaconing function description

int startBeaconing(TBeaconParameters *bParameters,TServerConf serverConf);

Description: this function starts and sets the initial configuration of Beacon Functionality.

Parameters:

- bParameters – this parameter represents the information that Beacon message must carry.

- serverConf – this parameter contains the IP destination address and the UDP port where the beacons will be send.




Table 7. setBeaconingParameter function description

int setBeaconingParameter(TBeaconParameters *bParameters, TBeaconParameters newbParameters);

Description: this function sets and configures a new Beacon Functionality without interrupting the sending.

Parameters:

- bParameters – this parameter represents the information that Beacon message must carry.

- newbParameters – this parameter contains the new set of parameters that the Beacon will carry.

Table 8. stopBeaconing function description

int stopBeaconing( void );

Description: this function stops Beacon Functionality.

The structure TBeaconParameters contains all the parameters that define the Beacon Functionality, these are:

Table 9. TBeacon parameters description

Parameter Description

beaconperiod It is the period of time between two beacons. The unit is seconds.

msgtype

It is the type of message and the values of this parameter could be e_Unknowns, e_Beacon, e_Awareness_Cooperative, e_Emergence, e_Event, e_Periodic, e_HMIEvent, e_HMIPeriodic and e_CVISBeacon based on [3].

nodeid It is the Node Identifier. The format selected is hexadecimal following the structure XX:XX:XX:XX:XX:XX:XX:XX

Nodetype It is the type of the node and the values of this parameter could be e_UnknownType, e_VehicleType and e_RSUType based on [3].

priority It is the priority of the message and the values of this parameter could b e_UnknownPri, e_BeaconPri, e_EmergencyPri, e_HighPri, e_MediumPri and e_LowPri based on [3].

pos It is the position of the vehicle. This position is defined using the longitude and the latitude.

nodespeed It is the speed of the node defined as a module and a direction.

Txpower

It is contains the type of antenna and the power transmitted. The values of the type of antenna could be e_UnknownAnt and e_OmniAnt based on [3]. Moreover, the unit of power transmited is dBm.

The configuration of the destination address is stored in a TserverConf structure, which has two fields:




Table 10. TServerConf parameters description

Parameter Description

ipaddress It contains the IP address of the destination.

port It contains the UDP port of the destination.

4.3.2. Using the dummy application

In this section the use of the beaconing application will be briefly explained. Once, the application starts, the following GUI is presented to the user:

Figure 29. Dummy Application GUI.

The user finds three main buttons and two sets of parameters. The following steps describe the sequence of use to achieve the functionality of the tool:

Step 1: The first step is to configure the destination IP address and UDP port where the beacon will be sent, this can be done editing the parameters in the set Test System Address .

Step 2: The next step is the configuration of the parameters of the Beaconing functionality, which can be found in the set Beacon Parameters , here the parameters commented in the previous point can be set up filling the correspondent fields.

Step 3: Clicking on the button Start Beaconing will start sending the beacons with all the previously configured parameters, and to the address previously defined.




Step 4: Once the beaconing process is initiated, any parameter can be changed by changing the correspondent field and clicking on Modify Parameters . This change on the parameters does not interrupt the sending, the beacon will be modified in the moment of clicking, and the sending will continue in a transparent way.

Step 5: The button Stop Beaconing allows the user to stop the sending in any moment. This sending can be re-started again by clicking the button Start Beaconing.

Step 6: Clicking on Quit at any moment will stop the beaconing process and close the program.

4.4. Validation Procedure

The interface with the test house test operator is through the Test Manager. Test Manager is an AT4 wireless tool that can manage test case execution, test reports generation, PICS and PIXIT edition and so on. This tool is used as test laboratory facility for SAFESPOT test system mock-up.

The validation process is performed following the next steps.

1. Start the test manager tool.

2. PICS filling by test operator.

3. General parameters filling by test operator

4. Test Cases selection to be run.

5. Test Case execution.

6. Test results.

4.4.1. Starting test manager

When test operator starts test manager, first of all it has to select the technology to be implemented. Usually a test laboratory is able to test other technologies and therefore first step is to select the SAFESPOT subproject as technology to be tested.

In this case, the only installed project on the test manager tool is the SAFESPOT project.

Figure 30. Test manager – Technology manager

SAFESPOT




The work on this aspect has been to include SAFESPOT into the technology database of Test Manager.

4.4.2. PICS filling by test operator

SUUT manufacturer fills the PICS according to the capabilities of the product to be tested. Once PICS are filled, Test Manager selects automatically the set of test cases to be executed, i.e., it produces the Test Plan for the specific device to be tested and for the specific applications, in this case, the beaconing service.

Figure 31. Test manager – PICS filling

First column is the PICS reference according to the test specifications. The column “SCR” (Static Conformance Requirement) notes to the test operator that every PIC is correctly filled. For example, in the Figure 28, PICS 3.7.1 and 3.7.2 does not apply to the selected configuration (SCR red flag) because PIC 3.2.2 is set to false, so the current configuration was made to test a vehicle.

Clicking on any PICS item reveals detail information about the PICS item.




Figure 32. Test manager – PIC detailed

PICS item detailed above is about one of the documents that applies to Beaconing functionality, the user needs and requirements document. Obviously, this PIC item is mandatory.

4.4.3. General parameters filling by test operator

Once PICS has been correctly filled, test operator has to fill the general parameters which will be used by all the test cases.

Figure 33. Test manager – General parameters

In the Beaconing service, there are two global parameters, ControlTimer and NodeID.

ControlTimer specifies the maximun time before a timeout during test case execution.

NodeID specifies the Node ID value specified in the SUUT and must be used in each beacon message header.

Clicking on any general parameter reveals detail information about the parameter.




Figure 34. Test manager – General parameters detail ed

4.4.4. Test cases selection to be run

When the test operator fills all PICS, the Test Campaign is generated. Once all the PICS have been selected, test operator will select the set of test cases to run at execution session, i.e., the group of test cases to be executed in batch mode.

Figure 35. Test manager – Test case selection




After selecting the desired test cases to be executed, test case parameters should be filled.

Figure 35 shows an example where test case parameters are configured for TC_VANET_BC_BB_VEH_002 test case. As shown above, there are four general parameters to be configured.

Once the list of applicable test cases is available, double-clicking on each test case selected launches the execution controller.

4.4.5. Test case execution

During test case execution, test reports has been generated and shown notifying to the test operator about the relevant events are occurring.

Figure 36. Test manager – Execution controller

4.4.6. Test results

A complete view of the list of executed test cases and the verdict are shown to the test operator. See Figure 37.

Figure 37. Test manager – Test results




Information for each test case executed and Date/Time, Duration and Verdict are shown to the test operator.

In this test result window, test operator can open the xml file which contains the complete list of logged actions by double-clicking over one of the presented results.

4.5. Beaconing Validation

The Beaconing reference implementation used in the beaconing validation process is described in the chapter 4.2 and consists of a configurable dummy application by a GUI (Graphical User interface).

The GUI allows changing Beacon configuration by introducing new parameters values and clicking on the “Modify Parameters” button. IP server and port over which take part the UDP/IP socket communication are configurable too. Next figure shows the defined interface:

Figure 38. SAFESPOT beaconing controller GUI

Enumerated data types values are set by a command bar popup which allows test operator to choose only valid values.




Next table shows a list of validated test cases:

Table 11. List of validated test cases

Test case ID Validated Verdict

TC_VANET_BC_BB_GEN_001 YES PASS




TC_VANET_BC_BB_VEH_001 YES PASS



TC_VANET_BC_BB_RSU_001 YES PASS

TC_VANET_BC_BB_RSU_002 YES PASS

TC_VANET_BC_TI_GEN_001 YES PASS

TC_VANET_BC_TI_GEN_002 YES PASS

The validation activity for each test case included a detailed analysis of the messages exchanged between the SUUT and the tester and the verification that their sequence and their contents are compliant to the dynamic behaviour. To illustrate the process a detailed description of one test case is presented. The test case illustrated is TC_VANET_BC_BB_VEH_001. The goal of that test case is to verify beaconing adaptation to vehicle movement. Figure 35 shows ATS of this test case through UML diagram.

Figure 39. Beaconing validation sample: TC_VANET_BC _BB_VEH_001




The following figures show a complete trace of TC_VANET_BC_BB_VEH_001 test case execution together with the signalling exchange and operator actions. Beaconing functionality is implemented into a laptop which connects to the testing unit by a UDP/IP line. Test operator shows test execution logs and results by that testing unit.




Figure 40. Beaconing TC_VANET_BC_BB_VEH_001 test ex ecution (I)

UDP/IP

Configure Communication (UDP , Socket)

ACK

Switch on the SUUT and configure correct position

Communication established

Init Beaconing Test System

TESTER

Waiting for Beacon Message Headers

Beacon received (Position)

Beacon Message Header sent (Current Position {1 , 1})

Vehicle position: {1 ,1}

TEST OPERATOR




Figure 41. Beaconing TC_VANET_BC_BB_VEH_001 test ex ecution (II)

UDP/IP

TESTER

Waiting for Beacon Message Headers

Tester awaits a change in vehicle position

Beacon received (Position)

Test operator changes vehicle position from {1 , 1} to {2 , 2}

Vehicle position: {2 ,2}

Vehicle successfully changes its position from {1 , 1} to {2 , 2}

Beacon Message Header sent (Current Position {2 , 2})

TEST OPERATOR




Figure 42. Beaconing TC_VANET_BC_BB_VEH_001 test ex ecution (III)

UDP/IP

TESTER

Test Verdict: PASS!!

Finish beaconing Service

Release communication

ACK




5. Conclusions This deliverable is the result of applying the SAFESPOT Testing methodology described in [5] for beaconing functionality. The first phase of such a methodology is the definition of the Test Specification. The test purposes have been defined for vehicle and road side infrastructure mainly focused on conformance testing, and these tests are able to check the format of the beaconing message, the behaviour of the beaconing protocol when the vehicle is moving, e.g. speed modification, and even timing restrictions.

Next phase has been the implementation and validation of the conformance test system mock-up using the standardized test language TTCN-3. The TTCN-3 code is available on the SAFESPOT web site (http://bscw.safespot-eu.org/bscw/bscw.cgi/177787), and can be used for any SAFESPOT partner.

All test cases have been integrated and validated in the mock-up test system and are up and running. The validation has been done against a dummy beaconing application developed by AT4 wireless. The results of testing performed are successful and very promising. All of the test cases have been executed and a pass verdict has been obtained.

A potential enhancement of this mock-up would be to use a “real” SAFESPOT beaconing implementation from SINTECH with the aim of adapting the mock-up to the communication technologies used in SAFESPOT.




6. References [1] D3.3.4 – Vehicular Ad hoc Network Specification v1.1, SAFESPOT

SP3 SINTECH, 2007-11-19.

[2] D3.2.2 – User Needs and Requirements v1.0, SAFESPOT SP3

SINTECH, 2008-02-04.

[3] User Data Format & Messages v2.3, SAFESPOT SP7 SCORE,

2008-01-09.

[4] D3.4.2 – Implementation Plan v3.6, SAFESPOT SP3 SINTECH,

2008-02-04.

[5] D7.4.3 – SAFESPOT Certification reference framework – Part B

v1.0, SAFESPOT SP7 SCORE, 2008-04-24.

[6] ETSI EG 202 568 V1.1.3: (2007-04). “IP Testing; Methodology and

Framework”.

[7] ETSI SR 001 262 V2.0.0: (2004-07). “ETSI drafting rules”.

[8] ETSI ETS 300 406 ed.1: (1995-04): “Methods for Testing and

Specification (MTS); Protocol and profile conformance testing

specifications; Standardization methodology”.

[9] Requirements Catalogue for VANET – Beaconing v1.0, SAFESPOT

SP7 SCORE, 2008-04-02.

[10] ISO/IEC 9646-1: “Information Technology – Open Systems

Interconnection – Conformance testing methodology and framework

– Part 1: General concepts”.

[11] ISO/IEC 9646-2: “Information Technology – Open Systems

Interconnection – Conformance testing methodology and framework

– Part 2: Abstract Test Suite specification”.

[12] Test Suite Structure and Test Purpose for VANET – Beaconing v1.0,

SAFESPOT SP7 SCORE, 2008-04-08.




Appendix A – TTCN-3 Documentation Template The present appendix provides the template to document the Test Specification and TTCN-3 code.

1. Test Suite TTCN-3

1.1 Modules suite

# Built-in Types to be used: integer, float, boolean, verdicttype, objid, bitstring, hexstring, octetstring, charstring and universal charstring #

Name Module Name of the module.

Comments Description of module.

Type Either Definition or Control Module

Location To locate the *.ttcn file ( NameFile.ttcn )

1.2 Groups suite

# All groups to be described using the following Proforma #

Name Group < Name of the group >

Parameters < Description of group >


Comments < Comments >

1.3 Types suite

1.3.1 Simple types suite

# Built-in Types to be used: integer, float, boolean, verdicttype, objid, bitstring, hexstring, octetstring, charstring and universal charstring #

Name Definition Comments Group

< TypeName > < Definition Type > < Comments Type > Group Reference

Detailed Comments Several comments can be written here




1.3.2 Structured types suite

# Structured Types to be used: Record, Set and Union #

Name Name of the type.

Group Group Reference.

Comments Description of type.

Structure Identify the structure type: Record, Set or Union.

Field Name Field Type Comments

FieldIdentifier1 Type1 < Comments 1 >

FieldIdentifier2 Type2 < Comments 2 >


1.3.3 Enumerated types suite

# Enumerated Types to be used: Enumerated #




Enumeration Name Enumeration Value Comments

EnumerationIdentifier1 Value1 < Comments 1 >

EnumerationIdentifier2 Value2 < Comments 2 >


1.3.4 Ports types suite

# Port Types to be used: Port #



Communication Model < message or procedure >


Type / Signature Direction Comments

< MsgType1 > < in, out, inout > < Comments 1 >

< MsgType2 > < in, out, inout > < Comments 2 >





1.3.5 Components types suite

# Component Types to be used: Component #




Local Def Name Type Initial Value Comments

VarIdentifier1 < Type1> < Value1 > < Comments 1 >

VarIdentifier2 < Type 2 > < Value2 > < Comments 2 >

Port Name Port Type Comments

< PortIdentifier1 > < PortType1 > < Comments 1 >

< PortIdentifier2 > < PortType2 > < Comments 2 >


1.4 Constants suite

# All constants to be used will be described using the following Proforma #

Group Group Reference

Name Type Value Comments

< ConstIdentifier > < Type > < Value > < Comments >


1.5 templates suite

# Templates to be used: built types based on Structured Types #

Name < Name of the type >

Group < Group Reference >

Type Signature < Type Identifier >

Comments < Description of type >

Element Name Element Value Comments

< FieldReference1 > < FieldValue1 > < Comments 1 >

< FieldReference2 > < FieldValue2 > < Comments 2 >

Detailed Comments < Several comments can be written here




1.6 Test cases suite

# Add all the Test Cases description#

Name Test Case < Name of the test cases >

Test Purpose < Test Purpose >

Interface Part < Identify the component in the Interface Part >

Test System Part < Identify the component in the Test System Part >


Parameter Name Parameter Type Comments

< ParameterName > < ParameterType > < Comments 1 >




Appendix B – SAFESPOT Beaconing Test Specifications

B.1 Beaconing Requirement Catalogue The Requirements for Beaconing are distributed onto three groups:

• Beaconing Behaviour (BB). Those requirements are related to the general behaviour and messages exchanged over the external interface between RSU and Vehicle units.

• Timing (TI). Those requirements are related to time restrictions (delays, valid transmission intervals, etc.).

• Transmission Characteristics (TX). Those requirements are related to the channel transmission characteristics on which beacons are transmitted.

-----------------------------------------------------------------------------------------------------------------

Identifier: RQ_VANET_BC_BB_001_v10

Spec Clause: SP7 Data Format & Message – Section 2.1

Type: Mandatory

Applies to: Vehicles

Requirement: The general beacon message transmitted from Vehicle shall contain three basic data: Header, Payload and satellite data for positioning.

Spec Text:

‘ Vehicle-beacon ::= SEQUENCE {

header-V Header-V, satellitesData SatelliteRawData, payload MessagePayload-V }’

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory

Applies to: RSU

Requirement: The general beacon message transmitted from RSU shall contain three basic data: Header, Payload and satellite data for positioning.

Spec Text:

‘ RSU-beacon ::= SEQUENCE {

header-V Header-V, satellitesData SatelliteRawData, payload MessagePayload-V }’

-----------------------------------------------------------------------------------------------------------------



Type: Optional

Applies to: Vehicles

Requirement: Beacon messages transmitted from Vehicle shall agree with C2C version.

Spec Text:

‘Vehicle beacon is aligned, as much as possible, to C2C version.’




-----------------------------------------------------------------------------------------------------------------


Spec Clause: D3.4.2 – Section 3.3.1 (Version 3.6)

Type: Mandatory

Applies to: Vehicles and RSU

Requirement: Beacons message header for a vehicle or RSU beacon shall include the fields: Header version, Message type, Sequence number, node ID, node Type, Timestamp, Position, Position Variance, Node Speed, Beacon Period, Tx power and Priority.

Spec Text:

‘ ’

VEHICLE / RSU BEACON HEADER

Content Length (Byte)

headerVersion 1

messageType 1

sequenceNumber 2

nodeID 8

nodeType 1

Timestamp 6

Position 8 PositionVariance 2

nodeSpeed 2+2 Beacon period 1

txPower 1 Priority 1

-----------------------------------------------------------------------------------------------------------------


Spec Clause: D3.3.4 – Section 3.2.6

Type: Mandatory


Requirement: Beacons message header shall contain 36 bytes.

Spec Text:

See RQ_VANET_BC_BB_004_v10 Spec Text.

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: Beacons message header shall contain both packet information (packet type and priority) and basic node information (node identifier, position, timestamp, speed and heading).

Spec Text:

‘The header is divided into two sections:

• Packet information NL_PktInfo including packet type, priority and the length of the originator or forwarder secti on. • The basic node information NL_NodeInfo including the EGO node identifier, the own position, timestamp and the mov ing information speed.’

-----------------------------------------------------------------------------------------------------------------





Spec. Clause: D3.3.4 – Section 4.1

D3.3.4 – Section 3.3

Type: Mandatory


Requirement: Basic node information (node identifier, position, timestamp, speed and heading) of beacon message headers shall be filled with information of the own vehicle taken from the LDM.

Spec. Text:

‘The beacon header is filled with information of th e own vehicle. By default, this information is taken from the LDM’ extracted from D3.3.4 – Section 4.1. ‘The LDM Interface is described in the LDM specific ation deliverable D3.3.3. The VANET module will access the LDM Q-API to update header fields of the transmitted messages, especially the EGO information NL_NodeInfo’ extracted from D3.3.4 – Section 3.3.

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: MessageType field (Packet type) of beacon message header shall use the PT_BEACON value.

Spec Text:

‘The following settings are used: PT (Packet Type) • PT_BEACON, PRIO (Priority) • PRI_BEACON, NodeID • EGO, Routing • RT _BROADCAST.’

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: Priority field of beacon message header shall use the following value:

PRIO → PRI_BEACON.

Spec Text:


-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: Node ID field of beacon message header shall use the following value:

NodeID → EGO.

Spec Text:


-----------------------------------------------------------------------------------------------------------------






Type: Mandatory


Requirement: Transmission mode field (Routing) of beacon message header shall use the following value: Routing → RT_BROADCAST.

Spec Text:


-----------------------------------------------------------------------------------------------------------------


Spec Clause: Data Format & Message – Section 2.5

D3.4.2 – Section 3.3.1 (Version 3.6)

Type: Mandatory

Applies to: RSU

Requirement: NodeSpeed field for RSU beacon shall be filled to zero.

Spec Text:

‘ Header-V::= SEQUENCE {

... nodeSpeed speed /* defined as SAE: it includes speed

module and heading . Both set to 0 when the transmitter is an RSU */

... }’

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: The sequence number field shall increase for each beacon transmitted.

Spec Text:

‘The NL_PktInfo contains two fields to control the packet flow, i.e. a description of the transmission scheme to be used and a sequence number SeqNo, that is incremented for every transmi tted packet.’

-----------------------------------------------------------------------------------------------------------------

Identifier: RQ_VANET_BC_TI_001_v10

Spec Clause: D3.3.4 – Section 4.1

Type: Optional


Requirement: The beacon interval should be fixed. Eventually Congestion Control mechanism can change this parameter.

Spec Text:

‘The beacon interval BC_Interval normally is fixed, but might be changed occasionally under the control of the conge stion control algorithm.’

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory





Requirement: Beaconing shall use a timer to control the periodic transmissions of beacons.

Spec Text:

‘The beacon timer BC_Timer is used to control the p eriodic transmissions of the network layer beacons NL_BEACO N.’

-----------------------------------------------------------------------------------------------------------------



Type: Optional


Requirement: The time interval between beacon messages should be enclosed to the range [TBCmin. - TBCmax.].

Spec Text:

‘The time interval between NL beacons should not be less than TBCmin’. ‘The time interval between NL beacons should not ex ceed TBCmax’.

-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: Beaconing interval shall be fixed by configuration. Values between 0.5 and 2 seconds could be used.

Spec Text:

‘ ’ Parameter Expected Value Comments

Channel Control Channel Data Rate Min. available 3 Mbit/s Tx. Power Max available 100 mW

BC_INTERVAL Managed by CCA 1s [0.5 … 2] s Priority PRI_BEACON Tx. Mode 1-hop Broadcast

-----------------------------------------------------------------------------------------------------------------

Identifier: RQ_VANET_BC_TX_001_v10


Type: Mandatory


Requirement: Beacon messages shall always be transmitted on a specific Control Channel (the Safety Control Channel) at high priority.

Spec Text:

‘Network Layer Beacons will be transmitted on the S afety Control Channel. The originator of a High Priority Safety M essage will use the Safety Control Channel for transmitting this me ssage.’ -----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: Beaconing transmission mode shall be single hop broadcast.

Spec Text:




See RQ_VANET_BC_TI_004_v10 Spec Text.

-----------------------------------------------------------------------------------------------------------------



Type: Optional


Requirement: The minimum data rate for transmitting beacons messages shall be 3Mbit/s.

Spec Text:


-----------------------------------------------------------------------------------------------------------------



Type: Mandatory


Requirement: The maximum transmit power (EIRP) for beacons messages shall be 100 mW.

Spec Text:


-----------------------------------------------------------------------------------------------------------------




B.2. Beaconing ICS The Implementation Conformance Statement (ICS) has been divided into seven groups:

• Group 1: Role . Those ICSs allow selecting if the IUT has the role of a SF Vehicle or a SF RSU.

• Group 2: Specs . Those ICSs are related to the specifications that shall be agreed by the IUT.

• Group 3: Message format . Those ICSs are related to the data format that Beacon Message Headers shall agree.

• Group 4: General beaconing behaviour . Those ICSs are related to the general behaviour and messages exchanged over the external interface between RSU and Vehicle units.

• Group 5: Vehicles . Those ICSs are related only to SAFESPOT Vehicles.

• Group 6: RSU . Those ICSs are related only to SAFESPOT RSUs.

• Group 7: Timing . Those ICSs are related to time restrictions (delays, valid transmission intervals, etc.).

Table 12. Group 1: Role

Item Description Status Yes | No

1 Vehicle C.1

2 RSU C.1

Table 13. Group 2: Specs


1 D3.3.4 – Vehicular Ad hoc Network Specification v1.1, SAFESPOT SP3 SINTECH, 2007-11-19. M

2 D3.2.2 – User Needs and Requirements v1.0, SAFESPOT SP3 SINTECH, 2008-02-04. M

3 User Data Format & Messages v2.3, SAFESPOT SP7 SCORE, 2008-01-09. M

4 D3.4.2 – Implementation Plan v3.6, SAFESPOT SP3 SINTECH, 2008-02-04. M

Table 14. Group 3: Message format


1 Header Version. M

2 Message Type. M

3 Sequence Number. M

4 Node ID. M

5 Node Type. M

6 TimeStamp. M

7 Position. M

8 Position Variance. M




9 Speed. M

10 Beacon Period. M

11 Transmitted Power. M

12 Priority. M

Table 15. Group 4: General Beaconing Behaviour


1 BC transmissions over the Safety Control Channel. M

2 Single Hop Broadcast transmitting mode. M

3 Agree with C2C version. O

4 Provide a beaconing minimum data rate of 3Mbit/s. O

5 Increase the Sequence Number field. M

Table 16. Group 5: Vehicles


1 Adapt the Position field of vehicle Beacon Message Headers. C.1

2 Adapt the Speed field of vehicle Beacon Message Headers. C.1

Table 17. Group 6: RSU


1 Capacity to set the Position field of RSU Beacon Message Headers to a fixed value. C.1

2 Capacity to set the Speed field of RSU Beacon Message Headers to 0. C.1

Table 18. Group 7: Timing


1 Periodically transmissions of Beacons M

2 Possibility to use a timer to control beaconing transmissions. M

3 Possibility to change Beacon interval of Beacon Message Headers. O

4 Time interval between Beacon Message Headers should be

enclosed to the range [TBCmin. - TBCmax.].

O




B.3. Beaconing Test Purpose

The Test Purposes (TP) has been divided into two groups:

• Group 1: Beaconing Behaviour (BB). Those TPs are related to the general behaviour and messages exchanged over the external interface between RSU and Vehicle units.

o Group 1.1 : Those TPs are related to both SAFESPOT Vehicles and SAFESPOT RSU.

o Group 1.2 : Those TPs are related only to SAFESPOT Vehicles.

o Group 1.3 : Those TPs are related only to SAFESPOT RSU.

• Group 2: Timing (TI). Those TPs are related to time restrictions (delays, valid transmission intervals, etc.).

TP Id TP_VANET_BC_BB_GEN_001_v10

RQ Reference RQ_VANET_BC_BB_004_v10, RQ_VANET_BC_BB_005_v10

Role The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU.

Test Purpose

ensure that {

when { IUT sends a beacon message header }

then { the beacon message header contains the fields: Header version, Message type, Sequence number, node ID, node Type, Timestamp, Position, Position Variance, Node Speed, Beacon Period, Tx power and Priority and the beacon message header length is exactly 36 bytes }

}

Comments According to the latest version of the implementation plan document [4].

Fields are included into two general groups: Packet information (Packet type, priority) and basic Node information (node identifier, position, timestamp, speed and heading).


RQ Reference RQ_VANET_BC_BB_008_v10, RQ_VANET_BC_BB_009_v10,

RQ_VANET_BC_BB_010_v10, RQ_VANET_BC_BB_011_v10


Test Purpose

ensure that {


then { MessageType field of beacon message header is set to PT_BEACON

and Priority field is set to PRI_BEACON value

and Node ID field is set to EGO value

and Transmission mode field (Routing) is set to RT_BROADCAST value }

}

Comments





RQ Reference RQ_VANET_BC_BB_013_v10


Test Purpose

ensure that {

when { IUT sends a beacon message header containing SeqNo as the sequence number }

then { next beacon header sequence number is SeqNo+1 }

}

Comments SeqNo is the sequence number of the beacon message header.


RQ Reference RQ_VANET_BC_TX_004_v10


Test Purpose

ensure that {

when { IUT sends a beacon message header } containing TxPw as the transmitted power }

then { TxPw is between 0 and 100mW }

}

Comments TxPw is the current transmitted power.

TP Id TP_VANET_BC_BB_VEH_001_v10


Role The IUT is the beaconing functionality implemented in a SF Vehicle.

Test Purpose

with { IUT configured ‘with Position field value set to “POSITION_VEH“ ‘}

ensure that {

when { IUT sends a beacon message header

containing POSITION_VEH as the Position field value

and the vehicle position changes }

then { the Position field value adjusts to the new situation in movement }

}

Comments POSITION_VEH is the current position of the vehicle. The new situation in movement is that the car is going ahead or taking a curve.




Test Purpose

with { IUT configured ‘with Speed field value set to “VELOCITY_VEH“ ‘}

ensure that {

when { IUT sends a beacon message header containing VELOCITY_VEH as the nodeSpeed field value




and the vehicle speed changes }

then { the Speed field value adjusts to the new situation in movement }

}

Comments VELOCITY_VEH is the current velocity of the vehicle.

The new situation in movement is that the car accelerated, slow down or going in reverse.




Test Purpose

with { IUT configured ‘with Speed field value set to “0 “ ’

and ‘with Position field value set to “POSITION_VEH“ ‘

and SF Vehicle stopped }

ensure that {

when { IUT sends a beacon message header containing 0 as the nodeSpeed field value

and containing POSITION_VEH as the Position field value } then { next beacon message header Position field contains the same

POSITION_RSU

and next beacon message header nodeSpeed field is set to zero } }

Comments POSITION_VEH is the current position of the vehicle.

TP Id TP_VANET_BC_BB_RSU_001_v10


Role The IUT is the beaconing functionality implemented in a SF RSU.

Test Purpose

ensure that {


then { nodeSpeed field is set to zero }

}

Comments

TP Id TP_VANET_BC_BB_RSU_002_v10


Role The IUT is the beaconing functionality implemented in a SF RSU.

Test Purpose

with { IUT configured ‘with Position field value set to “POSITION_RSU“ ‘}

ensure that {


containing POSITION_RSU as the Position field value } then { the next beacon message header contains the same POSITION_RSU }

}

Comments POSITION_RSU is the current position of the SF RSU.




TP Id TP_VANET_BC_TI_GEN_001_v10

RQ Reference RQ_VANET_BC_TI_001_v10, RQ_VANET_BC_TI_002_v10,

RQ_VANET_BC_TI_003_v10, RQ_VANET_BC_TI_004_v10


Test Purpose

with { IUT configured ‘with Beacon period field value set to “TBC“ ‘}

ensure that {


containing TBC as the Beacon Period value

and TBC is not changed }

then { TBC is greater than 0.5 seconds

and TBC is less than 2 seconds and next beacon message header is sent in TBC seconds }

}

Comments TBC is the current beacon interval.

Allowed tolerance to be defined.

TP Id TP_VANET_BC_TI_GEN_002_v10

RQ Reference RQ_VANET_BC_TI_001_v10


Test Purpose

with { IUT configured ‘with Beacon period field value set to “TBC1“ ‘}

ensure that {


containing TBC1 as the Beacon Period value

and TBC1 is changed to TBC2 } then { current Beacon message header contains the same Beacon Period value

TBC1 and next Beacon message header contains TBC2 as the Beacon Period

value } }

Comments TBC1 is the previous beacon interval.

TBC2 is the new beacon interval.

Allowed tolerance to be defined.




B.4. Beaconing ATS Each Abstract Test Case (ATC) belongs to one of the following groups according to the reference Test Purpose (TP) used:

• Group 1: Beaconing Behaviour (BB). Those ATCs are related to the general behaviour and messages exchanged over the external interface between RSU and Vehicle units.

• Group 1.1 : Those ATCs are related to both SAFESPOT Vehicles and SAFESPOT RSU.

• Group 1.2 : Those ATCs are related only to SAFESPOT Vehicles.

• Group 1.3 : Those ATCs are related only to SAFESPOT RSU.

• Group 2: Timing (TI). Those ATCs are related to time restrictions (delays, valid transmission intervals, etc.).

Figure 43. TC_VANET_BC_BB_GEN_001










Figure 47. TC_VANET_BC_BB_VEH_001









Figure 50. TC_VANET_BC_BB_RSU_001

Figure 51. TC_VANET_BC_BB_RSU_002




Figure 52. TC_VANET_BC_TI_GEN_001




Figure 53. TC_VANET_BC_TI_GEN_002




Appendix C – Beaconing TTCN-3 Test Suite

Modules Suite

The modules which have been defined in the beaconing Test Suite are the following:

Name Module TestSuite

Comments Control Test Execution.

Type Control Module.

Location TestSuite.ttcn

Name Module mod_core_consts.

Comments Constants definition module.

Type Definition Module.

Location mod_core_consts.ttcn

Name Module mod_core_templates.

Comments Template definition module.


Location mod_core_templates.ttcn

Name Module mod_core_types

Comments Types definition module.


Location mod_core_types.ttcn

Name Module mod_functions.

Comments Function definition module.


Location mod_functions.ttcn

Name Module mod_module_parameters

Comments Module parameters definition module.


Location mod_module_parameters.ttcn

Name Module mod_test_cases

Comments Test cases definition module.


Location mod_test_cases.ttcn




According to the template, a global vision of the beaconing TTCN-3 Test Suite is shown in next figure.

Figure 54. Global Vision of the Beaconing TTCN-3 Te st Suite

Groups Suite

The groups which have been defined in the beaconing Test Suite are the following:

Name Group g_BC_GENERAL_BEHAVIOUR

Parameters Tempates related to general Beconing behaviour.


Comments

Name Group g_BC_VEHICULE_BEHAVIOUR

Parameters Templates related to vehicle beacons.


Comments

Name Group g_BC_RSU_BEHAVIOUR

Parameters Templates related to RSU beacons.


Comments

Name Group g_BC_TIMING

Parameters Templates related to timing procedures.

Location mod_core_template.ttcn

Comments




Types Suite

Simple Type Suite

The basic data types which have been defined in the beaconing Test Suite are the following:


dt_i_NIdent (0 ..2E64-1) OctetString

Detailed Comments Node ID type.


dt_i_LongType (-1440000000 .. +1440000000)

Integer

Detailed Comments Length type. Cover a range between (-90º , 90º).


dt_i_Sec (0 .. +4294967295) Unsigned Integer

Detailed Comments Seconds type.


dt_i_LatType (-720000000 .. +720000000)

Integer

Detailed Comments Latitude type. Cover a range between (-180º , 180º).


dt_i_BcPeriod (0.0 .. 12.75) Float

Detailed Comments Beacon Period type. Valid Beacon Period values are between 0.5 and 2.0.


dt_i_AccotedFields (0..255) Integer

Detailed Comments Header version, Position Variance X and Position Variance Y type.


dt_i_SeqNbrs (0..65535) Integer

Detailed Comments Sequence Number type.





dt_i_Module (-327.68 .. 327.67) Float

Detailed Comments Module type.


dt_i_Power (0 .. 31) Integer

Detailed Comments Transmitted power type. Cover a range between (0..31) dBm.

Structured Type Suite

The structured data types which have been defined in the beaconing Test Suite are the following:

Name dt_r_TSTp

Group

Comments Time Stamp type.

Structure Record


a_i_seconds dt_i_Sec Seconds type.

a_i_miliseconds dt_i_SeqNbrs Miliseconds type.

Detailed Comments Seconds field uses 32 bits.

Miliseconds field uses 16 bits.

Name dt_r_Spd

Group

Comments Speed type.

Structure Record


a_i_Direction dt_i_SeqNbrs Direction type.

a_i_Module dt_i_Module Module type.

Detailed Comments Valid Speed Module range is between -327.68 and 327.67 m/s

Name dt_r_Pos

Group

Comments Position type.

Structure Record


a_i_Longitude dt_i_LongType Length type.

a_i_Latitude dt_i_LatType Latitude type.

Detailed Comments




Name dt_r_PosVar

Group

Comments Position variance Type.

Structure Record


a_i_PosVarx dt_i_AccotedFields Position variance X type.

a_i_PosVary dt_i_AccotedFields Position variance Y type.

Detailed Comments

Name dt_r_TxPw

Group

Comments Transmitted Power type.

Structure Record


a_i_Power dt_i_Power Power type.

a_e_Antenna dt_e_AntennaType Antenna type.

Detailed Comments Allowed transmitted power cover the range between (0..31) dBm.

Name dt_r_BcHeader

Group

Comments Beacon Message Header type.

Structure Record


a_ut_HeadVer dt_i_AccotedFields Header Version field.

a_ut_MsgType dt_e_MsgTpe Message Type field.

a_ut_SqnNbr dt_i_SeqNbrs Sequence Number field.

a_i_NodeID dt_i_NIdent Node ID field.

a_ut_NodeType dt_e_NTpe Node Type field.

a_r_TmpStmp dt_r_TSTp Time Stamp field.,

a_ut_Position dt_r_Pos Position field.

a_ut_PositionVar dt_r_PosVar Position Variance field.

a_ut_Speed dt_r_Spd Speed field.

a_ut_Period dt_i_BcPeriod Beacon Period field.

a_e_Priority dt_e_PriorityTpe Priority field.

a_r_TxPower dt_r_TxPw Transmitted Power field.

Detailed Comments Complete Beacon Message Header.




Enumerated Type Suite

The enumerated data types which have been defined in the beaconing Test Suite are the following:

Name dt_e_MsgTpe

Group

Comments Message type.


e_Unknown 0

e_Beacon 1 Beacon Message Type.

e_Awareness_Cooperative 2

e_Emergence 3

e_Event 4

e_Periodic 5

e_HMIEvent 6

e_HMIPeriodic 7

e_CVISBeacon 8

Detailed Comments Valid message type value for Beaconing is “e_beacon”.

Name dt_e_NTpe

Group

Comments Node type.


e_Unknown 0

e_VehicleType 1 Vehicle Beacon Message Header.

e_RSUType 2 RSU Beacon Message Header.

Detailed Comments Node type value must be set to “e_VehicleType” or “e_RSUType”.

Name dt_e_PriorityTpe

Group

Comments Priority type.


e_UnknownPri 0

e_BeaconPri 1 Beacon priority.

e_EmergencyPri 2

e_HighPri 3

e_MediumPri 4

e_LowPri 5

Detailed Comments Beacon priority field must be set to “e_BeaconPri” for correct beaconing behaviour.




Port Type Suite

The port type which has been defined in the beaconing Test Suite is the following:

Name tpt_m_BcHeaderPDU

Group

Communication Model Message.

Comments Port used for Beacon Message Header transactions.

Type / Signature Direction Comments

dt_r_BcHeader inout

Detailed Comments

Component Type Suite

The components type which have been defined in the beaconing Test Suite are the following:

Name tcp_tsi_IUT

Group

Comments TSI port.



pt_tsiBcPDU tpt_m_BcHeaderPDU

Detailed Comments

Name tcp_mtc_LT

Group

Comments Lower Tester port.



pt_mtcBcPDU tpt_m_BcHeaderPDU

Detailed Comments




Constants Suite

The constants which have been defined in the beaconing Test Suite are the following:

Group

Name Type Value Comments

C_PT_BEACON dt_e_MsgTpe e_Beacon Message type.

C_EGO dt_i_NIdent '000000000000FFFF' O

Node ID type.

C_PRI_BEACON dt_e_PriorityTpe e_BeaconPri Priority type.

C_VALID_SEQ_NBR dt_i_SeqNbrs 1000 Sequence Number type.

C_NODE_TYPE dt_e_NTpe e_VehicleType Node type.

C_STOP dt_r_Spd {0 , 0.0} Speed type.

Detailed Comments

Structured Templates Suite The templates which have been defined in the beaconing Test Suite are the following:

Name mw_AnyBcHeader

Group g_BC_GENERAL_BEHAVIOUR

Type Signature dt_r_BcHeader

Comments


a_ut_HeadVer ? Header Version field.

a_ut_MsgType ? Message Type field.

a_ut_SqnNbr ? Sequence Number field.

a_i_NodeID ? Node ID field.

a_ut_NodeType ? Node Type field.

a_r_TmpStmp ? Time Stamp field.

a_ut_Position ? Position field.

a_ut_PositionVar ? Position variance field.

a_ut_Speed ? Speed field.

a_ut_Period ? Beacon Period field.

a_e_Priority ? Priority field.

a_r_TxPower ? Transmitted Power field.

Detailed Comments Template represents any Beacon Message Header.




Name mw_ValidBcHeader



Comments



a_ut_MsgType v_MT Message Type field.


a_i_NodeID v_NI Node ID field.







a_e_Priority v_PT Priority field.



v_MT dt_e_MsgTpe Must be set to C_PT_BEACON.

v_NI dt_i_NIdent Node ID value.

v_PT dt_e_PriorityTpe Must be set to C_PRI_BEACON

Detailed Comments Template represents any valid Beacon Message Header.




Name mw_NextSequenceNbr



Comments



a_ut_MsgType C_PT_BEACON Message Type field.

a_ut_SqnNbr v_SN Sequence Number field.








a_e_Priority C_PRI_BEACON Priority field.




v_SN dt_i_SeqNbrs Value represents the previous Sequence Number value.

Detailed Comments Template is used to check the correct sequence Number behaviour.




Name mw_TxPowerCheck



Comments













a_r_TxPower { (0..20) , ? } Transmitted Power field.



Detailed Comments Template is used to check Transmitted Power value and Antenna kind.




Name mw_Position

Group g_BC_VEHICLE_BEHAVIOUR


Comments






a_ut_NodeType v_NT Node Type field.


a_ut_Position v_P Position field.








v_NT dt_e_NTpe Must be set to “e_VehicleType”

v_P dt_r_Pos Vehicoe Position.

Detailed Comments Template is used to check correct Vehicle Position behaviour.




Name mw_PositionRSU

Group g_BC_RSU_BEHAVIOUR


Comments










a_ut_Speed C_SPEED_0 Speed field.






v_NT dt_e_NTpe Must be set to “e_RSUType”

v_P dt_r_Pos RSU position value.

Detailed Comments Template is used to check RSU Position.




Name mw_Velocity



Comments










a_ut_Speed v_SP Speed field.






v_NT dt_e_NTpe Vehicle OR RSU Node Type.

v_SP dt_r_Spd Vehicle speed.

Detailed Comments Template is used in the Speed check of Vehicle Beacon Test Cases.




Name mw_StopSituation



Comments










a_ut_Speed v_SP Speed field.






v_NT dt_e_NTpe Must be set to “e_VehicleType”

v_SP dt_r_Spd Speed value.

v_P dt_r_Pos Position value.

Detailed Comments Template is used to check the state of repose of vehicles.




Name mw_ValidPeriod

Group g_BC_TIMING


Comments











a_ut_Period (0.5 .. 2.0) Beacon Period field. Valid range is (0,5..2) sec. 1LSB = 50 msec.).





Detailed Comments Template is used to check the correct timing procedures.




Name mw_InitValidBcHeader

Group


Comments


a_ut_HeadVer 0 Header Version field.

a_ut_MsgType e_Beacon Message Type field.

a_ut_SqnNbr 0 Sequence Number field.

a_i_NodeID 0 Node ID field.

a_ut_NodeType e_VehicleType Node Type field.

a_r_TmpStmp {0,0} Time Stamp field.

a_ut_Position {0,0} Position field.

a_ut_PositionVar {0,0} Position variance field.

a_ut_Speed {0,0.0} Speed field.

a_ut_Period 1.0 Beacon Period field. Valid range is (0,5..2) sec. 1LSB = 50 msec.).

a_e_Priority e_BeaconPri Priority field.

a_r_TxPower {0,e_UnknownAnt} Transmitted Power field.



Detailed Comments Template is used to initialize Beacon Message headers to valid values

Test Cases Suite

The test cases which have been defined in the beaconing Test Suite are the following:

Name Test Case TC_BB_GEN_001

Test Purpose

IUT sends a Beacon Message Header.

LT checks if the message has all the required fields and the total size of the message is 36 bytes.

Interface Part tcp_mtc_LT

Test System Part tcp_tsi_IUT



t_CtrlTimer float Timer to control timeouts.





Test Purpose

IUT sends a Beacon Message Header.

LT checks if the Message Type, Node ID and Priority fields are adequately configured.






v_NoID dt_i_NIdent Node ID.


Test Purpose

IUT sends a Beacon Message Header containing the value “SEQ” in the Sequence Number field.

IUT sends other Beacon Message Header.

LT checks if the new Sequence Number value is “SEQ+1”.








Test Purpose

IUT sends a Beacon Message Header containing a specific value in the transmitted power field.

LT checks if the Transmitted Power value is between 0 and 100 mW.










Name Test Case TC_BB_VEH_001

Test Purpose

Upper Tester configures IUT Position field to “POSITION_VEH”.

IUT sends a Beacon Message Header with “POSITION_VEH” as the value of the Position field.

UT changes the Position field and IUT sends a new Beacon Message Header containing the new value (“NEW_POSITION”) in the Position field.






v_NoID dt_i_NIdent Node ID

v_PositionVeh dt_r_Pos Vehicle position.

v_NewPositionVeh dt_r_Pos New Vehicle position.


Test Purpose

Upper Tester configures IUT Speed field to “VELOCITY_VEH”.

IUT sends a Beacon Message Header with “VELOCITY_VEH” as the value of the Speed field.

UT changes the Speed field and IUT sends a new Beacon Message Header containing the new value (“NEW_VELOCITY”) in the Speed field.







v_VelocityVeh dt_r_Spd Vehicle Speed.

v_NewVelocityVeh dt_r_Spd New vehicle speed.





Test Purpose

Upper Tester configures IUT Position field to “POSITION_VEH” and Speed field to “0”.

IUT sends a Beacon Message Header with “POSITION_VEH” as the value of the Position field and “0” as the value of the Speed field.

Next Beacon Message Header contains the Speed field set to 0 and the same value in the Position field.







Name Test Case TC_BB_RSU_001

Test Purpose IUT sends a Beacon Message Header to the LT.

LT checks if the Speed field of the received message is set to “0”.







Name Test Case TC_BB_RSU_002

Test Purpose

Upper Tester configures IUT Position field to “POSITION_RSU”.

IUT sends a Beacon Message Header with “POSITION_RSU” as the value of the Position field.

Next Beacon Message Header contains the Position field set to the same value.







v_PositionRSU dt_r_Pos RSU position.




Name Test Case TC_TI_GEN_001

Test Purpose

Upper Tester configures IUT Period field to “TBC”.

IUT sends a Beacon Message Header with “TBC” as the value of the Period field.

Next Beacon Message Header must be sent within “TBC” seconds after the first message.

The allowed tolerance is set to 10%.







v_Tolerance float Allowed tolerance.

Name Test Case TC_TI_GEN_002

Test Purpose

Upper Tester configures IUT Period field to “TBC2”.

IUT sends a Beacon Message Header with “TBC2” as the value of the Period field.

Next Beacon Message Header must be sent within “TBC2” seconds after the previous message.

The allowed tolerance is set to 10%.







v_Tolerance float Allowed tolerance.




Appendix D – Detailed MSC Test Cases

MSC diagrams are based on Test Configuration described in section 3.3 and consist of three basic actions, test system initialization, test case behaviour and closing phase.

Table 19. MSC - TC_VANET_BC_BB_GEN_001

TC ID: TC_VANET_BC_BB_GEN_001

Test Purpose: To verify correct Beacon Message Header format and size.

SUUT TE CD TRI

TRI

SA/PA

TCI TTCN-3

T C I

triSAReset() Configure(UDP, Socket )

triPAReset() Configure(Timers )

sendTo(BcHeader) recvFrom(BcHeader)

triEnqueueMsg tciDecode

BcHeader := { HeadVer := ? MsgType := ? SeqNbr := ? NodeID := ? NodeType := ? TimeStamp := ? Position := ? PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := ? }

pt_mtcBcPDU.recv

verdict(PASS)

close(Socket) Release_comm.

TEST SYSTEM INITIALIZATION

TEST CASE BEHAVIOUR

CLOSE PHASE

Decode Bc.

Header

Start Bc. Service






Test Purpose: To verify correct configuration settings for a Beacon Message Header.

SUUT TE CD TRI

TRI

SA/PA

TCI TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := ? TimeStamp := ? Position := ? PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE

Decode Bc.

Header

Start Bc. Service






Test Purpose: To verify the Sequence Number behaviour.

SUUT TE CD TRI

TRI

SA/PA

Header TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := SEQ NodeID := EGO NodeType := ? TimeStamp := ? Position := ? PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := SEQ+1 NodeID := EGO NodeType := ? TimeStamp := ? Position := ? PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

Decode Bc.

Header

Decode Bc.

Header

Start Bc. Service






Test Purpose: To verify that the transmitted poweris in the valid range.

SUUT TE CD TRI

TRI

SA/PA

TCI TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := ? TimeStamp := ? Position := ? PositionVar := ? Speed := ? Period := ? TxPower : = TxPW Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)

CLOSE PHASE


Decode Bc.

Header

Start Bc. Service




Table 23. MSC - TC_VANET_BC_BB_VEH_001

TC ID: TC_VANET_BC_BB_VEH_001

Test Purpose: To verify beaconing adaptation to vehicle movement.

SUUT TE CD TRI

TRI

SA/PA

TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := VEHICLE TimeStamp := ? Position := POS_VEH PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE


triEnqueueMsg

tciDecode

BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := VEHICLE TimeStamp := ? Position := NEW_POS PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

sendTo(BcHeader)

sendTo(BcHeader)

.

.

.

N

Decode Bc.

Header

Decode Bc.

Start Bc. Service

Change Config.






Test Purpose: To verify beaconing adaptation to changes in vehicle speed.

SUUT TE CD TRI

TRI

SA/PA

TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := VEHICLE TimeStamp := ? Position := ? PositionVar := ? Speed := SPD_VEH Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := VEHICLE TimeStamp := ? Position := ? PositionVar := ? Speed := NEW_SPD Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

sendTo(BcHeader)

sendTo(BcHeader)

.

.

.

N

Decode Bc.

Header

Decode Bc.

Header

Start Bc. Service

Change Config.






Test Purpose: To verify beaconing adaptation when the SF vehicle is stopped.

SUUT TE CD TRI

TRI

SA/PA

TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := VEHICLE TimeStamp := ? Position := POS_VEH PositionVar := ? Speed := “0” Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE


triEnqueueMsg

tciDecode

BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := VEHICLE TimeStamp := ? Position := POS_VEH PositionVar := ? Speed := “0” Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

Decode Bc.

Header

Decode Bc.

Header

Start Bc. Service




Table 26. MSC - TC_VANET_BC_BB_RSU_001

TC ID: TC_VANET_BC_BB_RSU_001

Test Purpose: To verify correct operation of RSU Beacon Message header Speed field.

SUUT TE CD TRI

TRI

SA/PA

TCI TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := RSU TimeStamp := ? Position := ? PositionVar := ? Speed := “0” Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)

CLOSE PHASE


Decode Bc.

Header

Start Bc. Service




Table 27. MSC - TC_VANET_BC_BB_RSU_002

TC ID: TC_VANET_BC_BB_RSU_002

Test Purpose: To verify correct operation of RSU Beacon Message header Position field.

SUUT TE CD TRI

TRI

SA/PA

TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := RSU TimeStamp := ? Position := POS_RSU PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE


triEnqueueMsg

tciDecode

BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := RSU TimeStamp := ? Position := POS_RSU PositionVar := ? Speed := ? Period := ? TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

Decode Bc.

Header

Decode Bc.

Header

Start Bc. Service




Table 28. MSC - TC_VANET_BC_TI_GEN_001

TC ID: TC_VANET_BC_TI_GEN_001

Test Purpose: To verify the correct Beaconing Interval performance.

SUUT TE CD TRI

TRI

SA/PA

TTCN-3

T C I



BcHeader := { HeadVer := ? MsgType := PT_BEACON SeqNbr := ? NodeID := EGO NodeType := ? TimeStamp := ? Position := ? PositionVar := ? Speed := ? Period := TBC TxPower : = ? Priority := PRI_BEACON

}

pt_mtcBcPDU.recv

verdict(PASS)


CLOSE PHASE


triEnqueueMsg

tciDecode


}

pt_mtcBcPDU.recv

timer.Start(TBC)

timer.Timeout

Decode Bc.

Header

Decode Bc.

Header

Start Bc. Service

TBC seconds




Table 29. MSC - TC_VANET_BC_TI_GEN_002

TC ID: TC_VANET_BC_TI_GEN_002

Test Purpose: To verify the correct procedure changing the Beacon Period.

SUUT TE CD TRI

TRI

SA/PA

TTCN-3

T C I




}

pt_mtcBcPDU.recv

verdict(PASS)


sendTo(BcHeader)

sendTo(BcHeader)

.

.

.

N

TEST CASE BEHAVIOUR [TC_VANET_BC_TI_GEN_001 (BcHeader.Period := NEW_TBC)]

CLOSE PHASE

Decode Bc.

Header

Start Bc. Service

Change Config.

Documents

SP7 – SCORE – SAFESPOT Core Architecture Conformance & … · 2010-10-26 · SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 9 of 109 SCORE EXECUTIVE SUMMARY This deliverable