A management method and system of vehicle safety log and related device

Abstract

The application discloses a kind of vehicle-mounted safety log management method, system and related device, it is related to data management field, comprising: according to the priority order of safety event, sequentially each safety event is executed write operation, the log fragment of one split and not completed writing of current safety log in buffer area is determined as current log fragment, write target storage area, and in the case where writing is completed and there is real-time task of priority higher than the safety event corresponding to current safety log, execute real-time task, and after the safety log storage of executed real-time task, continue to execute the step of determining one split and not completed writing of log fragment as current log fragment.The application based on the sequential write operation of priority order, ensure that high priority safety event is written first, while allowing to intersperse and execute real-time task after current log fragment storage, avoid the risk of task execution lag, improve log storage reliability.

Description

Technical Field

[0001] This application relates to the field of data management technology, and in particular to a method, system and related device for managing vehicle safety logs. Background Technology

[0002] In the development of automotive electronic control units (ECUs), the onboard safety log management function is a core requirement for ECUs to comply with functional safety standards (ISO 26262). The onboard safety log management function is used to automatically record, store, protect, and manage event data related to vehicle safety within the vehicle environment. Existing onboard safety log management solutions typically store and overwrite safety logs sequentially according to the order of their generation after generating the corresponding safety event's safety log.

[0003] However, under the resource constraints and functional safety standards of the automotive embedded environment, there are risks of task processing lag and decreased log storage reliability. Therefore, how to improve log storage reliability while avoiding the risk of task processing lag has become an urgent problem to be solved. Summary of the Invention

[0004] In view of the above problems, this application provides a method, system, and related device for managing vehicle safety logs, so as to improve the reliability of high-priority log storage while avoiding the risk of task processing delays. The specific solution is as follows:

[0005] The first aspect of this application provides a method for managing vehicle safety logs, including:

[0006] Upon detecting at least one security event, write operations are performed on each security event sequentially according to their priority from highest to lowest. The write operations include:

[0007] Obtain the current security log generated based on security event data, and store the current security log in the cache area;

[0008] The current security log in the cache is split into multiple log fragments, and the data volume of each log fragment is not greater than a preset single write data volume threshold.

[0009] A log fragment that has been split but not yet written is identified as the current log fragment. The current log fragment is written to the target storage area. After the writing is completed, it is monitored whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If there is, the real-time task is executed. After the security log of the executed real-time task is stored in the target storage area, the step of identifying the log fragment that has been split but not yet written as the current log fragment continues.

[0010] In one possible implementation, the method for managing the vehicle safety log further includes:

[0011] Upon receiving a security log read instruction, obtain the identifier of the security log to be read in the security log read instruction;

[0012] Extract the security log to be read corresponding to the identifier from the permanent storage medium, call the preset decryption script to decrypt the security log to be read, and send the obtained plaintext security log to the host computer;

[0013] When the host computer receives the plaintext security log, it performs a first erasure operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read.

[0014] In one possible implementation, the first erasure operation is a physical erasure operation or an asynchronous erasure operation. The step of performing the first erasure operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read includes:

[0015] If the amount of data in the security log to be read is less than the preset storage area capacity threshold, the physical erasure operation is performed on the security log to be read in the permanent storage medium.

[0016] If the amount of data in the security log to be read is not less than the preset storage area capacity threshold, the asynchronous erasure operation is performed on the security log to be read in the permanent storage medium. The asynchronous erasure operation is based on the task load state and performs the logical erasure operation and the physical erasure operation asynchronously.

[0017] In one possible implementation, obtaining the current security log generated based on security event data includes:

[0018] By using the peripheral side's preset call interface, the data of the security event is packaged according to the preset packetization rules to obtain the current security log, and the current security log is encrypted by calling the preset encryption algorithm.

[0019] In one possible implementation, storing the current security log in a cache includes:

[0020] Identify a preset overwrite policy. If the preset overwrite policy indicates that overwrite is allowed, overwrite the current security log in the target cache area with the earliest occupied state timestamp in the cache area, update the occupied state timestamp of the target cache area, and add a data overflow flag to the target cache area. The data overflow flag indicates the data information of the target cache area before it is overwritten.

[0021] If the preset overwrite policy indicates that overwriting is prohibited, the current security log is discarded.

[0022] In one possible implementation, the step of performing write operations on each of the security events sequentially according to their priority from high to low includes:

[0023] The priority label of the security event is identified, and the security event is imported into the processing queue corresponding to the priority label. The processing queue includes a high-priority processing queue, a medium-priority processing queue, and a low-priority processing queue arranged from high to low priority.

[0024] When a security event is imported into the high-priority processing queue, the write operation is performed on the security events in the high-priority processing queue in the order of import.

[0025] When the security event is imported into the medium-priority processing queue and there is no security event in the high-priority processing queue, the write operation is performed on the security events in the medium-priority processing queue in the order of import after a first preset time delay.

[0026] If the security event is imported into the low-priority processing queue, and there is no security event in either the high-priority processing queue or the medium-priority processing queue within a second preset time period, the write operation is performed on the security events in the low-priority processing queue in the order of import.

[0027] One possible implementation also includes:

[0028] If the security event always exists in the high-priority processing queue or the medium-priority processing queue within the second preset time period, the security event in the low-priority processing queue is discarded.

[0029] A second aspect of this application provides a vehicle safety log management system, comprising:

[0030] A writing unit is configured to, upon detecting at least one security event, sequentially perform a write operation on each of the security events in descending order of priority. The write operation includes:

[0031] Obtain the current security log generated based on security event data, and store the current security log in the cache area;

[0032] The current security log in the cache is split into multiple log fragments, and the data volume of each log fragment is not greater than a preset single write data volume threshold.

[0033] A log fragment that has been split but not yet written is identified as the current log fragment. The current log fragment is written to the target storage area. After the writing is completed, it is monitored whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If there is, the real-time task is executed. After the security log of the executed real-time task is stored in the target storage area, the step of identifying the log fragment that has been split but not yet written as the current log fragment continues.

