Method and apparatus for recording event data in a vehicle

Abstract

The invention relates to a method (100) for recording event data in a vehicle, wherein vehicle data is continuously received from at least one vehicle system (3) and written as event data into data frames (DR) of a predefined size, wherein the individual data frames (DR) are stored in at least one volatile memory (50), wherein the stored data frames (DR) are managed and kept available in the at least one volatile memory (50) until the event data stored in the individual data frames (DR) is older than a predefined maximum event time point or is persistently stored in at least one non-volatile memory (46) in response to a recognized predefined event, wherein a current event time window (EZF) is predefined, in which the event data should be persistently recorded, wherein a start time point of the current event time window (EZF) is predefined as a time stamp with reference to a current zero reference time point, which is redefined if necessary, and an end time point of the current event time window (EZF) is predefined as a time difference from the start time point, and to a device (1) for carrying out the method for recording event data in a vehicle.

Description

Technical Field

[0001] This invention relates to a method and an apparatus for recording event data in a vehicle. The subject of this invention also includes an apparatus and a computer program product for performing such a method for recording event data in a vehicle, and a computer-readable storage medium on which the computer program product is stored. Background Technology

[0002] Because there is no human error, highly automated driving ensures safer traffic. Simultaneously, in vehicles with such highly automated driving functions, the need for data detection in response to failures increases, ensuring all necessary information is available for subsequent analysis and product improvement. Therefore, a method for recording event data is used in such vehicles. Here, vehicle data is continuously received from at least one vehicle system and written as event data into data frames of a pre-given size, wherein each data frame is stored in at least one volatile memory. The stored data frames are managed and kept available in the at least one volatile memory until the event data stored in each data frame is older than a pre-given maximum event prior time point (Vorereigniszeitpunkt) or is persistently stored in at least one non-volatile memory in response to a pre-given event. The apparatus for performing such a method for recording event data typically includes a data providing device, an event recognition device, and a data recording device. Summary of the Invention

[0003] The method for recording event data in a vehicle according to the present invention has the advantage of saving bits when representing and storing the start and end times of the current event time window, by storing only the start time and duration of the current event time window. Typically, a time window can be represented as two absolute times, i.e., as two timestamps—a start timestamp and an end timestamp. One such timestamp requires 32 bits, thus requiring 64 bits to represent a time window. A 32-bit processor can only atomically read or write 32 bits, i.e., in a single machine instruction; therefore, 64 bits require more than one machine instruction, which is not atomic. To represent the current event time window in 32 bits and thus provide a lock-free atomic implementation of the current event time window using a 32-bit processor, instead of two timestamps, a start timestamp and the time difference relative to the start timestamp are used to define the current event time window. The duration, or length, of the current event time window is expected to be a sequence of minutes. Therefore, instead of storing two complete timestamps for the start and end times of the current event time window, bits can be saved by storing only the start timestamp of the start time of the current event time window and the duration of the current event time window. Thus, for example, with a 32-bit processor, the current event time window can be read or stored atomically using 17 bits for the start timestamp and 14 bits for the duration or length of the current event time window, with a resolution of 0.1 seconds. Here, the start time of the current event time window can be represented, for example, up to a maximum value of 3.6 hours after the current zero reference time, and the duration or length of the current event time window can be represented up to a maximum value of 27.3 minutes or 1638 seconds.

[0004] Embodiments of the present invention provide a method for recording event data in a vehicle, wherein vehicle data is continuously received from at least one vehicle system and written as event data into data frames of a pre-given size. Each data frame is stored in at least one volatile memory, wherein the stored data frames are managed and kept available in the at least one volatile memory until the event data stored in the respective data frames is older than a pre-given maximum event pre-time point or is persistently stored in at least one non-volatile memory in response to a pre-given event. Here, a current event time window is pre-given, within which the event data should be persistently recorded, wherein the start time of the pre-given current event time window is a timestamp based on the current zero reference time point (Bezug), which is redefined as needed, and the end time of the pre-given current event time window is the time difference from the start time point.

[0005] Furthermore, an apparatus is provided for performing such a method for recording event data, the apparatus comprising a data providing device, a buffer block, an event recognition device, and a data recording device. The data providing device is configured to continuously receive vehicle data to be recorded from at least one vehicle system, write the vehicle data as event data into data frames of a pre-given size, and store each data frame in at least one volatile memory. The buffer block is configured to manage the stored data frames and keep the stored data frames available in the at least one volatile memory until the event data stored in each data frame is older than a pre-given maximum event time point or is persistently stored in at least one non-volatile memory in response to a pre-given event recognized by the event recognition device. Here, the event recognition device is configured to pre-define the current event time window, within which event data should be persistently recorded. The event recognition device is further configured to pre-define the start time of the current event time window as a timestamp based on the current zero reference time point, and pre-define the end time of the current event time window as the time difference from the start time point. The buffer block is configured to redefine the current zero reference time point when needed.

[0006] It is also advantageous to have a computer program product with program code stored on a machine-readable medium—such as semiconductor memory, hard disk memory, or optical memory—and used to perform analytical processing when the computer program is executed.

[0007] Advantageous improvements to the method for recording event data in a vehicle according to the invention and the apparatus for recording event data in a vehicle according to the invention can be achieved through the measures and extensions listed below.

[0008] In this document, a data providing device can be understood as a processing unit that includes all processing steps from detecting raw vehicle data to organizing and storing the vehicle data as event data in a volatile storage block, so that the event data can remain available in the at least one volatile memory for a limited time period. In this document, an event recognition device can be understood as a processing unit that continuously monitors the state of the vehicle and determines when a pre-configured condition or pre-given event occurs, which requires the permanent storage of pre-given vehicle data. Such a pre-given event may be, for example, an identified malfunction of a vehicle system or an identified collision between the vehicle and a stationary obstacle or other vehicles. In this document, a data recording device can be understood as a processing unit that includes processing steps to extract vehicle data available for use in the at least one volatile memory, possibly perform further data transformation—such as encryption—and finally persistently store the vehicle data in at least one non-volatile memory.

[0009] Therefore, the data providing device, the event recognition device, and the data recording device may each have at least one interface, which may be constructed in hardware and / or software. In the case of a hardware construction, the interface may, for example, be part of a so-called system ASIC that contains various functions of the data providing device. However, it is also possible that these interfaces are standalone, integrated circuits, or at least partially composed of discrete structural elements. In the case of a software construction, these interfaces may be, for example, software modules coexisting on a microcontroller with other software modules.

[0010] Through the at least one interface, the data providing device can receive vehicle data to be recorded from at least one vehicle system, which may be implemented as an environmental monitoring system, an occupant protection system, a driving power system, or a braking system. Furthermore, the data providing device can be connected to at least one volatile memory via the at least one interface to ensure that the received vehicle data remains available in the at least one volatile memory for a limited time period. Additionally, the data providing device may include further components for preparing and preprocessing the received vehicle data. The event recognition device can receive vehicle data or information from at least one vehicle system via the at least one interface and analyze and process the received vehicle data or information to identify significant and relevant events. Therefore, the data providing device or the event recognition device can, for example, be coupled to a vehicle data bus, enabling the data providing device or the event recognition device to receive vehicle data and information from multiple vehicle systems connected to the vehicle data bus.

[0011] The data recording device can be connected to at least one volatile memory via the at least one interface to read persistently stored data. Furthermore, the data recording device can be connected to at least one non-volatile memory via the at least one interface to store persistently stored data in the at least one non-volatile memory.

[0012] In this document, a buffer block can be understood as a component that establishes the connection between the data providing device, the event recognition device, and the data recording device. Here, the buffer block retains vehicle data provided by the data providing device in at least one volatile memory until this data becomes outdated for the purpose of being "important to the event." In this case, the buffer block releases the storage area in the at least one volatile memory used for now-outdated vehicle data, allowing the data providing device to reuse this storage area to store newer vehicle data. Alternatively, the event recognition device notifies the buffer block that all vehicle data from a specific detection time window of the data recording device should be provided. In this case, the buffer block ensures that all vehicle data within the pre-given current event time window remains available until the data recording device has fully and persistently stored this vehicle data in the at least one non-volatile memory. The following critical case also falls under this category: the data recording device stores vehicle data so slowly that this vehicle data becomes outdated for a newer event during this period. Even then, the buffer block cannot release or overwrite the corresponding storage area in the at least one volatile memory.

