Parameter file management method

Abstract

The embodiment of the invention discloses a parameter file management method, and the method comprises the steps: reading a parameter file needed by each application node in a vehicle from a persistent storage region of the vehicle after a starting instruction of the vehicle is received, and writing the parameter file into a volatile storage region of the vehicle; and for any first application node in the application nodes, if a parameter reading instruction sent by the first application node is received, returning a required first parameter file to the first application node from the volatile storage area, so that the first application node is started and operated based on the first parameter file. According to the embodiment of the invention, various parameter files originally dispersed in a persistent storage area are read into a high-speed volatile storage area at one time through a centralized loading strategy during starting, and a uniform parameter access center is established. The mechanism fundamentally solves the problems of data redundancy and consistency caused by parameter decentralized management, and lays a high-performance foundation for subsequent access.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a parameter file management method. Background Technology

[0002] Throughout a vehicle's entire lifecycle, from startup and initialization to daily driving decisions, its upper-level applications and algorithms heavily rely on a series of critical calibration data. This data forms the foundation for the vehicle to perceive its environment and understand its own state, and mainly includes vehicle body parameters that define the vehicle's physical attributes, radar extrinsic parameters that describe the radar's installation position and angle, and camera intrinsic and extrinsic parameters that are crucial for accurate image mapping and recognition.

[0003] However, in practical distributed electronic and electrical architectures, these parameters are often stored in different functional modules or electronic control units. This discretized storage strategy leads to the same parameter being stored repeatedly in multiple modules, not only wasting storage resources but also creating the potential for data inconsistency. Therefore, optimizing the management of parameter files in vehicles is a problem that urgently needs to be solved. Summary of the Invention

[0004] This application provides a parameter file management method that solves the technical problem of chaotic management of vehicle parameter files in the prior art, and achieves the technical effect of optimizing the management of vehicle parameter files and reducing the waste rate of storage resources.

[0005] This application provides a parameter file management method, the method comprising: After receiving the vehicle's start command, the parameter files required by each application node in the vehicle are read from the vehicle's persistent storage area and written to the vehicle's volatile storage area. For any first application node among the application nodes, if a parameter read instruction is received from the first application node, the required first parameter file is returned from the volatile storage area to the first application node so that the first application node can start running based on the first parameter file; For any second application node among the application nodes, if a parameter write instruction containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, then the second parameter file in the volatile storage area and the persistent storage area are updated based on the data to be written.

[0006] In some embodiments of this application, based on the foregoing scheme, after receiving the parameter write instruction sent by the second application node, and before updating the second parameter file in the volatile storage area and the persistent storage area based on the data to be written, the method further includes: The second parameter file stored in the volatile storage area is locked to enable the second application node to have exclusive access to the second parameter file; After updating the second parameter file in the volatile storage area and the persistent storage area based on the data to be written, the method further includes: Unlock the second parameter file stored in the volatile storage area to release the exclusive access of the second application node to the second parameter file.

[0007] In some embodiments of this application, based on the foregoing scheme, the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle and writing them into the volatile storage area of ​​the vehicle includes: For any target parameter file among the parameter files required by each application node, after reading the target parameter file from the persistent storage area of ​​the vehicle, the integrity of the target parameter file is verified, and after the target parameter file passes the integrity verification, it is written to the volatile storage area of ​​the vehicle.

[0008] In some embodiments of this application, based on the foregoing scheme, the persistent storage area of ​​the vehicle includes a main persistent storage area and a backup persistent storage area; the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle and writing them into the volatile storage area of ​​the vehicle includes: For any target parameter file among the parameter files required by each application node, the target parameter file is read from the main persistent storage area or the backup persistent storage area of ​​the vehicle. If the reading is successful, the target parameter file is written to the volatile storage area of ​​the vehicle.

[0009] In some embodiments of this application, based on the foregoing scheme, if reading the target parameter file from the primary persistent storage area and the backup persistent storage area fails, the method further includes: The target parameter file is read again from the main persistent storage area or the backup persistent storage area of ​​the vehicle. If the number of read failures exceeds a preset number, a first preset flag indicating read failure is written to the main persistent storage area and / or the backup persistent storage area, and the vehicle is restarted. After the vehicle restarts, the first preset flag is read, the parameter files required by each application node are obtained from the server communicating with the vehicle, and written into the volatile storage area, the main persistent storage area, and the backup persistent storage area to overwrite the original parameter files required by each application node in the main persistent storage area and the backup persistent storage area.

[0010] In some embodiments of this application, based on the foregoing scheme, reading the target parameter file from the vehicle's main persistent storage area or the backup persistent storage area includes: If reading from the primary persistent storage area fails but reading from the backup persistent storage area succeeds, then the target parameter file is written to the primary persistent storage area. If reading from the primary persistent storage area is successful but reading from the backup persistent storage area fails, the target parameter file is written to the backup persistent storage area.

[0011] In some embodiments of this application, based on the foregoing scheme, the volatile storage area includes multiple memory partitions, with each application node corresponding one-to-one with a memory partition; the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle and writing them into the volatile storage area of ​​the vehicle includes: The parameter files required by each application node in the vehicle are read asynchronously from the persistent storage area of ​​the vehicle, and the parameter files required by each application node are written into the memory partition corresponding to each application node.

[0012] In some embodiments of this application, based on the foregoing scheme, the method further includes, during the process of reading parameter files required by various application nodes in the vehicle from the persistent storage area of ​​the vehicle and writing them into the volatile storage area of ​​the vehicle: For any target parameter file among the parameter files required by each application node, if the target parameter file has missing fields, the target parameter file is completed based on preset default parameters, and the completed target parameter file is written to the volatile storage area of ​​the vehicle.

