OTA guarantee method based on vehicle-cloud collaborative digital twinborn rehearsal and shadow link

Abstract

The invention provides an OTA guarantee method based on a vehicle cloud collaborative digital twinborn rehearsal and shadow link, and the method comprises the steps: a cloud side generates a feature fingerprint through digital twinborn simulation based on the hardware portrait of a target vehicle and the content of an upgrade package; synchronously issuing the feature fingerprint and the upgrade patch to a vehicle main system and an independent rescue subsystem; when the vehicle main system executes upgrading, the independent rescue subsystem collects physical layer feature data of the service controller in real time; dynamically comparing the physical layer feature data with the feature fingerprint to obtain a comparison result; if the comparison result exceeds the tolerance range, an active fusing protection mechanism is triggered; and if the local repair fails, establishing communication with the cloud through a shadow link independent of the vehicle main system, receiving a repair instruction and executing remote self-healing operation. In the mode, dynamic risk prediction is realized through digital twinborn rehearsal, and remote self-healing is implemented by means of an independent shadow link after the system fails, so that the brick changing risk and the after-sales cost are remarkably reduced.

Description

Technical Field

[0001] This invention relates to the field of automotive intelligent design technology, and in particular to an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. Background Technology

[0002] With the development of software-defined vehicles, over-the-air (OTA) download technology has become a core means of vehicle function iteration. Existing solutions generally adopt vehicle-to-cloud interaction and A / B partition backup mechanisms. However, these rely on static access conditions and cannot detect dynamic environmental changes and hardware behavior anomalies during the upgrade process. Furthermore, rescue operations are highly dependent on communication with the main system. Once the upgrade fails and the main system malfunctions, the vehicle becomes "offline and bricked," requiring costly on-site manual rescue. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. The method achieves dynamic risk prediction through digital twin pre-simulation and implements remote self-healing after system failure by means of independent shadow link, which significantly reduces the risk of system failure and after-sales costs.

[0004] In a first aspect, embodiments of the present invention provide an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. The method includes: generating a feature fingerprint in the cloud based on the hardware profile of the target vehicle and the content of the upgrade package through digital twin simulation; the feature fingerprint includes expected timing nodes, logic execution current benchmark, and instruction response tolerance; synchronously sending the feature fingerprint and upgrade package to the vehicle main system and independent rescue subsystem; when the vehicle main system performs the upgrade, the independent rescue subsystem collects the physical layer feature data of the business controller in real time; dynamically comparing the physical layer feature data with the feature fingerprint to obtain the comparison result; if the comparison result exceeds the tolerance range, an active circuit breaker protection mechanism is triggered; if local repair fails, communication is established with the cloud through a shadow link independent of the vehicle main system to receive repair instructions and perform remote self-healing operation.

[0005] In a preferred embodiment of the present invention, the cloud-based system generates a feature fingerprint based on the hardware profile of the target vehicle and the content of the upgrade package through digital twin simulation, including: acquiring the hardware parameters of the target vehicle; the hardware parameters include chip model, Flash media information, historical write / erase cycles, ambient temperature, and main frequency configuration; combining the hardware parameters and the instruction complexity of the upgrade package to construct a virtual upgrade simulation model; introducing a historical upgrade failure case library and optimizing the prediction accuracy of the virtual upgrade simulation model through transfer learning; and outputting a feature fingerprint containing timing, current, and latency tolerance.

[0006] In a preferred embodiment of the present invention, the above-mentioned independent rescue subsystem collects physical layer feature data of the service controller in real time, including: collecting service controller data; the service controller data includes: power rail current, voltage fluctuation, temperature change, bus load status and vehicle attitude sensor data; and constructing a time series feature window from the service controller data using a sliding window algorithm.

[0007] In a preferred embodiment of the present invention, the above-mentioned dynamic comparison of physical layer feature data and feature fingerprint to obtain the comparison result includes: aligning the real-time current sequence with the reference current sequence using a dynamic time warping algorithm; calculating the Pearson correlation coefficient within the sliding window to evaluate the command-power consumption coordination; when an anomaly is detected during the comparison, determining the root cause of the fault by combining vehicle attitude sensor data: if there is abnormal vibration, it is determined to be environmental interference, and the process is initiated to wait for retry or safely exit; if there is no abnormal vibration, it is determined to be an internal fault in the upgrade process, and the active fuse protection mechanism is triggered; for internal faults, if the actual execution time exceeds the tolerance range, it is determined to be a deadlock or hangup state.

