WO2023232471A1

WO2023232471A1 - Perception service test mode in intelligent transport systems

Info

Publication number: WO2023232471A1
Application number: PCT/EP2023/063221
Authority: WO
Inventors: Brice Le Houerou; Isabelle Morvan; Eric Nassor; Hervé Ruellan; Benjamin GALMICHE; Gérald Kergourlay
Original assignee: Canon Kabushiki Kaisha; Canon Europe Limited
Priority date: 2022-05-31
Filing date: 2023-05-17
Publication date: 2023-12-07
Also published as: GB2619325A; GB202208074D0

Abstract

According to some embodiments of the disclosure, it is provided a method of communication in an intelligent transport system, ITS, comprising at an ITS station, ITS-S, under test, SUT, receiving a request to obtain data from at least one component of the SUT, the received request comprising an item of information enabling selection of at least one component of the SUT, selecting at least one component of the SUT as a function of the received item of information, and obtaining data from the at least one selected component, and transmitting an ITS message comprising the obtained data.

Description

PERCEPTION SERVICE TEST MODE IN INTELLIGENT TRANSPORT SYSTEMS

FIELD OF THE DISCLOSURE

The present disclosure relates generally to Intelligent Transport Systems (ITS) and more specifically to Cooperative Intelligent Transport Systems (C-ITS).

BACKGROUND OF THE DISCLOSURE

Cooperative Intelligent Transport Systems (C-ITS) is an emerging technology for future transportation management that aims at improving road safety, traffic efficiency, and driver experience.

Intelligent Transport Systems (ITS), as defined by the European Telecommunications Standards Institute (ETSI), include various types of communication such as: communications between vehicles (e.g. car-to-car) and communications between vehicles and fixed locations (e.g. car-to-infrastructure).

C-ITSs are not restricted to road transport as such. More generally, C-ITS may be defined as the use of information and communication technologies (ICT) for rail, water and air transport, including navigation systems. Such various types of C-ITS rely on radio services for communication and use dedicated technologies.

Cooperation within C-ITS is achieved by exchange of messages, referred as to ITS messages, among ITS stations (denoted ITS-Ss). The ITS-Ss may be vehicles, Road Side Units (RSUs), Vulnerable Road Users (VRUs) carrying an ITS equipment (for instance included in a smartphone, a GPS, a smart watch, or in a cyclist equipment), or any other entities or infrastructures equipped with an ITS equipment, as well as central subsystems (back-end systems and traffic management centers).

C-ITS may support various types of communications, for instance between vehicles (vehicle-to-vehicle or “V2V”), referring to all kinds of road users, e.g. car-to-car, or between vehicles and fixed locations such as vehicle-to-infrastructure or “V2I”, and infrastructure-to-vehicle or “12V”, e.g., car-to-infrastructure.

Such message exchanges may be performed via a wireless network, referred to as “V2X” (for “vehicle” to any kind of devices) networks, examples of which may include 3GPP LTE- Advanced Pro, 3GPP 5G, or IEEE 802.11p technology.

Exemplary ITS messages include Collective Perception Messages (CPMs), Cooperative Awareness Messages (CAMs), and Decentralized Environmental Notification Messages (DENMs). The ITS-S sending an ITS message is named “originating” ITS-S and the ITS-S receiving an ITS message is named “receiving” ITS-S.

ITS messages are often broadcast. They are generally not encrypted. However, for security reasons, they can be emitted only by authorized ITS stations. The authorization is implemented through a certificate, known as an Authorization Ticket (AT) generated through an operational certificate chain, which AT defines authorization for one or more operational ITS services.

A Public Key Infrastructure (PKI) mechanism is implemented to provide anonymity to the ITS stations within an ITS communication system.

The ITS message and the corresponding authorization ticket are electronically signed, before being broadcast. The AT may be provided together with the broadcast ITS message, or may be provided before or after the broadcasting. The ITS message refers to the AT, for the receiving ITS station to be able to check the whole package.

The Collective Perception Service described in the ETSI TR 103 562 standard enables ITS stations to share information about their perceived environment with other nearby ITS stations using CPM ITS messages. Typically, a CPM contains object attributes and kinematics perceived by on-board sensors, information about the used sensor, and free space areas perceived by on-board sensors.

In a C-ITS communication system, a Test Mode Service makes it possible to conduct some tests, in particular to verify conformance regarding the ITS protocol stack implementation as well as to monitor the transmission and reception parameters. The Test Mode Service enables the identification of non-working and damaged components that are essential for ITS communication, using the test mode message set. The Test Mode Service defined in ETSI TR 103573 V1.1.1 (2019-11) makes it possible to verify Radio Frequency (RF) and functional requirements of the ITS protocol communications.

While these mechanisms have proven to be efficient, there is a constant need to improve monitoring of the proper behavior of the ITS Stations and to control the reliability of the CPM data in C-ITS.

SUMMARY OF THE DISCLOSURE

The present disclosure has been devised to address one or more of the foregoing concerns.

According to a first aspect of the disclosure, there is provided a method of communication in an intelligent transport system, ITS, comprising at an ITS station, ITS-S, under test, SUT: receiving a request to obtain data from at least one component of the SUT, the received request comprising an item of information enabling selection of at least one component of the SUT, selecting at least one component of the SUT as a function of the received item of information and obtaining data from the at least one selected component, and transmitting an ITS message comprising the obtained data.

Accordingly, the method of the disclosure makes it possible to obtain data from specific sensors of an ITS station, enabling a test system having some knowledge of the ITS station environment to detect a malfunction of the ITS station. Such a perception test request - response process may be part of more global detection means used to identify erroneous sensors in ITS stations, that may lead to trigger reporting of a Report message to a certification authority in order to revoke the Authorization Tickets used by the erroneous ITS station. Therefore, such a method is an additional mechanism to detect erroneous sensors, that participates to improve the global quality in the ITS messages that contribute to improving the safety of the road users.

The transmitted ITS message may be signed. The signature may indicate that the ITS message is sent in response to a request to obtain data from at least one component of the SUT. The transmitted ITS message may be a CPM. The transmitted ITS message may be a broadcast unencrypted message.

According to some embodiments, the at least one selected component comprises at least one sensor.

Still according to some embodiments, the obtained data comprise measurements acquired by the at least one sensor and/or data derived from measurements acquired by the at least one sensor.

Still according to some embodiments, the at least one selected component comprises at least one fusion sensor.

Still according to some embodiments, the method further comprises transmitting a response message, the response message comprising an item of information describing the at least one component of the SUT, used to obtain the data transmitted in the ITS message.

