Method and system for recording and managing vehicle generation data

Abstract

The vehicle system includes a communication device enabling communication between the vehicle and a remote server, a first data recorder for storing in a first internal store a plurality of interaction data representative of time-stamped interactions occurring between the vehicle's autonomous driving system and a driver while traveling, and a second data recorder for storing in a second internal store event data indicative of a vehicle state during a predetermined time period before and after the occurrence of a predefined event, the first data recorder being configured to protect at least one interaction data stored proximate to the occurrence of the event by overwriting it with new interaction data without uploading it to the remote server.

Description

Technical Field

[0001] The present invention relates to a data recorder that records data generated by a vehicle.

Background Art

[0002] The content described in this section merely provides background information related to the present invention and does not constitute prior art.

[0003] An event data recorder (EDR) is configured to detect an accident or the like and record information related to the driving state of the vehicle and operations by the driver within a predetermined time before and after that time. Various parameters including speed, seat belt state, and airbag deployment state are stored so that they can be recovered during the forensic investigation process.

[0004] Forensic investigations are generally performed by reading data through a vehicle's diagnostic link connector (e.g., OBD-II port) or physically extracting the data memory of the event data recorder. The data in the event data recorder may be damaged or altered by incorrect reading techniques and may also be maliciously manipulated or deleted after storage, and it is difficult to consider that the integrity of the stored data is fully guaranteed.

[0005] As the application of ADAS (Advanced Driver Assistance Systems) and autonomous driving functions expands, it is useful for an appropriate investigation of the cause of an accident to identify which of the autonomous driving system and the driver was controlling the vehicle at the time of the accident.

Summary of the Invention

Problems to be Solved by the Invention

[0006] This disclosure presents a technique for identifying and protecting interaction data recorded close to the time of an event, which is useful in a vehicle system that includes a first data recorder for recording multiple interaction data showing times-stamped interactions that occurred between the vehicle's autonomous driving system and the driver while the vehicle is in motion, and a second data recorder for recording event data representing the vehicle's state during a predetermined period before and after an event such as a collision. [Means for solving the problem]

[0007] According to one aspect of this disclosure, a vehicle system includes a communication device that enables communication between the vehicle and a remote server, a first data recorder for storing a plurality of interaction data representing timestamped interactions that occurred between the vehicle's autonomous driving system and the driver while the vehicle was in motion in a first internal storage, and a second data recorder for storing event data indicating the vehicle state for a predetermined period before and after the occurrence of a predefined event in a second internal storage. The first data recorder is configured to protect at least one interaction data stored close to the time of the event (hereinafter referred to as "primary interaction data") by overwriting it with new interaction data without uploading it to the remote server.

[0008] The embodiment of the vehicle system further includes one or more of the following features:

[0009] In some embodiments, the first data recorder is configured to set the lock flag of new interaction data to a first value and change the lock flag of the main interaction data to a second value when saving new interaction data to the first internal storage.

[0010] In some embodiments, the second data recorder is configured to send a locking request signal to the first data recorder in response to the occurrence of the event, so that the first data recorder can identify the primary interaction data from among the plurality of interaction data.

[0011] In some embodiments, the first data recorder is configured to respond to the lock request signal by changing the lock flag of recent interaction data stored during a certain period prior to the time the lock request signal was received to a second value.

[0012] In some embodiments, the first data recorder is configured to respond to the lock request signal by changing the lock flag of a predefined number of recent interaction data stored prior to the time the lock request signal was received to a second value.

[0013] In some embodiments, the first data recorder and the second data recorder are configured to upload a plurality of interaction data stored in the first internal storage and event data stored in the second internal storage, respectively, to the remote server via the communication device. The first data recorder is configured to delete the associated interaction data from the first internal storage once the upload to the remote server is successful.

[0014] In some embodiments, the first data recorder is configured to preferentially upload the main interaction data from among a plurality of interaction data stored in the first internal storage to the remote server.

[0015] In some embodiments, the first data recorder is configured to upload a plurality of interaction data stored in the first internal storage to the remote server each time the vehicle's ignition system enters the ON state.

[0016] In some embodiments, the first data recorder is configured to upload the plurality of interaction data stored in the first internal storage to the remote server after a waiting time calculated by a random number generator has elapsed from the time the vehicle's ignition system enters the ON state.

