Describing I2V Communication in Scenarios for Simulation-Based Safety Assessment of Truck Platooning

Abstract

V2X communication plays an important role in the transition towards connected, cooperative, automated driving. Wireless communication enables instant information exchange between vehicles (V2V) to support, e.g., platooning, and between the infrastructure and vehicles (I2V) to inform vehicles on, e.g., the local speed limit information or the approach of an accident location. In the Horizon 2020 HEADSTART project, we have shown how to test V2V communication in a scenario-based safety assessment framework. Safety assessment aims to determine the impact on safety in the case of potentially critical scenarios, e.g., due to, or in parallel to deterioration of communication. In this study, we extend this methodology with the incorporation of I2V communication. The developed method allows us to treat V2V and I2V communication independently. We demonstrate the method in the use case of an Intelligent Speed Adaptation I2V-functionality for platooning trucks. The practical implementation of test descriptions that consider the potential deterioration of communication signals in the standardized OpenSCENARIO format is shown. The study illustrates how tests are performed in a hardware-in-the-loop setup specifically developed for testing platooning functions. The availability of a test method that is capable of dealing with V2X communication is an important step towards the implementation of type approval methods for Cooperative, Connected and Automated Mobility (CCAM) systems.

1. Introduction

Large efforts are taken by the industry to enable deployment of automated vehicles on the public road. Further automation of the driving task in vehicles bears the promise of increased safety on the road by diminishing the impact of human errors that potentially lead to crashes and consequential harm. Additionally, automation is expected to lead to more comfortable and efficient mobility systems.

The development of a fair and reliable safety assessment framework is important for the safe deployment of connected and automated vehicles on the public road, i.e., to test performance of perception and performance of control and decision logic. Results are important for authorities to monitor the safety of vehicles that they allow on the road and to steer policy with regard to implementation of connected and automated vehicles, and for the industry to get an understanding of how their automated vehicle performs in terms of safety on the road, as early as the development phase. According to [1], tests for safety assessment are an evaluation of test criteria (what is being evaluated using the tests), under a set of relevant specified conditions (the test cases), using quantitative safety metrics to express the outcome of the tests (e.g., as proposed by [2]) and a reference of what would be an acceptable outcome for each test. In this paper, we focus on the specification of test cases, based on real-life scenarios that describe what the system-under-test may encounter on the road in operation during its lifetime.

Safety assessment frameworks that are based on real-world scenarios are considered to be a structured way of dealing with the infinite different situations that an automated vehicle needs to be able to deal with in a safe way when deployed on the public road [3], [4,5,6]. Safety assessment frameworks consider automated vehicles that base their responses on their view of the surrounding traffic and their environment. Sensor systems based on radar, lidar and/or camera techniques collect that view, where sensor fusion on board of each individual automated vehicle is used to build a single world model [7]. The world model serves as the input to the automated vehicle’s decision and control logic, in order for the vehicle to provide an appropriate response.

A key technology to enable higher levels of automation is vehicle-to-X or V2X communication, in which “X” represents everything. This “X” can be other vehicles, as in V2V communication, or communication between vehicle and infrastructure (V2I and I2V communication). V2V communication is an indispensable technology to enable safe platooning of trucks at short (<1.5 s.) following distances [8]. For higher levels of automation, connectivity of vehicles to Intelligent Transport Systems (C-ITS) services through I2V communication is considered an important added value. This form of digitalization allows direct information exchange with the vehicle’s automation system, e.g., regarding locally applicable speed limits, the presence of roadworks, or the location of an incident [9]. This cooperative element is expected to significantly improve road safety, traffic efficiency and comfort of driving, by supporting the driver to make the right decisions and adapt to the traffic situation. It is also an indispensable step in the transition towards Cooperative, Connected and Automated Mobility (CCAM) systems.

Within the German research project PEGASUS, scenarios are described as following a 6-layer model according to [10]. The sixth layer in this model represents the digital information included in the scenario description, specifically referring to information becoming available in the vehicle through V2X communication. The PEGASUS project herewith showed that in case V2X communication is essential for the functionality of a vehicle, such V2X communication also needs to be included in the description of scenarios that form the basis for generating appropriate test cases.

