SAFESPOT INTEGRATED PROJECT - IST IP DELIVERABLE. SP7 SCORE SAFESPOT Core Architecture

Transcription

1 SAFESPOT INTEGRATED PROJECT - IST IP DELIVERABLE SP7 SCORE SAFESPOT Core Architecture Conformance & Interoperability Test System Mock-up Ready 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) Status (F: final; D: draft; RD: revised draft): Main Authors: A. Plaza, F.J. Nuñez, J. Baños (AT4 wireless) 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 1 of 109 SCORE

2 Revision Log Version Date Reason Name and Company First Draft Introducing Test System A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) Added TL entity and Annexes. Revised test system A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) Validation procedure Annexes Complete version A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) Final Version after Peer Review EU reviewers from 3 rd review meeting included A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) A. Plaza, F J. Nuñez, J. Baños (AT4 wireless) SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 2 of 109 SCORE

3 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 ) 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 3 of 109 SCORE

4 SA SCORE SINTECH SP SUT SUUT T3RTS TCI TCP TCRL TE TL TP TRI TS TSI TSS TTCN-3 TTL UDP UML V2I V2V VANET WP System Adaptor SAFESPOT CORE architecture SAFESPOT Innovative Technologies Sub Project System Under Test SAFESPOT Unit Under Test TTCN-3 RunTime System TTCN-3 Control Interface Transport Control Protocol Test Case Reference List TTCN-3 Executable Test Logging Test Purpose TTCN-3 RunTime Interface Test Suite Test System Interface Test Suite Structure Testing and Test Control Notation Telematic Test Laboratory User Data Protocol Unified Modelling Language Vehicle to Infrastructure Vehicle to Vehicle Vehicle Ad Hoc Network Work Package SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 4 of 109 SCORE

5 Table of contents Revision Log... 2 Abbreviation List... 3 Table of contents... 5 List of Figures... 7 List of Tables... 8 EXECUTIVE SUMMARY Introduction Contribution to the SAFESPOT Objectives Methodology Deliverable Structure Beaconing SAFESPOT Test Specification Introduction Beaconing Functionality Requirement Catalogue PICS Test Suite Structure and Test Purposes Abstract Test Suite SAFESPOT Test System Mock-up Introduction Test Management SAFESPOT TTCN-3 Test Executable TTCN-3 Test Configuration SAFESPOT TTCN-3 Test Suite TTCN-3 Test Cases Parameter List SAFESPOT Test System Adaptor System Adaptor (SA) Platform Adaptor (PA) CODECS (CD) LOGS TTCN-3 Test System Development SAFESPOT Test System Validation Introduction Interface Requirements Reference Implementations Description of the API Using the dummy application Validation Procedure Starting test manager PICS filling by test operator General parameters filling by test operator Test cases selection to be run Test case execution Test results Beaconing Validation Conclusions References Appendix A TTCN-3 Documentation Template SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 5 of 109 SCORE

6 Appendix B SAFESPOT Beaconing Test Specifications 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 Modules Suite...78 Groups Suite...79 Types Suite...80 Simple Type Suite Structured Type Suite Enumerated Type Suite Port Type Suite Component Type Suite Constants Suite...85 Structured Templates Suite...85 Test Cases Suite...94 Appendix D Detailed MSC Test Cases SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 6 of 109 SCORE

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

8 List of Tables Table 1. Test Case Parameters Table 2. TTCN-3 and TRI correlation Table 3. Beaconing Framework Table 4. Extended logging events Table 5. List of Test Cases implemented Table 6. startbeaconing function description Table 7. setbeaconingparameter function description Table 8. stopbeaconing function description Table 9. TBeacon parameters description Table 10. TServerConf parameters description Table 11. List of validated test cases Table 12. Group 1: Role Table 13. Group 2: Specs Table 14. Group 3: Message format Table 15. Group 4: General Beaconing Behaviour Table 16. Group 5: Vehicles Table 17. Group 6: RSU Table 18. Group 7: Timing Table 19. MSC - TC_VANET_BC_BB_GEN_ Table 20. MSC - TC_VANET_BC_BB_GEN_ Table 21. MSC - TC_VANET_BC_BB_GEN_ Table 22. MSC - TC_VANET_BC_BB_GEN_ Table 23. MSC - TC_VANET_BC_BB_VEH_ Table 24. MSC - TC_VANET_BC_BB_VEH_ Table 25. MSC - TC_VANET_BC_BB_VEH_ Table 26. MSC - TC_VANET_BC_BB_RSU_ Table 27. MSC - TC_VANET_BC_BB_RSU_ Table 28. MSC - TC_VANET_BC_TI_GEN_ Table 29. MSC - TC_VANET_BC_TI_GEN_ SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 8 of 109 SCORE