[0017] Other aspects of this disclosure provide a method performed by a vehicle system comprising a first data recorder and a second data recorder. The method includes the steps of: using the first data recorder to store a plurality of interaction data representing timestamped interactions that occurred between the vehicle's autonomous driving system and the driver during a drive in a first internal storage; and using the second data recorder to store event data indicating the vehicle's state for a predetermined period before and after the occurrence of a predefined event in a second internal storage. The method further includes the steps of: using the first data recorder to identify at least one interaction data stored close to the time the event occurred; and using the first data recorder to change the value of a lock flag for the identified primary interaction data in order to protect it by overwriting it with new interaction data without uploading it to a remote server. [Effects of the Invention]

[0018] According to the descriptions in this disclosure, interaction data recorded close to the time of an event such as a collision is protected by being overwritten with new interaction data without being uploaded to a remote server. Furthermore, some of the technologies in this disclosure can increase the likelihood that interaction data recorded close to the time of the collision will be successfully uploaded to the remote server. [Brief explanation of the drawing]

[0019] [Figure 1]A conceptual diagram of an example of a centralized system that collects and manages vehicle-generated data from vehicles, where the technology of the present disclosure can be used. [Figure 2] A flowchart for explaining a method of setting a lock on interaction data recorded close to the time when an event occurs that triggers the recording of EDR in a vehicle according to an embodiment of the present invention. [Figure 3] A flowchart for explaining a method for a vehicle to store new interaction data according to an embodiment of the present invention. [Figure 4] A flowchart for explaining a method for a vehicle to transmit interaction data to a cloud storage system according to an embodiment of the present invention. [Figure 5] A conceptual diagram showing the difference between event data and interaction data recorded in a vehicle.

Embodiments for Carrying Out the Invention

[0020] Hereinafter, some embodiments of the present invention will be described in detail through exemplary drawings. Note that when adding reference numerals to the components of each drawing, for the same components, even if they are shown in other drawings, they are made to have the same reference numerals as much as possible. In addition, in the description of the present invention, when it is determined that a specific description of a related known configuration or function makes the gist of the present invention unclear, the detailed description thereof will be omitted.

[0021] FIG. 1 is a conceptual diagram of an example of a centralized system that collects and manages vehicle-generated data from vehicles, where the technology of the present disclosure can be used.

[0022] System 100 includes an in-vehicle data recording system 10 equipped in a vehicle and a cloud storage system 20 implemented on a server on a network. The server implementing the cloud storage system 20 includes a server operated by a vehicle manufacturer, a server operated by an operator independent of the vehicle manufacturer, or a combination thereof.

[0023] The vehicle is configured to operate completely or partially in an autonomous driving mode and may thus be referred to as an "autonomous driving vehicle". For example, the autonomous driving system 14 can receive information from the sensor system 13 and execute one or more control processes in an automated manner based on the received information (such as setting steering to avoid detected obstacles).

[0024] The vehicle is fully autonomous or partially autonomous. In a partially autonomous vehicle, some functions are manually controlled by a driver temporarily or continuously. Further, the partially autonomous vehicle is configured to be switchable between a fully manual operation mode and a partially autonomous operation and / or a fully autonomous operation mode.

[0025] The vehicle includes a data recording system 10 configured to generate, record, or store various types of data related to the operation of the vehicle and the behavior of the driver. The in-vehicle data recording system 10 includes two types of data recorders: an Event Data Recorder (EDR) 11 and a Data Storage System for Automated Driving Vehicles (DSSAD) 12. These record vehicle-generated data for different purposes.

[0026] The purpose of EDR11 is to store vehicle information about specific events, such as airbag deployment. EDR11 data is used for crash analysis and reconstruction. The purpose of DSSAD12 is to record all predefined interactions between the driver and the autonomous driving system. Generally, DSSAD12 data, stored in a timestamp format, is used to identify who was controlling the vehicle at a particular point in time. EDR11 and DSSAD12 data are used complementaryly in forensic investigations, and DSSAD12 data is particularly useful in identifying who was controlling the vehicle at the time of the collision.