[0034] In one possible implementation, the vehicle safety log management system further includes:

[0035] The reading unit is configured to, upon receiving a security log reading instruction, obtain the identifier of the security log to be read in the security log reading instruction; extract the security log to be read corresponding to the identifier from the permanent storage medium, call a preset decryption script to decrypt the security log to be read, and send the obtained plaintext security log to the host computer; and, upon receiving the plaintext security log, perform a first erasure operation on the security log to be read in the permanent storage medium based on the data volume of the security log to be read.

[0036] In one possible implementation, the reading unit is configured to perform a first erase operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read:

[0037] If the amount of data in the security log to be read is less than a preset storage area capacity threshold, a physical erasure operation is performed on the security log to be read in the permanent storage medium. The first erasure operation is either the physical erasure operation or an asynchronous erasure operation.

[0038] If the amount of data in the security log to be read is not less than the preset storage area capacity threshold, the asynchronous erasure operation is performed on the security log to be read in the permanent storage medium. The asynchronous erasure operation is based on the task load state and performs the logical erasure operation and the physical erasure operation asynchronously.

[0039] In one possible implementation, the writing unit is configured to, upon obtaining the current security log generated based on security event data, as follows:

[0040] By using the peripheral side's preset call interface, the data of the security event is packaged according to the preset packetization rules to obtain the current security log, and the current security log is encrypted by calling the preset encryption algorithm.

[0041] In one possible implementation, the writing unit is configured to store the current security log to the cache as follows:

[0042] Identify a preset overwrite policy. If the preset overwrite policy indicates that overwrite is allowed, overwrite the current security log in the target cache area with the earliest occupied state timestamp in the cache area, update the occupied state timestamp of the target cache area, and add a data overflow flag to the target cache area. The data overflow flag indicates the data information of the target cache area before it is overwritten. If the preset overwrite policy indicates that overwrite is prohibited, discard the current security log.

[0043] In one possible implementation, the writing unit is configured to perform write operations on each security event sequentially according to its priority from high to low as follows:

[0044] The priority label of the security event is identified, and the security event is imported into the processing queue corresponding to the priority label. The processing queue includes a high-priority processing queue, a medium-priority processing queue, and a low-priority processing queue arranged from high to low priority.

[0045] When a security event is imported into the high-priority processing queue, the write operation is performed on the security events in the high-priority processing queue in the order of import.

[0046] When the security event is imported into the medium-priority processing queue and there is no security event in the high-priority processing queue, the write operation is performed on the security events in the medium-priority processing queue in the order of import after a first preset time delay.

[0047] If the security event is imported into the low-priority processing queue, and there is no security event in either the high-priority processing queue or the medium-priority processing queue within a second preset time period, the write operation is performed on the security events in the low-priority processing queue in the order of import.

[0048] In one possible implementation, the writing unit is further configured as follows:

[0049] If the security event always exists in the high-priority processing queue or the medium-priority processing queue within the second preset time period, the security event in the low-priority processing queue is discarded.

[0050] A third aspect of this application provides an electronic control unit, comprising at least one processor and a memory connected to the processor, wherein:

[0051] The memory is used to store computer programs;

[0052] The processor is used to execute the computer program so that the electronic control unit can implement the vehicle safety log management method of the first aspect or any implementation thereof.

[0053] A fourth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic control unit, enable the electronic control unit to implement the vehicle safety log management method described in the first aspect or any implementation thereof.

[0054] By employing the above technical solution, this application provides a method, system, and related apparatus for managing vehicle safety logs. By configuring the system to sequentially write to each safety event in descending order of priority when at least one safety event is detected, high-priority safety events are written first, improving the reliability of high-priority log storage. Subsequently, the system obtains the current safety log generated based on the safety event data and stores it in a cache, thus achieving temporary storage of the current safety log. Furthermore, by splitting the current security log in the cache into multiple log fragments and configuring the data volume of each log fragment to not exceed a preset single write data volume threshold, the write time of a single log fragment is shortened. During the process of writing each log fragment to the target storage area, the first fragment split and not yet written is identified as the current log fragment and written to the target storage area. After writing is complete, it is monitored whether there are real-time tasks with a higher priority than the security event corresponding to the current security log. If so, the real-time task is executed. This splits the continuous write operation of a complete security log into multiple independent write operations. After completing the write of a log fragment, it is configured to allow the interleaving execution of real-time tasks with a higher priority than the security event that generated the current security log, further avoiding the risk of task processing delays. Finally, by configuring the step of identifying a split but not yet written log fragment as the current log fragment after storing the security log of the completed real-time task to the target storage area, it is ensured that the current security log, even if storage is interrupted, can be stored completely, improving log storage reliability. As can be seen, this application ensures the reliability of log storage while avoiding the risk of task processing delays. Attached Figure Description

[0055] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0056] Figure 1 A flowchart illustrating a method for managing vehicle safety logs provided in this application;

[0057] Figure 2 This application provides a flowchart of a current security log writing process;

[0058] Figure 3 A flowchart of a first erasure operation is provided for this application;

[0059] Figure 4 A schematic diagram illustrating the operational mechanism of a vehicle safety log management method provided in this application;

[0060] Figure 5 This application provides a flowchart of a current security log caching process;

[0061] Figure 6 A flowchart for writing security event sorting provided in this application. Detailed Implementation