9 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 ( 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 Mockup. 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 9 of 109 SCORE

10 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 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 10 of 109 SCORE

11 SAFESPOT Architecture Phase 1: Elements to be tested / Certified Beaconing Specifications Phase 2: SAFESPOT Test Specification Beaconing Implementations Beaconing Test Specifications Phase 3: Beaconing Test System 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 11 of 109 SCORE

12 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 Specifications 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: D 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. D 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 12 of 109 SCORE

13 Specifications document is available on SAFESPOT web site ( 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 13 of 109 SCORE

14 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 14 of 109 SCORE

15 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 15 of 109 SCORE

16 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 16 of 109 SCORE

17 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 17 of 109 SCORE

18 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 18 of 109 SCORE

19 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 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 Configuration 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 19 of 109 SCORE

20 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 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 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 The whole description of all the types, components, ports, etc. of this Test Suite are described in Appendix C 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 20 of 109 SCORE

21 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. TC_BB_GEN_002 TC_BB_GEN_003 TC_BB_GEN_004 t_ctrltimer float X.y seconds Timer to control timeouts. v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh Node ID. t_ctrltimer float X.y seconds Timer to control timeouts. v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh Node ID. t_ctrltimer float X.y seconds Timer to control timeouts. v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh Node ID. t_ctrltimer float X.y seconds Timer to control timeouts. TC_BB_VEH_001 v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh Node ID. v_positionveh dr_r_pos {X º, Yº} Vehicle position. v_newpositionve h dt_r_pos {X º, Yº} v_newpositionveh t_ctrltimer float X.y seconds t_ctrltimer TC_BB_VEH_002 v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh v_noid v_velocityveh dt_r_spd {X.y m/s, X} v_velocityveh v_newvelocityve h dt_r_spd {X.y m/s, X} v_newvelocityveh TC_BB_VEH_003 TC_BB_RSU_001 t_ctrltimer float X.y seconds t_ctrltimer v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh v_noid t_ctrltimer float X.y seconds t_ctrltimer v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh v_noid t_ctrltimer float X.y seconds t_ctrltimer TC_BB_RSU_002 v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh v_noid v_positionrsu dt_r_pos {X º, Yº} v_positionrsu t_ctrltimer float X.y seconds t_ctrltimer TC_TI_GEN_001 v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh v_noid v_tolerance float X.y % v_tolerance t_ctrltimer float X.y seconds t_ctrltimer TC_TI_GEN_002 v_noid dt_i_nident 0xhhhhhhhhhhhhhhhh v_noid v_tolerance float X.y % v_tolerance SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 21 of 109 SCORE

22 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 System Adaptor (SA) This section focuses on describing SA subsystem onto the TTCN-3 Test System Architecture. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 22 of 109 SCORE

23 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 23 of 109 SCORE

24 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 Send Receive Start to execute a test case TRI Operation Name trisend trienqueuemessage 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 p, 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 24 of 109 SCORE

25 Figure 14. Conventional and virtual tester 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 25 of 109 SCORE

26 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 CODECS (CD) This section focuses on describing CODECS subsystem onto the TTCN-3 Test System Architecture. Figure 17. CODECS into TTCN-3 Test System SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 26 of 109 SCORE

27 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 and 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]. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 27 of 109 SCORE

28 BEACON MESSAGE HEADER bytes 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 28 of 109 SCORE

29 Figure 20. Decoder subsystem 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 29 of 109 SCORE

30 Figure 21. Lower decoder architecture for beaconing 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 30 of 109 SCORE

31 TTCN-3 Context Native (C) Context 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 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 Figure 22. Upper decoder for Beaconing LOGS This section focuses on describing logging subsystem onto the TTCN-3 Test System Architecture. Figure 23. Test logging entity SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 31 of 109 SCORE

32 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 32 of 109 SCORE

33 Traces are shown here 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 33 of 109 SCORE

34 Next table shows the complete list of extended logs: Event Test Case started Test Case verdict Timer started Timer stopped Timer timeout Message received Template match begin Template match end Template match result Template match failed Logs TTCN-3 Component started Table 4. Extended logging events Parameters shown Name of the Test Case Verdict(pass,fail,inconc,none) Timer name and duration Timer name Timer name Port, length and value of each field Template name Template name Successful or Fail Template result, template value Logs generated in the test Suite with the log statement Component name Alternative entered Alternative left Port mapped Port unmapped Both ports name Both ports name Test execution info. Extended test execution logs Received beacon value Figure 26. Extended logs SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 34 of 109 SCORE

35 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 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 mockup must be connected to a reference system under test. 1 Adaptors in SAFESPOT mock-up are coding in C language. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 35 of 109 SCORE

36 Figure 27. Test System Components Integration SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 36 of 109 SCORE

37 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 TC_VANET_BC_BB_GEN_001 TC_VANET_BC_BB_GEN_002 TC_VANET_BC_BB_GEN_003 TC_VANET_BC_BB_GEN_004 TC_VANET_BC_BB_VEH_001 TC_VANET_BC_BB_VEH_002 TC_VANET_BC_BB_VEH_003 TC_VANET_BC_BB_RSU_001 TC_VANET_BC_BB_RSU_002 TC_VANET_BC_TI_GEN_001 TC_VANET_BC_TI_GEN_002 Test purpose To verify correct Beacon Message Header format and size. To verify correct configuration settings for a Beacon Message Header. To verify the Sequence Number behaviour. To verify that the transmitted is in the valid range. To verify beaconing adaptation to vehicle movement. To verify beaconing adaptation to changes in vehicle speed. To verify beaconing adaptation when the SF vehicle is stopped. To verify correct operation of RSU Beacon Message header Speed field. To verify correct operation of RSU Beacon Message header Position field. To verify the correct Beaconing Interval performance. 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 37 of 109 SCORE

38 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 38 of 109 SCORE

39 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 39 of 109 SCORE

40 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. int stopbeaconing( void ); Table 8. stopbeaconing function description 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 beaconperiod msgtype nodeid Nodetype priority pos nodespeed Txpower Description It is the period of time between two beacons. The unit is seconds. 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]. It is the Node Identifier. The format selected is hexadecimal following the structure XX:XX:XX:XX:XX:XX:XX:XX 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]. 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]. It is the position of the vehicle. This position is defined using the longitude and the latitude. It is the speed of the node defined as a module and a direction. 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: SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 40 of 109 SCORE