[0027] The EDR11 can receive data from various sensors and / or electronic control units (ECUs) mounted on the vehicle. The EDR11's buffer (or volatile memory) continuously updates and records data over a set period of time. When the EDR11 detects the occurrence of one or more predefined events, it is designed to save the data recorded in the buffer within a predetermined time before and after the detection to an internal data storage (or non-volatile memory). Such events are particularly traffic collisions. A traffic collision is detected, for example, when the deployment of an irreversible safety device such as an airbag or pretensioner is triggered. A traffic collision may also be detected when acceleration or deceleration exceeding a predefined threshold occurs (e.g., a speed change of 8 km / h or more within 150 ms). Events may further include failures of the vehicle's main functions.

[0028] The EDR11 can also receive trigger signals from an electronic control unit, such as an airbag control unit (ACU), to indicate the occurrence of an event. The EDR11 has access to values ​​measured by at least one sensor included in the sensor system 13. At least one sensor is designed to sense the vehicle's speed / acceleration / distance traveled / geographic location, etc. The EDR11 may be included as a single module within the airbag control unit (ACU).

[0029] The data recorded and stored by EDR11 is suitable for analyzing collision accidents, such as vehicle dynamics, driver behavior, and the operating status of vehicle safety systems. EDR11 provides the stored data (which may also be referred to as "EDR data" or "event data") to a communication device 15 so that it can be transmitted to a cloud storage system 20.

[0030] The autonomous driving system 14 generates interaction signals that represent interactions between the driver and the autonomous driving system 14. Such interaction signals include signals indicating whether one or more autonomous driving functions are currently active. For example, the autonomous driving system 14 generates a signal indicating whether the Adaptive Cruise Control (ACC) function is currently active. As another example, the autonomous driving system 14 may generate a signal indicating whether the vehicle's driving is currently under fully automated control rather than manual control. Such interaction signals may further include signals indicating a transition demand instructing the driver to take over control of the driving task, and signals indicating that control of the driving task has been taken over to the driver. The autonomous driving system 14 provides interaction signals to the DSSAD 12 via a data bus (e.g., a CAN bus, an Ethernet bus, etc.).

[0031] The DSSAD12 stores multiple interaction data representing interactions between the driver and the autonomous driving system in an internal storage location, based on interaction signals received from the autonomous driving system 14 while driving. The DSSAD storage is a non-volatile memory such as EEPROM or flash memory. The DSSAD12 is a data storage system installed in vehicles equipped with highly-automated driving systems (e.g., classified as SAE levels 3, 4, and 5) and aims to clearly distinguish between the "entity requested to drive" and the "entity that actually drove." During the switching process (i.e., from the time a switching request is issued until the driver actually takes over control), the "entity requested to drive" and the "entity that actually drove" may be different from each other.

[0032] Interaction data includes, for example, time-stamped data elements representing specific interaction events such as changes in the state of the autonomous driving system (switched off, activated, transition demand, override), the start and end of Minimal Risk Maneuver (MRM) by the autonomous driving system, and the handover of control of the driving task to the driver. DSSAD12 provides the communication device 15 with the stored interaction data (which may also be referred to as "DSSAD data") to be transmitted to the cloud storage system 20.

[0033] The communication device 15 is an electronic device having wired or wireless communication capabilities that connects the vehicle's internal network to an external communication network. The communication device 15 is, for example, a telematics unit (TMU) or a wired / wireless dongle plugged into an OBD-II port. The communication device 15 may be configured to include a wireless transceiver capable of cellular communication such as GSM / WCDMA / LTE / 5G, or short-range wireless communication such as WLAN, c-V2X, WAVE, DSRC, or Bluetooth.

[0034] When the communication device 15 receives EDR data from the EDR 11, it generates an event report message. The communication device 15 transmits the event report message to the cloud storage system 20 via the communication network. The event report message includes Vehicle Identifiable Information (VII) and the EDR data received from the EDR 11. In a typical embodiment, Vehicle Identifiable Information (VII) is the vehicle identification number (VIN), which is a 17-digit unique identifier consisting of numbers and letters assigned by the vehicle manufacturer to each individual vehicle. Alternatively, the vehicle identification information may be the license plate information, a unique identifier used by the communication device 15 for communication, or a (long-term or short-term) certificate assigned to the vehicle for V2X communication. The event report message may further include additional information such as the geographical location, date, and time the event occurred.

