A fault frame processing method and device, electronic equipment and vehicle

Abstract

This application provides a method, apparatus, electronic device, and vehicle for processing fault frames. The method involves acquiring fault frames from a first operating system, each fault frame having a corresponding fault frame length; sending the fault frames from the first operating system to a second operating system; determining a target storage file corresponding to the fault frames in the file system of the second operating system, the storable data volume of the target storage file being determined based on the lengths of historical fault frames; and storing the fault frames in the target storage file. This application allows for a larger total number of storable fault frames, resulting in richer stored fault frame content. Early fault frames are less likely to be overwritten by subsequent fault frames, thus extending the retention time of fault frames and facilitating fault analysis. Furthermore, this application allows for writing fault frames to the corresponding target storage file based on their actual length, avoiding wasted storage space and improving the domain controller's storage capacity for fault frames.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and vehicle for processing fault frames. Background Technology

[0002] Currently, the mainstream solution for storing fault frames in domain controllers is primarily based on the AUTOSAR CP protocol stack. Specifically, the domain controller runs two operating systems: the first operating system deploys the AUTOSAR CP protocol stack and uses limited-capacity NOR Flash memory for fault frame storage; the second operating system deploys the AUTOSAR AP protocol stack. In the first operating system, fault frames generated by multiple applications have inconsistent lengths. The system unifies them according to the maximum fault frame length, allocating several fixed-size storage spaces in the NOR Flash memory. Fault frames from all applications are cyclically written to these shared storage spaces.

[0003] Existing fault frame storage solutions have the following problems. First, storage space utilization is low, as even short fault frames require a fixed amount of storage space. Second, due to the limited storage capacity of NOR Flash, the total number of fault frame entries that can be stored is limited, and the length of each fault frame is also constrained. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and vehicle for processing fault frames, aiming to solve or partially solve the above-mentioned technical problems.

[0005] To address the aforementioned problems, this application discloses a method for processing fault frames, applied to a domain controller in a vehicle. The domain controller includes a first operating system and a second operating system, which are communicatively connected. The maximum storage capacity supported by the first operating system is less than the maximum storage capacity supported by the second operating system. The second operating system is configured with a memory including a file system. The method includes: Obtain the fault frame of the first operating system, wherein the fault frame has a corresponding fault frame length; The fault frame is sent from the first operating system to the second operating system; In the file system of the second operating system, the target storage file corresponding to the fault frame is determined, and the amount of data that can be stored in the target storage file is determined according to the length of the historical fault frame; The fault frame is stored in the target storage file.

[0006] In this embodiment, fault frames from a first operating system are acquired, each fault frame having a corresponding fault frame length. The fault frames are then sent from the first operating system to a second operating system. A target storage file corresponding to the fault frame is determined in the file system of the second operating system, and the storable data volume of the target storage file is determined based on the historical fault frame lengths. The fault frame is then stored in the target storage file. This embodiment utilizes a storage device containing a file system within the second operating system for fault frame storage. Since the capacity of this storage device is larger than that of the first operating system, it can store a greater total number of fault frames, typically accommodating all fault frames generated by the first operating system, resulting in richer stored fault frame content. Furthermore, due to the larger capacity of the second operating system's file system storage, early fault frames are less likely to be overwritten by subsequent fault frames, thus extending the retention time of fault frames. This facilitates fault analysis and solves the problems of limited storable fault frame entries and limited single fault frame length caused by the small storage capacity of NOR Flash in the prior art. In addition, in this embodiment, the storable data volume of each target storage file within the file system is determined based on the historical fault frame lengths. When storing fault frames, the corresponding target storage file can be written according to the actual length of each fault frame, avoiding waste of storage space. This solves the problem of low utilization of fault data storage space in existing domain controllers and improves the storage capacity of domain controllers for fault frames.

[0007] Optionally, the first operating system has an application deployed thereon. Before determining the target storage file corresponding to the fault frame in the file system of the second operating system, the method includes: Check if the storage file corresponding to the application exists in the file system; If the file system does not contain a storage file corresponding to the application, then a new storage file corresponding to the application is created.

[0008] In this embodiment, each application uses an independent storage file to store the corresponding fault frames. The storage of fault frames of each application does not interfere with each other, and the fault frames of other applications will not be lost due to frequent failures of one application. This extends the retention time of fault frames of different applications, which is beneficial for fault analysis.

[0009] Optionally, the newly created storage file corresponding to the application includes: Obtain the historical failure frequency and failure frame storage duration of the application; The amount of storable data in the storage file corresponding to the application is determined based on the length of the historical fault frames corresponding to the application, the frequency of the historical fault occurrence, and the storage duration of the fault frames. Create a new storage file corresponding to the application based on the amount of data that the storage file corresponding to the application can store.

[0010] In this embodiment, for each application, the amount of data that can be stored in the storage file corresponding to the application is determined based on the length of the historical fault frame, the frequency of historical fault occurrence, and the storage duration of the fault frame. Thus, when each application stores fault frames, it can write them into the corresponding storage file according to the length of each single fault frame, avoiding waste of storage space.