[0013] In some embodiments of this application, based on the foregoing scheme, after receiving the vehicle's start command and before reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area, the method further includes: The system retrieves a verification file containing a reference checksum stored in the persistent storage area after the vehicle last received a power-down command. The reference checksum is obtained by the vehicle performing an integrity check on the parameter file in the persistent storage area after the vehicle last received a power-down command. The reference checksum is stored in the first partition of the persistent storage area, and the reference files required by each application node are stored in the second partition of the persistent storage area. The first partition and the second partition are different. Determine whether the verification file contains a preset flag feature; If the verification file contains the preset flag feature, then continue to execute the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle; If the verification file does not contain the preset flag feature, a second preset flag indicating verification failure is written to the persistent storage area, and the vehicle is restarted. After the vehicle restarts, the second preset flag is read, the parameter files required by each application node are obtained from the server communicating with the vehicle, and written to the volatile storage area and the persistent storage area to overwrite the original parameter files required by each application node in the persistent storage area.

[0014] In some embodiments of this application, based on the foregoing scheme, the persistent storage area of ​​the vehicle includes a main persistent storage area and a backup persistent storage area; After receiving the vehicle start command, the method further includes: The parameter file in the main persistent storage area is subjected to integrity verification to obtain a first current checksum; the parameter file in the backup persistent storage area is subjected to integrity verification to obtain a second current checksum. The first current checksum is compared with the first reference checksum pre-stored in the main persistent storage area, and the second current checksum is compared with the second reference checksum pre-stored in the backup persistent storage area; the first reference checksum is obtained after performing an integrity check on the parameter file in the main persistent storage area after the vehicle last received a power-down command; the second reference checksum is obtained after performing an integrity check on the parameter file in the backup persistent storage area after the vehicle last received a power-down command. If the first current check code matches the first reference check code, and the second current check code does not match the second reference check code, then the parameter file in the main persistent storage area is written into the backup persistent storage area to overwrite the original parameter file in the backup persistent storage area. If the first current checksum does not match the first reference checksum, and the second current checksum matches the second reference checksum, then the parameter file in the backup persistent storage area is written into the main persistent storage area to overwrite the original parameter file in the main persistent storage area.

[0015] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: In this embodiment, after receiving a vehicle start command, the system reads the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writes them to the vehicle's volatile storage area. For any first application node among the application nodes, if a parameter read command is received from the first application node, the system returns the required first parameter file from the volatile storage area to the first application node, so that the first application node can start running based on the first parameter file. For any second application node among the application nodes, if a parameter write command containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, the system updates the volatile storage area and the second parameter file in the persistent storage area based on the data to be written.

[0016] As can be seen, this embodiment of the application, through a centralized loading strategy at startup, reads various parameter files that were originally scattered in the persistent storage area into a high-speed volatile storage area all at once, establishing a unified parameter access center. This mechanism fundamentally solves the data redundancy and consistency problems caused by decentralized parameter management and lays a high-performance foundation for subsequent access.

[0017] This application embodiment achieves efficient parameter reading and secure writing. For read requests, application nodes do not need to access slow persistent storage and can directly retrieve parameters from memory at extremely high speed, greatly improving application startup speed and the real-time response capability of the vehicle system, especially meeting the stringent low-latency requirements of intelligent vehicle scenarios. For write requests, this application embodiment introduces a differential comparison and dual update mechanism, performing update operations only when data undergoes a valid change. This not only avoids redundant I / O, improves execution efficiency, and extends the lifespan of storage devices, but more importantly, by atomically and synchronously updating volatile and persistent storage areas, it ensures strong data consistency and crash reliability, effectively preventing data inconsistency or corruption caused by unexpected power outages in the vehicle system. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a parameter file management method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a parameter file management architecture provided in an embodiment of this application. Detailed Implementation

[0020] This application provides a parameter file management method, which solves the technical problem of chaotic management of vehicle parameter files in the prior art.

[0021] The technical solution of this application embodiment is to solve the above-mentioned technical problems, and the general idea is as follows: In this embodiment, after receiving a vehicle start command, the system reads the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writes them to the vehicle's volatile storage area. For any first application node among the application nodes, if a parameter read command is received from the first application node, the system returns the required first parameter file from the volatile storage area to the first application node, so that the first application node can start running based on the first parameter file. For any second application node among the application nodes, if a parameter write command containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, the system updates the volatile storage area and the second parameter file in the persistent storage area based on the data to be written.

[0022] As can be seen, this embodiment of the application, through a centralized loading strategy at startup, reads various parameter files that were originally scattered in the persistent storage area into a high-speed volatile storage area all at once, establishing a unified parameter access center. This mechanism fundamentally solves the data redundancy and consistency problems caused by decentralized parameter management and lays a high-performance foundation for subsequent access.

[0023] This application embodiment achieves efficient parameter reading and secure writing. For read requests, application nodes do not need to access slow persistent storage and can directly retrieve parameters from memory at extremely high speed, greatly improving application startup speed and the real-time response capability of the vehicle system, especially meeting the stringent low-latency requirements of intelligent vehicle scenarios. For write requests, this application embodiment introduces a differential comparison and dual update mechanism, performing update operations only when data undergoes a valid change. This not only avoids redundant I / O, improves execution efficiency, and extends the lifespan of storage devices, but more importantly, by atomically and synchronously updating volatile and persistent storage areas, it ensures strong data consistency and crash reliability, effectively preventing data inconsistency or corruption caused by unexpected power outages in the vehicle system.

[0024] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0025] First, it should be clarified that the term "and / or" in this article 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, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0026] Throughout the entire lifecycle of intelligent connected vehicles, from initial startup to daily driving decisions, their core functions heavily rely on a series of precise calibration data, such as vehicle parameters (wheelbase, track width), radar extrinsic parameters (installation position and angle), and camera intrinsic and extrinsic parameters (focal length, distortion coefficient, installation posture). This data forms the foundation for the vehicle to perceive its environment, achieve accurate positioning, and make correct decisions. However, the current mainstream distributed management architecture poses significant challenges to the reliability, safety, and maintainability of vehicle systems.