[0008] In a preferred embodiment of the present invention, the above-mentioned active circuit breaker protection mechanism includes: sending an interrupt signal to the service controller and pulling the reset pin high; switching the Flash bus permission to the independent rescue subsystem; loading the backup image from the isolated storage area and writing it to the boot partition; if the verification still fails after writing, recording the fault snapshot and marking it as a serious failure state.

[0009] In a preferred embodiment of the present invention, the above-mentioned communication with the cloud via a shadow link independent of the vehicle main system includes: activating an NB-IoT communication module independent of the vehicle main system; encapsulating the fault snapshot and the status of the vehicle main system into a lightweight data packet and uploading it to the cloud; the cloud dynamically selecting the optimal repair strategy based on the fault type and the real-time location of the vehicle; and issuing repair micro-patches or register-level instruction sets.

[0010] In a preferred embodiment of the present invention, the cloud dynamically selects the optimal repair strategy based on the fault type and the real-time location of the vehicle, including: if it is a logical deadlock, a register reset instruction is issued; if it is a boot sector corruption, a boot repair patch is issued; if it is a hardware compatibility problem, a downgraded version or an adapted driver is issued; if it is caused by environmental interference, a delayed retry instruction is issued and the user is advised to drive away from the interference area.

[0011] Secondly, embodiments of the present invention also provide an OTA assurance device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. The device includes: a feature fingerprint generation module, used to generate a feature fingerprint in the cloud based on the hardware profile of the target vehicle and the content of the upgrade package through digital twin simulation; the feature fingerprint includes expected timing nodes, logic execution current reference, and instruction response tolerance; a synchronous distribution module, used to synchronously distribute the feature fingerprint and upgrade package to the vehicle main system and the independent rescue subsystem; a physical layer feature data acquisition module, used to collect physical layer feature data of the business controller in real time when the vehicle main system performs an upgrade; a dynamic comparison module, used to dynamically compare the physical layer feature data and the feature fingerprint to obtain the comparison result; an active circuit breaker protection mechanism triggering module, used to trigger the active circuit breaker protection mechanism if the comparison result exceeds the tolerance range; and a repair instruction receiving module, used to establish communication with the cloud through a shadow link independent of the vehicle main system if local repair fails, receive repair instructions, and perform remote self-healing operation.

[0012] Thirdly, embodiments of the present invention also provide an electronic device, including a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link of the first aspect described above.

[0013] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link described in the first aspect above.

[0014] The embodiments of the present invention bring the following beneficial effects: This invention provides an OTA (Over-The-Air) assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. The method generates a feature fingerprint in the cloud based on the target vehicle's hardware profile and upgrade package content using digital twin simulation. This feature fingerprint and upgrade package are simultaneously sent to the vehicle's main system and an independent rescue subsystem. When the vehicle's main system performs an upgrade, the independent rescue subsystem collects physical layer feature data from the business controller in real time. The physical layer feature data is dynamically compared with the feature fingerprint to obtain the comparison result. If the comparison result exceeds the tolerance range, an active circuit breaker protection mechanism is triggered. If local repair fails, communication is established with the cloud through a shadow link independent of the vehicle's main system to receive repair instructions and perform remote self-healing. This method achieves dynamic risk prediction through digital twin pre-simulation and implements remote self-healing after system failure using an independent shadow link, significantly reducing the risk of system failure and after-sales costs.

[0015] Other features and advantages of this disclosure will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0016] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link, provided as an embodiment of the present invention; Figure 2 A flowchart of another OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link provided in an embodiment of the present invention; Figure 3 A schematic diagram of the structure of an OTA assurance device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Currently, with the evolution of the automotive software-defined vehicle (SDV) trend, over-the-air (OTA) technology has become a core means of vehicle function iteration, bug fixing, and performance optimization. Existing OTA upgrade processes typically employ a vehicle-cloud interaction model, where the cloud server pushes the upgrade package to the vehicle terminal. The vehicle's OTA manager triggers the upgrade program when specific access conditions are met (such as the gear being in Park, battery level exceeding a preset threshold, and network signal strength meeting requirements). To prevent upgrade failures from causing the vehicle controller (ECU) or domain controller (DCU) to malfunction, the industry generally adopts an A / B partition backup mechanism. This means that while the system is running on partition A, the upgrade content is written to partition B; if the upgrade verification fails, an attempt is made to roll back to the original partition.