In [11], we showed a concrete procedure for testing a V2V-enabled platooning functionality. Special attention was paid to the formulation of tests that result from the possible deterioration of the communication between the vehicles in the platoon, and that should reveal the impact on safety of such deterioration. The study described here, focuses on the added value of communicating messages from the digital infrastructure to the vehicle (I2V communication). In this paper, we will show how the methodology described in [11] is extended to include I2V communication in the functionality into the formulation of tests, and how such tests can be performed within the safety assessment framework for CCAM systems that has been established in the Horizon 2020 project HEADSTART [12].

Different research projects demonstrated CCAM deployments using I2V communication to improve traffic safety [13,14,15]. I2V failures and the impact on platooning vehicles supported by digital infrastructure are used in [16]. In [17], I2V is used to deploy an In-vehicle Signage (IVS) service to evaluate user acceptance in real-life deployments. For our I2V use case, we will use the Intelligent Speed Adaptation (ISA) function as an example. In this paper, we will focus on how the quality of communication influences the safety performance of such ISA functionality using model- and hardware-in-the-loop simulations.

This paper is organized as follows. In the following section, the method on how to integrate I2V communication into scenarios for scenario-based safety assessment is presented. It is shown how disturbances in the communication signals are modelled and how such models are validated by the proposed method. In Section 3, the results are provided for the safety assessment of a platooning use case extended with an ISA application. The method proposed in Section 2 is applied to a hardware-in-the-loop setup used for assessment of platooning vehicles, using test cases in OpenSCENARIO v0.9.1 format that include the relevant I2V communication parameters.

2. Approach of Testing I2V Communication

In this section, first, the role of wireless V2X communication is explained, and examples of typical V2V and I2V communication are given. Thereafter, the concept of scenarios to describe the situations that any vehicle can encounter in operation is presented, and the role of scenarios in providing test descriptions for safety assessment is explained. Finally, in this section, it is shown how I2V communication is added to the scenario description.

2.1. The Role of Wireless Communication

Figure 1 shows the different layers at which communication takes place in a V2V enabled platoon of trucks according to the Horizon 2020 ENSEMBLE project [18]. Three different layers are considered: the operational layer, the tactical layer and the strategic layer. The operational layer deals with time-critical information exchange (with a time constant in the order of 100 ms or less) to directly control the acceleration/deceleration and steering behaviour of the vehicles. In the tactical layer, additional information exchange between vehicles in the platooning system takes place. This information exchange is less time critical and deals with activities such as engaging in the platoon or disengaging the platoon, which has a time constant of several seconds. The I2V communication usually takes place in the strategic layer, where time constants might be in the order of up to one minute. Typical information that can be communicated is the locally applicable speed limit, the presence of a traffic jam, road works that are upcoming, or an incident that has happened on the route. Typically, navigation systems use the information from the strategic layer.

In a V2V enabled platoon, V2V communication, a wireless information exchange between vehicles, mainly takes place in the operational layer, similar to the decision and control logic (DCL) of the Automated Driving System (ADS) of the individual vehicle.

To enable communication, each vehicle in the platoon has a radio system with a receiver for receiving messages and potentially a transmitter for sending messages, as indicated in Figure 2. In this figure, the input-output scheme is shown in the case of wireless communication solely between two vehicles, e.g., in a platoon according to [11]. A transmitter is coupled with the ADS and provides information regarding the short-time intentions and state of the vehicle’s decision and control logic. Typically, the transmitter provides information on the intended acceleration level of the vehicle, so that the other vehicles in the platoon can anticipate the intended acceleration. A receiver acts as a sensor, receiving the information that is possibly disturbed, and providing the information to the vehicle’s decision and control logic. Based on the combined information from the vehicle’s sensor system and the vehicle’s receiver, the ADS determines which actions need to be taken by the vehicle.

Figure 3 shows the scheme for the situation in which a vehicle receives messages from the infrastructure by I2V communication with road side units (RSUs). This is a very generic situation, in which the vehicle is not necessarily part of a platoon. A typical I2V application in the strategic layer is the ISA function. In our use case, ISA is used to inform the vehicle of the locally applicable speed limit. In combination with an Advance Cruise Control (ACC) system, ISA might set the maximum speed for the ACC. The transmitter in this case is on the side of the infrastructure, e.g., an RSU that receives its information from a backend server. In addition, in this case, one has to anticipate possible message deterioration between transmitter and receiver as a result of disturbances due to, e.g., reflections, loss of line-of-sight between transmitter and receiver, or limited availability and performance of the communication channel.