[0062] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0063] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0064] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0065] It should be noted that, in practical application scenarios, compared with existing technologies, this application, while ensuring log storage reliability, avoids the risk of task processing lag. Specifically: Due to the limited hardware storage resources of the ECU, storing and overwriting each safety log sequentially will cause task scheduling blocking. For example, when low-priority safety logs are being executed, the storage of high-priority safety logs must wait for the low-priority safety logs to be stored before execution, thus causing task processing lag. Furthermore, since existing vehicle safety log management solutions store and overwrite safety logs according to the order in which they are generated, a sudden power outage during storage can easily lead to the loss of high-priority safety logs that have not yet been stored, reducing log storage reliability. This application, however, performs write operations on each safety event sequentially according to its priority from high to low, achieving priority writing of high-priority safety events and improving the storage reliability of high-priority logs. Subsequently, the current safety log generated based on the data of the safety events is obtained through configuration and stored in the cache, thereby achieving temporary storage of the current safety log and avoiding the risk of safety log loss due to sudden power outages. Furthermore, by splitting the current security log in the cache into multiple log fragments, each with a data size not exceeding a preset single write data size threshold, the write time for a single log fragment is shortened, further mitigating the risk of data loss due to sudden power outages and incomplete fragment writing. Simultaneously, by configuring real-time tasks with higher priority than the security event corresponding to the current security log to be executed first after writing is complete, the risk of task processing lag is further avoided. Finally, by configuring the process of storing the security log of the completed real-time task to the target storage area and then continuing to execute the step of determining a split but incompletely written log fragment as the current log fragment, the system ensures that the current security log, even with interrupted storage, can be stored completely, improving log storage reliability. Therefore, this application ensures log storage reliability while avoiding the risk of task processing lag.

[0066] The first aspect of this application provides a method for managing vehicle safety logs, the flowchart of which is shown below. Figure 1 As shown, the method for managing the vehicle safety log includes:

[0067] S101. Upon detecting at least one security event, write operations are performed on each security event sequentially according to their priority from high to low. The write operations include:

[0068] S102. Obtain the current security log generated based on the security event data, and store the current security log in the cache area;

[0069] S103. Split the current security log in the cache into multiple log fragments, and the data volume of each log fragment is not greater than the preset single write data volume threshold.

[0070] S104. Identify a log fragment that has been split but not yet written as the current log fragment, write the current log fragment to the target storage area, and after writing is completed, monitor whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If there is, execute the real-time task, and after storing the security log of the executed real-time task to the target storage area, continue to execute the step of identifying a log fragment that has been split but not yet written as the current log fragment.

[0071] It should be noted that, in practical application scenarios, the vehicle safety log management method provided in the first aspect of this application can be applied to existing automotive open system architecture (AUTOSAR CP), portable software architecture (PSA), or automotive integrated computing environment scalable platform (SPICE), boot loader, etc. This application does not impose excessive limitations or elaborate on the specific architecture type for this solution.

[0072] It should be noted that in practical application scenarios, the aforementioned monitoring of security events can be achieved by calling the data receiving interface of the architecture. For example, assuming that the architecture integrating the vehicle safety log management method provided in the first aspect of this application is the Basic Software (BSW) layer in the AUTOSAR architecture, the aforementioned monitoring of security events can be achieved by calling the AUTOSAR Run-Time Environment (RTE) interface to obtain the data and priorities of each security event from the Diagnostic Event Manager (DEM). The Diagnostic Event Manager is the core functional architecture of the AUTOSAR CP architecture for vehicle event diagnosis, priority determination, and reporting. The original priorities of security events in the DEM are obtained through the RTE interface and converted into predefined storage weight values ​​(i.e., priorities in this solution). The storage order of the Non-Volatile Memory Manager (NVM) operation requests (i.e., the order of the aforementioned security events from high to low priorities) is determined according to the storage weights, which not only complies with the AUTOSAR layered specification but also establishes a priority transmission chain from the DEM to the NVM.

[0073] It should be noted that, in practical applications, the aforementioned safety event refers to a specific state, malfunction, or emergency that may lead to abnormal vehicle function, increased driving risk, personal injury, or property damage during vehicle operation. These events can be collected by various types of vehicle sensors and identified by the built-in program of the electronic control unit. For example, air conditioning system malfunctions, compressor malfunctions, lighting malfunctions, braking system malfunctions, and powertrain malfunctions all fall under this category.

[0074] It should be noted that, in practical applications, the priority of the aforementioned safety events can be set based on the degree of impact of the safety event on vehicle driving safety. For example, an air conditioning system malfunction does not directly endanger driving safety, while a braking system malfunction directly and seriously endangers driving safety. Therefore, the priority of a safety event related to an air conditioning system malfunction can be set lower than that of a safety event related to a braking system malfunction.

[0075] It should be noted that in practical applications, existing vehicle safety log management functions write logs sequentially based on the order in which safety logs are generated. Furthermore, each write operation continues continuously within the main function and cannot be terminated. This means that writing high-priority safety logs requires waiting for lower-priority logs to be written before execution. Additionally, since safety logs are dynamically generated, they need to be stored in a cache for temporary storage. This results in a high risk of data loss in the cache during sudden power outages, reducing the reliability of high-priority log storage. Therefore, this application configures the system to execute write operations sequentially on each safety event according to its priority, from highest to lowest, upon detecting at least one safety event. This prioritizes high-priority safety events, improving both the processing priority of high-priority log write tasks and the reliability of log storage.

[0076] It should be noted that in practical applications, the aforementioned buffer (also known as a circular buffer) is a data structure based on the first-in, first-out (FIFO) rule of contiguous memory space, achieving efficient data access through the circular movement of read and write pointers. Due to resource constraints in existing automotive embedded environments, the available storage space of the vehicle's permanent storage medium is relatively limited, and the write and read processes are slow. Since security logs are dynamically generated, it cannot be guaranteed that there will still be sufficient available storage space in the permanent storage medium when security logs need to be stored. Therefore, this application obtains the current security log generated based on security event data through configuration and stores the current security log in the buffer, thereby achieving temporary caching of the current security log and avoiding the risk of security log loss due to sudden power outages.

