Dynamic differential update method of intelligent self-closing loop car light controller software

Abstract

The application discloses a kind of dynamic differential update methods of intelligent self-closing loop car light controller software, belong to car light software control technical field.It includes the following steps: step S1, executable file of new and old version and the compiling file corresponding to executable file of new and old version are preprocessed, then function section and data section difference calculation is carried out, dynamic integration script is generated, and complete differential package ΔF is built;Step S2, differential package ΔF is distributed to target LCU by vehicle gateway, and system compatibility check and resource pre-evaluation are carried out;Step S3, memory resource is dynamically scheduled by scheduling algorithm.The application provides a kind of dynamic differential update methods of intelligent self-closing loop car light controller software, realizes the method process from dynamic difference generation to safe and reliable transmission to resource adaptive integration to intelligent self-closing loop verification, aims at on the car light controller of resource limited, extremely high reliability requirement, realizes safe, efficient, reliable software differential update.

Description

Technical Field

[0001] This invention relates to a dynamic differential update method for intelligent self-closed-loop vehicle lighting controller software, belonging to the field of vehicle lighting software control technology. Background Technology

[0002] Currently, as automotive electronic and electrical architectures evolve towards centralized, domain controllers, the functions of the Lighting Control Unit (LCU) are becoming increasingly complex, and its software iteration frequency is significantly accelerating. Over-the-Air (OTA) software updates have become a core means of achieving functional upgrades and problem fixes throughout the vehicle's lifecycle. Among them, differential update technology effectively saves wireless communication bandwidth, reduces update time, and lowers data traffic costs by transmitting only the difference (differential) data packets between the old and new software versions, rather than the complete firmware image.

[0003] However, current differential update solutions for embedded nodes such as vehicle lighting controllers, which have extremely high requirements for real-time performance, functional safety, and reliability, still face challenges such as uncontrollable dynamic memory usage, weak anti-interference ability during the update process, and lack of automated verification closed-loop for the functional integrity of the updated system.

[0004] Existing technologies primarily employ static differential algorithms (such as BSDiff and HDiffPatch) based on file block or binary instruction sequence alignment. This process is typically executed in a dedicated bootloader environment isolated from the application to ensure basic reliability. First, on the server side, the old firmware image F... old Image F with the new firmware version new A comparison is performed to generate a differential packet ΔFF. Then, after downloading the differential packet ΔFF to the vehicle terminal, the agent updates the data based on the differential packet ΔFF and the locally stored F. old F is reconstructed (patched) block by block or instruction by instruction in the controller memory. new Finally, the reconstructed complete F new Write to the target area of ​​Flash to complete the update.

[0005] However, existing technologies have the following drawbacks: 1. Although the size of the differential packet ΔFF generated by the static differential algorithm is smaller than that of the complete image, when performing a "reconstruction-write" operation on a resource-constrained LCU, it is necessary to request consecutive packets with F. new Memory buffers of similar size are used to temporarily store reconstruction results, which puts a huge strain on the LCU's RAM resources, and this strain is fixed and cannot be optimized.

[0006] 2. The existing solution lacks an effective mechanism to deal with unexpected interruptions during the update process (such as power fluctuations or communication interruptions). Once interrupted in the "reconstruction-write" process, the incomplete new image temporarily stored in the controller's memory may be corrupted and cannot be automatically restored to a working old version, resulting in the risk of the device becoming "bricked".

[0007] 3. Existing technologies typically perform simple CRC checks or startup tests after an update, but lack an automated, closed-loop verification process for each specific function of the LCU (such as daytime running lights, turn signals, and high / low beam control logic) in a real vehicle bus network environment. Functional anomalies can only be detected through subsequent manual testing or user feedback, resulting in a slow response.

[0008] 4. Most existing solutions are based on file block differentiation, and their minimum granularity is limited by the block size. They cannot accurately match specific function or data segment that changes frequently in LCU software, resulting in the differential packet ΔF still containing a lot of redundant data. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide a dynamic differential update method for intelligent self-closed-loop vehicle lighting controller software. The method realizes the process flow from dynamic differential generation to safe and reliable transmission to resource adaptive integration to intelligent self-closed-loop verification. It aims to achieve safe, efficient and reliable software differential update on vehicle lighting controllers with limited resources and extremely high reliability requirements.