[0011] Optionally, determining the target storage file corresponding to the fault frame in the file system of the second operating system includes: The fault frame is parsed to obtain the target application corresponding to the fault frame; Based on the target application corresponding to the fault frame, the target storage file corresponding to the fault frame and the amount of storable data in the target storage file are determined in the file system.

[0012] In this embodiment, each application uses an independent storage file to store the corresponding fault frame. The target storage file corresponding to the fault frame is determined by parsing the fault frame, thereby ensuring that the fault frame storage of each application does not interfere with each other, which is beneficial for subsequent fault analysis.

[0013] Optionally, before storing the fault frame in the target storage file, the method includes: Determine whether the amount of data currently stored in the target storage file has reached the storable data capacity of the target storage file; If the amount of data currently stored in the target storage file reaches the amount of data that the target storage file can store, then the data with the earliest storage time in the target storage file is determined and the data with the earliest storage time is selected as the data to be deleted. Delete the data to be deleted from the target storage file.

[0014] In this embodiment of the application, when the target storage file has reached its storage limit, the earliest stored fault frame in the target storage file can be deleted. Since each application uses an independent storage file to store the corresponding fault frame, the storage of fault frames of each application does not interfere with each other. Therefore, under normal circumstances, the storage time of the early stored fault frames in the target storage file can be longer than that of the prior art, which facilitates the storage of fault frames and the analysis of subsequent faults.

[0015] Optionally, obtaining the fault frame of the first operating system includes: When the application in the first operating system malfunctions, the fault frame corresponding to the application is obtained.

[0016] In this embodiment of the application, when an application in the first operating system malfunctions, the corresponding fault frame is stored and subsequently transmitted to the second operating system for storage.

[0017] Optionally, the first operating system includes a first data exchange component, and the second operating system includes a second data exchange component; the first operating system and the second operating system communicate with each other through the first data exchange component and the second data exchange component.

[0018] The embodiments of this application realize the communication connection between the first operating system and the second operating system through the first data exchange component and the second data exchange component, so that the first operating system can subsequently transmit the fault frame to the second operating system for storage.

[0019] This application also discloses a fault frame processing device applied to a domain controller in a vehicle. The domain controller includes a first operating system and a second operating system, which are communicatively connected. The maximum storage capacity supported by the first operating system is less than the maximum storage capacity supported by the second operating system. The second operating system is configured with a memory including a file system. The device includes: The fault frame acquisition module is used to acquire fault frames of the first operating system, wherein the fault frame has a corresponding fault frame length; A fault frame sending module is used to send the fault frame from the first operating system to the second operating system; The storage file determination module is used to determine the target storage file corresponding to the fault frame in the file system of the second operating system, wherein the amount of data that can be stored in the target storage file is determined according to the length of the historical fault frame. The fault frame storage module is used to store the fault frame in the target storage file.

[0020] This application also discloses an electronic device, including a processor and a memory, wherein the memory is used to store computer programs; the processor is used to execute the programs stored in the memory to implement the fault frame processing method as described in one or more of the embodiments of this application.

[0021] This application also discloses a vehicle that includes electronic devices as described in the embodiments of this application. Attached Figure Description

[0022] Figure 1 This is a system architecture diagram of the related technology of the fault frame processing method provided in one embodiment of this application; Figure 2 This is a flowchart of a method for processing fault frames according to an embodiment of this application; Figure 3 This is a system architecture diagram of a fault frame processing method provided in an embodiment of this application; Figure 4 This is a structural diagram of the fault frame processing apparatus provided in the embodiments of this application; Figure 5 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0023] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] Currently, the mainstream solution for storing fault frames in vehicle domain controllers is primarily based on the AUTOSAR CP (Automotive Open System Architecture Classic Platform) protocol stack. Specifically, the domain controller runs two operating systems: the first operating system deploys the AUTOSAR CP protocol stack, using a small-capacity NOR Flash memory (a type of non-volatile memory) for fault frame storage, and its supported RAM is limited; the second operating system deploys the AUTOSAR AP (Automotive Open System Architecture Adaptive Platform) protocol stack, which can use larger-capacity memory such as EMMC (Embedded Multi Media Card) for data storage, and its supported RAM is larger. In the first operating system, fault frames generated by multiple applications have inconsistent lengths. The system unifies them according to the maximum fault frame length, allocating several fixed-size storage spaces in the NOR Flash. Fault frames from all applications are cyclically written to these shared storage spaces.

[0025] Specifically, refer to Figure 1 This is a system architecture diagram of the related technology of the fault frame processing method provided in an embodiment of this application.

[0026] like Figure 1 As shown, the domain controller includes two operating systems. The first operating system is SYS1, which hosts multiple applications such as APP1, APP2, and APP3. SYS1 uses NOR Flash memory. The second operating system is SYS2, which uses eMMC memory. SYS1 and SYS2 communicate with each other through a first data exchange component (APP_SYS1) and a second data exchange component (APP_SYS2).