[0035] When the communication device 15 receives DSSAD data from the DSSAD 12, it generates an interaction report message. The communication device 15 transmits the interaction report message to the cloud storage system 20 via the communication network. The interaction report message includes vehicle identification information VII and the DSSAD data received from the DSSAD 12.

[0036] The cloud storage system 20 is a data management system implemented on a network server that collects and manages EDR data and DSSAD data from a large number of vehicles.

[0037] The cloud storage system 20 receives event report messages and interaction report messages from numerous vehicles. For the report messages received from the vehicles, the cloud storage system 20 separates vehicle identification information (VII) from the EDR / DSSAD data, enabling third parties to identify or track the associated vehicles and individuals. The vehicle identification information (VII) and the EDR / DSSAD data are stored in separate databases.

[0038] The cloud storage system 20 responds to requests from users 30 who wish to use EDR / DSSAD data by providing either anonymized EDR / DSSAD data that does not identify specific vehicles or individuals, or EDR / DSSAD data that identifies specific vehicles or individuals. Users 30 include vehicle owners, drivers, insurance companies, government agencies, researchers, and vehicle manufacturers who wish to utilize EDR / DSSAD data. The cloud storage system 20 must provide data only to investigators or other users authorized by the relevant vehicle owners, unless otherwise authorized by a court order, search warrant, and / or other applicable laws and regulations.

[0039] A centralized system like the one shown in Figure 1, which collects and manages DSSAD data from vehicles, frees EDR11 and DSSAD12 from storage capacity constraints.

[0040] As shown in Figure 5, EDR11 records or stores relevant data when an event such as a collision occurs, while DSSAD12 records or stores the interaction between the vehicle and the driver while driving. Note that the volume of data that DSSAD12 must record or store is significantly larger than that of EDR11. Furthermore, uploading EDR / DSSAD data to the cloud storage system may fail for a considerable period due to various reasons such as problems with the vehicle's communication device, expiration of the communication service subscription, or connection failures due to traffic congestion. This can lead to the internal storage capacity of DSSAD12 becoming full, and when the internal storage capacity is full, DSSAD12 is configured to overwrite the internal storage in a FIFO (first-in first-out) loop. Therefore, there remains a significant risk that past interaction data stored in DSSAD12's internal storage will be overwritten with new interaction data without being uploaded to the cloud storage system 20.

[0041] The inventors noted that EDR data and DSSAD data are used complementaryly in forensic investigations, and that DSSAD data, in particular, is useful for identifying the entity that was controlling the vehicle at the time of the collision. Therefore, among the series of interaction data recorded and stored by DSSAD12 while driving, the interaction data recorded close to the time of the collision is extremely important in forensic investigations.

[0042] Some of the technologies in this disclosure are intended to prevent interaction data recorded close to the time of collision from being overwritten with new interaction data without being uploaded to a cloud storage system. Furthermore, some of the technologies in this disclosure are intended to ensure that interaction data recorded close to the time of collision is uploaded to the cloud storage system as successfully as possible.

[0043] As will be explained in detail below, according to the technology of this disclosure, interaction data recorded in close proximity to the time of collision is protected from overwriting due to insufficient internal storage capacity or periodic data deletion, and is uploaded to a cloud storage system in priority to other interaction data.

[0044] Figure 2 is a flowchart illustrating a method for setting a lock on interaction data recorded close to the time of an event that triggers EDR recording by a vehicle, according to one embodiment of the present invention.

[0045] The EDR11 can also receive trigger signals indicating the occurrence of an event from an electronic control unit such as an airbag control unit (ACU). The EDR11 can also detect the occurrence of an event based on values ​​measured by at least one sensor included in the sensor system 13. At least one sensor is designed to sense the vehicle's speed / acceleration / distance traveled / geographic location, etc.

[0046] When EDR11 detects the occurrence of at least one predefined event or receives a trigger signal indicating the occurrence of an event, it can save event data recorded in a buffer (or volatile memory) within a predetermined time before and after the event to an internal storage location (or non-volatile memory) (S201), and can set a lock on the saved event data to prevent overwriting. Rule information that defines trigger conditions, data items to be saved in response to trigger signals, and data lock conditions is stored in the internal storage location or other non-volatile memory of EDR11.

[0047] EDR11 transmits a locking request signal to DSSAD12, requesting that a lock be set on the interaction data recorded close to the time the event occurred (S202).