[0021] However, existing OTA technology still carries a significant risk of "bricking" (system deadlock or inability to boot) in complex real-world vehicle usage environments. Its shortcomings are mainly reflected in the following two aspects: 1. Lag and Limitations of Static Admission Conditions: Existing OTA admission criteria rely solely on the vehicle's current static parameters, failing to detect dynamic environmental changes during the upgrade process. For example, the vehicle may enter a sleep state during the upgrade, causing voltage fluctuations, or electromagnetic interference from the parking environment (such as underground garages or tunnels) may lead to data write verification anomalies. Due to the lack of anticipated modeling of hardware behavior characteristics (such as current, computational load, and write time) during the upgrade process, vehicles often only trigger passive rollback after a complete system crash or verification failure. In some extreme cases, if the underlying bootloader or core file system experiences a hardware-level freeze during write operations, the existing A / B switching mechanism will fail due to logical deadlock, causing the vehicle to be unable to start and recover autonomously.

[0022] 2. Limited Reliability to Rely on Main Communication Link: Current OTA (Over-The-Air) rescue solutions heavily depend on the normal operation of the main system. If an upgrade fails, resulting in damage to the main domain control system or loss of connection to the main communication gateway, the vehicle will be completely "offline," and the cloud cannot remotely obtain fault logs or issue repair commands. In this situation, the only option is usually to manually tow the vehicle to an after-sales service center for a physical system reset, which not only incurs high after-sales costs but also severely impacts the user experience. The root cause of this problem is that the existing architecture lacks a rescue channel independent of the main system, possessing environmental awareness and a simplified self-healing function, making it impossible to achieve precise external system intervention and repair in a "frozen" or "partially bricked" system state.

[0023] Based on this, the present invention provides an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. This method generates a feature fingerprint through digital twin simulation based on the hardware profile of the target vehicle and the content of the upgrade package in the cloud. The feature fingerprint and the upgrade package are simultaneously sent to the vehicle's main system and an independent rescue subsystem. When the vehicle's main system performs an upgrade, the independent rescue subsystem collects the physical layer feature data of the business controller in real time and dynamically compares the physical layer feature data with the feature fingerprint to obtain the comparison result. If the comparison result exceeds the tolerance range, an active circuit breaker protection mechanism is triggered. If local repair fails, communication is established with the cloud through a shadow link independent of the vehicle's main system to receive repair instructions and perform remote self-healing operations. In this method, dynamic risk prediction is achieved through digital twin pre-simulation, and remote self-healing is implemented after system failure using an independent shadow link, significantly reducing the risk of system failure and after-sales costs.

[0024] To facilitate understanding of this embodiment, we will first provide a detailed description of an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link disclosed in this embodiment of the invention.

[0025] Example 1 This invention provides an OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. Figure 1 This is a flowchart illustrating an OTA (Over-The-Air) assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link, provided as an embodiment of the present invention. Figure 1 As shown, the OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link may include the following steps: In step S101, the cloud generates a feature fingerprint based on the hardware profile of the target vehicle and the content of the upgrade package through digital twin simulation.

[0026] Among them, the characteristic fingerprint includes the expected timing node, the logic execution current reference, and the instruction response tolerance.

[0027] Specifically, based on the hardware profile of the target vehicle and the content of the upgrade package, the cloud generates a feature fingerprint through digital twin simulation. This can include: obtaining the hardware parameters of the target vehicle; the hardware parameters include chip model, Flash media information, historical write / erase cycles, ambient temperature, and main frequency configuration; combining the hardware parameters and the instruction complexity of the upgrade package to construct a virtual upgrade simulation model; introducing a historical upgrade failure case library and optimizing the prediction accuracy of the virtual upgrade simulation model through transfer learning; and outputting a feature fingerprint that includes timing, current, and latency tolerance.

[0028] Step S102: Simultaneously send the feature fingerprint and upgrade package to the vehicle main system and the independent rescue subsystem.

[0029] In step S103, when the vehicle main system performs an upgrade, the independent rescue subsystem collects physical layer characteristic data of the business controller in real time.

[0030] Specifically, the independent rescue subsystem collects physical layer characteristic data of the business controller in real time, which may include: collecting business controller data; business controller data includes: power rail current, voltage fluctuation, temperature change, bus load status and vehicle attitude sensor data; and constructing a time series feature window from the business controller data using a sliding window algorithm.

[0031] Step S104: Dynamically compare the physical layer feature data with the feature fingerprint to obtain the comparison result.

[0032] Specifically, the comparison results are obtained by dynamically comparing physical layer feature data with feature fingerprints. This can include: aligning the real-time current sequence with the reference current sequence using a dynamic time warping algorithm; calculating the Pearson correlation coefficient within the sliding window to evaluate the command-power consumption coordination; and determining the root cause of the fault by combining vehicle attitude sensor data when an anomaly is detected during the comparison: if abnormal vibration is present, it is determined to be environmental interference, and the process is initiated to wait for retry or safely exit; if there is no abnormal vibration, it is determined to be an internal fault in the upgrade process, and the active circuit breaker protection mechanism is triggered; for internal faults, if the actual execution time exceeds the tolerance range, it is determined to be a deadlock or hangup state.

