Loop logging and hils-supported autonomous driving test system

Abstract

The present invention may include a loop logging and HILS-supported autonomous driving test system, a logger that collects and time-synchronizes and records a plurality of sensor data, a ROS bridge that converts ROS messages generated in a ROS software architecture into a communication protocol recognizable by an ECU and converts output signals of the ECU into ROS messages for mutual exchange, and an ECU that interacts with the ROS software architecture through the ROS bridge.

Description

Technology Field

[0001] The present invention relates to an autonomous driving test system, and more specifically, to a system capable of efficiently verifying the performance of an autonomous driving ECU by loop logging driving data in a ROS (Robot Operating System)-based environment and supporting HILS (Hardware-in-the-Loop Simulation). Background Technology

[0003] To commercialize autonomous vehicles, it is essential to ensure the reliability of the Electronic Control Unit (ECU). The ECU performs autonomous driving functions by processing various data collected from sensors to recognize driving conditions and generating vehicle control signals based on the results. Therefore, functional verification and performance testing of the ECU need to be performed repeatedly and precisely in various virtual environments, in addition to actual road driving tests.

[0004] Hardware-In-the-Loop Simulation (HILS) systems are widely used for this purpose. HILS systems simulate the actual driving environment by exchanging signals with the ECU in real time using a virtual vehicle model or simulation module, thereby enabling the prior evaluation of the ECU's control algorithms and safety.

[0005] Meanwhile, conventional HILS systems are often dependent on specific hardware devices or commercial software licenses, which raises concerns about high costs and limited scalability. Additionally, they do not provide sufficient capabilities to accurately record large amounts of sensor data and control signals generated during testing by time synchronization and to precisely replay them, making it difficult to perform repeated verification under the same conditions.

[0006] Meanwhile, open-source software architectures such as ROS (Robot Operating System) are widely utilized in the field of autonomous driving research and development. Although ROS can be applied to various research environments by providing functions such as sensor data processing, message exchange, and simulation integration, it has a limitation in that vehicle ECUs cannot directly recognize messages generated within the ROS environment. Accordingly, there is a need for a new type of test system that converts communication protocols between ROS messages and vehicle ECUs and enables the use of recorded data for ECU testing. Prior art literature

[0007] Republic of Korea Registered Patent Publication No. 10-2717592 The problem to be solved

[0008] The problem that the present invention aims to solve is to provide an autonomous driving test system that provides a loop logging function capable of repeatedly performing tests under the same conditions by recording multiple sensor data and vehicle control signals in time synchronization and managing them in a rosbag file format.

[0009] The problems that the present invention aims to solve are not limited to those mentioned above, and other unmentioned problems will be clearly understood by a person skilled in the art from the description below. means of solving the problem

[0011] An autonomous driving test system supporting loop logging and HILS according to an embodiment of the present invention for solving the above-mentioned problem is disclosed. The system may include a logger that collects a plurality of sensor data, synchronizes time, and records them; a ROS bridge that converts ROS messages generated in a ROS software architecture into a communication protocol recognizable by an ECU and converts output signals of the ECU into ROS messages to exchange with each other; and an ECU that interacts with the ROS software architecture through the ROS bridge.

[0012] In an alternative embodiment, the logger may be characterized by including a time synchronization module that assigns a common time standard to the plurality of sensor data and a buffer memory that temporarily stores the collected data to prevent omission in the recording process.

[0013] In an alternative embodiment, the logger may record time-synchronized multiple sensor data and timestamp information corresponding to each sensor data in a rosbag file format.

[0014] In an alternative embodiment, the logger may include test condition information and vehicle status information as metadata and record them in a form time-synchronized with the plurality of sensor data.

[0015] In an alternative embodiment, the logger may further include vehicle control signals as recording targets, and may acquire sensor data display information and ECU status display information by linking with a visualization tool and a monitoring tool based on the ROS software architecture, generate cause analysis information based on the plurality of sensor data, vehicle control signals and metadata, and provide a user interface that displays the sensor data display information, the ECU status display information and the cause analysis information.

[0016] In an alternative embodiment, the system may further include a playback module that transmits data written to the rosbag file to the input of the ECU without going through a ROS topic-based publisher-subscriber procedure.

[0017] In an alternative embodiment, the playback module can control the transmission to the ECU at the same time interval as the recording time by referring to the timestamp information of each frame recorded in the rosbag file.

[0018] In an alternative embodiment, the logger, the ROS bridge, and the playback module are implemented based on the ROS open source framework and can operate without being dependent on specific hardware devices or proprietary software licenses.

[0019] In an alternative embodiment, the ROS bridge can perform data conversion between different communication protocols and perform checksum-based integrity verification and timestamp-based time consistency verification on the converted data.

[0020] In an alternative embodiment, the system can support closed-loop HILS testing by providing the output signal of the ECU to a ROS-based virtual vehicle model or simulation module, and providing sensor data generated from the virtual vehicle model or simulation module back to the input of the ECU.

[0021] Other specific details of the present invention are included in the detailed description and drawings. Effects of the invention

[0023] According to one embodiment of the present invention, by time-synchronizing a plurality of sensor data and vehicle control signals and recording them in a rosbag file format, repetitive testing under the same conditions can be performed and the reliability of the test data can be improved.

[0024] In addition, by providing a ROS bridge capable of mutually converting messages between the ROS software architecture and vehicle ECUs, it is possible to reliably verify the performance of autonomous driving ECUs even in environments with different communication protocols.

[0025] Additionally, since data recorded in the rosbag file format can be directly played back as input to the ECU, or closed-loop HILS testing can be performed by linking the ECU with a ROS-based virtual vehicle model and simulation module, various situations that may occur in a real driving environment can be simulated repeatedly and precisely, thereby providing the effect of efficiently evaluating the stability and safety of the autonomous driving ECU.

[0026] The effects of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by a person skilled in the art from the description below. Brief explanation of the drawing

[0028] Figure 1 is an exemplary block diagram illustrating the general structure of ROS (Robot Operating System). FIG. 2 is a block diagram showing the interoperability structure between a ROS-based logger, a ROS bridge, a regeneration module, and an ECU related to one embodiment of the present invention. FIG. 3 is an exemplary diagram illustrating the process of logging and converting a plurality of sensor data related to an embodiment of the present invention in a ROS environment by time synchronization. FIG. 4 is an exemplary diagram illustrating the process of testing an ECU by replaying rosbag recording data in a HILS test mode related to an embodiment of the present invention. Specific details for implementing the invention