[0013] Data providing devices, event recognition devices, and data recording devices can be distributed across multiple components within a vehicle, interconnected via a suitable vehicle network infrastructure. For example, the data providing device can be implemented on multiple "data sources," such as computer units, which can forward vehicle data to other devices within the vehicle. These other devices can perform event recognition and further post-processing steps and may include buffer blocks, while the further post-processing steps and data storage can be implemented on another computer unit. Data providing, event recognition, and data recording can be implemented in separate processes. Furthermore, the device or hardware on which the method for recording event data in the vehicle is implemented can provide multiple CPU cores or processors capable of implementing these processes in practical parallelism. Buffer blocks allow calls to the data recording device, event recognition device, and data providing device to be separated from each other, ensuring that the result in each parallel implementation is always correct. Furthermore, the data providing device can invoke the buffer block in multiple parallel processes. Implementing the data recording device in a single process means that the buffer block does not necessarily separate the individual calls made by the data recording device from each other. The interface method provided by the buffer block is invoked by the interface component and therefore runs in its corresponding process.

[0014] A particular advantage is that the first zero reference time point can correspond to the vehicle's start-up time. The method used to record event data in the vehicle does not necessarily target events that occur before the current start of travel. Therefore, the zero reference time point does not necessarily need to be located before the start of travel.

[0015] In a further advantageous configuration of the method, if the start time of the new current event time window cannot be represented by the current zero reference time point because the start time of the new current event time window is too far in time from the current zero reference time point, the current zero reference time point can be redefined. For most trips, using the start time of the trip as the zero reference time point and adhering to this is probably sufficient. However, it is likely that the trip will last longer than 3.6 hours. In order not to run beyond the start time of the current event time window, the zero reference time point can be redefined. Thus, for example, a new zero reference time point can be defined whenever event identification attempts to define a current event time window that cannot be represented by the current zero reference time point.

[0016] In a further advantageous configuration of the method, the two last used zero-reference time points are stored in a single storage location (Speicherplatz). Here, the starting time of the current event time window can be indicated by a marker: which of the two stored zero-reference time points is used as the reference for the current event time window's start time. Furthermore, when redefining the currently used zero-reference time point, the older of the two stored zero-reference time points can first be overwritten with the new zero-reference time point, and then this new zero-reference time point can be atomically marked as the current zero-reference time point. For this purpose, bit 32 of the current event time window can be set. This bit serves as an array index (i.e., "0" or "1") for the two stored zero-reference time points. In summary, the current event time window can be encoded in 32 bits as follows: Bits 0 to 13 can set the duration or length of the current event time window. Bits 14 to 30 can set the time difference between the start time point and the zero-reference time point. Bit 31 can be used as an index or marker for the zero-reference time point. Furthermore, a new current event time window can then be atomically written based on this new current zero reference time point. This method is safe for concurrent reads as long as no call is made to, or the process still requires, an old, to-be-replaced zero reference time point used before the current zero reference time point. Assuming a resolution of 0.1 seconds and using 17 bits for the start time point, at least 3.6 hours have passed since the previous or old zero reference time point. After such a duration, there are no longer any events requiring the current event time window within that old time window.

[0017] In a further advantageous configuration of the method, at least one partition of a pre-given size can be provided, and the received reference information of each data frame can be written into these partitions in an arbitrary temporal order. Here, a temporally randomly ordered subsequence of the written reference information for each data frame can be obtained and labeled in the at least one partition. For this purpose, the reference information of each data frame can be sequentially numbered in ascending order according to its writing order.

[0018] In a further advantageous configuration of the method, reference information contained in the at least one partition, comprising data frames containing event data to be persistently recorded, can be read and forwarded in response to a request and according to at least one pre-defined read criterion, the at least one pre-defined read criterion including at least one current event time window within which event data should be persistently recorded. The data frames corresponding to the forwarded reference information can be persistently stored in at least one non-volatile memory.

[0019] In a further advantageous configuration of the method, multiple partitions of a pre-given size can be set. Here, one of the partitions is determined as the current write partition according to at least one write criterion, and the received reference information of each data frame is written into the current write partition. In response to a request and according to at least one pre-given read criterion, one of the other partitions can be determined as the current read partition, and the reference information contained in the data frame, which contains event data to be recorded, is read from and forwarded. Here, the current write partition can be marked by a write partition indicator, and the current read partition can be marked by a read partition indicator. By having a single current write partition that can be exclusively accessed by only one function, it is advantageous to avoid other functions being able to access and modify the data content of the current write partition. The same applies to a single read partition that can be exclusively accessed by only one function, so that other functions cannot access the current read partition and cannot modify the data content of the current read partition.

[0020] In a further advantageous configuration of the method, each data frame may involve a time window. Here, the reference information for each data frame may include a corresponding storage area and a corresponding time window with a start timestamp and an end timestamp for each data frame, where at least one data segment containing event data that has been generated or detected within that time window is included in the corresponding data frame. This allows for a simple and quick verification of whether a data frame contains event data or vehicle data whose generation or detection overlaps with the current event time window. Furthermore, the start and end timestamps of each data frame may be based on the current zero reference time point.

[0021] In a further advantageous configuration of the method, a time window can be assigned to each partition. Here, the start timestamp of the time window for a corresponding partition can be the oldest start timestamp of the reference information contained in that partition within the corresponding data frame. The end timestamp of the time window for a corresponding partition can be the latest end timestamp of the reference information contained in that partition within the corresponding data frame. This allows for a simple and quick verification of whether a corresponding partition overlaps with the current event time window.

[0022] In a further advantageous configuration of the method, reference information for at least one data frame whose time window overlaps with the current event time window can be read from the current read partition. Furthermore, the time window of the at least one data frame within the reference information can be invalidated after reading it. This avoids the situation where the reference information of a data frame is read multiple times and the corresponding data frame is persistently stored multiple times in at least one non-volatile memory.

[0023] In a further advantageous configuration of the method, the existing current event time window can be stored locally before determining the current read partition. Here, before each read operation of reference information for at least one data frame, the locally stored current event time window can be compared with this current event time window, and if the current event time window differs from the locally stored one, the stored current event time window can be stored locally. Furthermore, if the locally stored current event time window has changed, it can be checked whether the current read partition's time window overlaps with the new current event time window. If the current read partition overlaps with the changed current event time window, the read operation of the read partition can be restarted. This means rereading the current read partition from the beginning. Here, the reference information that has already been read is not read again, because after reading the reference information, the time window of the corresponding data frame in the reference information has been invalidated. Alternatively, if the current read partition does not overlap with the changed current event time window, a new current read partition can be determined. This means suspending and not restarting the read operation of a current read partition that corresponds to a current event time window that has become outdated during this period. Therefore, at most the reference information of one data frame is forwarded to the data recording device, and the time window of that data frame is now outside the new current event time window. However, this behavior is tolerable, as if the event recognition device only defines the new current event time window after the reference information of the data frame has been read during the reading process.

[0024] In a further advantageous configuration of the method, if the vehicle is restarted or the current write partition is completely written with reference information, a new write partition can be searched according to at least one pre-given write criterion. For this purpose, for example, a group of partitions can be identified that do not have a valid time window. This means that the partitions do not contain reference information for data frames, thus avoiding conflicts between identifying the current write partition and identifying the current read partition. Since the partitions do not contain reference information for data frames, they are not attempted to be used as the current read partition. Therefore, one of the partitions can be identified as the current write partition. Additionally or alternatively, partitions can be identified that have a valid time window that is completely older than the maximum pre-event time point and does not overlap with the existing current event time window. This means that there are no data frames for which future events still require the corresponding partition, and the partition is not currently of significant relevance as a read partition, and has not yet fully read all reference information for data frames overlapping with the current event window, even if these data frames are beyond the maximum pre-event time point. The partition without a valid time window or whose corresponding valid time window has the oldest start timestamp can be identified as the current write partition from the group of partitions. Furthermore, the existing current event time window can be stored locally before determining the current read partition. This allows verification that the current event time window has changed before determining the current read partition. When a new current write partition is determined, the write partition indicator can be reset according to atomic machine instructions.