According to a second aspect of the disclosure, there is provided a method of communication in an intelligent transport system, ITS, comprising at an ITS station, ITS-S, used to test an ITS-S under test, SUT: identifying at least one component to test of the SUT, transmitting a request to obtain data from the at least one identified component, the transmitted request comprising an item of information enabling selection of at least one component of the SUT, and receiving an ITS message, the received ITS message comprising requested data enabling to detect a malfunction of the at least one identified component.

This aspect of the disclosure has advantages similar to those mentioned above.

According to some embodiments, the at least one identified component is identified from a description of a set of components of the SUT, the description being received in a previous ITS message.

Still according to some embodiments, the method further comprises activating a test mode.

Still according to some embodiments, the method further comprises comparing the received requested data with expected data.

Still according to some embodiments, the method further comprises generating a test result report.

Still according to some embodiments, the method further comprises receiving a response message, the response message comprising an item of information describing at least one component of the SUT, used to obtain the received requested data.

According to another aspect of the disclosure, there is provided a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in an Intelligent Transport System station, ITS-S, causes the ITS-S to perform each step of the method described above.

This aspect of the disclosure has advantages similar to those mentioned above.

At least parts of the methods according to the disclosure may be computer implemented. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present disclosure may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the solutions of the present disclosure can be implemented in software, the solutions of the present disclosure can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages of the present disclosure will become apparent to those skilled in the art upon examination of the drawings and detailed description. Embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings.

Figure 1 illustrates an example of ITS in which embodiments of the disclosure may be implemented;

Figure 2 illustrates security mechanisms implemented in an ITS;

Figure 3 illustrates the verification of a received ITS message based on a digital signature and an authorization ticket;

Figure 4 illustrates an example of a flow of messages exchanged during a perception test sequence according to a first embodiment;

Figure 5 illustrates an example of a flow of messages exchanged during a perception test sequence according to a second embodiment;

Figure 6 illustrates an example of a message format of a CPM Test Request;

Figure 7 illustrates an example of a message format of a CPM Test Response;

Figure 8 illustrates an example of a message format of a Collective Perception Message;

Figure 9 illustrates, using a flowchart, an example of operations at a Test System to generate a test request;

Figure 10 illustrates, using a flowchart, an example of operations at an ITS station under test to process a test request received from a Dedicated Test System;

Figure 11 illustrates, using a flowchart, an example of operations at a Dedicated Test System to process a test response; and

Figure 12 illustrates an example of a communication device, configured to implement at least one embodiment of the present disclosure.

The same references are used across different drawings when designating the same elements.

DETAILED DESCRIPTION

It has been observed that the quality of the Collective Perception Service depends on the correctness of captured information by local sensors (e.g. cameras, radars, and/or LIDARs), data processing, objects detection, objects classification, and CPM generation by concerned ITS stations. It has also been observed that degraded images may result in wrong or missed ITS message generation (pre-crash DENM, VRU CPM, etc.) impacting the benefit of ITS and resulting in wrong (unsafe) decisions. The inventors have determined that it is necessary to monitor the proper behavior of the sensors and the reliability of the data obtained from the sensors in real conditions and disseminated over CPM.

Accordingly, to ensure proper operation of the ITS stations, the disclosure makes it possible to monitor the proper behavior of the sensors and the reliability of the data obtained from the sensors in real conditions.

To that end, a test request and response mechanism is disclosed, enabling an ITS Dedicated Test System (DTS) to obtain specific data from selected sensors of a System Under Test (SUT), enabling the DTS to compare the data obtained from the SUT with expected data (i.e. knowledge of the DTS about the SUT environment), thus enabling the DTS to detect a malfunction within (or of the selected sensor of) the SUT.

According to some embodiments of the disclosure, a Perception Test Request is generated in a test system and transmitted to a SUT having a Collective Perception Service (i.e. the SUT may transmit CPM ITS messages). This Perception Test Request advantageously comprises a list of selected sensors that the SUT may use to perceive objects in an area known by the DTS. The SUT should then provide a response to the Perception Test Request with a report containing data regarding perceived objects and status information of the requested areas. The DTS may then analyze the response content to determine whether the SUT is correctly perceiving objects.

In order to determine whether the SUT is correctly perceiving objects, the SUT should limit its perception to the sensors selected by the DTS (that are indicated in the test request). Such sensors may be selected according to identifiers, types, ranges, positions, field- of-views, or any field as defined in the CPM Sensor Information Container.

Under such test conditions, the SUT advantageously transmit CPM(s) using a different signature than the ones used under normal operation. In addition, under such test conditions, the SUT should transmit CPM(s) in response to the corresponding request(s), without considering inclusion rules defined in the standard for normal operations (which may result in a non-transmission of perceived objects to the DTS).

The disclosure will now be described by means of specific non-limiting exemplary embodiments and by reference to the drawings.

It is recalled here that ITS messages are generally not encrypted when exchanged during V2X communications. However, the integrity of ITS messages can be verified as a digital signature is provided by the sending ITS station. This signature is based on digital certificates owned by the originating station. For this purpose, each station receives one or more certificates through a Public Key Infrastructure (PKI). These certificates aim at ensuring that the originating ITS station has the privilege or authorization to transmit specific ITS messages. Privacy is ensured within the PKI mechanism thanks to the two following principles:

- pseudonymity ensuring that an ITS station may use a resource or service without disclosing its identity but can still be accountable for that use; and

- unlinkability ensuring that the greater the distance in time and space between two transmissions from a same device, the harder it is to determine that those two transmissions did in fact come from the same device.

To that end, the ITS stations are provisioned with a set of Pseudonym Certificates referred to as authorization tickets (AT) delivered by a certification authority. Thus, when exchanging ITS messages within the ITS network, each ITS message, made of an unencrypted message, is accompanied with a given AT and the above digital signature that validate the authenticity of the transmitting ITS station and the integrity of the message. The anonymity of the transmitting ITS station is ensured because each AT is associated with a pseudonym, also called ITS identifier, used by the ITS station to communicate within the ITS.

Besides, ATs are regularly changed according to a temporal AT change strategy performed by each ITS station. Therefore, as the change of AT causes the change of the pseudonym and the digital signature used by the station, a regular change of AT over time makes the tracking by the receiving stations very difficult or impossible, in a classic operating mode of the ITS. Indeed, the stations of the ITS (the vehicles or the vulnerable road users VRU) may share their current state (such as their position, speed, acceleration, etc.) using a Cooperative Awareness Message (CAM), for example as defined in the ETSI EN 302 637-2, (or VRU Awareness Messages (VAM), for example as ETSI TR 103 300). Such messages are received by the receiving ITS stations and help them to analyze their local environment.

Figure 1 illustrates an example of ITS in which embodiments of the disclosure may be implemented.

