Log storage method of controller in vehicle, controller, electronic device and vehicle

Abstract

The application discloses a log storage method of a controller in a vehicle, the controller, an electronic device and the vehicle. The controller comprises a plurality of cores, and different cores are used for executing different tasks of the vehicle. The method comprises the following steps: in response to the controller being in an abnormal running state, obtaining running state information of the controller in the abnormal running state; based on the running state information, determining weight information of a log set generated by the core in the process of executing the task, wherein the weight information is used for representing the association degree between the log in the log set and the abnormal running state; based on the weight information and the log set, determining a to-be-stored log set of the core; and calling a storage strategy corresponding to the weight information to store the to-be-stored log set, wherein the storage strategy is used for representing the rule of storing the log in the to-be-stored log set. The application solves the technical problem of low flexibility of log storage of the controller in the vehicle.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more specifically, to a log storage method for a controller in a vehicle, a controller, electronic devices, and a vehicle. Background Technology

[0002] Currently, the logs of the controller in the vehicle can be stored by calling a pre-set log mode through a single indicator, which can store different levels of logs specified in the controller's protocol stack configuration file.

[0003] However, due to the limited computing resources of the vehicle, the above-mentioned method of storing logs in log mode can lead to a large number of logs occupying the controller's buffer when the controller is in an abnormal operating state, which can easily result in the loss of logs that are not occupied in the buffer.

[0004] Therefore, the technical problem of low flexibility in storing controller logs in vehicles still exists.

[0005] There is currently no effective solution to the aforementioned technical problems. Summary of the Invention

[0006] This application provides a method for storing logs of a controller in a vehicle, a controller, an electronic device, and a vehicle, to at least solve the technical problem of low flexibility in storing logs of a controller in a vehicle.

[0007] According to one aspect of the embodiments of this application, a method for storing logs of a controller in a vehicle is provided. The controller includes multiple cores, each core performing different tasks of the vehicle. The method may include: in response to the controller being in an abnormal operating state, acquiring operating state information of the controller in the abnormal operating state; determining weight information of the log set generated by the cores during task execution based on the operating state information, wherein the weight information represents the degree of correlation between the logs in the log set and the abnormal operating state; determining a log set to be stored for the core based on the weight information and the log set; and invoking a storage strategy corresponding to the weight information to store the log set to be stored, wherein the storage strategy represents the rules for storing the logs in the log set to be stored.

[0008] Optionally, based on weight information and the log set, the log set to be stored is determined, including: in response to the weight information being greater than a weight threshold, determining a first subset of logs in the log set as the log set to be stored, wherein the degree of correlation between logs in the first subset of logs and the abnormal operating state is greater than the degree of correlation between logs in the log set other than the first subset of logs and the abnormal operating state; and in response to the weight information being less than a weight threshold, determining the log set as the log set to be stored.

[0009] Optionally, the second log subset in the log set includes logs other than the first log subset in the log set. The method further includes: determining the type of logs in the second log subset based on the status keywords of the abnormal running state, wherein different types of logs contain different numbers of status keywords; and invoking a compression strategy corresponding to the type of logs in the second log subset to compress the logs in the second log subset, wherein the compression strategy is used to represent the rules for compressing the logs in the second log subset.

[0010] Optionally, the types include a first type and a second type. The logs of the first type are more important to the controller than the logs of the second type. The compression strategy corresponding to the type of the logs in the second log subset is invoked to compress the logs in the second log subset. This includes: invoking the compression strategy corresponding to the first type to compress the logs of the first type in the second log subset; and invoking the compression strategy corresponding to the second type to compress the logs of the second type in the second log subset. The compression degree of the logs compressed by invoking the compression strategy corresponding to the first type is less than the compression degree of the logs compressed by invoking the compression strategy corresponding to the second type.

[0011] Optionally, the operational status information includes risk status information, resource status information, and task status information. Abnormal status information is used to indicate the risk level of the controller in an abnormal operational state. Resource status information is used to indicate the scheduling level of the amount of resources required to execute tasks. Task status information is used to indicate the backlog of tasks to be executed within the kernel. Based on the operational status information, the weight information of the log set generated during the kernel's task execution is determined, including: using a preset weight set in the controller's configuration file to perform a weighted average of the risk status information, task status information, and resource status information to obtain the weight information. The preset weight set includes preset weight information corresponding to the risk status information, task status information, and resource status information, respectively.

[0012] Optionally, the log set to be stored includes a third log subset and a fourth log subset. The third log subset is more important to the controller than the fourth log subset. The storage strategy includes a first storage strategy and a second storage strategy. The first storage strategy represents the rules for storing the logs to be stored in multiple cores, and the second storage strategy represents the rules for storing the logs to be stored in the same core. The storage strategy corresponding to the weight information is invoked to store the log set to be stored, including: in response to the first storage strategy, storing the third log subset in multiple cores; and in response to the second storage strategy, storing the fourth log subset in the target core.

[0013] Optionally, in response to the storage policy being the second storage policy, storing the fourth log subset in the target core includes: in response to the storage policy being the second storage policy, filling the fourth log subsets of multiple cores into a preset log template to obtain a filling result; and transmitting the filling result of multiple cores to the storage space in the target core for storage through a preset gateway.

[0014] According to another aspect of the embodiments of this application, a vehicle controller is also provided. The controller includes a real-time core and an intelligent core. The real-time core is used to obtain the operating status information of the controller in the abnormal operating state in response to the controller being in an abnormal operating state. Based on the operating status information, it determines the weight information of the log set generated by the real-time core and the intelligent core during the execution of tasks. The weight information is used to represent the degree of correlation between the logs in the log set and the abnormal operating state. The intelligent core is used to determine the log set to be stored by the core based on the weight information and the log set. It calls the storage strategy corresponding to the weight information to store the log set to be stored. The storage strategy is used to represent the rules for storing the logs in the log set to be stored.

[0015] According to another aspect of the embodiments of this application, a log storage device for a controller in a vehicle is also provided. The device may include: an acquisition unit, configured to acquire operating status information of the controller in an abnormal operating state in response to the controller being in an abnormal operating state; a first determination unit, configured to determine weight information of a log set generated by the core during task execution based on the operating status information, wherein the weight information is used to represent the degree of correlation between logs in the log set and the abnormal operating state; a second determination unit, configured to determine a log set to be stored for the core based on the weight information and the log set; and a storage unit, configured to invoke a storage strategy corresponding to the weight information to store the log set to be stored, wherein the storage strategy represents the rules for storing logs in the log set to be stored.

[0016] According to another aspect of the embodiments of this application, an electronic device is also provided. The electronic device may include a memory and a processor. The memory may be used to store an executable program. The processor may be used to run the aforementioned executable program, wherein the executable program performs any of the methods described in the embodiments of this application during execution.

[0017] According to another aspect of the embodiments of this application, a vehicle is also provided. The vehicle may include a memory and a processor. The memory is used to store an executable program. The processor can be used to run the executable program stored in the memory. During the execution of the executable program, any one of the methods of the embodiments of this application is implemented.

[0018] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided. This computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform any of the methods of the embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a processor is also provided. The processor is used to run a program, wherein the program executes any of the methods of the embodiments of this application during runtime.

[0020] According to another aspect of the embodiments of this application, a computer program product is also provided. This computer program product includes a computer program that, when executed by a processor, implements any of the methods described in the embodiments of this application.