[0025] In a further advantageous configuration of the method, each time reference information for a new data frame is written, the time window of that new data frame can be compared with the time window of a data frame whose reference information was previously written to the write partition as the last reference information.

[0026] In a further advantageous configuration of the method, for example, the start timestamp of the new data frame can be compared with the start timestamp of the last written data frame. If the start timestamp of the new data frame is newer than the start timestamp of the last written data frame, the current start time subsequence, which is randomly ordered in time, can be identified and the process can continue. Alternatively, if the start timestamp of the new data frame is older than the start timestamp of the last written data frame, a new start time subsequence can begin, and the start timestamp of the new start time subsequence can be marked by storing the corresponding number of the new data frame. Furthermore, the first start time subsequence can begin with the start timestamp of the first written data frame. This means that the smallest number in ascending order simultaneously marks the beginning of the current first start time subsequence, which is randomly ordered in time.

[0027] In a further advantageous configuration of the method, the end timestamp of the new data frame can be compared with the end timestamp of the last written data frame. If the end timestamp of the new data frame is newer than the end timestamp of the last written data frame, the current end timestamp subsequence, which is randomly ordered in time, is identified and continues. Alternatively, if the end timestamp of the new data frame is older than the end timestamp of the last written data frame, a new end timestamp subsequence can begin, and its end timestamp can be marked by storing the corresponding number of the new data frame. Furthermore, the first end timestamp subsequence can begin with the end timestamp of the first written data frame. This means that the smallest ascending number simultaneously marks the beginning of the current first end timestamp subsequence, which is randomly ordered in time.

[0028] In a further advantageous configuration of the method, reference information for at least one data frame to be read from the current read partition can be obtained based on the temporal correlation between at least one temporally randomly ordered start time subsequence and / or at least one temporally randomly ordered end time subsequence of the current read partition and the current event time window. By introducing temporally randomly ordered start time subsequences and temporally randomly ordered end time subsequences, the identification of reference information for data frames to be read can be accelerated because it is not always necessary to examine the reference information of all data frames contained in the current read partition.

[0029] In an advantageous configuration of the device, the buffer block may include a write function and at least one partition of a pre-given size. Here, the write function may be implemented to write received reference information of each data frame into the at least one partition in an arbitrary temporal order, and to mark in the at least one partition a temporally randomly ordered subsequence of the written reference information of each data frame. Furthermore, the buffer block may include a read function, which may be implemented to read out and forward to the data recording device, in response to a request from the data recording device and according to at least one pre-given read criterion, the reference information contained in the at least one partition of the data frame containing event data to be recorded, the at least one pre-given read criterion including at least one current event time window within which event data should be persistently recorded. The data recording device may be implemented to persistently store the data frame corresponding to the forwarded reference information in at least one non-volatile memory.

[0030] In a further advantageous configuration of the device, the buffer block may include multiple partitions of a pre-given size, wherein the write function may be further implemented to determine one of the partitions as the current write partition according to at least one pre-given write criterion, and to write the reference information of each data frame received by the data providing device into the current write partition. The read function may be further implemented to, in response to a request from the data recording device and according to at least one pre-given read criterion, determine one of the other partitions as the current read partition, read from the current read partition, and forward the reference information contained in the data frame to the data recording device.

[0031] In a further advantageous configuration of the device, the event recognition device can be implemented to continuously monitor the state of the vehicle and determine when a pre-given event occurs, the pre-given event requiring the persistent storage of corresponding event data for at least one vehicle system.

[0032] Embodiments of the invention are illustrated in the accompanying drawings and described in more detail in the following description. In these drawings, the same reference numerals denote parts or elements that perform the same or similar functions. Attached Figure Description

[0033] Figure 1 A schematic flowchart illustrating an embodiment of a method for recording event data in a vehicle according to the present invention is shown.

[0034] Figure 2 Showing the use of Figure 1 A schematic illustration of a first embodiment of a method for recording event data in a vehicle according to the present invention.

[0035] Figure 3 Showing the use of Figure 1 A schematic illustration of a second embodiment of a partition in a method for recording event data in a vehicle according to the present invention.

[0036] Figure 4 Showing the use of Figure 1 The illustration shows a first embodiment of the current event time window and several embodiments of the partitioned time window of the method for recording event data in a vehicle according to the present invention.

[0037] Figure 5 Shown in the use of Figure 1 A tabular illustration of the storage area during the current zero reference time point as described in the method for recording event data in a vehicle according to the present invention.

[0038] Figure 6 Showing the use of Figure 1A schematic flowchart of the process for redefining the zero reference time point in the method for recording event data in a vehicle according to the present invention.

[0039] Figure 7 Showing the execution Figure 1 A schematic block diagram of an embodiment of the apparatus according to the invention, which is a method for recording event data in a vehicle according to the invention. Detailed Implementation

[0040] As from Figure 1 As can be seen, in the illustrated embodiment of the method 100 for recording event data in a vehicle according to the invention, vehicle data is continuously received from at least one vehicle system 3 in step S100, and the vehicle data is written as event data into data frames DR of a pre-given size in step S110. In step S120, each data frame DR is stored in at least one volatile memory 50, wherein the stored data frames DR are managed and kept available in the at least one volatile memory 50 until the event data stored in each data frame DR is older than a pre-given maximum event pre-time point or is persistently stored in at least one non-volatile memory 46 in response to a pre-given event. For this purpose, a current event time window EZF is pre-given, within which the event data should be persistently recorded, wherein in step S130, the start time point EZF_1 of the pre-given current event time window EZF is used as the reference for the event data recorded in the vehicle. Figure 5 The timestamp of the current zero reference time point B shown is redefined when needed, and in step S140, the end time point EZF_2 of the current event time window EZF is pre-given as the time difference with the start time point EZF_1.

[0041] In the illustrated embodiment of the method 100 according to the invention, in step S150, a plurality of partitions 21, 21A, and 21B of a predetermined size are set, wherein, in step S160, one of the partitions 21, 21A, and 21B is determined as the current write partition according to at least one write criterion, and in step S170, the received reference information 25 of each data frame DR is written into the current write partition. Furthermore, in step S180, in response to a request and according to at least one predetermined read criterion, one of the other partitions 21, 21A, and 21B is determined as the current read partition, the at least one predetermined read criterion including at least the current event time window EZF, within which the event data should be persistently recorded. In step S190, the reference information 25 of the data frame DR containing the persistently recorded event data contained in the current read partition is read and forwarded, and in step S195, the data frame DR corresponding to the forwarded reference information 25 is persistently stored in at least one non-volatile memory 46.

[0042] In the illustrated embodiment, each data frame DR relates to a time window 27. (As shown from...) Figure 2 and Figure 3 As can be further seen, the reference information 25 of each data frame DR includes a corresponding storage area and a corresponding time window 27. The storage area is preferably indicated by the data frame indicator DRZ. The time window has a start timestamp 28 and an end timestamp 29 of each data frame DR, and at least one data segment containing event data that has been generated or detected in the corresponding data frame DR within the time window.

[0043] As from Figure 2 and Figure 3 As can be further seen, time windows 22 are assigned to each partition 21, 21A, and 21B. The oldest start timestamp 28 of the reference information 25 contained in partition 21 for the corresponding data frame DR is used as the start timestamp 23 of the time window 22 for the corresponding partitions 21, 21A, and 21B. The latest end timestamp 29 of the reference information 25 contained in partition 21 for the corresponding data frame DR is used as the end timestamp 24 of the time window 22 for the corresponding partition 21. (The last sentence appears to be incomplete and possibly refers to a different context.) Figure 2 and Figure 3As can be further seen, the fully written partitions 21A and 21B shown each include reference information for fifteen data frames DR, each relating to a corresponding time window 27. The time windows 22 of partitions 21A and 21B respectively exemplarily have a value "3" for the start timestamp 28 of the first data frame DR, which corresponds to the oldest start timestamp 28 in partitions 21A and 21B. As the end timestamp 24, partitions 21A and 21B respectively exemplarily have a value "37" for the end timestamp 29 of the last data frame DR, which corresponds to the latest end timestamp 29 in partitions 21A and 21B.