As illustrated, ITS 100 comprises a plurality of fixed and mobile ITS stations, in particular an ITS station of fixed road side entity 110, mobile ITS stations (or on-board units (OBUs)) associated with vehicles 120 and 130, mobile ITS station (or OBU) embedded within mobile phone 140, and central-ITS Station 180. An ITS station embedded within a vehicle is referred to as a ‘vehicle ITS station’ and an ITS station carried by a pedestrian or a cyclist is referred to as ‘VRU (Vulnerable Road User) ITS station’. As illustrated, fixed road side entity 110 contains a road side unit (RSU) 111 also having a roadside ITS station. The central-ITS station 180, is an example of central subsystem that may also form part of ITS 100. Other subsystems (not shown), such as back-end systems and traffic management centers, may also form parts of ITS 100.

Version V1.1.1 of the ETSI EN 302 665 specification defines a reference architecture of an ITS station. An ITS station may embed or may be linked to one or more local sensors that may provide information about the ITS station position and/or motion or analyze or scan an area in the vicinity of the ITS station to detect objects.

For the sake of illustration, vehicle 120 embeds perception sensors 125a and 125b, vehicle 130 embeds perception sensors 135a, 135b, and 135c, and mobile phone 140 embeds perception sensor 145. Perception sensors 125a, 125b, 135a, 135b, 135c, and 145, referred to as embedded perception sensors, may be of different types, for example they may be cameras, radars, radios, or LIDARs, that can be combined (e.g., a vehicle may embed several cameras and several LIDARs). For the sake of illustration, perception sensors 125a and 125b may be video cameras monitoring areas 126a and 126b, respectively. The output of the embedded perception sensors may be a list of perceived objects and corresponding description items of information.

Similarly, fixed road side entity 110 embeds a Roadside Surveillance Monitoring System (RSMS) 112. RSMS 112 includes in particular a set of perception sensors, for example video cameras 115a and 115b monitoring area 118 and a Video Content Analytics (VGA) module (not represented). VGA modules may analyze video streams captured by the video cameras 115a and/or 115b in order to detect objects, referred to as perceived objects, to monitor the state of areas, referred to as free spaces, and to output lists of detect objects and/or of free spaces with corresponding description information. It is noted that since RSMS 112 and RSU 111 may be connected through wires, RSMS 112 may be considered as an embedded perception sensor for RSU 111.

Description information of a perceived object may include its dynamic state and properties (for instance a position, a speed, an acceleration, a class, a dimension, an age, etc.). Description information of a free space may include its state and its geometry (for instance a confidence level that the space is free or a state of the space as well as a description of the geometry of the free space).

Cooperation within ITS 100 may be achieved through exchange of ITS messages between the ITS stations: V2V (vehicle-to-vehicle) messages, V2I (vehicle-to-infrastructure) messages, and/or I2V (infrastructure-to-vehicle) messages. Various types of ITS messages exist to share information, alert, inform, and/or warn users and/or vehicles of ITS 100. As illustrated, an ITS message like ITS message 150 comprises a header 151 (including multiple fields) and a payload 152. Such an ITS message may be accompanied with a Pseudonym Certificate, for example Pseudonym Certificate 160, and a digital signature, for example digital signature 170.

There exist several types of ITS messages, in particular the following:

- Cooperative Awareness Message (CAM), for example as defined in the version 1.3.1 of the ETSI EN 302 637-2 specification, that may be sent by any originating vehicle ITS station to share information about itself with the other ITS stations, for instance its current state (e.g. position, speed, length, width, and angle). A CAM may be sent by a corresponding operational service (or application) in the facility layer of the ITS protocol stack of the ITS station, namely the Cooperative Awareness basic service,

- Vulnerable Road User Awareness Message (VAM), for example as defined in version 2.1.1 of ETSI TS 103 300-3 specification, that may be sent by any originating VRU ITS station to share information about itself with the other ITS stations, for instance its current state (e.g. position, speed, length, width, and angle),

- Decentralized Environmental Notification Message (DENM), that may sent by an originating ITS station to alert receiving ITS stations of an event. A DENM is sent by a corresponding operational service in the facility layer of the ITS protocol stack of the ITS station, namely the Decentralized Environmental Notification basic service, and

- Collective Perception Message (CPM) for example as defined in the version 2.1.1 of the ETSI TR 103 562 specification and/or in the version 0.0.22 of the ETSI TS 103 324 specification, that may be sent by any originating ITS station to share its perceived environment retrieved from its embedded perception sensors with receiving ITS stations. A CPM is sent by a corresponding operational service in the facility layer of the ITS protocol stack of the ITS station, namely the Collective Perception basic service.

All exchanged messages may be encoded using for example the ASN.1 Unaligned Packed Encoding Rules as defined in Recommendation ITU-T X691/ISO/IEV 8825-2.

To secure V2X communications within ITS 100, a Public-Key-Infrastructure (PKI) (for example as defined in the version 1.1.1 of the ETSI TS 102 731 specification) may be used to enable a receiving station to make some verification to trust the originating ITS station. As described above, the PKI-based security may be implemented through the use of certificates delivered by a certification authority to the ITS stations. Accordingly, each ITS message comprises a non-encrypted message (e.g. ITS message 150) accompanied with a digital signature (e.g. digital signature 170) and a Pseudonym Certificate (e.g. a Pseudonym Certificate 160) that validate the authenticity of the originating ITS station and the integrity of the message, while keeping anonymity of the originating ITS station. The digital signature 170 may be computed (e.g. as the result of a hash function) from the corresponding ITS message 150 and the corresponding Pseudonym Certificate 160 (e.g. on a concatenation thereof). The Pseudonym Certificate 160 may be delivered by a certification authority. Such a certificate may be referred to as an authorization ticket. It ensures that the originating ITS station has the privileges and authorizations to transmit specific ITS messages. The authorization ticket may be verified by the receiving ITS station.

Basically, an ITS station is required to obtain specific credentials from dedicated certification authorities in order to access the ITS network 100 and make full use of the available ITS application, services, and capabilities, such as sending ITS messages. The certificate may depend on the capabilities of the ITS station (for instance its sensors or the Video Content Analytics (VGA) it can run) but also the role and the security level of the owner of the station. For example, only an ITS station with sensors with a sufficient quality of detection of a pedestrian and/or a cyclist may be authorized to send GPM messages containing VRU information. Still for the sake of illustration, the trust level associated with a certificate may be increased when it can be shown that the equipment used to generate and to transmit messages is regularly controlled against hacking.

Figure 2 illustrates an example of a PKI-based mechanism. The PKI-based security is implemented through the use of certificates delivered by a certification authority to the ITS stations.