[0048] Upon receiving a lock request signal (S203), DSSAD12 searches its internal storage for the target interaction data according to predefined rules (S204) and assigns a second value (e.g., "1") to the lock flag of the target interaction data (S205). DSSAD12 can identify the target interaction data based on the time the lock request signal was received. For example, the target interaction data is recent interaction data stored within a certain period prior to the time the lock request signal was received. Alternatively, the target interaction data is a predefined number of recent interaction data stored prior to the time the lock request signal was received.

[0049] The DSSAD11's internal storage or other non-volatile memory stores rule information that defines how to identify the interaction data to be locked, the scope of the locked data, and the format of the locked data. The rule information stored in the EDR11 and the rule information stored in the DSSAD are different from each other and are managed independently.

[0050] DSSAD12 transmits a response to EDR11 to inform it of the lock execution result (S206). The response received from DSSAD12 may indicate whether the lock execution was successful or not. Based on the response received from DSSAD12, EDR11 determines whether the lock was executed successfully (S207). Due to network problems or defects in DSSAD12, DSSAD12 may not receive the lock request signal from EDR11, or EDR11 may not receive a response from DSSAD12, in which case EDR11 may determine that the lock has failed. When the lock fails, EDR11 increments the failure count (FC) by 1 (S209) and transmits the lock request signal again to the cloud storage system (S202). If the failure count FC exceeds the threshold ("yes" in S210), EDR11 provides an alarm to the driver and terminates the lock process.

[0051] Figure 3 is a flowchart illustrating a method for a vehicle to save new interaction data according to one embodiment of the present invention.

[0052] When DSSAD12 receives a new interaction signal from the autonomous driving system, it generates new interaction data to be stored in its internal storage.

[0053] Interaction data has four fields, including a lock flag, a timestamped timestamp, and a type flag. The lock flag indicates whether the interaction data is locked. The timestamped time represents the time when a specific interaction occurred between the driver and the system. The type flag indicates the type of interaction between the driver and the system, such as a failover request or a minimum-risk activation.

[0054] When DSSAD12 saves new interaction data to its internal storage, it assigns a first value (e.g., "0") to the lock flag of the new interaction data (S301). As described above, in response to receiving a lock request signal from EDR11, the lock flag of interaction data that meets the lock condition is changed to a second value (e.g., "1").

[0055] DSSAD12 checks whether there is enough free storage space in the internal storage to store new interaction data (S302-S303). If there is enough free storage space ("Yes" in S303), DSSAD12 stores the new interaction data in the free storage space (S307).

[0056] If there is insufficient empty storage space ("No" in S303), the data storage is overwritten in a FIFO (first-in first-out) loop, but locked interaction data must be protected from overwriting. DSSAD12 moves to the beginning of the internal storage (S304) and determines whether the already stored interaction data is locked based on the lock flag value of the already stored interaction data (S305).

[0057] If the lock flag of already saved interaction data has a first value (i.e., "0") ("No" in S305), DSSAD12 overwrites the already saved interaction data with new interaction data (S307).

[0058] If the lock flag of already saved interaction data has the second value (i.e., "1") ("yes" in S305), DSSAD12 moves to the next save location to find interaction data that is not locked, without overwriting it with new interaction data (S306).

[0059] On the other hand, when the percentage of empty storage space in the internal storage reaches a predefined threshold ratio (e.g., 90%), the DSSAD12 may be configured to delete old interaction data. Furthermore, the DSSAD12 may be configured to periodically delete old interaction data in order to keep the remaining storage capacity of the internal storage at a constant level as much as possible. By maintaining the remaining storage capacity of the internal storage at a constant level, the DSSAD12 can efficiently handle situations where a large amount of interaction data must be recorded suddenly. In addition, this method of pre-deleting old interaction data is also advantageous from a data recovery perspective compared to the FIFO loop overwrite method. Locked interaction data must be protected from such (periodic) deletion tasks.

[0060] Figure 4 is a flowchart illustrating a method by which a vehicle transmits interaction data to a cloud storage system 20 according to one embodiment of the present invention. According to this embodiment, locked data (i.e., primary data) is transmitted before unlocked data (i.e., general data).