[0033] Triggering the active circuit breaker protection mechanism may include: sending an interrupt signal to the service controller and pulling the reset pin high; switching the Flash bus permission to the independent rescue subsystem; loading the backup image from the isolated storage area and writing it to the boot partition; if the verification still fails after writing, recording the fault snapshot and marking it as a critical failure state.

[0034] In step S105, if the comparison result exceeds the tolerance range, the active circuit breaker protection mechanism is triggered.

[0035] In step S106, if local repair fails, communication is established with the cloud through a shadow link independent of the vehicle's main system to receive repair instructions and perform remote self-healing operations.

[0036] The OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link provided in this invention can generate a feature fingerprint through digital twin simulation based on the hardware profile of the target vehicle and the content of the upgrade package in the cloud. This feature fingerprint and the upgrade package are then simultaneously sent to the vehicle's main system and an independent rescue subsystem. When the vehicle's main system performs an upgrade, the independent rescue subsystem collects the physical layer feature data of the business controller in real time and dynamically compares the physical layer feature data with the feature fingerprint to obtain the comparison result. If the comparison result exceeds the tolerance range, an active circuit breaker protection mechanism is triggered. If local repair fails, communication is established with the cloud through a shadow link independent of the vehicle's main system to receive repair instructions and perform remote self-healing operations. In this method, dynamic risk prediction is achieved through digital twin pre-simulation, and remote self-healing is implemented after system failure using an independent shadow link, significantly reducing the risk of system failure and after-sales costs.

[0037] Example 2 This invention also provides another OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link; this method is implemented on the basis of the above embodiment method; the method focuses on describing the specific implementation of establishing communication with the cloud through a shadow link independent of the vehicle main system.

[0038] Figure 2 A flowchart of another OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link provided by an embodiment of the present invention is shown below. Figure 2 As shown, establishing communication with the cloud via a shadow link independent of the vehicle's main system may include the following steps: Step S201: Activate the NB-IoT communication module, which is independent of the vehicle's main system.

[0039] Step S202: Encapsulate the fault snapshot and the status of the vehicle's main system into a lightweight data packet and upload it to the cloud.

[0040] In step S203, the cloud dynamically selects the optimal repair strategy based on the fault type and the vehicle's real-time location.

[0041] Specifically, the cloud dynamically selects the optimal repair strategy based on the fault type and the vehicle's real-time location. This may include: if it is a logical deadlock, issuing a register reset command; if it is a boot sector corruption, issuing a boot repair patch; if it is a hardware compatibility issue, issuing a downgraded version or an adapted driver; if it is caused by environmental interference, issuing a delayed retry command and advising the user to drive away from the interference area.

[0042] Step S204: Issue a repair micro-patch or register-level instruction set.

[0043] As an example of this application: Regarding the working principle of the product: Cloud-based: The cloud system of the digital twin pre-simulation algorithm based on multi-dimensional parameter coupling is not just a distribution source of upgrade packages, but also achieves deep prediction of single-vehicle upgrade behavior by running a "virtual upgrade simulator" with full-stack hardware awareness capabilities.

[0044] Implementation logic: A cloud server maintains a "Hardware Fingerprint DB" covering the entire lifecycle of a vehicle. This database records the chip model, Flash media batch, and historical erase / write statistics (P / E Cycles) for each vehicle. Historical erase / write data is no longer considered a cause of failure, but rather serves as a "timing evolution calibration parameter" to correct the baseline of Flash storage unit response latency to "erase-write" commands at different aging stages, thereby ensuring an accurate match between the simulation results and the actual state of each vehicle.

[0045] The core of the algorithm is to establish a mapping relationship between "software instruction flow and hardware physical representation" using a random forest or deep neural network regression model. This model generates a dynamic execution benchmark by performing density analysis on the binary instruction flow of the upgrade package and coupling it with environmental physical variables.

[0046] Model input variables: The data volume of the upgrade package and the corresponding instruction complexity distribution.

[0047] Storage media aging factor calculated based on P / E cycles (for fine-tuning) (Axis deviation).

[0048] : Current vehicle ambient temperature (used to compensate for power consumption offset caused by semiconductor thermal effects).

[0049] : The main frequency configuration and dynamic frequency modulation (DVFS) status of the service controller.