As part of the ITS station manufacturing process, a set of information elements 240 associated with the identity of the ITS station is established within the ITS station itself and within a so-called Enrolment Authority (EA) 235, for example as defined in the version 1.2.1 of the ETSI TS 102 941 specification. The set of information elements 240 is then registered within the ITS station and the EA 235.

As an example, the set of information elements 240 may comprise:

- a canonical identifier, that is an identifier uniquely identifying the ITS station (i.e. the canonical identifier is equivalent to the ITS station identity), and

- a public/private key pair for cryptographic purpose based on PKI mechanism.

Based on this set of information elements, Enrolment Authority 235 may generate an Enrolment Certificate 245 which contains a pseudonym provided to the ITS station during the enrolment process. The pseudonym is used for anonymity and is referred to as Enrolment Identity (Enrolment ID).

Next, after having enrolled with EA 235, the ITS station requests an Authorisation Authority (AA) 205 for specific services and permission within the EA's domain and AA's Authorisation context. In particular, AA 205 checks Enrolment Certificate 245 included in the request (more specifically, AA checks the Enrolment ID included in Enrolment Certificate 245). Then, if Enrolment Certificate 245 is suitable, AA 205 provides multiple Pseudonym Certificates referred to as Authorisation Tickets (AT) 215. Each AT 215 includes a pseudonym of the ITS station to be used in V2X communication, to ensure its privacy when interacting within the ITS network.

From this security procedure, an ITS station 210 selects an AT among its available multiple ATs 215 for a given period before switching to another AT in order to prevent the linkability. The change of AT may be performed according to an AT change strategy.

The message 225 sent by the ITS station 210 together with the AT 230 corresponds to message 150 with AT 160 (the digital signature 170 is not shown in Figure 2). Rather than accompanying the ITS message 225 with AT 230, ITS message 225 may contain a link to the AT 230 used, which is transmitted by other means, e.g. in a different message or using another transmission mean (prior to the ITS message or after the ITS message is sent, e.g. upon request from the receiving ITS station).

The pseudonym ITS identifier from the selected AT 230 may also be indicated in the header of the ITS message 225. In variants, an ID value linked to the ITS pseudonym may be indicated in the ITS message header, selected by the transmitting ITS station 210. Thus, the change of the value of the ID reflects the change of the selected AT 230 and the associated pseudonym.

An ITS station may thus have several valid certificates in the same time, all having different pseudonyms. The station can then select different certificates for different messages. Due to multiple pseudonyms, this may allow avoiding station tracking and thus ensure privacy protection. In addition, as a certificate contains a list of several authorizations, different authorizations may be used by a station depending of the particular context.

When receiving a message 225, the receiving ITS station 220, verifies the AT 230 in order to ensure that the transmitting ITS station 210 has the privileges and authorizations to transmit specific ITS messages 225.

Figure 3 illustrates verification of a signed message (i.e. a message accompanied with a digital signature).

The structure of the signed message 150 and its certificate AT 160 is described in Annex A.2 of the version 2.0.1 of the ETSI TS 103 097 specification. The structure of the certificate is a particular usage of the general signature defined in the specification IEEE 1609.2 and it is similar to the signature system defined in SAE J2945.

As illustrated, the signed message comprises the message 150 to be signed and the corresponding signature 170. The data to be signed comprise the payload 152 of the message and a header 151 comprising an ITS Application IDentifier (ITS-AID) 300 of the ITS application or service having generated the message and optionally other items of information such as the generation time and the generation location, which can be omitted, in particular if they can be deduced or inferred from the payload content. The signature 170 contains an identifier of the signer, i.e. the ITS-S ID (IDentifier) which is the pseudonym used by the originating ITS station, and an encrypted hashed value of the data being signed.

The pseudonym ITS-S ID allows the corresponding AT 160 to be retrieved by the receiving ITS-S. In other words, the pseudonym can be used as a reference to AT 160. For the sake of illustration, AT 160 may be requested by the receiving ITS station to an Authorization Authority or may be obtained from a secure memory if it has been received previously. As already described, the emitter (originating) station may have several identifiers or pseudonyms attributed by the Authorization Authority and thus, it may obtain as many certificates as identifiers or pseudonyms.

The certificate may specify an authorized period of time, an authorized location, and a list of authorized applications with specific permissions.

For instance, AT may 160 contain a validity period 305, a validity region 310, and a verification key 315. The verification key allows verification of the correctness of the encrypted hashed value included in the digital signature 170 (e.g. in digital signature 170). As illustrated, AT 160 also contains a list 320 of one or more application or service permissions (e.g. application or service permissions 321 and 322), each comprising an ITS Application IDentifier (e.g. ITS-AID 1 and ITS-AID2) defining the authorized ITS service and a Service Specific Permission (e.g. SSP1 and SSP2) defining permissions for the corresponding authorized ITS service.

The ITS AID identifies an ITS service or application which uses some types of messages, that is authorized by AT 160. Currently in ETSI TS 102 965 V1.4.1 , one ITS AID is defined per message type (for example CAM, DENM, CPM, and VAM), i.e. per operational ITS service. The allocation of ITS AID values to the ITS services may be defined by a predefined allocation scheme, as the one provided in ISO/TS 17419. The ITS AID may be encoded over 1 to 4 bytes. The shorter the ITS AID, the more critical the corresponding ITS service. For example, ITS AID equal to 36 (or 0x24) is assigned to the CA basic service, while ITS AID equal to 37 (or 0x25) is assigned to the DEN basic service

AT 160 thus provides the list of ITS messages that the ITS station is authorized to send.

As illustrated in Figure 3, digital signature 170 may be checked by using verification key 315, for example by computing again the result of a hash function applied to the ITS message 150 and AT 160 and by comparing the result with the hash value provided in the digital signature.

The time and location of ITS message 150 can also be checked with regard to the validity period 305 and validity region 310, respectively.

The authorization is also checked using ITS-AID 300 of the ITS message: the message can be processed only if ITS-AID 300 is present in the list 320 of permissions. In the affirmative, an additional check of the content of the message payload 152 with the SSP associated with the ITS-AID can be made to ensure e.g. the emitting ITS station has authorization to provide the payload data.

According to some embodiments of the disclosure, an ITS station having valid Authorization Tickets but that may generate erroneous ITS messages, especially CPM containers, can be tested. In normal operation of ITS system 100 in Figure 1 , an ITS station generates CPMs from data obtained from embedded sensors using authorized tickets. Other ITS stations receive these messages to enhance their perception. Under test conditions, after a test request has been generated and transmitted by a DTS, the same ITS station generates CPMs from data obtained from selected embedded sensors, using authorized tickets and/or signed messages delivered by the DTS. According to some embodiments, these CPMs are ignored by other ITS stations that are operating in a normal mode. According to other embodiments, these CPMs are taken into consideration by other ITS stations, possibly with a lower trust level than CPMs send in a normal mode.