[0021] In this embodiment, the operating status information of the controller under abnormal operating conditions can be obtained; based on the above operating status information, the weight information of the log set generated by the core during task execution is determined, and the log set to be stored is filtered based on the above weight information; the storage operation is performed by calling the storage strategy corresponding to the above weight information, thereby realizing the storage of the log set generated by the core during task execution. The above method can filter the log set to be stored based on the above weight information and execute the corresponding storage strategy based on the above weight information. Therefore, when the controller is in an abnormal operating state, the above method can call the corresponding storage strategy to prioritize the storage operation of the filtered log set to be stored. This overcomes the situation where the logs to be stored are lost due to a large number of logs other than the log set to be stored occupying the controller's buffer. This solves the technical problem of low log storage flexibility in vehicle controllers and achieves the technical effect of improving the log storage flexibility of vehicle controllers. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a flowchart of a log storage method for a controller in a vehicle according to an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of a heterogeneous multi-core dynamic sensing log system structure according to an embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating a high-risk scenario for a heterogeneous multi-core system according to an embodiment of this application;

[0026] Figure 4This is a flowchart of a heterogeneous multi-core log dynamic perception decision-making process according to an embodiment of this application;

[0027] Figure 5 This is a flowchart of a heterogeneous multi-core log intelligent compression strategy according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of a cross-core log information storage collaborative optimization structure according to an embodiment of this application;

[0029] Figure 7 This is a flowchart of a remote upgrade log dynamic sensing strategy according to an embodiment of this application;

[0030] Figure 8 This is a schematic diagram of a vehicle controller according to an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of a log storage device for a controller in a vehicle according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., 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 data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] According to an embodiment of this application, an embodiment of a log storage method for a controller in a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] Figure 1 This is a flowchart of a log storage method for a controller in a vehicle according to an embodiment of this application, as shown below. Figure 1 As shown, the method may include the following steps.

[0036] Step S102: In response to the controller being in an abnormal operating state, obtain the operating status information of the controller in the abnormal operating state.

[0037] In the technical solution provided in step S102 of this application, the controller includes multiple cores, with different cores used to execute different tasks of the vehicle. For example, the controller may include, but is not limited to, real-time cores and intelligent cores, wherein the performance and storage space of the real-time cores are more limited than those of the intelligent cores. In the embodiments of this application, when the vehicle is in an abnormal operating condition, it may cause the controller in the vehicle to enter a corresponding abnormal operating state.

[0038] Optionally, the aforementioned abnormal operating states can be used to represent abnormal operating states that affect the functional safety or stability of the controller. These abnormal operating states may include, but are not limited to, the operating state of the controller when the vehicle triggers a safety event, the operating state of the controller when the vehicle is in an unsafe state, and the operating state of the controller when the vehicle is in a high-risk scenario. For example, the aforementioned vehicle triggering a safety event could be triggering the vehicle's automatic emergency braking. The aforementioned unsafe state could be a state where the hydraulic pressure of the vehicle's braking system abnormally increases. The aforementioned high-risk scenario could be a scenario where the vehicle's braking system is overloaded.

[0039] It should be noted that the above-mentioned abnormal operating states are only illustrative examples and are not specifically limited here. Any abnormal operating state that can affect the log storage process of the controller is within the protection scope of the embodiments of this application.

[0040] Optionally, the aforementioned operational status information can be used to characterize different indicators of the controller under abnormal operational states. For example, this operational status information may include, but is not limited to, safety status, central processing unit (CPU) load, and communication queue depth. The safety status can represent the functional safety level of the controller. The CPU load can represent the proportion of computing resources utilized by the multiple cores per unit time. The communication queue depth can represent the number of pending messages in the message queues between the multiple cores. Specifically, the safety status can be represented by `safety_level`, the CPU load by `cpu_utilization`, and the communication queue depth by `comm_queue_depth`.

[0041] Optionally, if the vehicle controller is detected to be in an abnormal operating state during vehicle operation, the operating status information of the controller in the abnormal operating state can be obtained.

[0042] Optionally, in response to the controller being in an abnormal operating state, different metrics of the controller can be collected through a preset controller status interface. For example, the preset controller status interface can be used to call the get_safety_level() function to obtain the safety status, call the get_cpu_utilization() function to obtain the CPU load, and call the get_comm_queue_depth() function to obtain the communication queue depth.

[0043] It should be noted that the above method of obtaining running status information by calling function methods through the preset controller status interface is only an example, and there are no specific restrictions on the method of obtaining running status information.

[0044] In this embodiment of the application, the above step S102 can be used to perceive the operating status information of the controller based on different indicators of the controller in abnormal operating state, thereby determining the specific operating status information of the controller in abnormal operating state, thus overcoming the obstacle of lacking perception of the specific operating status information of the controller in abnormal operating state in related technologies.

[0045] Step S104: Based on the running status information, determine the weight information of the log set generated by the kernel during the execution of the task, wherein the weight information is used to represent the degree of correlation between the logs in the log set and the abnormal running status.

[0046] In the technical solution provided in step S104 of this application, the aforementioned log set can be a collection of log data generated by the controller for storage during abnormal operation. The aforementioned weight information can be used to represent the degree of correlation between the logs in the log set and the abnormal operation state. This weight information can also be called a log weight value, and can be represented by LogWeight.

[0047] Optionally, after obtaining the operating status information of the controller in an abnormal operating state, the weight information of the log set generated by the kernel during the execution of the task can be determined based on the operating status information.

[0048] Optionally, based on the operational status information, the collected operational status information can be linearly weighted and summed using preset software configuration file parameters and preset weight calculation formulas in the vehicle to obtain the weight information of the log set. For example, the weight information includes log weight values ​​that characterize the correlation strength between the log set and the current abnormal operational state. Based on the aforementioned safety status, CPU load, and communication queue depth, combined with preset software configuration file parameters, the correlation strength between each log in the log set generated by the controller under abnormal operational state and the current abnormal operational state is evaluated, and the aforementioned log weight values ​​are output.

[0049] In this embodiment of the application, the correlation strength between the log set and the current abnormal operating state can be evaluated through the above step S104, which overcomes the obstacle in the related technology that only relies on the predetermined different levels and ignores the correlation strength between the log set and the current abnormal operating state.

[0050] Step S106: Based on the weight information and the log set, determine the log set to be stored for the core.

[0051] In the technical solution provided in step S106 of this application, the log set to be stored can be the log set that the controller determines to be stored after dynamically filtering and classifying the log set generated by the kernel during the execution of the task according to the log weight value LogWeight. The log set to be stored may include, but is not limited to, critical logs and non-critical logs.

[0052] Optionally, after determining the weight information of the log set generated by the kernel during task execution, the kernel's log set to be stored can be determined based on the weight information and the log set.

[0053] Optionally, logs whose weight information meets preset conditions can be retained as the log set to be stored. For example, the preset conditions can be set as a threshold of the weight value that the weight information needs to meet. For instance, logs whose weight information meets LogWeight > 0.7 can be identified as core critical logs; logs whose weight information meets LogWeight < 0.7 can be identified as core non-critical logs.

[0054] It should be noted that the above-mentioned preset conditions, and the key or non-key logs determined by meeting the preset conditions, are only examples, and there are no specific restrictions on the method of determining the log set to be stored based on weight information.

[0055] In this embodiment of the application, the above step S106 can achieve fine classification of the log set and ensure that in the scenario where the controller is in an abnormal operating state, the key days with a higher correlation to the current risk scenario can be identified, thereby improving the flexibility of storing logs.