[0027] First, these crucial parameters are typically scattered across various independent electronic control units or software modules. This distributed structure easily leads to duplicate data storage, wasting valuable storage resources. More seriously, it makes it difficult to ensure data security and integrity in a unified and effective manner. Each storage point can become a security vulnerability or a single point of failure; unauthorized access or damage at any point could trigger system-wide risks at the vehicle level.

[0028] Secondly, when multiple concurrent application processes (such as perception, positioning, and planning modules) need to read or modify the same parameters simultaneously, the lack of a centrally coordinated access mechanism can lead to data consistency issues. Classic concurrency conflicts, such as dirty reads, phantom reads, and even inter-process deadlocks, become extremely likely to occur in such an environment. This can result in minor functional abnormalities or, in severe cases, vehicle control failure, seriously threatening driving safety.

[0029] Finally, calibration data is not static. For example, cameras may need to be recalibrated after vehicle maintenance or parts replacement. However, due to the complex interrelationships between parameters (e.g., after updating camera calibration data, the radar parameters fused with it may also need adjustment), the current decentralized management model requires engineers to manually search for and update all relevant parameters in each module. This process is not only tedious, inefficient, and error-prone, but also significantly increases the maintenance costs of the vehicle system, hinders rapid software iteration and upgrades, and cannot meet the demands of agile development and continuous integration in the era of "software-defined vehicles."

[0030] To address the aforementioned problems, this application provides a parameter file management method, which includes steps S11-S13, as detailed below. Figure 1 As shown.

[0031] Step S11: After receiving the vehicle start command, read the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle and write them into the volatile storage area of ​​the vehicle. Step S12: For any first application node among the application nodes, if a parameter reading instruction is received from the first application node, the required first parameter file is returned from the volatile storage area to the first application node so that the first application node can start running based on the first parameter file. Step S13: For any second application node among the application nodes, if a parameter write instruction containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, then based on the data to be written, update the volatile storage area and the second parameter file in the persistent storage area.

[0032] The parameter file management method provided in this application embodiment can be executed by the vehicle's processor, such as a domain controller, central processing unit, etc. The specific method can be selected and adjusted according to the actual situation. This application embodiment only uses the processor as an example for illustration.

[0033] The vehicle in this embodiment includes at least a processor, a volatile storage area, a persistent storage area, and multiple application nodes. The volatile storage area refers to a storage component whose data is lost upon power failure; its main function is to provide a high-speed data access environment for the processor. The volatile storage area includes cache and main memory, which together constitute a temporary working area where the processor directly manipulates data.

[0034] Volatile memory can be main memory, and its physical carrier can be a memory module directly connected to the processor via a bus. Volatile memory can also be cache, a high-speed static random access memory integrated inside the processor, used to alleviate the speed difference between the processor and main memory.

[0035] Persistent storage refers to storage devices that retain data long-term even after power loss. These include embedded memory such as hard disk drives (HDDs), solid-state drives (SSDs), embedded multimedia cards (eMMC), and universal flash storage (UFS), as well as external expansion devices like USB flash drives (USB flash drives) and secure digital cards (SD cards). These types of storage are characterized by large capacity and low cost, but their access speed is significantly lower than that of volatile memory.

[0036] Regarding step S11, after receiving the vehicle's start command, the parameter files required by each application node in the vehicle are read from the vehicle's persistent storage area and written to the vehicle's volatile storage area.

[0037] The triggering sources and methods for starting commands are diverse, designed to adapt to different user interaction habits and intelligent scenarios. The most traditional triggering method is direct operation by the user through physical buttons (such as the start / stop button inside the car or the remote start button on the key). With the development of smart cockpit technology, more natural voice commands (such as saying "start the vehicle") and gesture recognition (such as specific hand gestures) have also become common triggering methods, improving the convenience and technological feel of operation. In addition, in the vehicle-to-everything (V2X) ecosystem, remote start commands issued through mobile terminals (such as smartphone applications and smart keys) allow users to pre-start the vehicle from outside, thereby pre-setting comfort features such as turning on the air conditioning and heating the seats.

[0038] Application nodes can be any hardware or software in the vehicle configured with relevant calibration parameters. For example, they can be various software programs included in the vehicle's infotainment system, or hardware such as radar or cameras. In this embodiment, the calibration parameters corresponding to each application node are defined as parameter files, with different application nodes corresponding to different parameter files.