2.2. Introducing the Concept of Scenarios

In the Horizon 2020 project HEADSTART [12], a scenario-based safety assessment framework is proposed that can deal with CCAM systems. Special attention is paid to the implication and impact of the use of communication on safety performance of a vehicle equipped with connected and/or cooperative functionalities that use wireless communication with other vehicles and the infrastructure. In [11], we focussed on safety assessment of V2V communication in the operational layer between vehicles in a platoon. In this paper, we will address the extension of this approach in case vehicles also receive messages through I2V communication. As a use case, we take an ISA functionality, in which a vehicle receives information on the locally applicable speed limit, e.g., to be used as an upper setpoint for its ACC.

We use scenarios to describe the situations and conditions that a vehicle may encounter on the road during its lifetime. In this way, a trip on the road can be seen as a sequence of scenarios, where scenarios might occur in parallel to each other. In a more formal way, a scenario is a quantitative description of the relevant characteristics and activities and/or goals of the ego vehicle(s), the static environment, the dynamic environment, and all events that are relevant to the ego vehicle(s) within a relevant time interval [20]. As depicted in Figure 4, this includes:

• Dynamic environment: the manoeuvres of other traffic participants such as vehicles and pedestrians;
• Static environment: the type of infrastructure, roads and road furniture;
• Conditions such as lighting and weather conditions under which the scenario occurs.

2.3. I2V Communication Added to the Scenario Description

In this section, we will show how relevant information regarding I2V communication is added to a scenario description. It is determined which activities and events in a scenario are potentially influenced by the quality of the I2V communication signal that is received in the ego vehicle. In analogy with the Safety of The Intended Functionality (SOTIF) standard ISO/PAS 21448:2019 [21], we call these triggering conditions. Triggering conditions are considered to be potential causes for disturbances that decrease the quality of the received communication signal.

In the same way that a weather condition, such as fog, can cause a camera to be less capable of distinguishing other traffic participants around the ego vehicle, triggering conditions may cause disturbances in the I2V communication channel and exchanged I2V messages. Examples of triggering conditions are:

• Multi-path reflections: the receiver receives multiple times the same signal due to reflections on objects in the dynamic and static environment, e.g., when driving through a tunnel;
• Losing line-of-sight: the direct line-of-sight between the transmitter (RSU) and the receiver (on the ego vehicle) is lost due to the local environment, e.g., obstructed by other vehicles or by road infrastructure elements like bridges;
• Availability and performance of the communication channel: this can depend on the environment (no coverage), the communication system itself (off-line), usage of the channel (congestion, overload), etc. This has an impact on experiencing message delay, messages being lost/dropped, or, in the worst-case, a complete failure of the I2V communication.

These examples of triggering conditions show that there is a direct relationship between the course of events and activities in the scenario and a triggering condition for communication. Both the scenario and the triggering conditions are required to determine the effect on the quality of the received communication signal. The triggering conditions for communication are added to the scenario description of Figure 4 as communication triggering conditions, in a similar way as for lighting and weather conditions.

3. Implementation of I2V-Related Triggering Conditions

In this section, it is explained how the truck platooning use case is extended with an ISA functionality. It is shown how this functionality is being applied to an existing Hardware-in-the-Loop (HiL) setup used for tuck platooning assessment, with adapted test cases to generically support specific I2V triggering conditions. An example of an ISA function test description is provided in OpenSCENARIO format. This section concludes with planned Field Testing of ISA functionality on urban, semi-urban and highway roads in the Netherlands to provide input to the description of test cases.

3.1. Use Case Definition for Truck Platooning

The starting point is a truck platooning use case using the ENSEMBLE Platooning Support Function (PSF) [22]. The platooning function itself is supported by V2V communication. Our study investigates the platooning use cases with additional digital infrastructure support (I2V) to enable ISA functionality.

3.1.1. ISAD Classes