[0056] Step S108: Invoke the storage strategy corresponding to the weight information to store the log set to be stored.

[0057] In the technical solution provided in step S108 of this application, the storage strategy can be used to characterize the rules for storing logs in the log set to be stored. For example, the storage strategy can be used to indicate whether to store all or part of the logs in the log set to be stored. The storage strategy can also be called a log recording strategy.

[0058] Optionally, after determining the log set to be stored for the kernel based on the weight information and the log set, a storage strategy corresponding to the weight information can be invoked to store the log set to be stored.

[0059] Optionally, while determining the log set to be stored for the core based on weight information and preset conditions, a storage strategy corresponding to the preset conditions can be invoked, thereby allowing different responses to the log set to be stored based on the weight information. For example, when the weight information satisfies LogWeight>0.7, a partial storage strategy can be invoked. This partial storage strategy can represent a rule that writes the critical logs generated by the core to the storage space corresponding to the core, and writes the non-critical logs generated by the core to the storage space of the intelligent core. The full storage strategy can represent a rule that writes all logs to the core's storage space when the weight information meets the normal state.

[0060] In this application, steps S102 to S108 described above can obtain the operating status information of the controller in an abnormal operating state; determine the weight information of the log set generated by the core during task execution based on the operating status information, and filter the log set to be stored based on the weight information; and call the storage strategy corresponding to the weight information to perform the storage operation, thereby realizing the storage of the log set generated by the core during task execution. The above method can filter the log set to be stored based on the weight information and execute the corresponding storage strategy based on the weight information. Therefore, when the controller is in an abnormal operating state, the above method can call the corresponding storage strategy to prioritize the storage operation of the filtered log set to be stored. This overcomes the problem of a large number of logs other than the log set to be stored occupying the controller's buffer, thus preventing the loss of the logs to be stored. This solves the technical problem of low log storage flexibility in vehicle controllers and achieves the technical effect of improving the log storage flexibility of vehicle controllers.

[0061] The method described in this embodiment will be further described below.

[0062] As an optional embodiment, step S106, determining the log set to be stored based on weight information and the log set, includes: in response to the weight information being greater than a weight threshold, determining a first subset of logs in the log set as the log set to be stored, wherein the correlation between logs in the first subset of logs and the abnormal operating state is greater than the correlation between logs in the log set other than the first subset of logs and the abnormal operating state; and in response to the weight information being less than a weight threshold, determining the log set as the log set to be stored.

[0063] In this embodiment, the aforementioned weight threshold can be used to represent a critical value indicating the strength of the association between the log set and the current abnormal operating state. The aforementioned first log subset can be used to represent the logs with the highest priority that are directly related to functional safety under the abnormal operating state. For example, safety event trigger code logs and brake control anomaly logs. The degree of association between the logs in the first log subset and the abnormal operating state is greater than the degree of association between the logs in the log set other than the first log subset and the abnormal operating state.

[0064] Optionally, in response to a weight information greater than a weight threshold, each log in the log set whose weight information is greater than the weight threshold can be used as the first log subset in the log set, and the first log subset can be determined as the log set to be stored.

[0065] Optionally, in response to the weight information being less than the weight threshold, it is determined that the current controller is in a normal or low-risk operating state. At this time, there is no urgent risk of resource shortage, so the log set is not filtered or compressed, and the entire log set can be retained as a log set to be stored.

[0066] In this embodiment of the application, the above method can realize adaptive hierarchical control of log storage decisions. By using the first subset of logs with a high degree of correlation with abnormal operating states as the log set to be stored, the occupation of limited resources in the vehicle by logs with a low degree of correlation with abnormal operating states can be minimized.

[0067] As an optional implementation, the second log subset in the log set includes logs other than the first log subset in the log set. The method further includes: determining the type of logs in the second log subset based on the status keywords of the abnormal running state, wherein different types of logs contain different numbers of status keywords; and invoking a compression strategy corresponding to the type of logs in the second log subset to compress the logs in the second log subset, wherein the compression strategy is used to represent the rules for compressing the logs in the second log subset.

[0068] In this embodiment, the second log subset can represent logs other than the first log subset, such as non-critical logs. The status keywords can represent keywords or semantic identifiers reflecting the controller's operating status, event type, or semantic features in the log content, such as "Debug," "Info," "Warning," and "Repeated." The log type can represent the classification of the second log subset based on the semantics and functional importance of the status keywords; the log type can include, but is not limited to, critical logs, important logs, and non-important logs. The compression strategy can represent the rules for compressing logs in the second log subset.

[0069] Optionally, logs other than the first log subset can be identified as the second log subset. Semantic parsing can be performed on each log in the second log subset to extract predefined status keywords contained in each log in the second log subset, which may include, but are not limited to, "Debug", "Info", and "Warning". The logs can be classified into different log types based on different security-related keywords appearing in the logs.

[0070] Optionally, after determining the log type, a compression strategy corresponding to the log type in the second log subset can be invoked to compress the logs in the second log subset. For example, a compression strategy can be implemented where logs of the critical log type are not compressed and are directly written to the implementation buffer.

[0071] In this embodiment of the application, the above method can realize differentiated and intelligent hierarchical compression control based on the semantic recognition of logs of different types, and execute corresponding compression strategies for the different categories of logs, thereby reducing the consumption of storage resources in the vehicle.

[0072] As an optional implementation, the types include a first type and a second type. The logs of the first type are more important to the controller than the logs of the second type. A compression strategy corresponding to the type of logs in the second log subset is invoked to compress the logs in the second log subset. This includes: invoking the compression strategy corresponding to the first type to compress the logs of the first type in the second log subset; and invoking the compression strategy corresponding to the second type to compress the logs of the second type in the second log subset. The compression level of the logs compressed using the compression strategy corresponding to the first type is less than the compression level of the logs compressed using the compression strategy corresponding to the second type.

[0073] In this embodiment, the first type of logs may include, but is not limited to, logs of medium to high value for controller functional safety and fault diagnosis, and can also be referred to as important logs. The second type of logs may include, but is not limited to, logs that have no direct impact on the operation of the controller, and can also be referred to as unimportant logs. Wherein, the importance of the first type of logs to the controller is greater than that of the second type of logs, and the compression strategy corresponding to the log type in the second log subset is invoked.

[0074] Optionally, the compression strategy corresponding to the first type can be invoked. For logs of the first type, such as important logs, a semantically preservative light compression strategy can be executed. The above light compression strategy can remove only redundant formats, standardized timestamps, and abbreviated non-critical fields, retain error codes, and control the compression ratio within 30%.

[0075] Optionally, the compression strategy corresponding to the second type can be invoked. For logs of the second type, such as non-important logs, a hash table can be used to delete consecutive duplicate entries (for example, if "Engine RPM:2000" appears 10 times consecutively, only one entry is kept). Then, semantic compression encoding is performed on important and non-important information, and the entire log information is replaced by common numbers or initial abbreviations, retaining only key information data. This converts the structured log into a lightweight format while controlling the compression rate to be no less than 70%.

[0076] For example, logs classified as important can be compressed at a compression rate of 30% or less, retaining high-level logs such as Warning, Error, and above, and preserving their key semantics; logs classified as non-important can be compressed at a compression rate of 70% or more.

[0077] In this embodiment of the application, the above method can be used to perform corresponding compression strategies on different types of logs, thereby achieving the goal of preserving the core semantics and diagnostic elements of important logs, and achieving a compression rate of over 70% for non-important logs through hash table deduplication and symbol encoding, thus reducing storage occupation and memory buffer pressure.