[0044] In the illustrated embodiment, a pre-defined... Figure 4 The start time point EZF_1 of the current event time window EZF shown is used as a reference for... Figure 5 The timestamp of the current zero reference time point B is shown. The end time point EZF_2 of the current event time window EZF is pre-given as the time difference with the start time point EZF_1, wherein the current zero reference time point B is redefined as needed. For example, if the start time point EZF_1 of the new current event time window EZF is too far in time from the current zero reference time point B to represent the new current event time window EZF, then the current zero reference time point B is redefined. Furthermore, the start timestamp 28 and end timestamp 29 of each data frame DR, and therefore the start timestamp 23 and end timestamp 24 of each partition 21, 21A, 21B, are also based on the current zero reference time point B.

[0045] The following is for reference Figure 5 and Figure 6 This describes the process 200 used to redefine the current zero reference time point B. (As from...) Figure 5As can be seen, the two last used zero reference time points A and B are stored in storage locations Epoch A and Epoch B, respectively. The current event time window EZF is indicated in the corresponding storage location by a marker M: which of the two stored zero reference time points A and B is used as the reference for the start time point EZF_1 of the current event time window EZF. Typically, the oldest zero reference time point corresponds to the vehicle's start time. In the illustrated embodiment, the current event time window EZF is encoded with 32 bits. Here, bits 0 to 13 represent the duration or length of the current event time window EZF, and bits 14 to 30 represent the time difference between the start time point EZF_1 of the current event time window EZF and the current zero reference time point B. Bit 31 represents a marker for the currently valid zero reference time point B. Therefore, the validity of the zero reference time point A stored in storage location Epoch A can be marked, for example, by a logical value "0", while the validity of the zero reference time point B stored in storage location Epoch B can be marked, for example, by a logical value "1". Figure 5 In the table, the second row shows the current state of the corresponding storage area. This means that an older first zero reference time point A with an exemplary value of 2:00:00:000 is stored in storage location Epoch A, while an updated second zero reference time point B with a value of 8:00:00:000 is stored in storage location Epoch B. The marker M with the indicated value "B" shows that the updated second zero reference time point B stored in storage location Epoch B is equivalent to the current zero reference time point B.

[0046] As from Figure 6 As can be further seen, when redefining the currently used zero reference time point B, in step S200, the older of the two stored zero reference time points A and B is first overwritten with the new zero reference time point C. Figure 5 In the table, the third row shows this state of the corresponding storage area. This means that a new zero reference time point C with an exemplary value of 16:00:00:000 is stored in storage location Epoch A. Furthermore, a second, older zero reference time point B with a value of 8:00:00:000 is stored in storage location Epoch B, where the marker M with the indicated value "B" further shows that the second zero reference time point B stored in storage location Epoch B is equivalent to the current zero reference time point B. Then, in step S210, the new zero reference time point C is marked as the current zero reference time point C in an atomic process. Figure 5In the table, the fourth row shows this state of the corresponding storage area. This means that a new zero reference time point C with an exemplary value of 16:00:00:000 is stored in storage location Epoch A. Furthermore, a second, older zero reference time point B with a value of 8:00:00:000 is stored in storage location Epoch B, where the marker M with the indicated value "A" now shows that the new zero reference time point C stored in storage location Epoch A is now equivalent to the current zero reference time point C. Subsequently, in step S220, a new current event time window EZF based on the new current zero reference time point C is atomically written. Figure 5 In the table, the fifth row shows the state of the corresponding storage area after the current zero reference time point C is redefined.

[0047] The process for determining the current write partition in step S160 of the method 100 for recording event data in a vehicle according to the present invention is described in more detail below. Here, if the vehicle is restarted or the current write partition is completely written with reference information 25, a new write partition is searched according to at least one pre-given write criterion. In the illustrated embodiment, the current event time window EZF, if it exists, is stored locally before determining the current write partition. The process determines a group of partitions 21, 21A, 21B that do not have a valid time window 22 or have a valid time window that is completely older than the largest event pre-time point and does not overlap with the existing current event time window EZF. From these groups of partitions 21, 21A, 21B, partitions 21, 21A, 21B that do not have a valid time window 22 or whose corresponding valid time window 22 has the oldest start timestamp 23 are determined as the current write partitions.

[0048] In the illustrated embodiment of the invention, the received reference information 25 of each data frame DR is written into the current write partition in an arbitrary time order, wherein a temporally randomly ordered subsequence of the written reference information 25 of each data frame DR is obtained and marked in the write partition. For this purpose, each partition 21, 21B includes additional auxiliary information 60, such as from... Figure 3 As can be seen further. With Figure 2 The partition 21A shown is different. Figure 3 The reference information 25 written to each data frame DR of partition 21B shown includes number 62. This means that, for Figure 3 The reference information 25 of each data frame DR of partition 21B shown is numbered sequentially in ascending order according to their writing order.

[0049] Each time reference information 25 of a new data frame DR is written, the time window 27 of the new data frame DR is compared with the time window 27 of a data frame DR whose reference information 25 was previously written as the last reference information to the current write partition. For this purpose, the start timestamp 28 of the new data frame DR is compared with the start timestamp 28 of the last written data frame DR. Here, if the start timestamp 28 of the new data frame DR is newer than the start timestamp 28 of the last written data frame DR, the current start time subsequence 64, which is randomly ordered in time, is identified and continues. Alternatively, if the start timestamp 28 of the new data frame DR is older than the start timestamp 28 of the last written data frame DR, a new start time subsequence 64 begins and the start timestamp 28 of the new start time subsequence is marked by storing the corresponding number 62 of the new data frame DR. The first start time subsequence 64 begins with the start timestamp 28 of the first written data frame DR and the number "0". Furthermore, the end timestamp 29 of the new data frame DR is compared with the end timestamp 29 of the last written data frame DR. Here, if the end timestamp 29 of the new data frame DR is newer than the end timestamp 29 of the last written data frame DR, the current end timestamp subsequence 66, which is randomly ordered in time, is identified and continues. Alternatively, if the end timestamp 29 of the new data frame DR is older than the end timestamp 29 of the last written data frame DR, a new end timestamp subsequence 64 begins and the end timestamp 29 of the new end timestamp subsequence is marked by storing the corresponding number 62 of the new data frame DR. The first end timestamp subsequence 66 begins with the end timestamp of the first written data frame DR.

[0050] As from Figure 3As can be further seen, the exemplary partition 21B includes four start time subsequences 64. Here, the first start time subsequence 64 begins with the smallest number "0" in ascending order number 62. The second start time subsequence 64 begins with the number "3" because the start timestamp 28 of the corresponding data frame DR with the value "5" is older than the start timestamp 28 of the previous data frame DR with the value "7". The third start time subsequence 64 begins with the number "7" in ascending order number 62 because the start timestamp 28 of the corresponding data frame DR with the value "7" is older than the start timestamp 28 of the previous data frame DR with the value "13". The fourth start time subsequence 64 begins with the number "13" in ascending order number 62 because the start timestamp 28 of the corresponding data frame DR with the value "28" is older than the start timestamp 28 of the previous data frame DR with the value "29". Furthermore, the exemplary partition 21B includes five end time subsequences 66. Here, the first end time subsequence 66 begins with the smallest number "0" in ascending order number 62. The second end time subsequence 66 begins with the number "1" because the end timestamp 29 of the corresponding data frame DR with the value "19" is older than the end timestamp 29 of the previous data frame DR with the value "20". The third end time subsequence 66 begins with the number "5" because the end timestamp 29 of the corresponding data frame DR with the value "19" is older than the end timestamp 29 of the previous data frame DR with the value "27". The fourth end time subsequence 66 begins with the number "7" because the end timestamp 29 of the corresponding data frame DR with the value "12" is older than the end timestamp 29 of the previous data frame DR with the value "30". The fifth end time subsequence 66 begins with the number "11" because the end timestamp 29 of the corresponding data frame DR, which has the value "25", is older than the end timestamp 29 of the previous data frame DR, which has the value "28".

