Method for safety testing of v2x-based applications

Abstract

A comprehensive method suitable for the safety testing of V2X-based applications enables the determination of safety-critical vehicle functions — such as driver assistance, emergency warning, and collision avoidance system characteristics— based on configured and measured network performance metrics and vehicle dynamic parameters. The method ensures that tests are properly prepared and executable in accordance with requirements relating to specified vehicle dynamic parameters, network performance indicators, and noise characteristics. The method includes the coordination and activation of the elements of a test system, followed by verification of whether a detailed data-level description of the test scenario is available. The testing procedure further includes the confirmation of the readiness status of the participants, the coordination of a synchronized test start time, and the configuration of parameters of the test environment, such as network performance indicators and radio- communication interference conditions. During the test, the motion, speed, and position of real and simulated participants are continuously adjusted in accordance with the requirements of the scenario. Based on the recording and evaluation of the results, the method can handle identified errors, modifying parameters, and, if necessary, restarting the test, thereby ensuring compliance with the requirements and enabling a final conformity assessment.

Description

[0001] M ethod for safety testing of V2X-based applications

[0002] The invention relates to a method according to the preamble of Claim 1 for safety testing of V2X-based applications. The proposed method is suitable for examining and testing safety-critical vehicle functions based on Vehicle-to-B / erything communication (V2X), such asdriver assistance systems, emergency warning systems, and collision avoidance systems.