[0078] As an optional implementation, the running status information includes risk status information, resource status information, and task status information. The risk status information is used to indicate the degree of risk of the controller in an abnormal running state, the resource status information is used to indicate the scheduling degree of the amount of resources required to execute the task, and the task status information is used to indicate the backlog of tasks to be executed within the kernel. Based on the running status information, the weight information of the log set generated during the kernel's task execution is determined, including: using a preset weight set in the controller's configuration file to perform a weighted average of the risk status information, task status information, and resource status information to obtain the weight information. The preset weight set includes preset weight information corresponding to the risk status information, task status information, and resource status information, respectively.

[0079] In this embodiment, the aforementioned risk status information can be used to characterize the risk level of the controller under abnormal operating conditions. The aforementioned resource status information can be used to characterize the scheduling level of the resources required to execute tasks, and the aforementioned task status information can be used to characterize the backlog of tasks to be executed within the kernel. The aforementioned preset weight set can be a pre-calibrated ternary weight vector. The preset weight set includes preset weight information corresponding to the risk status information, task status information, and resource status information, respectively. For example, α can represent the preset weight of the risk status information, β can represent the preset weight of the resource status information, and γ can represent the preset weight of the task status information.

[0080] Optionally, the aforementioned risk status information, resource status information, and task status information can be collected through a preset controller status interface; a preset weight set in the controller's configuration file can be used to perform linear weighted summation, and the above linear weighted summation method can be expressed by the following formula.

[0081] LogWeight=α (safety_level)+β (cpu_utilization / 100)+γ (comm_queue_depth / max_queue_depth)

[0082] Here, `safety_level` represents risk status information, `cpu_utilization` represents resource status information, `comm_queue_depth` represents task status information, and `max_queue_depth` represents the maximum queue depth. The calculated result, `LogWeigh`, can be output as the log weight information for abnormal controller operation states.

[0083] In this embodiment, the above method can unify risk status, resource status, and task status into a single decision indicator (LogWeight) in a quantifiable manner, enabling the identification and priority determination of high-risk scenarios. This method overcomes the problems of misjudgment and missed judgment of log risks caused by switching different log modes using a single indicator, such as CPU load, in related technologies.

[0084] As an optional embodiment, the log set to be stored includes a third log subset and a fourth log subset. The third log subset is more important to the controller than the fourth log subset. The storage strategy includes a first storage strategy and a second storage strategy. The first storage strategy represents the rules for storing the logs to be stored in multiple cores, and the second storage strategy represents the rules for storing the logs to be stored in the same core. The storage strategy corresponding to the weight information is invoked to store the log set to be stored, including: in response to the first storage strategy, storing the third log subset in multiple cores; and in response to the second storage strategy, storing the fourth log subset in the target core.

[0085] In this embodiment, the third log subset can be used to characterize logs that are highly important to the controller, such as critical logs. The fourth log subset can be used to characterize other logs besides the critical logs, wherein the importance of the third log subset to the controller is greater than that of the fourth log subset. The first storage strategy can be used to represent the rules for storing logs to be stored in multiple cores. The second storage strategy can be used to represent the rules for storing logs to be stored in the same core. The multiple cores can include intelligent cores and real-time cores. The target core can be used to characterize a processing unit in the controller with relatively limited performance, memory, and storage space compared to intelligent cores; it can also be called a real-time core. In this embodiment, the importance of logs to the controller and the correlation between logs and abnormal operating states can be used to characterize the same situation.

[0086] Optionally, when the calculated weight information is greater than a preset threshold, such as LogWeight>0.7, the first storage policy can be triggered. In response to the storage policy being the first storage policy, the intelligent core can directly write the generated third log subset into the local secure storage area to ensure that even if the target core malfunctions or communication is interrupted, the third log subset can still be saved independently.

[0087] Optionally, when the calculated weight information is less than a preset threshold, for example, LogWeight < 0.7, a second storage strategy can be triggered; in response to the storage strategy being the second storage strategy, the fourth log subset can be stored in a unified Diagnostic Log and Trace (DLT) format; and uniformly aggregated to the target core via the controller's diagnostic log and trace gateway.

[0088] In this embodiment of the application, the above method can ensure that critical logs are stored simultaneously on both the real-time core and the intelligent core when a security event is triggered, thus avoiding the loss of critical data due to single-core anomalies or communication interruptions. When the controller is running normally, non-critical logs are uniformly sent to the real-time core for centralized storage via IPCF, reducing the storage pressure on the intelligent core and preventing the real-time core from discarding logs due to insufficient storage space. This achieves the matching of log storage with the actual operating state of the controller.

[0089] As an optional embodiment, in response to the storage policy being the second storage policy, storing the fourth log subset in the target core includes: in response to the storage policy being the second storage policy, filling the fourth log subsets of multiple cores into a preset log template to obtain a filling result; and transmitting the filling result of multiple cores to the storage space in the target core for storage through a preset gateway.

[0090] Optionally, the aforementioned preset log template can be a standardized (JavaScript Object Notation, or JSON) file template. The aforementioned population result can be used to represent a standardized message set generated after mapping and formatting the fourth log subset from the real-time core and the intelligent core according to the aforementioned preset log template. The aforementioned preset gateway can be used to represent the DLT gateway module running in the intelligent core.

[0091] Optionally, in response to the second storage strategy, the real-time core and the intelligent core each fill in the fields of their generated fourth log subset according to a preset standardized JSON file template, generating a JSON file with a consistent structure. The aforementioned JSON log messages can be sent to the intelligent core via the Inter-Processor Communication Facility (IPCF). The DLT gateway module in the intelligent core receives JSON-formatted log messages from multiple cores, performs format verification and deduplication, and finally encapsulates them into standard DLT messages. The encapsulated DLT messages can be written to a preset storage path in the target core, achieving centralized aggregation of non-critical logs. The aforementioned JSON-formatted log messages can be updated via Over-the-Air Update (OTA). OTA can download a new JSON file from the cloud to the controller, where the intelligent core verifies the signature and integrity, and the real-time core loads the new authorization and threshold, thereby achieving seamless controller switching strategies.

[0092] In this embodiment, the operating status information of the controller under abnormal operating conditions can be obtained; based on the operating status information, the weight information of the log set generated by the core during task execution is determined, and the log set to be stored is filtered based on the weight information; the storage operation is performed by calling the storage strategy corresponding to the weight information, thereby realizing the storage of the log set generated by the core during task execution. The above method can filter the log set to be stored based on the weight information and execute the corresponding storage strategy based on the weight information. Therefore, when the controller is in an abnormal operating state, the above method can call the corresponding storage strategy to prioritize the storage operation of the filtered log set to be stored. This overcomes the problem of a large number of logs other than the log set to be stored occupying the controller's buffer, thus preventing the loss of the logs to be stored. This solves the technical problem of low log storage flexibility in vehicle controllers and achieves the technical effect of improving the log storage flexibility of vehicle controllers.

[0093] The technical solutions of the embodiments of this application will be illustrated below with reference to preferred embodiments.