[0010] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: A dynamic differential update method for intelligent self-closed-loop vehicle light controller software includes the following steps: Step S1: Preprocess the executable files of the new and old versions and the corresponding compilation files of the executable files of the new and old versions, then perform differential calculation of function segment and data segment, generate dynamic integration script, and build a complete differential package ΔF; Step S2: Distribute the differential packet ΔF to the target LCU through the vehicle gateway, and perform system compatibility checks and resource pre-assessment; Step S3: Monitor memory resources and dynamically schedule memory resources using a scheduling algorithm, then execute each atomic operation instruction in the integrated script Π. Step S4: Perform intelligent self-closed loop verification.

[0011] Furthermore, in step S11, preprocessing is performed on the executable files of the new and old versions, as well as the corresponding compiled files, specifically including the following steps: The compiled files include symbol table files and linker files. The symbol table files and linker files are parsed to establish mappings between function names and their absolute addresses or relative offsets in memory, and to establish mappings between global variable names and their absolute addresses or relative offsets in memory. Simultaneously, disassembly is used to identify older versions of executable files (e.g., F). old and the new version of executable file F new The boundary information in the data segment includes function boundaries and data segment boundaries.

[0012] Furthermore, in step S12, the difference calculation between the function segment and the data segment is performed, specifically including the following steps: This embodiment is based on symbol and boundary information, for each in F new Function Func that changes the content i and Data segment j It uses an improved binary difference algorithm to calculate its relative to F old The difference data ΔF in i and ΔF j ; Then, analyze the call dependencies and data reference relationships between the basic units that have changed.

[0013] Furthermore, the integrated script Π is an ordered list of operation instructions, all of which are atomic operations, and each operation instruction includes operation type, operation parameters, and dependencies.

[0014] Furthermore, the differential packet ΔF includes a header, metadata area, integration script area, differential data area, verification test case area, and digital signature area.

[0015] Furthermore, in step S2, the differential packet ΔF is distributed to the target LCU through the vehicle gateway, and system compatibility checks and resource pre-assessments are performed. Specifically, this includes the following steps: First, the differential packet ΔF is encrypted and signed before being transmitted to the vehicle gateway, and then distributed by the vehicle gateway to the target LCU; Then, the smart update client in the target LCU first verifies the signature to ensure that the packet has not been tampered with and that the source is trustworthy. Then it parses the differential packet ΔF and checks system compatibility and performs resource pre-assessment based on the information in the metadata area Γ. If both system compatibility and resource pre-assessment meet the requirements, proceed to step S3; if either system compatibility or resource pre-assessment fails to meet the requirements, immediately terminate the update process, do not perform any Flash rewriting operations, and perform a rollback operation.

[0016] Furthermore, in step S3, monitoring memory resources and dynamically scheduling memory resources using a scheduling algorithm specifically includes the following steps: The resource monitor obtains the currently available RAM fragment information in real time, and represents all available RAM fragment information as a set of available memory blocks M. The integrated script Π is read by a dynamic memory scheduler, the dependencies between each atomic operation in the integrated script Π are analyzed, and the topological order is sorted out. Based on the set of available memory blocks M, the set of atomic operations Op, and the dependencies (Op) between atomic operations, a scheduling algorithm is used for scheduling. One or more memory blocks are allocated to each atomic operation, and each atomic operation has its required minimum buffer size buf. min (op n ) and the size of the data to be processed (size(op)) n ).