[0051] Figure 4Four time windows 22A, 22B, 22C, and 22D of partitions 21, 21A, and 21B are exemplarily shown, which overlap with the current event time window EZF. Since all the shown time windows 22A, 22B, 22C, and 22D overlap with the current event time window EZF, all corresponding partitions 21, 21A, and 21B are suitable to be identified as the current read partition. Because the time windows 22A, 22B, 22C, and 22D of the current read partition overlap with the current event time window EZF, at least one data frame DR of the current read partition also overlaps with the current event time window EZF. Reference information 25 for at least one such data frame DR is read from the current read partition: the time window 27 of the data frame overlaps with the current event time window EZF. Here, after reading the reference information 25, the time window 27 of at least one data frame DR in the reference information 25 is invalidated.

[0052] Before determining the current read partition, the existing current event time window EZF is stored locally. Before each read operation of the reference information 25 for at least one data frame DR, the locally stored current event time window EZF is compared with this current event time window EZF. If the current event time window EZF differs from the locally stored one, the stored current event time window EZF is stored locally. Furthermore, if the locally stored current event time window EZF has changed, it is checked whether the current read partition's time window 22 overlaps with the new current event time window EZF. If the current read partition overlaps with the changed current event time window EZF, the read operation restarts. Alternatively, if the current read partition does not overlap with the changed current event time window EZF, a new current read partition is determined.

[0053] To accelerate the readout process, reference information 25 for at least one data frame DR to be read from the current readout partition is obtained based on the time correlation between at least one temporally randomly ordered start time subsequence 64 and / or at least one temporally randomly ordered end time subsequence 66 of the current read partition and the current event time window EZF.

[0054] As from Figure 4As can be further seen, the start timestamp 23 of the first time window 22 of the corresponding partitions 21, 21A, and 21B is outside the current event time window EZF, and the end timestamp 24 of the first time window 22 of the corresponding partitions 21, 21A, and 21B is within the current event time window EZF. Therefore, partitions 21, 21A, and 21B can contain data frames DR that are too old for the current event time window EZF, but cannot contain data frames DR that are too new for the current event time window EZF. Therefore, in order to obtain the reference information 25 to be read from partitions 21, 21A, and 21B for data frames DR, only the end timestamp 29 of the data frame DR of the time-randomized end time subsequence 66 is compared with the start time point EZF_1 of the current event time window EZF to identify data frames DR that are completely before the current event time window EZF.

[0055] As from Figure 4 As can be further seen, the start timestamp 23 and end timestamp 24 of the second time window 22B of the corresponding partitions 21, 21A, and 21B are located within the current event time window EZF. Therefore, partitions 21, 21A, and 21B do not contain data frame DRs that are too old for the current event time window EZF, nor do they contain data frame DRs that are too new for the current event time window EZF. Thus, the reference information 25 of all data frame DRs in the corresponding partitions 21, 21A, and 21B can be read and forwarded without further verification, and the corresponding data frame DRs can be persistently stored.

[0056] As from Figure 4 As can be further seen, the start timestamp 28 of the third time window 22C of the corresponding partitions 21, 21A, and 21B is within the current event time window EZF, and the end timestamp 29 of the third time window 22C of the corresponding partitions 21, 21A, and 21B is outside the current event time window EZF. Therefore, partitions 21, 21A, and 21B can contain data frames DR that are too new for the current event time window EZF, but cannot contain data frames DR that are too old for the current event time window EZF. Therefore, in order to obtain the reference information 25 to be read from partitions 21, 21A, and 21B for data frames DR, only the start timestamp 28 of the marked, time-randomly ordered start time subsequence 64 is compared with the end time point EZF_2 of the current event time window EZF to identify data frames DR that are completely located after the current event time window EZF.

[0057] As from Figure 4As can be further seen, the start timestamp 28 and end timestamp 29 of the fourth time window 22D of the corresponding partitions 21, 21A, and 21B are all located outside the current event time window EZF. Therefore, partitions 21, 21A, and 21B can contain data frames DR that are too new for the current event time window EZF and data frames DR that are too old for the current event time window EZF. Therefore, in order to obtain the reference information 25 to be read from partitions 21, 21A, and 21B for data frames DR, the start timestamp 28 of the marked, time-randomized start time subsequence 64 is compared with the end time point EZF_2 of the current event time window EZF to identify data frames DR that are completely after the current event time window EZF. In addition, the end timestamp 29 of the marked, time-randomized end time subsequence 66 is compared with the start time point EZF_1 of the current event time window EZF to identify data frames DR that are completely before the current event time window EZF.

[0058] Here, a randomly ordered end time subsequence 66 is first used to find data frames DR that are not entirely before the event time window EZF. To do this, the end timestamp 29 of the last entry of the randomly ordered first end time subsequence 66 is compared with the start time EZF_1 of the current event time window EZF to check if the data frames DR of the randomly ordered first end time subsequence 66 are entirely before the event time window EZF. If so, the process continues with the next randomly ordered end time subsequence 66, and the reference information 25 of the data frames DR of the randomly ordered first end time subsequence 66 is not forwarded. If not, starting from the first entry, the end timestamp 29 of the data frames DR of the randomly ordered first end time subsequence 66 is checked to find data frames DR that are not entirely before the event time window EZF, because earlier entries of the data frames DR of the randomly ordered first end time subsequence 66 can still be entirely older than the current event time window EZF. After obtaining the number of the first data frame DR, the corresponding randomly ordered start time subsequence 64 containing the first data frame DR is taken as the first start time subsequence. To ensure that the data frame DR is not completely after the event time window EZF, starting from the start timestamp 28 of the obtained first data frame DR, the start timestamp 28 of the randomly ordered first start time subsequence 64 is compared with the end time point EZF_2 of the current event time window EZF to find the data frame DR that is completely after the event time window EZF. If a data frame DR that is completely after the current event time window EZF is found, the process continues with the first entry of the next randomly ordered start time subsequence 64. Furthermore, whenever a data frame DR that overlaps with the current event time window EZF is found, it is checked whether the found data frame DR still belongs to the previously checked randomly ordered end time subsequence 66. If this is the case, the reference information 25 of the found data frame DR is forwarded and the time window 27 in the reference information 25 of the data frame DR is deleted from the partition 21. Otherwise, the process continues with the end time subsequence 66 of the randomly ordered data frame DR to which the found data frame belongs.

[0059] The implementation of method 100 according to the present invention can be implemented, for example, in software or hardware or in a hybrid form of software and hardware.

[0060] As from Figure 7As can be seen, the illustrated embodiment of the apparatus 1 according to the invention for performing a method 100 for recording event data in a vehicle includes a data providing device 10, a buffer block 20, an event identification device 30, and a data recording device 40. The data providing device 10 continuously receives vehicle data to be recorded from at least one vehicle system 3, writes the vehicle data as event data into data frames DR of a pre-given size, and stores each data frame DR in at least one volatile memory 50. The buffer block 20 manages the stored data frames DR and keeps the stored data frames available in the at least one volatile memory 50 until the event data stored in each data frame DR is older than a pre-given maximum event time point or is persistently stored in at least one non-volatile memory 46 in response to a pre-given event identified by the event identification device 30. The event identification device 30 pre-given a current event time window EZF within which the event data should be persistently recorded. To this end, the event recognition device 30 pre-defines the start time point EZF_1 of the current event time window EZF as a timestamp based on the current zero reference time point B, and pre-defines the end time point EZF_2 of the current event time window EZF as the time difference with the start time point EZF_1. The buffer block 20 redefines the current zero reference time point B when needed.

[0061] In order to redefine the current zero reference time point B, buffer block 20 executes the procedure 200 described above for redefining the current zero reference time point B.

[0062] In the illustrated embodiment, buffer block 20 includes a write function SF and multiple partitions 21, 21A, 21B of a pre-given size. The write function SF determines one of the partitions 21, 21A, 21B as the current write partition based on at least one write criterion and writes reference information 25 of each data frame DR received by the data providing device 10 into the current write partition. Furthermore, in the illustrated embodiment, buffer block 20 includes a read function LF. The read function LF, in response to a request from the data recording device 40 and based on at least one pre-given read criterion including at least one current event time window EZF, determines one of the other partitions 21 as the current read partition, reads the reference information 25 contained in the data frame DR containing event data to be persistently recorded within the current read partition, and forwards this reference information to the data recording device 40, within which event data should be persistently recorded. The data recording device 40 persistently stores the data frame DR corresponding to the forwarded reference information 25 in the at least one non-volatile memory 46.