[0050] Model output (feature fingerprint vector) Based on the above input, the algorithm outputs a set of feature fingerprint vectors that evolve over time. : (Expected timing nodes): The standard execution time points for each stage (such as boot sector erasure, image writing, hash verification) based on instruction density prediction.

[0051] (Logic Execution Current Baseline): Predicts the characteristic pulse current generated by the core power rail of the SoC when executing a specific code segment (such as Flash internal charge pump startup or high-volume bus load). This parameter serves as a key basis for determining whether the SoC core process is deadlocked and whether the hardware is responding properly.

[0052] (Command Response Tolerance): Comprehensive Aging Factors The maximum tolerable delay is used to set the threshold for determining the intervention of the shadow system, so as to avoid false intervention caused by normal aging of the medium.

[0053] Vehicle-side: Time series comparison algorithm based on dynamic windows This algorithm runs on an isolated rescue microprocessor (Tiny-MCU). Its core task is to determine in real time whether the kernel process of the business controller (SoC) has deviated from the "safety roadmap" issued by the cloud by backtracking through physical layer features.

[0054] Algorithm Name: Dynamic Time Warping (DTW) + Sliding Window for Difference Implementation steps: High-frequency sampling: The rescue system utilizes a high-gain sampling circuit integrated on the power rail of the business controller (SoC) core to acquire its characteristic current at a period of 1ms. This current represents the dynamic power consumption characteristics of the SoC's internal logic gate array when executing specific OTA commands.

[0055] Feature window construction: Set a time length as The sliding window. Since the timing fine-tuning due to Flash aging factors has been considered during cloud-based pre-playback, Tiny-MCU will display the real-time acquired data... Sequence and cloud fingerprint benchmark after lifetime calibration Normalization is performed.

[0056] Co-correlation calculation: Calculate the Pearson correlation coefficient between the actual current sequence and the reference sequence within the calculation window. To assess the current "instruction-power coherence" of the SoC:

[0057] Decision logic: Process deviation determination (logical deviation): If the correlation coefficient And the duration exceeds This indicates that although the SoC is still running, its physical power consumption characteristics are completely inconsistent with the expected OTA write operation. This situation is usually judged as "illegal process tampering" or "instruction execution flow deviation," suggesting that the upgrade program has lost effective control over the underlying hardware.

[0058] Timing response determination (deadlock / hangover): The algorithm monitors the completion signal of a specific stage. If the actual execution time of the current stage... ,in This is a fault tolerance coefficient that is dynamically adjusted based on the current Flash aging state. If at this time... Maintaining a constant high current without pulse characteristics indicates a kernel deadlock (HardHang); if at this time... The manifestation is extremely low current, which is determined to be a core power supply shutdown or an abnormal system restart (SilentBrick).

[0059] Shadow System: The core of system repair lies in its out-of-band management architecture.

[0060] When the Service Controller (SOC) is unable to execute normal instructions due to firmware corruption or logical deadlock, the shadow system forcibly intervenes through the physical layer interface. Its underlying repair logic is divided into the following three stages: Physical layer state reset and mode reconstruction: After determining that the SOC is bricked, the rescue microprocessor (Tiny-MCU) directly changes the SOC's hardware operating state through a physical connection: Hardware forced reset: Tiny-MCU applies a level signal to the RESET pin of the SOC through GPIO, forcibly terminating the abnormal flipping of all logic gate arrays inside, and returning the chip circuit to the initial power-on state.

[0061] Boot path redirection: Tiny-MCU synchronously controls the level combination of the BOOT_SEL (boot select) pin to change the boot source of the SOC from the built-in damaged Flash mapping to an external interface (such as UART or USB recovery mode) controlled by Tiny-MCU.

[0062] Bus access arbitration: By driving the analog multiplexer (MUX), Tiny-MCU disconnects the original connection between SOC and Flash on the physical link, and connects the Flash bus to Tiny-MCU's communication peripheral, thereby obtaining read and write access to the storage medium.

[0063] Atomic instruction injection: The shadow system utilizes the hardware debugging instruction set (JTAG / SWD) built into the SOC kernel for non-intrusive repair. Even if the SOC's operating system layer is completely corrupted, its hardware debugging logic can still respond when power is normal. Kernel register takeover: Tiny-MCU accesses the SOC's kernel debug registers through the SWD interface to obtain the accurate values ​​of the current program counter (PC) and stack pointer (SP), and locate the instruction address that caused the deadlock.

[0064] SRAM Data Overlay: Utilizing the memory mapping access function of the SWD interface, Tiny-MCU directly writes the binary repair patch sent from the cloud via the shadow link into the SOC's static random access memory (SRAM).