Accordingly, the perception of an ITS station emitting CPM may be tested by requesting this ITS station to select sensors and to transmit a perception measurement report based on data obtained from these sensors.

Figure 4 illustrates an example of a flow of messages exchanged during a perception test sequence according to a first embodiment, between a Dedicated Test System (DTS) and a System Under Test (SUT). According to this example, the Perception Test Request requesting data obtained from selected sensors of the SUT is initiated by a central ITS Station, for example central ITS Station 180 in Figure 1 , the central ITS station sending a Test Request message to the SUT, for example SUT 120 in Figure 1 , using a unicast encrypted message (step 410). An advantage of sending the Test Request message as a unicast encrypted message is that this message may be ignored by ITS stations that are not involved in the test sequence.

Next, the SUT preferably answers to the Test Request message by a Test Response message (step 420), preferably using a similar communication scheme (i.e. a unicast encrypted message) going through the RSU (e.g. through RSU 111). The Test Response message may be considered as an acknowledgement of the Test Request message, providing, for example, characteristics of the sensors that will be used by the SUT for responding to the Test Request message.

Next, after having transmitted a Test Response message (if such a message is transmitted), the SUT could answer to the Test Request message requesting data obtained from selected sensors by transmitting such a CPM message (step 421). The CPM message may be transmitted using a similar communication scheme (i.e. a unicast encrypted message) or using a broadcast communication scheme with a test ticket, going through the RSU. In addition, the data obtained by a selected sensor may be processed, for example to select data of a region of interest, to compress the obtained data, or to extract some features from these data.

Using this sequence of messages, the DTS explicitly selects sensors of SUT and requests a measurement to be performed using a similar way as operating on the road within C-ITS. Also, this operation permits to execute a measurement using a selection of sensors of SUT.

Alternatively, in other embodiments, the SUT answers to the Test Request message requesting data obtained from selected sensors, after having transmitted a first Test Response message (step 420) if such a message is transmitted, by transmitting a second Test Response message (step 422) including at least a complete or a part of a CPM message or payload generated using the selected sensors. Again, the Test Response message may be transmitted using a similar communication scheme (i.e. a unicast encrypted message) or may be broadcast, going through the RSU. Likewise, the data obtained by a selected sensor may be processed.

According to particular embodiments, a CPM message associated with a Test Response message is broadcast so that its content (that should represent a real perception of the SUT environment) can be used by other ITS stations. Such a CPM message should not be broadcast to other ITS station in particular circumstances, for example when a fake scene is used to test the SUT.

Figure 5 illustrates an example of a flow of messages exchanged during a perception test sequence according to a second embodiment, between a Dedicated Test System (DTS) and a System Under Test (SUT), where the central ITS station, representing the DTS, asks to a RSU to start a test request (step 500) using a test mode. In turn, the RSU (e.g. RSU 111) sends a Test Request message (step 510) to the SUT (e.g. SUT 120 in Figure 1), the Test Request message requesting data obtained from selected sensors of the SUT. The SUT then preferably responds with a Test Response message to the RSU (step 520). Again, the Test Response message may be considered as an acknowledgement of the Test Request message, providing, for example, characteristics of the sensors that will be used by the SUT for responding to the Test Request message.

Next, after having transmitted a Test Response message (if such a message is transmitted), the SUT could answer to the Test Request message requesting data obtained from selected sensors by sending to the RSU such a CPM message (step 521), using a similar communication scheme (i.e. a unicast encrypted message) or a broadcast communication scheme using a test ticket. In addition, the data obtained by a selected sensor may be processed, for example to select data of a region of interest, to compress the obtained data, or to extract some features from these data.

Alternatively, in other embodiments, the SUT answers to the Test Request message requesting data obtained from selected sensors, after having transmitted a first Test Response message (step 520) if such a message is transmitted, by transmitting a second Test Response message (step 522) including at least a complete or a part of a CPM message or payload generated using the selected sensors using a similar communication scheme (unicast encrypted message) or broadcast going using a test ticket. Likewise, the data obtained by a selected sensor may be processed.

Next, the RSU generates a Test result report to the DTS (step 530). In these embodiments, the Test Request and Response messages can use the ITS Test Mode Message service (e.g. as defined in ETSI TR 103573 V1.1.1 (2019-11)) or a unicast encrypted message.

Again, according to particular embodiments, a CPM message associated with a Test Response message may be broadcast so that its content (that should represent a real perception of the SUT environment) can be used by other ITS stations.

Figure 6 and 7 illustrate examples of a message format for the Perception Test Request (or CPM test request, e.g. the test request sends at steps 420 and 520 in Figures 4 and 5, respectively) and the Perception Test Response (or CPM test response, e.g. the test response sends at steps 410 and 510 in Figures 4 and 5, respectively), respectively, based on the ITS Test Mode Message service (as defined in the TR 103 573 standard). The Test Mode Service permits to verify conformance regarding the ITS protocol stack implementation as well as to monitor the transmission and reception parameters. According to ETSI TR 103 573 V1.1.1 (2019-11), the test mode makes it possible to verify RF and functional requirements of the ITS protocol communications. The test coverage deals with the following items: reception ability, transmission ability, protocol conformance, certificates accept I reject I trust I revocation functions, message format, and stress test.

The test Mode service permits to request the transmission of CPM messages but their content is not derived from any sensor. In other words, the test mode service does not permit to test components such as sensors involved in the Collective Perception Service.

The test mode service benefit can be extended by adding requested sensor(s) to be used by OBU (On Board Unit) for transmission of test mode messages when the requested message type is CPM.

Therefore, some embodiments of the disclosure aim at supplementing the test mode to make it possible to test the sensors.

According to some embodiments, a Perception Test Request message contains one or more of the following items of information:

- a perception test request ID, that is a unique identifier of the request (it may correspond to a test sequence number to which is concatenated a SUT ITS ID), and a message request type,

- a signature,

- a requested message,

- a list of sensors to be used (also denoted requested or selected sensors),

- a list of requested radio parameters, and - a reference message counter and a reference time of the message.

The format of the list of sensors to be used (or requested sensors) may correspond to a sub-set to the Sensor Information container transmitted in CPMs by the SUT. It is recalled that the Sensor Information container provides information about the sensory capabilities of an ITS Station such as the sensor type (e.g, LIDAR, monovision, etc.) and the sensor detection area. In the case where a Sensor Information container could not be obtained from a Perception Test Request, a default detection area may be defined in the surrounding of, for example, in front of, the vehicle embedding the SUT, with some typical sensor detection area dimensions. In such a case, the SUT can precise in the Perception Test Response what is its detection area. The detection area is a mean to indirectly select sensors of the SUT. A definition of a Sensor Information container format may be found in the Collective Perception Service Technical Report TR 103 562 (e.g. ETSI TR 103 573 V1.1.1 (2019-11)).

