Method, device, and computer program for improving safety in an intelligent transport system

Abstract

A certificate comprising safety level associated with information transmitted in the ITS message related to the confidence in perception of a region or of an object. The current safety level may depen

Description

FIELD OF THE DISCLOSURE The present disclosure relates generally to Intelligent Transport Systems (ITSs) and more specifically to Cooperative Intelligent Transport Systems (C-ITSs). BACKGROUND OF THE DISCLOSURE Cooperative Intelligent Transport Systems (C-ITSs) 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 stationary stations (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 generally rely on radio services for communication and use dedicated technologies. Such C-ITSs are subject to standards, specified for each country and / or territory where C-ITSs are implemented. Today, in Europe, the European Telecommunications Standards Institute is in charge of the elaboration of the specifications forming the standards to which C-ITSs are subjected. Cooperation within C-ITSs is achieved by exchange of messages, referred as to ITS messages, between 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 device, a smart watch, or in a cyclist equipment), or any other entities or infrastructure equipped with an ITS equipment, as well as central subsystems (back-end systems and traffic management centers). As observed above, C-ITSs 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 stationary stations such as vehicle-to-infrastructure or“V2l”, and infrastructure-to-vehicle or“l2V”, e.g., car-to-infrastructure. Such exchanges of messages 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 (3GPP, LTE, and IEEE are Registered Trademarks). Exemplary ITS messages include Collective Perception Messages (CPMs), Cooperative Awareness Messages (CAMs), Vulnerable Road Users Awareness Messages (VAMs), and Decentralized Environmental Notification Messages (DENMs). An ITS-S sending an ITS message is referred to as an “originating” ITS-S and an ITS-S receiving an ITS message is referred to as a “receiving” ITS-S. VAMs and CAMs are generally periodically sent with a period varying depending, for example, on the speed of the originating ITS-S. It is noted that ETSI TS 103 324 (v2.1.1 of June 2023) defines the Collective Perception Service through which an ITS-S having on-board sensor systems detects objects in its vicinity and transmits, using broadcast CPMs, description information (e.g. dynamics such as position and / or kinematic information) thereof. The CPMs are sent periodically with a period from 100 ms to 1 s depending for example on the speed of the objects sensed by the originating ITS-S. It is recalled here that ETSI TS 103 900 (V2.1.1, 2023) defines the Cooperative Awareness Basic Service, that may be used by an ITS-S to transmit, using broadcast CAMs, its ego-vehicle dynamics (e.g., its position and speed). The CAMs are generally periodically sent with a period varying from 100 milliseconds to one second depending, for example, on the speed of the originating ITS-S. It is also to be noted that ETSI TS 103 831 (V2.2.1, 2024) defines the Decentralized Environmental Notification Basic Service, that may be used by an originating ITS-S to send, using broadcast DENMs, notifications to other ITS-Ss, such as warnings or alerts. Such a message notifies an event (e.g., a road hazard, driving environment information, traffic condition information, etc.) detected by the originating ITS-S. Each ITS station has an environment model called a Local Dynamic Map (LDM) that is regularly updated with highly dynamic data to locate vehicles, pedestrians, bicycles, etc., in the vicinity of the ITS station. The LDM is updated using information from on-board sensors and completed with information from received ITS messages such as awareness messages containing the ego-position and the speed of connected vehicles (CAMs) and / or of connected Vulnerable Road Users (VAMs) and such as Collective perception messages (CPMs) containing the perceived objects (e.g. vehicles, motorbikes, bicycles, or pedestrians) from sensor-equipped ITS stations. CPMs improve the local perception ability (larger field of view, non-connected objects etc.). It is noted that cooperative ITS messages are not encrypted when exchanged over the V2X network however, to make it possible to authenticate the transmitting or originating ITS station and to check data integrity of the ITS messages, a Public Key Infrastructure (PKI), providing digital certificates to the ITS stations, is implemented. Certificate format is described in IEEE 1609.2-2016. Although the PKI mechanism offers many advantages, cyber-threats remain. For instance, misbehaving entities in possession of valid certificates may still transmit tampered data. Therefore, additional security mechanisms need to be deployed in the ITS stations to detect misbehaving entities, and to take appropriate action such as sending a report to a Misbehaviour Authority (MA) in case of detection, it being noted that a misbehaving entity is not necessarily malicious since it may also be a malfunctioning entity. Indeed, it is difficult to determine whether a station is malicious or “only” malfunctioning, but in both cases, it is important to make its misbehaviour visible. TS 103 759 (V2.1.1 of January 2023) defines the Misbehaviour Reporting Service, by which an ITS-S or an end entity may provide misbehaviour reports to the MA of the C-ITS Cooperative-ITS Credential Management System (CCMS). In particular, it defines the report format, which is dependent of the application in which a misbehaviour has been detected. While these mechanisms have proven to be efficient, there is a continuous need to improve them. SUMMARY OF THE DISCLOSURE The present disclosure has been devised to address one or more of the foregoing concerns. In this context, there is provided a solution to improve safety in intelligent transport systems. According to a first aspect of the disclosure, there is provided a method of communication, in an Intelligent Transport System, ITS, comprising an ITS station, ITS-S, the method comprising, at the ITS-S: sending an ITS message referencing a certificate, the certificate comprising a predetermined safety upper-level (or upper limit or maximum level) associated with at least one item of information transmitted in the ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message Accordingly, the method of the disclosure makes it possible to improve safety, in particular by providing a upper-level of safety of items of information transmitted in ITS messages. According to some embodiments, the ITS message comprises at least one current safety level associated with the at least one item of information, the at least one current safety level being lower than, or equal to, the corresponding predetermined safety upper-level to be valid. Accordingly, the method of the disclosure makes it possible to improve safety, in particular by assessing dynamically a current level of safety and transmitting it in ITS messages. The current safety level may relate to a safety mode, level or standard compliance. According to some embodiments, the certificate further comprises an authorization allowing the ITS-S to compute the at least one current safety level, the method further comprising computing the at least one current safety level. Accordingly, the method of the disclosure makes it possible to describe such safety integrity levels of information in ITS-S messages, with associated authorizations described in the ITS-S certificates. Therefore, a certificate may contain evidence that the associated ITS-S has the right to describe some information with a pre-defined maximum level of safety integrity, while some messages may contain such information with associated safety integrity level. The fixed information in the certificate, validated and generated by an authority, allows an ITS-S to state that some part (or all) of its information is compliant to a certain safety mode, level or standard. Still according to some embodiments, the at least one current safety level is determined as a function of at least one characteristic of at least one sensor used to perceive the region or the object. Still according to some embodiments, the at least one current safety level is determined as a function of conditions of perception of the region or the object. Still according to some embodiments, the ITS message is a Cooperative Awareness Message, CAM. Still according to some embodiments, the current safety level is encoded in a performance class of a high-frequency container. Still according to some embodiments, the ITS message is a Collective Perception Message, CPM. Still according to some embodiments, the current safety level is encoded in a sensor information container, in a perception region container or in a perceived object container. According to a second aspect of the disclosure, there is provided a method of communication, in an Intelligent Transport System, ITS, comprising an ITS station, ITS-S, the method comprising, at the ITS-S: receiving an ITS message referencing a certificate, the certificate comprising a predetermined safety upper-level (or upper limit or maximum level) associated with at least one item of information transmitted in the ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message, and processing the at least one item of information as a function of the predetermined safety level. Accordingly, the method of the disclosure makes it possible to improve safety, in particular by providing a upper-level of safety of items of information transmitted in ITS messages. According to some embodiments, the received ITS message comprises a current safety level associated with the at least one item of information, processing the at least one item of information as a function of the predetermined safety level comprising checking the validity of the current safety level as a function of the predetermined safety upper-level and processing the at least one item of information as a function of the current safety level. Accordingly, the method of the disclosure makes it possible to improve safety, in particular by assessing dynamically a current level of safety and transmitting it in ITS messages. The current safety level may relate to a safety mode, level or standard compliance. Still according to some embodiments, the ITS message is a Cooperative Awareness Message, CAM, or a Collective Perception Message, CPM. Still according to some embodiments, the predetermined safety level is determined as a function of an Automotive Safety Integrity Level, ASIL. According to a third aspect of the disclosure, there is provided a certificate, in an Intelligent Transport System, ITS, the certificate comprising a predetermined safety upper-level (or upper limit or maximum level) associated with at least one item of information transmitted in an ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message. Accordingly, the certificate of the disclosure makes it possible to improve safety, in particular by providing a upper-level of safety of items of information transmitted in ITS messages. According to some embodiments, the certificate further comprises an authorization allowing an originating ITS station, ITS-S, to compute a current safety level to be transmitted in the ITS message. Accordingly, a certificate may contain evidence that the associated ITS-S has the right to describe some information with a pre-defined maximum level of safety integrity, while some messages may contain such information with associated safety integrity level. The fixed information in the certificate, validated and generated by an authority, allows an ITS-S to state that some part (or all) of its information is compliant to a certain safety mode, level or standard. According to a fourth aspect of the disclosure, there is provided a method of communication, in an Intelligent Transport System, ITS, comprising an Authorization Authority, AA, the method comprising, at the AA sending, to an ITS station, ITS-S, managed by the AA, a certificate as described above. Accordingly, the method of the disclosure makes it possible to improve safety, in particular by providing a upper-level of safety of items of information transmitted in ITS messages. According to a fifth aspect of the disclosure, there is provided an Intelligent Transport System, ITS, message, to transmit information in an ITS, comprising a current safety level associated with at least one item of information transmitted in the ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message. Accordingly, the Intelligent Transport System message of the disclosure makes it possible to improve safety, in particular by assessing dynamically a current level of safety and transmitting it in ITS messages. The current safety level may relate to a safety mode, level or standard compliance. According to another aspect of the disclosure there is provided a device comprising a processing unit configured for carrying out each of the steps 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, micro-code, 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, byway of example only, and with reference to the following drawings, in which: Figure 1 illustrates an example of an Intelligent Transport System (ITS) used to monitor a road having two lanes, one lane for each direction, wherein embodiments of the disclosure may be implemented; Figure 2a illustrates a schematic representation of the architecture (or of a portion of the architecture) of a device generating CPMs and receiving ITS messages, for example a road ITS station; Figure 2b illustrates a schematic representation of the architecture (or of a portion of the architecture) of an ITS-S embedded in a connected and autonomous vehicle (CAV) generating CAMs and receiving ITS messages; Figure 3 illustrates an example of a signed message and of a certificate; Figure 4 illustrates an example of a structure of a collective perception message, CPM, making it possible to transmit dynamic safety levels, according to some embodiment of the disclosure; Figure 5 illustrates an example of a structure of a cooperative awareness message, CAM, making it possible to transmit dynamic safety levels, according to some embodiment of the disclosure; Figure 6 illustrates an example of steps that may be carried out in an originating ITS-S for managing safety levels to be transmitted with associated pieces of information in ITS messages; Figure 7 illustrates an example of steps that may be carried out in a receiving ITS-S for processing received data and associated safety levels; Figure 8 illustrates an example of steps that may be carried out in a receiving ITS-S for transmitting received data to appropriate modules as a function of a safety level; and Figure 9 is a schematic representation of an example of a communication ITS-S device configured to implement some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE DISCLOSURE The inventors have observed that there are situations where a given functional safety is required (to be protected against accidental risks or hazards), in addition to a security level (providing protection from intentional threats or attacks). For example, when an emergency vehicle has to perform a blind manoeuvre, such as overtaking another vehicle, it has to rely on environmental data perceived by one or more other ITS-Ss. It is therefore necessary for these perceived environmental data to meet a particular level of requirement that results from a functional safety integrity level (or safety level in short) associated with these ITS-Ss. Accordingly, all parts of these ITS-Ss should be designed to properly handle systematic errors, hardware failures, and operational / environmental stress. In order to be part of an automating driving system, an emitting ITS-S should be designed to ensure safety functions including under conditions of incorrect operator input and failure modes. This is done by determining the probability of dangerous failure, checking minimum levels of redundancy, and reviewing systematic capability. According to some embodiments, safety integrity levels of items of information may be described in ITS-S messages. In addition, authorizations associated with these safety integrity levels may be described in corresponding ITS-S certificates. Therefore, a certificate may contain evidence that the associated ITS-S has the right to describe some items of information with a pre-defined maximum level of safety integrity, while some ITS messages may contain such items of information with an actual associated safety integrity level. As a consequence, a receiving ITS-S may use these messages to assess the reliability of the items of information described in the received messages. The evidence that the associated ITS-S has the right to describe some items of information with a pre-defined maximum level of safety integrity may be static data stored in the certificate, that are generated and validated by an authority, allowing the ITS-S to state that all or some of its shared items of information are compliant with a certain safety mode, level or standard. Accordingly, the ITS-S is allowed to assess dynamically a current level of safety integrity of items of information, that may be included in the ITS messages that are generated and adapted by ITS-S, such items of information being related to a safety mode, level or standard compliance. For example, a road operator may schedule regular audits to verify the reliability of a roadside ITS-S (R-ITS-S). Aware of these regular audits, a certification authority may distribute certificates to the R-ITS-S, allowing it to describe perceived objects or the state of regions, using its calibrated roadside sensors, with a high safety integrity level. The R-ITS-S could therefore describe as regions or objects with high safety integrity level the regions or objects specifically audited by the road operator. Alternatively, a vehicle ITS-S could also be evaluated regularly (for example while charging or during the periodic car technical inspection) ensuring high reliability and integrity. Nevertheless, this description could change through time. For example, after some time without audit or evaluation, the ITS-S could decide to modify the safety integrity level of some regions or objects to a lower value. According to another example, an R-ITS-S having enough sensors and therefore achieving a given redundancy level in a specific area, may obtain such a certificate from a certification authority. Therefore, it could describe objects perceived in a portion of the area or in the whole area in which high redundancy is achieved, with a high safety integrity level. If, for some reason, one or several of the sensors become unreliable in this specific area (therefore decreasing the overall reliability in this area), the R-ITS-S could decide to modify the safety integrity level of the perceived objects or the region to a lower value. Still for the sake of illustration, a vehicular ITS-S could decide to adapt such a safety integrity level as a function of the weather (e.g., poor visibility reduces perception reliability), or as a function of the type of detected object (e.g., LiDARs detect pedestrian less reliably than vehicles). More generally, such a description may be dynamically modified following the different Operational Design Domain (ODD) of the station. Intelligent Transport System Figure 1 illustrates an example of an Intelligent Transport System (ITS) 100 used to monitor a road having two lanes, one lane for each direction, wherein embodiments of the disclosure may be implemented. According to this example, the vehicles on the bottom lane (e.g., vehicles 105 and 106) move from left to right, while the vehicles on the top lane (e.g., vehicle 107) move from right to left. As illustrated, area 115 is monitored by road ITS station (R-ITS-S) 120 that comprises an RSU and that is associated with a set of sensors, such as one or more cameras, lidars and / or radars, for example the two cameras 110 and 112 monitoring areas 111 and 113, respectively. These sensors are used to monitor the traffic, especially to identify vehicles, pedestrians, and possibly other kinds of objects, using analytic module 121. The analytic module is used to determine a list of objects that may be described in transmitted messages, for example in Collective Perception Messages (CPM) 124 emitted by ITS station 120. Associated certificate 125 makes it possible for a receiving ITS-S to verify the identity of an originating ITS-S and the authorization to send associated CPM 124. Still for the sake of illustration, vehicles 105 and 107 are connected and autonomous vehicles (CAVs). CAV 107 comprises ITS station (ITS-S) 130 comprising analytic module 131. CAV 107 can rely on analytic module 131 and on a set of sensors (not represented) to determine its position and other properties. These items of information may be sent in Cooperative Awareness Messages (CAM) 122. In addition, ITS-S 130 comprises behavioural module 132 which is responsible for planning and controlling actions of the connected and autonomous vehicle. Certificate 123 makes it possible for a receiving ITS-S to verify the identity of the originating ITS-S and the authorization to send associated CAM 122. Similarly, CAV 105 comprises ITS station 140 comprising analytic module 141 that is connected to a set of sensors (not represented). ITS-S 140 is therefore capable of receiving and processing messages such as CAM 122 and CPM 124. ITS station 140 further comprises behavioural module 142 that may use items of information received in CPMs and / or CAMs for planning its trajectory and taking decisions. For the sake of illustration, it is assumed that vehicle 107 has sensors of high integrity and reliability, and implements processes of high integrity and reliability. It is also assumed that area 115 is monitored by highly redundant sensors and that the items of information provided by R-ITS-S 120 are highly reliable and accurate thanks to regular external audits. Therefore, vehicle 107 and R-ITS-S 120 may associate a safety integrity level (or safety level) to some items of information they may transmit into ITS-S messages (e.g., CAMs or CPMs), for example like in the embodiments described by reference to Figures 4 and 5. According to some embodiments, such a safety level is updated dynamically to take into account parameters that may cause it to vary. For example, sensor 110 may be tampered, or moved (e.g., due to a climate event), degrading redundancy and therefore reliability of R-ITS-S 120 in area 115. Therefore, this ITS station preferably adapts its safety level, for example as described in reference to Figure 6. According to some embodiments, R-ITS-S 120 may use vehicle 107 as a probe vehicle and rely on its information to update its safety level. Aware of the capabilities of the R-ITS-Ss and / or of the vehicles configured to provide items of information with a safety level, certificate authorities may provide them with certificates comprising high safety authorizations, as described in reference to Figures 3, 4, and 5. In the scenario illustrated in Figure 1, vehicle 105 is an emergency vehicle that is blocked by vehicle 106 and wants to take a risky overtaking. Since it is assumed that vehicle 106 is not a connected vehicle, vehicle 105 must rely on CAMs emitted by the ITS-S of vehicle 107 and / or on CPMs emitted by R-ITS-S 120. Due to their capabilities, the ITS-S of vehicle 107 and R-ITS-S 120 can provide items of information about area 115 with a safety level that may be dynamically adapted. Accordingly, vehicle 105, upon reception of messages from these ITS-Ss, checks whether the items of information contained in these received messages have a sufficiently high safety level for its specific need (here, a risky overtaking) to take a decision based on these received items of information. This example is described in more detail by reference to Figure 7. ITS stations Figure 2a illustrates a schematic representation of the architecture (or of a portion of the architecture) of a device generating CPMs and receiving ITS messages, for example R-ITS-S 120 in Figure 1. As illustrated, analytic module 121 is connected to one or more sensors, for example cameras 210, lidars 211, radars, etc. The sensors may be located nearby the road for a roadside ITS-S, or sensors may be embedded within a vehicle, in which case the sensors may also include a Global Navigation Satellite System (GNSS) sensor and / or an Inertial Measure Unit (IMU) to obtain an approximate position of the ITS-S. Objects detected by each sensor are analysed by sensor data fusion module 225, that may fuse objects detected by several sensors if the confidence level that they are the same objects is high enough, for example above a given threshold. This may be done by analysis of their object type, their position, their speed, their trajectory, etc. Newly detected objects or update about tracked objects are used to update environment model 230. The environment model may contain a list of objects, that may contain items of information for each tracked object such as one, some or all of the following: - a unique identifier (ID) to track the object; - a time of measurement (or perception) of the object by one or more the sensors; - the list of the sensors that have perceived the object and optionally their corresponding safety integrity level; - the object relative distance and speed from the ITS-S reference position with their confidence level (i.e., the confidence in the estimated position and speed of the object) and optionally their safety integrity level; - the object type (e.g. vehicle, pedestrian, etc.) with its confidence level (i.e., the confidence in the type of object detected) and optionally its safety integrity level; - optionally an associated V2X object ID with its confidence level (i.e., the confidence in the fusion of the V2X object with the sensor-detected object) and optionally its safety integrity level; and - a global safety integrity level per object. In addition, the environment model may contain a list of regions of interest, that may contain items of information for each region such as one, some or all of the the following: - a time of estimation of the region; - a shape of the region; - a list of object IDs contained in the region; - a list of sensors that have perceived the region; and - the global safety integrity level of the region. These regions may be computed by situation analysis 231 according to the CPM specifications. Safety integrity levels may be obtained from different ways. For example, a high sensor safety integrity level could result from some installation certification associated with regular sensor audits. According to another example, object type safety integrity levels could be dependent of the sensor type (e.g., a LiDAR would have a high safety level for vehicle detections but a low safety level for pedestrian detections). Still for the sake of illustration, an object position safety integrity level could be obtained depending on the position of the object in the Field of View (FoV) of the sensor which detected (or perceived) it (e.g., a high level being used for close objects and a low level being used for far objects or for objects located near the border of the FoV). Still for the sake of illustration, a region safety integrity level could result from a combination of objects’ safety levels or may be dependant of redundancy of sensors in the considered area. Optionally, sensor data fusion module 225 may receive ITS message information extracted from ITS messages such as CAMs or CPMs, received by the ITS-S (e.g., R-ITS station 120 in Figure 1) through its ITS module (e.g., ITS module 235). As for the local sensor data fusion, if the confidence level that an object perceived by local sensors is corresponding to a V2X object described in a CAM or a CPM is high enough, the corresponding V2X object ID contained in the message may be associated with the tracked object in the environment model. Sensor data fusion module 225 may compute a confidence level to the V2X object ID association. For example, it may compute a confidence level based on the accuracy of the position contained in the message and the one measured by the local sensors. As another example, the confidence level may be computed based on the number of perceived objects versus the number of transmitting ITS-Ss for a zone. In addition to these modules, a safety integrity assessment module 240 is responsible for modifying (or adjusting) the safety level of items of information that have to be sent in future messages, for example as described in reference to Figure 6. According to some embodiments, wherein the ITS-S is configured to detect sensor or computation issues, the safety integrity assessment module may modify the safety level associated in the environment model accordingly. According to other embodiments, wherein the ITS-S is evaluated regularly, the safety integrity assessment module may modify the safety levels based on results of the performed evaluation. In addition, the safety integrity assessment module may be responsible for analysing received V2X messages comprising some items of information associated with a safety integrity level, for example as described in reference to Figure 7. In particular, it may verify the safety level authorizations comprised in certificates as well as the level requirements for the needs of the ITS station. If there is not any safety integrity level associated with items of information received in a V2X message, the items of information may still be used as raw data in environment model 230, for other applications, or could be fused in module 225, therefore improving its safety integrity level. As illustrated, the ITS-S, for example R-ITS station 120, is configured to generate and transmit ITS messages such as CPMs and CAMs using ITS module 235. Such ITS messages may be periodically transmitted. Figure 2b illustrates a schematic representation of the architecture (or of a portion of the architecture) of an ITS-S embedded in a CAV generating CAMs and receiving ITS messages, for example ITS station 140 of CAV 105 (or ITS station 130 of CAV 107) in Figure 1. Similarly to R-ITS-S 120 illustrated in Figure 2a, ITS-S 140 comprises analytic module 141 that is connected to one more sensors. Data obtained by the latter are fused in sensor data fusion module 265 to obtain and update environment model 270. Items of information of environment model 270 are used in behavioural module 142 and may be sent in ITS messages through ITS module 275. Regions may be computed by situation analysis 271 according to the CPM specifications. In the case of vehicular stations, GNSS and / or IMU may be used to determine an approximate position of the ITS-S, with a precision of just a few metres in the case of a classical GNSS. High precision GNSS are also available but because of their relatively high cost, few stations may have a precise absolute position (e.g., with an accuracy of just a few centimetres). Other sensors (like cameras) may also be used to obtain a relative position of the ITS-S compared to road signalization such as road marking or road signs. Such information may be used to compute precisely the relative position of a vehicle inside a road lane and to know on which road lane the vehicle is positioned. Messages received through ITS module 275 are provided to the safety integrity assessment module 280 which may verify the safety level authorizations as well as its fitting for the needs of the decision and planning module 285. If the safety levels of the received items of information are not high enough, the items of information may still be used as raw data in environment model 270 for particular applications, or could be fused in sensor data fusion module 265, therefore improving its safety level. An example of steps for handling messages received through ITS module 275 is described in reference to Figure 7. Decision and planning module 285 uses the environment model and the safety levels determined by the safety analysis module to decide and plan the motion and behaviour of the autonomous vehicle (for example path planning, action prediction, obstacle avoidance, etc.). Such items of information may be described in messages such as CAMs or Maneuver Coordination Messages (MCMs). In this case, generated items of information may be provided to safety integrity assessment module 280 where a safety integrity level may be associated with the item of information (e.g., with the predicted path). Control module 290 receives information from the decision and planning module 285 and performs functions or actions related to physical control of the vehicle (such as steering, braking, accelerating etc.). Signed messages and certificate Figure 3 illustrates an example of a signed message and of a certificate, for example CAM 122 and its associated certificate 123 or CPM 124 and its associated certificate 125 in Figure 1. A structure of such a signed message and of its certificate is described in Annex A.2 of the version 2.1.1 of the ETSI TS 103 097 specification. The structure of the certificate corresponds to 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. According to some embodiments, the data to be signed comprise a payload of the message, such as payload 330 in Figure 3, and a header. The header comprises an ITS Application IDentifier (ITS-AID) 340 of the ITS application or service generating the data to be sent in a message. The header may also comprise other items of information such as a generation time 341 (i.e., the time at which the data to be sent are acquired or generated) and the generation location 342 (i.e., the location where the data to be sent are acquired), which can be omitted in some context, for example if they can be deduced or inferred from the payload content. The obtained signature 350 contains an identifier of the signer, ITS-S ID, which may be a pseudonym used by the originating ITS station, and an encrypted hashed value of the data to be signed. The pseudonym ITS-S ID makes it possible for a receiving ITS-S to retrieve the certificate of the originating ITS-S. In other words, the pseudonym may be used as a reference to the certificate. For the sake of illustration, the certificate may be requested by the receiving ITS station to a Certification Authority or may be obtained from a secure memory if it was previously received. It is noted that an originating ITS-S (or emitter station) may have several such pseudonyms (or identifiers) attributed by the Certification Authority and thus, it may obtain as many certificates as pseudonyms (or identifiers). The certificate may specify an authorized period of time, an authorized location and a list of authorized applications with specific permissions. Also, it can describe an assurance level, indicating the security of both the platform and storage of secret keys as well as the confidence in this assessment. For the sake of illustration, certificate 123 (or 125) contains a validity period 305, a validity region 310, a verification key 315, and an assurance level 316. The verification key allows verification of the correctness of the encrypted hashed value included in the digital signature 350. The certificate also contains a list 320 of items of information of one or more authorized application or service (e.g., items of information 321 and 326), each comprising an ITS Application IDentifier (e.g., ITS-AID 1, ITS-AID 2) defining the authorized ITS application or service and a Service Specific Permission (e.g, SSP1 322 and SSP2 328) defining permissions for the corresponding authorized ITS application or service. The ITS AID identifies an ITS application or service which generates messages of some given types and which is authorized by the certificate to do so. Currently, in ETSI TS 102 965 V2.1.1, one ITS AID is defined per message type (for example CAM or CPM), i.e. per operational ITS service. The allocation of ITS AID values to the ITS services is defined by a predefined allocation scheme provided in ISO / TS 17419. The ITS AIDs are 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 639 (or 0x27F) is assigned to the CP basic service. A certificate thus provides a list of ITS messages that an ITS station is authorized to send. An SSP associated with an ITS AID identifies some restrictions (or authorizations or permissions) with respect to the ability of the concerned ITS station to emit an ITS message in relation to the associated ITS service. This may restrict the type of data that can be provided within the ITS message. For example, an ITS station emitting a CAM may be entitled to send CAMs for a specific vehicle role only (e.g., emergency vehicle, public transport, etc.). No generic encoding of the SSP field is defined for the time being; each facility layer service may use its own SSP format. For the sake of illustration SSP1 322 may comprise 3 octets, referenced 323, 324, and 325, the first octet 323 identifying a version of the SSP and the second octet 324 and third octet 325 specifying specific permissions. As illustrated in Figure 3, digital signature 350 may be verified by using verification key 315. This may be done by computing a hash on the ITS message (payload and header), and by comparing the result with the hash value provided in the digital signature. If the value of the result is the same as the hash value provided in the digital signature, the signed message is considered as valid and if the result is different from the hash value provided in the digital signature, the signed message is considered corrupted. The time and location of generating the ITS message can also be checked against the validity period 305 and validity region 310 respectively. If the time of generating the ITS message does not belong to the validity period 305 and / or if the location of generating the ITS message does not belong to the validity region 310, the signed message is considered invalid. An authorization is also checked using the ITS-AID of the ITS message: a message can be processed only if the ITS-AID is present in the list of permissions (e.g., a message having ITS-AID 340 can be processed only if ITS-AID 340 is present in the list 320 of permissions. If the ITS-AID is present in the list of permissions, an additional check of the content of the message payload may be carried out based on the SSP associated with the ITS-AID, for example to verify that the emitting ITS station has authorization to provide the payload data. Safety levels The safety integrity level (or safety level) may be of different natures. According to some embodiments, it may be a Boolean value stating, for example, whether the associated piece of information is compliant with a safety standard. According to another embodiment, the safety level values may be based on the Automotive Safety Integrity Level (ASIL), defined in vehicular functional safety standard ISO 26262. The ASIL helps defining the safety requirements necessary to comply with ISO 26262. It is established by performing a risk analysis of a potential hazard by looking at the Severity, Exposure and Controllability of the vehicle operating scenario. The safety goal for that hazard in turn carries the ASIL requirements. ASIL ranges up from A (lowest safety requirements) to D (highest safety requirements). Quality Management (QM) is an additional level that dictates no safety requirement. Automotive electrical, electronic, and software suppliers must ensure that their products have been certified or otherwise accredited to the required ASIL level. Safety levels could therefore be ranged from 0 to 4 with respect to ASIL QM, A, B, C and D. Table 1 in the Appendix provides an example of safety level values based on the ASIL. In practice, considering a scenario requesting ASIL D processes, an ITS-S would have the possibility to use V2X messages including information associated with a safety level equal to 4. As another example, considering a scenario requesting ASIL QM processes, an ITS-S would have the possibility to use V2X messages including information associated with a safety level with the value 0 or with a value smaller than or equal to 4. For the sake of illustration, the safety level could be calculated similarly to ASIL, where ASIL = Severity * (Exposure * Controllability). According to some embodiments, the authorizations related to safety levels are described in SSPs of each application for which a safety level would be described. Figures 4 and 5 describe such embodiments. Still according to some embodiments, a new application is defined to describe a safety service. Such safety service would be independent of each application. The safety service could generate a new type of message containing a piece of information having a safety level or a reference to a piece of information having a safety level and described in another message. In addition, such new message could contain additional information, such as the reason why this piece of information has a safety level. For example, in the case where a road operator is performing regular audits on an ITS-S, the station may want to include the fact that it is regularly evaluated and the date of the last audit. Still according to some embodiments, the assurance level of a certificate could be used to describe authorizations. For example, a data field could be added to describe maximum safety level an ITS-S can describe. Still according to some embodiments, the validity region of a certificate could be used to specify a certain area with a maximum safety level. For example, a R-ITS-S could be authorized to describe safety levels only in one specific validity region, for example as a function of the Field of View of a specific high reliable sensor. Transmitting safety levels in ITS messages Figure 4 illustrates an example of a structure of a collective perception message, CPM, making it possible to transmit dynamic safety levels, according to some embodiment of the disclosure. The illustrated CPM structure is based on ETSI TS 103 324 specification. It comprises an ITS Packet Data Unit (PDU) header 405 and a payload 410. The disclosure is not specific to this version of CPMs and may apply to different versions of CPMs. In particular, the disclosure applies as soon as CPMs may contain data associated with at least one region. For the sake of illustration, header 405 is a common header that includes information regarding the protocol version, the message type, and the ITS-S identifier (ID) of the originating ITS-S. As illustrated, payload 410 contains a management container referenced 420 and a cpmContainers component 430, which itself comprises a Wrapped CPM container 440. Wrapped CPM container 440 may contain various kinds of containers: Originating Vehicle Container 450 (which is present if the CPM is emitted by a vehicle), Originating RSU Container 460 (which is present if the CPM is emitted by an RSU), Sensor Information Container 470 (which describes information about sensors used to generate the considered CPM), a Perception Region Container 480 (which describes some regions), and a Perceived Object Containers 490 (which describes objects perceived through sensors). The information contained in the Perceived Object Containers 490 can be obtained from the environment model 230 of the ITS-S originating the CPM. The information contained in the Perception Region Container 480 are prepared by a situation analysis module, for example situation analysis module 231 in Figure 2. The regions can be generated dynamically or statically depending on the application. For example, an application consisting in monitoring a pedestrian cross-walking would define a static region around the cross-walk area. The sensorinformation container 470 contains a description of each sensor of the ITS station such as the type of sensor (e.g., camera, lidar, or fusion), the perception region area, and the default confidence level of detections. A Perception Region Container such as Perception Region Container 480 lists information about perception regions using the type PerceptionRegion. PerceptionRegion includes the components measurementDeltaTime, perceptionRegionConfidence and perceptionRegionShape for a specific perception region. A PerceptionRegion can be used to indicate a perceptionRegionConfidence different from the perceptionRegionConfidence given in the Sensorinformation, or to mark regions where the shadowing model does not apply for a particular object. The component perceptionRegionShape should be specified as a geographical area or volume with respect to a reference position (in the case of a vehicle ITS-S generating and transmitting the CPM) or with respect to a reference point (in the case of a roadside ITS-S disseminating the CPM), for example in the East-North-Up coordinate system. Additionally, a PerceptionRegion can be used to divide the perception region of a sensor into smaller parts, e.g. in the case according to which more than one CPM need to be assembled. PerceptionRegion includes the component shadowingApplies to indicate the application of the shadowing mechanism within the given perceptionRegionShape. The shadowingApplies applies for the PerceptionRegion as stated for the Sensorinformation. PerceptionRegion may include the component sensorldList. If present, sensorldList lists the values of the component sensorld of the sensors described in the Sensorinformation which are involved in monitoring the region (i.e., perceiving objects within the region). PerceptionRegion may include the component numberOfPerceivedObjects. If present, numberOfPerceivedObjects contains the number of all currently perceived objects in the PerceptionRegion. If the number of perceived objects is zero, the perceived region is empty. This is the information which can be used in the scenario described in reference to Figure 1 to allow vehicle 105 to start a risky manoeuvre if the safety level is high enough. PerceptionRegion may also include the component perceivedObjectlds. If present, perceivedObjectlds should list the values of the component objectld of all perceived objects that are contained in PerceptionRegionShape that are not dominated by any other PerceptionRegion. Thus, each objectld is contained in at most one PerceptionRegion, while the value of numberOfPerceivedObjects may be higher than the number of elements in perceivedObjectlds. According to some embodiments, data field perceptionRegionSafetyLevel is added in a perceptionRegion, as an integer. Therefore, CPM senders are able to describe a region with a certain safety level, for example using an integer value or a Boolean value, as illustrated in Tables 2a and 2b in the Appendix, respectively. Again, a region may be described with a certain safety level that can be mapped on ASIL levels, as illustrated in Table 2c in the Appendix. Naturally, the perceptionRegionSafetyLevel data field may take any other name provided it is unique (i.e. discriminating). Still according to some particular embodiments, a safety level may be associated with sensors within a new data field sensorSafetyLevel (or any other name provided it is unique). For example, the sensor safety level may be encoded as the perception region safety level using an integer, a Boolean, or an enumerated value. This sensor safety level indicates the safety level associated with each element perceived by this sensor: the element may be for example an object or a perceived region with a number of contained objects. In such a last case, a perceivedObjectSafetyLevel may be added to the CPM perceived object container, as illustrated in Table 2d in the Appendix. Considering the example illustrated in Figure 1, RSU 120 may generate a CPM reporting data obtained from camera 110 (first sensor) and data obtained from camera 112 (second sensor). Each camera may have a limited safety level, set for example to ASI LB, that is indicated in the corresponding description fields sensorSafetyLevel. RSU 120 may also report data obtained from another sensor corresponding to the result of the fusion, in analytic module 121, of the data obtained from the two cameras. Such a third sensor would be indicated as another sensor of the type fusion, which may have a higher safety level than the one of the two cameras, for example ASILD, because it has a much higher reliability by using simultaneously two sensors making it possible to detect a hardware failure. This higher safety level may be indicated in the sensorSafetyLevel description field of this third sensor. As illustrated in Table 3 in the Appendix, a specific one-bit SSP may be added to the sender certificate to authorize a station to describe a safety integrity level in a perception region. According to a particular embodiment according to which the perception region safety level has only two possible values, it could be set as the first bit of the second octet of the CPM SSP. According to another embodiment and as illustrated in Table 4 in the Appendix, four SSPs are added to the sender certificate to authorize a station to describe a maximum safety integrity level using one bit per authorized safety level. Still according to another embodiment, three bits may be used to binary encode an integer value between 0 and 7 representing the maximum safety integrity level. Still in another embodiment, another field may be used in the sender certificate to encode the safety level. In particular, it is noted that a certificate contains a field referred to as SubjectAssurance, that is composed of eight bits. Among these bits, three bits are currently used to encode the assurance level which indicates the security of the hardware platform used to store the keys and two bits are used to encode the confidence in this assessment. According to particular embodiments, the three remaining bits are used to encode the safety integrity level, encoded as an integer to encode up to seven values of safety levels or as an enumerated to encode the ASIL levels between QM and D. Figure 5 illustrates an example of a structure of a cooperative awareness message, CAM, making it possible to transmit dynamic safety levels, according to some embodiment of the disclosure. As illustrated, CAM 500 comprises an ITS PDU header referenced 510, a Basic Container 520, a High-Frequency Container 530, a Low-Frequency Container 540, and a special vehicle Container 550. ITS PDU header 510 may be a common header including information about the protocol version, a message type (set to 2 for CAM), and an ITS-S identifier (ID) of the originating ITS-S. Each container includes some data elements (DE) and / or data frames (DF). The ETSI TS 102 894-2 specification defines conventional data elements and data frames used in ITS messages. Basic Container 520 comprises information such as the station type (category / class or RSU) and its position. High-Frequency Container 530 may be used to transmit any dynamics of a vehicle in a Vehicle HF Container such as Vehicle HF Container 535. A High-Frequency Container is transmitted in each CAM and may comprise, for example: - a Heading to indicate the orientation of the ITS-S, for example according to WGS84 north, - a Speed to indicate the speed value of the ITS-S, for example in centimetres per second, - a Lane position to indicate the lane on the road where the ITS-S is located, a lane off the road, or an island between two lanes to allow the correlation with a map, - an Acceleration to indicate the acceleration value of the ITS-S, for example in centimetres per second squared, and - a Performance class, used to describe characteristics of data sent by the ITS-Ss. It denotes its ability to provide information fulfilling additional requirements. Performance class may be set to unknown, class A or class B. Low-Frequency Container 540 is used to transmit additional information, not having place in High-Frequency Container 530 as it is static or slow-changing according to dynamics. Low-Frequency Container 540 is conditionally transmitted in CAM 500. According to some embodiments and as illustrated in Table 5 in the Appendix, the performance class could be extended to make it possible to transmit safety levels, for example safety levels based on ASIL. As illustrated in Table 6 in the Appendix, a specific two-bits SSP may be added to the sender certificate. The first bit would authorize CAM senders to describe themselves as sending certified information in performanceclass field. The second bit, associated with the first bit set to 1, would authorize the senders to describe themselves as having the performance class B characteristic. Combinations are described in Table 7 of the Appendix. For example, it could be set as the first and second bits of the second octet of the CAM SSP. When the performance class needs to take more than two possible values, a set of corresponding SSPs could be added, as described for CPMs by reference to Table 4 in the Appendix. It is observed here that Cooperative Awareness Service (TS 103 900, V2.1.1) uses the data element performanceclass which description was recently modified in the Common Data Dictionary (CDD) following change request ITSWG 1(24)068023. It now denotes the ability of an ITS-S to provide information fulfilling additional requirements, a performance class value being used to describe characteristics of data. According to the change request, such performance class field could therefore be used to differentiate between non quality managed and quality managed information. It could enable additional compliance verification of information by the receiving ITS-S, specifically for applications relying heavily on Position and Time (PoTi) data. Therefore, a security risk is introduced by this new field. A malicious station could send information with a high quality performance class indicating that it fulfils additional requirements which could impact the receiving ITS-S. The performance class field should thus have its own SSP to authorize a station to describe certified class A or B information fulfilling additional requirements. On the other hand, CAMs users should still be able to use performanceclass field without certification. Therefore, it is proposed a two-bits CAM SSP, with associated authorizations depending of the combination of the bits as described in Table 7 of the Appendix. Managing safety levels in ITS-Ss Figure 6 illustrates an example of steps that may be carried out in an originating ITS-S for managing safety levels to be transmitted with associated pieces of information in ITS messages. As illustrated, a first step is directed to obtaining pre-processed data (or pieces of information) that are ready to be added into an ITS message, in order to be sent (step 600). Next, it is determined in which extend the originating ITS-S is authorized to modify the safety levels associated with the obtained data, if any, in steps 610, 620, and 630. In particular, for each piece of information to be transmitted, it is checked whether the ITS-S is authorized to modify the associated safety level (if any), it being noted that safety levels may be associated with all the data to be transmitted in a message (step 610), with all the data of one or more specific containers (step 620), or only with the data of one or more data elements. If not any safety level is associated with the data to be transmitted in a message, the algorithm ends. On the contrary, if at least one safety level is associated with data to be transmitted in a message, it is determined whether the safety level associated with the data to be transmitted in a message has evolved (step 640). If the safety level associated with the data to be transmitted in a message has evolved, the safety level is modified with regards to the reason of the evolution (step 650). On the contrary, if the safety level associated with data to be transmitted in a message has not evolved, the actual safety level is kept for this piece of information (step 660). According to some embodiments, a safety level associated with a whole ITS message or with a container of an ITS message could respectively overwrite the safety levels of underneath containers or data elements, without any specific link with these data. Alternatively, the safety level associated with a whole ITS message or with a container of an ITS message could be defined based on a combination (e.g., the mean) of the safety levels of underneath containers or data elements. Still according to some embodiments, a more complex analysis of the underneath containers and / or data elements may be carried to define the safety level of the associated pieces of information. It is noted here that the decision to modify a safety level may vary depending on the reasons why a certification authority gives authorizations to an ITS-S to describe some safety levels. For example, in the case where a road operator would have scheduled regular audits to verify the reliability of a particular ITS-S but the last audit would be some time ago, the ITS-S could decide to modify the safety level of some pieces of information to a lower value. According to another example, an ITS-S connected to a large number of sensors in a specific area, providing a significant redundancy, may share data having a high safety level. If one or more sensors malfunction, for example if they break down, are hacked, or are disrupted by external conditions (e.g., bad weather could greatly impact visibility for camera sensors or climate events could move a sensor, decreasing the reliability of its information), the ITS-S may lower the safety level upon detecting such issues. Figure 1 illustrates an example of steps that may be carried out in a receiving ITS-S for processing received data and associated safety levels. As illustrated, a first step is directed to obtaining some data (or pieces of information) and associated safety levels (step 700), that are extracted from received ITS-S messages, for example a CPM or a CAM. Next, a test is carried out to determine whether the emitting ITS-S that sent the received message was authorized to describe the received pieces of information with the received safety levels (step 710). Such a test may comprise comparing the safety levels received in the ITS message with the maximum safety levels provided in the corresponding certificate. If the safety levels received in the ITS message are less than or equal to the maximum safety levels provided in the corresponding certificate, it may be concluded that the emitting ITS-S that sent the received message was authorized to describe the received pieces of information with the received safety levels. On the contrary, if the safety levels received in the ITS message are higher than the maximum safety levels provided in the corresponding certificate, it may be concluded that the emitting ITS-S that sent the received message was not authorized to describe the received pieces of information with the received safety levels. If the emitting ITS-S that sent the received message was not authorized to describe the received pieces of information with the received safety levels, the received data are ignored and / or may be reported (step 720), for example to a Misbehaviour Reporting Service (MRS), which could collect evidence and build a report for the Misbehaviour Authority (MA). On the contrary, if the emitting ITS-S that sent the received message was authorized to describe the received pieces of information with the received safety levels, another test may be carried out to determine whether the received pieces of information may be used for specific needs of the receiving ITS-S (step 730). Step 730 is described in more detail in Figure 8. Next, the received data that are relevant and compliant with the specific needs of the receiving ITS-S, from a safety perspective, are transmitted to the appropriate modules of the receiving ITS-S (step 740). Figure 8 illustrates an example of steps that may be carried out in a receiving ITS-S for transmitting received data to appropriate modules as a function of a safety level. As illustrated, a first step is directed to determining whether a specific data component (carrying a piece of information) received in an ITS message is needed by a given module of the receiving ITS-S (step 800). If not any data component received in an ITS message is needed by the given module of the receiving ITS-S, or if the specific data components needed by the given module have already been processed, the algorithm goes to step 870 for selecting another module of the receiving ITS-S, that has not been selected yet and that needs data components. On the contrary, if a data component received in an ITS message is needed by the given module of the receiving ITS-S, another test is carried out to determine whether there is a need for a specific safety level for the considered data component (step 810). For example, a vehicle about to perform an emergency brake would require ASIL D processes. Therefore, according to some embodiments, it could then use pieces of information having a safety level equal to 4. If there is no specific need for a specific safety level for the considered data component, this data component, that is compliant with the need of the given module, is added to a list of safety compliant data components (step 830), enabling this module to access and process the data components of that list. On the contrary, if there is a need for a specific safety level for the considered data component, another test is carried out to determine whether the safety level associated with the considered data component is greater than or equal to the safety level required by the given module (step 820). For example, a receiving ITS-S requiring a safety level equal to 3 for a piece of information checks whether such a piece of information was associated by the emitting ITS-S with a safety level equal to or greater than 3. Using a piece of information with a safety level equal to 4 would not be a problem, as the minimum required is 3. If the safety level associated with the considered data component is greater than or equal to the safety level required by the given module, the corresponding data component is added to the list of safety compliant data components (step 830), enabling this module to access and process the data components of that list. On the contrary, if the safety level associated with the considered data component is smaller than the safety level required by the given module, the considered data component cannot be used by the receiving ITS-S as raw data and should be ignored (step 840). According to some particular embodiments, data components that safety levels are below required safety levels cannot be used as raw data but can be processed to become usable (if possible). For example, such data components could be fused with data acquired from other sources or sensors, therefore improving their safety level and making them usable for the needs of the receiving ITS-S. In such a case, they can be added to the list of safety compliant data components (step 830), once it is determined that their safety level is equal to or greater than the corresponding required safety level. Next, after having added the considered data component to the list of safety compliant data component (step 830) or discarded the considered data component (step 840), the algorithm goes to step 860 to determine whether the given module needs to use one or more other data components that have not yet been analysed. If there is at least such a data component, the process is repeated with this data component (i.e., the algorithm goes to step 810). On the contrary, if all the data components needed by the given module have been analysed, another test is performed to determine whether at least one other module, not yet considered, needs data components (step 870). If at least one other module, not yet considered, needs data components, it is selected as the given module and the algorithm goes to step 810 so that the process is repeated with this given module. Once all the needed data components for all the modules have been analysed, the algorithm goes to step 880 wherein the lists of safety compliant data components are provided to the corresponding modules. It is noted here that depending on the definition of the safety level of the ITS messages and containers, the receiving ITS-S requiring some items of information with a specific safety level may overwrite containers or message or not. Example of a hardware to carry out steps of the method of embodiments of the present disclosure Figure 9 is a schematic representation of an example of a communication ITS-S device configured to implement some embodiments of the present disclosure. It may be either an ITS-S embedded in a vehicle or in a road side entity. The communication device 900 may preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 900 comprises a communication bus 905 to which there are preferably connected: a central processing unit 910, such as a microprocessor, denoted CPU or a GPU (for graphical processing unit); - a read-only memory 915, denoted ROM, for storing computer programs for implementing some embodiments of the disclosure; - a random access memory 920, denoted RAM, for storing the executable code of methods according to embodiments of the disclosure as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the disclosure; and - at least one communication interface 925 connected to the radio communication network over which ITS messages are transmitted. The ITS messages are written from a FIFO sending memory in RAM 920 to the network interface for transmission or are read from the network interface for reception and writing into a FIFO receiving memory in RAM 920 under the control of a software application running in the CPU 910. Optionally, the communication device 900 may also include the following components: - a data storage means 930 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the disclosure; a disk drive 935 for a disk 940, the disk drive being adapted to read data from the disk 940 or to write data onto said disk; - a screen 945 for serving as a graphical interface with the user, by means of a keyboard 950 or any other pointing means. The communication device 900 may be optionally connected to various peripherals including perception sensors 960, such as for example a digital camera, each being connected to an input / output interface 955 so as to supply data to the communication device 900. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 900 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 900 directly or by means of another element of the communication device 900. The disk 940 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to the disclosure to be implemented. The executable code may optionally be stored either in read-only memory 915, on the hard disk 930 or on a removable digital medium such as for example a disk 940 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 925, in order to be stored in one of the storage means of the communication device 900, such as the hard disk 930, before being executed. The central processing unit 910 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the disclosure, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a nonvolatile memory, for example on the hard disk 930 or in the read-only memory 915, are transferred into the random access memory 920, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the disclosure. In a preferred embodiment, the apparatus is a programmable apparatus which uses software to implement the disclosure. However, alternatively, the present disclosure may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Although the present disclosure has been described herein above with reference to specific embodiments, the present disclosure 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 disclosure. 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 disclosure, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged, where appropriate. Each of the embodiments of the disclosure described above can be implemented solely or as a combination of a plurality of the embodiments. Also, features from different 5 embodiments can be combined where necessary or where the combination of elements or features from individual embodiments in a single embodiment is beneficial. 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 10 that a combination of these features cannot be advantageously used. APPENDIX ASIL Corresponding safety integrity level QM 0 A 1 B 2 C 3 D 4 5 Table 1: example of safety level values based on the ASIL ASN.1 representation * This DE describes the safety integrity level of a perception region . * The value shall be set to: * - '0' to indicate that the region and its properties have no safety integrity, * - '1' to indicate that the region and its properties have low safety integrity, * - '2' to indicate that the region and its oroperties have medium safety integrity, * - '3' to indicate that the region and its properties have high safety integrity, * - '4' to indicate that the region and its oroperties have very high safety integrity. *7 PerceptionRegionSafetyLevel ::= INTEGER { noSafetyintegrity (0), lowSafetylnteqrity (1), mediumSafetylnteqrity ( 2 ) , highSafetylntegrity (3) , veryHighSafetylntegrity (4) } (0..4) Table 2a: example of a perceptionRegionSafetyLevel defined as an integer ASN.1 representation / « This DE describes the safety integritv level of region . perception * The value shall be set to: * - '0' to indicate that the region and its properties ha ve no safety integrity, * - '1' to indicate that th e region and i ts oroperties have high safety integrity. * / PerceptionRegionSafetyLevel : noSafetyintegrity (0), safetyintegrity (1) } (0..1) := BOOLEAN ( Table 2b: example of a perceptionRegionSafetyLevel defined as a Boolean Descriptive name perceptionRegionSafetyLevel ASN.1 representation * This DE describes the safety integrity level of a perception region, following the ISO26262 Automotive Safety Integrity Level (ASIL). e — '0' To indicate that the r^oion and its properties have no safety integrity (no ASIL or ASIL QM), * - '1' to indicate that the region and its properties have low safety integrity (ASIL A), * - '2' to indicate that the region and its oroperties have medium safety integrity (ASIL E), * - '3' to indicate that the region and its oroperties have high safety integrity (ASIL C), e — ' 4 ' To indicate that the r^oion and its orop^rti^s have very high safety integrity (ASIL D) PerceptionRegionSafetyLevel ::= ENUMERATED { ASILQM (0), ASILA (1), ASILE (2), ASILC (3), ASILD (4) } 5 Table 2c: example of a perceptionRegionSafetyLevel defined as the ASIL level associated with the element ASN.1 representation / :: * This DE describes the safety integrity level of a perceived object, following the ISO26262 Automotive Safety Integrity Level (ASIL). * The value shall be set to: * - '0' to indicate that the object and its properties have no safety integrity (no ASIL or ASIL QM), * - '1' to indicate that the object and its properties have low safety integrity (ASIL A)r '2 ' to indicate that the object" and its oroperties have medium safety integrity (ASIL B), * - '3' to indicate that the object and its oroperties have high safety integrity (ASIL Cj, * - '4' to indicate that the object and its oroperties have very high safety integrity (ASIL D) A / PerceivedObjectSafetyLevel ::= ENUMERATED { ASILQM (0)r AuILA (1) ASILB (2), ASILC (3), ASILD (4) } Table 2d: example of a perceivedObjectSafetyLevel defined as the ASIL level associated with the element octet bit position permission item bit value 1 0 perception Region high safety level 0 : certificate not allowed to sign 1 : certificate allowed to sign 5 Table 3: Example of an SSP added to a sender certificate to authorize a station to describe a high safety integrity level in a perception region of a CPM octet bit position permission item bit value 1 0 Perception Region low safety integrity level 0 : certificate not allowed to sign 1 : certificate allowed to sign 1 1 Perception Region medium safety integrity level 0 : certificate not allowed to sign 1 : certificate allowed to sign 1 2 Perception Region high safety integrity level 0 : certificate not allowed to sign 1 : certificate allowed to sign 1 3 Perception Region very high safety integrity level 0 : certificate not allowed to sign 1 : certificate allowed to sign Table 4: Example of SSPs added to a sender certificate to authorize a station to describe a high safety integrity level in a perception region of a CPM 5 Table 5: example of using the performanceclass to describe a safety level like ASIL octet bit position permission item bit value 1 0 performanceclass certification 0 : certificate not allowed to sign 1 : certificate allowed to sign 1 1 performanceclass B 0 : certificate not allowed to sign 1 : certificate allowed to sign Table 6: Example of an SSP added to a sender certificate to authorize a station to describe a high safety integrity level in a high-freguency container of a CAM 10 Two-bits SSP values Authorization associated 00 Station authorized to describe any performanceclass without certification 01 Reserved 10 Station authorized to describe performanceclass A 11 Station authorized to describe performanceclass B Table 7: Example of two-bits SSP combination for authorizing and certifying data described in performanceclass field in a high-freguency container of a CAM 10

Claims

1. A method of communication, in an Intelligent Transport System, ITS, comprising an ITS station, ITS-S, the method comprising, at the ITS-S:sending an ITS message referencing a certificate, the certificate comprising a predetermined safety upper-level associated with at least one item of information transmitted in the ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message.

2. The method of claim 1, wherein the ITS message comprises at least one current safety level associated with the at least one item of information, the at least one current safety level being lower than, or equal to, the corresponding predetermined safety upper-level to be valid.

3. The method of claim 2, wherein the certificate further comprises an authorization allowing the ITS-S to compute the at least one current safety level, the method further comprising computing the at least one current safety level.

4. The method of claim 2 or claim 3, wherein the at least one current safety level is determined as a function of at least one characteristic of at least one sensor used to perceive the region or the object.

5. The method of any one of claims 2 to 4, wherein the at least one current safety level is determined as a function of conditions of perception of the region or the object.

6. The method of any one of claims 1 to 5, wherein the ITS message is a Cooperative Awareness Message, CAM.

7. The method of claim 6 depending directly or indirectly on claim 2, wherein the current safety level is encoded in a performance class of a high-frequency container.

8. The method of any one of claims 1 to 5, wherein the ITS message is a Collective Perception Message, CPM.

9. The method of claim 8 depending directly or indirectly on claim 2, wherein the current safety level is encoded in a sensor information container, in a perception region container or in a perceived object container.

10. A method of communication, in an Intelligent Transport System, ITS, comprising an ITS station, ITS-S, the method comprising, at the ITS-S:receiving an ITS message referencing a certificate, the certificate comprising a predetermined safety upper-level associated with at least one item of information transmitted in the ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message, andprocessing the at least one item of information as a function of the predetermined upper-safety level.

11. The method of claim 10, wherein the received ITS message comprises a current safety level associated with the at least one item of information, processing the at least one item of information as a function of the predetermined safety level comprisingchecking the validity of the current safety level as a function of the predetermined safety upper-level andprocessing the at least one item of information as a function of the current safety level.

12. The method of claim 10 or claim 11, wherein the ITS message is a Cooperative Awareness Message, CAM, ora Collective Perception Message, CPM.

13. The method of anyone of claims 1 to 12, wherein the predetermined safety upperlevel is determined as a function of an Automotive Safety Integrity Level, ASIL.

14. A certificate, in an Intelligent Transport System, ITS, the certificate comprising a predetermined safety upper-level associated with at least one item of information transmitted in an ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message.

15. The certificate of claim 14, wherein the certificate further comprises an authorization allowing an originating ITS station, ITS-S, to compute a current safety level to be transmitted in the ITS message.

16. A method of communication, in an Intelligent Transport System, ITS, comprising an Authorization Authority, AA, the method comprising, at the AAsending, to an ITS station, ITS-S, managed by the AA, a certificate according to claim 14 or claim 15.

17. An Intelligent Transport System, ITS, message, to transmit information in an ITS, comprising a current safety level associated with at least one item of information transmitted in the ITS message, the at least one item of information being related to a perception of a region or of an object reported in the ITS message.

18. 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 13 and 16 when loaded into and executed by the programmable apparatus.

19. 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 13 and 16.

20. A device for an Intelligent Transport System, ITS, station, the device comprising a processing unit configured for carrying out each of the steps of the method according to any one of claims 1 to 13 and 16.40

Images