[0027] When APP1, APP2, and APP3 on SYS1 detect a fault, the fault frame Snap_Data_APP1 (assuming a length of 10 bytes) for APP1, the fault frame Snap_Data_APP2 (assuming a length of 100 bytes) for APP2, and the fault frame Snap_Data_APP3 (assuming a length of 1000 bytes) for APP3 need to be stored respectively.

[0028] Based on Snap_Data_APP1 (10 bytes), Snap_Data_APP2 (100 bytes), and Snap_Data_APP3 (1000 bytes), SYS1 calculates that the length of a single fault frame in memory should be defined as 1000 bytes. In other words, the length of the longest fault frame generated by all applications is defined as the length of a single fault frame in memory. SYS1 allocates n fault frame storage spaces in the NOR Flash memory, each with a fixed length of 1000 bytes, numbered #1-#n.

[0029] When APP1 detects a fault and needs to record a fault frame, SYS1 sequentially checks if storage spaces #1-#n are free. For example, if #2 is free, it records Snap_Data_APP1 (10 bytes long) in storage space #2 (allocated to 1000 bytes). When all n storage spaces are full, SYS1 will clear the storage spaces in the order of #1-#N and then record Snap_Data_APP1 (10 bytes long) in the cleared storage space. For example, when all storage spaces are full, Snap_Data_APP1 is stored in #1, overwriting the old data in #1. When a second new fault frame is received, it is overwritten and stored in #2, and so on. Fault data for APP2 and APP3 are stored in the same way. That is, APP1, APP2, and APP3 share the same storage space, and fault frames from all applications are cyclically written to these shared storage spaces.

[0030] However, existing fault frame storage schemes have the following problems. First, although the lengths of Snap_Data_APP1 (10 bytes), Snap_Data_APP2 (100 bytes), and Snap_Data_APP3 (1000 bytes) are different, they all require storage in a fixed 1000 bytes of space each time. This results in low storage space utilization for fault frames in Snap_Data_APP1 (10 bytes) and Snap_Data_APP2 (100 bytes). Second, since Snap_Data_APP1 (10 bytes), Snap_Data_APP2 (100 bytes), and Snap_Data_APP3 (1000 bytes) share the same space, if APP1 fails frequently, earlier fault frames in APP2 and APP3 will be overwritten, hindering fault analysis of APP2 and APP3. Furthermore, SYS1 uses NOR Flash memory for storage. NOR Flash memory itself is only in the MB range, with a relatively small capacity. This limits the total number of fault frames that can be allocated for storage, and the length of each individual fault frame is also very limited. The limited number of allocable fault frames results in short retention times and high overwriting frequency. It's possible that when a problem is discovered and fault data is retrieved, the fault data from the period in which the problem occurred has already been refreshed and overwritten, rendering it unusable. The limited length of each individual fault frame results in a small amount of fault information that can be recorded, making it difficult to further pinpoint the problem, leading to low fault frame utilization.

[0031] Therefore, this application provides a method for processing fault frames, applied to a domain controller in a vehicle. The domain controller includes a first operating system and a second operating system, which are communicatively connected. The maximum storage capacity supported by the first operating system is less than the maximum storage capacity supported by the second operating system. The second operating system is configured with a memory including a file system. The method includes: acquiring fault frames from the first operating system, wherein each fault frame has a corresponding fault frame length; sending the fault frame from the first operating system to the second operating system; determining a target storage file corresponding to the fault frame in the file system of the second operating system, wherein the storable data volume of the target storage file is determined based on the historical fault frame lengths; and storing the fault frame in the target storage file.

[0032] This application embodiment uses a memory containing a file system within a second operating system for fault frame storage. Since this memory has a larger capacity than the storage space of the first operating system, it can store a greater total number of fault frames, typically accommodating all fault frames generated by the first operating system, resulting in richer stored fault frame content. Simultaneously, due to the larger capacity of the second operating system's file system memory, early fault frames are less likely to be overwritten by subsequent fault frames, thus extending the retention time of fault frames. This is beneficial for fault analysis and solves the problems of limited number of fault frame entries and limited length of individual fault frames caused by the small storage capacity of NOR Flash in existing technologies. Furthermore, in this application embodiment, the storable data volume of each target storage file within the file system is determined based on the length of historical fault frames. During fault frame storage, the corresponding target storage file can be written according to the actual length of each fault frame, avoiding wasted storage space. This solves the problem of low utilization of fault data storage space in existing domain controllers and improves the domain controller's fault frame storage capacity.

[0033] Example 1 This application provides a method for processing fault frames. Please refer to the following embodiments. Figure 2 This includes the following steps: S210: Obtain the fault frame of the first operating system, wherein the fault frame has a corresponding fault frame length.

[0034] The fault frame processing method shown in this application is applied to a domain controller on a vehicle. The domain controller includes a first operating system and a second operating system. In one embodiment, the first operating system deploys an AUTOSAR CP protocol stack and uses a small-capacity memory, such as NOR Flash memory; the second operating system deploys an AUTOSAR AP protocol stack and is configured with a memory including a file system, such as a large-capacity memory like EMMC, for data storage.