For each requested sensor of the list of sensors to be used, the Sensor Information container included in the Perception Test Request may contain one or more the following fields:

- sensori D , that is a Sensor pseudonym ID used to relate which measurement has been received by which sensor,

- type, that describes the sensor type (e.g. camera, radar, LIDAR, fusion, etc.),

- detectionArea that defines the sensor perception area,

- xSensorOffset, ySensorOffset, zSensorOffset, that represent the coordinates of the mounting position of the sensor, and

- range, that indicates the range of the sensor within the indicated opening angle.

Any other field, in particular any other field as specified in Collective Perception Service Technical Report TR 103 562 describing the Sensor Information container, can be used to select sensors in a SUT, from which data are to be obtained in response to the Perception Test Request.

In addition, it is noted that a selected sensor (or requested sensor) can be a fusion sensor. In such a case, the SUT may be in charge of detecting objects based on its fusion sensor which may comprise or involve one or more physical sensors associated with a fusion algorithm. It is also noted that the sensori D field may be used by a DTS as means to select more precisely which sensors associated with the requested fusion sensor should be selected by the SUT to perform the test and to generate the CPM message.

According to some embodiments, items of information of requested sensors in the SUT (i.e. the list of sensors or the requested sensors of the Perception Test Request) may comprise specific values of sensori D, type, detectionArea, coordinates, and/or position, that are different from the corresponding items of information set by the SUT in the Sensor Information container in a normal operating mode (i.e. the SUT is not responding to a request of DTS). These specific values could be used by an authorized entity to select and configure SUT sensors in a diagnostic mode. For example, a DTS may select a specific detectionArea value that is different from the detectionArea value used by the SUT in normal operation to test the coverage of a sensor.

According to some embodiments, the requested sensors of the SUT are determined by the Dedicated Test System based on a first CPM message previously received from the SUT, by analyzing the Sensor Information Container part of the CPM message. This first CPM message may be obtained during a normal mode or during a first test step, by selecting all the sensors of the SUT, i.e. by indicating a value equivalent to ‘all sensors’ in the field requested sensors in the Perception Test Request message sent to the SUT. As disclosed above, if the DTS cannot obtain a Sensor Information Container from the SUT to select sensors, default values may be used to select sensors. For example, a default detection area can be defined, for example and without limitation, in front of the vehicle embedding the SUT, with a typical sensor detection area dimension.

In response to a Perception Test Request, the SUT provides a perception report for the requested sensors using a Perception Test Response like the one illustrated in Figure 7 and a CPM like the one illustrated in Figure 8.

According to some embodiments, the Perception Test Response message contains the following information:

- a perception test response ID that is unique identifier of the request (it may correspond to a test sequence number to which is concatenated a SUT ITS ID) and a message request type,

- a signature,

- the list of selected sensors (equivalent to the list of sensors requested by the DTS),

- a list of selected radio parameters,

- various hardware and software version and control checksums used by the SUT during the TEST, and

- a reference message counter and a reference time of the message.

For each sensor used by the SUT to perceive objects and area states, the Perception test Response message contains items of information similar to the Sensor Information Container provided in standard CPM, for example a CPM as described in Collective Perception Service Technical Report TR 103 562 (e.g. ETSI TR 103 573 V1.1.1 (2019-11)):

- sensor ID (SensorlD), that is an identifier of the sensor,

- sensor type (Type), that describes the type of the sensor (e.g. LIDAR, radar, monovision, etc.), - detection area {detection Area), that defines the sensor perception area, for example as a polygon area with a list of offset points from the reference position set in the management header,

- free space confidence, that represents a confidence level regarding whether the detection area is free or not.

In addition to the Perception Test Response, the SUT should generate a CPM using the sensors requested by the DTS. The example of the format of such a CPM is described in Figure 8. As illustrated, the CPM should contain a list of objects and areas perceived using the requested sensors. Each of the perceived objects is characterized by values measured by the selected on-board sensors (e.g. on-board sensors 125a and 125b of the SUT embedded in vehicle 120 in Figure 1) with some additional items of information used by the on-board sensors to perceive this object, for example one or more of the following:

- objectID, that is an identifier corresponding to the perceived object,

- sensori Dlist, that is a reference to the sensor IDs used for perceive the object,

- timeOfMeasurement, that indicates the time at which the object attributes were measured, it may correspond to the time difference with respect to the reference time set in the management header part or, in some embodiments to an absolute time value,

- the distance defined by xDistance, yDistance, and zDistance (optional), that corresponds to the distance between the perceived object and the reference position defined in the management header the in x, y, z-direction of the ITS-S coordinate system, respectively, at the time of measurement. In some embodiments, the distance can be replaced by the geographical coordinates of the objects,

- the speed defined by xSpeed, ySpeed and zSpeed (optional), that corresponds to the speed of the perceived object in the detecting ITS-S’s reference system in the x, y, z-direction, respectively, at the time of measurement,

- the dimension (optional) defined by planarObjectDimensionl, planarObjectDimension2, and verticalObjectDimension, that represents the dimension of the perceived object, and

- classification, that provides the classification of the object. It is composed of an object class (e.g. vehicle class, Vulnerable Road User (VRU) class, etc) and possibly a subclass (e.g. vehicle class has subclasses passengerCar, bus, etc.).

Figure 8 illustrates an example of a format of a CPM, according to ETSI TS 103 324 (VO.0.22 of May 2021).

As illustrated, a CPM 800 contains an ITS PDU header 810 and a CPM Parameters field 820. ITS PDU header 810 is a common header that includes the information of the protocol version, the message type and the ITS-S ID of the originating ITS-S. CPM Parameters field 820 contains a Management Container 830, a Station Data Container 840, a set of Sensor Information containers 850, a set of Perceived Object containers 860, and a set of Free Space Addendum Containers 870. The CPM payload comprises a set of Sensor Information containers 850, a set of Perceived Object containers 860, and a set of Free Space Addendum Containers 870.

Regardless of which type of ITS-S generates a CPM, the Management Container provides information regarding the Station Type and the Reference Position of the originating ITS Station. The message can be transmitted either by an ITS Station, such as a vehicle, or by a stationary RSU. In case of a CPM generated by a vehicle, the Station Data Container contains dynamic information of the originating ITS Station. It is not optional in case of a vehicle transmitting the CPM. In case of a CPM generated by a RSU, the Station Data Container may provide references to identification numbers provided by the MAP Message (CEN ISO/TS 19091) reported by the same RSU. These references are required in order to match data provided by the CPM to the geometry of an intersection or road segment as provided by the MAP message. It is not required that a RSU has to transmit a MAP message for matching objects to road geometries. In this case, the Station Data Container may be omitted. It is for this reason that the Station Data Container is set as optional.