With I2V connectivity technically part of the use case, we identify the level of support expected from the digital infrastructure surrounding the platooning vehicles. We use the classification scheme for the infrastructure support for automated driving (ISAD) as defined by [23]. In general, a differentiation between conventional and digital infrastructure is made, and each of these categories is further split into subcategories, ranging from E (no infrastructure support for an ADS) up to A, which enables cooperative driving with the guidance from respective digital infrastructure. In this paper, we focus on level (C), in which infrastructure information is available in digital form that can be provided to ADS functions. The I2V communication extensions are applied to the scenarios used for assessment in an existing HiL setup for truck platooning. We use this practical approach to demonstrate the proof-of-concept of including I2V communication in a generic way for scenario-based assessment.

3.1.2. Intelligent Speed Adaptation for Truck Platooning

For truck platooning, the V2V communication enables the PSF [22] for which data from the operational layer are exchanged between the vehicles (see Figure 1). The ISA function operates in the strategic layer, and, via I2V communication, it provides optimal speed advice based on the locally applicable speed limit and the local traffic conditions surrounding the ego vehicle. This could be dynamic speed advice based on the current traffic situation, such as traffic congestion upstream, nearby roadworks, etc. In a more straightforward I2V solution, only the locally applicable speed limit is communicated to the ISA function, as a static message that only depends on the time of the day (according to ISAD level C), e.g., when during different periods of time, different speed limits are applicable.

With the truck platoon in nominal platooning mode, the ISA functionality is only relevant for the first or leading vehicle as other vehicles are following the leading vehicle. Nevertheless, the other trucks in the platoon are able to receive the I2V messages, and might respond to this information, e.g., if the response of the leading vehicle is considered inappropriate given the received I2V messages.

In ENSEMBLE, the nominal platooning is defined for highway situations considering a single lane deployment [24], as depicted in Figure 5. An RSU is used for the I2V interaction with the platoon. It can provide a new maximum speed policy or information to adjust the minimum distances between the platooning vehicles. In platooning mode, the leading vehicle will adjust its cruising speed to the received ISA information, and the other vehicles will adapt accordingly. If somehow the leading vehicle does not adapt its speeds, it is still possible for the other platooning vehicles to respond to the ISA information, decide to adapt their own speed, and if needed leave the platoon.

For safety assessment, it is important to notice that the ISA information provided via I2V is only relevant for non-safety-critical decision and control processes in the tactical or strategic control layers. By definition, it is not part of the PSF. The platooning and ISA functionality need to be designed so that disturbances in the I2V communication never trigger any safety-critical situation. Nevertheless, the inclusion of such communication in scenarios is still relevant to validate whether I2V communication disturbances indeed do not trigger safety-critical situations, and to assess the validity of the I2V information with respect to the area of relevance, in time (delay) and content (correct speed information).

3.2. Testing Solution for Truck Platooning

The HEADSTART project focuses on providing test methods with an emphasis on the testing of several key enabling technologies for automated driving. Four main testing methods have been identified [19]:

• Virtual Testing (VT): software-only based testing solutions;
• XiL-based testing (X-in-the-loop): a combination of Software-in-the-Loop (SiL), Model-in-the-Loop (MiL) and Hardware-in-the-Loop (HiL) test setups. XiL testing ranges from relatively simple setups including some hardware, to much more complex setups including complete Vehicle-in-the-Loop test environments.
• Proving Ground testing: testing in a well-controlled test environment on dedicated test tracks and non-public roads;
• Field Testing (FT): testing on the public roads under real-world traffic conditions.

The starting point for the practical approach presented in this paper is a HiL setup used for the assessment of ENSEMBLE truck platooning “reference” implementation. This HiL setup has been extended to explore the possibilities of testing, validating and assessing a truck platooning use case including V2V and I2V communication functionality, with possible deterioration of the V2V and I2V communication due to triggering conditions. It has been investigated how to integrate V2X communication in a more generic way, as part of scenario-based assessment using a HiL test setup.

3.2.1. HiL-Based Testing Solution for Truck Platooning

The scope for our approach, is a Hardware-in-the-Loop setup designed for testing ENSEMBLE truck platooning including V2V communication [19]. The HiL setup is a combination of hardware and software components running on multiple platforms. A flexible HiL setup is used in which hardware components can be replaced by software components, and hardware systems can be extended and/or interchanged, depending on the testing requirements. We use this setup to explore the testing of specifically the V2X communication, and for the validation of models used in scenario-based assessment. For this paper, the focus is on generic I2V extensions according to the framework proposed in HEADSTART [25].