[0017] Furthermore, the scheduling algorithm specifically includes the following steps: Step S311: Perform topological sorting on the atomic operations in the atomic operation set Op to obtain a linear execution sequence that satisfies the dependencies; Step S312: Sequentially process each atomic operation op in the execution sequence. n ; Step S313: In the current set of memory blocks M, find the smallest buffer size buf whose size satisfies size ≥ minimum buffer size buf. min (op n The memory blocks are defined, and the smallest memory block is found among all memory blocks that meet the size condition. Step S314: Allocate the memory block found in step S313 to op. n Perform the operation, and once completed, immediately release the memory block and mark it as reusable; Step S315: Update the memory state of the memory block set M and continue processing the next atomic operation.

[0018] Furthermore, in step S4, intelligent self-closed-loop verification is performed, which specifically includes the following steps: Step S41, New version executable file F new After running, start the verification agent: Step S42: Execute the verification test cases in the differential package: Step S43: The verification agent inputs control signals to the LCU itself by simulating the software or controlling the hardware test switch, and at the same time listens to the status of the LCU's output pins or the bus messages it sends.

[0019] Step S44: Compare the expected output with the actual output and generate a verification report.

[0020] Step S45: Conduct decision-making closed-loop and feedback.

[0021] Furthermore, in step S45, the decision-making loop and feedback are performed, specifically including the following steps: If all verification test cases pass, the verification agent sends a successful verification report to the vehicle gateway via the vehicle network; simultaneously, it clears the pending verification flag and marks the Backup Slot in the backup update area as a stable version; the vehicle gateway notifies the cloud server of a successful update and erases the old version executable file F from the Active Slot in the main runtime area. old .

[0022] If any verification test case fails, the verification agent immediately records the failure information and triggers a forced restart. When the bootloader detects the verification failure flag during restart, it will not switch the boot slot and will continue to start from the main running area Active Slot to achieve automatic rollback. After rollback, the LCU reports the update failure and verification failure logs to the cloud server through the vehicle gateway.

[0023] By adopting the above technical solution, the beneficial effects of the present invention are as follows: 1. By using dynamic memory scheduling and atomic script execution, the update process's need for large blocks of memory is transformed into the sequential use of multiple small memory blocks, enabling the update function to run stably on resource-constrained LCUs and solving the problem of drawback 1.

[0024] 2. Atomized operations and state recording at each step, combined with dual mirroring and intelligent rollback mechanisms, ensure that if an interruption occurs at any stage of the update process, the system can safely and automatically recover to the previous known good state, fundamentally avoiding the risk of bricking.

[0025] 3. The embedded self-closing verification agent and targeted test cases can immediately and automatically verify the functions of key change points after the update is completed, discover potential problems before the vehicle leaves the factory or before the user notices them, and automatically roll back, forming an intelligent quality assurance closed loop.

[0026] 4. Fine-grained differential based on functions and data segments, compared to block-based differential, can more accurately extract the changed parts and remove redundant information around the unchanged code, thereby generating smaller differential packets and improving transmission efficiency. Attached Figure Description

[0027] Figure 1 The flowchart shows the dynamic differential update method of the intelligent self-closed-loop vehicle light controller software of the present invention. Figure 2 This is a schematic diagram of the system that applies the dynamic differential update method of the intelligent self-closed-loop vehicle light controller software according to the present invention. Detailed Implementation

[0028] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0029] Example 1 like Figure 1 As shown, this embodiment provides a dynamic differential update method for intelligent self-closed-loop vehicle light controller software, including the following steps: Step S1: Preprocess the executable files of the old and new versions, as well as the corresponding compiled files, then perform differential calculations on the function and data segments to generate a dynamic integration script and construct a complete differential package ΔF. This embodiment not only compares F... old With F new The binary differences are further analyzed by combining the symbol table and linker mapping file generated at compile time for dynamic code analysis. Specifically: Step S11: Preprocess the executable files of the new and old versions, as well as the corresponding compiled files of the new and old versions: The compilation process includes a symbol table file and a linker file. The process involves parsing the symbol table file and the linker file, establishing a mapping between function names and their absolute addresses or relative offsets in memory, and establishing a mapping between global variable names and their absolute addresses or relative offsets in memory. Simultaneously, disassembly is used to identify older versions of the executable file F. old and the new version of executable file F new The boundary information includes function boundaries and data segment boundaries.

[0030] Step S12: Perform the difference calculation between the function segment and the data segment: This embodiment performs difference comparison based on symbol and boundary information, using functions and initialized data segments as basic units, rather than fixed-size binary blocks. Specifically, for each function in F... new The function Func handles changes to the content (addition, deletion, or modification). i and Data segment j It uses an improved binary differential algorithm (e.g., an improved version of BSDiff that changes instruction relative addresses) to calculate its relative to F. old The difference data ΔF in i and ΔF j .

[0031] Next, analyze the call dependencies and data references between the basic units that have changed. For example, if function A calls function B, and function B is modified, the address of the instruction in function A that calls function B needs to be relocated.

[0032] Step S13: Generate dynamic integration script Π: In this embodiment, the integration script Π is an ordered list of operation instructions that guides the LCU on how to complete the update with minimal resource consumption. All operation instructions are atomic operations, and each instruction includes the operation type, operation parameters, and dependencies.