Each Sensor Information container contained in the set of Sensor Information containers 850 is optional. It provides information about the sensory capabilities of an ITS station. Depending on the station type of the originating ITS station, different container specifications are available to encode the properties of a sensor. The Sensor Information containers are attached at a lower frequency than the other containers, as defined in ETSI TR 103 562. Up to 128 containers of this type may be added. The container 895 offers the possibility to provide descriptive information about the sensory properties of a disseminating ITS-S. Every described sensor is provided with a pseudonym id (sensorlD) which is in turn utilized in the Perceived Object Container to link measured object information to a particular sensor. Additionally, each provided sensor information is accompanied by a sensor categorization to indicate the type (type) of the perception system. This can be a specific sensor type such as a radar or LIDAR sensor up to a system providing fused object information from multiple sensors. As different sensor types may be attached to an ITS-S, e.g. radar, LIDAR, combined sensor fusion system and alike, this container provides different possibilities for describing the properties of a sensor-system.

Two types of descriptions are differentiated: sensors which are mounted onto moving station, such as vehicles, are described using the vehicleSensor description. Sensors which are stationary, e.g. because they are mounted onto a RSU, are described by using a stationarySensor description. The perception area (detectionArea) of a perception system can be inferred on the receiving ITS-S by the data provided in the SensorlnformationContainer. Either variant can be used to describe the sensory capabilities of the disseminating ITS-S. This can be the actual parameters of a perception-system, i.e. its actual perception range (range), or the applicable perception area {detectionArea) of the perception system, i.e. the area in which objects will be detected by the perception system. Additionally, each described sensor can be provided with a position using an absolute coordinate or relative offset position relative to the RSU holding the corresponding sensor.

Each Perceived Object container contained in the set of Perceived Object containers 860 is optional. It comprises a sequence of optional or mandatory data elements (DEs) which give a detailed description of the dynamic state and properties of a detected object.

More precisely, each object is described using a specific structure such as structure 880, by at least an identifier (defined by the DE ObjectID), a time of measurement (defined by the DE timeOfMeasurement) referred to as corresponding to the time difference for the provided measurement information with respect to the generation delta time stated in the management container, a distance (defined by the DEs xDistance and yDistance), and a speed (defined by the DEs xSpeed and ySpeed) in the x-y plane of the respective coordinate system with respect to a station’s reference point.

In addition, several optional DEs may be used to provide a more detailed description of the perceived object. Such optional DEs may be related to an acceleration (defined by the DEs xAcceleration and yAcceleration), a dynamic Status (defined by the DE dynamicstatus), or a classification (defined by the classification DE). Distance, Speed and Acceleration values can also be provided in three dimensions (respectively with the DEs zDistance, zSpeed and zAcceleration) along with the yaw angle of the object (defined by the DE yawAngle). Furthermore, a three-dimensional description of an object’s geometric extension can be provided (with the DEs planarObjectDimensionl , planarObjectDimension2 and verticalObjectDimension). Moreover, a RSU is also able to provide a map-matching result for a particular object with respect to the MAP information (defined by the DE matchedPosition).

Each Free Space Addendum Container contained in the set of Free Space Addendum Containers 870 is optional. It is composed of a sequence of optional or mandatory data elements (DEs) which provide information of detected free space performed by a particular sensor. More precisely, each Free Space has to be described using a specific structure like structure 890 by at least a confidence (defined by the DE FreeSpaceConfidence), a space area geometry (defined by the DE FreeSpaceArea), the sensors used to monitor the free space (optional, defined by the DE Sensori D), and a flag shadowingApplies indicating that shadowing mechanism applies within the area described by freeSpaceArea. The flag shadowingApplies is a Boolean indicator to indicate if tracing approach should be used to compute a shadowed area behind an object. If set to TRUE, the simple tracing approach should be applied for each object intersecting or located within the area or volume described by the freeSpaceAddendum container. If set to FALSE, the simple tracing approach should not be applied for each object intersecting or located within the area or volume described by the freeSpaceAddenum container.

According to embodiments of the disclosure, Collective Perception Messages are used according to their normal mode of use but the optional fields should be used by the SUT to match the requests of the DTS under the test sequence. In particular, the Sensor container information, the Perceived object container, and FreeSpace Addendum container should be used as a function of the requests received from the DTS.

Figure 9 illustrates an example of a perception test procedure initiated by a Dedicated Test System (either a central ITS Station or a RSU).

As illustrated, a first step is directed to activating the perception test mode (step 900). The activation of this test mode can be triggered by a central ITS station or by a roadside ITS Station (RSU) based on various criteria such as:

- repair and maintenance in authorized workshops,

- periodic technical inspection,

- end-of-line test I initial test, and/or

- in-field Inspection.

Next, the DTS determines the sensors to be requested to the SUT (step 905). To that end, the DTS should have knowledge of the objects and areas for the collective perception test. The test can be executed in different situations and the DTS should trigger the test according to a specific test case. For example, the aim of the test can be to ensure production quality and V2X compliance of new vehicles. Another objective can be directed to verifying basic functionalities of V2X components during the lifetime of the SUT. Still another objective can be directed to verifying basic functionalities after carrying out repair and maintenance operations in authorized workshops. In each perception test case, the DTS should have knowledge of the potential perceived objects and areas by the SUT, using a selection of sensors. For example, the test environment can use other vehicles or a fake scene for which the SUT should provide already known CPM containers (objects or areas). Such objects and areas are considered as reference objects and reference areas. The reference objects can also be selected from real-time object list perceived by the RSU monitoring the area where is positioned the SUT or specific test pattern.

The reference objects or areas are selected based on the geographical position of the SUT and of its detection area, before determining the sensors to be requested to the SUT. As disclosed above, the SUT detection area could be obtained through the content of Sensor Information in the CPMs regularly transmitted by the SUT. If the detection area of the SUT could not be obtained prior to sending the test request, then a default detection area could be used such as a circular area around the SUT with a certain distance (e.g. 50 m) or multiple polygon areas representing a typical front, lateral, and/or rear sensor detection area of a vehicle.

Next, the sensors to test are selected based, for example and without limitation, on the need of test case and the detection area where the reference objects and areas can be perceived by the SUT (step 910). The list of selected sensors may comprise several sensors to test or a single sensor to test from the already determined sensors (step 905). Selecting a single sensor makes it possible to test independently all the sensors by executing multiple tests. In a particular embodiment, the selection of sensors can be based on a sub-set of the previously determined sensors using some of the sensori D list. For example, the DTS can individually request each sensor and perform series of test sequence to request a measurement using only one sensor per test sequence.