[0094] Currently, in automotive electronic systems, due to the increasing demands for real-time performance and high computing power in vehicles, controller solutions equipped with heterogeneous multi-core chips are becoming the mainstream of technological development. Log management is a core aspect of functional safety, especially in high-risk scenarios where system resources (such as CPU load and communication queues) become extremely strained. Traditional logging solutions, due to the specifications of the Adaptive AUTOSAR (AP AUTOSAR) and Classic AUTOSAR (CP AUTOSAR) protocol stacks, employ static strategies, leading to the loss of critical logs and seriously threatening safety and reliability.

[0095] Current technologies rely on single-metric triggering for log mode switching and logging based on log levels specified in protocol stack configuration files. These methods fail to differentiate between high-risk scenarios, such as security incidents and normal high loads (e.g., entertainment system operation). This leads to critical logs being overwritten by non-critical logs due to limited vehicle resources, resulting in their loss. Furthermore, in heterogeneous multi-core architectures, logs are managed separately in real-time cores (M-cores) and intelligent cores (A-cores), lacking a unified and collaborative log management approach and failing to fully leverage the memory space resources of intelligent cores.

[0096] This application proposes a dynamic awareness log storage mechanism for heterogeneous multi-core controllers: Security status, CPU load, and communication queue depth are collected in real-time by the M-core; weight values ​​are calculated using a linear formula; and the log strategy is dynamically switched by driving the A-core to fully capture important logs. Non-critical log information is intelligently compressed based on system load status. Finally, the log information is stored in the file system.

[0097] The embodiments of this application will be further described below.

[0098] This application discloses a log storage method for a vehicle controller. It integrates real-time core logs and intelligent core logs through a dynamic sensing mechanism, achieving highly reliable capture of important logs and intelligent compression of other non-important logs. Cross-core log information storage management is performed via IPCF inter-core communication, intelligently optimizing storage resources. The method includes: dynamic sensing of cross-core collaborative logs based on the heterogeneous multi-core system status; monitoring the real-time core operating status; periodically collecting key controller indicators through a predefined system status interface, including safety level, CPU utilization, and communication queue depth. Based on the current real-time core system operating status and software configuration file parameters, the log weight (LogWeight) is dynamically calculated.

[0099] Optionally, the real-time core transmits the dynamically calculated log weight value (LogWeight) to the intelligent core via IPCF inter-core communication, and the intelligent core dynamically adjusts the logging strategy. When LogWeight is in a high-risk state, only critical log information (such as security events, error codes, etc.) is recorded, and non-critical logs (such as debugging information during development, application runtime print logs, etc.) are intelligently compressed; when LogWeight is in a normal state, all log information is recorded.

[0100] Optionally, logs can be categorized into three levels based on a predefined rule base (e.g., "based on security-related keywords"). The three categories of logs are: critical logs (not compressed, written directly to the implementation buffer), important logs (compression rate ≤30%, retaining high-level logs such as Warning, Error and above, and retaining their key semantics), and non-important logs (compression rate ≥70%, such as debugging information for non-real-time application operation, recurring status reports, etc.).

[0101] Optionally, intelligent compression processing will detect duplicate information, compare historical logs using a hash table, and delete duplicate entries; it will also perform semantic compression encoding to transform structured logs into a lightweight format (using common numbers or initials to replace the entire log information, retaining only the key information data).

[0102] Optionally, critical logs are stored on a core-by-core basis (real-time cores store real-time logs, and intelligent cores store intelligent logs). For non-critical logs, the log formats of the real-time core and intelligent core are unified, and the logs of the two cores are collected into the pre-set log file storage space of the intelligent core through the DLT gateway according to the log modules of CP AUTOSAR and AP AUTOSAR (DLT format).

[0103] Optionally, the log-dynamic awareness strategy parameters are designed and developed using a JSON file structure, defining a standardized JSON file template that supports dynamic updates of relevant parameters. Through OTA updates, a new JSON file is downloaded from the cloud, and the real-time core and intelligent core load the weight coefficients and thresholds from the new JSON file, seamlessly switching to the new strategy without requiring a power-on restart.

[0104] In this embodiment, dynamic perception of cross-core collaborative logs is performed based on system status. By dynamically collecting important runtime parameters of heterogeneous multi-core operating systems, log information weight values ​​are calculated to select a logging strategy. Log types are classified, and different types of logs are intelligently compressed to different degrees. Key log information is stored on a core-by-core basis, while other non-key log information is transmitted across cores to intelligent cores with sufficient resources. Through OTA updates, new JSON files are downloaded from the cloud, and new weight coefficients and thresholds are loaded in real time, seamlessly switching to the new strategy.

[0105] Optionally, dynamic perception of cross-core collaborative logs is performed based on the controller state. The aforementioned controller architecture includes a real-time core (M core) and an intelligent core (A core). The real-time core deploys critical applications with high real-time requirements, such as those related to braking commands and Autonomous Emergency Braking Trigger Event (AEB) triggering events, which are crucial for vehicle functional safety. The intelligent core, due to its need to deploy applications with higher computing power, has more CPU performance and storage resources compared to the real-time core. However, when a sudden event occurs during vehicle operation, in high-risk scenarios for the controller, the limited flash and solid-state storage resources of the real-time core become a significant factor. After a safety event is triggered, the number of protocol stack tasks deployed in the real-time and intelligent cores surges, causing a sharp increase in CPU load. At this point, the generation rate of the controller's full log exceeds the storage write rate, resulting in a log buffer overflow. In severe cases, this can cause system crashes and restarts, threatening the personal safety of the vehicle's driver.

[0106] Optionally, to prevent system crashes caused by log avalanche and to enable real-time analysis of security events, this embodiment monitors the real-time kernel operating status by periodically collecting key controller indicators through the system status interface, including: security status, CPU load, and communication queue depth. The security status ranges from 0 (safe) to 1 (high risk); the CPU load ranges from 0% to 100%; and the communication queue depth ranges from 0 to the maximum depth.

[0107] Based on the current real-time system operating status and the parameters in the software configuration file, the log weight LogWeight is dynamically calculated. LogWeight can be calculated using the following formula.

[0108] LogWeight=α (safety_level)+β (cpu_utilization / 100)+γ (comm_queue_depth / max_queue_depth)

[0109] In this context, α can represent the preset weight of risk status information, β can represent the preset weight of resource status information, and γ can represent the preset weight of task status information. The preset weight of α can be 0.5, the preset weight of β can be 0.3, and the preset weight of γ can be 0.2. These can be dynamically adjusted later based on the actual working conditions through the software configuration file.

[0110] Optionally, the real-time core can transmit the dynamically calculated log weight value (LogWeight) to the intelligent core via a private protocol through IPCF inter-core communication. The intelligent core will dynamically adjust the logging strategy based on the LogWeight. If LogWeight > 0.7, the heterogeneous multi-core controller is considered to be in a high-risk state, and only critical logs (such as security events, error codes, etc.) are recorded. Simultaneously, intelligent compression is performed on the logs (including keyword filtering, duplicate log filtering, semantic compression, etc.). If LogWeight < 0.7, the heterogeneous multi-core controller is considered to be in a normal state, and the full log is recorded.

[0111] Optionally, when a multi-core heterogeneous controller is in a high-risk scenario, logs need to be compressed. The intelligent log compression strategy categorizes logs based on a predefined rule base. The three types of logs are: critical logs (not compressed, directly written to the implementation buffer), important logs (compression rate ≤30%, retaining high-level logs such as Warning, Error and above, and retaining their key semantics), and non-important logs (compression rate ≥70%, such as debugging information for non-real-time application operation, recurring status reports, etc.).