[0033] Operation types: such as COPY (copy unchanged blocks), PATCH (apply differential), RELOC FUNC (Function address relocation), RELOC DATA (Data pointer relocation), FILL (fill in a specific value), CHECKSUM (calculate the checksum).

[0034] Operation parameters: including source address (in F) old (or temporary buffer), target address (in the Flash backup area), data size, reference identifier pointing to a specific differential data block in the differential data area Σ, etc.

[0035] Dependency: Declares which other operations must be completed before this operation can be executed.

[0036] The dynamism of this example is reflected in the fact that the generation of the integrated script Π takes into account the Flash layout of the LCU (such as the address offset of the A / B area in dual-image setups) and automatically calculates the target address. Simultaneously, it breaks down large change functions into multiple sequential PATCH operations, creating conditions for memory block scheduling on the terminal.

[0037] Step S14: Construct the complete difference package ΔF: The differential packet ΔF generated in this embodiment is a structured data packet, which is usually encapsulated in TLV (Type-Length-Value) format. The differential packet ΔF includes a header, metadata area, integration script area, differential data area, verification test case area, and digital signature area.

[0038] Header: Contains information such as the Magic Number, the version of the difference packet ΔF, and the total size of the difference packet ΔF.

[0039] Metadata area Γ: Contains F old and F new The version number, password hash (such as SHA-256), firmware size, Flash layout requirements, and a list of functions and data segments changed in this update.

[0040] Integrated Script Area: Used to store the integrated scripts in binary or text format generated above.

[0041] Differential data area Σ: Used to sequentially store all calculated differential data blocks ΔF1, ΔF2, ... ΔF nEach data block has header information, which is associated with the instructions in the integration script Π via an ID.

[0042] Verification Case Area ξ: In this embodiment, automated test scripts for the updated content will be stored. The test cases involved include: preset conditions (such as setting simulated input), triggering actions (such as sending a specific CAN message), expected results (such as asserting that a certain output pin is high level, or that a certain internal state variable is a specific value), and post-cleanup.

[0043] Digital signature area: In this embodiment, the hash value of the entire differential ΔF packet, excluding the signature area, is calculated and encrypted using the cloud private key, which is used by the LCU to verify the integrity of the data and the credibility of the source.

[0044] Step S2: Distribute the differential packet ΔF to the target LCU through the vehicle gateway, and perform system compatibility checks and resource pre-assessment. Specifically: First, the differential packet ΔF is encrypted, signed, and then transmitted to the vehicle gateway, which then distributes it to the target LCU. Then, the smart update client in the target LCU first verifies the signature to ensure that the packet has not been tampered with and that the source is trustworthy. Then it parses the differential packet ΔF and checks the system compatibility and performs resource pre-evaluation based on the information in the metadata area Γ to avoid performing updates due to hardware incompatibility or insufficient resources, which could lead to the system becoming "bricked" or malfunctioning.

[0045] System compatibility checks include: 1. Verify that the target hardware model, chip ID, peripheral version, etc. specified in the metadata area Γ are completely matched with the target LCU to prevent software used for Type A headlights from being flashed onto Type B headlights.

[0046] 2. Check whether the target LCU's bootloader version, underlying driver, operating system kernel version, etc., meet the requirements of the new software F. new Minimum requirements for operation.

[0047] Resource pre-assessment includes: 1. Calculate and verify whether the available space of the Backup Slot is greater than F. new The estimated size (including temporary data during the update process) is calculated, while checking whether there is enough space in the non-volatile memory (NVM) status area to record the operation log.

[0048] 2. The intelligent update client within the LCU parses the integrated script Π, extracting the estimated peak memory requirements of all atomic operations. It then queries the resource monitor to obtain the total amount of continuous or fragmented memory that the target LCU can guarantee in a stable state before the update task starts.

[0049] If both system compatibility and resource pre-assessment meet the requirements, proceed to step S3; if either system compatibility or resource pre-assessment fails to meet the requirements, immediately terminate the update process, do not perform any Flash rewriting operations, and perform a rollback operation.

[0050] Step S3: Monitor memory resources and dynamically schedule them using a scheduling algorithm, then execute each atomic operation instruction in the integrated script Π. Specifically: Step S31: Monitor memory resources and dynamically schedule memory resources using a scheduling algorithm. The resource monitor is used to obtain real-time information on currently available RAM fragments, and all available RAM fragments are represented as a set of available memory blocks M = {(base addr 1, size1), (base addr 2, size2), ... (base addr n,sizen)}.