[0065] PC pointer relocation: Tiny-MCU sends an instruction to modify the SOC's program counter, forcibly pointing it to the starting address of the patched code in SRAM. After the SOC releases the reset, it will skip the damaged sectors in Flash and instead execute the recovery instructions in SRAM.

[0066] Precise data layer repair and link closure: After establishing control, the shadow system performs targeted data recovery to reduce the bandwidth consumption of the shadow link. Damaged data replacement: After parsing the fault snapshot in the cloud, only the damaged boot sector or critical configuration file (usually in the KB range) is sent out. Tiny-MCU uses the Flash bus it has taken over to overwrite specific physical addresses, repairing the underlying bootloader chain.

[0067] Independent communication backhaul: During the failure of the SOC main gateway (5G / Ethernet), all repair commands, status feedback, and verification results are transmitted via the NB-IoT shadow link. This link is not processed by the SOC but is directly controlled by the Tiny-MCU.

[0068] Self-test and release: After the repair is completed, Tiny-MCU monitors the startup current sequence of the SOC. If the current characteristics match the normal startup waveform in the pre-simulated fingerprint, it controls the MUX to return Flash privileges to the SOC and releases the reset signal, completing the system recovery.

[0069] As an example of this application: Regarding the product workflow: Step 1: Generate a "safe route map" in the cloud.

[0070] In addition to sending update.zip (an example update package file), the cloud will also send a safety_profile.json (a pre-processed update example) file. This JSON file records the following: "When the write progress reaches 45%, the current should jump from 100mA to 300mA, and the time should be in the range of 10s-15s" (example content description).

[0071] Step 2: Enable "Bypass Listening" in the Shadow System.

[0072] When the main system initiates the upgrade process Upgrade_Start, the shadow system is interrupted and awakened. It enters a non-intrusive monitoring mode, does not participate in business operations, and only monitors the "health status" of the business controller by means of system power consumption and master-slave communication messages.

[0073] Step 3: Active circuit breaker protection mechanism.

[0074] When the sliding window algorithm detects an anomaly (e.g., current drops to 0, indicating an abnormal restart of the main chip; or latency significantly exceeds the standard): The shadow system will immediately send a SUSPEND signal to the main system.

[0075] The shadow system pulls the RESET pin high, forcing the service controller to stop running.

[0076] The shadow system checks the GoldenImage of the Flash memory and writes the backup boot sector directly overwrites the damaged area via the SPI interface.

[0077] Step 4: External repair and rescue of the shadow link.

[0078] If the local backup also fails, proceed to the lowest level of the repair process: Status reporting: The shadow system sends the following information through an independent NB-IoT channel: {"error_node":"U-Boot","fail_offset":"0x4F20","current_voltage":"12.4V"} (this is an example).

[0079] Instruction pushdown: The raw register instruction set (instead of the entire upgrade package) is pushed down from the cloud.

[0080] Injection Repair: The shadow system simulates the JTAG protocol and injects these key bytes directly into the registers of the business controller, forcing it to skip the corrupted self-test code and directly boot into emergency maintenance mode.

[0081] Example 3 Corresponding to the above method embodiments, this invention provides an OTA assurance device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. Figure 3 This is a schematic diagram of an OTA assurance device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link, provided as an embodiment of the present invention. Figure 3 As shown, the OTA assurance device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link may include: The feature fingerprint generation module 301 is used to generate feature fingerprints in the cloud based on the hardware profile and upgrade package content of the target vehicle through digital twin simulation. The feature fingerprint includes expected timing nodes, logic execution current reference and instruction response tolerance.

[0082] The synchronous distribution module 302 is used to synchronously distribute the feature fingerprint and upgrade package to the vehicle main system and the independent rescue subsystem.

[0083] The physical layer feature data acquisition module 303 is used by the independent rescue subsystem to collect physical layer feature data of the business controller in real time when the vehicle main system performs an upgrade.

[0084] The dynamic comparison module 304 is used to dynamically compare physical layer feature data with feature fingerprints to obtain comparison results.

[0085] The active circuit breaker protection mechanism trigger module 305 is used to trigger the active circuit breaker protection mechanism if the comparison result exceeds the tolerance range.

[0086] The repair instruction receiving module 306 is used to establish communication with the cloud through a shadow link independent of the vehicle's main system if local repair fails, to receive repair instructions and perform remote self-healing operations.