[0077] In one possible implementation, since the permanent storage medium stores a large amount of vehicle driving parameters and safety log data, if the storage space in the target storage area of ​​the permanent storage medium is already occupied, the current security log will fail to be written to the target storage area, leading to storage failure. Therefore, before splitting the current security log into multiple log fragments, a second erase operation can be configured to be performed on the target storage area if the amount of current security log data in the cache exceeds the remaining storage capacity of the target storage area in the permanent storage medium. This ensures sufficient storage space is available for the current security log to be written, improving the success rate of the write operation and thus enhancing the storage reliability of the security log.

[0078] In one possible implementation, the second erasure operation described above can be based on the amount of data in the current security log to erase the target storage area so that the remaining storage capacity of the target storage area after erasure is not less than the amount of data in the current security log, or it can be based on the difference between the amount of data in the current security log and the remaining storage capacity of the target storage area to erase the target storage area so that the remaining storage capacity of the target storage area after erasure is equal to the difference.

[0079] Furthermore, the second erasure operation described above can also be performed by erasing the target storage area multiple times according to a preset byte deletion length, so that the remaining storage capacity of the target storage area after all erasures are completed is not less than the amount of data in the current security log.

[0080] Those skilled in the art will understand that, in practical application scenarios, the above-mentioned splitting of the current security log into multiple log fragments can be achieved by calling a fragmentation algorithm. There are various types of fragmentation algorithms, including but not limited to: fixed-size fragmentation, record-boundary fragmentation, and NVM block-aligned fragmentation. This application does not impose too many limitations or elaborate on the specific types of the above-mentioned fragmentation algorithms and the fragmentation process.

[0081] It's important to note that in real-world applications, a complete security log writing process typically takes milliseconds, which is a relatively long time in the main loop of an automotive embedded environment. The aforementioned real-time tasks refer to processing tasks with higher priority than the security event corresponding to the current security log and requiring immediate response, such as high-priority security log writing tasks and emergency diagnostic tasks. When this security log writing task is executed in the main loop, since the main loop only processes one task per iteration, it means that the main loop needs several milliseconds to execute this task before it can execute other tasks, thus causing blocking and resulting in task processing delays. Therefore, this application configures a split log fragment that has not yet been written to be designated as the current log fragment, writes the current log fragment to the target storage area, and after the writing is completed, monitors whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If so, the real-time task is executed, and after the real-time task is completed, the step of designating a split log fragment that has not yet been written to be designated as the current log fragment continues. This splits a security log writing task that takes several milliseconds into multiple writing tasks that take less than one millisecond, and allows the execution of other tasks with a higher priority than the corresponding priority of the current security log between two adjacent tasks. This shortens the single write time, improves the reliability of log storage, and avoids the risk of task processing lag.

[0082] It should be noted that, in the absence of a real-time task with a higher priority than the current security event in the current security log, the step of determining a split and incompletely written log fragment as the current log fragment can be configured to continue execution, so as to achieve reliable storage of each log fragment of the current security log.

[0083] It should be noted that in practical applications, there are multiple ways to implement the above-mentioned method of writing the current security log from the cache to the permanent storage medium. One example is provided here: Figure 2 The flowchart shown is the current security log writing process, which includes the following steps S201 to S209.

[0084] Step S201: Receive the current security log. And trigger step S202.

[0085] Step S202: Determine whether the current amount of security log data is greater than the remaining storage capacity of the target storage area. If yes, trigger step S203; otherwise, trigger step S204.

[0086] Step S203: Perform a second erase operation on the target storage area. This triggers step S204.

[0087] Step S204: Split the current security log into multiple log fragments. Then trigger step S205.

[0088] Step S205: Determine if there are any log fragments that have not been written. If yes, trigger step S206; otherwise, trigger step S209.

[0089] Step S206: Identify a split log fragment that has not yet been written as the current log fragment, and write the current log fragment to the target storage area. This triggers step S207.

[0090] Step S207: Determine if there is a real-time task with a higher priority than the current security event in the security log. If yes, trigger step S208; otherwise, trigger step S205.

[0091] Step S208: Execute the real-time task and store the security log of the real-time task to the target storage area after the real-time task is completed. This triggers step S205.

[0092] Step S209: End the current security log writing process.

[0093] This application configures the system to perform write operations on security events sequentially, from highest to lowest priority, upon detecting at least one security event. This prioritizes writing to high-priority security events, ensuring log storage reliability. Furthermore, by configuring the system to obtain the current security log generated based on security event data and storing it in a cache, it provides temporary storage for the current security log. Moreover, by splitting the current security log into multiple log shards and configuring the data size of each shard to not exceed a preset single write data size threshold, the write time for a single log shard is shortened. This avoids the risk of write failure and data loss due to sudden power outages during prolonged write times, thus improving storage reliability. Subsequently, by configuring the split but incomplete log fragment to be identified as the current log fragment, the current log fragment is written to the target storage area. After writing is complete, it is monitored whether there are real-time tasks with a higher priority than the security event corresponding to the current security log. If so, the real-time task is executed. This splits the continuous writing operation of a complete security log into multiple independent writing operations. Furthermore, after completing the writing of a log fragment, it is configured to allow the interleaving execution of real-time tasks with a higher priority than the security event that generated the current security log, further avoiding the risk of task processing delays. Finally, by configuring the process of identifying a split but incomplete log fragment as the current log fragment after storing the security log of the completed real-time task to the target storage area, it ensures that the current security log, even if storage is interrupted, can be stored completely, improving log storage reliability. Therefore, this application ensures log storage reliability while avoiding the risk of task processing delays.

[0094] In one possible implementation, the vehicle safety log management method provided in the first aspect of this application further includes:

[0095] Upon receiving a security log read instruction, obtain the identifier of the security log to be read from the security log read instruction;

[0096] Extract the security log to be read corresponding to the identifier from the permanent storage medium, call the preset decryption script to decrypt the security log to be read, and send the obtained plaintext security log to the host computer;

[0097] When the host computer receives plaintext security logs, it performs a first erasure operation on the security logs to be read in the permanent storage medium based on the amount of data in the security logs to be read.