41 Parameter ipaddress port Table 10. TServerConf parameters description Description It contains the IP address of the destination. It contains the UDP port of the destination 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 41 of 109 SCORE

42 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 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 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. SAFESPOT Figure 30. Test manager Technology manager SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 42 of 109 SCORE

43 The work on this aspect has been to include SAFESPOT into the technology database of Test Manager 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 and does not apply to the selected configuration (SCR red flag) because PIC 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 43 of 109 SCORE

44 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 44 of 109 SCORE

45 Figure 34. Test manager General parameters detailed 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 45 of 109 SCORE

46 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 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 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 46 of 109 SCORE

47 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 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 47 of 109 SCORE

48 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_GEN_002 YES PASS TC_VANET_BC_BB_GEN_003 YES PASS TC_VANET_BC_BB_GEN_004 YES PASS TC_VANET_BC_BB_VEH_001 YES PASS TC_VANET_BC_BB_VEH_002 YES PASS TC_VANET_BC_BB_VEH_003 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 48 of 109 SCORE

49 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. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 49 of 109 SCORE

50 TESTER TEST OPERATOR UDP/IP Configure Communication (UDP, Socket) ACK Switch on the SUUT and configure correct position Init Beaconing Test System Communication established Waiting for Beacon Message Headers Beacon Message Header sent (Current Position {1, 1}) Beacon received Vehicle position: {1,1} Figure 40. Beaconing TC_VANET_BC_BB_VEH_001 test execution (I) SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 50 of 109 SCORE