[0063] In addition, the write function SF writes the received reference information 25 of each data frame DR into the write partition in an arbitrary time order, and retrieves and marks the time-randomly ordered subsequence of the written reference information 25 of each data frame DR in at least one partition 21.

[0064] The event recognition device 30 continuously monitors the vehicle's status and determines when a pre-defined event occurs, which requires the persistent storage of corresponding event data for at least one vehicle system 3. The event recognition device 30 outputs the current event time window (EZF) corresponding to the recognized event to the buffer block 20, within which event data should be persistently recorded. The start time of the current event time window (EZF) is not temporally preceding the time point preceding the largest event.

[0065] In the illustrated embodiment, the first vehicle system 3 is implemented as an environmental detection system 3A. The second vehicle system 3 is implemented as an occupant protection system 3B, the third vehicle system 3 is implemented as a driving power system 3C, and the fourth vehicle system is implemented as a braking system 3D. Of course, vehicle data from other vehicle systems or other combinations of the aforementioned vehicle systems 3 can also be detected and recorded.

[0066] In the illustrated embodiment, the data providing device 10 includes data detection 12 and data preprocessing, and delivers reference information 25 of data frames DR stored in at least one volatile memory 50 to a buffer block 20. In the illustrated embodiment, as explained above, the reference information 25 of each data frame DR includes a data frame indicator DRZ indicating the storage location of a data block or data frame stored in the volatile memory, and a corresponding time window 27 of the data frame DR with a start timestamp 28 and an end timestamp 29. Upon detection of an event, the buffer block 20 forwards the corresponding reference information 25 of the data frame to be persistently stored in at least one non-volatile memory 46 to the data recording device 40. In the illustrated embodiment, the data recording device 40 includes data post-processing 42, data storage 44, and at least one non-volatile memory 46. Each data frame DR typically contains more than one data segment that has been generated or stored within the time window 27 of the data frame DR. Buffer block 20 only knows the time window 27 of data frame DR and does not know or understand the content of data frame DR. Buffer block 20 receives and forwards data frame DR from data providing device 10 to data recording device 40 with reference. This means that buffer block 20 does not copy the stored content of data frame DR. If event identification device 30 notifies buffer block 20 of the current event time window EZF, buffer block 20 identifies data frame DR based on the current event time window EZF. Then, buffer block 20 accurately provides reference information 25 of data frame DR to data recording device 40 for data recording, the data frame overlapping the current event time window EZF in time. This means that buffer block 20 forwards the complete reference information 25 of data frame DR to data recording device 40, even if data frame DR only partially overlaps the current event time window EZF and therefore some data segments may be outside the current event time window EZF. Buffer block 20 only associates data frame DR with events that have occurred with time overlap with the current event time window EZF. Buffer block 20 does not apply additional criteria to assign data frame DRs to events. Buffer block 20 provides the data recording device 40 with accurate reference information 25 for data frame DRs that overlap with the current event time window EZF. There is no restriction on the order in which buffer block 20 forwards data frame DRs to the data recording device 40. Buffer block 20 processes only one event at a time. Event identification device 30 only notifies buffer block 20 of the current event time window EZF. Buffer block 20 does not require further knowledge of the event's circumstances or details.If event identification device 30 identifies a second event, and buffer block 20 has already processed the current event time window EZF of the first event, event identification 30 may change the current event time window EZF. Furthermore, buffer block 20 has a statically configurable limit, i.e., known at compile time, specifying at most how many time units before the current time point the current event time window EZF can begin. This limit is called the maximum pre-event time point. Event identification device 30 cannot change the start of the current event time window EZF to a time point that is temporally located before this maximum pre-event time point. Furthermore, event identification device 30 cannot specify that its start point is the current event time window EZF that is temporally located before the maximum pre-event time point.

[0067] Therefore, the behavior of buffer block 20 is displayed through the current event time window EZF. If event recognition device 30 recognizes an event for which data must be permanently recorded, it notifies buffer block 20 of the corresponding current event time window EZF, which corresponds to a time range within which the corresponding data frame DR should be persistently stored. The end of the current event time window EZF can be a future point in time. If another event is recognized, the current event time window EZF can change. This could be, for example, a less significant event being recognized first, followed by a more serious event considered associated with the first event. An example might be that a vehicle crosses the center line of the road laterally, i.e., a malfunction in the vehicle's automated steering function, as event A, and subsequently the airbag controller notifies event recognition device 30 of airbag deployment as a consequence of a frontal collision as event B. Event A can be considered independently of being significant for recording vehicle data in the current first event time window EZF, which has a start time of 10 seconds before and an end time of 10 seconds after event A. Event B, which is significantly more serious than event A, can require recording vehicle data in the current second event time window EZF, which has a start time of 30 seconds before and an end time of 30 seconds after event B. Therefore, while vehicle data recording for event A is still in progress, the current event time window EZF used by the event recognition device 30 for recording vehicle data for event B changes.

[0068] In the illustrated embodiment, from the outside, buffer block 20 corresponds to a set of indicators DRZ pointing to data frames DR. Buffer block 20 retains these indicators for a period of time until it either returns them to the storage management of at least one volatile memory 50 or forwards them to a data recording device 40, which reads the data frame DR corresponding to the forwarded indicator DRZ from at least one volatile memory 50 and persistently stores it in at least one non-volatile memory 46. Buffer block 20 can, for example, mark the current write partition in atomic machine instructions using write partition indicators. Internally, the buffer block includes columns of partitions 21, 21A, and 21B. Individual partitions 21, 21A, and 21B correspond to, for example, arrays of data frame indicators DRZ, which are enriched with additional information 26 relating to a time window 27 of the corresponding data frame DR and with auxiliary information 60, which simplifies and accelerates the reading process of reference information 25. The size and number of partitions 21, 21A, and 21B in buffer block 20 can be statically configured, meaning they are known at compile time. Buffer block 20 statically contains the storage areas for partitions 21, 21A, and 21B; that is, buffer block 20 is statically allocated partitions 21, 21A, and 21B at program startup. The size and number of partitions 21, 21A, and 21B can be configured such that the number of Data Frame Indicators (DRZs) is sufficient under all conditions. In addition to partitions 21, 21A, and 21B containing the Data Frame Indicators (DRZs), buffer block 20 also contains a materialized representation of the current event time window (EZF).

[0069] The data providing device 10 inserts the reference information 25 of the corresponding data frame DR into the buffer block 20, while the data recording device 40 reads the reference information 25 of the data frame DR from the buffer block 20 and persistently stores the corresponding data frame DR. Therefore, the data providing device 10 is referred to as a "writer" and the data recording device 40 is referred to as a "reader". The writer and the reader can invoke the methods of the buffer block 20 simultaneously or in parallel from different processes, and the internal state of the buffer block 20 is kept correct in all possible simultaneous or parallel processes.

[0070] Buffer block 20 separates the write process of write function SF from the read process of read function LF by exclusively occupying partitions 21, 21A, and 21B. Buffer block 20 designates one of partitions 21, 21A, and 21B as the current "write partition." Write function SF exclusively occupies this current write partition. Read function LF can neither read from nor modify the current write partition, even if the current write partition contains data frames DR that overlap temporally with the current event time window EZF. When write function SF has completely filled the current write partition with reference information 25, write function SF uses the above-described determination process to search for a new current write partition and make the write partition accessible to read function LF.

[0071] If the write function SF has determined a new current write partition, the write function SF, in accordance with the atomic stored procedure, resets the write partition indicator of buffer block 20. This eliminates the possibility of race conditions that could occur due to the read function LF accessing an outdated cache version of the current write partition, for example, in the CPU cache of another CPU core.