[0003] The development of highly automated, connected vehicles and wireless communication technologies provides significant advantages in terms of transportation safety and efficiency. Autonomous vehicles can make independent decisions and operate in traffic, while communicating with their environment via wireless connections, such as with other vehicles, roadside infrastructure units, and various participants in the traffic ecosystem. This technology is known as V2X (Vehicle-to-B / erything), for which several alternatives exist, including ad-hoc Wi-Fi-based communication aswell as comm unication based on cellular network technologies. However, these complex systems are not immune to disturbances and noise, which raises reliability concerns. The main reason is that thequality of wireless communication (QoS- Quality of Service) may influence data exchange between vehicles and its reliability. For example, radio channel congestion may cause interference problems, which can hinder the clear and high-quality transmission of signals. Environmental parameters such as adverse weather conditions, geographical obstacles (radio signal shadowing), and the distance between the transmitter and receiver can also significantly affect connection quality. Problems related to radio wave propagation also include cases where the environment-perception sensor under investigation does not have a direct line-of-sight to the object, meaning that another object obstructs the target within the sensor’s field of view (Non-Line-of-Sght, NLoS). Another characteristic issue associated with radio communication is transmission latency, which may particularly occur in satellite-based networks and cellular communication systems, such as Cellular V2X (C-V2X). In addition, cyberattacks, such as denial-of-service attacks (DoS'DDoS), may also threaten the security and reliability of communication.

[0004] If the quality of communication is insufficient, the information may be delayed, partially unavailable, or even completely unavailable. The absence of critical information may pose safety risks and may lead to accidents. The lack of information arriving through the wireless communication channel is particularly critical when other environmental sensors are also unable to provide reliable information (e.g., poor visibility conditions, extreme weather conditions, or objects that obstruct the propagation of light and radio waves).Numerous solutions have been developed in the field of the development and testing of autonomous vehicles and V2X technology that aim to minimize safety risks. These include the development of various communication protocols, testing methods, and risk analysis techniques. In thefollowing,thesolutionsthat are closest to thepresent invention aredescribed, aswell asthe differences between those solutions and the present invention.

[0005] US2016 / 0071417 A1 generally relates to a vehicle collision avoidance system, but it does not include the system architecture and steps required for testing the function. Accordingly, it does not contain a coordination unit supporting the efficient coordination of tests, nor a humanmachine interface unit.

[0006] US2018 / 0208195 A1 relates to systems and methods for automated control of autonomous vehicles. The document presents a control solution and doesnot relate to a test system or testing methodology. Accordingly, it does not contain a coordination unit supporting the efficient coordination of tests, nor a human-machine interface unit.

[0007] US 10,631 ,269 B2 discloses a collision avoidance system and method based on V2V communication, which takes security risk levels into account. However, the invention does not relate to a test system. Accordingly, it does not contain either a coordination unit supporting the efficient coordination of tests or a human-machine interface unit.

[0008] US9,762,470 B2 discloses a method that enables the determination of performance criteria for vehicle communication networks. The invention does not relate to a test system, but rather to the determination of network performance indicators. Accordingly, it does not include a coordination unit supporting the efficient coordination of tests, nor a human-machine interface unit.

[0009] A report DOT HS 812 298 documents test procedures for a specific Forward Collision Warning (FCW) application, as well as the results of vehicle testing carried out using the presented methods. Thedocument doesnot addressthe network performanceof V2Xcomm unication, nor the cases in which the reliability of wireless communication is insufficient. Furthermore, it does not include a coordination unit supporting the efficient coordination of tests or a humanmachine interface unit.

[0010] EP 4087306 discloses a general V2Xtest system and its mandatory components. However, the invention does not take network performance indicators into account and does not include a coordination unit supporting the efficient coordination of tests or a human-machine interface unit.A document P-180092 issued by the automotive organization 5G Automotive Association (5GAA) defines testing procedures for system-level functional and performance testing of V2X systems. The documents proposed by 5GAA assist in test planning and prescribe various performance indicators that must be recorded during measurements. These include the measurement of latency and packet loss; however, the documents do not address safety impacts. Furthermore, the document does not include a system component suitable for generating network interference, nor doesit include a coordination unit supporting the efficient coordination of tests or a human-machine interface unit.

[0011] A safety-critical vehicle function based on wireless communication must be tested in terms of safety and reliability to ensure that the given function does not pose vehicle safety risks. The generation of communication disturbances and the measurement of their effects are key elements during the development and testing of V2X systems, particularly in the case of critical applications, such as collision avoidance systems, emergency braking warnings, and other traffic safety-supporting applications.

[0012] During testing, it is necessary to obtain and collect data based on which it can be verified within which operating ranges the safety of the examined vehicle function can be guaranteed, and to what extent it is sensitive to changes in the quality of V2Xcommunication.

[0013] The technology related to V2X-based vehicle functions is currently in the early stage of standardization, technological definition, and industrial application. This technology cannot yet be considered fully mature in several respects, and many questions remain regarding the technical parameters of the communication solutions to be applied. B / en among standard industrial solutions, several competing or alternative technologies exist, such as Dedicated Short-Range Communication (DSRC) and cellular network-based communication (Cellular V2X / C-V2X).

[0014] Due to the current level of technological maturity, V2X-based vehicle functions are primarily used for convenience features or for tasks that do not require direct intervention by the automated vehicle systems. Consequently, scientific and industrial research groups working on the development and investigation of thisfield are not yet focusing on complex and advanced testing systems for the different solutions, but rather primarily on the development of the solutions themselves and on improving their efficiency.

[0015] Current development trends and results clearly indicate that the application of wireless communication in the automotive industry carries significant potential for improving safety. Thispotential can be effectively utilized if it becomes possible for vehicle systems to automatically use information received through the V2X communication channel and to intervene directly in the driving process based on that information. In this way, the adverse effects of human error can be reduced or eliminated. Therefore, the testability of safety-critical vehicle functions based on V2X communication will contribute in the future to the widespread adoption of vehicle functions based on wireless communication, and thus to the improvement of road safety. Accordingly, the objective of the present invention isthe practical examination of the capabilities and reliability of such systems, more specifically, the development of a method that enables such testing.

[0016] The present invention is based on the following fundamental recognitions:

[0017] Unlike conventional vehicle systems, due to the operational concept of V2X-based vehicle functions, the safety of these systems cannot be adequately assessed from the perspective of a single technical domain. A method is required by which the safety risks of V2X-based vehicle systemscan be determined and characterized by simultaneously considering vehicle dynamics factors (e.g., speed, acceleration, heading angle), communication factors (e.g., noise level, latency, packet reception rate), and safety-related factors (e.g., time to collision, temporal gap between crossing vehicles, etc.).

[0018] Owing to the operational concept of V2X-based vehicle functions, the set of factors influencing safety (e.g., noise level, latency, packet reception rate, vehicle speed, acceleration, heading angle, time to collision, etc.) does not depend on the applied communication technology. Therefore, a method is required by which the safety risk of a V2X-based vehicle system can be characterized in a comparable manner, independently of the communication technology used.

[0019] More precisely, the objective of the invention is to create a testing method that is suitable for testing safety-critical scenarios, for example scenarios in which the trajectories of physical participants intersect at a conflict point.

[0020] The above objective is achieved by a method according to the features of claim 1 for the safety testing of V2X-based applications, which in a novel manner comprises:

[0021] switching on a test system performing the examination, and checking whether, after switching on, a detailed, data-level description of the test scenario to be executed is available;where, if the description of the test scenario is not available, loading it separately and then repeating the verification;

[0022] iterating through the individual steps of the detailed, data-level description of the test scenario, and during this process examining, by means of the test system, whether the other system elements required for implementing the test scenario are switched on, functioning properly, and ready for starting the test;

[0023] where, if all participants and system elements are switched on, operating properly, and ready for starting the test, checking whether the planned start time of the test has been accepted by all participants, for which purpose message exchange is performed via the test system, based on the test scenario, with all participants and system elements regarding the planned start time of the test and their readiness status, followed by qualifying the test as execu table / st art able; if not all participants and system elements are switched on, repeatedly checking whether the result of the examination has changed over time regarding whether the system elements required for implementing the test scenario are switched on, functioning properly, and ready to start the test;

[0024] if the planned start time of the test has not been accepted by all participants, repeatedly checking whether the result of the examination has changed over time regarding whether the planned start time has been accepted by all participants;

[0025] if the repeated examination yields a positive result, qualifying the test as executable / startable; if the repeated examination remains negative, recording and storing data relating to the start, suspension, or interruption of the test, eliminating the cause of the suspension or interruption, and returning to the step of iterating through the detailed, data-level description of the test scenario;

[0026] after starting the test, in order to ensure that during the period between the start and completion of the test scenario execution the vehicles under test and the real and simulated traffic participants are located at spatial positions corresponding to the detailed, data-level description of the test scenario, move along the defined trajectories and proceed with the specified speed, heading angle, and acceleration, continuously setting the spatial positions, trajectories, speeds, heading angles, and accelerations of the modeled virtual participants according to the test scenario at every moment of the testing process; additionally generating and emitting an interference signal that influencesthe tested V2X communication according tothe noise characteristics specified in the test scenario, and continuously measuring the performance of the network used to perform the test;

[0027] based on the communication between the real traffic participants under test, the simulated traffic participants, and a central control station, wherein the real and simulated traffic participants transmit to the central control station their current position, speed, acceleration, and direction, checking whether the communication disturbance (radio signal interference) corresponds to that described in the test scenario; further checking whether the network performance indicators correspond to those described in the test scenario, and whether the movement of the real and simulated traffic participants corresponds to the description of the test scenario; and

[0028] if the verification that the communication disturbance corresponds to the test scenario yields a negative result, continuously controlling and fine-tuning the characteristics of the generated interference signal based on continuously monitored measurement data;

[0029] if the verification that the network performance indicators correspond to the test scenario yields a negative result, continuously controlling and fine-tuning the values of the set performance indicators based on continuously monitored measurement data;

[0030] if the verification that the movement of the real and simulated traffic participants corresponds to the test scenario yields a negative result, sending instructions to the traffic participants to modify at least one of the following parameters: speed, acceleration, or direction; performing continuous data recording during the period between the start and completion of the test scenario execution;

[0031] checking the compliance of the performed test based on the measured and recorded data; if the requirements relating to the aspects examined during the test are not fulfilled, or are only partially fulfilled, or if the errors identified during the test fall outside predefined permissible ranges, attempting to resolve the testing problem or problems by modifying the parameters used during the test according to professional considerations, and then returning to the step of checking whether the system elements required for implementing the test scenario are switched on, functioning properly, and ready for starting the test, and if the examination yields a positive result, repeating the test;if the requirements relating to the aspects examined during the test are fulfilled, and the errors identified during the test remain within the predefined permissible ranges, qualifying the test result as satisfactory and terminating the test.

[0032] Some preferred embodimentsof the proposed method are disclosed in dependent claims. According to a preferred implementation of the proposed method, the verification of the compliance of the performed test, based on the measured and recorded data, includes checking the following:

[0033] whether the positions of the participants during the test correspond to the positions prescribed in the test scenario;

[0034] whether the driving profiles implemented by the vehicles (1 , 2) participating in the test correspond to the driving profiles specified in the test scenario;

[0035] whether the performance indicator values of the communication processes specified in the test scenario were achieved during the test;

[0036] whether the difference between the safety characteristics of the displacement processes realized during the test and those prescribed in the test scenario remains within a predefined permissible range.

[0037] The invention will be described in more detail below with the aid of a possible embodiment of the method, with reference to the accompanying drawings, in which:

[0038] Figure 1 shows a sample of a safety-critical scenario, in which the trajectories of physical participants intersect at a conflict point;

[0039] Figure 2 shows a main flowchart of a possible implementation of the method according to the invention, suitable for testing and evaluating wireless vehicle functions; Figure 3 shows a schematic of a general testing environment, in which all vehicles involved in the test scenario are equipped;

[0040] Figure 4 shows a schematic of test vehicles or traffic participants in a test scenario, e.g., the onboard unitsof the vehicles; and

[0041] Figure 5 shows the structure of a central control station used in the method according to the invention.In the schematic of Figure 1 , a sample safety-critical scenario is shown, in which trajectories 3, 4 — indicated by dashed lines — of vehicles 1 and 2, acting as physical traffic participants, intersect at conflict point 5. The test scenario to be implemented - referred to briefly as a “test scenario,” an example of which is shown in Figure 1 - must be defined taking into account the prevailing conditions necessary for determining the safety characteristics. For example, if the trajectories 3, 4 of vehicles 1 and 2, acting as real traffic participants in Figure 1 , intersect, the spatial position of the conflict point 5 representing the collision process must be used as the starting point. In the procedure shown in Figure 2, the following steps are carried out:

[0042] In Step S1 , the test system performing the examination is switched on, and it is checked whether, following activation, a detailed, data-level description of a test scenario to be executed is available. This description may, for example, be available in a standard OpenScenario format known to experts.

[0043] If the test scenario description is not available, in Step S2, the test scenario is loaded separately, for example, by having the test system signal this to an operator module, which then loads the test scenario to be examined.

[0044] In Step S3, the individual steps of the detailed, data-level description of the test scenario are sequentially processed. During this, the test system verifies whether all other system elements necessary for the execution of the test scenario are also switched on, functioning correctly, and ready for the test to commence. If feedback in Step S3 indicates that not all participants and / or system elements are switched on and / or not all participants and / or system elements are functioning correctly and ready to start the test, then in Step S4, the fault is diagnosed. In Step 95, it is checked whether the fault is correctable. If it is correctable, after correction, the procedure returns to Step S3. If the fault is not correctable, the test is terminated. If the test is not terminated and all systems are functioning as intended, in Step S6, it is checked whether all participants have accepted the planned start time of the test. For this purpose, the test system communicates with all participants and system elements based on the test scenario regarding the planned start time of the test and the readiness status of the participants and system elements.

[0045] If, in step 96, feedback is received indicating that all participants and system elements have accepted the test scenario start time and are ready, then in step S7 the test is classified as feasible / ready to start. If, in step 96, feedback is received indicating that not all participants have accepted the planned start time of the test, then in step 94 it is again examined whether, overtime, the result of the evaluation performed in step 96 has changed. If all conditions for starting the test are met, step 97 is carried out, in which the test is classified as feasible / ready to start. If the result of step 96 remains negative, the test is terminated after repeating steps 94 and 95, if the error persists.

[0046] During the execution of the test - that is, the period between the start and completion of the test scenario - we must ensure that the vehicles under test, as well as the real and simulated traffic participants, at all times, are in accordance with the detailed, data-level description of the test scenario:

[0047] positioned in the correct spatial location,

[0048] moving along the defined trajectory, and

[0049] traveling with the specified speed, direction, and acceleration.

[0050] In accordance with these requirements, in step 98 following step 97, the modeled virtual participants are continuously adjusted, at every moment of the testing process, to match the test scenario:

[0051] their spatial position,

[0052] their movement trajectory, and

[0053] their speeds, directions, and accelerations.

[0054] A key element of the test is that, according to step 99, V2X communication is continuously interfered with during the test, according to the noise characteristics defined in the test scenario, for example by varying the frequency range and / or noise level.

[0055] Furthermore, in step 910, the network performance metrics defined in the scenario are set. During the test, continuous com munication is ensured between the vehicles under test, the real traffic participants, the simulated traffic participants, and a central control station, during which the vehicles under test, real traffic participants, and simulated traffic participantstransmit their current position, speed, acceleration, and direction to the central control station.

[0056] Based on this, in step 911 , it is continuously checked whether the vehicle dynamic parameters comply with the specifications defined in the scenario.

[0057] In step 912, it is checked whether the communication, i.e., radio signal interference, complies with the test scenario, and in step 913, it is checked whether the network performance metrics comply with the test scenario.If the results of the checks in steps S11 , S12, and S13 are negative, the characteristics of the generated parameters are continuously controlled and fine-tuned in stepsS8, S9, and S10 based on the continuously monitored measurement data.

[0058] During the test, the performance of the network used for the test execution is continuously measured, and the measurement result istransmitted to the central control station via a wireless channel independent of the interference.

[0059] During the period between the start and completion of the test scenario, the participants involved in the implementation of the test scenario — that is, the one or two vehicles containing the component to be tested, as well asthe real and virtual traffic participants defined in the test scenario — follow the trajectory prescribed in the test scenario according to the instructions of the coordinating central control station. If the result of the check in step S11 is negative, in step S8 instructions are sent to the affected participantsto modify at least one of speed, acceleration, or direction.

[0060] During the period between the start and completion of the test scenario, continuous data recording is performed.

[0061] Based on the measured and recorded data, in step S14, the compliance of the executed tests is checked, considering, for example:

[0062] whether the positions of the vehicles 1 and 2 participating in the test match the positions prescribed in the test scenario,

[0063] whether the driving profiles executed by vehicles 1 and 2 match the driving profiles prescribed in the test scenario,

[0064] whether the performance metricsof the communication processes implemented during the test match those prescribed in the test scenario, and

[0065] whether deviations between the implemented and prescribed safety characteristics of movement processes remain within a predetermined allowable range.

[0066] If, in step S15, it isdetermined that the requirements according to the examined aspectsare not, or only partially, met, or that the errors affecting the test exceed the predetermined allowable range, an attempt is made to resolve the testing problem(s) by modifying the parameters according to professional criteria. After this, testing is repeated by returning to step S3.If, in step S15, it isdetermined that the requirements according to the examined aspectsare met and the errors affecting the test remain within the allowable range, the test result is classified as acceptable, and in step S16 the test is concluded.

[0067] In the proposed method, during the execution of the test scenario, both the vehicle 1 to be tested, which contains a test application or component, and the other real and virtual traffic participants defined in the test scenario continuously follow the control, intervention, and navigation instructionsof the central control station 11 responsible for coordinating thetest. The real and virtual test vehicles 1 and 2 communicate continuously via a standard automotive wireless connection (e.g., DSRC / ITSG5, C-V2X, 5G-NR). During the test, the real communication processes of virtual test vehicles 2 are implemented by the test system based on positional data, environmental characteristics (e.g., extreme weather conditions), and various shielding factors. Thus, the standard communication processes of virtual test vehicles 2 also reflect real-world interference effects. The components of the system enabling the testing procedure — in this example vehicles 1 and 2, central control station 11 , RF interference unit 12, and simulation unit 13 — continuously communicate via wireless channels outside the dedicated frequency bands, for example via Wi-Fi or 4G / 5G mobile networks. If required by the test scenario, RF interference unit 12 continuously interferes with V2X communication according to the noise characteristics defined in the test scenario, for example by varying the frequency range and / or noise level of the emitted interference signal. An emulation unit 22 ensures that the network performance metrics remain at the level prescribed in thetest scenario, and a performance measurement unit 25 continuously measures network performance. Continuous data recording is implemented using a data recording unit 26. If the participants involved in the execution of the test scenario — the test vehicles 1 and 2 containing the component or application 24 to be tested, as well as the real and virtual traffic participants defined in the scenario — followed the trajectory prescribed in the test scenario according to the instructions of central control station 11 , the evaluation unit 30 checks the compliance of the executed tests. In this test phase, the success of the tests is examined with respect to, for example:

[0068] whether deviations between the positional characteristics of test vehicles 1 and 2 and the positional characteristics prescribed in the test scenario remain within the allowable range,

[0069] whether deviations between the driving profiles executed by vehicles 1 and 2 and those prescribed in the test scenario remain within the allowable range,whether deviations between the performance metrics of communication processes implemented during thetest and those prescribed in the test scenario remain within the allowable range, and

[0070] whether deviations between the safety characteristics of movement processes implemented during thetest and those prescribed in the test scenario remain within the allowable range.

[0071] For implementing the presented procedure, a professional may apply or develop numerous known elements and units. Some concrete implementations are presented below as examples, without limiting the scope of the solution.

[0072] In Figure 3, the subcomponentsof vehicle 1 from Figure 1 that enable testing are illustrated. An essential element of vehicle 1 is the on-board unit 14, which is equipped with a standard V2X antenna 15 for sending and receiving standard V2X messages in the usual manner, and a GNSS antenna 16 that enables determination of the positional data of system elements and temporal synchronization. The on-board unit 14 isconnected viaadatatransmission switch 17 to a humanmachine interface unit 18, which is itself equipped with a Wi-Fi antenna 19.

[0073] The vehicles 1 and 2 to be tested, as well as the traffic participants involved in the test, necessarily possess an on-board unit 14 required for standard wireless communication. In FIG.

[0074] 4, the schematic structure of an on-board unit 14 of vehicle 1 is shown according to one implementation, for traffic participants defined in a test scenario. As with all units in the system, the on-board unit 14 is connected via known, standard industrial connectors to the previously mentioned V2X antenna 15 and GNSS antenna 16. It also contains an on-board diagnostic connector 20 that provides a link to the internal communication network of vehicle 1 , enabling data collection from the in-vehicle network or, for example, correction of positional, speed, or heading data in case of GNSS signal errors. The on-board unit 14 is further equipped with an Ethernet interface 21 , which allows direct communication with other system components, such as the network distribution unit 14 or the human-machine interface unit 18, and indirect communication with the central control station 11 or the simulation unit 13. These elements are connected to a network emulation unit 22, which is used to set network performance metrics. This emulation unit 22 is traditionally not part of industrial on-board units and communicates with a test application component 24 via the V2X application unit 23 implemented within the on-board unit 14 using standard computing devices. Novelly, the on-board unit 14 also includes a network performance measurement unit 25, which is traditionally not part of industrial on-board units, and measures the operation of the V2X application unit 23 of the network emulation unit 22. Additionally, the on-board unit 14 contains a data recording unit 26, which records the data of the communication between the network performance measurement unit 25 and the V2X application unit 23 mentioned above.

[0075] In Figure 5, the central control station 11 is shown. Smilar to the on-board unit 14, the central control station 11 is connected to a Wi-Fi antenna 27 and a GNSSantenna28. The central control station 11 also houses the previously mentioned data collection unit 29, evaluation unit 30, and coordination unit 31.

[0076] The purpose of using the RF interference unit 12 is to study the effects of interference on the safety and reliability of communication between vehicles and infrastructure, particularly in safety-critical situations where communication disruptions may lead to potentially hazardous consequences. The RF interference unit 12 is capable of deliberately disrupting the radio communication of vehicles participating in thetest and isdesigned to interfere with radio signals over a wide spectrum, with special attention to the specific frequency bands used for V2X communication (e.g., 5.9 GHz), thereby simulating interference scenarios that may occur in real-world environments. The RF interference unit 12 can emit radio frequency interference signals in adjustable frequency bands. These signalscan be standard messagesor arbitrary interference signals, intended to interfere with useful radio signals. The details of the interference scenarios in the test scenario enable the evaluation of the robustness of V2Xtechnologies and protocols, as well as the safety and reliability of the communication system between vehicles 1 and 2. To achieve the outlined operation, the RF interference unit 12 can, for example, be implemented as a software-defined radio (SDR) with a structure and operation known to a skilled professional, capable of transmitting and receiving radio signals over a range of at least 1 MHz to 6 GHz or greater.

[0077] For the procedure to be suitable for testing and developing current and next-generation radio technologies, it is advantageously implemented using an open-source hardware platform, which can be used as a peripheral or programmed and used independently. In this context, the minimum requirements for the RF interference unit 12 can, for example, be interpreted by a skilled professional from known devices such as the Ettus USRP N210 (SDR / Cognitive Radio), Ettus UBX40m, or FLEX-6600 Sgnature Series SDR Transceiver as follows:

[0078] operating frequency range from 1 M Hz to 6 GHz,

[0079] half-duplex transceiver,20 million samples per second,

[0080] software-configurable RXand TXgain and baseband filter,

[0081] software-controllable antenna connector power supply (50 mA at 3.3 V),

[0082] open-source hardware.

[0083] The network emulation unit 22, which sets the network performance metrics, is used to configure various network parameters. This emulation unit 22 allows simulation and customization of different aspects of network performance, such as latency, latency variation over time (jitter), and packet reception ratio. It isdesigned to precisely control and modify these network parameters, enabling the simulation of a wide range of real-world network conditions. This is particularly important in testing and developing V2X communication systems, where different network conditions can directly affect the reliability and efficiency of communication. The emulation unit 22 can be applied in varioustest scenariosto examine system behavior under different network conditions. This may include simulating network conditions found in urban, suburban, and rural environments, where network performance can vary significantly. The unit plays a critical role in testing and optimizing V2X communication systems, ensuring efficient and reliable operation under various network conditions. Standard industrial vehicle communication test units, without hardware modification, can also perform network emulation via software adjustments - for example, using a VECTOR VN4610 device. The VECTOR VN4610 hardware can be fully controlled via CANoe software, enabling real-time configuration of communication parameters through a graphical interface or CAPL (Communication Access Programming Language) code, which directly influences communication.

[0084] The network performance measurement unit 25, which monitors network performance metrics, enables real-time tracking and recording of communication quality, such as latency, latency variation over time (jitter), and packet reception ratio. The network performance measurement unit 25 is designed to measure changes in network performance accurately, allowing the recording of real-world network conditions. It can be applied in all test scenarios. As is known, standard industrial vehicle communication on-board units, without hardware modification, can measure latency, jitter, and packet reception ratio through software adjustments. Examples of such units include the Cohda Wireless MK6 OBU and Commsignia ITS-OB4 devices. Software adjustmentscan be made at the operating system level — for example, in Linux using the built-in "Traffic Control" unit in the kernel — which enables monitoring of network interfaces and configuration of the aforementioned network parameters.Thecollection and storageof measurement dataand configuration parameters generated during the test can be performed using a data collection unit 29, known in information technology and the relevant field of expertise. The data collected during tests may include, for example:

[0085] vehicle dynamic data collected by the on-board units 14 of participants in the test scenario (e.g., test vehicles 1 and 2), such as position, speed, acceleration, and heading, communication data (e.g., V2X messages, modulation type, signal strength, reliability of position data, packet reception ratio, latency),

[0086] characteristics and configuration of interference signals generated by the RF interference unit 12, and the safety characteristics of the scenario (e.g., TTC- time-to- collision, PET-temporal distance between intersecting vehicles, SRI - V2X-based system safety indicator).

[0087] The collection of data generated during the test can be implemented using general-purpose desktop or portable computer software, which, as known to a skilled professional, can receive, collect, and systematically store data arriving via various wired and wireless channels in a database. Vehicle tests can be evaluated using various software environments (for example, Python, MATLAB, LabVIEW), which can process data from different sources, including data collected through wired channels (USB, Ethernet) and wireless channels (Wi-Fi, Bluetooth), such as information from CAN buses, OBD-II interfaces, or external sensors. The data can be analyzed in real time or retrospectively, allowing a detailed assessment of the behavior of vehicles 1 and 2, as well as rapid identification of errorsand anomalies. Additionally, commonly used databases in information technology, such as MySQL or NoSQL databases (e.g., MongoDB), can systematically collect and store measurement data. Cloud-based solutions (e.g., Amazon Web Services) can also be suitable in the established test environment.

[0088] The evaluation unit 30, which has a known structure and operation in information technology and the relevant field of expertise, is used to determine the effect of the examined factors on safety and to verify the compliance of the tests executed. A skilled professional can configure the evaluation unit 30 so that it assessesthe successof the tests according to the following criteria:

[0089] verification of the driving profile, for example, adherence to characteristic spatial points, route, speed, and acceleration profiles,

[0090] verification of the communication characteristics defined in the test scenario, such as message transmission frequency, signal strength, packet reception ratio, latency,verification of safety characteristics, for example, compliance with the risk level prescribed in the test scenario.

[0091] Test reporting is also performed using the evaluation unit 30. The assessment of information characterizing the test can be implemented using general-purpose desktop or portable computer software, which, as known to a skilled professional, is suitable for processing information collected through variouswired and wireless channels.

[0092] The monitoring, verification, and coordination of measurement processes of real vehicles 1 and 2, whether in autonomous mode or under human driver control, are carried out via the coordination unit 31. The coordination unit 31 processes data related to the current state of the test participants (e.g., spatial position, speed, acceleration / deceleration), which is then transmitted via the human-machine interface unit 18 and its antenna 16 to the coordination unit 31 in a manner that ensures interference does not affect the coordination processes necessary for executing the test scenario. Based on the defined scenario, the coordination unit 31 sends intervention, control, and driver-assistance / navigation signals to the participants. Real vehicles 1 and 2 under human control are also equipped with individual human-machine interface units 18, which display all relevant test information (e.g., navigation guidance, test results). The human-machine interface unit 18 includes a display, computing unit, and wireless communication unit with its associated antenna 19, providing connectivity with other participants and coordination unit 31. The human-machine interface unit 18 communicates in the usual manner over a wired connection with the on-board unit 14. Monitoring, verification, and coordination of measurement processes of real vehicles 1 and 2, whether autonomous or human-driven, can be implemented using general-purpose desktop or portable computer software capable of coordinating and virtually running the elements of any vehicle test scenario, as known to a skilled professional — for example, MATLAB Driving Scenario Designer and Automated Driving Toolbox, or VECTOR CANoe Car2Xsimulation software.

[0093] Simulation unit 13 is used to implement and measure test scenarios in which, alongside the real vehicles 1 and 2 under test, other participants are present virtually in simulated form, and in collision scenarios, their projected trajectories intersect. During the simulation of the communication processes of virtual participants, positional data, environmental characteristics (e.g., extreme weather conditions), and various shielding factors are considered to generate standard radio signals, so that the transmitted radio signals reflect the effects of real interference. The simulation unit 13 can be implemented using general-purpose desktop orportable computer software capable of modeling the behavior of participants present virtually in simulated form, as known to a skilled professional — for example, Semens PreScan, Matlab Driving Scenario Designer and Automated Driving Toolbox, IPG CarMaker, or VECTOR DYNA4. The testing of the on-board unit 14 is carried out in test vehicle 1 , although the test vehicle 1 itself can also be the subject of testing.

[0094] List of Reference signs:

[0095] 1 vehicle

[0096] 2 vehicle

[0097] 3 trajectory

[0098] 4 trajectory

[0099] 5 conflict point

[0100] 11 central control station

[0101] 12 RF interference unit

[0102] 13 simulation unit

[0103] 14 on-board unit

[0104] 15 V2X antenna

[0105] 16 GNSS antenna

[0106] 17 data transmission switch

[0107] 18 human-machine interface unit (HM I)

[0108] 19 WiFi antenna

[0109] 20 on-board diagnostic port

[0110] 21 Ethernet interface

[0111] 22 emulation unit

[0112] 23 V2X application unit

[0113] 24 application

[0114] 25 performance measurement unit

[0115] 26 data recording unit

[0116] 27 WiFi antenna

[0117] 28 GNSS antenna

[0118] 29 data collection unit

[0119] 30 evaluation unit

[0120] 31 coordination unit

Claims

Claims1. A method for safety testing of V2X-based applications, characterized in that it comprises: powering on a test system executing the test and verifying whether, after power-on, a detailed, data-level description of a test scenario to be executed is available (SI ),wherein, if the test scenario description is not available, loading (S2) the test scenario separately and repeating the verification of step (S1 ),proceeding (S3) through the individual steps of the detailed, data-level description of the test scenario and, during this process, verifying via the test system that other system elements required for implementing the test scenario are also powered on, operating correctly, and ready to start the test,wherein, if all participants and system elements are powered on, operating correctly, and ready to start the test, verifying (96) whether the planned start time of the test is accepted by all participants, by exchanging messages via the test system according to the test scenario with all participants and system elements regarding the planned start time and the readiness status of the participants and system elements, and then qualifying (S7) the test as feasible / startable, wherein, if not all participants and system elements are powered on, repeating (S3) the verification to determine (94) the cause of the error and whether the error is correctable (95), wherein, if the error is not correctable, terminating the test, and if the error is correctable, verifying (S6) whether, over time, the result of the verification that other system elements required for implementing the test scenario are powered on, operating correctly, and ready to start the test has changed,wherein, if the planned start time of the test is not accepted by all participants, repeating the verification (S6) to determine whether, over time, the result of the verification that the planned start time of the test is accepted by all participants has changed,wherein, if the repeated verification (96) result is positive, qualifying (S7) the test as feasible / startable, and if the repeated verification (96) result remains negative, terminating the test;after starting the test, in order to ensure that during the period between the start and completion of the test scenario execution the vehicles under test and the real and simulated traffic participants are located at spatial positions corresponding to the detailed, data-leveldescription of the test scenario, move along the defined trajectories and proceed with the specified speed, heading angle, and acceleration, continuously adjusting (SB) the spatial positions, trajectories, speeds, heading angles, and accelerations of the modeled virtual participants according to the test scenario at every moment of the testing process; additionally generating and emitting an interference signal (S9) that influences the tested V2X communication according to the noise characteristics specified in the test scenario, and continuously measuring the performance of the network used to perform the test; further continuously adjusting (S10) network performance metrics used for test execution, based on communication between real and simulated traffic participants and a central control station (11), wherein real and simulated traffic participants transmit their current positions, speeds, accelerations, and headings to the central control station (11), verifying (S12) that the communication, i.e., radio signal interference, complies with the test scenario, verifying (S13) that the network performance metrics comply with the test scenario, verifying (S11) that the movement of real and simulated traffic participants complies with the test scenario, and if the verification (S12) that the communication, i.e., radio signal interference, complies with the test scenario is negative, continuously controlling and fine-tuning (S9) the characteristics of the generated interference signal based on continuously monitored measurement data, wherein, if the verification (S13) that the network performance metrics comply with the test scenario is negative, continuously controlling and fine-tuning (S10) the set performance metrics based on continuously monitored measurement data,wherein, if the verification (S11) that the movement of real and simulated traffic participants complies with the test scenario is negative, sending instructions (SB) to at least change one of speed, acceleration, or heading of the traffic participants,continuously recording data during the period between the start and completion of the test scenario execution,verifying (S14), based on the measured and recorded data, the compliance of the performed test,and, if the requirements according to the examined aspects are not, or only partially, met, or if the errors identified during the test fall outside predefined permissible ranges, attempting to resolve the test problem(s) by changing (S8) the parameters used during the test to minimize deviation from the specified reference values, and returning to verify whether the systemelements required for implementing the test scenario are powered on, operating correctly, and ready to start the test, and repeating the test if the verification is positive,verifying (S15) whether the requirements according to the examined aspects were met, and if the requirements according to the examined aspects are met, and the errors identified during the test remain within the predefined permissible ranges, classifying the test result as satisfactory,and if the requirements according to the examined aspects are not, or only partially, met, or if the errors affecting the test fall outside the predefined permissible ranges, attempting to resolve the test problem(s) by changing the parameters according to professional judgment, and then returning to step S3 to repeat the test,and if the requirements according to the examined aspects are met and the errors affecting the test remain within the permissible ranges, classifying the test result as satisfactory and terminating the test.

2. The method according to claim 1 , characterized in that the verification (S14) of the compliance of the test performed based on the measured and recorded data comprises checking the following:whether the positions of the participants during the test correspond to the positions specified in the test scenario,whether the driving profiles implemented by the vehicles (1 , 2) participating in the test correspond to the driving profiles specified in the test scenario,whether the performance metric values of the communication processes specified in the test scenario were achieved during the test, andwhether the deviation between the safety characteristics of the displacement processes realized during the test and those specified in the test scenario remains within a predefined permissible range.

Images