In another embodiment, the selection of sensors can be based on agiven area permitting to perceive the reference objects. For example, the DTS can request a detection area corresponding to the front or the rear of a vehicle. The SUT will perform measurements using only the sensors permitting to perceive objects in the requested detection area.

In still another embodiment, the selection of sensors can be based on the type of sensors. For example, the DTS can request a LIDAR sensor type. In this case, the SUT will perform measurements using only the LIDAR sensors. Other sensors are not involved in the requested test.

Next, the Dedicated Test System (CIS 180 or RSU 111) sends a Perception Test Request message containing the list of selected sensors to the SUT (step 915), requesting a Perception Test response.

Figure 10 illustrates an example of steps carried out in an ITS Station Under Test to test sensors. As illustrated, a first step is directed to receiving a Test Request message (step 1000) comprising a list of sensors to test. Next, the SUT carries out measurements using its on-board sensors that are identified in the received Test Request message (step 1005).

Next, the SUT generates a CPM message including perceived objects and perceived areas using the selected sensors, as requested by the DTS (step 1010).

Next, a Test Response message and the associated CPM, previously generated, are transmitted by the SUT to the DTS (step 1015). In some embodiments, the transmission of the Test Response message may be optional.

Figure 11 illustrates an example of steps carried out by the DTS upon reception of Perception response.

As illustrated, after having received a Perception Test response and an associated CPM from the SUT (step 1100), the received Perception Test response and the associated CPM are analyzed (step 1105). It is noted that a timer may be used so as to check that the Perception Test response and the associated CPM are received no longer than a predetermined time duration after a Perception Test request has been sent. In such a case, a failure indication may be added into a test result report if the Perception Test response and the associated CPM are not received within the predetermined time duration, being noted that an obligation of response by the SUT could be brand-specific, or may be decided by regulation and then controlled by authorities.

Analyzing the received Perception Test response and the associated CPM may comprise comparing a list of reference objects and/or areas with the list of received perceived objects and/or areas. According to some embodiments, it may be considered that the requested sensors are correctly operating if these two lists are matching (step 1110), possibly with an error margin. Otherwise the requested sensors should be considered on fault. Such a test result may be included in a test result report (step 1115).

According to some embodiments, forwarding the test result report mainly consists in forwarding the received Perception Test Response to a central ITS station (e.g. central ITS station 180 in Figure 1) that analyzes the response. In other embodiment, such an analysis is carried out within the RSU. If some of the perceived objects and/or area are badly positioned or badly classified, there is a high probability that there are some malfunctioning sensors. Then, the mitigation action may be to create a malfunction report (proprietary message) and send it to an OEM (Original Equipment Manufacturer) server in charge of the SUT ITS Station maintenance to trigger a maintenance operation (to repair malfunctioning sensor) or other mitigation actions such as stopping the CPM transmission to avoid to get a revocation of the SUT Authorization Tickets.

Figure 12 schematically illustrates a communication device 1200, typically any of the vehicle or roadside or VRU ITS stations illustrated in Figure 1 , of an ITS, configured to implement at least one embodiment of the present disclosure. The communication device 1200 may preferably be a device such as a micro-computer, a workstation, or a light portable device. The communication device 1200 may comprise a communication bus 1205 to which may be connected:

- a central processing unit 1201 , such as a processor, denoted CPU,

- a memory 1203, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the disclosure as well as the registers adapted to record variables and parameters necessary for implementing the methods, and

- at least two communication interfaces 1202 and 1202’ connected to the V2X network, for example a communication network according to 3GPP LTE- Advanced Pro, 3GPP 5G or IEEE 802.11p technology, via transmitting and receiving antennas 1204 and 1204’, respectively. Preferably the communication bus 1205 may provide communication and interoperability between the various elements included in the communication device 1200 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1200 directly or by means of another element of the communication device 1200.

The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1202 or 1202’, in order to be stored in the memory 1203 of the communication device 1200 before being executed.

In an embodiment, the device 1200 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Although the present invention has been described herein above with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A method of communication in an intelligent transport system, ITS, comprising at an ITS station, ITS-S, under test, SUT: receiving a request to obtain data from at least one component of the SUT, the received request comprising an item of information enabling selection of at least one component of the SUT, selecting at least one component of the SUT as a function of the received item of information and obtaining data from the at least one selected component, and transmitting an ITS message comprising the obtained data.

2. The method of claim 1 , wherein the at least one selected component comprises at least one sensor.

3. The method of claim 2, wherein the obtained data comprise measurements acquired by the at least one sensor.

4. The method of claim 2 or 3, wherein the obtained data comprise data derived from measurements acquired by the at least one sensor.

5. The method of any one of claims 1 to 4, wherein the at least one selected component comprises at least one fusion sensor.

6. The method of any one of claims 1 to 5, wherein the ITS message is a CPM.

7. The method of any one of claims 1 to 6, wherein the ITS message is signed.

8. The method of claim 7, wherein the signature indicates that the ITS message is sent in response to a request to obtain data from at least one component of the SUT.

9. The method of any one of claims 1 to 6, wherein the ITS message is a broadcast unencrypted message.

10. The method of any one of claims 1 to 9, further comprising transmitting a response message, the response message comprising an item of information describing the at least one component of the SUT, used to obtain the data transmitted in the ITS message.

11. A method of communication in an intelligent transport system, ITS, comprising at an ITS station, ITS-S, used to test an ITS-S under test, SUT: identifying at least one component to test of the SUT, transmitting a request to obtain data from the at least one identified component, the transmitted request comprising an item of information enabling selection of at least one component of the SUT, and receiving an ITS message, the received ITS message comprising requested data enabling to detect a malfunction of the at least one identified component.

12. The method of claim 11 , wherein the at least one identified component is identified from a description of a set of components of the SUT, the description being received in a previous ITS message.

13. The method of claim 11 or claim 12, further comprising activating a test mode.

14. The method of any one of claims 11 to 13, further comprising comparing the received requested data with expected data.

15. The method of any one of claims 11 to 14, further comprising generating a test result report.

16. The method of any one of claims 11 to 15, further comprising receiving a response message, the response message comprising an item of information describing at least one component of the SUT, used to obtain the received requested data.

17. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing each of the steps of the method according to any one of claims 1 to 16 when loaded into and executed by the programmable apparatus.

18. A non-transitory computer-readable storage medium storing instructions of a computer program for implementing each of the steps of the method according to any one of claims 1 to 16.

19. A device comprising a processing unit configured for carrying out each of the steps of the method according to any one of claims 1 to 16.