[0061] When the upload process begins, DSSAD12 searches its internal storage for interaction data with the lock flag set to the second value (i.e., "1") (S401), and provides the found locked data to the communication device 15 so that it can be uploaded to the cloud storage system 20 (S402). Based on the upload results received by the cloud storage system 20, DSSAD12 determines whether the transmission of the locked data has been successfully completed (S403-S404). If the upload is successful, DSSAD12 can delete the transmitted locked data from its internal storage (S405).

[0062] Once the transmission of locked data is successfully completed, DSSAD12 can provide the communication device 15 with unlocked interaction data (i.e., general data) so that it can upload the unlocked interaction data to the cloud storage system 20 (S406). Upon successful upload, DSSAD12 can delete the transmitted unlocked interaction data from its internal storage (S407-S408).

[0063] Interaction data uploads may fail due to network issues or other reasons. When an upload fails, DSSAD12 increments the failure count (FC) by "1" (S405-1, S409-1) and can attempt to upload the interaction data to the cloud storage system 20 again (S402, S406). If the failure count (FC) exceeds a threshold ("Yes" in S405-2, S409-2), DSSAD12 provides an alarm to the driver and terminates the interaction data upload process.

[0064] In some embodiments, the DSSAD12 may be configured to perform an upload process that transmits interaction data to the cloud storage system 20 when the percentage of empty storage space in the DSSAD12's internal storage reaches a threshold.

[0065] In some other embodiments, DSSAD12 may be configured to periodically upload interaction data to a cloud storage system. For example, DSSAD12 may be scheduled to perform the interaction data upload process every 6 hours, every 12 hours, or daily or weekly. When the vehicle's ignition enters the ON state, DSSAD12 may also determine whether the upload cycle has elapsed since the last upload. If it is determined that the upload cycle has elapsed, DSSAD12 may also initiate the upload process.

[0066] In some other embodiments, the DSSAD12 may be configured to initiate an upload process that transmits interaction data to the cloud storage system 20 whenever the vehicle's ignition enters the ON state.

[0067] Therefore, in some embodiments, when a vehicle's ignition is turned on, the DSSAD12 executes an upload process to transmit interaction data to the cloud storage system 20. In such cases, during commuting hours, a large number of vehicle ignitions may be turned on in a short period of time, and therefore there may be a concentration of attempts to upload to the cloud storage system 20.

[0068] To distribute upload attempts, DSSAD12 may be configured to hold the execution of the upload process from the moment the vehicle's ignition enters the ON state until a waiting time calculated by a random number generator has elapsed. That is, DSSAD12 may be configured to start the upload process after the waiting time has elapsed from the moment the vehicle's ignition enters the ON state. The waiting time is, for example, the remainder obtained by dividing a predefined maximum waiting time (e.g., 30 minutes) by a random number.

[0069] It should be understood that the exemplary embodiments described above can be embodied in many other ways. In some embodiments, the various methods and apparatus described herein can be embodied in programmable hardware devices such as field programmable gate arrays (FPGAs), programmable array logic, and programmable logic devices. In some embodiments, the various methods, apparatus, servers, and (sub)systems described herein may be embodied in at least one general-purpose computer having a processor, memory, disks, or other mass storage, communication interfaces, input / output (I / O) devices, and other peripherals. The general-purpose computer can function as an apparatus, server, system, etc., that performs the aforementioned methods by loading software instructions into the processor and then executing instructions to perform the functions described herein.

[0070] On the other hand, the various methods described herein may be embodied in instructions stored on a non-temporary recording medium that can be read and executed by one or more processors. A non-temporary recording medium includes, for example, any type of recording device on which data is stored in a form readable by a computer system. For example, a non-temporary recording medium includes storage media such as EPROM (erasable programmable read-only memory), flash drives, optical drives, magnetic hard drives, and solid-state drives (SSDs).

[0071] The above description is merely illustrative of the technical concept of this embodiment, and any person with ordinary skill in the art to which this embodiment belongs will be able to make various modifications and variations without departing from the essential characteristics of this embodiment. Therefore, this embodiment is for illustrative purposes only and not to limit the technical concept of this embodiment, and the scope of the technical concept of this embodiment is not limited by such embodiment. The scope of protection of this embodiment should be interpreted by the claims, and all technical concepts within an equivalent scope should be interpreted as being included in the scope of rights of this embodiment.