[0029] Various embodiments are now described with reference to the drawings. In this specification, various descriptions are provided to facilitate an understanding of the invention. However, it is evident that these embodiments can be practiced without such specific descriptions.

[0030] As used herein, terms such as “component,” “module,” “system,” etc. refer to computer-related entities, hardware, firmware, software, combinations of software and hardware, or executions of software. For example, a component may be a process, processor, object, execution thread, program, and / or computer running on a processor, but is not limited thereto. For example, both an application running on a computing device and the computing device itself may be a component. One or more components may reside within a processor and / or execution thread. A component may be localized within a single computer. A component may be distributed among two or more computers. Additionally, these components may be executed from various computer-readable media having various data structures stored therein. Components may communicate through local and / or remote processes, for example, according to signals having one or more data packets (e.g., data from a component interacting with another component in a local system or distributed system, and / or data transmitted through signals to other systems and networks such as the Internet).

[0031] Furthermore, the term "or" is intended to mean an implicit "or" rather than an exclusive "or." That is, unless otherwise specified or evident from the context, "X uses A or B" is intended to mean one of the natural implicit substitutions. In other words, if X uses A; if X uses B; or if X uses both A and B, "X uses A or B" may apply to any of these cases. Additionally, the term "and / or" as used herein should be understood to refer to and include all possible combinations of one or more of the enumerated related items.

[0032] Additionally, the terms “comprising” and / or “comprising” should be understood to mean that such features and / or components are present. However, the terms “comprising” and / or “comprising” should be understood not to exclude the presence or addition of one or more other features, components and / or groups thereof. Furthermore, unless otherwise specified or clearly evident from the context to indicate a singular form, the singular in this specification and claims should generally be interpreted to mean “one or more.”

[0033] Those skilled in the art should recognize that the various exemplary logical blocks, configurations, modules, circuits, means, logics, and algorithmic steps described in connection with the embodiments disclosed herein may be implemented in electronic hardware, computer software, or a combination of both. To clearly exemplify the interchangeability of hardware and software, various exemplary components, blocks, configurations, means, logics, modules, circuits, and steps have been generally described above in terms of their functionality. Whether such functionality is implemented in hardware or software depends on the specific application and design constraints imposed on the overall system. Skilled technicians may implement the described functionality in various ways for each specific application. However, such decisions regarding implementation should not be construed as moving out of the scope of the invention.

[0034] The description of the presented embodiments is provided to enable those skilled in the art to use or practice the present invention. Various modifications to these embodiments will be apparent to those skilled in the art. The general principles defined herein may be applied to other embodiments without departing from the scope of the present invention. Thus, the present invention is not limited to the embodiments presented herein. The present invention should be interpreted in the broadest possible scope consistent with the principles and novel features presented herein.

[0035] In this specification, the term "computer" refers to any type of hardware device comprising at least one processor, and may be understood to include software configurations operating on said hardware device according to the embodiments. For example, the term "computer" may be understood to include smartphones, tablet PCs, desktops, laptops, and user clients and applications running on each of these devices, but is not limited thereto.

[0036] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

[0037] Each step described in this specification is described as being performed by a computer, but the subject of each step is not limited thereto, and depending on the embodiment, at least some of each step may be performed on different devices.

[0039] Figure 1 is an exemplary block diagram illustrating the general structure of ROS (Robot Operating System). ROS is an open-source middleware platform designed for the development of robots and autonomous driving systems, and is an integrated framework that supports sensor data processing, message communication, execution of control algorithms, and the provision of visualization and simulation environments. ROS acts as middleware that processes data acquired from sensors, performs autonomous driving control of the vehicle based on the processed data, and transmits control signals to the ECU (Electronic Control Unit).

[0040] More specifically, data generated from multiple sensors, such as cameras, LiDAR, radar, and GPS, is input into the ROS and converted into control commands—such as driving path generation, maintaining distance between vehicles, and lane recognition—through autonomous driving algorithms within the ROS. These converted control commands are transmitted to the ECU and used to control the vehicle's steering, acceleration, and braking. Additionally, the output signals from the ECU are transmitted back to the ROS to be used for status verification or monitoring of the driving control algorithms.

[0041] While general ROS-based architectures are functionally capable of basic data transmission and reception and the execution of control algorithms, they have several limitations in providing the precise test environment required for the development and verification of actual autonomous driving ECUs. In particular, since actual automotive ECUs often do not directly support ROS messages, separate communication converters or complex interface configurations may be essential to perform interoperability testing between the ECU and the ROS environment.

[0042] Furthermore, when playing back sensor data using rosbag, frame drops or timestamp inconsistencies frequently occur, differing from the time interval at the time of recording. This is because logging and playing back driving data in a ROS environment typically relies on a publisher / subscriber (pub / sub) model; when playing back large volumes of sensor data (e.g., camera images or LiDAR point clouds), accumulated processing delays lead to frame drops or timestamp errors, making it difficult to accurately reproduce the conditions at the time of recording. Synchronization between sensors can break down, such as when camera images are output normally but LiDAR point clouds are missing at specific points, making it difficult to accurately reproduce actual driving conditions. Additionally, since the structure involves the ECU and ROS merely exchanging data, it is difficult to configure Hardware-In-the-Loop Simulation (HILS) tests where control signals from the ECU are transmitted to a virtual vehicle model or simulator for feedback.

[0043] Meanwhile, commercial HILS equipment (e.g., dSPACE, ETAS, etc.) provides sensor data simulation and ECU signal verification functions, but they face problems such as high costs due to their dependence on specific hardware and dedicated software licenses, and difficulty in flexibly expanding to suit research environments. Additionally, conventional ROS-based logging functions are designed primarily for sensor data and cannot comprehensively record metadata such as test condition information or vehicle status information. Consequently, the analysis of the causes of specific situations occurring during driving tests is limited, and the establishment of a test environment capable of repeatedly reproducing the same conditions may be incomplete.

[0044] Due to these issues, when developing or improving algorithms for autonomous driving ECUs, it is difficult to secure a reliable simulation environment prior to actual road testing, and the error detection and correction process can consume a significant amount of time and cost.

[0045] The present invention aims to provide an autonomous driving test system comprising a logger capable of stably synchronizing sensor data and ECU signals to record and play back while utilizing an open environment based on ROS, a ROS bridge that stably supports communication between ROS and ECU, and a playback module capable of precisely playing back the recorded data, in order to solve the aforementioned problems.

[0046] FIG. 2 is a block diagram showing the interoperability structure between a ROS-based logger, a ROS bridge, a regeneration module, and an ECU related to one embodiment of the present invention.