51 TESTER TEST OPERATOR UDP/IP Waiting for Beacon Message Headers Tester awaits a change in vehicle position Test operator changes vehicle position from {1, 1} to {2, 2} Beacon Message Header sent (Current Position {2, 2}) Beacon received Vehicle position: {2,2} Vehicle successfully changes its position from {1, 1} to {2, 2} Figure 41. Beaconing TC_VANET_BC_BB_VEH_001 test execution (II) SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 51 of 109 SCORE

52 TESTER UDP/IP Release communication Finish beaconing Service ACK Test Verdict: PASS!! Figure 42. Beaconing TC_VANET_BC_BB_VEH_001 test execution (III) SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 52 of 109 SCORE

53 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 ( 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 mockup to the communication technologies used in SAFESPOT. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 53 of 109 SCORE

54 6. References [1] D3.3.4 Vehicular Ad hoc Network Specification v1.1, SAFESPOT SP3 SINTECH, [2] D3.2.2 User Needs and Requirements v1.0, SAFESPOT SP3 SINTECH, [3] User Data Format & Messages v2.3, SAFESPOT SP7 SCORE, [4] D3.4.2 Implementation Plan v3.6, SAFESPOT SP3 SINTECH, [5] D7.4.3 SAFESPOT Certification reference framework Part B v1.0, SAFESPOT SP7 SCORE, [6] ETSI EG V1.1.3: ( ). IP Testing; Methodology and Framework. [7] ETSI SR V2.0.0: ( ). ETSI drafting rules. [8] ETSI ETS ed.1: ( ): 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, [10] ISO/IEC : Information Technology Open Systems Interconnection Conformance testing methodology and framework Part 1: General concepts. [11] ISO/IEC : 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, SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 54 of 109 SCORE

55 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 Modules suite # Built-in Types to be used: integer, float, boolean, verdicttype, objid, bitstring, hexstring, octetstring, charstring and universal charstring # Name Module Comments Type Name of the module. Description of module. 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 > Location To locate the *.ttcn file ( NameFile.ttcn ) Comments < Comments > 1.3 Types suite 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 55 of 109 SCORE

56 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 > Detailed Comments Several comments can be written here Enumerated types suite # Enumerated Types to be used: Enumerated # Name Name of the type. Group Group Reference. Comments Description of type. Enumeration Name Enumeration Value Comments EnumerationIdentifier1 Value1 < Comments 1 > EnumerationIdentifier2 Value2 < Comments 2 > Detailed Comments Several comments can be written here Ports types suite # Port Types to be used: Port # Name Name of the type. Group Group Reference. Communication Model < message or procedure > Comments Description of type. Type / Signature Direction Comments < MsgType1 > < in, out, inout > < Comments 1 > < MsgType2 > < in, out, inout > < Comments 2 > Detailed Comments Several comments can be written here SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 56 of 109 SCORE

57 1.3.5 Components types suite # Component Types to be used: Component # Name Name of the type. Group Group Reference. Comments Description of type. 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 > Detailed Comments Several comments can be written here 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 > Detailed Comments Several comments can be written here 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 57 of 109 SCORE

58 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 > Location To locate the *.ttcn file ( NameFile.ttcn ) Parameter Name Parameter Type Comments < ParameterName > < ParameterType > < Comments 1 > SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 58 of 109 SCORE

59 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: Applies to: Requirement: Spec Text: Mandatory Vehicles The general beacon message transmitted from Vehicle shall contain three basic data: Header, Payload and satellite data for positioning. Vehicle-beacon ::= SEQUENCE { header-v Header-V, satellitesdata SatelliteRawData, payload MessagePayload-V } Identifier: RQ_VANET_BC_BB_002_v10 Spec Clause: SP7 Data Format & Message Section 2.1 Type: Applies to: Requirement: Spec Text: Mandatory RSU The general beacon message transmitted from RSU shall contain three basic data: Header, Payload and satellite data for positioning. RSU-beacon ::= SEQUENCE { header-v Header-V, satellitesdata SatelliteRawData, payload MessagePayload-V } Identifier: RQ_VANET_BC_BB_003_v10 Spec Clause: SP7 Data Format & Message Section 2.1 Type: Applies to: Requirement: Spec Text: Optional Vehicles Beacon messages transmitted from Vehicle shall agree with C2C version. Vehicle beacon is aligned, as much as possible, to C2C version. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 59 of 109 SCORE

60 Identifier: RQ_VANET_BC_BB_004_v10 Spec Clause: D3.4.2 Section (Version 3.6) Type: Mandatory Applies to: Requirement: Spec Text: Vehicles and RSU 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. 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 Identifier: RQ_VANET_BC_BB_005_v10 Spec Clause: D3.3.4 Section Type: Applies to: Requirement: Spec Text: Mandatory See RQ_VANET_BC_BB_004_v10 Spec Text. Vehicles and RSU Beacons message header shall contain 36 bytes Identifier: RQ_VANET_BC_BB_006_v10 Spec Clause: D3.3.4 Section Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU Beacons message header shall contain both packet information (packet type and priority) and basic node information (node identifier, position, timestamp, speed and heading). The header is divided into two sections: Packet information NL_PktInfo including packet type, priority and the length of the originator or forwarder section. The basic node information NL_NodeInfo including the EGO node identifier, the own position, timestamp and the moving information speed SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 60 of 109 SCORE

61 Identifier: RQ_VANET_BC_BB_007_v10 Spec. Clause: D3.3.4 Section 4.1 D3.3.4 Section 3.3 Type: Applies to: Requirement: Mandatory Vehicles and RSU 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 the 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 specification deliverable D 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 Identifier: RQ_VANET_BC_BB_008_v10 Spec Clause: D3.3.4 Section Type: Mandatory Applies to: Requirement: Spec Text: Vehicles and RSU MessageType field (Packet type) of beacon message header shall use the PT_BEACON value. The following settings are used: PT (Packet Type) PT_BEACON, PRIO (Priority) PRI_BEACON, NodeID EGO, Routing RT_BROADCAST Identifier: RQ_VANET_BC_BB_009_v10 Spec Clause: D3.3.4 Section Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU Priority field of beacon message header shall use the following value: PRIO PRI_BEACON. See RQ_VANET_BC_BB_008_v10 Spec Text Identifier: RQ_VANET_BC_BB_010_v10 Spec Clause: D3.3.4 Section Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU Node ID field of beacon message header shall use the following value: NodeID EGO. See RQ_VANET_BC_BB_008_v10 Spec Text SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 61 of 109 SCORE

62 Identifier: RQ_VANET_BC_BB_011_v10 Spec Clause: D3.3.4 Section Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU See RQ_VANET_BC_BB_008_v10 Spec Text. Transmission mode field (Routing) of beacon message header shall use the following value: Routing RT_BROADCAST Identifier: RQ_VANET_BC_BB_012_v10 Spec Clause: Data Format & Message Section 2.5 Type: Applies to: Requirement: Spec Text: D3.4.2 Section (Version 3.6) Mandatory Header-V::= SEQUENCE {... nodespeed RSU NodeSpeed field for RSU beacon shall be filled to zero. speed /* defined as SAE: it includes speed module and heading. Both set to 0 when the transmitter is an RSU */... } Identifier: RQ_VANET_BC_BB_013_v10 Spec Clause: D3.3.4 Section Type: Mandatory Applies to: Requirement: Spec Text: Vehicles and RSU The sequence number field shall increase for each beacon transmitted. 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 transmitted packet Identifier: RQ_VANET_BC_TI_001_v10 Spec Clause: D3.3.4 Section 4.1 Type: Applies to: Requirement: Spec Text: Optional Vehicles and RSU The beacon interval should be fixed. Eventually Congestion Control mechanism can change this parameter. The beacon interval BC_Interval normally is fixed, but might be changed occasionally under the control of the congestion control algorithm Identifier: RQ_VANET_BC_TI_002_v10 Spec Clause: D3.3.4 Section 4.1 Type: Applies to: Mandatory Vehicles and RSU SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 62 of 109 SCORE

63 Requirement: Spec Text: Beaconing shall use a timer to control the periodic transmissions of beacons. The beacon timer BC_Timer is used to control the periodic transmissions of the network layer beacons NL_BEACON Identifier: RQ_VANET_BC_TI_003_v10 Spec Clause: D3.2.2 Section 2.1 Type: Applies to: Requirement: Spec Text: Optional Vehicles and RSU The time interval between beacon messages should be enclosed to the range [TBCmin. - TBCmax.]. The time interval between NL beacons should not be less than TBCmin. The time interval between NL beacons should not exceed TBCmax Identifier: RQ_VANET_BC_TI_004_v10 Spec Clause: D3.3.4 Section 4.1 Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU Beaconing interval shall be fixed by configuration. Values between 0.5 and 2 seconds could be used. 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 Spec Clause: D3.2.2 Section 2.1 Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU Beacon messages shall always be transmitted on a specific Control Channel (the Safety Control Channel) at high priority. Network Layer Beacons will be transmitted on the Safety Control Channel. The originator of a High Priority Safety Message will use the Safety Control Channel for transmitting this message Identifier: RQ_VANET_BC_TX_002_v10 Spec Clause: D3.3.4 Section 4.1 Type: Applies to: Requirement: Spec Text: Mandatory Vehicles and RSU Beaconing transmission mode shall be single hop broadcast. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 63 of 109 SCORE

64 See RQ_VANET_BC_TI_004_v10 Spec Text Identifier: RQ_VANET_BC_TX_003_v10 Spec Clause: D3.3.4 Section 4.1 Type: Applies to: Requirement: Spec Text: Optional Vehicles and RSU See RQ_VANET_BC_TI_004_v10 Spec Text. The minimum data rate for transmitting beacons messages shall be 3Mbit/s Identifier: RQ_VANET_BC_TX_004_v10 Spec Clause: D3.3.4 Section 4.1 Type: Mandatory Applies to: Vehicles and RSU Requirement: The maximum transmit power (EIRP) for beacons messages shall be 100 mw. Spec Text: See RQ_VANET_BC_TI_004_v10 Spec Text SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 64 of 109 SCORE

65 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 Item Description Status Yes No D3.3.4 Vehicular Ad hoc Network Specification v1.1, SAFESPOT SP3 SINTECH, D3.2.2 User Needs and Requirements v1.0, SAFESPOT SP3 SINTECH, User Data Format & Messages v2.3, SAFESPOT SP7 SCORE, D3.4.2 Implementation Plan v3.6, SAFESPOT SP3 SINTECH, M M M M Table 14. Group 3: Message format Item Description Status Yes No 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 65 of 109 SCORE

66 9 Speed. M 10 Beacon Period. M 11 Transmitted Power. M 12 Priority. M Table 15. Group 4: General Beaconing Behaviour Item Description Status Yes No 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 Item Description Status Yes No 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 Item Description Status Yes No 1 2 Capacity to set the Position field of RSU Beacon Message Headers to a fixed value. Capacity to set the Speed field of RSU Beacon Message Headers to 0. C.1 C.1 Table 18. Group 7: Timing Item Description Status Yes No 1 Periodically transmissions of Beacons M 2 Possibility to use a timer to control beaconing transmissions. M 3 4 Possibility to change Beacon interval of Beacon Message Headers. Time interval between Beacon Message Headers should be enclosed to the range [TBCmin. - TBCmax.]. O O SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 66 of 109 SCORE

67 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 RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_GEN_001_v10 RQ_VANET_BC_BB_004_v10, RQ_VANET_BC_BB_005_v10 The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU. 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 } } 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). TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_GEN_002_v10 RQ_VANET_BC_BB_008_v10, RQ_VANET_BC_BB_009_v10, RQ_VANET_BC_BB_010_v10, RQ_VANET_BC_BB_011_v10 The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU. ensure that { when { IUT sends a beacon message header } 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 } SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 67 of 109 SCORE