[0087] The OTA (Over-The-Air) support device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link provided in this invention can generate a feature fingerprint through digital twin simulation based on the hardware profile of the target vehicle and the content of the upgrade package in the cloud. This feature fingerprint and the upgrade package are simultaneously sent to the vehicle's main system and an independent rescue subsystem. When the vehicle's main system performs an upgrade, the independent rescue subsystem collects the physical layer feature data of the business controller in real time and dynamically compares the physical layer feature data with the feature fingerprint to obtain the comparison result. If the comparison result exceeds the tolerance range, an active circuit breaker protection mechanism is triggered. If local repair fails, communication is established with the cloud through a shadow link independent of the vehicle's main system to receive repair instructions and perform remote self-healing operations. In this method, dynamic risk prediction is achieved through digital twin pre-simulation, and remote self-healing is implemented after system failure using an independent shadow link, significantly reducing the risk of system failure and after-sales costs.

[0088] In some embodiments, the feature fingerprint generation module is also used to obtain the hardware parameters of the target vehicle; the hardware parameters include chip model, Flash media information, historical write / erase cycles, ambient temperature, and main frequency configuration; combining the hardware parameters with the instruction complexity of the upgrade package, a virtual upgrade simulation model is constructed; a historical upgrade failure case library is introduced, and the prediction accuracy of the virtual upgrade simulation model is optimized through transfer learning; and a feature fingerprint containing timing, current, and latency tolerance is output.

[0089] In some embodiments, the physical layer feature data acquisition module is also used to acquire service controller data; the service controller data includes: power rail current, voltage fluctuation, temperature change, bus load status and vehicle attitude sensor data; the service controller data is constructed into a time series feature window using a sliding window algorithm.

[0090] In some embodiments, the dynamic comparison module is further configured to align the real-time current sequence with the reference current sequence using a dynamic time warping algorithm; calculate the Pearson correlation coefficient within the sliding window to evaluate the command-power consumption coherence; and when an anomaly is detected during comparison, determine the root cause of the fault by combining vehicle attitude sensor data: if abnormal vibration is present, it is determined to be environmental interference, and a waiting retry or safe exit process is initiated; if there is no abnormal vibration, it is determined to be an internal fault in the upgrade process, and an active fuse protection mechanism is triggered; for internal faults, if the actual execution time exceeds the tolerance range, it is determined to be a deadlock or hangup state.

[0091] In some embodiments, the dynamic comparison module is also used to send an interrupt signal to the service controller and pull the reset pin high; switch the Flash bus permission to the independent rescue subsystem; load the backup image from the isolated storage area and write it to the boot partition; if the verification still fails after writing, record the fault snapshot and mark it as a critical failure state.

[0092] In some embodiments, the repair instruction receiving module is further configured to activate an NB-IoT communication module independent of the vehicle's main system; encapsulate the fault snapshot and the status of the vehicle's main system into a lightweight data packet and upload it to the cloud; the cloud dynamically selects the optimal repair strategy based on the fault type and the vehicle's real-time location; and issues repair micro-patches or register-level instruction sets.

[0093] In some embodiments, the repair instruction receiving module is further configured to: issue a register reset instruction if the problem is a logical deadlock; issue a boot repair patch if the problem is a boot sector corruption; issue a downgraded version or an adapted driver if the problem is a hardware compatibility issue; and issue a delayed retry instruction and suggest that the user leave the interference area if the problem is caused by environmental interference.

[0094] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0095] Example 4 This invention also provides an electronic device for running the above-described OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link; see also Figure 4The diagram shows the structure of an electronic device, which includes a memory 400 and a processor 401. The memory 400 is used to store one or more computer instructions, which are executed by the processor 401 to realize the above-mentioned OTA guarantee method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link.

[0096] Furthermore, Figure 4 The electronic device shown also includes a bus 402 and a communication interface 403. The processor 401, the communication interface 403 and the memory 400 are connected via the bus 402.

[0097] The memory 400 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 403 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 402 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0098] Processor 401 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 401 or by instructions in software form. Processor 401 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 400, and processor 401 reads information from memory 400 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0099] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the above-mentioned OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0100] The computer program product for the OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link provided in this embodiment of the invention includes a computer-readable storage medium storing non-volatile program code executable by a processor. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0101] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0102] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0103] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0104] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link, characterized in that, The method includes: Based on the hardware profile of the target vehicle and the content of the upgrade package, the cloud generates a feature fingerprint through digital twin simulation; the feature fingerprint includes expected timing nodes, logic execution current reference, and instruction response tolerance. The characteristic fingerprint and the upgrade package are simultaneously sent to the vehicle's main system and the independent rescue subsystem; When the vehicle main system performs an upgrade, the independent rescue subsystem collects physical layer characteristic data of the business controller in real time; The physical layer feature data is dynamically compared with the feature fingerprint to obtain the comparison result; If the comparison result exceeds the tolerance range, the active circuit breaker protection mechanism is triggered; If local repair fails, communication is established with the cloud via a shadow link independent of the vehicle's main system to receive repair instructions and perform remote self-healing operations.