[0035] The first and second operating systems communicate with each other, and the maximum storage capacity supported by the first operating system is less than that supported by the second operating system. Specifically, because the first operating system generates less data and has less RAM, mounting a large-capacity storage device or expanding the existing storage device would increase costs and could even cause the first operating system to lag or become unusable. On the other hand, the second operating system supports more RAM and generates more data during operation; therefore, the maximum storage capacity supported by the first operating system is less than that supported by the second operating system.

[0036] In step S210, fault frames generated by the first operating system are acquired. Each fault frame has a corresponding fault frame length, which may be 10 bytes, 100 bytes, or 1000 bytes. The fault frames are used to record fault information generated by applications in the first operating system, and include fault data, the source of the fault data, and other information.

[0037] S220: Send the fault frame from the first operating system to the second operating system.

[0038] In step S220, the fault frames generated by the first operating system are sent from the first operating system to the second operating system for storage. That is, in this embodiment, the memory corresponding to the first operating system is not responsible for storing the fault frames generated by the first operating system, but is stored by the memory corresponding to the second operating system, which has a larger capacity.

[0039] S230: Determine the target storage file corresponding to the fault frame in the file system of the second operating system, wherein the amount of data that can be stored in the target storage file is determined according to the length of the historical fault frame.

[0040] In step S230, after receiving the fault frame, the second operating system determines the target storage file corresponding to the fault frame in its own memory file system.

[0041] Since the memory corresponding to the second operating system is a memory with a file system, different storage files can be partitioned within the second operating system to store different types of fault frames. The amount of data that can be stored in each storage file is determined based on the historical fault frame lengths of the corresponding type of fault frame, thereby improving storage space utilization and avoiding waste. For example, if the historical fault frame lengths of a certain type of fault frame are all 10 bytes, then storage files with corresponding storable data sizes can be partitioned based on these 10-byte historical fault frame lengths. When the second operating system receives a fault frame of that type with a length of 10 bytes, it can store that fault frame in the corresponding storage file.

[0042] S240: Store the fault frame in the target storage file.

[0043] In step S240, after determining the target storage file corresponding to the fault frame, the fault frame is stored in the target storage file for subsequent fault data analysis, fault location, fault resolution and other operations.

[0044] This application embodiment uses a memory containing a file system within a second operating system for fault frame storage. Since this memory has a larger capacity than the storage space of the first operating system, it can store a greater total number of fault frames, typically accommodating all fault frames generated by the first operating system, resulting in richer stored fault frame content. Simultaneously, due to the larger capacity of the second operating system's file system memory, early fault frames are less likely to be overwritten by subsequent fault frames, thus extending the retention time of fault frames. This is beneficial for fault analysis and solves the problems of limited number of fault frame entries and limited length of individual fault frames caused by the small storage capacity of NOR Flash in existing technologies. Furthermore, in this application embodiment, the storable data volume of each target storage file within the file system is determined based on the length of historical fault frames. During fault frame storage, the corresponding target storage file can be written according to the actual length of each fault frame, avoiding wasted storage space. This solves the problem of low utilization of fault data storage space in existing domain controllers and improves the domain controller's fault frame storage capacity.

[0045] Optionally, obtaining the fault frame of the first operating system includes: When the application in the first operating system malfunctions, the fault frame corresponding to the application is obtained.

[0046] In this embodiment, several applications are deployed on the first operating system. When an application in the first operating system malfunctions, the corresponding fault frame is obtained. Different applications may generate different types of fault frames, and the length of the fault frames generated by different applications may also be different. Furthermore, the length of each fault frame for each application may also be different.

[0047] In practical applications, the first operating system's applications control specific functions on the vehicle, such as windshield wipers and headlights. When hardware faults such as short circuits or ground faults occur in the outputs of the headlights or windshield wipers, fault data is recorded, thereby generating corresponding fault frames.

[0048] For example, if the applications deployed on the first operating system include APP1, APP2, and APP3, when APP1 fails, a fault frame Snap_Data_APP1 with a length of 10 bytes can be collected; when APP2 fails, a fault frame Snap_Data_APP2 with a length of 100 bytes can be collected; and when APP3 fails, a fault frame Snap_Data_APP3 with a length of 1000 bytes can be collected. These fault frames will then be sent to the second operating system for storage.

[0049] The specific fault frame length values ​​involved in the embodiments of this application are for illustrative purposes only. In reality, the fault frame length generated by the application should be determined according to the actual situation.

[0050] In this embodiment of the application, when an application in the first operating system malfunctions, the corresponding fault frame is stored and subsequently transmitted to the second operating system for storage.

[0051] Optionally, the first operating system includes a first data exchange component, and the second operating system includes a second data exchange component; the first operating system and the second operating system communicate with each other through the first data exchange component and the second data exchange component.

[0052] In this embodiment of the application, the first operating system includes a first data exchange component, the second operating system includes a second data exchange component, and the communication connection between the first operating system and the second operating system is realized through the first data exchange component and the second data exchange component.