[0047] According to one embodiment of the present invention, a loop logging and HILS-supported autonomous driving test system (hereinafter referred to as the 'autonomous driving system') may include a sensor (11), a ROS environment (10), a logger (110), a ROS bridge (120), a regeneration module (130), and an ECU (20).

[0048] According to one embodiment, the sensor (11) may perform the role of acquiring sensor data regarding the vehicle driving environment. For example, the sensor may be a camera, LiDAR, radar, GPS (Global Positioning System), or IMU (Inertial Measurement Unit). However, the types of the sensor are not limited thereto, and other types of sensors capable of perceiving the driving environment or measuring the vehicle state may also be included.

[0049] In one embodiment, a camera can acquire image data regarding driving footage, lanes, and road signs, and a LiDAR can acquire distances to surrounding objects and 3D point cloud data. A radar can acquire relative velocity and position data of moving objects, and a Global Positioning System (GPS) can acquire absolute position data of the vehicle. Additionally, an Inertial Measurement Unit (IMU) can acquire data regarding acceleration and angular velocity and be utilized to calculate the attitude and motion state of the vehicle. Sensor data having different characteristics can be used as basic data to comprehensively reflect the vehicle driving environment, and can subsequently be time-synchronized and fused through a ROS bridge.

[0050] Additionally, the data acquired by the sensor (11) may include internal vehicle control signals. Vehicle control signals can be collected via a CAN (Controller Area Network) bus within the vehicle, and include, for example, control-related information such as the vehicle's speed, engine rotation speed, and steering angle. The vehicle control signals can be recorded and analyzed together with data acquired from an external driving environment sensor and used as more precise test data for ECU verification.

[0051] Meanwhile, since the data obtained through each sensor may be temporally irregular or have different cycles for each sensor, it is input into the ROS software architecture (10) and processed by being assigned a common time standard. For example, cameras, lidar, GPS, IMU, etc., output data at different cycles, and the output timing may become unstable depending on communication delays or sensor characteristics.

[0052] In one embodiment, the ROS software architecture (10) is a middleware platform that collects and processes sensor data and control signals generated in a vehicle driving test environment, and can transmit and receive each data stream at the node level based on a publisher / subscriber (pub / sub) model. The ROS software architecture (10) is advantageous for distributed system design, so sensors, controllers, and algorithm modules are implemented as independent nodes, and each node exchanges data via topics. This allows for reduced coupling between modules and ensures scalability, but overhead such as message serialization-deserialization processes, message queue management, network latency, and callback processing delays may occur. In particular, when the data size is large, such as camera images or LiDAR point clouds, frame drops or timestamp inconsistencies may occur, which can act as a limitation in ECU test environments requiring real-time performance. In the present invention, these limitations can be overcome through the ROS bridge (120) and the playback module (130). Specifically, the ROS bridge directly maps and converts the signal format between ROS topic-based data and the ECU (20), thereby shortening unnecessary serialization-deserialization paths and minimizing delays in data transmission. Additionally, the playback module directly transmits data recorded in the rosbag file in accordance with the ECU input format without going through the publisher-subscriber procedure, thereby preventing frame drops or queue overflow issues that occur during large-capacity data transmission. Through this structure, the autonomous driving test system of the present invention can perform highly reliable data logging and reproduction tests while maintaining real-time performance.

[0053] In addition, in one embodiment, the ECU (20) is an electronic control unit responsible for the actual control of the vehicle and generally operates based on automotive communication protocols such as CAN, FlexRay, and Ethernet. However, most of the ECUs (20) used in the test environment of the present invention correspond to non-ROS-native ECUs that cannot directly interpret or process ROS messages. Since these ECUs do not understand ROS-based publisher-subscriber models or topic-based data exchange, it is impossible to directly interact with the ROS software architecture (10).

[0054] In the present invention, compatibility between the ECU (20) and the ROS software architecture (10) is ensured through the ROS bridge (120), based on the premise that the ECU (20) may be an unsupported ECU. Specifically, the ROS bridge (120) converts ROS messages into vehicle communication signals (CAN frames, Ethernet packets, etc.) that the ECU (20) can recognize, and conversely, converts control signals output from the ECU (20) back into ROS messages and provides them to the ROS software architecture (10). Through this bidirectional conversion process, even an unsupported ECU can be integrated into a ROS-based test environment, and as a result, a data loop can be formed between the actual vehicle control environment and the ROS-based simulation / logging environment.

[0055] According to one embodiment, the logger (110) can collect multiple sensor data, synchronize time, and record them. More specifically, the logger (110) collects data from various sensors such as cameras, lidar, radar, GPS, and IMUs that have different periods and delay characteristics, and can align all data to a common reference time axis by correcting time discrepancies that may occur when relying on individual timestamps for each sensor. Since the data aligned by the logger can be reproduced with the same time relationship in a subsequent playback process or HILS test environment, the reliability of the test can be ensured.

[0056] In a specific embodiment, the logger (110) may include a time synchronization module that provides a common time standard to multiple sensor data. The time synchronization module may provide a consistent time standard to all data streams by utilizing a Pulse Per Second (PPS) signal provided by a Global Positioning System (GPS), a high-precision crystal oscillator-based clock signal, or a network-based synchronization protocol such as Network Time Protocol (NTP) or Precision Time Protocol (PTP).

[0057] For example, if the camera frame operates at a cycle of 30fps, the lidar at 10Hz, and the radar at 20Hz, data from different cycles can be accurately aligned and recorded on an integrated timeline, allowing multiple sensor data to be recorded at the same timing as their actual occurrence order. This time alignment improves the accuracy of sensor fusion algorithms during subsequent data playback and contributes to clearly analyzing the causal relationship between inputs and outputs during the ECU verification process.

[0058] In addition, in an embodiment, the logger (110) may include a buffer memory that temporarily stores collected data to prevent omissions in the recording process. The buffer memory prevents loss by temporarily storing data even when the data stream momentarily overflows or the processing speed of the recording device is temporarily reduced. For example, even when high-resolution camera images or LiDAR data generating hundreds of thousands of points per second are input simultaneously, the buffer memory can load the data sequentially and stably deliver it to the recording device. This prevents problems such as frame drops in camera images or partial loss of the LiDAR point cloud, and ensures the continuity and integrity of the data even during long-term driving tests or in complex traffic environments.