[0072] [CROSS-REFERENCE TO RELATED APPLICATION] This patent application claims priority to patent application no. 10-2020-0033526 filed in Korea on 19 March 2020 and patent application no. 10-2021-0031545 filed in Korea on 10 March 2021, both of which are included herein by reference in their entirety.

Claims

1. It is a vehicle system, A communication device that enables communication between the vehicle and a remote server, A first data recorder for storing multiple interaction data representing timestamped interactions that occurred between the autonomous driving system and the driver of the vehicle while it was driving in a first internal storage location, and Includes a second data recorder for storing event data indicating the vehicle state during a predetermined time period before and after the occurrence of a predefined event in a second internal storage location, The first data recorder described above is The system is configured to protect at least one interaction data (hereinafter referred to as "primary interaction data") stored close to the time the event occurred from being overwritten by new interaction data without uploading it to the remote server. The first data recorder and the second data recorder are configured to upload a plurality of interaction data stored in the first internal storage and event data stored in the second internal storage to the remote server, respectively, via the communication device. The first data recorder is configured to prioritize uploading the main interaction data from among the multiple interaction data stored in the first internal storage to the remote server. A vehicle system characterized in that the first data recorder is further configured to upload the plurality of interaction data stored in the first internal storage to the remote server after a waiting time calculated by a random number board has elapsed from the time the vehicle's ignition device (Ignition) enters the ON state.

2. The first data recorder described above is When saving new interaction data to the first internal storage location, the lock flag of the new interaction data is set to a first value. The vehicle system according to claim 1, characterized in that the lock flag of the main interaction data is changed to a second value.

3. The second data recorder described above is: The vehicle system according to claim 2, characterized in that the first data recorder is configured to transmit a locking request signal to the first data recorder in response to the occurrence of the event, so that the first data recorder can identify the main interaction data from among the plurality of interaction data.

4. The first data recorder described above is The vehicle system according to claim 3, characterized in that, in response to the lock request signal, it is configured to change the lock flag of recent interaction data stored during a certain period prior to the time the lock request signal was received to a second value.

5. The first data recorder described above is The vehicle system according to claim 3, characterized in that, in response to the lock request signal, it is configured to change the lock flag of a predefined number of recent interaction data stored prior to the time the lock request signal was received to a second value.

6. The first data recorder described above is The vehicle system according to claim 1, characterized in that it is configured to delete the associated interaction data from the first internal storage when the upload to the remote server is successful.

7. A method performed by a vehicle system comprising a first data recorder and a second data recorder, The first data recorder stores multiple interaction data representing timestamped interactions that occurred between the vehicle's autonomous driving system and the driver during driving in a first internal storage location. The second data recorder stores event data indicating the vehicle state during a predetermined time period before and after the occurrence of a predefined event in a second internal storage location. The first data recorder identifies at least one interaction data (hereinafter referred to as "main interaction data") stored close to the time the event occurred, The first data recorder modifies the value of the lock flag for the identified primary interaction data in order to protect the primary interaction data from being overwritten by new interaction data without uploading it to a remote server. The steps include uploading multiple interaction data stored in the first internal storage location and event data stored in the second internal storage location to a remote server, From among the multiple interaction data stored in the first internal storage, the interaction data stored closest to the time of the event is preferentially uploaded to the remote server. Includes, A method characterized in that, after a waiting time calculated by a random number generator has elapsed from the moment the vehicle's ignition system enters the ON state, the plurality of interaction data stored in the first internal storage are uploaded to the remote server.

8. Furthermore, when saving new interaction data to the first internal storage, the lock flag of the new interaction data is set to a first value, and The method according to claim 7, characterized by including the step of changing the lock flag of the main interaction data to a second value.

9. The method according to claim 8, further comprising the step of the second data recorder transmitting a locking request signal to the first data recorder in response to the occurrence of the event, so that the first data recorder can identify the main interaction data from among the plurality of interaction data.

10. The method according to claim 9, further comprising the step of changing the lock flag of recent interaction data stored during a certain period prior to the time the first data recorder received the lock request signal to a second value in response to the lock request signal.

11. The method according to claim 9, further comprising the step of changing the lock flag of a predefined number of recent interaction data stored prior to the time the first data recorder received the lock request signal to a second value in response to the lock request signal.

12. The method according to claim 7, further comprising the step of deleting the associated interaction data from the first internal storage when the upload to the remote server is successful.

Images