[0053] Specifically, when an application in the first operating system generates a fault frame, the first operating system sends the fault frame to the second data exchange component through the first data exchange component, and the second operating system receives the fault frame through the second data exchange component. For example, fault frames Snap_Data_APP1 generated by APP1, Snap_Data_APP2 generated by APP2, and Snap_Data_APP3 generated by APP3 in the first operating system can all be sent to the second data exchange component on the second operating system through the first data exchange component.

[0054] In one embodiment, the data exchange between the first operating system and the second operating system via the first data exchange component and the second data exchange component may also include other types of data, and is not limited to the transmission of fault frames.

[0055] The embodiments of this application realize the communication connection between the first operating system and the second operating system through the first data exchange component and the second data exchange component, so that the first operating system can subsequently transmit the fault frame to the second operating system for storage.

[0056] Optionally, the first operating system has an application deployed thereon. Before determining the target storage file corresponding to the fault frame in the file system of the second operating system, the method includes: Check if the storage file corresponding to the application exists in the file system; If the file system does not contain a storage file corresponding to the application, then a new storage file corresponding to the application is created.

[0057] In this embodiment of the application, corresponding storage files can be created for different applications in the second operating system, thereby enabling independent management of fault frames of different applications.

[0058] Specifically, the second data exchange component can perform the step of creating the storage file corresponding to the application. When the application in the second data exchange component starts, it checks whether a storage file corresponding to each application has already been created under the preset fault frame storage path. If it is found that an application of the first operating system does not have a corresponding storage file under the fault frame storage path, then a new storage file corresponding to the application is created.

[0059] In one example, the second data exchange component is APP_SYS2. APP_SYS2 has a management table APP_FILE_PATH that manages the file paths of the storage files corresponding to each application. APP_SYS2 can manage the write file paths of different application fault frames according to the definition of APP_FILE_PATH.

[0060] If the applications deployed on the first operating system include APP1, APP2, and APP3, then APP_FILE_PATH can be represented as follows: APP_FILE_PATH{ APP1: DATA / APP1_FILE / APP1.JSON APP2: DATA / APP2_FILE / APP2.JSON APP3: DATA / APP3_FILE / APP3.JSON } For example, when APP_SYS2 starts, it checks if an APP1.JSON file exists in the DATA / APP1_FILE / path. The APP1.JSON file is the storage file for APP1 fault frames. If it doesn't exist, it's created via software commands. If APP1.JSON exists, no action is taken. Similarly, the APP2.JSON and APP3.JSON files follow the same processing procedure.

[0061] In this embodiment, each application uses an independent storage file to store the corresponding fault frames. The storage of fault frames of each application does not interfere with each other, and the fault frames of other applications will not be lost due to frequent failures of one application. This extends the retention time of fault frames of different applications, which is beneficial for fault analysis.

[0062] Optionally, the newly created storage file corresponding to the application includes: Obtain the historical failure frequency and failure frame storage duration of the application; The amount of storable data in the storage file corresponding to the application is determined based on the length of the historical fault frames corresponding to the application, the frequency of the historical fault occurrence, and the storage duration of the fault frames. Create a new storage file corresponding to the application based on the amount of data that the storage file corresponding to the application can store.

[0063] In this embodiment of the application, the amount of storable data in the storage file corresponding to each application can be determined based on the length of the historical fault frame, the frequency of historical fault occurrence, and the expected storage duration of the fault frame corresponding to each application.

[0064] Specifically, for each application, the historical fault frame length and historical fault occurrence frequency for that application are obtained. The historical fault frame length can be obtained by statistically analyzing the historical fault frame lengths generated by that application, and the historical fault occurrence frequency can be obtained by statistically analyzing the historical fault frequency of that application. The specific value of the fault frame storage duration can be set as needed, and this application does not impose any restrictions on it.

[0065] For example, the second data exchange component APP_SYS2 can define the storable data volume of the storage file corresponding to each application based on the APP1 fault frame Snap_Data_APP1 (the statistically obtained historical fault frame length is 10 bytes), the APP2 fault frame Snap_Data_APP2 (the statistically obtained historical fault frame length is 100 bytes), the APP3 fault frame Snap_Data_APP3 (the statistically obtained historical fault frame length is 1000 bytes), and the historical fault occurrence frequency and expected fault frame storage duration of each application. This storable data volume is managed by APP_FILE_LIMIT. APP_FILE_LIMIT is a management table used by APP_SYS2 to manage the storable data volume of the storage files corresponding to each application.

[0066] If the applications deployed on the first operating system include APP1, APP2, and APP3, then APP_FILE_LIMIT can be represented as follows: APP_FILE_LIMIT{ APP1.JSON: xKB APP2.JSON: yKB APP3.JSON: zKB } For example, if APP3 expects fault data to be stored for one month, and the historical data of APP3 shows that a fault occurs at most once per day, then the maximum size of APP3.JSON can be designed to be 30KB. The maximum size of APP1.JSON and APP2.JSON is calculated in the same way.