[0059] According to one embodiment, the logger (110) can record time-synchronized multiple sensor data and timestamp information corresponding to each sensor data in a rosbag file format. A rosbag file is a data recording format provided as a standard in the ROS software architecture, which stores sensor data along with timestamps assigned to each message. Through this, the recorded data can be preserved in a form that reflects the temporal context of the actual driving time, rather than simply being a list of sensor outputs.

[0060] For example, during a driving test, the camera can record video at 30fps, the lidar can output a point cloud at 10Hz, and the GPS can provide location information at a 1Hz cycle. In this case, the logger (110) records the time when each data occurs in a rosbag file along with a unique timestamp, so that when playing back, the camera frame and lidar scan are output with the same time difference as in reality. This method has the advantage of ensuring an input environment similar to reality in verifying sensor fusion algorithms or testing the response of an autonomous driving ECU.

[0061] In addition, the rosbag file format supports data output at equal intervals by referencing the timestamp at the time of recording during playback within the ROS environment. Therefore, developers can repeatedly reproduce data collected from actual road driving and verify whether the ECU's control algorithm operates consistently under specific conditions. This has the advantage of reducing the cost and risk associated with road testing and enabling repeated verification under identical conditions.

[0062] In one embodiment, the logger (110) may record test condition information and vehicle status information as metadata in a form time-synchronized with a plurality of sensor data. The test condition information is data related to the external environment in which the driving test is performed, and may include elements such as road type (e.g., highway, urban road, test track), weather conditions (e.g., clear, rain, snow), light conditions (daytime, nighttime, tunnel entry, etc.), and road surface conditions (dry, wet, whether icy). This test condition information may be obtained from environmental sensors mounted on the vehicle (e.g., road surface friction sensor, light sensor, weather sensor) or from test scenario data entered by the test manager.

[0063] In addition, vehicle status information is data representing the dynamics and operational status of the vehicle itself while driving, and may include data obtained through the vehicle's internal ECU and sensor network, such as vehicle speed, engine rotational speed, steering angle, input status of the accelerator and brake pedals, battery voltage and current, and braking pressure. This vehicle status information may be transmitted to a logger via the vehicle's CAN bus, LIN (Local Interconnect Network) bus, or a vehicle diagnostic interface (e.g., OBD-II).

[0064] Since test condition information and vehicle status information are recorded as metadata based on the same time frame as sensor data, it is possible to precisely track how specific external conditions or internal state changes affected sensor output and ECU control response.

[0065] For example, differences in the response of the ECU control algorithm can be analyzed based on the difference between dry and frozen road conditions with the same sensor input, and changes in the LiDAR point cloud pattern based on changes in vehicle speed and steering angle can also be analyzed in conjunction.

[0066] According to one embodiment, the logger (110) can record a plurality of sensor data and vehicle control signals and provide a user interface for visualization and analysis based thereon.

[0067] In a specific embodiment, the logger (110) may include vehicle control signals as recording targets. The vehicle control signals may include various control-related data such as speed, engine rotational speed (RPM), steering angle, accelerator pedal opening rate, brake pedal input, transmission status, battery voltage and current, which are collected via a CAN bus or OBD-II interface within the vehicle. The vehicle control signals are recorded together with sensor data and can be used to verify the causal relationship between the input and output of a vehicle control algorithm or to track the ECU response in specific situations.

[0068] In addition, the logger (110) can be linked with visualization tools and monitoring tools based on the ROS software architecture to obtain sensor data display information and ECU status display information. For example, RViz is the most widely used 3D visualization tool in the ROS environment and can convert and display data collected from various sensors into an intuitive graphic form. Since image data collected from a camera, point clouds generated from a LiDAR, and location information obtained from a GPS can be visualized integrally in 3D space through RViz, the user can check the driving environment in a recreated form in a virtual space.

[0069] Meanwhile, rqt is a modular GUI-based monitoring tool provided in the ROS environment that supports the ability to check ECU control variables and system status information in real time. By utilizing the rqt plugin, changes in control variables (e.g., target torque, braking pressure, steering angle) generated by the ECU can be monitored in the form of graphs or numerical values, and simultaneously, the switching of ECU operating modes and the occurrence of error codes can be displayed in real time.

[0070] Therefore, the two tools complement each other, with RViz providing a spatial and visual understanding of sensor data and rqt supporting the numerical and temporal analysis of control variables and ECU status. This allows users to simultaneously grasp sensor data and ECU status during testing, enabling a more intuitive and precise understanding of what inputs the vehicle received and what control outputs it generated at specific points in time. For example, by monitoring the point at which lane recognition failed in the camera footage during a lane change test alongside changes in ECU control outputs (e.g., steering angle, torque values), it is possible to clearly analyze how sensor recognition errors affected the operation of the control algorithm.

[0071] That is, the logger (110) can operate in conjunction with visualization tools and monitoring tools that are natively supported in the ROS software architecture. Through this, sensor data and vehicle control signals recorded by the logger can be visualized and monitored in standard ROS tools such as RViz and rqt without developing separate independent tools, which has the advantage of improving system development efficiency and compatibility.

[0072] According to one embodiment, cause analysis information refers to the results of an analysis to identify the cause of an event or specific action that occurred during a test process, and can be generated by extracting correlations between data from different sources or comparing time series patterns.

[0073] Specifically, if the point in time when lane recognition fails in the camera image data coincides with the point in time when the steering angle control value in the ECU output signal changes abnormally, the logger (110) can determine that the cause of the steering instability is a lane recognition error. As another example, if the lidar sensor detects an obstacle that suddenly appears in front and immediately thereafter the brake control signal and braking pressure data rise rapidly, the logger (110) can present the analysis result that the cause of the sudden braking action is due to the detection of the obstacle.

[0074] Cause analysis linked to environmental conditions is also possible. For example, if a frozen road surface condition is recorded in the test condition metadata and at the same time, an increase in wheel slip and an ABS intervention signal are detected in the vehicle control signal, the logger (110) can identify that the cause of the braking instability is the frozen road surface. This analysis is not limited to simply confirming the simultaneity of sensor data and control signals, but can be used to explain the causal relationship of the occurrence of an event by synthesizing test condition information and vehicle state information.

[0075] The generated cause analysis information can be used as a basis for identifying the cause of defects in the ECU algorithm, verifying sensor recognition performance, improving test scenarios, and ensuring the safety of the autonomous driving system. Therefore, the logger (110) can improve the reliability and efficiency of the autonomous driving ECU verification process by providing a data-based cause analysis function.

[0076] Additionally, the logger (110) may provide a user interface that displays sensor data display information, ECU status display information, and cause analysis information. The user interface may go beyond a simple data log viewer and include various visualization means to allow for an intuitive understanding of the test process and results.