[0072] Similarly, the read function LF is identified as occupying partitions 21, 21A, and 21B of the current read partition. Of course, the current read partition must overlap with the current event time window EZF in time; otherwise, the read function LF would not be interested in the contained data frames DR. Due to the above determination process, the write function SF will never access the current read partition unless there is another means to separate the processes. If the read function LF has read all the reference information 25 of the important and relevant data frames DR from the current read partition, then either the time window 22 of the current read partition is invalid—because all data frames DR contained in the current read partition have been read—or the time window 22 of the current read partition no longer overlaps with the current event time window EZF. The read function LF then searches for other partitions 21, 21A, and 21B that overlap with the current event time window EZF and are not the current write partition. If the read function LF finds partitions 21, 21A, and 21B because the buffer block contains reference information 25 for multiple important related data frames DR relative to the current event, then the read function LF determines that partitions 21, 21A, and 21B are used for the new current read partition. Since the write function SF never accesses the current read partition, there is no requirement to atomically store the read partition indicator. In most calls to buffer block 20, the write function SF simply inserts the reference information 25 about the new data frame DR at the end of the current write partition, thereby potentially extending the time window 22 of the current write partition. Similarly, the read function LF simply reads the reference information 25 about the next data frame DR from the current read partition. In this way, the write function SF and the read function LF never interfere with each other. Simultaneous access to a partition is only possible when the current write partition has been completely written or the current read partition has been completely read. However, this is a write-protected read-only access that compares the time windows 22 of partitions 21, 21A, and 21B. Due to the definition of a new exclusive read partition or a new exclusive write partition, the read process and the write process are separated from each other at any time according to the rules.

[0073] There may be more than one call to the write function SF. To avoid race conditions caused by two calls that want to simultaneously define a new current write partition or overwrite state information within the current write partition, all accesses to buffer block 20 from calls to the write function SF are implemented only when the lock is exclusively held. In the case of only one write function SF, the lock is always available during a single atomic read. Otherwise, a second call must wait until the currently active write function SF has released the lock. Since the actions performed under this lock are very fast, this is a better solution than the opposite, which introduces a separate current write partition for each call to the write function SF. It should be noted that neither the read function LF nor the event identification device 30 needs to acquire the lock every time. This means that if two calls here simultaneously insert the reference information 25 of the new data frame DR into buffer block 20 via the write function SF, the lock only results in a wait period.

[0074] Event identification can be implemented in a separate process within the event identification device 30. The event identification device 30 does not directly interact with the processing of the data frame DR. However, the event identification device 30 can define, change, or invalidate the current event time window stored in the buffer block 20 at any time. The write function SF reads the current event time window EZF when searching for a new write partition. Although simultaneous access to the current event time window by the event identification device 30 and the write function SF is "only" a read conflict / write conflict, the buffer block 20 ensures that the write function SF does not read the current event time window EZF if it is partially written and thus arbitrarily corrupted, while the event identification device 30 modifies the current event time window EZF. If there are more than one call to the write function SF, only one can acquire the described exclusive lock. Therefore, for simultaneous access to the current event time window EZF, only one write function SF may conflict with the event identification device 30 while other calls attempt to acquire the lock. Buffer block 20 resolves the conflict between event identification device 30 and write function SF by storing the current event time window EZF as an atomic value, i.e., within a single machine instruction. Therefore, event identification device 30 writes a new current event time window EZF in a single atomic process. Write function SF either reads the old current event time window EZF or the new current event time window EZF, but never reads a corrupted or partially written current event time window EZF.

[0075] When searching for a new write partition, the write function SF first creates a locally running copy of the current event time window EZF using an atomic read process. The write function SF then works only with this locally running copy until a new write partition is found. In this way, it is possible for the write function SF to search for a new write partition using an outdated current event time window EZF. However, this behavior is the same as if the write function SF first updates the write partition, and the event recognition device 30 subsequently changes the current event time window EZF.

[0076] As described in the case of a read / write conflict between the event identification device 30 and the write function SF, the read function LF also has a read / write conflict with the event identification device 30 regarding the current event time window EZF of the access buffer block 20. The read function LF must know the current event time window EZF in order to find partitions 21, 21A, and 21B that contain data frames DR overlapping with the current event time window EZF, and know that partitions 21, 21A, and 21B are not completely contained within the current event time window EZF, in order to identify or determine the important and relevant data frames DR within those partitions. Of course, the read function LF does not read partially written, corrupted portions of the current event time window EZF, while the event identification device 30 simultaneously modifies the current event time window EZF.

[0077] As explained above, the event identification device 30 atomically updates the current event time window EZF. Similarly, the read function LF atomically reads the current event time window EZF and stores it in a locally running copy at the start of each method call in buffer block 20. During the read process, the read function LF uses this copy of the current event time window EZF wherever it is needed.

[0078] It is possible that the current event time window EZF stored in buffer block 20 is different from the locally running copy of the read function LF. The read function LF ends the current read process with the current event time window EZF that is outdated during this period, and therefore forwards the reference information 25 of the data frame DR whose time window 22 is outside the current event time window EZF to the data recording device 40 at most. However, this behavior is as if the event identification device 30 only specifies the new current event time window EZF after the read function LF has processed the data frame DR, and is therefore tolerable.

[0079] At the start of each call to buffer block 20, the read function LF not only creates a locally running copy of the current event time window EZF, but also checks whether the current event time window EZF has changed since the previous call. If the current event time window EZF has changed, the read function LF first checks whether the current read partition still overlaps with the new current event time window. If this is not the case, the read function LF searches for the new current read partition, as described above. If the current read partition always overlaps with the new current event time window EZF, the read function LF restarts the read process and begins rereading the current read partition from the beginning.

Claims

1. A method (100) for recording event data in a vehicle, wherein, Vehicle data is continuously received from at least one vehicle system (3) and written as event data into data frames (DRs) of a pre-given size, wherein each data frame (DR) is stored in at least one volatile memory (50), wherein the stored data frames (DRs) are managed and kept available in the at least one volatile memory (50) until the event data stored in each data frame (DR) is older than a pre-given maximum event time point or persisted in response to a pre-given event. The event data is stored in at least one non-volatile memory (46), wherein a current event time window (EZF) is pre-defined, within which the event data should be persistently recorded, wherein the start time point (EZF_1) of the current event time window (EZF) is pre-defined as a timestamp based on the current zero reference time point, which is redefined as needed, and the end time point (EZF_2) of the current event time window (EZF) is pre-defined as the time difference from the start time point (EZF_1). In this process, at least one partition (21) of a pre-given size is set up, and the received reference information (25) of each data frame (DR) is written into the partition in an arbitrary time order, wherein a time-randomly ordered subsequence of the written reference information (25) of each data frame (DR) is obtained and marked in the at least one partition (21).

2. The method (100) according to claim 1, characterized in that, The oldest zero reference time point is equivalent to the vehicle's start-up time point.

3. The method (100) according to claim 1 or 2, characterized in that, If the start time (EZF_1) of the new current event time window (EZF) is too far from the current zero reference time point in time to represent the new current event time window (EZF), then the current zero reference time point is redefined.

4. The method (100) according to any one of claims 1 to 2, characterized in that, The two last used zero reference time points are stored in a storage location (Epoch A, Epoch B), wherein the start time point (EZF_1) of the current event time window (EZF) is indicated by a marker (M) to show which of the two stored zero reference time points is used as the reference.

5. The method (100) according to claim 4, characterized in that, When redefining the currently used zero reference time point, the older of the two stored zero reference time points is first overwritten with the new zero reference time point, and then the new zero reference time point is marked as the current zero reference time point in an atomic process.

6. The method (100) according to claim 5, characterized in that, Then, a new current event time window (EZF) is atomically written based on the new zero reference time point.

7. The method (100) according to claim 1 or 2, characterized in that, The reference information (25) written to each data frame (DR) is sequentially numbered in ascending order according to the order in which it was written.

8. The method (100) according to claim 7, characterized in that, In response to a request and according to at least one pre-given reading criterion, reference information (25) contained in the at least one partition (21) is read out and forwarded, which includes a data frame (DR) containing event data to be persistently recorded. The at least one pre-given reading criterion includes at least the current event time window (EZF) within which the event data should be persistently recorded, and wherein the data frame (DR) corresponding to the forwarded reference information (25) is persistently stored in the at least one non-volatile memory (46).