[0039] The parameter files required by each application node are centrally stored in the persistent storage area. The storage format of the parameter files can be selected according to the actual situation, such as YAML (YAML Ain't Markup Language). After receiving the vehicle's start command, the parameter files required by each application node are read from the persistent storage area and then written to the vehicle's volatile storage area.

[0040] Furthermore, after receiving the vehicle's start command, and before reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area, the method further includes steps SA1-SA4.

[0041] Step SA1: Obtain the verification file containing the reference check code stored in the persistent storage area after the vehicle last received the power-down command. The reference check code is obtained by the vehicle performing an integrity check on the parameter file in the persistent storage area after the vehicle last received the power-down command. The reference check code is stored in the first partition of the persistent storage area, and the reference files required by each application node are stored in the second partition of the persistent storage area. The first partition and the second partition are different. Step SA2: Determine whether the verification file contains a preset flag feature; Step SA3: If the verification file contains the preset flag feature, then continue to execute the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle; Step SA4: If the verification file does not contain the preset flag feature, write a second preset flag indicating verification failure to the persistent storage area and restart the vehicle; after the vehicle restarts, read the second preset flag, obtain the parameter files required by each application node from the server communicating with the vehicle, and write them to the volatile storage area and the persistent storage area to overwrite the original parameter files required by each application node in the persistent storage area.

[0042] This application embodiment ensures that the vehicle can safely and reliably load the parameter files required by each application node when it starts up through a systematic verification and recovery mechanism. Its core lies in using a preset verification file in the persistent storage area to verify the integrity of the parameter file and automatically triggering the recovery process from the remote server when an anomaly is detected.

[0043] First, in step SA1, the vehicle system retrieves a reference checksum from a checksum file stored in persistent storage since the last power-off. The reference checksum and parameter file are stored in different partitions (partition one and partition two). This partitioning design not only avoids total data corruption due to a single point of failure but also improves the clarity and security of storage management, laying the foundation for independent verification operations.

[0044] Next, in step SA2, the vehicle system performs a preliminary integrity check by determining whether the verification file contains preset flag features, such as specific start-end flags set at the beginning and end of the verification file. This design can effectively identify file corruption caused by storage anomalies or unexpected power outages. If the flags are incomplete, it means that the verification file itself is unreliable, thus intercepting potential data errors in advance and improving the robustness of the vehicle system.

[0045] If the verification file passes the flag feature check (step SA3), the vehicle system will continue to read the parameter file in the persistent storage area for use by various application nodes. This ensures that the vehicle can start quickly without additional overhead, optimizing startup efficiency and user experience, provided the data is intact. Conversely, if the verification file does not contain the preset flag feature (step SA4), the vehicle system will write a second preset flag indicating verification failure to the persistent storage area and immediately restart the vehicle. After restarting, the vehicle system reads the flag and automatically retrieves the complete parameter file from the remote server, overwriting the original file in the volatile storage area and the persistent storage area. This mechanism not only achieves rapid fault isolation and recovery but also ensures data up-to-dateness and consistency through remote backup, significantly reducing the risk of vehicle system downtime due to local data corruption, ultimately enhancing vehicle stability and maintainability. Therefore, this embodiment of the application, through step-by-step verification, partitioned storage, and automatic recovery strategies, tightly integrates technical implementation and effects, improving data integrity and vehicle system reliability while ensuring the continuity and safety of vehicle startup through an efficient error handling mechanism.

[0046] Furthermore, the persistent storage area of ​​the vehicle may include a main persistent storage area and a backup persistent storage area; under this premise, after receiving the vehicle start command, the method further includes steps SB1-SB6.

[0047] Step SB1: Perform integrity verification on the parameter file in the main persistent storage area to obtain a first current checksum; perform integrity verification on the parameter file in the backup persistent storage area to obtain a second current checksum. Step SB2: Compare the first current checksum with the first reference checksum pre-stored in the main persistent storage area, and compare the second current checksum with the second reference checksum pre-stored in the backup persistent storage area; the first reference checksum is obtained after performing an integrity check on the parameter file in the main persistent storage area after the vehicle last received a power-down command; the second reference checksum is obtained after performing an integrity check on the parameter file in the backup persistent storage area after the vehicle last received a power-down command. Step SB3: Determine whether the first current check code matches the first reference check code to obtain a first matching result; determine whether the second current check code matches the second reference check code to obtain a second matching result; Step SB4: If at least one of the first matching result and the second matching result is a match, based on the target persistent storage area in the main persistent storage area and the backup persistent storage area where the matching result is a match, continue to execute the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle. Step SB5: If the first current check code matches the first reference check code, and the second current check code does not match the second reference check code, then the parameter file in the main persistent storage area is written into the backup persistent storage area to overwrite the original parameter file in the backup persistent storage area. Step SB6: If the first current check code does not match the first reference check code, and the second current check code matches the second reference check code, then the parameter file in the backup persistent storage area is written into the main persistent storage area to overwrite the original parameter file in the main persistent storage area.

[0048] Based on the introduction of dual storage areas (primary persistent storage area and backup persistent storage area), this application embodiment ensures that as long as either storage area retains complete data when the vehicle starts up, the vehicle system can quickly resume normal operation and automatically repair abnormal storage areas, thereby greatly improving the availability and robustness of the vehicle system.

[0049] First, in step SB1, the vehicle system performs integrity checks on the parameter files in the primary persistent storage area and the backup persistent storage area in parallel, generating a first current checksum and a second current checksum respectively. This step aims to assess their respective integrity status in real time and independently, providing an accurate data foundation for subsequent decisions and enabling proactive fault detection.

[0050] Following this, steps SB2 and SB3 constitute the "diagnostic decision" phase of the vehicle system. The vehicle system compares the calculated first current checksum with the first reference checksum pre-stored in the main persistent storage area (representing the correct state at the time of the last power-down), and simultaneously compares the second current checksum with the second reference checksum pre-stored in the backup storage area. Through these two comparison operations (step SB2), the vehicle system can accurately determine which storage area's data remains intact and which may have been corrupted. Step SB3 explicitly formalizes the comparison results as "first matching result" and "second matching result," providing a clear basis for subsequent logical branches.

[0051] In step SB4, as long as either the first or second matching result is "yes" (i.e., at least one storage area has complete data), the vehicle system will continue the startup process based on the "target persistent storage area" with intact data. This means that even if one storage area is completely corrupted, the vehicle system can immediately switch to another healthy storage area to read the parameter file, thereby ensuring rapid vehicle startup, minimizing vehicle system downtime due to single points of failure, and guaranteeing normal user operation.

[0052] Finally, regarding steps SB5 and SB6, after the vehicle system successfully boots from a healthy storage area, it does not ignore the problematic storage area. Step SB5 handles the "main memory intact, backup corrupted" scenario, in which the vehicle system will overwrite the original corrupted file in the backup storage area with the correct parameter file from the main persistent storage area. Conversely, step SB6 handles the "main memory corrupted, backup intact" scenario, in which the vehicle system will repair the main persistent storage area with the correct file from the backup storage area. This mechanism ensures the continued effectiveness of the dual-backup architecture. After each fault repair, the vehicle system can restore to an ideal state where both copies are healthy, preparing for the next potential fault and significantly improving the long-term reliability of the vehicle system.

[0053] Therefore, SB1 to SB6 provided in this application embodiment realize a complete closed loop from detection to decision-making to execution. Its technical advantage lies not only in preventing single points of failure through redundant design, but more importantly, in endowing the vehicle system with self-healing capabilities, thereby reducing reliance on manual intervention or remote server recovery and creating a more resilient and autonomous vehicle storage management system.

[0054] The aforementioned scheme has verified whether there are errors in the data stored in the persistent storage area. If there are no errors in the data stored in at least one persistent storage area, the subsequent scheme will continue to be executed.

[0055] Specifically, the volatile storage area includes multiple memory partitions, with each application node corresponding one-to-one with a memory partition. The step of reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writing them into the vehicle's volatile storage area includes: The parameter files required by each application node in the vehicle are read asynchronously from the persistent storage area of ​​the vehicle, and the parameter files required by each application node are written into the memory partition corresponding to each application node.

[0056] In the vehicle parameter file processing flow, the parameter files required by each application node are read asynchronously from the vehicle's persistent storage area, and the read parameter files are written to the pre-allocated memory partitions of each application node. Since the parameter files themselves are relatively small in size, and the memory of each application node is pre-planned and allocated, reading and writing parameter files in memory does not consume excessive memory resources, effectively avoiding the impact of memory shortages on the vehicle system's operation.

[0057] Meanwhile, read and write operations on the parameter file are implemented asynchronously using a thread pool. On one hand, this asynchronous execution method avoids blocking the calling thread, ensuring that the calling thread can handle other vehicle system tasks normally, thus guaranteeing the overall operational efficiency of the vehicle. On the other hand, during asynchronous execution, the results of the asynchronous read and write operations can be obtained in real time, allowing for timely assessment of operation success. If an operation exception occurs, the subsequent exception handling mechanism can be quickly triggered, further improving the reliability and stability of vehicle parameter file processing. Exception handling for read failures will be explained later and will not be elaborated upon here.

[0058] During the process of reading parameter files required by various application nodes in the vehicle from the persistent storage area of ​​the vehicle and writing them into the volatile storage area of ​​the vehicle, if any target parameter file in the parameter files required by each application node has missing fields, the target parameter file is completed based on preset default parameters, and the completed target parameter file is written into the volatile storage area of ​​the vehicle.

[0059] This application significantly improves the stability and fault tolerance of vehicle application nodes through dynamic detection and intelligent completion mechanisms. When loading parameter files from persistent storage to volatile storage, the integrity of fields is checked in real time. If a critical field is detected as missing, the logic for automatically filling in preset default parameters is immediately triggered. This application ensures that application nodes always obtain complete parameter configurations, avoiding runtime anomalies or functional degradation caused by missing fields. This application also significantly reduces latency through a memory-level fast completion mechanism (compared to rereading persistent storage), ensuring real-time requirements and significantly improving the compatibility and maintainability of the vehicle system.

[0060] Furthermore, for any target parameter file among the parameter files required by each application node, after reading the target parameter file from the persistent storage area of ​​the vehicle, the integrity of the target parameter file is verified, and after the target parameter file passes the integrity verification, it is written to the volatile storage area of ​​the vehicle.

[0061] In the process of reading the parameter file from the persistent storage area to the volatile storage area, this application embodiment performs binary-level integrity verification, including but not limited to: checksum verification, field length detection, key flag matching, and other multi-dimensional verification algorithms. This proactive verification system provided by this application embodiment can intercept corrupted or tampered parameter files during the data loading stage, preventing incorrect configurations from infiltrating the runtime environment and blocking potential risks at the initialization stage. This application embodiment avoids the resource waste of "loading first and then reporting errors" in traditional solutions through pre-verification, thus improving memory utilization.

[0062] The vehicle's persistent storage area may include a primary persistent storage area and a backup persistent storage area. Under this premise, the step of reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writing them to the vehicle's volatile storage area includes: For any target parameter file among the parameter files required by each application node, the target parameter file is read from the main persistent storage area or the backup persistent storage area of ​​the vehicle. If the reading is successful, the target parameter file is written to the volatile storage area of ​​the vehicle.

[0063] For ease of distinction, any given parameter file will be referred to as the target parameter file. The target parameter file can be read from either the primary persistent storage area or the backup persistent storage area. For example, it can be read first from the primary persistent storage area; if that fails, it can then be read from the backup persistent storage area. If the read succeeds, the target parameter file can be written to the vehicle's volatile storage area.

[0064] Further, the step of reading the target parameter file from the main persistent storage area or the backup persistent storage area of ​​the vehicle includes: if reading from the main persistent storage area fails but reading from the backup persistent storage area succeeds, then writing the target parameter file into the main persistent storage area; if reading from the main persistent storage area succeeds but reading from the backup persistent storage area fails, then writing the target parameter file into the backup persistent storage area.

[0065] When a read failure occurs in the primary persistent storage area while a read success occurs in the backup storage area, it indicates that the primary storage may have partial corruption or a temporary access anomaly. In this case, the vehicle system will rewrite the verified and usable target parameter file from the backup storage area into the primary storage, thereby automatically repairing the abnormal state of the primary storage and ensuring its integrity and availability. Conversely, if a read success occurs in the primary storage area but a read failure occurs in the backup storage area, it indicates an anomaly in the backup storage. The vehicle system will immediately synchronize the correct parameter file from the primary storage area to the backup storage area to rebuild the redundancy protection of the backup link. This mechanism not only achieves rapid self-healing from storage media failures but also ensures the eventual consistency of parameter files in both storage spaces through bidirectional data repair, effectively improving the vehicle system's ability to guarantee data integrity and service continuity at the persistence level.

[0066] However, in rare cases, both the primary persistent storage area and the backup persistent storage area may encounter errors, leading to failures in reading from both the primary persistent storage area and the backup persistent storage area. In such cases, the target parameter file can be read again from either the primary persistent storage area or the backup persistent storage area of ​​the vehicle.

[0067] If reading from both the primary persistent storage area and the backup persistent storage area fails, and the number of read failures exceeds a preset number (e.g., 3 times), a first preset flag indicating read failure can be written to the primary persistent storage area and / or the backup persistent storage area, and the vehicle can be restarted.

[0068] After the vehicle restarts, the first preset flag is read, and the parameter files required by each application node are obtained from the server communicating with the vehicle. These files are then written into the volatile storage area, the main persistent storage area, and the backup persistent storage area, overwriting the original parameter files required by each application node in the main persistent storage area and the backup persistent storage area. Then, the process returns to step S11, which involves reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writing them into the vehicle's volatile storage area.

[0069] When read errors are detected in both the primary persistent storage area and the backup persistent storage area, exceeding the preset retry threshold, it indicates that the local storage may have encountered a serious, non-healable fault (such as physical damage or widespread logical data errors). In this situation, the vehicle system does not enter an infinite loop or directly report an error. Instead, it takes an escalation measure of "actively marking and orderly restarting." By writing specific read failure flags, this operation acts like setting up a fault "beacon" in the vehicle system, providing crucial contextual information for the subsequent recovery process. The subsequent vehicle restart is a forced reset aimed at clearing temporary software state errors and attempting recovery from the hardware level.

[0070] After rebooting, by identifying pre-set flags, the system intelligently determines that the conventional recovery path has failed, and automatically initiates the highest-level recovery plan, which involves retrieving all necessary parameter files from a remote server. This step represents the ultimate demonstration of the vehicle system's self-healing capabilities. Leveraging the cloud-based collaborative advantages of the Internet of Vehicles (IoV), and using the server as a trusted data source, it thoroughly rebuilds and overwrites all local storage areas (including volatile memory, main storage, and backup storage). This not only restores the vehicle system's immediate operational capabilities but, more importantly, simultaneously repairs the underlying faults in the local persistent storage, resetting the storage media to a known and correct state. The entire process forms a closed-loop negative feedback recovery loop, ensuring that the vehicle can eventually return to normal operation while significantly improving the vehicle system's robustness, self-healing capabilities, and service continuity in the face of extreme storage failures. This is a key technological guarantee for achieving a highly reliable in-vehicle system.

[0071] Regarding step S12, for any first application node among the application nodes, if a parameter read instruction is received from the first application node, the required first parameter file is returned from the volatile storage area to the first application node so that the first application node can start running based on the first parameter file.

[0072] When any first application node (such as the perception module or the positioning module) in the vehicle system initiates a parameter reading command, the mechanism does not allow it to directly access the slow persistent storage. Instead, a central management service directly retrieves and returns the required first parameter file from the volatile storage area (i.e., memory).

[0073] As can be seen, the embodiments of this application significantly improve the efficiency of node startup and operation. Since memory access speed far exceeds that of persistent storage such as hard disks or Flash, application nodes can obtain their configurations almost instantaneously, achieving millisecond-level rapid startup and meeting the stringent real-time requirements of intelligent vehicle systems. The embodiments of this application ensure strong consistency and security of data access. All nodes obtain parameters through a unified interface, avoiding multiple nodes reading different versions or corrupted parameter files, fundamentally eliminating abnormal vehicle system behavior caused by data inconsistency. Simultaneously, centralized management isolates direct interaction between application nodes and underlying storage, reducing the risk of unauthorized modification or corruption of parameters. The embodiments of this application ensure that the first application node can complete initialization and operation based on the correct and up-to-date first parameter file, laying a solid foundation for the stability and reliability of upper-layer functions and being a key link in building a reusable and maintainable software architecture in "software-defined vehicles."

[0074] Regarding step S13, for any second application node among the application nodes, if a parameter write instruction containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, then based on the data to be written, the second parameter file in the volatile storage area and the persistent storage area is updated.

[0075] Whether there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area can be determined using the following methods: exact matching, tolerance comparison, hash verification, version number comparison, serialized string comparison, and field-level recursive comparison. For details, please refer to relevant technologies; this application embodiment will not elaborate further.

[0076] When any second application node in the vehicle system (such as the autonomous driving module or the cockpit entertainment vehicle system) initiates a parameter write command, this mechanism does not unconditionally execute the write operation directly, but first performs a difference comparison. Specifically, the central parameter management service verifies whether there are any differences between the data to be written contained in the command and the second parameter file currently cached in the volatile storage area (i.e., memory).

[0077] This preliminary comparison step is crucial for improving vehicle system efficiency. First, it avoids redundant write operations, optimizing vehicle system performance and storage lifespan. If the data remains unchanged, all subsequent update processes are skipped. This not only saves valuable processor and memory bandwidth but, more importantly, avoids unnecessary erase / write operations on persistent storage (such as the vehicle's hard drive), which is significant for extending the lifespan of flash memory storage devices. Second, it ensures the atomicity and consistency of data updates, guaranteeing the robustness of the vehicle system. Only when a difference is detected does the mechanism initiate a collaborative update process, atomically updating the second parameter file in both volatile and persistent storage. This "dual-write" strategy ensures that even in extreme situations such as unexpected power outages, the data in memory and on the hard drive will not remain inconsistent for extended periods; either both updates successfully, or the data remains unchanged, thus preventing functional abnormalities caused by incorrect parameter versions. Ultimately, this mechanism, while meeting the dynamic configuration requirements of application nodes, constructs a closed loop for updating vehicle parameters that is performance-optimized, resource-saving, and highly reliable, providing a solid foundation for the stability and maintainability of vehicles in complex operating environments.

[0078] Furthermore, after receiving the parameter write instruction sent by the second application node, before updating the second parameter file in the volatile storage area and the persistent storage area based on the data to be written, the second parameter file stored in the volatile storage area is locked to enable the second application node to have exclusive access to the second parameter file.

[0079] After updating the second parameter file in the volatile storage area and the persistent storage area based on the data to be written, the second parameter file stored in the volatile storage area is unlocked to release the exclusive access of the second application node to the second parameter file.

[0080] As can be seen, this application provides a concurrent safe write mechanism based on a mutex lock to solve the data contention problem in a multi-process environment. Specifically, after receiving the parameter write instruction from the second application node, the vehicle system does not immediately update the data, but first performs a crucial pre-operation: locking the target second parameter file stored in the volatile storage area. Here, "lock" typically refers to a mutex lock, which, upon successful acquisition, immediately grants the second application node exclusive access to the parameter. This means that while the lock is held, any other process attempting to read or write to this parameter file will be blocked or enter a waiting queue, thus logically serializing access to the resource.

[0081] The direct technical effect of this locking mechanism is to enforce the atomicity and consistency of data updates. It ensures that during the critical window of parameter updates (from reading the old value, calculating to writing the new value), no other process will read incomplete "dirty data" in an intermediate state, and it also completely avoids the chaotic scenario of multiple write operations overwriting each other. This is the foundation for resolving data races and preventing deadlocks.

[0082] Following the completion of the data update process (i.e., both the volatile and persistent storage areas have been successfully updated), the vehicle system immediately performs an unlocking operation, releasing exclusive control over the parameter file. This step is crucial, as it removes the blockade from other waiting processes, restoring the vehicle system's ability to access concurrently and thus preventing performance bottlenecks or system freezes caused by prolonged lock holding.

[0083] Ultimately, the "lock-update-unlock" closed-loop operation provided in this application embodiment transforms potential concurrent writes into serial execution in the time dimension and isolates the interference of different processes on shared resources in the spatial dimension. Thus, it constructs a thread-safe, data-reliable, and highly available parameter management service as a whole, providing solid underlying support for the stable operation of upper-layer applications.

[0084] In summary, after receiving a vehicle start command, this embodiment reads the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writes them to the vehicle's volatile storage area. For any first application node among the application nodes, if a parameter read command is received from the first application node, the required first parameter file is returned from the volatile storage area to the first application node so that the first application node can start running based on the first parameter file. For any second application node among the application nodes, if a parameter write command containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, the second parameter file in the volatile storage area and the persistent storage area is updated based on the data to be written.

[0085] As can be seen, this embodiment of the application, through a centralized loading strategy at startup, reads various parameter files that were originally scattered in the persistent storage area into a high-speed volatile storage area all at once, establishing a unified parameter access center. This mechanism fundamentally solves the data redundancy and consistency problems caused by decentralized parameter management and lays a high-performance foundation for subsequent access.

[0086] This application embodiment achieves efficient parameter reading and secure writing. For read requests, application nodes do not need to access slow persistent storage and can directly retrieve parameters from memory at extremely high speed, greatly improving application startup speed and the real-time response capability of the vehicle system, especially meeting the stringent low-latency requirements of intelligent vehicle scenarios. For write requests, this application embodiment introduces a differential comparison and dual update mechanism, performing update operations only when data undergoes a valid change. This not only avoids redundant I / O, improves execution efficiency, and extends the lifespan of storage devices, but more importantly, by atomically and synchronously updating volatile and persistent storage areas, it ensures strong data consistency and crash reliability, effectively preventing data inconsistency or corruption caused by unexpected power outages in the vehicle system.

[0087] This application provides a complete, efficient, and reliable centralized management solution for vehicle parameters. This solution significantly improves the vehicle system's startup speed, operating efficiency, data consistency, and maintenance convenience by constructing a layered parameter access mechanism. Specifically, upon receiving a vehicle startup command, the vehicle system first performs a batch preloading operation, reading all the parameter files required by each application node, which were originally scattered in persistent storage (such as a hard drive), and loading them into a high-speed volatile storage area (i.e., memory) at once. The direct technical effect of this design is that during the vehicle system initialization phase, a high-speed cache is established for parameter access by all subsequent application nodes, fundamentally avoiding the latency caused by repeated access to slow storage devices during operation. This achieves millisecond-level fast startup of application nodes and a significant improvement in the overall response performance of the vehicle system.

[0088] During operation, this scheme optimizes resource scheduling and ensures data security by differentiating between read and write requests. For any parameter read command issued by the first application node, the vehicle system directly returns the required first parameter file from its volatile storage cache. This not only guarantees extremely low latency for data calls but also fundamentally ensures strong consistency of parameter reads because all nodes access the same copy of data in memory. For any parameter write command initiated by the second application node, the vehicle system introduces a rigorous update process: first, it intelligently determines whether the data to be written has been effectively changed through a differential comparison mechanism (such as checksum, hash, or version number), thereby avoiding unnecessary write operations and optimizing vehicle system overhead and storage lifespan; when an update is confirmed, a locking mechanism ensures the atomicity of the update, synchronously updating the parameter files in both the volatile and persistent storage areas. The technical effect of this mechanism is that it ensures the efficiency and accuracy of dynamic runtime parameter modification while eliminating the risk of data inconsistency due to power outages or other anomalies through synchronous updates of dual storage, achieving high reliability for dynamic parameter maintenance and high robustness of the vehicle system as a whole.

[0089] Since the electronic device described in this embodiment is an electronic device used to implement the information processing method in the embodiments of this application, those skilled in the art can understand the specific implementation methods and various variations of the electronic device in this embodiment based on the information processing method described in the embodiments of this application. Therefore, how the electronic device implements the method in the embodiments of this application will not be described in detail here. Any electronic device used by those skilled in the art to implement the information processing method in the embodiments of this application falls within the scope of protection of this application.

[0090] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0093] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the function specified in one or more boxes.

[0094] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0095] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A parameter file management method, characterized in that, The method includes: After receiving the vehicle's start command, the parameter files required by each application node in the vehicle are read from the vehicle's persistent storage area and written to the vehicle's volatile storage area. For any first application node among the application nodes, if a parameter read instruction is received from the first application node, the required first parameter file is returned from the volatile storage area to the first application node so that the first application node can start running based on the first parameter file; For any second application node among the application nodes, if a parameter write instruction containing data to be written is received from the second application node, and there is a difference between the data to be written and the second parameter file corresponding to the second application node in the volatile storage area, then the second parameter file in the volatile storage area and the persistent storage area are updated based on the data to be written.