[0077] Specifically, sensor data display information can be implemented as real-time output of camera video frames, 3D visualization of point clouds acquired from LiDAR, display of the location and speed of radar-detected objects, and GPS-based display of vehicle movement trajectory maps. Through this, users can intuitively check how driving environment recognition data has changed over time.

[0078] ECU status display information may include control output values ​​calculated by the ECU and the status of internal algorithms; for example, values ​​such as target steering angle, control torque command, braking pressure, and power distribution ratio may be displayed in graph or numerical form. In addition, the ECU's operating mode switching status, error codes, and safety diagnostic signals are provided, allowing for real-time monitoring of the ECU's operational reliability during testing.

[0079] In one embodiment, the cause analysis information refers to the analysis result of identifying the cause of an event that occurred at a specific point in time by synthesizing sensor data, vehicle control signals, and test condition information. Meanwhile, the user interface supports intuitive verification of this cause analysis information and, for example, can display causal relationships such as "front obstacle detection -> ECU braking command -> rapid decrease in vehicle speed" in the form of a timeline or a linkage graph during a sudden braking situation. Additionally, the cause of steering instability caused by lane recognition failure can also be presented in a visualization form connecting sensor recognition results and changes in ECU output.

[0080] The user interface goes beyond simple data verification and can be utilized as supporting material for generating post-test analysis reports or simulating problem reproduction. Furthermore, by providing intuitive and visual information that enables both expert engineers and non-experts to easily understand test results, it can simultaneously improve development efficiency and collaborative productivity.

[0081] Therefore, the logger (110) is not limited to simply recording multiple sensor data and vehicle control signals, but also manages metadata including test conditions and vehicle status information, and can obtain sensor data display information and ECU status display information linked with visualization tools and monitoring tools. In addition, the logger can generate cause analysis information to identify the causal relationship of an event based on the recorded data and provide a user interface that displays this information in an integrated manner, thereby providing a comprehensive management function that encompasses the collection, storage, analysis, and display of data during the autonomous driving test process. This can increase the reliability of test results, support rapid cause identification and reproduction analysis in the event of a problem, and further contribute to performance verification and improved development efficiency of the autonomous driving ECU and sensor algorithm.

[0082] According to one embodiment, the ROS bridge (120) is a module that relays data exchange between the ROS software architecture (10) and the ECU (20), and can ensure compatibility between different communication protocols.

[0083] Specifically, the ROS bridge (120) can convert ROS messages generated in the ROS software architecture into a communication protocol recognizable by the ECU (20), and can relay the output signal of the ECU (20) into a ROS message for mutual exchange. Through the bidirectional conversion function via the ROS bridge (120), the ECU (20) can be seamlessly integrated with a ROS-based test environment even if it does not directly support the ROS environment.

[0084] In one embodiment, the ROS bridge (120) can perform signal format mapping and data unit scaling during the process of converting ROS messages into ECU signals. For example, if a steering angle command value expressed as a float type within the ROS architecture is defined as an integer (raw value) signal in the ECU, the ROS bridge (120) converts the data to match the signal specifications of the ECU and transmits it. Additionally, if a control signal output from the ECU (e.g., RPM, vehicle speed, braking pressure, etc.) does not match the topic format required by ROS, the ROS bridge can convert it into a ROS message format so that ROS nodes can receive it normally.

[0085] Additionally, the ROS bridge (120) can support message filtering and mapping rules according to specific test purposes. Specifically, the ROS bridge (120) can selectively convert and transmit only the signals necessary for the test purpose, excluding signals that are not directly related to the test scenario from among dozens or more control signals generated by the ECU. For example, among the signals output from the ECU, steering angle commands, acceleration / braking commands, and safety diagnostic signals directly related to autonomous driving function verification are transmitted to the ROS architecture, while lighting control signals or signals related to the air conditioning system that are unrelated to the test can be excluded through filtering.

[0086] In addition, the ROS bridge (120) can not only filter signals but also map the selected signals to the topic structure required by the ROS architecture. For example, control signals defined as individual variables within the ECU can be grouped into a single driving control topic and transmitted in the ROS architecture, or conversely, a single ECU signal can be divided and mapped into multiple ROS topics. Through this, inconsistencies in data structures can be resolved, and a data transmission structure optimized for testing purposes can be provided.

[0087] As described above, message filtering and mapping functions not only prevent unnecessary bandwidth consumption and data congestion but also enable test personnel to focus on verifying specific functions or specific ECU modules. Therefore, unlike simply transmitting all data in bulk, the test environment can perform more goal-oriented and precise data exchange, thereby simultaneously improving test efficiency and analysis accuracy.

[0088] In addition, in the embodiment, the ROS bridge (120) can dynamically adjust message filtering and mapping rules according to the test scenario. For example, during normal driving, all vehicle status signals are provided to the ROS architecture, but in an emergency braking scenario, it can be configured to focus on transmitting only specific signals, such as braking pressure, wheel slip rate, and ABS intervention. Through this, the tester can optimize data exchange between the ECU and ROS under various driving conditions.

[0089] In one embodiment, the ROS bridge (120) can perform a direct conversion between a data structure generated in the ROS software architecture and a signal structure required by the ECU. Specifically, if the target trajectory information generated by the autonomous driving planning module exists as a plurality of detailed items such as path coordinates, target speed, and turning radius, the ROS bridge (120) can integrate and transmit them in a single signal format called a "target path packet" required by the ECU control logic. Since the integration conversion is performed by the bridge generating a data packet that directly matches the ECU requirements instead of using the pub / sub model as is, it can reduce unnecessary serialization / deserialization and message queue waiting steps and ensure real-time control responsiveness.

[0090] Additionally, the ROS bridge (120) can also support conversion in the opposite direction. For example, if the composite recognition result output by the ECU includes lane recognition, front object recognition, and side radar detection results simultaneously in a single packet, the ROS bridge can divide this into subdivided message units required by the ROS environment and provide them. That is, by converting a single data frame of the ECU into independent structures such as "lane recognition message," "front object message," and "side radar message," it can support each ROS node to receive and process only the information related to itself.

[0091] The ROS Bridge enables goal-oriented data utilization in autonomous driving test environments by adopting a direct conversion structure that resolves data format differences between the ECU and the ROS environment and guarantees real-time performance and consistency. Consequently, even with the same data, it can provide integrated signals to the ECU and granular signals to the ROS analysis node, allowing for more precise functional verification, performance analysis, and root cause tracing of autonomous driving ECUs.