2. The method according to claim 1, characterized in that, The cloud-based system generates a feature fingerprint based on the target vehicle's hardware profile and upgrade package content, using digital twin simulation, including: Obtain the hardware parameters of the target vehicle; the hardware parameters include chip model, Flash media information, historical erase / write cycles, ambient temperature, and main frequency configuration; By combining the hardware parameters with the instruction complexity of the upgrade package, a virtual upgrade simulation model is constructed. A historical upgrade failure case library is introduced, and the prediction accuracy of the virtual upgrade simulation model is optimized through transfer learning; The output includes a feature fingerprint containing timing, current, and delay tolerance characteristics.

3. The method according to claim 1, characterized in that, The independent rescue subsystem collects physical layer characteristic data from the business controller in real time, including: Collect service controller data; the service controller data includes: power rail current, voltage fluctuation, temperature change, bus load status, and vehicle attitude sensor data; The business controller data is used to construct a time series feature window using a sliding window algorithm.

4. The method according to claim 1, characterized in that, The step of dynamically comparing the physical layer feature data with the feature fingerprint to obtain the comparison result includes: A dynamic time warping algorithm is used to align the real-time current sequence with the reference current sequence; Calculate the Pearson correlation coefficient within the sliding window to evaluate the command-power coordination. When an anomaly is detected during comparison, the root cause of the fault is determined by combining the vehicle attitude sensor data: If abnormal vibration is detected, it is determined to be environmental interference, and the process of waiting for retry or safely exiting is initiated. If there is no abnormal vibration, it is determined to be an internal fault during the upgrade process, triggering the active fuse protection mechanism; For internal faults, if the actual execution time exceeds the tolerance range, it is judged as a deadlock or hang.

5. The method according to claim 4, characterized in that, The mechanism for triggering active circuit breaker protection includes: Send an interrupt signal to the service controller and pull the reset pin high; Switch Flash bus permissions to the independent rescue subsystem; Load the backup image from the isolated storage area and write it to the boot partition; If the verification still fails after writing, record the fault snapshot and mark it as a critical failure state.

6. The method according to claim 5, characterized in that, The establishment of communication with the cloud via a shadow link independent of the vehicle's main system includes: Activate the NB-IoT communication module, which is independent of the vehicle's main system; The fault snapshot and the status of the vehicle's main system are encapsulated into a lightweight data packet and uploaded to the cloud. The cloud-based system dynamically selects the optimal repair strategy based on the fault type and the vehicle's real-time location. Issue micro-patches or register-level instruction sets to fix the issues.

7. The method according to claim 6, characterized in that, The cloud-based system dynamically selects the optimal repair strategy based on the fault type and the vehicle's real-time location, including: If it is a logical deadlock, then issue a register reset instruction; If the boot sector is corrupted, a boot repair patch will be issued. If the issue is hardware compatibility, a downgraded version or an adapted driver will be released. If the problem is caused by environmental interference, a delayed retry command will be issued and the user will be advised to drive away from the interference area.

8. An OTA assurance device based on vehicle-cloud collaborative digital twin pre-simulation and shadow link, characterized in that, The device includes: The feature fingerprint generation module is used to generate a feature fingerprint in the cloud based on the hardware profile of the target vehicle and the content of the upgrade package through digital twin simulation; the feature fingerprint includes expected timing nodes, logic execution current reference and instruction response tolerance; The synchronous distribution module is used to synchronously distribute the feature fingerprint and the upgrade package to the vehicle main system and the independent rescue subsystem; The physical layer feature data acquisition module is used by the independent rescue subsystem to collect physical layer feature data of the business controller in real time when the vehicle main system performs an upgrade. The dynamic comparison module is used to dynamically compare the physical layer feature data with the feature fingerprint to obtain the comparison result; An active circuit breaker protection mechanism triggering module is used to trigger the active circuit breaker protection mechanism if the comparison result exceeds the tolerance range; The repair instruction receiving module is used to establish communication with the cloud through a shadow link independent of the vehicle's main system if local repair fails, to receive repair instructions and perform remote self-healing operations.

9. An electronic device, characterized in that, The system includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the OTA assurance method based on vehicle-cloud collaborative digital twin pre-simulation and shadow link as described in any one of claims 1 to 7.

Images