[0051] The integrated script Π is read by a dynamic memory scheduler, and the dependencies between each atomic operation within Π are analyzed to determine the topological order. Assume this update modifies two functions and one piece of data: Function A: calculates headlight brightness; Function B: adjusts the beam pattern, which calls Function A; Global variable C: maximum headlight current limit. After analysis, atomic operations for these three modified units are generated, but they cannot be executed out of order.

[0052] Dependency 1 (data dependency) is as follows: If function B calls function A, then function A must be updated (PATCH) first to determine its new memory address before function B can be updated. This is because updating function B requires re-registering (RELOC) the address of the instruction that calls function A to the new address of function A. Therefore, the order is: PATCH(A) - RELOC(address of function A) - PATCH(B).

[0053] Dependency 2 (Control Dependency): When function A executes, it needs to read the value of global variable C. Therefore, the new data C must be prepared first to ensure that the updated function A calculates correctly. The order is: PATCH(C) -> PATCH(A) In summary, a valid topological order is: PATCH(C) - PATCH(A) -> RELOC (the call to A in B) - PATCH(B).

[0054] Based on the available memory block set M, the atomic operation set Op, and the dependency relationship (Op) between atomic operations, a scheduling algorithm is used for scheduling, allocating one or more memory blocks for each atomic operation, thus minimizing the peak memory usage during the entire update process. Memory Minimize. The set of atomic operations Op is each independent operation (op) parsed and extracted from the ensemble script Π. 1, op2, …op n Extract the atomic operations and place them into a set, forming the atomic operation set Op, where each atomic operation has its required minimum buffer size buf. min (op n ) and the size of the data to be processed (size(op)) n ).