Figure 6 provides a high-level view of the HiL setup, which is based on the implementation for the ENSEMBLE project and which has been extended for the HEADSTART project. The HiL setup covers a three-truck design. In the figure, only the “Following Truck” instance has been detailed. A similar scheme holds for the Leading Truck and the Rear (or Trailing) Truck instance. The actual implementation of the ENSEMBLE platooning functionality is indicated by the purple box. This implementation offers the functionality needed for platoon manoeuvring, coordination, status updates and exchange, etc., supported by the specific V2V platooning messages: Platoon Control Message (PCM) and Platoon Management Message (PMM) [26]. The blue box represents the exchange of V2V messages between the trucks in the platoon. The orange boxes are related to world modelling (WM, sensor simulation and fusion), vehicle control and human machine interaction (HMI). The simulator box in grey is for simulation control and relates to the simulator environment (e.g., visualization and test automation using scenario files). The blue box in the figure is extended with I2V communication and fault injection capabilities, as part of the generic test execution.

The HEADSTART HiL setup is more focused on V2X testing and assessment supporting generic extensions. See

Table 1. Functional adaptation of the HiL setup from the ENSEMBLE implementation to the HEADSTART implementation [19]. indicates that the implementation makes use of the functionality, means no use is made of the functionality and shows that a specific implementation has been added to the ENSEMBLE HiL.

Functionality	ENSEMBLE	HEADSTART
Simulation environment
Simulated sensors (radar, camera, lidar)
Simulated vehicle dynamics and low-level controllers	High fidelity	Mock-up implementation
Longitudinal control		Mock-up implementation
Platoon maneuver coordination, platoon status	ENSEMBLE implementation	ENSEMBLE implementation
V2X communication
V2X fault and parameter injection		HEADSTART solution
Test automation	OpenSCENARIO v0.9.1	OpenSCENARIO v0.9.1 HEADSTART V2X extensions
Sensor fusion, object and host tracking	High fidelity	Mock-up implementation
2D and 3D visualization

for an overview of both HiL setups. The HEADSTART HiL setup differs from the ENSEMBLE HiL setup in two ways. First, vehicle control and world modelling are performed by mock-up implementations for HEADSTART, this is to simplify the software modules and dependencies. The used Control and World Modelling functionalities are still capable to drive and platoon the vehicles in a virtual simulation world. This is enough to support the HEADSTART V2X test cases.

Second, I2V communication extensions are made to support an ISA function. For this, an RSU communicates local temporally adjusted speed limits via In-Vehicle Information (IVI) messages [27] to the platooning vehicles. An IVI message contains per-lane information, comparable to the information shown in a gantry or speed limit signs on highways.

3.2.2. V2X Network Parameter and Triggering Conditions

In the HiL setup, a new component is designed to control V2X parameters and triggering conditions and to add failure modes at runtime into the system. In principle, this component interferes with the I2V communication at a high level to make the desired changes during “transmission” of the message from an RSU towards a vehicle. These injections are integrated into the already existing HiL test automation infrastructure by modifying the OpenSCENARIO v.0.9.1 specification [28], and also by a HiL OpenSCENARIO parser and executer modules. The relation of the V2X parameter and fault injection component with the other HiL components is illustrated in Figure 7.

The light blue box represents the I2V communication network(s) from a transmitter (RSU) towards the receiving vehicle. Relevant I2V communication parameters can be controlled via the OpenSCENARIO Executer, and is integrated into the Simulator so automation of running test cases with I2V scenarios is possible. The I2V parameters under control or faults to be injected during test execution are, e.g., IVI message delay or loss of IVI messages. More details of the proposed parameter and fault injection settings and modification at OpenSCENARIO specification are elaborated in Section 3.3.2.

3.3. ISA for Truck Platooning

An ISA function is shown in Figure 8 as an example of an I2V use case. The test plan from [23] is taken in which the platoon receives a new maximum speed policy, and the platoon adapts the speed accordingly. In principle, all vehicles can receive IVI messages communicated via I2V. For the PSF, the received new maximum speed is presented on the HMI of the driver of each truck in the platoon. The leading vehicle will automatically adapt its ACC set speed based on this new speed limit information. Via V2V communication, the “maximum platooning speed” is updated across the platoon. Herewith, the other vehicles in the platoon follow their preceding vehicle and will remain a constant time-distance gap between each other.