[0112] Optionally, intelligent log compression performs duplicate information detection on unimportant information by comparing historical logs with a hash table and deleting redundant entries; it performs semantic compression encoding on important and unimportant information by replacing the entire log information with common numbers or initial abbreviations, retaining only the key information data, and converting structured logs into a lightweight format.

[0113] Optionally, due to the limited memory and storage space of the real-time core, critical logs are stored on a core-by-core basis. Real-time core logs are stored in the real-time core's cache, and intelligent core logs are stored in the intelligent core's cache. For non-critical logs, log files are generated according to the log modules of CP AUTOSAR and AP AUTOSAR, and stored uniformly in the DLT format. Simultaneously, non-critical log information in the real-time core's cache is collected from both cores via a DLT gateway and stored in the intelligent core's pre-defined log file storage space.

[0114] Optionally, remote upgrades to the log dynamic awareness strategy are supported. The correlation coefficient of the log dynamic awareness strategy is designed and developed using a JSON file structure. A standardized JSON file template is defined, and the correlation coefficient in the JSON file can be adjusted according to actual needs. The adjusted JSON file is then updated via OTA. OTA sends the new JSON file from the cloud to the heterogeneous multi-core controller, where the intelligent core verifies the signature and integrity, and the real-time core loads the new rights and rewrites the threshold, thereby achieving a seamless system switch to the new strategy without requiring a power-on restart.

[0115] Optionally, the coefficient setting in the LogWeight value of the log dynamic perception strategy can be adjusted according to actual needs to achieve dynamic log perception and realize high-reliability capture of application logs; changing the log semantic compression encoding method in intelligent log compression can also enable the function of semantic compression of logs.

[0116] Figure 2 This is a flowchart illustrating the architecture of a heterogeneous multi-core dynamic sensing log system according to an embodiment of this application. Figure 2 As shown, the above-mentioned heterogeneous multi-core dynamic sensing log system architecture may include a heterogeneous multi-core controller 200, a real-time core (M core) 202, and an intelligent core (A core) 204. The real-time core (M core) 202 may include application A... Application B Applications C, D, standard middleware CP AUTOSAR 206, and status monitoring service 208 are all related to Application A. And application B For critical applications, the aforementioned standard middleware CP AUTOSAR 206 provides deterministic communication services and logging interfaces compliant with the AUTOSAR Classic specification for critical applications within the real-time core. It supports local log generation based on preset log levels (such as Error and Warning) and ensures real-time performance and functional safety requirements. The aforementioned status monitoring service 208 collects system status and calculates Log Weight. The aforementioned intelligent core (A core) 204 includes applications E, F, G, and H. The aforementioned standard middleware AP AUTOSAR 210 also includes communication management and log management. The aforementioned standard middleware AP AUTOSAR 210 provides applications within the intelligent core with asynchronous communication services based on SOA architecture, Diagnostic Log and Trace (DLT), log framework support, and cross-core log aggregation and storage management capabilities, supporting log format standardization and remote upload. The aforementioned log scheduling service 212 dynamically adjusts log policies and receives weights via IPCF.

[0117] Figure 3 This is a flowchart illustrating a high-risk scenario in a heterogeneous multi-core system according to an embodiment of this application. Figure 3 As shown, the high-risk scenarios of the above heterogeneous multi-core system include the following steps.

[0118] Step S302, security event triggered.

[0119] Optionally, if a critical application on the real-time core (M core) detects an event that endangers driving safety, it triggers the safety status flag (safety_level) to rise from 0 to 1, indicating that the system has entered the highest risk level.

[0120] Step S304: AP / CP tasks surge.

[0121] Optionally, after a security event is triggered, real-time tasks in the CP AUTOSAR protocol stack (such as braking control loop and sensor fusion) and intelligent tasks in the AP AUTOSAR protocol stack (such as camera image processing and vehicle-to-everything communication) simultaneously enter a high-load response mode, resulting in a significant increase in the task scheduling frequency on both types of cores.

[0122] In step S306, the CPU load rate spiked to 95%.

[0123] Optionally, due to the concentrated contention of CPU computing resources by a large number of concurrent tasks, the CPU load rate of the real-time core rapidly climbs to over 95% within milliseconds, increasing system scheduling latency and pushing the response capability to its limit.

[0124] Step S308: Full log generation speed > storage write speed.

[0125] Optionally, under this high load condition, all modules in the CP and AP protocol stacks (including diagnostics, communication, and application layers) continuously output full logs according to preset log levels (such as Info / Debug / Warning / Error), and the log generation rate far exceeds the write bandwidth of the Flash / NVM storage medium.

[0126] Step S310: Log buffer overflow.

[0127] Alternatively, due to the limited RAM buffer capacity of the real-time core (typically only a few KB to tens of KB), log data cannot be written to disk in a timely manner, the buffer overflows, and new log entries are overwritten by old entries, resulting in the loss of critical log information.

[0128] Step S312: The system freezes or restarts.

[0129] Optionally, log buffer overflow can further cause system resource management anomalies, with some tasks being blocked due to the inability to complete log recording, ultimately leading to real-time kernel scheduling failure, watchdog timeout, triggering controller forced reset or system freeze, seriously endangering vehicle driving safety.

[0130] Figure 4 This is a flowchart illustrating a heterogeneous multi-core log dynamic perception decision-making process according to an embodiment of this application. Figure 4 As shown, the above heterogeneous multi-core log dynamic awareness decision-making includes the following steps.

[0131] Step S402: Application launch.

[0132] Optionally, after the heterogeneous multi-core controller is powered on or reset, the operating system and core applications in the real-time core (M core) and intelligent core (A core) are initialized, the CP AUTOSAR and AP AUTOSAR protocol stacks are running normally, and the log management subsystem enters the ready state.

[0133] Step S404: Load the dynamic perception decision log file.

[0134] Optionally, the real-time core and the intelligent core load a pre-configured JSON-formatted log dynamic awareness strategy file from non-volatile storage media. This file contains coefficients α, β, and γ in the log weight calculation formula, as well as a threshold (default 0.7) for judging high-risk states, and defines a rule base for key logs. This strategy file supports signature verification and integrity verification to ensure its source is trustworthy.

[0135] Step S406: Collect key indicators of the controller.

[0136] Optionally, the real-time kernel status monitoring service (208) periodically collects system operating status parameters through a standard API interface, including: security status, CPU load rate, and communication queue depth.

[0137] Step S408: Real-time dynamic calculation of LogWeight.

[0138] Optionally, the real-time kernel dynamically calculates the log weight value based on the three key indicators collected using a preset linear weighting formula.

[0139] Step S410: Is LogWeight greater than 0.7?

[0140] Optionally, if LogWeight is 0.7, then proceed to step S414; otherwise, proceed to step S412.

[0141] Step S412: Record the full log.

[0142] Optionally, when LogWeight≤0.7, the log scheduling service (212) of the intelligent core (A core) controls the APAUTOSAR log module to record all log information in the original format (DLT standard format) to ensure that the data required for development, debugging and routine operation and maintenance is complete and traceable.

[0143] Step S414: Record only critical logs.

[0144] Optionally, based on the rule base in the JSON policy, logs containing security keywords (such as "AEB Triggered" or "Brake Command Failed") or Error level or above can be filtered out, while the remaining logs can be ignored.

[0145] Figure 5 This is a flowchart illustrating a heterogeneous multi-core log intelligent compression strategy according to an embodiment of this application. Figure 5 As shown, the above-mentioned heterogeneous multi-core log intelligent compression strategy includes the following steps.