[0067] In this embodiment, for each application, the amount of data that can be stored in the storage file corresponding to the application is determined based on the length of the historical fault frame, the frequency of historical fault occurrence, and the storage duration of the fault frame. Thus, when each application stores fault frames, it can write them into the corresponding storage file according to the length of each single fault frame, avoiding waste of storage space.

[0068] Optionally, determining the target storage file corresponding to the fault frame in the file system of the second operating system includes: The fault frame is parsed to obtain the target application corresponding to the fault frame; Based on the target application corresponding to the fault frame, the target storage file corresponding to the fault frame and the amount of storable data in the target storage file are determined in the file system.

[0069] In this embodiment of the application, when the second data exchange component of the second operating system receives a fault frame sent by the first data exchange component, it parses the fault frame to determine the application corresponding to the fault frame, thereby determining the target storage file corresponding to the fault frame and the amount of storable data in the target storage file. Based on the amount of storable data corresponding to the target storage file, it can be determined whether the fault frame can be stored directly or whether earlier data needs to be deleted before storing the fault frame.

[0070] In one example, the first data exchange component and the second data exchange component communicate according to the following convention format, where DATA_FORMAT_FOR_SYS1_SYS2 is the format definition for data interaction between the two operating systems.

[0071] DATA_FORMAT_FOR_SYS1_SYS2{ APP: Application Name (APP1 / APP2 / APP3) DATA: Data content (Snap_Data_APP1 / Snap_Data_APP2 / Snap_Data_APP3) } The DATA_FORMAT_FOR_SYS1_SYS2 field can include the DATA_FORMAT_FOR_SYS1_SYS2.APP field and the DATA_FORMAT_FOR_SYS1_SYS2.DATA field. DATA_FORMAT_FOR_SYS1_SYS2.APP represents which application on the first operating system the fault data exchanged between the two operating systems belongs to, while DATA_FORMAT_FOR_SYS1_SYS2.DATA represents the fault data itself exchanged between the two operating systems.

[0072] When the second data exchange component receives a fault frame sent by the first data exchange component, it parses the data according to the DATA_FORMAT_FOR_SYS1_SYS2 format. Based on the first field of DATA_FORMAT_FOR_SYS1_SYS2 (i.e., DATA_FORMAT_FOR_SYS1_SYS2.APP), it identifies which application the fault frame belongs to, specifically APP1, APP2, or APP3. Using APP_FILE_PATH, it determines that the fault frame should be stored in DATA / APP1_FILE / APP1.JSON, APP2: DATA / APP2_FILE / APP2.JSON, or APP3: DATA / APP3_FILE / APP3.JSON. Finally, it uses APP_FILE_LIMIT to determine the storable data size of the corresponding storage file for this fault frame, which is xKB, yKB, or zKB.

[0073] In this embodiment, each application uses an independent storage file to store the corresponding fault frame. The target storage file corresponding to the fault frame is determined by parsing the fault frame, thereby ensuring that the fault frame storage of each application does not interfere with each other, which is beneficial for subsequent fault analysis.

[0074] Optionally, before storing the fault frame in the target storage file, the method includes: Determine whether the amount of data currently stored in the target storage file has reached the storable data capacity of the target storage file; If the amount of data currently stored in the target storage file reaches the amount of data that the target storage file can store, then the data with the earliest storage time in the target storage file is determined and the data with the earliest storage time is selected as the data to be deleted. Delete the data to be deleted from the target storage file.

[0075] In this embodiment, before storing a fault frame into the corresponding target storage file, it is determined whether the target storage file has reached its storage limit based on the current amount of data stored in the target storage file and the storable data capacity of the target storage file. If the current amount of data stored in the target storage file reaches the storable data capacity of the target storage file, it is considered that the target storage file has reached its storage limit. Before storing the fault frame, the oldest existing fault frame in the target storage file needs to be deleted, and then the current fault frame is stored. In one embodiment, software instructions can be used to delete the oldest existing fault frame in the target storage file, i.e., the data to be deleted in the target storage file.

[0076] If the amount of data currently stored in the target storage file does not reach the amount of data that the target storage file can store, then it is considered that the target storage file has not reached its storage limit, and this fault frame is directly written to the target storage file.

[0077] In this embodiment of the application, when the target storage file has reached its storage limit, the earliest stored fault frame in the target storage file can be deleted. Since each application uses an independent storage file to store the corresponding fault frame, the storage of fault frames of each application does not interfere with each other. Therefore, under normal circumstances, the storage time of the early stored fault frames in the target storage file can be longer than that of the prior art, which facilitates the storage of fault frames and the analysis of subsequent faults.

[0078] Example 2 To enable those skilled in the art to more clearly understand the method for processing fault frames shown in the embodiments of this application, the following describes... Figure 3 The system architecture of a fault frame processing method shown in the embodiments of this application is explained.

[0079] Reference Figure 3 This is a system architecture diagram of a fault frame processing method provided in an embodiment of this application.