2. The parameter file management method as described in claim 1, characterized in that, After receiving the parameter write instruction sent by the second application node, and before updating the second parameter file in the volatile storage area and the persistent storage area based on the data to be written, the method further includes: The second parameter file stored in the volatile storage area is locked to enable the second application node to have exclusive access to the second parameter file; After updating the second parameter file in the volatile storage area and the persistent storage area based on the data to be written, the method further includes: Unlock the second parameter file stored in the volatile storage area to release the exclusive access of the second application node to the second parameter file.

3. The parameter file management method as described in claim 1, characterized in that, The step of reading parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle and writing them to the volatile storage area of ​​the vehicle includes: For any target parameter file among the parameter files required by each application node, after reading the target parameter file from the persistent storage area of ​​the vehicle, the integrity of the target parameter file is verified, and after the target parameter file passes the integrity verification, it is written to the volatile storage area of ​​the vehicle.

4. The parameter file management method as described in claim 1, characterized in that, The vehicle's persistent storage area includes a main persistent storage area and a backup persistent storage area; the step of reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area and writing them to the vehicle's volatile storage area includes: For any target parameter file among the parameter files required by each application node, the target parameter file is read from the main persistent storage area or the backup persistent storage area of ​​the vehicle. If the reading is successful, the target parameter file is written to the volatile storage area of ​​the vehicle.