9. The method (100) according to claim 8, characterized in that, Multiple partitions (21) of a pre-given size are set up, wherein one of the partitions (21) is determined as the current write partition according to at least one write criterion, and the received reference information (25) of each data frame (DR) is written into the current write partition, and wherein, in response to a request and according to the at least one pre-given read criterion, one of the other partitions (21) is determined as the current read partition, and the reference information (25) contained in the data frame (DR) is read from and forwarded, the data frame containing event data to be recorded.

10. The method (100) according to claim 1 or 2, characterized in that, Each data frame (DR) involves a time window (27), wherein the reference information (25) of each data frame (DR) includes a corresponding storage area and a corresponding time window (27) with a start timestamp (28) and an end timestamp (29) of each data frame (DR), wherein at least one data segment containing the corresponding data frame (DR) has been generated or detected in the time window, wherein the start timestamp (28) and end timestamp (29) of each data frame (DR) are based on the current zero reference time.

11. The method (100) according to claim 10, characterized in that, Each partition (21) is assigned a time window (22), wherein the start timestamp (23) of the time window (22) of the corresponding partition (21) is the oldest start timestamp (28) of the reference information (25) contained in the partition (21) of the corresponding data frame (DR), and the end timestamp (24) of the time window (22) of the corresponding partition (21) is the latest end timestamp (29) of the reference information (25) contained in the partition (21) of the corresponding data frame (DR).

12. The method (100) according to claim 11, characterized in that, Reference information (25) of at least one data frame (DR) is read from the current read partition: the time window (27) of the data frame overlaps with the current event time window (EZF), wherein, after reading the reference information (25), the time window (27) of the at least one data frame (DR) in the corresponding reference information (25) is invalidated.

13. The method (100) according to claim 12, characterized in that, Before determining the current read partition, the existing current event time window (EZF) is stored locally, wherein, before each readout process of reference information (25) of at least one data frame (DR), the locally stored event time window (EZF) is compared with the current event time window (EZF), and if the current event time window is different from the locally stored event time window (EZF), the current event time window (EZF) is stored locally, wherein, if the locally stored event time window (EZF) has changed, it is checked whether the time window (22) of the current read partition overlaps with the changed event time window (EZF), and wherein, if the time window of the current read partition overlaps with the changed event time window (EZF), the readout process of the read partition is restarted, or if the time window of the current read partition does not overlap with the changed event time window (EZF), a new current read partition is determined.

14. The method (100) according to claim 9, characterized in that, If the vehicle is restarted or the current write partition is completely written with reference information, a new write partition is searched according to at least one pre-given write criterion.

15. The method (100) according to claim 14, characterized in that, Determine a group of partitions (21) that do not have a valid time window (22) or have a valid time window (22) that is completely older than the largest event time point and does not overlap with the existing current event time window (EZF), wherein the partition (21) that does not have a valid time window (22) or the partition (21) whose corresponding valid time window (22) has the oldest start timestamp (23) is determined from the group of partitions (21) as the current write partition.

16. The method (100) according to any one of claims 11 to 15, characterized in that, Each time a new data frame (DR) reference information (25) is written, the time window (27) of the new data frame (DR) is compared with the time window (27) of the data frame (DR) whose reference information (25) was previously written as the last reference information in the at least one partition.

17. The method (100) according to claim 16, characterized in that, The start timestamp (28) of the new data frame (DR) is compared with the start timestamp (28) of the last written data frame (DR). If the start timestamp (28) of the new data frame (DR) is newer than the start timestamp (28) of the last written data frame (DR), the current start time subsequence (64) is identified and proceeds in a time-random order. Alternatively, if the start timestamp (28) of the new data frame (DR) is older than the start timestamp (28) of the last written data frame (DR), a new start time subsequence (64) is started and the start timestamp (28) of the new start time subsequence is marked by storing the corresponding number (62) of the new data frame (DR). The first start time subsequence (64) begins with the start timestamp (28) of the first written data frame (DR).

18. The method (100) according to claim 17, characterized in that, The end timestamp (29) of the new data frame (DR) is compared with the end timestamp (29) of the last written data frame (DR). If the end timestamp (29) of the new data frame (DR) is newer than the end timestamp (29) of the last written data frame (DR), the current end timestamp subsequence (66) is identified and continues in a time-randomized order. If the end timestamp (29) of the new data frame (DR) is older than the end timestamp (29) of the last written data frame (DR), a new end timestamp subsequence (66) is started and the end timestamp (29) of the new end timestamp is marked by storing the corresponding number (62) of the new data frame (DR). The first end timestamp subsequence (66) begins with the end timestamp (29) of the first written data frame (DR).

19. The method (100) according to claim 18, characterized in that, Based on the temporal correlation between at least one temporally randomly ordered start time subsequence (64) and / or at least one temporally randomly ordered end time subsequence (66) of the current read partition and the current event time window (EZF), obtain reference information (25) for at least one data frame (DR) to be read from the current read partition.

20. An apparatus (1) for performing a method for recording event data in a vehicle according to any one of claims 1 to 19, the apparatus comprising a data providing device (10), a buffer block (20), an event recognition device (30), and a data recording device (40), wherein, The data providing device (10) is configured to continuously receive vehicle data to be recorded from at least one vehicle system (3), write the vehicle data as event data into data frames (DRs) of a pre-given size, and store each data frame (DR) in at least one volatile memory (50), wherein the buffer block (20) is configured to manage the stored data frames (DRs) and keep the stored data frames available in the at least one volatile memory (50) until the event data stored in each data frame (DR) is older than a pre-given maximum event time point or is persistently stored in at least one non-volatile memory (46) in response to a pre-given event identified by the event identification device (30), wherein the event identification device (30) is configured to pre-given a current event time window (EZF) within which the event data should be persistently recorded. The event recognition device (30) is further configured to pre-define the start time (EZF_1) of the current event time window (EZF) as a timestamp based on the current zero reference time, and pre-define the end time (EZF_2) of the current event time window (EZF) as the time difference with the start time (EZF_1). The buffer block (20) is configured to redefine the current zero reference time when needed. The buffer block (20) includes a write function (SF) and at least one partition (21) of a pre-defined size. The write function (SF) is configured to write the received reference information (25) of each data frame (DR) into the at least one partition (21) in an arbitrary time order, and mark the subsequence of the written reference information (25) of each data frame (DR) in the at least one partition (21) in a time-randomized order.

21. The device (1) according to claim 20, characterized in that, The buffer block (20) includes a read function (LF) configured to, in response to a request from the data recording device (40) and according to at least one pre-defined read criterion, read out and forward to the data recording device (40) reference information (25) contained in the at least one partition (21) of a data frame (DR) containing event data to be recorded, the at least one pre-defined read criterion including at least one current event time window (EZF) within which the event data should be recorded, and wherein the data recording device (40) is configured to persistently store the data frame (DR) corresponding to the forwarded reference information (25) in the at least one non-volatile memory (46).

22. The device (1) according to claim 21, characterized in that, The buffer block (20) includes a plurality of partitions (21) of a pre-given size, wherein the write function (SF) is further implemented to determine one of the partitions (21) as the current write partition according to the at least one pre-given write criterion, and to write the reference information (25) of the respective data frames (DR) received by the data providing device (10) into the write partition, and wherein the read function (LF) is further implemented to, in response to a request from the data recording device (40) and according to the at least one pre-given read criterion, determine one of the other partitions (21) as the current read partition, read from the read partition and forward the reference information (25) contained in the data frames (DR) to the data recording device (40).

23. The device (1) according to any one of claims 20 to 22, characterized in that, The event recognition device (30) is configured to continuously monitor the state of the vehicle and determine when a pre-given event occurs, the pre-given event requiring the persistent storage of corresponding event data of the at least one vehicle system (3).

24. The device (1) according to any one of claims 20 to 22, characterized in that, The data providing device (10) and / or the buffer block (20) and / or the event recognition device (30) and / or the data recording device (40) are distributed on multiple devices in the vehicle, which communicate with each other via a vehicle network structure.

25. A computer program product configured to implement a method for recording event data in a vehicle according to any one of claims 1 to 19.

26. A computer-readable storage medium on which a computer program product according to claim 25 is stored.

Images