[0098] It should be noted that in practical application scenarios, the aforementioned security log read command can be generated in scenarios such as maintenance, R&D testing, and remote operation and maintenance. In these scenarios, since the vehicle is powered on, it dynamically generates new security logs and other task data (such as routine hardware status detection results or sensor data). This task data and security logs also need to be stored in permanent storage media. Therefore, this application configures the system to extract the security log to be read corresponding to the identifier from the permanent storage media upon receiving a security log read command, and calls a preset decryption script to decrypt the security log to be read. The obtained plaintext security log is then sent to the host computer. Upon receiving the plaintext security log, the host computer performs a first erasure operation on the security log to be read in the permanent storage media based on the amount of data in the security log to be read. This ensures that the security log to be read has been completely uploaded, and releases the space occupied by the security log to be read in the permanent storage media through the first erasure operation, thereby improving the storage reliability of subsequent security logs and avoiding the risk of security log writing failure due to insufficient storage space.

[0099] In one possible implementation, the mapping relationship between the security log to be read and its identifier can be achieved through the Flash Translation Layer (FTL) in flash management.

[0100] In one possible implementation, the first erase operation is either a physical erase operation or an asynchronous erase operation. Based on the amount of data in the security log to be read, the first erase operation is performed on the security log to be read in the permanent storage medium, including:

[0101] If the amount of data in the security log to be read is less than the preset storage area capacity threshold, perform a physical erasure operation on the security log to be read in the permanent storage medium.

[0102] If the amount of data in the security log to be read is not less than the preset storage area capacity threshold, an asynchronous erasure operation is performed on the security log to be read in the permanent storage medium. The asynchronous erasure operation is based on the task load state and performs logical erasure operation and physical erasure operation asynchronously.

[0103] It should be noted that, in practical applications, the aforementioned preset storage area capacity threshold can be the data capacity value of the smallest storage area in the permanent storage medium, or it can be the average data capacity value of all storage areas in the permanent storage medium. Assuming that the data capacity values ​​of all storage areas in the permanent storage medium are the same, if the amount of data in the security log to be read is less than the preset storage area capacity threshold, it indicates a high probability that the security log to be read occupies one storage area; if the amount of data in the security log to be read is not less than the preset storage area capacity threshold, it indicates a high probability that the security log to be read occupies at least two storage areas. This application, by configuring a comparison between the amount of data in the security log to be read and the preset storage area capacity threshold, can achieve a rough identification of the number of storage areas occupied by the security log in the permanent storage medium.

[0104] It should be noted that in practical applications, the above logical erasure operation updates the index status of the storage area of ​​the security log to be read from a state indicating that it is not storable to a state indicating that it is storable. This operation is a microsecond-level operation, and the logical storage space is released immediately after the logical erasure operation is performed, without affecting subsequent parameter writing. The above task load status indicates the backlog of tasks that need to be executed. Under this operation, the above security log to be read is not physically erased. Since the security log to be read has a large amount of data, it needs to cover multiple target storage areas of the permanent storage medium when writing it to the permanent storage medium. When erasing multiple target storage areas, the erasure time is much greater than that of erasing a single target storage area. Therefore, this application configures the logical erasure operation and physical erasure operation to be performed asynchronously on the security log to be read in the permanent storage medium based on the task load status, provided that the amount of data in the security log to be read is not less than the preset storage area capacity threshold. Thus, when the task load status indicates a large backlog of tasks, only the logical erasure operation is performed, so as to avoid the erasure task occupying the main loop for a long time, causing the execution of subsequent write tasks to lag. When the task load status indicates a small backlog of tasks, a physical erase operation is then performed on the storage area where the logical erase operation was executed, thereby ensuring the stability of subsequent writes.

[0105] It should be noted that in practical application scenarios, there are various implementation methods for performing the first erasure operation on the security log to be read in the permanent storage medium based on the amount of data to be read. One such method is provided here as an example, and the specific operation process includes the following: Figure 3Steps S301 to S307 in the first erasure operation flowchart shown.

[0106] Step S301: When the host computer receives the plaintext security log, it obtains the amount of security log data to be read. Then, step S302 is triggered.

[0107] Step S302: Determine whether the amount of data in the security log to be read is less than the preset storage area capacity threshold. If yes, then trigger step S303; otherwise, trigger step S304.

[0108] Step S303: Call the underlying erase interface to perform a physical erase operation on the storage area in the permanent storage medium that stores the security log to be read.

[0109] Step S304: Update the storage area index status flag in the permanent storage medium that stores the security log to be read to an index status flag that represents a storable state. Then trigger step S305.

[0110] Step S305: Release the logical storage space of the storage area storing the security log to be read. And trigger step S306.

[0111] Step S306: Determine whether the current task load status indicates task backlog. If not, repeat step S306; if yes, trigger step S307.

[0112] Step S307: Create a low-priority background wipe task. This triggers step S303.

[0113] To facilitate understanding of the operational mechanism of the vehicle safety log management method provided by the first aspect of this solution and one possible implementation of the first aspect, the following description is provided in conjunction with one possible implementation of this application:

[0114] like Figure 4 The diagram illustrates the operational mechanism of a vehicle safety log management method. Currently, the vehicle safety log is integrated into the AUTOSAR architecture, which includes a Software Component (SWC) layer, a Unified Diagnostic Services (UDS) layer, a Run Time Environment (RTE) layer, a Complex Device Driver (CDD) layer, a Memory Interface (MemIf) layer, and a non-volatile storage medium (i.e., non-volatile memory, NVM). The CDD layer includes a built-in cache.

[0115] The RTE layer monitors security events generated by the SWC layer and sends these events to the CDD layer. The CDD layer prioritizes the received security events, performing write operations on each event sequentially according to its priority from highest to lowest. After prioritizing, the CDD layer aggregates the security events and stores the current security log, generated through packet assembly and encryption, in a cache. After caching the current security log, the CDD layer selectively performs a second erase operation on the target storage area based on the data volume of the current security log and the remaining storage capacity of the target storage area. After erasing the target storage area, based on the vehicle security log management method provided in this application, the current security log is stored in the target storage area of ​​the NVM by calling the MemIf interface.