3.3.1. Test Case Definition and Automation

An important capability of the HiL setup is the ability to execute tests defined in OpenSCENARIO (OSC) files. This guarantees deterministic test definitions, repeatability in the test execution and enables scenario-based test automation.

The HiL setup uses OSC files to extract event-based instructions. These instructions are used by the HiL setup to initiate a simulation environment and vehicle software (control, world modelling, platoon state machine, etc.) in the proper order. Subsequently, vehicles (position, speed, etc.), vehicle states (ACC-state, platoon-state, etc.) and any other events are manipulated regarding the conditions defined in the test instructions. In the sequence diagram of Figure 9, the OpenSCENARIO execution of the HiL is explained for the ISA test case.

3.3.2. I2V in HiL Simulations

This section describes the method to test the influence of triggering conditions on I2V communication and the resulting impact on the system performance with HiL setup test cases for truck platooning. The focus has been on the integration of I2V communication to support the ISA use case with the exchange of IVI messages in a V2V truck platooning situation.

OpenDRIVE (ODR) and OSC files are used to describe the static and dynamic environment for a test case [28]. An OSC file describes manoeuvres of vehicles in a storyboard. The vehicle manoeuvres are described by vehicle activities (e.g., accelerating, braking, changing lanes) that are triggered by specific conditions (e.g., vehicle speed, distance, position). Currently, the OSC file format does not support the description of the effect regarding V2X communication in test cases.

Infrastructure components (such as tunnels, buildings) that can affect the V2X communication are described in ODR files. Based on, e.g., the height and length of a tunnel described in the ODR file, the V2X communication parameters such as message delay, packet loss or loss of signal are affected. Similarly, there is a possible relation between the deterioration of communication and weather conditions as described in the OSC file. The V2X communication parameters can be set based on the weather conditions. However, it is not desirable to determine the V2X communication parameters in such an indirect way, as the effect of a tunnel or weather conditions on V2X communication can be interpreted differently by different simulation tools.

To prevent this difference in interpretation, the changes in I2V communication parameters, such as signals strength (range), latency and reliability (message drop), are chosen to be defined independently and specifically. We have chosen to describe the level of deterioration of V2X with communication signals directly in the test cases, which allows us to introduce V2X failure modes in a controlled manner in a test. So, depending on the triggering conditions, certain V2X parameters are relevant and those parameters in relation to the triggering conditions are controlled directly in the description of the test cases in an OSC file.

For the definition of the ISA I2V test cases, the V2X parameters and triggering conditions are added with a new element CommunicationAction to the existing OSC file format. The idea is that this allows to generically add “actions” that effect the I2V communication network performance. Child elements of CommunicationAction can be different types of I2V networks and types of messages to support I2V.

Table 2. Additional OpenSCENARIO element definitions to enable inclusion of I2V communication in the OpenSCENARIO format.

Element Name	Parent Element	Child Element(s)	Attributes (and Description)
CommunicationAction		CellularNetwork
	PrivateAction	MessagesIn MessagesOut
CellularNetwork	CommunicationAction	CellularNetworkSpeed CellularNetworkLatency CellularNetworkReliability	name generation (2/3/4/5G) cellSize
CellularNetworkSpeed	CellularNetwork	-	averageDownloadSpeed averageUploadSpeed maxDownloadSpeed maxUploadSpeed
CellularNetworkLatency	CellularNetwork	-	delay jitter jitterType
CellularNetworkReliability	CellularNetwork	-	factor (messages received/lost)
MessageIn	CommunicationAction	Message	-
MessageOut	CommunicationAction	Message	-
Message	MessageIn	-	name
			value
	MessageOut	-	frequency
			networkName