[0146] Step S502: Obtain log information.

[0147] Optionally, the smart core obtains log message packets to be processed from the local or real-time core log buffer received via IPCF through the AP AUTOSAR DLT log framework. Each log contains structured fields such as timestamp, log level, module identifier, and text content.

[0148] Step S504: Predefine the rule base.

[0149] Optionally, the smart core loads a log classification rule base configured by a JSON policy file, which defines the criteria for judging three types of logs.

[0150] Step S506: Determine the log type.

[0151] Optionally, based on the rule base in step S504, each log entry is categorized and matched to determine if it belongs to one of the three categories: "critical log," "important log," or "non-important log." If determined to be a critical log, no compression is performed, and it directly enters the implementation buffer to ensure 100% complete recording for post-event security auditing and fault tracing. If determined to be an important log, a semantic compression process is executed, with the compression rate controlled at ≤30%, preserving its core semantics, such as retaining "Warning: CAN Bus Timeout" but omitting redundant context. If determined to be a non-important log, a deduplication detection and deep compression process is performed, with a compression rate ≥70%, or it is directly filtered and discarded.

[0152] Step S508: Record warning level or higher logs.

[0153] Optionally, as a subset of important logs, all Warning and higher level logs should be retained and participate in subsequent semantic compression to ensure that high-priority non-critical information is not lost.

[0154] Step S510: Calculate the hash value.

[0155] Optionally, for the logs to be processed (especially important and unimportant logs), a consistent hashing algorithm (such as SHA-256 or CRC32) is used to calculate the digest of the log content and generate a unique hash value for subsequent duplicate identification.

[0156] Step S512: Query the historical hash table.

[0157] Optionally, the smart core maintains a historical hash table of limited capacity to store the hash values ​​of the most recent N log entries, enabling quick retrieval of whether the current log entry has appeared before.

[0158] Step S514: Determine whether the log information is duplicated.

[0159] Optionally, if so, proceed to step S516; otherwise, proceed to step S518.

[0160] Step S516, replace with<repeat xN> Logo.

[0161] Optionally, for duplicate logs, the original text content is not stored, but instead a lightweight identifier is used to indicate "this log has appeared before, and the previous record is the 3rd duplicate", reducing storage overhead.

[0162] Step S518: Insert the new hash value.

[0163] Optionally, the hash value of the current log is inserted into the historical hash table. If the table is full, the oldest entry is overwritten using a first-in-first-out strategy to ensure that the hash table always reflects recent log behavior.

[0164] Step S520: Semantic compression encoding of log information.

[0165] Optionally, semantic-level lightweight coding can be performed on non-repeating important logs and non-important logs.

[0166] Step S522: The log is stored to the file system.

[0167] Optionally, the classified and compressed logs are uniformly packaged in the DLT standard format and written to the large-capacity non-volatile storage medium by the file system module of the intelligent core, forming a unified log file that can be parsed by remote diagnostic tools, thereby realizing centralized log management across cores and platforms.

[0168] Figure 6This is a schematic diagram of a cross-core log information storage collaborative optimization structure according to an embodiment of this application. Figure 6 As shown, the aforementioned cross-core log information storage collaborative optimization structure includes: a real-time core 600 and an intelligent core 602. The real-time core 600 may include a CP protocol stack log management module 604, a log dynamic sensing module 606, and a real-time core buffer 608. The intelligent core 602 may include an AP protocol stack log management module 610, a log dynamic sensing module 612, and an intelligent core file system 614. The real-time core buffer 608 includes real-time core critical logs and real-time core non-critical logs, while the intelligent core file system 614 includes real-time core non-critical logs and intelligent core logs. The real-time core buffer 608 and the intelligent core file system 614 communicate via a DLT gateway using DLT format messages.

[0169] Optionally, the CP protocol stack log management module 604 is used to provide a deterministic logging interface for critical applications within the real-time core (such as AEB and ESC) based on the CP AUTOSAR Classic specification. It generates standard DLT format logs according to a preset log level (Error / Warning) and directly writes critical logs to the real-time core buffer 608, ensuring low-latency and highly reliable log capture. The aforementioned log dynamic awareness 606 is deployed on the real-time core 600 and is used to periodically collect system status parameters (safety_level, cpu_utilization, comm_queue_depth), dynamically calculate the log weight value LogWeight based on a preset linear weight formula, and transmit this value to the intelligent core 602 via IPCF inter-core communication to trigger cross-core collaborative adjustments to the log policy.

[0170] Optionally, the aforementioned real-time core cache 608 is used as a temporary log buffer in the limited memory space within the real-time core. It is used to prioritize caching critical logs to prevent loss and temporarily store non-critical logs to be forwarded to the intelligent core. When LogWeight ≤ 0.7, non-critical logs can be temporarily stored. When LogWeight > 0.7, only critical logs are retained, and non-critical logs are immediately forwarded to the intelligent core 602 via the DLT gateway and the local cache is cleared, thereby realizing dynamic release of resources. The aforementioned AP protocol stack log management module 610, based on the DLT framework, provides asynchronous log recording services for applications on the intelligent core 602 (such as entertainment systems, navigation, and remote diagnostics). It supports high throughput and multi-threaded log generation, and outputs all logs (including locally generated logs) in a unified DLT standard format for integration and storage by the log scheduling service 612. The aforementioned log dynamic awareness 612 is deployed on the intelligent core 602 to receive the LogWeight value from the real-time core 600 and dynamically switch the log processing strategy according to the value: when LogWeight > 0.7, the intelligent compression mechanism is enabled, and only critical logs (from the real-time core) and important logs (from this core) are received and stored, while non-important logs are semantically compressed or discarded; when LogWeight ≤ 0.7, the full log recording mode is restored to ensure the integrity of data required for development, debugging, and operation and maintenance.

[0171] Figure 7 This is a flowchart illustrating a remote upgrade log dynamic sensing strategy according to an embodiment of this application. Figure 7 As shown, the above-mentioned heterogeneous multi-core log intelligent compression strategy includes the following steps.

[0172] Step S702, OTA server.

[0173] Optionally, an Over-The-Air (OTA) platform deployed by the vehicle manufacturer or service provider is used to manage and release updated versions of the log dynamic awareness policy. This server stores a digitally signed, verified, and encrypted log_policy.json configuration file, which contains parameters such as log weight calculation coefficients (α, β, γ), high-risk thresholds, a key log keyword rule base, and compression rate strategies, supporting version number management and canary releases.

[0174] Step S704: Activate the log_policy.json configuration.

[0175] Optionally, the OTA server may selectively push a new log_policy.json file to the target ECU (Electronic Control Unit) based on the vehicle model, software version, operating conditions, or safety event feedback. This file is transmitted through an encrypted channel and includes a digital signature and integrity verification value to ensure that the data source is trustworthy and the content is not tampered with.

[0176] Step S706, ECU storage partitioning.

[0177] Optionally, after receiving a new policy file, the ECU writes it to a separate non-volatile update partition, isolated from the currently running "active partition," to prevent system crashes due to update failures. The writing process includes security checks such as signature verification, file integrity verification, and version number comparison. Once the verification passes, it is marked as "pending activation."

[0178] Step S708, Real-time kernel log scheduling service.

[0179] Optionally, the log scheduling service deployed on the real-time core (M core) continuously monitors and updates the partition status. When a new version of log_policy.json is detected to have passed security verification and been marked as "pending activation", the service triggers a hot reload mechanism, starting the asynchronous reading process of the configuration file without interrupting real-time task scheduling.