[0092] Additionally, the ROS bridge (120) may apply a time synchronization mechanism to minimize latency or loss that may occur during the message transmission process. For example, it maintains temporal consistency of data by verifying consistency based on timestamps between control signals periodically transmitted from the ECU and sensor data generated from the ROS, and by performing correction processing (e.g., interpolation, retransmission request, etc.) when necessary.

[0093] In one embodiment, the ROS bridge (120) can perform data conversion between different communication protocols and perform checksum-based integrity verification and timestamp-based time consistency verification on the converted data.

[0094] To explain in more detail, the ROS bridge (120) can perform a checksum verification procedure to ensure the integrity of the message generated during the data conversion process. Specifically, the ROS bridge (120) calculates a hash-based checksum value for the original data immediately before conversion and calculates a checksum value for the converted packet in the same way, and determines whether the data is corrupted by comparing the two. In this process, various checksum or hash algorithms such as CRC (Cyclic Redundancy Check), MD5 (Message Digest Algorithm), and SHA (Secure Hash Algorithm) may be used.

[0095] For example, if a specific byte is lost due to interference on the transmission path or a buffer overflow during the process of converting a braking pressure control signal output from the ECU (20) into a ROS message, the ROS bridge (120) can detect that the checksum value calculated after the conversion is complete does not match the checksum value of the original data and can discard the message or request retransmission. As another example, even if a data overflow occurs during the process of converting LiDAR frame data published in the ROS environment into an ECU format, the error can be immediately identified through the checksum mismatch, thereby preventing the input of damaged data into the ECU in advance.

[0096] Therefore, the checksum-based integrity verification function provided by the ROS bridge (120) can detect and correct errors that may occur during the conversion process of sensor data and control signals in real time, and can significantly improve data reliability in the test environment. In particular, in environments directly related to safety, such as autonomous driving tests, if damaged data is input into the ECU, incorrect control commands may occur; thus, this integrity verification function serves as a key element in ensuring the stability and safety of the system.

[0097] Additionally, the ROS bridge (120) can perform timestamp-based time consistency verification to ensure that data between different devices is not temporally inconsistent. Specifically, the ROS bridge (120) can reference the occurrence time of each data packet recorded by the logger (110) or sensor (11) in the form of a timestamp and control synchronization so that the time of transmission to the ECU (20) matches the occurrence time. Through this, even when sensors with different cycles and amounts of data are operated simultaneously, the data is aligned and processed on the same time axis.

[0098] For example, if camera video frames occur at approximately 33ms (30fps cycle) and LiDAR point cloud data occurs at 100ms intervals, the ROS bridge (120) can correct the frame and point cloud based on the timestamps of the two sensor data so that they match as if they were observed by the ECU at the same time point. Even if a specific camera frame arrives late due to network delay, the ROS bridge (120) refers to the recording timestamp of the frame to correctly synchronize it with the LiDAR data and transmit it to the ECU. Through this, the ECU receives an input that reproduces the exact time of data generation during actual driving, allowing it to accurately test the operation of the control algorithm.

[0099] As another example, when an ECU is linked with a driving simulation module to perform a closed-loop HILS test, if the sensor data and the ECU output signal are out of sync by even 1 to 2 ms, the response of the control algorithm may differ from the actual driving situation. The ROS bridge (120) detects and corrects even such minute errors through timestamp-based time consistency verification, thereby ensuring that the test environment has the same temporal context as the actual driving conditions.

[0100] Accordingly, the timestamp-based time alignment verification function of the ROS bridge (120) can contribute to accurate reproduction of driving conditions, ensuring test reliability, and performing closed-loop-based HILS verification by ensuring that sensor data of various cycles and ECU control signals are aligned on a single consistent time axis.

[0101] According to one embodiment of the present invention, the autonomous driving test system may include a playback module (130) for utilizing recorded driving data for ECU verification.

[0102] More specifically, the playback module (130) can directly transmit data recorded in the rosbag file to the input of the ECU (20) without going through the ROS topic-based publisher-subscriber (pub / sub) procedure. Generally, the publisher-subscriber procedure in a ROS environment is structured such that when a sensor node or application node publishes a message to a specific topic, other nodes that subscribe to that topic receive the message. In this process, a ROS master (ROS1) or DDS middleware (ROS2) manages the communication session, and the message is delivered through the steps of serialization, transmission, and deserialization. While this structure is advantageous for distributed scalability, problems such as latency, queue overflow, and callback processing delay may occur as the data transmission path becomes more complex. In particular, when reproducing large volumes of sensor data, such as camera footage or LiDAR point clouds, problems like frame drops or timestamp inconsistencies occur frequently, making it difficult to accurately reproduce test data.

[0103] The playback module (130) of the present invention can omit the publisher-subscriber procedure and directly convert and transmit data recorded in a rosbag file to match the signal format required by the ECU (20). To this end, the playback module (130) supplies data by directly interacting with the ECU communication interface based on ROS API calls without going through the publisher-subscriber path of the ROS middleware. The playback module (130) provides an API that abstracts driver-level calls for each ECU interface, allowing the playback section, playback speed, and sensor channel to be programmatically controlled in a test script.

[0104] Through this structure, serialization-deserialization processes and message queue management steps can be eliminated, and data packets suitable for ECU input formats (CAN, Ethernet, etc.) are directly generated and transmitted at the API level. For example, by immediately calling and transmitting a LiDAR data frame read from rosbag via the ROS API in accordance with the Ethernet packet structure defined by the ECU, it can be delivered to the ECU input buffer without undergoing unnecessary internal topic processing. Consequently, data transmission delays are minimized, loss of large-capacity sensor data is prevented, and a highly reliable test environment can be provided that is reproduced with the same timing as during recording.

[0105] According to one embodiment, the playback module (130) can control the transmission to the ECU (20) at the same time interval as the recording time by referring to the timestamp information of each frame recorded in the rosbag file. More specifically, the playback module (130) can simulate the time flow of actual driving by calculating the playback time based on the timestamp included in each sensor data frame stored in the rosbag file and sequentially transmitting data to the ECU (20) at the corresponding time. For example, if camera video frames are recorded at intervals of 33ms, the playback module (130) can reproduce conditions identical to the original driving situation by transmitting each frame to the ECU (20) at the same 33ms interval. Timestamp-based playback control prevents errors caused by time delays or synchronization mismatches during the ECU verification process and enables the faithful restoration of data input conditions at the time of driving. Therefore, the playback module (130) can support the evaluation of the ECU's control algorithm under data conditions identical to the actual driving situation in a HILS environment.