[0080] The domain controller in this embodiment includes two operating systems. The first operating system is SYS1, which hosts multiple applications such as APP1, APP2, and APP3. SYS1 uses NOR Flash memory, but in this embodiment, the NOR Flash memory of SYS1 is not used to store fault frames. The second operating system is SYS2, which uses eMMC memory and is a memory with a file system. SYS1 and SYS2 are connected via a first data exchange component (APP_SYS1) and a second data exchange component (APP_SYS2).

[0081] When APP1, APP2, and APP3 on SYS1 detect a fault, they need to store the fault frame Snap_Data_APP1 (assumed to be 10 bytes long), the fault frame Snap_Data_APP2 (assumed to be 100 bytes long), and the fault frame Snap_Data_APP3 (assumed to be 1000 bytes long) corresponding to APP1 and APP2, respectively. Snap_Data_APP1, Snap_Data_APP2, and Snap_Data_APP3 are then sent to APP_SYS2 of SYS2 via APP_SYS1.

[0082] On SYS2, APP_SYS2 manages the storage file paths for fault data of APP1, APP2, and APP3 according to the definition of APP_FILE_PATH. It checks whether the file APP1.JSON (i.e., APP1_FILE) exists under the path DATA / APP1_FILE / . If not, it creates the APP1.JSON file via software commands; if APP1.JSON exists, no action is taken. The files APP2.JSON (i.e., APP2_FILE) and APP3.JSON (i.e., APP3_FILE) follow the same process. APP_SYS2 defines the storable data volume of each storage file based on the historical fault frame length, historical fault occurrence frequency, and fault frame storage duration for each application, and manages it using APP_FILE_LIMIT.

[0083] When APP_SYS2 receives fault data from APP_SYS1, it parses the data according to the DATA_FORMAT_FOR_SYS1_SYS2 format. Based on the first field of DATA_FORMAT_FOR_SYS1_SYS2, it identifies whether the fault frame belongs to APP1, APP2, or APP3. Using APP_FILE_PATH, it determines that the fault frame should be stored in DATA / APP1_FILE / APP1.JSON, APP2: DATA / APP2_FILE / APP2.JSON, or APP3: DATA / APP3_FILE / APP3.JSON. Using APP_FILE_LIMIT, it finds the storable data limit of the storage file for this fault frame. APP_SYS2 checks if the storage file corresponding to this fault frame has reached its storage limit. If it has, it uses software commands to delete the oldest existing fault frame in the storage file before writing this fault frame. If it has not reached the limit, it writes the fault frame directly.

[0084] Ultimately, in the EMMC of SYS2, the APP1_FILE file stores APP1 fault frame data #1-#n, the APP2_FILE file stores APP2 fault frame data #1-#n, and the APP3_FILE file stores APP3 fault frame data #1-#n.

[0085] This application embodiment uses a memory containing a file system within a second operating system for fault frame storage. Since this memory has a larger capacity than the storage space of the first operating system, it can store a greater total number of fault frames, typically accommodating all fault frames generated by the first operating system, resulting in richer stored fault frame content. Simultaneously, due to the larger capacity of the second operating system's file system memory, early fault frames are less likely to be overwritten by subsequent fault frames, thus extending the retention time of fault frames. This is beneficial for fault analysis and solves the problems of limited number of fault frame entries and limited length of individual fault frames caused by the small storage capacity of NOR Flash in existing technologies. Furthermore, in this application embodiment, the storable data volume of each target storage file within the file system is determined based on the length of historical fault frames. During fault frame storage, the corresponding target storage file can be written according to the actual length of each fault frame, avoiding wasted storage space. This solves the problem of low utilization of fault data storage space in existing domain controllers and improves the domain controller's fault frame storage capacity.

[0086] This application also provides a fault frame processing device 40, please refer to... Figure 4 ,include: The fault frame acquisition module 410 is used to acquire fault frames of the first operating system, wherein the fault frame has a corresponding fault frame length. The fault frame sending module 420 is used to send the fault frame from the first operating system to the second operating system; The storage file determination module 430 is used to determine the target storage file corresponding to the fault frame in the file system of the second operating system, wherein the storable data volume of the target storage file is determined according to the length of the historical fault frame; The fault frame storage module 440 is used to store the fault frame in the target storage file.

[0087] Optionally, the first operating system has applications deployed on it, and the device includes: The file checking module is used to check whether the storage file corresponding to the application exists in the file system; The file creation module is used to create a new storage file corresponding to the application if the file system does not have a storage file corresponding to the application.

[0088] Optionally, the file creation module includes: The historical data acquisition submodule is used to acquire the historical failure frequency and failure frame storage duration of the application. The data volume determination submodule is used to determine the storable data volume of the storage file corresponding to the application based on the length of the historical fault frames corresponding to the application, the frequency of the historical fault occurrence, and the storage duration of the fault frames. The storage file creation submodule is used to create a new storage file corresponding to the application based on the amount of data that can be stored in the storage file corresponding to the application.

[0089] Optionally, the storage file determination module 430 includes: The fault frame parsing submodule is used to parse the fault frame and obtain the target application corresponding to the fault frame. The target file determination submodule is used to determine the target storage file corresponding to the fault frame and the amount of storable data in the target storage file in the file system based on the target application corresponding to the fault frame.