68 TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_GEN_003_v10 RQ_VANET_BC_BB_013_v10 The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU. ensure that { when { IUT sends a beacon message header containing SeqNo as the sequence number } then { next beacon header sequence number is SeqNo+1 } } SeqNo is the sequence number of the beacon message header. TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_GEN_004_v10 RQ_VANET_BC_TX_004_v10 The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU. ensure that { when { IUT sends a beacon message header } containing TxPw as the transmitted power } then { TxPw is between 0 and 100mW } } TxPw is the current transmitted power. TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_VEH_001_v10 RQ_VANET_BC_BB_007_v10 The IUT is the beaconing functionality implemented in a SF Vehicle. 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 } } 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. TP Id RQ Reference Role Test Purpose TP_VANET_BC_BB_VEH_002_v10 RQ_VANET_BC_BB_007_v10 The IUT is the beaconing functionality implemented in a SF Vehicle. 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 68 of 109 SCORE

69 Comments } and the vehicle speed changes } then { the Speed field value adjusts to the new situation in movement } 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. TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_VEH_003_v10 RQ_VANET_BC_BB_007_v10 The IUT is the beaconing functionality implemented in a SF Vehicle. 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 } } POSITION_VEH is the current position of the vehicle. TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_RSU_001_v10 RQ_VANET_BC_BB_012_v10 The IUT is the beaconing functionality implemented in a SF RSU. ensure that { when { IUT sends a beacon message header } then { nodespeed field is set to zero } } TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_BB_RSU_002_v10 RQ_VANET_BC_BB_012_v10 The IUT is the beaconing functionality implemented in a SF RSU. with { IUT configured with Position field value set to POSITION_RSU } ensure that { when { IUT sends a beacon message header containing POSITION_RSU as the Position field value } then { the next beacon message header contains the same POSITION_RSU } } POSITION_RSU is the current position of the SF RSU. SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 69 of 109 SCORE