[0116] The RTE layer is also configured to forward the security log read command sent by the UDS layer to the CDD layer, so that the CDD layer can parse the security log read command and extract the security log to be read from the NVM through MemIf based on the obtained identifier of the security log to be read. The CDD decrypts the extracted security log to be read and sends the obtained plaintext security log to the host computer. When the host computer receives the plaintext security log, it performs a second erase operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read.

[0117] In one possible implementation, the current security log generated based on security event data is obtained, including:

[0118] By using the preset calling interface on the peripheral side, the preset packet assembly rules are invoked to assemble the data of the security event, obtain the current security log, and then the preset encryption algorithm is invoked to encrypt the current security log.

[0119] It should be noted that in practical application scenarios, the aforementioned preset packet assembly rules can be security log encoding rules set by the user based on their own needs. The aforementioned preset encryption algorithm is an encryption algorithm selected by the user based on their own data confidentiality requirements. Since the packet assembly rules and preset encryption algorithms for security logs differ among different users (such as vehicle manufacturers), and existing vehicle log management methods are mostly built using customized development, these methods cannot be reused. This application, however, achieves the reuse of the vehicle security log management architecture by pre-constructing preset packet assembly rules adapted to different users and generating the current security log by calling the preset packet assembly rules and preset encryption algorithms through interface calls.

[0120] It should be noted that, in practical application scenarios, the configuration process for calling the aforementioned preset packet assembly rules and preset encryption algorithms can be implemented by constructing a configuration file based on the preset packet assembly rules and preset encryption algorithms. This configuration file should include various macro definitions, constant definitions, and variable definitions for the preset packet assembly rules and preset encryption algorithms, as well as initialization and application-layer callback function frameworks. The aforementioned data can be obtained based on the Original Equipment Manufacturer Requirements Specification (OEM) issued by the user. The aforementioned constant and variable definitions include, but are not limited to: data encoding rules (data structure, event type, aggregation time, etc.), security requirements (encryption algorithm, key), and storage strategies (permanent storage medium, overwrite rules, etc.). Finally, the core code and configuration code of the preset packet assembly rules and preset encryption algorithms are output according to the configuration parameters, and the two are used together and integrated into the software system. During the integration process, core functions (such as the main loop configuration), including the vehicle safety log management method provided in the first aspect of this application, are encapsulated as static code, and variable strategies (such as the aforementioned preset encryption algorithm and preset packet assembly rules) are exposed as configuration items, so that the integrated software system can meet the ASIL level functional safety requirements and improve the reusability.

[0121] In one possible implementation, the current security log is stored in a cache, including:

[0122] Identify the preset overwrite policy. If the preset overwrite policy indicates that overwrite is allowed, overwrite the current security log in the target cache area with the earliest occupied state timestamp in the cache area, update the occupied state timestamp of the target cache area, and add a data overflow flag to the target cache area. The data overflow flag indicates the data information of the target cache area before it is overwritten.

[0123] If the preset overwrite policy indicates that overwriting is prohibited, discard the current security log.

[0124] It should be noted that in actual application scenarios, the above-mentioned preset coverage strategy is similar to the above-mentioned preset package rules and can also be obtained from the OEM.

[0125] It should be noted that in practical applications, there are multiple ways to implement storing the current security log in the cache. One example is provided here, and the flowchart for caching the current security log is as follows: Figure 5 As shown, it includes the following steps S501 to S507.

[0126] Step S501: Receive the current security log generation signal. And trigger step S502.

[0127] Step S502: Determine whether all cache regions in the cache are full. If not, trigger step S503; if yes, trigger step S504.

[0128] Step S503: Write the current security log to the target cache area that is not full, and update the valid status bit of the target cache area.

[0129] Step S504: Determine whether the preset coverage policy indicates that coverage is allowed. If not, trigger step S505; if yes, trigger step S506.

[0130] Step S505: Discard the current security log.

[0131] Step S506: Determine the cache region with the earliest occupied state timestamp as the target cache region. Then trigger step S507.

[0132] Step S507: Overwrite the current security log in the target cache area, update the occupancy status timestamp of the target cache area, and add a data overflow flag to the target cache area.

[0133] It should be noted that in real-world applications, due to differences in overlay strategies among different automakers, any vehicle security log management solution cannot prevent the loss of security logs for users prohibited from overlaying without authorization. For users allowed to overlay, recording the overlaid security logs is a necessary measure for subsequent traceability. Therefore, this application improves the reusability and compatibility of the vehicle security log management provided in the first aspect by configuring the identification of a preset overlay strategy before overlay storage. Simultaneously, by configuring the current security log to be overlaid and stored in the target cache area with the earliest occupied state timestamp when overlay is allowed, and updating the occupied state timestamp of the target cache area, the application avoids overlaying the most recently stored security logs, reducing the risk of recently stored security logs being overlaid and deleted before being written to permanent storage media, thus improving the storage reliability of security logs. Furthermore, by configuring the addition of a data overflow flag to the target cache area, the application utilizes the data overflow flag, which represents the data information of the target cache area before it is overlaid, to record information about the overlaid security logs, facilitating subsequent traceability.

[0134] In one possible implementation, write operations are performed on each security event sequentially, according to their priority from highest to lowest, including:

[0135] Identify the priority labels of security events and import them into the processing queues corresponding to the priority labels. The processing queues include a high-priority processing queue, a medium-priority processing queue, and a low-priority processing queue, arranged from high to low priority.

[0136] When security events are imported into the high-priority processing queue, write operations are performed on the security events in the high-priority processing queue in the order of import.

[0137] In the security event import priority processing queue, if there are no security events in the high priority processing queue, after a first preset time delay, the security events in the medium priority processing queue are written sequentially according to the import order.