[0090] Optionally, the device includes: The storage limit determination module is used to determine whether the amount of data currently stored in the target storage file has reached the amount of data that the target storage file can store. The data to be deleted determination module is used to determine the data with the earliest storage time in the target storage file if the amount of data currently stored in the target storage file reaches the amount of data that the target storage file can store, and to use the data with the earliest storage time as the data to be deleted. The data deletion module is used to delete the data to be deleted from the target storage file.

[0091] Optionally, the fault frame acquisition module 410 is specifically used for: When the application in the first operating system malfunctions, the fault frame corresponding to the application is obtained.

[0092] Optionally, the first operating system includes a first data exchange component, and the second operating system includes a second data exchange component; the first operating system and the second operating system communicate with each other through the first data exchange component and the second data exchange component.

[0093] This application also provides an electronic device 50, please refer to... Figure 5It includes a processor 510 and a memory 520, wherein the memory 510 is used to store computer programs; the processor 520 is used to execute the programs stored in the memory 510 to implement the fault frame processing method described in any embodiment of this application.

[0094] This application also provides a vehicle that includes the electronic equipment described in this application.

[0095] In this application, "multiple" refers to two or more.

[0096] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0097] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0098] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0099] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0100] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for processing fault frames, characterized in that, A domain controller applied to a vehicle, the domain controller including a first operating system and a second operating system, the first operating system and the second operating system being communicatively connected, the first operating system supporting a maximum storage capacity less than the second operating system supporting a maximum storage capacity, the second operating system being configured with a memory including a file system, the method comprising: Obtain the fault frame of the first operating system, wherein the fault frame has a corresponding fault frame length; The fault frame is sent from the first operating system to the second operating system; In the file system of the second operating system, the target storage file corresponding to the fault frame is determined, and the amount of data that can be stored in the target storage file is determined according to the length of the historical fault frame; The fault frame is stored in the target storage file.

2. The method for processing fault frames according to claim 1, characterized in that, The first operating system has an application deployed thereon. Before determining the target storage file corresponding to the fault frame in the file system of the second operating system, the method includes: Check if the storage file corresponding to the application exists in the file system; If the file system does not contain a storage file corresponding to the application, then a new storage file corresponding to the application is created.

3. The method for processing fault frames according to claim 2, characterized in that, The newly created storage file corresponding to the application includes: Obtain the historical failure frequency and failure frame storage duration of the application; The amount of storable data in the storage file corresponding to the application is determined based on the length of the historical fault frames corresponding to the application, the frequency of the historical fault occurrence, and the storage duration of the fault frames. Create a new storage file corresponding to the application based on the amount of data that the storage file corresponding to the application can store.

4. The method for processing fault frames according to claim 3, characterized in that, Determining the target storage file corresponding to the fault frame in the file system of the second operating system includes: The fault frame is parsed to obtain the target application corresponding to the fault frame; Based on the target application corresponding to the fault frame, the target storage file corresponding to the fault frame and the amount of storable data in the target storage file are determined in the file system.

5. The method for processing fault frames according to claim 4, characterized in that, Before storing the fault frame in the target storage file, the method includes: Determine whether the amount of data currently stored in the target storage file has reached the storable data capacity of the target storage file; If the amount of data currently stored in the target storage file reaches the amount of data that the target storage file can store, then the data with the earliest storage time in the target storage file is determined and the data with the earliest storage time is selected as the data to be deleted. Delete the data to be deleted from the target storage file.

6. The method for processing fault frames according to claim 2, characterized in that, The step of obtaining the fault frame of the first operating system includes: When the application in the first operating system malfunctions, the fault frame corresponding to the application is obtained.

7. The method for processing fault frames according to claim 1, characterized in that, The first operating system includes a first data exchange component, and the second operating system includes a second data exchange component; the first operating system and the second operating system communicate with each other through the first data exchange component and the second data exchange component.

8. A fault frame processing apparatus, characterized in that, A domain controller for use in vehicles, the domain controller including a first operating system and a second operating system, the first operating system and the second operating system being communicatively connected, the first operating system supporting a maximum storage capacity less than the second operating system supporting a maximum storage capacity, the second operating system being configured with a memory including a file system, the device comprising: The fault frame acquisition module is used to acquire fault frames of the first operating system, wherein the fault frame has a corresponding fault frame length; A fault frame sending module is used to send the fault frame from the first operating system to the second operating system; The storage file determination module is used to determine the target storage file corresponding to the fault frame in the file system of the second operating system, wherein the amount of data that can be stored in the target storage file is determined according to the length of the historical fault frame; The fault frame storage module is used to store the fault frame in the target storage file.

9. An electronic device, characterized in that, Including processor and memory, among which Memory, used to store computer programs; A processor is configured to execute a program stored in memory to implement the fault frame processing method according to any one of claims 1-7.

10. A vehicle, characterized in that, It includes the electronic device as described in claim 9.

Images