70 TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_TI_GEN_001_v10 RQ_VANET_BC_TI_001_v10, RQ_VANET_BC_TI_002_v10, RQ_VANET_BC_TI_003_v10, RQ_VANET_BC_TI_004_v10 The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU. with { IUT configured with Beacon period field value set to TBC } ensure that { when { IUT sends a beacon message header 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 } } TBC is the current beacon interval. Allowed tolerance to be defined. TP Id RQ Reference Role Test Purpose Comments TP_VANET_BC_TI_GEN_002_v10 RQ_VANET_BC_TI_001_v10 The IUT is the beaconing functionality implemented in a SF Vehicle or in a SF RSU. with { IUT configured with Beacon period field value set to TBC1 } ensure that { when { IUT sends a beacon message header containing TBC1 as the Beacon Period value and TBC1 is changed to TBC2 } then { current Beacon message header contains the same Beacon Period TBC1 and next Beacon message header contains TBC2 as the Beacon value } } TBC1 is the previous beacon interval. TBC2 is the new beacon interval. Allowed tolerance to be defined. value Period SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 70 of 109 SCORE

71 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 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 71 of 109 SCORE

72 Figure 44. TC_VANET_BC_BB_GEN_002 Figure 45. TC_VANET_BC_BB_GEN_003 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 72 of 109 SCORE