[0138] If a security event is imported into a low-priority processing queue, and there are no security events in either the high-priority or medium-priority processing queues within the second preset time period, the security events in the low-priority processing queue are written sequentially according to the order of import.

[0139] It should be noted that, in practical application scenarios, this application configures the security events in the high-priority processing queue to be written sequentially according to the import order when security events are imported into the high-priority processing queue. When security events are imported into the medium-priority processing queue and there are no security events in the high-priority processing queue, the security events in the medium-priority processing queue are written sequentially according to the import order after a first preset time delay. When security events are imported into the low-priority processing queue and there are no security events in either the high-priority or medium-priority processing queues within a second preset time, the security events in the low-priority processing queue are written sequentially according to the import order. This prioritizes the writing of high-priority security events, avoiding the risk of high-priority security log writing failures due to low-priority security events occupying storage space on the permanent storage medium, thus improving the storage reliability of high-priority security logs.

[0140] It should be noted that, in practical applications, the priorities of the aforementioned safety events can be pre-set based on their impact on vehicle driving safety. For example, assuming the safety events include brake malfunction, tire pressure malfunction, and air conditioning malfunction, then brake malfunction should be placed in a high-priority processing queue, tire pressure malfunction in a medium-priority processing queue, and air conditioning malfunction in a low-priority processing queue.

[0141] One possible implementation also includes:

[0142] If a security event consistently exists in the high-priority processing queue or the medium-priority processing queue within the second preset time period, the security event in the low-priority processing queue will be discarded.

[0143] It should be noted that in practical applications, there are multiple implementation methods for performing write operations on security events sequentially according to their priority from high to low. One such implementation is provided here as an example:

[0144] like Figure 6 The diagram shows a flowchart for sorting and writing security events, including the following steps S601 to S609.

[0145] Step S601: Identify the priority label of the current security event. Then trigger step S602.

[0146] Step S602: Determine whether the priority label corresponds to the high-priority processing queue. If yes, trigger step S603; otherwise, trigger step S604.

[0147] Step S603: Import the current security event into the high-priority processing queue, and remove the security events from the high-priority processing queue in the order of import to perform write operations.

[0148] Step S604: Determine whether the priority label corresponds to the medium-priority processing queue. If yes, trigger step S605; otherwise, trigger step S606.

[0149] Step S605: Import the current security event into the medium-priority processing queue. After a first preset time delay and when there are no security events in the high-priority processing queue, remove the security events from the medium-priority processing queue in the order of import and perform the write operation.

[0150] It should be noted that in actual application scenarios, the starting time of the first preset duration is the moment when the first security event is imported into the medium priority processing queue, and it is reset after each timeout.

[0151] Step S606: Import the current security event into the low-priority processing queue. Then trigger step S607.

[0152] Step S607: Determine whether there are no security events in either the high-priority processing queue or the medium-priority processing queue within the second preset time period. If yes, trigger step S608; otherwise, trigger step S609.

[0153] It should be noted that in actual application scenarios, the start time of the second preset duration is the moment when the first security event is imported into the low-priority processing queue, and it is reset after each timeout.

[0154] Step S608: Based on the import order, security events in the low-priority processing queue are removed and written operations are performed sequentially.

[0155] Step S609: Discard all security events in the low-priority processing queue.

[0156] A second aspect of this application provides a vehicle safety log management system, comprising:

[0157] The write unit is used to perform write operations on each security event sequentially according to their priority from high to low when at least one security event is detected. The write operation includes:

[0158] Obtain the current security log generated based on security event data, and store the current security log in the cache;

[0159] The current security log in the cache is split into multiple log fragments, and the data volume of each log fragment is no greater than the preset threshold for the amount of data written in a single instance.

[0160] A log fragment that has been split but not yet written is identified as the current log fragment. The current log fragment is written to the target storage area. After the writing is completed, it is checked whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If there is, the real-time task is executed. After the security log of the executed real-time task is stored in the target storage area, the step of identifying a log fragment that has been split but not yet written as the current log fragment is continued.

[0161] In one possible implementation, the vehicle safety log management system also includes:

[0162] The reading unit is used to obtain the identifier of the security log to be read in the security log reading instruction when a security log reading instruction is received; extract the security log to be read corresponding to the identifier from the permanent storage medium, call the preset decryption script to decrypt the security log to be read, and send the obtained plaintext security log to the host computer; when the host computer receives the plaintext security log, it performs a first erasure operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read.

[0163] In one possible implementation, the read unit is configured to perform a first erase operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read:

[0164] If the amount of data in the security log to be read is less than the preset storage area capacity threshold, a physical erasure operation is performed on the security log to be read in the permanent storage medium. The first erasure operation is either a physical erasure operation or an asynchronous erasure operation.

[0165] If the amount of data in the security log to be read is not less than the preset storage area capacity threshold, an asynchronous erasure operation is performed on the security log to be read in the permanent storage medium. The asynchronous erasure operation is based on the task load state and performs logical erasure operation and physical erasure operation asynchronously.

[0166] In one possible implementation, the write unit is set to:

[0167] By using the preset calling interface on the peripheral side, the preset packet assembly rules are invoked to assemble the data of the security event, obtain the current security log, and then the preset encryption algorithm is invoked to encrypt the current security log.

[0168] In one possible implementation, the write unit is configured to store the current security log to the buffer as follows:

[0169] Identify the preset overwrite policy. If the preset overwrite policy indicates that overwrite is allowed, overwrite the current security log in the target cache area with the earliest occupied state timestamp in the cache area, update the occupied state timestamp of the target cache area, and add a data overflow flag to the target cache area. The data overflow flag indicates the data information of the target cache area before it is overwritten. If the preset overwrite policy indicates that overwrite is prohibited, discard the current security log.

[0170] In one possible implementation, the write unit is configured to perform write operations on security events sequentially according to their priority from high to low as follows:

[0171] Identify the priority labels of security events and import them into the processing queues corresponding to the priority labels. The processing queues include a high-priority processing queue, a medium-priority processing queue, and a low-priority processing queue, arranged from high to low priority.

[0172] When security events are imported into the high-priority processing queue, write operations are performed on the security events in the high-priority processing queue in the order of import.

[0173] In the security event import priority processing queue, if there are no security events in the high priority processing queue, after a first preset time delay, the security events in the medium priority processing queue are written sequentially according to the import order.

[0174] If a security event is imported into a low-priority processing queue, and there are no security events in either the high-priority or medium-priority processing queues within the second preset time period, the security events in the low-priority processing queue are written sequentially according to the order of import.

[0175] In one possible implementation, the write unit is also set as:

[0176] If a security event consistently exists in the high-priority processing queue or the medium-priority processing queue within the second preset time period, the security event in the low-priority processing queue will be discarded.

[0177] A third aspect of this application provides an electronic control unit, including at least one processor and a memory connected to the processor, wherein:

[0178] Memory is used to store computer programs;

[0179] The processor is used to execute computer programs to enable the electronic control unit to implement the vehicle safety log management method of the first aspect or any implementation thereof.

[0180] The fourth aspect of this application provides a computer storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic control unit, the electronic control unit is able to implement the vehicle safety log management method described in the first aspect or any implementation thereof.

[0181] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0182] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0183] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0184] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for managing vehicle safety logs, characterized in that, include: Upon detecting at least one security event, write operations are performed on each security event sequentially according to their priority from highest to lowest. The write operations include: Obtain the current security log generated based on security event data, and store the current security log in the cache area; The current security log in the cache is split into multiple log fragments, and the data volume of each log fragment is not greater than a preset single write data volume threshold. A log fragment that has been split but not yet written is identified as the current log fragment. The current log fragment is written to the target storage area. After the writing is completed, it is monitored whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If there is, the real-time task is executed. After the security log of the executed real-time task is stored in the target storage area, the step of identifying a log fragment that has been split but not yet written is identified as the current log fragment is continued.

2. The method for managing vehicle safety logs according to claim 1, characterized in that, The method for managing the vehicle safety log also includes: Upon receiving a security log read instruction, obtain the identifier of the security log to be read in the security log read instruction; Extract the security log to be read corresponding to the identifier from the permanent storage medium, call the preset decryption script to decrypt the security log to be read, and send the obtained plaintext security log to the host computer; When the host computer receives the plaintext security log, it performs a first erasure operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read.

3. The method for managing vehicle safety logs according to claim 2, characterized in that, The first erasure operation is a physical erasure operation or an asynchronous erasure operation. The step of performing the first erasure operation on the security log to be read in the permanent storage medium based on the amount of data in the security log to be read includes: If the amount of data in the security log to be read is less than the preset storage area capacity threshold, the physical erasure operation is performed on the security log to be read in the permanent storage medium. If the amount of data in the security log to be read is not less than the preset storage area capacity threshold, the asynchronous erasure operation is performed on the security log to be read in the permanent storage medium. The asynchronous erasure operation is based on the task load state and performs the logical erasure operation and the physical erasure operation asynchronously.

4. The method for managing vehicle safety logs according to claim 1, characterized in that, The process of obtaining the current security log generated based on security event data includes: By using the peripheral side's preset call interface, the data of the security event is packaged according to the preset packetization rules to obtain the current security log, and the current security log is encrypted by calling the preset encryption algorithm.

5. The method for managing vehicle safety logs according to claim 1, characterized in that, The step of storing the current security log in the cache includes: Identify a preset overwrite policy. If the preset overwrite policy indicates that overwrite is allowed, overwrite the current security log in the target cache area with the earliest occupied state timestamp in the cache area, update the occupied state timestamp of the target cache area, and add a data overflow flag to the target cache area. The data overflow flag indicates the data information of the target cache area before it is overwritten. If the preset overwrite policy indicates that overwriting is prohibited, the current security log is discarded.

6. The method for managing vehicle safety logs according to claim 1, characterized in that, The step of performing write operations on each security event sequentially according to its priority from high to low includes: The priority label of the security event is identified, and the security event is imported into the processing queue corresponding to the priority label. The processing queue includes a high-priority processing queue, a medium-priority processing queue, and a low-priority processing queue arranged from high to low priority. When a security event is imported into the high-priority processing queue, the write operation is performed on the security events in the high-priority processing queue in the order of import. When the security event is imported into the medium-priority processing queue and there is no security event in the high-priority processing queue, the write operation is performed on the security events in the medium-priority processing queue in the order of import after a first preset time delay. If the security event is imported into the low-priority processing queue, and there is no security event in either the high-priority processing queue or the medium-priority processing queue within a second preset time period, the write operation is performed on the security events in the low-priority processing queue in the order of import.

7. The method for managing vehicle safety logs according to claim 6, characterized in that, Also includes: If the security event always exists in the high-priority processing queue or the medium-priority processing queue within the second preset time period, the security event in the low-priority processing queue is discarded.

8. A vehicle safety log management system, characterized in that, include: A writing unit is configured to, upon detecting at least one security event, sequentially perform a write operation on each of the security events in descending order of priority. The write operation includes: Obtain the current security log generated based on security event data, and store the current security log in the cache area; The current security log in the cache is split into multiple log fragments, and the data volume of each log fragment is not greater than a preset single write data volume threshold. A log fragment that has been split but not yet written is identified as the current log fragment. The current log fragment is written to the target storage area. After the writing is completed, it is monitored whether there is a real-time task with a higher priority than the security event corresponding to the current security log. If there is, the real-time task is executed. After the security log of the executed real-time task is stored in the target storage area, the step of identifying the log fragment that has been split but not yet written as the current log fragment continues.

9. An electronic control unit, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic control unit can implement the vehicle safety log management method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by the electronic control unit, enable the electronic control unit to implement the vehicle safety log management method as described in any one of claims 1 to 7.

Images