5. The parameter file management method as described in claim 4, characterized in that, In the event that reading the target parameter file from the primary persistent storage area and the backup persistent storage area fails, the method further includes: The target parameter file is read again from the main persistent storage area or the backup persistent storage area of ​​the vehicle. If the number of read failures exceeds a preset number, a first preset flag indicating read failure is written to the main persistent storage area and / or the backup persistent storage area, and the vehicle is restarted. After the vehicle restarts, the first preset flag is read, the parameter files required by each application node are obtained from the server communicating with the vehicle, and written into the volatile storage area, the main persistent storage area, and the backup persistent storage area to overwrite the original parameter files required by each application node in the main persistent storage area and the backup persistent storage area.

6. The parameter file management method as described in claim 4, characterized in that, The step of reading the target parameter file from the vehicle's main persistent storage area or the backup persistent storage area includes: If reading from the primary persistent storage area fails but reading from the backup persistent storage area succeeds, then the target parameter file is written to the primary persistent storage area. If reading from the primary persistent storage area is successful but reading from the backup persistent storage area fails, the target parameter file is written to the backup persistent storage area.

7. The parameter file management method as described in claim 1, characterized in that, The volatile storage area includes multiple memory partitions, and each application node corresponds one-to-one with a memory partition; The step of reading parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle and writing them to the volatile storage area of ​​the vehicle includes: The parameter files required by each application node in the vehicle are read asynchronously from the persistent storage area of ​​the vehicle, and the parameter files required by each application node are written into the memory partition corresponding to each application node.