73 Figure 46. TC_VANET_BC_BB_GEN_004 Figure 47. TC_VANET_BC_BB_VEH_001 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 73 of 109 SCORE

74 Figure 48. TC_VANET_BC_BB_VEH_002 Figure 49. TC_VANET_BC_BB_VEH_003 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 74 of 109 SCORE

75 Figure 50. TC_VANET_BC_BB_RSU_001 Figure 51. TC_VANET_BC_BB_RSU_002 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 75 of 109 SCORE

76 Figure 52. TC_VANET_BC_TI_GEN_001 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 76 of 109 SCORE

77 Figure 53. TC_VANET_BC_TI_GEN_002 SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 77 of 109 SCORE

78 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 Comments Type Location TestSuite Control Test Execution. Control Module. TestSuite.ttcn Name Module Comments Type Location mod_core_consts. Constants definition module. Definition Module. mod_core_consts.ttcn Name Module Comments Type Location Name Module Comments Type Location mod_core_templates. Template definition module. Definition Module. mod_core_templates.ttcn mod_core_types Types definition module. Definition Module. mod_core_types.ttcn Name Module Comments Type Location mod_functions. Function definition module. Definition Module. mod_functions.ttcn Name Module Comments Type Location mod_module_parameters Module parameters definition module. Definition Module. mod_module_parameters.ttcn Name Module Comments Type Location mod_test_cases Test cases definition module. Definition Module. mod_test_cases.ttcn SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 78 of 109 SCORE

79 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 Test Suite Groups Suite The groups which have been defined in the beaconing Test Suite are the following: Name Group Parameters Location Comments g_bc_general_behaviour Tempates related to general Beconing behaviour. mod_core_templates.ttcn Name Group Parameters Location Comments g_bc_vehicule_behaviour Templates related to vehicle beacons. mod_core_templates.ttcn Name Group Parameters Location Comments g_bc_rsu_behaviour Templates related to RSU beacons. mod_core_templates.ttcn Name Group Parameters Location Comments g_bc_timing Templates related to timing procedures. mod_core_template.ttcn SF_D7.4.4_C&I Test System Mock-up_v1.1.doc Page 79 of 109 SCORE