gives an overview with some general descriptions of the I2V communication actions, network elements and their child elements and attributes. Networks like CellularNetwork, or short-range Intelligent Transport Systems (ITS)-based ITSNetwork can be added. It is possible to introduce different relevant I2V parameters (child elements: Speed, Latency, Reliability) with different levels of complexity (very basic high-level models versus more complex and detailed low-level models are possible). This makes this way of working scalable for model complexity. Moreover, multiple networks can be defined making this approach scalable to support multiple technologies and allowing for multiple communication systems per vehicle. In addition, it is possible to define specific messages (child elements: MessageIn, MessageOut) to support different use cases. For the ISA use case, IVI messages are used for the I2V exchange from roadside infrastructure to the platooning vehicles.

For the ISA use case, the V2X network parameters can be changed in the OSC storyboard as a private action, and the ISA information is provided in the message definitions. Figure 10 gives an example to provide ISA related speed limit information as entering a new speed limit area according to the example provided in Figure 8.

In the ISA example above, the speed limit information is provided via the Cellular_I2V network. For this example, the network has a constant message delay (CellularNetworkLatency delay = 25 ms) and no messages are dropped (CellularNetworkReliabilty factor = 1.0)

The listing in Table 2 can be easily extended with other parameters depending on test case needs for I2V triggering conditions, I2V model complexity, used I2V network technologies and messages, or based on specific V2X assessment needs.

At the vehicle level, the V2X communication acts as a sensor with a new OSCCommunication element. One or multiple communication units can be added, that are used to “connect” to multiple I2V networks as defined in CommunicationAction network elements. The OSCCommunication element compares as adding an OBU (onboard unit) and it is placed in the OSC OSCVehicle element.

3.4. Field Testing of ISA

One of the test methods in HEADSTART is Field Testing. Field testing is used to validate the I2V communication extensions as applied in the HiL setup test cases under real-life conditions. For the ISA functionality, we use IVI messages to be exchanged via I2V communication. The connectivity is based on cellular technology. The vehicles can subscribe to the ISA service and will receive the relevant IVI messages based on their actual position. The ISA service is deployed for a combination of urban, sub-urban and highway roads in the surroundings of the Automotive Campus in the Netherlands.

To test the specific ISA functionality and to get access to possible triggering conditions and the potential deterioration of the received signal in the ego vehicle, field tests are going to be performed. Field tests are expected to reveal the quality of the ISA messages that are received in the vehicle over the stretch of road for which ISA information is made available. The vehicles will cross 11 different speed limit zones while driving from the Automotive Campus in Helmond towards Eindhoven and back. In the test vehicle, which is equipped with an accurate GPS inertial navigation system, all I2V communications from the digital Infrastructure are logged synchronously with accurate time and location measurements. In addition, the vehicle will be tracked using a video-based monitoring system while driving through the different speed limit zones. In the vehicles, the received IVI messages are logged and enriched with current vehicle information for assessment purposes. Evaluation will focus on I2V communication performance with respect to availability, reliability, latency, correctness and timing of actual IVI information provided to the vehicles.

4. Discussion

The application of V2X communication technology is important for the introduction of CCAM systems at a large scale. In HEADSTART, a methodology is developed for safety assessment of such CCAM systems. While in [11], we showed how to deal with V2V communication in the safety assessment of platooning trucks, in this paper, we have focused on the addition of I2V communication, in which information transmitted from the roadside (infrastructure) is considered in the decision and control logic of the vehicles that are capable to receive such information. For an ISA functionality as an example, we have shown how to address potential deterioration of the received signal in the description of tests for the scenario-based safety assessment. Typical parameters describing the deterioration of V2X communication between transmitter and receiver are:

• The encountered communication delay at any moment in time.
• The number of messages lost over the different instances that message loss occurs (given a certain message frequency).
• The moments in time when communication loss was detected (the number of messages lost increases over a pre-defined threshold), and the level of the threshold.

From field operational tests of platooning functions in several projects (e.g., ENSEMBLE [18]), experience is available on the possible deterioration of V2V communication, also in the relation between the level of deterioration and triggering conditions in scenarios such as crossing a steel bridge or driving through a tunnel.

In the generation of scenario-based tests, similar to V2V communication, there are two options to include deterioration of I2V communication at the level of the communicated messages, i.e., as a disturbance to an ideally transmitted message at the side of the receiver (see Figure 3):

• By stochastically sampling the deterioration parameters independent of the scenarios that are simultaneously occurring.
• By relating the deterioration parameters to the scenarios, for those scenarios that have been shown to influence the signal quality as a result of triggering conditions, e.g., driving through a tunnel or over a steel bridge.