[0106] According to one embodiment of the present invention, the logger (110), ROS bridge (120), and playback module (130) may be implemented based on the ROS open source framework. ROS (Robot Operating System) is a general-purpose middleware platform for the development of robots and autonomous driving systems, and includes a message-based data exchange structure, sensor actuator drivers, visualization tools, debugging tools, network communication packages, etc. Since ROS is distributed in an open source form, it is not dependent on proprietary software licenses or dedicated hardware devices of specific vendors and can be freely utilized in various development environments and hardware platforms.

[0107] Due to these structural features, the autonomous driving test system of the present invention can be constructed without the high licensing costs required for existing commercial HILS equipment (dSPACE, ETAS, etc.) or the purchase of dedicated hardware from a specific manufacturer. That is, the logger (110), ROS bridge (120), and playback module (130) can be implemented and executed on low-cost / general-purpose hardware such as general-purpose PCs, embedded boards, and standard network interface devices, which provides the effect of improving the cost efficiency of the test system.

[0108] In addition, each component module of the present invention, implemented based on the ROS open-source framework, can utilize numerous packages and libraries provided within the ROS ecosystem. For example, integration with new sensor drivers, various automotive communication standards (CAN, FlexRay, Ethernet, etc.), and simulation modules (Gazebo, CARLA, etc.) is possible without module redevelopment, and functions tailored to specific test purposes can be rapidly expanded by directly modifying the source code as needed. This can be considered a significant technical differentiator in that it simultaneously guarantees compatibility and scalability for the test environment.

[0109] Accordingly, the autonomous driving test system according to the present invention is characterized by technical features such as independence not bound by specific hardware or proprietary software licenses, cost reduction effects due to its open-source basis, high scalability and compatibility through the utilization of the ROS ecosystem, and flexibility to quickly customize the test environment to suit the user's purpose. The aforementioned technical features enable the simultaneous achievement of universality and cost-effectiveness, which existing commercial HILS-based test systems could not provide, and can efficiently support the development and verification process of autonomous driving ECUs and algorithms.

[0110] In addition, in the embodiment, the autonomous driving test system can support closed-loop HILS testing by providing the output signal of the ECU (20) to a ROS-based virtual vehicle model or simulation module, and by providing sensor data generated from the virtual vehicle model or simulation module back as input to the ECU (20). More specifically, the ECU (20) executes a vehicle control algorithm to produce control commands such as steering, braking, and driving torque. The produced control commands are transmitted to the virtual vehicle model through the ROS bridge (120), and the virtual vehicle model calculates the vehicle's motion state according to the input control commands to form a virtual driving trajectory. In this process, the virtual vehicle model goes beyond simply calculating the vehicle's speed or position to generate various sensor data such as virtual camera images, LiDAR point clouds, radar signals, and vehicle speed, thereby providing input conditions similar to the actual driving environment to the ECU.

[0111] This cyclic structure differs from a form where the ECU simply passively receives recorded data (rosbag). In other words, since a feedback loop is formed in real time where the output of the ECU leads to the calculation of the virtual vehicle model's behavior and the result returns to the ECU's input, the responsiveness of the ECU control algorithm is directly reflected in the testing process. For example, if the ECU commands an excessive steering angle, the virtual vehicle model calculates an understeer trajectory based on actual physical constraints and resupplies image data or LiDAR recognition data corresponding to the calculated trajectory back to the ECU. This allows the ECU to repeatedly and safely verify various dynamic situations that may be encountered during actual road driving.

[0112] In particular, this closed-loop HILS structure enables the precise evaluation of the ECU's response capabilities not only during normal algorithm operation but also in failure situations or extreme conditions. For example, if a frontal obstacle suddenly appears in a virtual environment, the ECU outputs a braking command, and the resulting virtual sensor data is fed back to the ECU to verify the stability of braking control and whether ABS intervention is required. Since such iterative scenario-based testing becomes possible, risks that may occur on actual roads can be prevented in advance, and stability and reliability can be secured early in the development process.

[0113] Therefore, the autonomous driving test system according to the present invention goes beyond simply reproducing past data and can implement a closed-loop environment similar to actual driving through interaction between the ECU and a virtual vehicle model. Through this, users can sufficiently verify and optimize ECU algorithms in a virtual environment prior to actual driving tests, which entail costs and risks, thereby providing the effect of dramatically improving the safety and efficiency of autonomous driving system development.

[0115] FIG. 3 is an exemplary diagram illustrating the process of logging and converting a plurality of sensor data related to an embodiment of the present invention in a ROS environment by time synchronization.

[0116] As illustrated in FIG. 3, data output from various sensors such as a camera (11a), lidar (11b), and CAN (11c) each have different sampling periods and transmission delay characteristics, so simple collection alone may result in problems such as time inconsistencies or missing data. Accordingly, after collecting each sensor data, the logger (110) assigns a common timestamp based on a GPS time signal, a high-precision clock, or a network-based synchronization protocol (NTP, PTP, etc.) and ensures time consistency between the data by aligning them according to the actual order of occurrence. The synchronized data is recorded as a rosbag file and simultaneously transmitted in real time to the ECU (20) via the ROS bridge (120).

[0117] In addition, the logger (110) can be linked with ROS visualization and monitoring tools such as RViz and rqt to simultaneously display sensor data and ECU status information. For example, RViz can visualize camera images, LiDAR point clouds, and GPS location information in a three-dimensional space, and rqt provides real-time changes in ECU control variables (e.g., steering angle, braking pressure, driving torque) as graphs, allowing the user to intuitively understand input data and control output during the test process.

[0118] The ROS bridge (120) converts sensor data organized into ROS topics during this data exchange process into vehicle communication protocols such as CAN and Ethernet that can be recognized by the ECU (20) and provides them, and conversely, the control signal output from the ECU (20) is also converted into a ROS message and re-transmitted to the logger (110).

[0119] That is, multiple sensor data are precisely time-synchronized and recorded by a logger (110), and have a structure in which they are exchanged bidirectionally with the ECU (20) through a ROS bridge (120). Through this structure, all input and output data generated during vehicle operation can be managed and analyzed within a single integrated system, thereby ensuring high reliability in subsequent reproduction tests or cause analysis processes.

[0120] FIG. 4 is an exemplary diagram illustrating the process of testing an ECU by replaying rosbag recording data in a HILS test mode related to an embodiment of the present invention.