[0180] Step S710: Load the configuration file in real time.

[0181] Optionally, the log scheduling service loads the new policy file from the update partition into memory and parses the parameters such as weight coefficients, thresholds, and keyword rules to replace the original runtime configuration. This process ensures system stability during loading through atomic operations and memory snapshot mechanisms, preventing race conditions or data inconsistencies.

[0182] Step S712: Dynamically adjust the logging strategy.

[0183] Optionally, after loading is complete, the log scheduling service immediately broadcasts a "policy update complete" signal to the corresponding module of the intelligent core (A core), and both parties switch to the new policy synchronously.

[0184] Figure 8 This is a schematic diagram of a vehicle controller according to an embodiment of this application. Figure 8 As shown, the vehicle controller 800 includes a real-time core 802 and an intelligent core 804. The real-time core 802 is used to: respond to an abnormal operating state of the controller by acquiring the controller's operating status information during that abnormal state; and based on the operating status information, determine the weight information of the log sets generated by the real-time core and the intelligent core during task execution, wherein the weight information represents the degree of correlation between the logs in the log set and the abnormal operating state. The intelligent core 804 is used to: determine the log set to be stored based on the weight information and the log set; and invoke the storage strategy corresponding to the weight information to store the log set to be stored, wherein the storage strategy represents the rules for storing the logs in the log set to be stored.

[0185] Figure 9This is a schematic diagram of a log storage device for a controller in a vehicle according to an embodiment of this application. Figure 9 As shown, the log storage device 900 of the controller in the vehicle includes: an acquisition unit 902, a first determination unit 904, a second determination unit 906, and a storage unit 908. The acquisition unit 902 is used to acquire the operating status information of the controller in the abnormal operating state in response to the controller being in an abnormal operating state. The first determination unit 904 is used to determine the weight information of the log set generated by the kernel during the execution of the task based on the operating status information, wherein the weight information is used to represent the degree of correlation between the logs in the log set and the abnormal operating state. The second determination unit 906 is used to determine the log set to be stored of the kernel based on the weight information and the log set. The storage unit 908 is used to call the storage strategy corresponding to the weight information to store the log set to be stored, wherein the storage strategy is used to represent the rules for storing the logs in the log set to be stored.

[0186] In this embodiment, the acquisition unit 902 acquires the controller's operating status information in response to the controller being in an abnormal operating state. The first determination unit 904 determines the weight information of the log set generated by the core during task execution based on the operating status information, where the weight information represents the degree of correlation between the logs in the log set and the abnormal operating state. The second determination unit 906 determines the core's log set to be stored based on the weight information and the log set. The storage unit 908 calls the storage strategy corresponding to the weight information to store the log set to be stored, where the storage strategy represents the rules for storing the logs in the log set to be stored. This solves the technical problem of low log storage flexibility in vehicle controllers and achieves the technical effect of improving the log storage flexibility of vehicle controllers.

[0187] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0188] The units described as separate components may or may not be physically separate. 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0189] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, ROM, RAM, portable hard drives, magnetic disks, or optical disks.

[0190] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for storing logs of a controller in a vehicle, characterized in that, The controller includes multiple cores, with different cores used to perform different tasks of the vehicle, and the method includes: In response to the controller being in an abnormal operating state, obtain the operating status information of the controller in the abnormal operating state; Based on the running status information, the weight information of the log set generated by the kernel during the execution of the task is determined, wherein the weight information is used to represent the degree of correlation between the logs in the log set and the abnormal running status; Based on the weight information and the log set, determine the log set to be stored for the core; The storage strategy corresponding to the weight information is invoked to store the log set to be stored, wherein the storage strategy is used to represent the rules for storing the logs in the log set to be stored.

2. The method according to claim 1, characterized in that, Based on the weight information and the log set, the log set to be stored is determined, including: In response to the weight information being greater than the weight threshold, the first log subset in the log set is determined as the log set to be stored, wherein the correlation between the logs in the first log subset and the abnormal operating state is greater than the correlation between the logs in the log set other than the first log subset and the abnormal operating state. In response to the weight information being less than the weight threshold, the log set is determined as the log set to be stored.

3. The method according to claim 2, characterized in that, The second subset of logs in the log set includes logs in the log set other than the first subset of logs, and the method further includes: Based on the status keywords of the abnormal operating state, the type of logs in the second log subset is determined, wherein the number of status keywords contained in logs of different types is different; The compression strategy corresponding to the type of the logs in the second log subset is invoked to compress the logs in the second log subset, wherein the compression strategy is used to represent the rules for compressing the logs in the second log subset.

4. The method according to claim 3, characterized in that, The types include a first type and a second type. The logs of the first type are more important to the controller than the logs of the second type. A compression strategy corresponding to the type of logs in the second log subset is invoked to compress the logs in the second log subset, including: Invoke the compression strategy corresponding to the first type to compress the logs of the first type in the second log subset; The compression strategy corresponding to the second type is invoked to compress the logs of the second type in the second log subset, wherein the compression degree of the logs after compression by invoking the compression strategy corresponding to the first type is less than the compression degree of the logs after compression by invoking the compression strategy corresponding to the second type.

5. The method according to claim 1, characterized in that, The operational status information includes risk status information, resource status information, and task status information. The risk status information indicates the risk level of the controller under abnormal operational conditions. The resource status information indicates the scheduling level of the resources required to execute the task. The task status information indicates the backlog of tasks to be executed within the kernel. Based on the operational status information, the weight information of the log set generated by the kernel during the execution of the task is determined, including: Using a preset weight set in the controller's configuration file, the risk status information, the task status information, and the resource status information are weighted and averaged to obtain the weight information. The preset weight set includes preset weight information corresponding to the risk status information, the task status information, and the resource status information, respectively.

6. The method according to claim 5, characterized in that, The log set to be stored includes a third log subset and a fourth log subset. The third log subset is more important to the controller than the fourth log subset. The storage strategy includes a first storage strategy and a second storage strategy. The first storage strategy represents the rules for storing the logs to be stored in multiple cores, and the second storage strategy represents the rules for storing the logs to be stored in the same core. The storage strategy corresponding to the weight information is invoked to store the log set to be stored, including: In response to the storage policy being the first storage policy, the third log subset is stored in multiple cores respectively; In response to the storage policy being the second storage policy, the fourth log subset is stored in the target core.

7. The method according to claim 6, characterized in that, In response to the storage policy being the second storage policy, storing the fourth log subset in the target core includes: In response to the storage strategy being the second storage strategy, the fourth log subset of the multiple cores is filled into a preset log template to obtain a filling result; The filling results of multiple cores are transmitted to the storage space in the target core for storage via a preset gateway.

8. A vehicle controller, characterized in that, The controller includes a real-time core and an intelligent core, wherein... The real-time core is used to respond to the controller being in an abnormal operating state, to obtain the operating state information of the controller in the abnormal operating state; based on the operating state information, to determine the weight information of the log sets generated by the real-time core and the intelligent core during the execution of the task, wherein the weight information is used to represent the degree of correlation between the logs in the log set and the abnormal operating state; The intelligent core is used to determine the log set to be stored based on the weight information and the log set; and to call the storage strategy corresponding to the weight information to store the log set to be stored, wherein the storage strategy is used to represent the rules for storing the logs in the log set to be stored.

9. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 7.

10. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 7.

Images