Field tests are required to identify and characterize the communication signal deteriorations and to provide input to both options A. and B. In the methodology, option A. is preferred in the context of HEADSTART as to test the effect of deteriorations of communication in any type of scenario, independent of the source of the deteriorations. Section 3 shows how the parameters are introduced in the description of tests using the OSC format.

Feasibility: On a practical implementation in a HiL setup for Truck Platooning, it has been shown that this approach for including the influence of communication in the safety assessment of the individual trucks in the platoon is feasible. The scenario descriptions have been extended to include digital infrastructure support with I2V communication, relevant I2V parameters and triggering conditions for a concrete ISA use case. In future research, it needs to be explored what the limitations are of the current HiL setup for a more generic extension with V2X communication.

Scalability: The proposed method is scalable, as in the ISA implementation, it has been shown to be possible to define multiple I2V networks, add I2V parameters and triggering conditions and use multiple I2V messages.

Maintainability: As the OSC format has been used as a single interface to address V2X in the description of safety assessment tests, we adhere to a commonly accepted standard. This makes software tools for test case generation easy to maintain, as only the latest formal standard of OSC needs to be followed.

Extensibility: Moreover, the followed approach to incorporate V2X communication using OSC simplifies the extension of the scenario-based safety assessment with new communication-based functionalities, new features and new definitions. It has been shown in this paper that adding a new I2V network component in HiL testing is easily possible. Similarly, the developed structure makes it easy to add additional triggering conditions.

Each of these features have been shown by making extensions to an existing HiL setup that was originally developed to test the platooning functionality in the ENSEMBLE project. In addition of the V2V communication required for efficient platooning, we extended the HiL with a practical description of I2V communication, in an Intelligent Speed Adaptation use case. Extending scenario and V2X integration has been done based on the current HiL capabilities (hardware, software) using a straightforward and logical approach. The generic extensions are not based on specific solutions. The integration of other middleware or 3rd-party tooling such as available communication model simulation software (e.g., ns-3, Opnet, VSimRTI,), micro-simulations (e.g., SUMO, Simcenter PreScan, IPG carmaker), emulation hardware, or other open source interfacing are considered out-of-scope.

Herewith, it was demonstrated how to consider V2V and I2V communication in the description of scenario-based tests, also the practical implementation into OpenSCENARIO and the testing using the extended HiL setup in view of the HEADSTART project was shown.

5. Conclusions

This paper shows how infrastructure-to-vehicle (I2V) and vehicle-to-vehicle (V2V) communication are considered in test descriptions using the OpenSCENARIO v0.9.1 format and how to apply tests involving V2X communication in a hardware-in-the-loop (HiL) setup. Insights are provided on the typical parameters that describe deterioration of V2X communication between transmitter and receiver, such as delay, message loss or communication loss. A truck platooning use case has been considered that uses V2V communication for establishing and maintaining a platoon, and I2V communication for Intelligent Speed Adaptation (ISA) for the leading truck in the platoon. Hardware-in-the-Loop (HiL) tests are used to reveal the impact on safety of the possible deterioration of communication signals in various relevant scenarios on the road that a platoon can run into.

The implementation that TNO has chosen to incorporate V2X communication in the OSC format allows to consider the deterioration of the I2V communication independently from the deterioration of the V2V communication. To determine realistic values for the parameters describing the deterioration of the I2V communication, tests are planned to be conducted on the public road in the Netherlands with a Proof-of-Concept ISA implementation in view of the Dutch TKI project StreetWise+ [29]. A 5G solution to communicate speed limit information through I2V is available through the 5G MOBIX project [30]. The tests also aim to study the possible relationship between deterioration of I2V communication and the presence of triggering conditions in certain scenarios. The results are important input in the scenario-based safety assessment of vehicle-functions that make use of V2V and/or I2V communication. The method described in this paper enables this type of testing, e.g., using a HiL setup.

In the next paper, it will be shown how the results of the executed tests are used to provide realistic model descriptions of the deterioration of I2V and V2V communication. These models will then be used in the described HiL setup. Additionally, collected test data are used to validate the HiL setup by comparing simulated results for the scenarios encountered in the real world, with the vehicle responses recorded during the tests.