8. The parameter file management method as described in claim 1, characterized in that, The method further includes, in the process of reading parameter files required by various application nodes in the vehicle from the vehicle's persistent storage area and writing them to the vehicle's volatile storage area: For any target parameter file among the parameter files required by each application node, if the target parameter file has missing fields, the target parameter file is completed based on preset default parameters, and the completed target parameter file is written to the volatile storage area of ​​the vehicle.

9. The parameter file management method as described in claim 1, characterized in that, After receiving the vehicle's start command, and before reading the parameter files required by each application node in the vehicle from the vehicle's persistent storage area, the method further includes: The system retrieves a verification file containing a reference checksum stored in the persistent storage area after the vehicle last received a power-down command. The reference checksum is obtained by the vehicle performing an integrity check on the parameter file in the persistent storage area after the vehicle last received a power-down command. The reference checksum is stored in the first partition of the persistent storage area, and the reference files required by each application node are stored in the second partition of the persistent storage area. The first partition and the second partition are different. Determine whether the verification file contains a preset flag feature; If the verification file contains the preset flag feature, then continue to execute the step of reading the parameter files required by each application node in the vehicle from the persistent storage area of ​​the vehicle; If the verification file does not contain the preset flag feature, a second preset flag indicating verification failure is written to the persistent storage area, and the vehicle is restarted. After the vehicle restarts, the second preset flag is read, the parameter files required by each application node are obtained from the server communicating with the vehicle, and written to the volatile storage area and the persistent storage area to overwrite the original parameter files required by each application node in the persistent storage area.

10. The parameter file management method as described in claim 1, characterized in that, The vehicle's persistent storage area includes a main persistent storage area and a backup persistent storage area; After receiving the vehicle start command, the method further includes: The parameter file in the main persistent storage area is subjected to integrity verification to obtain a first current checksum; the parameter file in the backup persistent storage area is subjected to integrity verification to obtain a second current checksum. The first current checksum is compared with the first reference checksum pre-stored in the main persistent storage area, and the second current checksum is compared with the second reference checksum pre-stored in the backup persistent storage area; the first reference checksum is obtained after performing an integrity check on the parameter file in the main persistent storage area after the vehicle last received a power-down command; the second reference checksum is obtained after performing an integrity check on the parameter file in the backup persistent storage area after the vehicle last received a power-down command. If the first current check code matches the first reference check code, and the second current check code does not match the second reference check code, then the parameter file in the main persistent storage area is written into the backup persistent storage area to overwrite the original parameter file in the backup persistent storage area. If the first current checksum does not match the first reference checksum, and the second current checksum matches the second reference checksum, then the parameter file in the backup persistent storage area is written into the main persistent storage area to overwrite the original parameter file in the main persistent storage area.

Images