[0055] The scheduling algorithm in this embodiment employs a combination of a greedy algorithm and a best-fit strategy. The scheduling algorithm specifically includes the following steps: Step S311: Perform topological sorting on the atomic operations in the atomic operation set Op to obtain a linear execution sequence that satisfies the dependencies; Step S312: Sequentially process each atomic operation op in the execution sequence. n ; Step S313: In the current set of memory blocks M, find the smallest buffer size buf whose size satisfies size ≥ minimum buffer size buf. min (op n The goal is to find the smallest memory block among all the memory blocks that meet the size criteria. This is done to reserve a large block of memory for possible large operations later. Step S314: Allocate the memory block found in step S313 to op. n Perform the operation, and once completed, immediately release the memory block and mark it as reusable; Step S315: Update the memory state of the memory block set M and continue processing the next atomic operation.

[0056] Step S32: Execute each atomic operation instruction in the integrated script Π. The execution flow is as follows: According to the instructions, from the Active area of ​​Flash (where F is stored) old In the process, the baseline data that needs to be patched is read into the memory buffer allocated by the scheduler.

[0057] The corresponding differential data block is read from the differential data area Σ, merged with the baseline data in memory, and the target data block is generated.

[0058] Calculate the temporary checksum (such as CRC32) of the generated target data block, compare the temporary checksum with the expected checksum in the instruction, and if they do not match, declare the operation a failure.

[0059] The target data block that passes verification is atomically written to a specified location in the Flash Backup area. Atomicity here can usually be guaranteed in one or more of the following ways: 1. Using the smallest programmable unit of Flash (such as a Page) for operation; 2. Backing up the target sector before writing and restoring it if the write fails; 3. Using Flash that supports atomic writing or implementing it through a file system or log structure.

[0060] The success status of this atomic operation and the address range written are recorded in a non-volatile memory area (NVM) with power loss protection.

[0061] This embodiment employs a reliable dual-mirror update and rollback mechanism to ensure the security and stability of the system during the update process. Specifically, the flash memory of the headlight controller (LCU) is divided into two independent areas of equal capacity: the main running area (Active Slot) and the backup update area (Backup Slot).

[0062] When the system is operating normally, it boots from the main runtime area containing the stable version of the software. When a software update is performed, all new version data is written to the backup update area. The backup update area is only marked as ready after all update operations for the new version have been successfully executed and fully recorded in non-volatile memory (NVM).

[0063] If an unexpected interruption occurs during the update process, or if the self-closed-loop verification fails after the update is completed, the system's bootloader will make a decision based on the operation logs recorded in NVM: if the backup update area is ready but the verification fails, or if the update process encounters a serious error, the system will automatically clear the incomplete data in the backup update area and continue to boot from the original version in the main runtime area, thereby achieving a safe automatic rollback and ensuring that the controller is always available.

[0064] Step S4: Perform intelligent self-closed-loop verification. Specifically: When the new version of the executable file F in the Flash Backup area new After the update is complete and passes the integrity verification, the system restarts and switches to the Flash Backup area for startup.

[0065] Step S41, New version executable file F new After running, start the verification agent: New version executable file F newAfter running, the self-closing verification agent will be started first. The new version executable file F... new Upon initial startup, the bootloader checks a flag set by the update process. If the flag indicates that an update has just been completed and is pending verification, a self-closing verification agent is initiated.

[0066] Step S42: Execute the verification test cases in the differential package: The agent reads the verification test cases carried in the differential packet ΔF. These verification test cases are designed for the functions / data segments affected by this change. For example, if the turn signal control logic is updated, verification test cases simulating left and right turn signal inputs are used, and a test sequence is used to verify whether the corresponding turn signal output is correct by listening to the CAN bus or internal signals.

[0067] Step S43: The verification agent inputs control signals (such as CAN messages) to the LCU itself through software simulation or control of the hardware test switch, while listening to the status of the LCU's output pins or the bus messages it sends.

[0068] Step S44: Compare the expected output with the actual output and generate a detailed verification report.

[0069] Step S45: Conduct decision-making closed-loop and feedback: If all verification test cases pass, the verification agent will send a successful verification report (containing timestamps and summaries of the execution results of each verification test case) to the vehicle gateway via the vehicle network; simultaneously, it will clear the pending verification flag and mark the Backup Slot in the backup update area as a stable version; the vehicle gateway will notify the cloud server of the successful update and erase the old version executable file F in the ActiveSlot of the main runtime area. old To free up space.

[0070] If any verification test case fails, the verification agent immediately records detailed failure information (such as which test case failed, the expected value, and the actual value), and then triggers a forced restart by calling a system service or setting a specific register. Upon restarting, the bootloader detects the verification failure flag and will not switch boot slots, but will continue from the main runtime active slot (i.e., the intact old version of the executable file F). old The system is activated to enable automatic rollback. After rollback, the LCU reports update failure and verification failure logs to the cloud server through the vehicle gateway for developers to analyze.

[0071] Example 2 like Figure 2As shown, this embodiment provides a system that applies the dynamic differential update method of the intelligent self-closed-loop vehicle light controller software of Embodiment 1. The overall system architecture is: cloud server, vehicle gateway and LCU, whose collaborative workflow forms a closed loop.

[0072] The cloud server is used to store software versions, perform intelligent differential analysis, generate structured dynamic differential packages, and securely encrypt and sign the differential packages.

[0073] The vehicle gateway, acting as a vehicle domain gateway, is used to securely download differential packets from the cloud server and distribute them to the target LCUs, while also aggregating the LCUs' update status reports.

[0074] The LCU is the main execution and self-closing verification unit for updates. Internally, it runs an intelligent update client, which coexists with the application or resides in a separate protected partition. This client is responsible for performing differential packet verification, parsing, resource scheduling, atomic integration, and, after the update, initiating a self-closing verification agent to perform automated testing of software functions.

[0075] The specific embodiments described above further illustrate the technical problems, technical solutions, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A dynamic differential update method for intelligent self-closed-loop vehicle light controller software, characterized in that, Includes the following steps: Step S1: Preprocess the executable files of the new and old versions and the corresponding compilation files of the executable files of the new and old versions, then perform differential calculation of function segment and data segment, generate dynamic integration script, and build a complete differential package ΔF; Step S2: Distribute the differential packet ΔF to the target LCU through the vehicle gateway, and perform system compatibility checks and resource pre-assessment; Step S3: Monitor memory resources and dynamically schedule memory resources using a scheduling algorithm, then execute each atomic operation instruction in the integrated script Π. Step S4: Perform intelligent self-closed loop verification.

2. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that, In step S11, the executable files of the new and old versions, as well as the corresponding compiled files, are preprocessed, specifically including the following steps: The compiled files include symbol table files and linker files. The symbol table files and linker files are parsed to establish mappings between function names and their absolute addresses or relative offsets in memory, and to establish mappings between global variable names and their absolute addresses or relative offsets in memory. Simultaneously, disassembly is used to identify older versions of executable files (e.g., F). old and the new version of executable file F new The boundary information in the data segment includes function boundaries and data segment boundaries.

3. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that, In step S12, the difference calculation between the function segment and the data segment is performed, which specifically includes the following steps: This embodiment is based on symbol and boundary information, for each in F new Function Func that changes the content i and Data segment j It uses an improved binary difference algorithm to calculate its relative to F old The difference data ΔF in i and ΔF j ; Then, analyze the call dependencies and data reference relationships between the basic units that have changed.

4. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that: The integrated script Π is an ordered list of operation instructions. All operation instructions are atomic operations, and each operation instruction includes operation type, operation parameters, and dependencies.

5. The dynamic differential update method for intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that: The differential packet ΔF includes a header, metadata area, integration script area, differential data area, verification test case area, and digital signature area.

6. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that, In step S2, the differential packet ΔF is distributed to the target LCU through the vehicle gateway, and system compatibility checks and resource pre-assessments are performed. Specifically, this includes the following steps: First, the differential packet ΔF is encrypted and signed before being transmitted to the vehicle gateway, and then distributed by the vehicle gateway to the target LCU; Then, the smart update client in the target LCU first verifies the signature to ensure that the packet has not been tampered with and that the source is trustworthy. Then it parses the differential packet ΔF and checks system compatibility and performs resource pre-assessment based on the information in the metadata area Γ. If both system compatibility and resource pre-assessment meet the requirements, proceed to step S3; if either system compatibility or resource pre-assessment fails to meet the requirements, immediately terminate the update process, do not perform any Flash rewriting operations, and perform a rollback operation.

7. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that, In step S3, memory resources are monitored, and memory resources are dynamically scheduled using a scheduling algorithm. Specifically, this includes the following steps: The resource monitor obtains the currently available RAM fragment information in real time, and represents all available RAM fragment information as a set of available memory blocks M. The integrated script Π is read by a dynamic memory scheduler, the dependencies between each atomic operation in the integrated script Π are analyzed, and the topological order is sorted out. Based on the set of available memory blocks M, the set of atomic operations Op, and the dependencies (Op) between atomic operations, a scheduling algorithm is used for scheduling. One or more memory blocks are allocated to each atomic operation, and each atomic operation has its required minimum buffer size buf. min (op n ) and the size of the data to be processed (size(op)) n ).

8. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 7, characterized in that, The scheduling algorithm specifically includes the following steps: Step S311: Perform topological sorting on the atomic operations in the atomic operation set Op to obtain a linear execution sequence that satisfies the dependencies; Step S312: Sequentially process each atomic operation op in the execution sequence. n ; Step S313: In the current set of memory blocks M, find the smallest buffer size buf whose size satisfies size ≥ minimum buffer size buf. min (op n The memory blocks are defined, and the smallest memory block is found among all memory blocks that meet the size condition. Step S314: Allocate the memory block found in step S313 to op. n Perform the operation, and once completed, immediately release the memory block and mark it as reusable; Step S315: Update the memory state of the memory block set M and continue processing the next atomic operation.

9. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 1, characterized in that, In step S4, intelligent self-closed-loop verification is performed, which specifically includes the following steps: Step S41, New version executable file F new After running, start the verification agent: Step S42: Execute the verification test cases in the differential package: Step S43: The verification agent inputs control signals to the LCU itself through software simulation or control of the hardware test switch, and at the same time listens to the status of the LCU's output pins or the bus messages it sends. Step S44: Compare the expected output with the actual output and generate a verification report; Step S45: Conduct decision-making closed-loop and feedback.

10. The dynamic differential update method for the intelligent self-closed-loop vehicle light controller software according to claim 9, characterized in that, In step S45, the decision-making loop and feedback are performed, specifically including the following steps: If all verification test cases pass, the verification agent will send a successful verification report to the vehicle gateway through the vehicle network; at the same time, it will clear the pending verification flag and mark the Backup Slot in the backup update area as a stable version. The vehicle gateway notifies the cloud server that the update was successful and erases the old version of executable file F from the Active Slot in the main runtime area. old； If any verification test case fails, the verification agent immediately records the failure information and triggers a forced restart. When the bootloader detects the verification failure flag during restart, it will not switch the boot slot and will continue to start from the main running area Active Slot to achieve automatic rollback. After rollback, the LCU reports the update failure and verification failure logs to the cloud server through the vehicle gateway.

Images