[0121] As illustrated in FIG. 4, a plurality of sensor data and vehicle control signals acquired in a vehicle driving environment are stored in a rosbag file by a logger (110) and can subsequently be provided again as input to the ECU (20) through a playback module (130). The playback module (130) refers to the timestamp of each data frame in the rosbag file and supplies the data to the ECU (20) at the same time interval and order of occurrence as at the time of recording, thereby enabling the ECU (20) to receive input under conditions identical to those during actual driving. Through this, the ECU (20) can repeatedly perform control algorithm verification and function testing in an environment similar to the field.

[0122] In particular, the playback module (130) of the present invention can directly convert and provide recorded data into a signal format (CAN frame, Ethernet packet, image / tensor data, etc.) required by the ECU (20) without going through the publisher-subscriber (pub / sub) procedure of the ROS architecture. Therefore, delays, callback delays, or data loss that may occur during serialization / deserialization and message queue management can be fundamentally reduced, and data such as large-capacity camera images or LiDAR point clouds can be stably reproduced as ECU input without frame drops.

[0123] Additionally, the playback module (130) provides an API-based interface to selectively play only specific sections of the rosbag file, adjust the playback speed, and filter only specific sensor data to input into the ECU (20). For example, the braking control algorithm of the ECU can be intensively verified by repeatedly playing only the sudden braking scenario section, or the performance of the image recognition module can be independently tested by selectively providing only camera image data.

[0124] Accordingly, the loop logging and playback structure of the present invention according to FIG. 4 enables closed-loop HILS testing based on actual driving data and provides a repetitive and stable verification environment during the ECU development process. Furthermore, it can efficiently reproduce various test scenarios, ensuring high versatility and reliability ranging from functional verification and performance analysis to tracing the cause of problems.

[0125] The components of the present invention may be implemented as a program (or application) and stored on a medium to be executed in combination with a computer, which is hardware. The components of the present invention may be implemented as software programming or software elements, and similarly, embodiments may be implemented in programming or scripting languages ​​such as C, C++, Java, assembler, etc., including various algorithms implemented as combinations of data structures, processes, routines, or other programming configurations. Functional aspects may be implemented as algorithms executed on one or more processors.

[0126] Those skilled in the art will understand that the various exemplary logic blocks, modules, processors, means, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented by electronic hardware, various forms of programs or design code (referred to herein as “software”), or a combination of all such. To clearly illustrate this interoperability between hardware and software, various exemplary components, blocks, modules, circuits, and steps have been generally described above in relation to their functions. Whether such functions are implemented as hardware or software depends on the design constraints imposed on the specific application and the overall system. Those skilled in the art may implement the functions described in various ways for each specific application, but such implementation decisions should not be interpreted as being outside the scope of the invention.

[0127] The various embodiments presented herein may be implemented as methods, devices, or articles of manufacture using standard programming and / or engineering techniques. The term “article of manufacture” includes a computer program, carrier, or medium accessible from any computer-readable device. For example, computer-readable media include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips, etc.), optical discs (e.g., CDs, DVDs, etc.), smart cards, and flash memory devices (e.g., EEPROMs, cards, sticks, key drives, etc.). Additionally, the various storage media presented herein include one or more devices and / or other machine-readable media for storing information. The term “machine-readable media” includes, but is not limited to, wireless channels and various other media capable of storing, holding, and / or transmitting command(s) and / or data.

[0128] It should be understood that the specific order or hierarchy of steps in the presented processes is merely an example of exemplary approaches. It should be understood that, based on design priorities, the specific order or hierarchy of steps in the processes may be rearranged within the scope of the invention. The appended method claims provide various step elements in a sample order, but do not imply limitation to the specific order or hierarchy presented.

[0129] The description of the presented embodiments is provided so that any person skilled in the art may use or practice the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the present invention. Thus, the present invention is not limited to the embodiments presented herein, but should be interpreted in the broadest possible scope consistent with the principles and novel features presented herein.

Claims

Claim 1 An autonomous driving test system supporting loop logging and HILS (Hardware-In-the-Loop Simulation), comprising: a logger that collects multiple sensor data, synchronizes the time, and records it; a ROS bridge that converts ROS messages generated in a ROS (Robot Operating System) software architecture into signals of a vehicle communication protocol specification recognizable by an ECU (Electronic Control Unit) that does not directly support ROS messages, and converts hardware control signals output from the ECU into ROS messages and provides them to the ROS software architecture to relay bidirectional heterogeneous protocol conversion, while performing checksum-based integrity verification and timestamp-based time consistency verification on the converted signals; and the ECU that interacts with the ROS software architecture through the ROS bridge. Claim 2 An autonomous driving test system supporting loop logging and HILS according to claim 1, wherein the logger comprises a time synchronization module that assigns a common time standard to the plurality of sensor data and a buffer memory that temporarily stores the collected data to prevent omission in the recording process. Claim 3 In claim 1, the logger is a loop logging and HILS-supported autonomous driving test system that records time-synchronized multiple sensor data and timestamp information corresponding to each sensor data in a rosbag file format. Claim 4 In paragraph 3, the above logger is a loop logging and HILS-supported autonomous driving test system that includes test condition information and vehicle status information as metadata and records them in a time-synchronized form with the plurality of sensor data. Claim 5 In claim 4, the logger further includes vehicle control signals as recording targets, and is linked with a visualization tool and a monitoring tool based on the ROS software architecture to acquire sensor data display information and ECU status display information, generates cause analysis information based on the plurality of sensor data, vehicle control signals and metadata, and provides a user interface for displaying the sensor data display information, the ECU status display information and the cause analysis information, a loop logging and HILS-supported autonomous driving test system. Claim 6 In paragraph 3, the system further comprises a playback module that transmits data recorded in the rosbag file to the input of the ECU without going through a ROS topic-based publisher-subscriber procedure, a loop logging and HILS-supported autonomous driving test system. Claim 7 In claim 6, the above-mentioned playback module controls the transmission to the ECU at the same time interval as the recording time by referring to the timestamp information of each frame recorded in the above-mentioned rosbag file, in a loop logging and HILS-supported autonomous driving test system. Claim 8 In claim 6, the logger, the ROS bridge, and the playback module are implemented based on the ROS open source framework and operate without being dependent on specific hardware devices or proprietary software licenses, a loop logging and HILS-supported autonomous driving test system. Claim 9 delete Claim 10 A loop logging and HILS-supported autonomous driving test system according to claim 1, wherein the system provides an output signal of the ECU to a ROS-based virtual vehicle model or simulation module and provides sensor data generated from the virtual vehicle model or simulation module back to the input of the ECU to support closed-loop HILS testing.

Images