An in-vehicle software base application layer digital twin verification and OTA closed-loop system

Abstract

The application discloses a kind of vehicle-mounted software base application layer digital twin verification and OTA closed loop system, it is related to electric digital data processing technical field, including window record module, interface record module, boundary correlation module and upgrade control module.Window record module records the running window of security protection area and generates window record, interface record module records the interface call request and interface call response issued by the application layer version to be verified in customer application area, boundary correlation module binds the same interface call through association serial number and call key value at isolation boundary and generates verification record containing window track sequence, and upgrade control module controls digital twin verification, HIL retest and OTA upgrade path according to final call state and version level verification record set.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, specifically to a digital twin verification and OTA closed-loop system for the application layer of an in-vehicle software base. Background Technology

[0002] As in-vehicle software platforms evolve towards centralization and service-orientation, vehicle control, diagnostics, communication, actuator protection, and OTA upgrade management are increasingly being uniformly scheduled by the software system. Application-layer functions typically call underlying platform services through standardized interfaces. This type of software interaction involves interface requests, response recording, operational status assessment, and upgrade control, representing a crucial technical scenario for in-vehicle application software verification and data processing control.

[0003] Currently, in vehicle electronic control platforms where the security protection zone and the customer application zone are isolated from each other, existing OTA verification or digital twin verification cannot reliably bind the same interface call request, interface call response and security operation window. This makes it difficult to accurately determine whether the interface call crosses windows, occupies restricted windows or prohibited windows. Consequently, digital twin verification, HIL retesting, shadow partition loading, formal switching and rollback lack a unified basis, increasing the risk of erroneous upgrade release or erroneous blocking. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the technical solution of this invention is as follows:

[0005] A digital twin verification and OTA closed-loop system for the application layer of an in-vehicle software base includes a window recording module, an interface recording module, a boundary association module, and an upgrade control module;

[0006] The window recording module is used to record the operating windows of the safety protection zone and generate window records containing window status and window number. The window status includes at least open, restricted and prohibited states.

[0007] The interface recording module is used to record the interface call requests and responses issued by the application layer version to be verified in the customer application area, and generate interface records containing call start records and call end records;

[0008] The boundary association module is located at the isolation boundary between the security protection zone and the customer application zone. The boundary association module writes the association sequence number when the interface call request passes through the isolation boundary, and writes the same association sequence number when the interface call response returns to the isolation boundary. It also combines the call start record, call end record, window record, and window trajectory sequence during the duration of the interface call corresponding to the same association sequence number into a verification record.

[0009] The boundary association module determines the final call status based on the window trajectory sequence, window number, and window status in the verification record. The final call status is used to characterize the completion status of the interface call in the running window of the security protection zone, cross-window status, restricted window entry status, and prohibited window entry status.

[0010] The upgrade control module issues upgrade control instructions based on the final call status and the set of verification records corresponding to the application layer version to be verified. The upgrade control instructions are used to control the corresponding upgrade path in the upgrade process of the application layer version to be verified, including digital twin verification, hardware-in-the-loop HIL retesting, differential package generation, shadow partition loading, formal switchover, delayed switchover, shadow partition loading blocking, and version rollback.

[0011] Furthermore, when there are multiple unclosed calls to the same interface object, the boundary association module maintains an unclosed call queue based on the call key value composed of the boundary channel identifier, the interface call object, the request sequence number, and the call handle, and looks up the corresponding call start record based on the call key value when the interface call response returns.

[0012] Furthermore, the verification record also includes a window trajectory sequence, which is used to record all window numbers and window states traversed during the process from when the request passes through the isolation boundary to when the response returns to the isolation boundary.

[0013] Furthermore, the window recording module divides the running window according to the base service status, diagnostic response status, communication transmission and reception status, actuator protection status, and OTA flashing status of the security protection zone;

[0014] And update the window number and window state when the running window is switched.

[0015] Furthermore, the interface recording module generates a call start record when the interface call request is issued by the client application area, and generates a call end record when the interface call response is returned to the client application area.

[0016] The call start record and call end record respectively record the direction of the interface call and the interface call object.

[0017] Furthermore, the boundary association module generates an association sequence number when the interface call request first crosses the isolation boundary, and writes the association sequence number into the call start record;

[0018] When the interface call response returns to the isolation boundary, the boundary association module writes the same association sequence number into the call end record.

[0019] Furthermore, the boundary association module reads the current window record when writing the association sequence number;

[0020] And write the window record corresponding to the interface call request into the call start record;

[0021] Write the window record corresponding to the API call response to the call end record.

[0022] Furthermore, the verification records include the associated sequence number, the call start record, the call end record, the window sequence number and window state corresponding to the call start record, the window sequence number and window state corresponding to the call end record, and the window trajectory sequence during the duration of the interface call.

[0023] Furthermore, the window trajectory sequence records the window number, window state, window start time, and window end time that passed during the continuous API call, according to the window switching time sequence.

[0024] Furthermore, the boundary association module first determines the window occupancy risk based on the window state in the window trajectory sequence, and then determines the call crossing situation based on the window sequence number in the window trajectory sequence;

[0025] If any window in the window trajectory sequence is in a prohibited state, it is determined to be a prohibited window occupancy state.

[0026] If a window trajectory sequence does not have a prohibited state but has a restricted state, it is determined to be a restricted window occupancy state.

[0027] If a window trajectory sequence does not contain any prohibited or restricted states, and contains two or more different window numbers, it is determined to be a cross-window state.

[0028] A window trajectory sequence that does not contain any prohibited or restricted states and contains only one window number is determined to be in a completed state within the window.

[0029] Furthermore, when the upgrade control module is in the final call state of the window completion state, it will input the verification record into the digital twin verification environment;

[0030] After the digital twin verification is passed, differential package generation instructions, shadow partition loading instructions, and formal switching instructions are generated based on the application layer version to be verified and the currently running application layer version. If the digital twin verification fails, delayed switching instructions or shadow partition loading blocking instructions are generated.

[0031] Furthermore, the digital twin verification environment generates simulation conditions based on the interface objects, call parameter summaries, call durations, window trajectory sequences, and final call states in the verification records. If the interface return status, actuator response deviation, communication confirmation time, and storage write results in the simulation conditions all meet the preset verification thresholds, the digital twin verification pass result is output; otherwise, the digital twin verification fail result is output.

[0032] Furthermore, when the final call state of the upgrade control module is a cross-window state or a restricted window occupancy state, the verification record will be used as the hardware-in-the-loop (HIL) retest input.

[0033] The delay switching instruction is maintained until the hardware-in-the-loop (HIL) retest is completed. The delay switching instruction is released after the hardware-in-the-loop (HIL) retest is passed. If the hardware-in-the-loop (HIL) retest fails, the delay switching instruction is maintained or a shadow partition loading blocking instruction is generated.

[0034] Furthermore, the hardware-in-the-loop (HIL) retest generates a retest script based on the verification records. The retest script includes at least the interface object, call parameter summary, window switching time, restricted or prohibited state triggering conditions, actuator response sampling items, communication confirmation sampling items, and storage write verification items.

[0035] Furthermore, when the final call state is the prohibited window occupancy state, the upgrade control module issues a shadow partition loading blocking command;

[0036] When the application layer version to be verified has been loaded into the shadow partition and has not been switched, issue a shadow partition clearing command;

[0037] When the application layer version to be verified has been switched, a version rollback command is issued to restore the vehicle electronic control platform to the stable version before the application layer version to be verified was switched.

[0038] Furthermore, the upgrade control module uses the set of verification records corresponding to the application layer version to be verified as the version-level decision object. If there is a prohibited window occupancy state or a failed digital twin verification result in the set of verification records, no formal switchover instruction will be generated. If there is a cross-window state or a restricted window occupancy state in the set of verification records and the hardware-in-the-loop (HIL) retest is not completed, the switchover instruction will be delayed. Only if all window completion states in the set of verification records have passed digital twin verification and all verification records that need to be retested have passed HIL retesting, a formal switchover instruction will be allowed to be generated.

[0039] The beneficial effects of this invention are as follows:

[0040] 1. By writing the same associated sequence number to the interface call request and interface call response at the isolation boundary, and combining it with the window record and window trajectory sequence of the security protection zone to form a verification record, the same interface call can establish a traceable association with the corresponding secure operation window, thereby solving the problem that the interface call status is difficult to determine accurately and the upgrade control lacks a unified basis in the existing technology in the isolation scenario. Attached Figure Description

[0041] Figure 1 This is a diagram showing the overall structure of the vehicle software base application layer digital twin verification and OTA closed-loop system of the present invention.

[0042] Figure 2 This is a flowchart of the window recording module of the present invention;

[0043] Figure 3 This is a flowchart of the interface recording module of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments 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, and 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.

[0045] Example 1

[0046] Please see Figures 1-3 This invention provides a digital twin verification and OTA closed-loop system for the application layer of an in-vehicle software base: including a window recording module, an interface recording module, a boundary association module, and an upgrade control module;

[0047] The window recording module is used to record the operating windows of the safety protection zone and generate window records containing window status and window number. The window status includes at least open, restricted and prohibited states.

[0048] The interface recording module is used to record the interface call requests and responses issued by the application layer version to be verified in the customer application area, and generate interface records containing call start records and call end records;

[0049] The boundary association module is located at the isolation boundary between the security protection zone and the customer application zone. The boundary association module writes the association sequence number when the interface call request passes through the isolation boundary, and writes the same association sequence number when the interface call response returns to the isolation boundary. It also combines the call start record, call end record, window record, and window trajectory sequence during the duration of the interface call corresponding to the same association sequence number into a verification record.

[0050] The boundary association module determines the final call status based on the window trajectory sequence, window number, and window status in the verification record. The final call status is used to characterize the completion status of the interface call in the running window of the security protection zone, cross-window status, restricted window entry status, and prohibited window entry status.

[0051] The upgrade control module issues upgrade control instructions based on the final call status and the set of verification records corresponding to the application layer version to be verified. The upgrade control instructions are used to control the corresponding upgrade path in the upgrade process of the application layer version to be verified, including digital twin verification, hardware-in-the-loop HIL retesting, differential package generation, shadow partition loading, formal switchover, delayed switchover, shadow partition loading blocking, and version rollback.

[0052] In this embodiment, the application scenario is the upgrade of the battery thermal management application layer version in the vehicle electronic control platform. The currently running application layer version is V2.2, and the application layer version to be verified is V2.3. Compared with V2.2, V2.3 adds logic for early start of the cooling pump after battery high temperature prediction, compressor linkage logic, and adaptive writing logic for thermal management parameters. The vehicle electronic control platform is deployed on a domain controller, which is divided into a safety protection zone and a customer application zone. The safety protection zone runs the base task scheduling service, diagnostic response service, communication transceiver service, actuator protection service, NVM storage service, and OTA flashing protection service. The customer application zone runs the application layer version V2.3 to be verified. The base task code, base scheduling table, and customer application algorithm source code are not exposed between the safety protection zone and the customer application zone. The customer application zone can only access the pump control interface, compressor control interface, CAN message sending interface, NVM writing interface, and OTA loading interface provided by the safety protection zone through standardized interfaces. The request entry and response exit of the above standardized interfaces constitute the isolation boundary in this embodiment.

[0053] In this embodiment, the running window is a continuous running phase formed by the security protection zone based on its own service constraints. The window recording module is deployed within the security protection zone and generates window records based on changes in the service status of the security protection zone. Window records include at least a window sequence number and a window status. Window statuses include open, restricted, and prohibited states. An open state indicates that regular interface calls issued by the client application zone can enter the subsequent digital twin verification path; a restricted state indicates that interface calls can be recorded, but the corresponding application layer version needs to enter the hardware-in-the-loop (HIL) retesting or delayed switching path; a prohibited state indicates that interface calls are not allowed to push the application layer version to be verified into the shadow partition loading or formal switching path. The window sequence number is used to identify continuously switching running windows. For example, when the security protection zone is in regular hot management service, the window sequence number is W203, and the window status is open; when the security protection zone enters diagnostic response service, the window sequence number is updated to W204, and the window status is restricted; when the security protection zone enters OTA write protection service, the window sequence number is updated to W205, and the window status is prohibited.

[0054] The interface recording module is deployed within the customer application area. This module does not parse the control algorithm content of V2.3; instead, it records the interface call requests sent by V2.3 to the security protection zone and the interface call responses returned by the security protection zone. A call start record is generated when an interface call request crosses the isolation boundary, and a call end record is generated when the interface call response returns to the isolation boundary. The call start record includes at least the interface object, call direction, the time the request crosses the isolation boundary, the boundary channel identifier, the request sequence number, the call handle, the call parameter summary, and an associated sequence number storage bit. The call end record includes at least the interface object, call direction, the time the response returns to the isolation boundary, the boundary channel identifier, the response sequence number, the call handle, the return status summary, and an associated sequence number storage bit.

[0055] The boundary association module is deployed at the isolation boundary to combine the window records of the security protection zone with the interface records of the client application zone into a verification record. When an interface call request passes through the isolation boundary, the boundary association module generates an association sequence number, combines the boundary channel identifier, interface object, request sequence number, and call handle into a call key value, writes the association sequence number to the call start record, and reads the window record output by the window record module at that moment. When the interface call response returns to the isolation boundary, the boundary association module searches for the corresponding call start record in the unclosed call queue based on the call handle, response sequence number, boundary channel identifier, and interface object carried in the response, writes the same association sequence number to the call end record, and reads the window record at the moment of response return. Subsequently, the boundary association module combines the call start record, call end record, request moment window record, response moment window record, and window trajectory sequence during the duration of the interface call corresponding to the same association sequence number into a single verification record.

[0056] The window trajectory sequence is started by the boundary association module when the call begins and a record is created. During the duration of the interface call, window records are appended based on the window switching events output by the window record module, and the sequence is closed when the same association number is written to the end of the call record.

[0057] To illustrate feasibility under different application boundaries, the processing methods for synchronous control interfaces, asynchronous communication interfaces, storage interfaces, and OTA loading interfaces are described below. For the coolant pump control interface and compressor control interface, the interface call request is an actuator control request issued by the client application area, and the interface call response is the execution result returned by the safety protection zone. The boundary association module writes the same association sequence number when the request and response pass through the isolation boundary twice. For the CAN message transmission interface, the interface call request is a message transmission request issued by the client application area, and the interface call response is a transmission confirmation response returned by the communication service of the safety protection zone. The boundary association module binds the transmission request and transmission confirmation to the same verification record. For the NVM write interface, the interface call request is a parameter write request issued by the client application area, and the interface call response is a write completion confirmation returned by the storage service of the safety protection zone. The boundary association module binds the write request, the write completion confirmation, and the window records at both times to a verification record. For the OTA loading interface, the interface call request is a shadow partition loading request issued by the client application area or the OTA management terminal. The interface call response is the loading permission, loading blocking, or loading completion result returned by the OTA write protection service in the security protection area. The boundary association module also forms a verification record according to the same association sequence number. Therefore, although the interface objects are different for different application boundaries, they all adopt the processing rule of "the request passes through the isolation boundary and writes the association sequence number, the response returns to the isolation boundary and writes the same association sequence number, reads the corresponding time window record, and synthesizes it into a verification record". Therefore, those skilled in the art can implement this scheme in different standardized interface scenarios.

[0058] The boundary association module determines the final call state based on the window trajectory sequence, window number, and window state in the verification record. If any window state in the window trajectory sequence is prohibited, it is determined to be a prohibited window occupancy state. If there are no prohibited states in the window trajectory sequence but there are restricted states, it is determined to be a restricted window occupancy state. If there are no prohibited or restricted states in the window trajectory sequence and it contains more than two different window numbers, it is determined to be a cross-window state. If there are no prohibited or restricted states in the window trajectory sequence and it contains only one window number, it is determined to be an in-window completion state. This processing rule allows the final call state to be directly derived from the observable fields in the verification record, rather than relying on manual interpretation or post-processing inference.

[0059] The upgrade control module issues upgrade control commands based on the final call state and the set of verification records corresponding to the application layer version to be verified. When the final call state is in-window completion, the upgrade control module inputs the verification records into the digital twin verification environment. The digital twin verification environment reproduces the interface call process according to the interface object, call parameter summary, call duration, window trajectory sequence, and return state summary, and outputs the digital twin verification result. After the digital twin verification passes, the upgrade control module issues differential packet generation commands, shadow partition loading commands, and formal switching commands. When the digital twin verification fails, the upgrade control module issues a delayed switching command or a shadow partition loading blocking command. When the final call state is in cross-window state or restricted window occupancy state, the upgrade control module issues a hardware-in-the-loop (HIL) retest command and maintains the delayed switching command until the HIL retest is completed. When the final call state is prohibited window occupancy state, the upgrade control module issues a shadow partition loading blocking command; if the application layer version to be verified has been loaded into the shadow partition but has not yet switched to run, a shadow partition clearing command is issued; if the application layer version to be verified has already switched to run, a version rollback command is issued.

[0060] The upgrade control module uses the set of verification records corresponding to the application layer version to be verified as the version-level decision object. If there is a prohibited window occupancy state or a failed digital twin verification result in the set of verification records, no formal switchover instruction will be generated. If there is a cross-window state or a restricted window occupancy state in the set of verification records and the HIL retest is not completed, the switchover instruction will be delayed. Only if all window completion states in the set of verification records have passed digital twin verification and all verification records that need to be retested have passed HIL retesting, a formal switchover instruction will be allowed to be generated.

[0061] For example, at 09:18:24.126, V2.3 issues a coolant pump control interface call request. When the interface call request crosses the isolation boundary, the boundary association module writes the association sequence number A0318 and reads the window record W203, whose window state is open. At 09:18:24.154, the coolant pump control interface call response returns to the isolation boundary. The boundary association module writes the same association sequence number A0318 to the call end record and reads the window record W203 at the time of the response return. After synthesizing the verification record A0318, the boundary association module determines that the final call state is the window-completed state. The upgrade control module inputs the verification record A0318 into the digital twin verification environment. After the digital twin verification is passed, the upgrade control module allows V2.3 to enter the differential packet generation and shadow partition loading process.

[0062] For example, at 09:26:41.392, V2.3 issues an NVM write interface call request. The window record when the interface call request passes through the isolation boundary is W217, and the window state is open. At 09:26:41.449, when the NVM write completion confirmation returns to the isolation boundary, the security protection area has switched to window W218, and the window state is restricted. After the boundary association module synthesizes verification record A0576, it determines the final call state as restricted window occupancy based on the window state at the end time. The upgrade control module does not allow V2.3 to directly perform a formal switch, but instead issues a HIL retest command and a delayed switch command.

[0063] For example, at 09:35:08.210, V2.3 sends a compressor linkage interface call request. The window record when the interface call request crosses the isolation boundary is W226, and the window state is disabled. At 09:35:08.237, the interface call response returns to the isolation boundary. At the time of the response, the window record is still W226, and the window state is still disabled. After the boundary association module synthesizes and verifies record A0812, it determines that the final call state is disabled window occupancy. The upgrade control module issues a shadow partition loading blocking command; if V2.3 has already been loaded into the shadow partition, then V2.3 in the shadow partition is cleared; if V2.3 has already switched to running, then it is rolled back to V2.2.

[0064] The above results demonstrate a definite correspondence between the input data, processing rules, and output control in this embodiment. The input data includes window records, interface call requests, interface call responses, and associated sequence numbers; the processing rules include binding of identical associated sequence numbers, verification record synthesis, and final call state determination; the output control includes digital twin verification, HIL retesting, differential packet generation, shadow partition loading, formal switchover, delayed switchover, loading blocking, shadow partition clearing, and version rollback. Since the associated sequence number is written when the interface call request and interface call response pass through the same isolation boundary, this embodiment does not rely on the open internal task scheduling table of the security protection zone, nor on the publicly disclosed control algorithm content of the client application zone, yet it can still form traceable verification records. Compared to conventional schemes that only match logs by timestamp, this embodiment can reduce mismatches caused by asynchronous interface responses, log sampling intervals, and rapid window switching; compared to schemes that only perform digital twin verification or HIL retesting, this embodiment provides explicit verification record inputs for digital twin verification and HIL retesting, and makes the OTA upgrade path driven by the final call state, thereby improving the security screening capability of the application layer version to be verified before entering shadow partition loading and formal switchover.

[0065] Furthermore, in scenarios where there are multiple unclosed calls to the same interface object, the boundary association module prioritizes matching based on the call key value. If the call key values ​​are the same but the response arrival order is different, the corresponding call start record is determined according to the request sequence number and call handle. Calls that are not closed after exceeding the timeout threshold are marked as unclosed and added to the set of records to be retested and verified.

[0066] Example 2

[0067] Please refer to Figures 1-3 Specifically, the implementation of the window recording module is further explained under the vehicle-mounted electronic control platform architecture of Example 1. The safety protection zone operates the base service, diagnostic service, communication service, actuator protection service, and OTA flashing protection service. The window recording module is deployed within the safety protection zone and receives status flags output by the aforementioned services. The status flags do not contain base task codes or scheduling table content; they only indicate the current operational constraints of the corresponding service. For example, base service status includes normal service, service switching, and degraded service; diagnostic response status includes default session, extended session, and programming session; communication transmission and reception status includes normal transmission and reception, queue backlog, and bus protection; actuator protection status includes no intervention, protection intervention, and forced protection; and OTA flashing status includes no flashing, flashing preparation, flashing write, and flashing verification.

[0068] The window recording module generates candidate window states based on status flags. If the OTA write status is write-to-write or write-to-verify, the window recording module determines the candidate window state as prohibited; if the actuator protection status is forced protection, the window recording module determines the candidate window state as prohibited; if the diagnostic response status is programming session, the communication transmit / receive status is queue backlog, or the actuator protection status is protection intervention, the window recording module determines the candidate window state as restricted; if none of the above states occur, the window recording module determines the candidate window state as open. When multiple status flags occur simultaneously, the window recording module determines the candidate window state in the order of prohibited state being higher than restricted state, and restricted state being higher than open state, to avoid inconsistent window judgments when different service states occur simultaneously.

[0069] The window recording module performs a running window switch when the candidate window state is inconsistent with the current window state. During the switch, the window recording module closes the current window record, updates the window sequence number, and generates a new window record. The new window record includes at least the updated window sequence number and window state. To avoid frequent changes in window sequence numbers caused by short-term jitter, the window recording module determines the jitter merging threshold Td based on the minimum task scheduling period Tbase of the safety protection zone. Td is no greater than half of Tbase. In this embodiment, Tbase is 10ms and Td is 5ms. The window recording module merges restriction status flags with a duration shorter than Td. For prohibited status flags, the window recording module does not merge them and immediately generates a new prohibited status window record. Thus, the window recording module can maintain consistent window division rules between normal state switching, short-term diagnostic disturbances, and safety protection intervention.

[0070] For example, during a battery thermal management application layer version V2.3 upgrade verification, at 09:20:14.000, the security protection zone was in normal service, default diagnostic session, normal communication transmission and reception, actuator protection not intervened, and no flashing state. The window recording module generated window record W501, with the window state being open. At 09:20:14.186, the diagnostic response state entered the programming session, the window recording module closed W501, generated window record W502, and the window state was restricted. At 09:20:14.314, the diagnostic response state returned to the default session, but the communication transmission and reception state was still queued backlog. The window recording module maintained the restricted state and continued to use W502. At 09:20:14.462, the communication transmission and reception state returned to normal, the window recording module generated window record W503, and the window state was open. At 09:20:14.733, the OTA flashing state entered the flashing state, the window recording module generated window record W504, and the window state was disabled.

[0071] In the above process, the window records output by the window recording module are read by the subsequent boundary association module. When the application layer version to be verified in the client application area issues an interface call request, the boundary association module reads the window record when the request passes through the isolation boundary; when the running window switches during the interface call, the boundary association module appends the newly generated window record to the window trajectory sequence; when the interface call response returns to the isolation boundary, the boundary association module reads the window record when the response returns and closes the window trajectory sequence. Since each window record has a clear window sequence number and window state, subsequent verification records can distinguish whether the interface call occurred in the same running window, whether it crossed different running windows, whether it occupied a restricted state window, and whether it occupied a prohibited state window.

[0072] This embodiment demonstrates that the running window is not an abstract field set manually, but is jointly determined by the observable base service status, diagnostic response status, communication transmission and reception status, actuator protection status, and OTA write status within the security protection zone; the window sequence number is not a regular time number, but a sequential identifier generated when the running window switches; the window status is not a result-based judgment, but a control attribute obtained according to the priority rules of the service status within the security protection zone. Through the above methods, those skilled in the art can implement the window recording module in scenarios such as overlapping different service states, short-term status jitter, and OTA write protection intervention, and use the window records as the basis for subsequent verification records and final call status determination.

[0073] Example 3

[0074] Please refer to Figures 1-3 Specifically, under the vehicle-mounted electronic control platform architecture of Embodiments 1 and 2, the implementation method of the interface recording module is further explained. The operating window and window record of the safety protection zone are formed according to Embodiment 2. The customer application area runs the application layer version V2.3 to be verified. The application layer version to be verified accesses the cooling pump control interface, compressor control interface, CAN message sending interface, NVM writing interface, and OTA loading interface provided by the safety protection zone through standardized interfaces. This embodiment focuses on explaining how the interface recording module in the customer application area records interface call requests and interface call responses, and generates call start records and call end records.

[0075] The interface recording module is deployed in the standardized interface call layer of the client application area. This standardized interface call layer, located between the application layer version to be verified and the isolation boundary, handles interface call requests from the application layer version to be verified and receives interface call responses returned from the security protection zone. The interface recording module does not read the control algorithm content of the application layer version to be verified, nor does it determine whether the interface call is allowed. Instead, it generates a call start record when the interface call request is issued from the application layer version to be verified and a call end record when the interface call response is returned to the client application area. Therefore, the input data for the interface recording module are interface call requests and interface call responses, and the output data is interface records, which include call start records and call end records.

[0076] The call start record indicates that an interface call has been issued by the client application area. The call start record includes at least the interface call direction and the interface call object. The interface call direction is recorded as the request direction in the call start record, indicating that the call data flows from the client application area to the security protection area. The interface call object represents the standardized interface accessed in this interface call, such as a cooling pump control interface, compressor control interface, CAN message transmission interface, NVM write interface, or OTA loading interface. The call end record indicates that the interface call response corresponding to the call start record has been returned to the client application area. The call end record includes at least the interface call direction and the interface call object. The interface call direction is recorded as the response direction in the call end record, indicating that the call data returns from the security protection area to the client application area. The interface call object is consistent with the interface call object in the call start record, used by subsequent boundary association modules to determine whether the request and response belong to the same interface call process.

[0077] In the synchronous control interface scenario, the application layer version V2.3 to be verified sends a coolant pump control interface call request at 10:12:08.036. The interface recording module generates a call start record R1001-S, in which the interface call direction is the request direction and the interface call object is the coolant pump control interface. At 10:12:08.061, the security protection zone returns a coolant pump control interface call response, and the interface recording module generates a call end record R1001-E, in which the interface call direction is the response direction and the interface call object is the coolant pump control interface. At this time, the interface recording module writes the call start record R1001-S and the call end record R1001-E into the same interface record buffer, waiting for the subsequent boundary association module to write the association sequence number and combine it with the window record to form a verification record.

[0078] In the asynchronous communication interface scenario, the application layer version V2.3 to be verified sends a CAN message sending interface call request at 10:15:42.218. The interface recording module generates a call start record R1047-S, with the interface call direction being the request direction and the interface call object being the CAN message sending interface. The security protection zone communication service returns a sending confirmation response at 10:15:42.286, and the interface recording module generates a call end record R1047-E, with the interface call direction being the response direction and the interface call object still being the CAN message sending interface. Due to potential queuing and bus arbitration delays in the communication service, the call start record and call end record are not matched at a fixed time interval. Instead, they are closed by the same interface call object, complementary call direction relationship, and the association sequence number written by the subsequent boundary association module.

[0079] In the storage interface scenario, the application layer version V2.3 to be verified issues an NVM write interface call request at 10:21:17.403. The interface recording module generates a call start record R1132-S, with the call direction being the request direction and the call object being the NVM write interface. After the security protection zone storage service completes the write, it returns the write result at 10:21:17.492. The interface recording module generates a call end record R1132-E, with the call direction being the response direction and the call object being the NVM write interface. If the call response is not returned within the preset waiting time, the interface recording module retains the call start record and sets the call end record position to empty. The empty call end record position does not directly generate upgrade control instructions, but is used by the subsequent boundary association module and upgrade control module to identify unclosed interface calls.

[0080] In the OTA loading interface scenario, when the application layer version V2.3 to be verified or the OTA management terminal issues a shadow partition loading request through the OTA interface proxy module in the client application area, the interface recording module records the shadow partition loading request as an interface call request and generates a call start record; when the security protection zone returns a loading allow, loading block, or loading complete response, the interface recording module generates a call end record. The interface call object is denoted as the OTA loading interface. Through the above processing, although executor control, communication transmission, storage writing, and OTA loading belong to different application boundaries, they are all transformed into a unified record format of "interface call request and call start record" and "interface call response and call end record".

[0081] When the OTA management terminal is located outside the security protection zone, the OTA interface proxy module is used to convert the shadow partition loading request of the OTA management terminal into a standardized interface call request of the client application area, so that the request still passes through the same isolation boundary and accepts the same interface records and boundary association rules.

[0082] In this embodiment, the call start record and call end record generated by the interface recording module serve as inputs for the subsequent boundary association module. The boundary association module writes an association sequence number to the call start record when the interface call request crosses the isolation boundary, and writes the same association sequence number to the call end record when the interface call response returns to the isolation boundary. It then combines this with the window record formed in Embodiment 2 to generate a verification record. Therefore, although the interface recording module does not directly determine whether the interface call crosses windows, occupies a restricted window, or is prohibited from entering a window, the call start record and call end record it generates provide traceable request-side and response-side data for subsequent verification records.

[0083] The beneficial effects of this embodiment are as follows: the interface recording module generates records solely based on interface call requests and responses, without relying on publicly available control algorithms in the client application area, nor requiring the security protection zone to expose its internal scheduling logic. Simultaneously, the call start record and call end record respectively record the interface call direction and the interface call object, enabling different types of standardized interfaces to be converted into a unified interface record format. Therefore, the subsequent boundary association module can reuse the same association processing rules across different application boundaries, reducing the risk of record inconsistencies caused by differences in synchronous interfaces, asynchronous interfaces, storage interfaces, and OTA loading interfaces, and providing a feasible data foundation for verifying record formation and determining the final call state.

[0084] Example 4

[0085] Please refer to Figures 1-3 Specifically, based on Embodiments 1 to 3, the implementation of the boundary association module is further explained. Embodiment 1 has already described the interaction between the security protection zone and the client application zone through a standardized interface. Embodiment 2 has already described the window recording module generating window records containing window serial numbers and window states. Embodiment 3 has already described the interface recording module generating call start records and call end records. In this embodiment, the boundary association module is deployed at the isolation boundary between the security protection zone and the client application zone. The isolation boundary is the software interception layer where the request entry and response exit of the standardized interface are located. The boundary association module does not parse the control algorithm content of the client application zone, nor does it read the task code of the security protection zone. Instead, it completes cross-zone association based on the interface call request, interface call response, and the current window record.

[0086] When an API call request first crosses the isolation boundary, the boundary association module generates an association sequence number. This sequence number can be obtained by combining the boundary channel identifier, the API call count, and an incrementing sequence number, for example, B03-PUMP-000426. The boundary association module combines the boundary channel identifier, the API object, the request sequence number, and the call handle into a call key value. It writes the association sequence number to the call start record and, during writing, reads the current window record output by the window record module, writing the window sequence number and window state corresponding to the API call request into the call start record. Simultaneously, it creates a queue entry corresponding to the call key value in the unclosed call queue. Therefore, the call start record includes at least the association sequence number, call key value, API call object, request direction, call start time, and the window sequence number and window state corresponding to the call start record.

[0087] Calling key-value pairs is used to resolve the correspondence between concurrent requests and asynchronous responses under the same interface object; each time an interface call request is generated within the same boundary channel, the request sequence number is incremented once, and the call handle remains valid until the response is returned.

[0088] When the API call response returns to the isolation boundary, the boundary association module searches for the queue entry corresponding to the API call response in the unclosed call queue based on the call handle, response sequence number, boundary channel identifier, and API object carried in the response. If multiple unclosed calls exist under the same API object, the boundary association module determines the corresponding call start record in the order of call handle priority, request sequence number second, and call start time third, and writes the same association sequence number into the call end record. When writing the call end record, the boundary association module reads the current window record again and writes the window sequence number and window state corresponding to the API call response into the call end record. Therefore, the call end record includes at least the association sequence number, call key value, API call object, response direction, call end time, and the window sequence number and window state corresponding to the call end record.

[0089] After writing the same association sequence number to both the call start record and the call end record, the boundary association module combines the call start record, call end record, window sequence number and window state corresponding to the call start record, window sequence number and window state corresponding to the call end record, and window trajectory sequence corresponding to the same association sequence number into a verification record. If the interface call response does not return within the preset waiting time, the boundary association module retains the call start record and marks the corresponding association sequence number as unclosed; the unclosed mark serves as supplementary input for subsequent HIL retesting or delayed switching and is marked as a record to be retested in the version-level verification record set.

[0090] When the window recording module generates a new window record during the duration of an interface call, the boundary association module appends the new window record to the window trajectory sequence of the corresponding queue item based on the queue items in the running state in the unclosed call queue. If multiple interface calls are not closed at the same time, each queue item maintains its own window trajectory sequence.

[0091] For example, the application layer version to be verified in the customer application area issues a request to call the cooling pump control interface. The request crosses the isolation boundary at 10:06:31.128. The boundary association module generates an association sequence number B02-PUMP-000318 and reads window record W701, where the window state is open. The response returns to the isolation boundary at 10:06:31.154. The boundary association module writes the same association sequence number into the call end record and reads window record W701. After the boundary association module synthesizes the verification record, it determines the final call state as the window-completed state based on the start window sequence number W701, the end window sequence number W701, and the open state.

[0092] For example, when a client application sends an NVM write interface call request, the corresponding window record when the request crosses the isolation boundary is W716, and the window state is open; when the response returns to the isolation boundary, the corresponding window record is W717, and the window state is restricted. After the boundary association module synthesizes the verification records, it first determines the window occupancy risk based on the window state. Since the window state corresponding to the call end record is restricted, and neither the call start record nor the call end record corresponds to a prohibited state, the boundary association module determines that the final call state is a restricted window occupancy state, instead of determining the cross-window state solely based on changes in the window sequence number.

[0093] For example, when a client application sends a request to the compressor linkage interface, the corresponding window record is W729 when the request crosses the isolation boundary, and the window state is prohibited. When the response returns to the isolation boundary, the corresponding window record is also W729, and the window state is still prohibited. After synthesizing the verification record, the boundary association module first determines the existence of a prohibited state based on the window state, and directly determines the final call state as a prohibited window occupation state. Even if the window sequence numbers corresponding to the call start record and the call end record are the same, the prohibited state still takes precedence over the window completion state.

[0094] In this embodiment, the boundary association module uses a hierarchical rule to determine the final call state: first, it reads the states of each window in the window trajectory sequence; if any window state is prohibited, it is determined to be a prohibited window occupation state; if there is no prohibited state but there is a restricted state, it is determined to be a restricted window occupation state; if there are no prohibited or restricted states, it then reads the window sequence number in the window trajectory sequence; if the window trajectory sequence contains two or more different window sequence numbers, it is determined to be a cross-window state; if the window trajectory sequence contains only one window sequence number, it is determined to be a window-in-the-window completion state. By judging the window state first and then the window sequence number, the boundary association module can avoid the same verification record falling into multiple final call states simultaneously, thereby providing a definite input for the upgrade control module.

[0095] This embodiment discloses the input, processing, and output relationships of the boundary association module. Input data includes interface call requests, interface call responses, current window records, and window switching events. Processing rules include generating association sequence numbers, generating call key values, maintaining an unclosed call queue, writing association sequence numbers to the call start record, writing the same association sequence number to the call end record, reading window records at the request and response times, recording the window trajectory sequence during the interface call duration, synthesizing verification records, and hierarchically determining the final call state. Output data includes verification records, unclosed flags, window trajectory sequences, and the final call state. Through the above processing, even if the security protection zone and the customer application zone are isolated from each other, those skilled in the art can still implement the boundary association module based on the request entry and response exit of the standardized interface, establishing a traceable correspondence between the interface call process and the operating window of the security protection zone.

[0096] Example 5

[0097] Please refer to Figures 1-3 Specifically, the implementation method of the upgrade control module is further explained based on Embodiments 1 to 4. Embodiment 1 has disclosed the overall architecture of the vehicle electronic control platform, safety protection zone, customer application zone, and isolation boundary; Embodiment 2 has disclosed the method for generating window records; Embodiment 3 has disclosed the method for recording interface call requests and interface call responses; Embodiment 4 has disclosed the method for synthesizing verification records and the method for determining the final call status. In this embodiment, the upgrade control module receives the verification records and final call status output by the boundary association module, and reads the version identifier of the application layer version to be verified, the version identifier of the currently running application layer version, the shadow partition loading status, and the current running partition status, thereby generating corresponding upgrade control instructions.

[0098] When the final call status is "complete within window," the upgrade control module does not directly issue a formal switchover command. Instead, it first inputs the verification record into the digital twin verification environment. The digital twin verification environment uses the interface object, call start record, call end record, call parameter summary, return status summary, window number and state corresponding to the call start record, window number and state corresponding to the call end record, and window trajectory sequence from the verification record as input to reproduce the interface call process of the application layer version to be verified within the running window of the security protection zone. When the digital twin verification environment outputs a verification pass result, the upgrade control module generates a differential packet generation command based on the application layer version to be verified and the currently running application layer version. After the differential packet signature verification passes, it generates a shadow partition loading command. When the shadow partition loading is complete and the health check results meet preset conditions, the upgrade control module generates a formal switchover command. When the digital twin verification environment outputs a verification fail result, the upgrade control module generates a delayed switchover command or a shadow partition loading blocking command.

[0099] In this embodiment, the conditions for passing the digital twin verification are: the simulation interface returns a status that is consistent with the return status summary in the verification record; the response deviation of the cooling pump and compressor actuators does not exceed the calibration threshold; the CAN message sending confirmation time does not exceed the communication confirmation threshold; the NVM writing result is consistent with the parameter verification value; and there is no prohibited state in the window trajectory sequence.

[0100] When the final call state is a cross-window state, the upgrade control module uses the corresponding verification record as the hardware-in-the-loop (HIL) retest input. The HIL retest input includes at least the interface object, call duration, the window number corresponding to the call start record, the window number corresponding to the call end record, the window trajectory sequence, the window state corresponding to the call start record, and the window state corresponding to the call end record. The HIL retest environment reproduces the process of the interface call crossing the running window according to the verification record, and records the executor response, communication confirmation, and storage write results. Before the HIL retest is completed, the upgrade control module maintains the delayed switching instruction and does not issue a formal switching instruction; after the HIL retest passes, the upgrade control module releases the delayed switching instruction; if the HIL retest fails, the upgrade control module maintains the delayed switching instruction or generates a shadow partition loading blocking instruction.

[0101] During the HIL retest, the upgrade control module generates a window switching trigger script based on the window trajectory sequence, enabling the interface call to reproduce the same window number change and the same limit state trigger condition in the test bench. The HIL retest passes when the actuator response does not exceed the protection threshold, the communication queue does not generate a blocking flag, the NVM write verification does not fail, and the security protection zone does not generate a fault degradation state.

[0102] When the final call status is in the restricted window occupancy state, the upgrade control module also uses the verification record as input for HIL retesting. However, the retesting focuses on the impact of interface calls on the security protection zone services under the restricted window. If the HIL retesting results show that the application layer version to be verified did not cause executor exceptions, communication blockages, or storage errors within the restricted window, the upgrade control module releases the delayed switching instruction and allows re-entry into the upgrade path after digital twin verification. If the HIL retesting results do not meet the preset conditions, the upgrade control module maintains the delayed switching instruction and writes the corresponding verification record into the retesting record table. Therefore, the restricted window occupancy state is not directly considered a version failure, but rather enters the controlled retesting path.

[0103] When the final call status is a prohibited window state, the upgrade control module issues a shadow partition loading blocking command. If the application layer version to be verified has not yet been loaded into the shadow partition, the upgrade control module blocks shadow partition loading and seals the corresponding verification record; if the application layer version to be verified has been loaded into the shadow partition and has not switched to operation, the upgrade control module issues a shadow partition clearing command, deleting the application layer version to be verified and its differential packet cache in the shadow partition; if the application layer version to be verified has switched to operation, the upgrade control module issues a version rollback command, restoring the vehicle electronic control platform to the stable version before the application layer version to be verified switched. For example, verification record A0812 corresponds to the compressor linkage interface, and both the call start record and call end record correspond to the prohibited state window W226. The upgrade control module generates a shadow partition loading blocking command; if V2.3 is already in the shadow partition, the upgrade control module further generates a shadow partition clearing command; if V2.3 has switched to operation, the upgrade control module generates a version rollback command and restores V2.2.

[0104] In this embodiment, the input data for the upgrade control module includes verification records, final call status, application layer version identifier to be verified, currently running application layer version identifier, shadow partition loading status, currently running partition status, and a set of verification records corresponding to the application layer version to be verified. The processing rules are to select the digital twin verification path, HIL retest path, delayed switching path, shadow partition loading blocking path, shadow partition clearing path, and version rollback path based on the verification record set. The output results are differential packet generation instructions, shadow partition loading instructions, formal switching instructions, HIL retest instructions, delayed switching instructions, shadow partition loading blocking instructions, shadow partition clearing instructions, and version rollback instructions. Through this method, the upgrade control module can transform the final call status formed in Embodiment 4 into executable OTA closed-loop control actions, ensuring that digital twin verification, hardware-in-the-loop HIL retest, differential packet generation, shadow partition loading, formal switching, delayed switching, shadow partition loading blocking, and version rollback all have clear data sources and triggering conditions, thereby avoiding reliance solely on upgrade logs or timestamp matching results as the basis for upgrade control.

[0105] In this embodiment, the differential packet signature verification object includes the differential packet hash value, version identifier, target partition identifier, and signature field; the health check results include the startup success flag, key interface self-check results, diagnostic fault code status, and rollback protection flag. If any health check item fails to meet the preset conditions, the upgrade control module cancels the formal switchover command and maintains the delayed switchover command or triggers the version rollback command.

[0106] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A digital twin verification and OTA closed-loop system for the application layer of an in-vehicle software base, characterized in that, It includes a window recording module, an interface recording module, a boundary association module, and an upgrade control module; The window recording module is used to record the operating windows of the safety protection zone and generate window records containing window status and window number. The window status includes at least open status, restricted status and prohibited status. The interface recording module is used to record the interface call requests and responses issued by the application layer version to be verified in the customer application area, and generate interface records containing call start records and call end records. The boundary association module is located at the isolation boundary between the security protection zone and the customer application zone. The boundary association module writes an association number when the interface call request passes through the isolation boundary, and writes the same association number when the interface call response returns to the isolation boundary. The module also combines the call start record, call end record, window record, and window trajectory sequence during the duration of the interface call corresponding to the same association number into a verification record. The boundary association module determines the final call status based on the verification record. The final call status is used to characterize the completion status of the interface call in the security protection zone's operating window, cross-window status, window entry restriction status, and window entry prohibition status. The upgrade control module issues upgrade control instructions based on the final call status and the set of verification records corresponding to the application layer version to be verified. The upgrade control instructions are used to control the upgrade process corresponding to the application layer version to be verified to execute the corresponding upgrade path in digital twin verification, hardware-in-the-loop HIL retesting, differential package generation, shadow partition loading, formal switch, delayed switch, shadow partition loading blocking, and version rollback.

2. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 1, characterized in that, The window recording module divides the running window according to the base service status, diagnostic response status, communication transmission and reception status, actuator protection status, and OTA flashing status of the safety protection zone; And update the window number and window state when the running window is switched.

3. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 1, characterized in that, The interface recording module generates a call start record when the interface call request is issued by the client application area, and generates a call end record when the interface call response is returned to the client application area. The call start record and the call end record respectively record the interface call direction and the interface call object.

4. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 1, characterized in that, The boundary association module generates an association sequence number when the interface call request first passes through the isolation boundary, and writes the association sequence number into the call start record; When the interface call response returns to the isolation boundary, the boundary association module writes the same association sequence number into the call end record.

5. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 4, characterized in that, The boundary association module reads the current window record when writing the association sequence number; And write the window record corresponding to the interface call request into the call start record; Write the window record corresponding to the API call response to the call end record.

6. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 5, characterized in that, The verification record includes the associated sequence number, call start record, call end record, the window sequence number and window state corresponding to the call start record, the window sequence number and window state corresponding to the call end record, and the window trajectory sequence during the duration of the interface call.

7. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 6, characterized in that, The boundary association module first determines the window occupancy risk based on the window state in the window trajectory sequence, and then determines the call crossing situation based on the window sequence number in the window trajectory sequence; If any window in the window trajectory sequence is in a prohibited state, it is determined to be a prohibited window occupancy state. If the window trajectory sequence does not have a prohibited state but has a restricted state, it is determined to be a restricted window occupancy state. If the window trajectory sequence does not contain any prohibited or restricted states, and contains two or more different window numbers, it is determined to be a cross-window state. If the window trajectory sequence does not contain any prohibited or restricted states and only contains a window number, it is determined to be in a completed state within the window.

8. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 1, characterized in that, When the upgrade control module is in the final call state of "completed within the window", it will input the verification record into the digital twin verification environment. After the digital twin verification is passed, differential package generation instructions, shadow partition loading instructions, and formal switching instructions are generated based on the application layer version to be verified and the currently running application layer version. If the digital twin verification fails, delayed switching instructions or shadow partition loading blocking instructions are generated.

9. The in-vehicle software base application layer digital twin verification and OTA closed-loop system according to claim 1, characterized in that, When the final call state is a cross-window state or a restricted window state, the upgrade control module uses the verification record as the hardware-in-the-loop (HIL) retest input. The delay switching instruction is maintained until the hardware-in-the-loop (HIL) retest is completed. The delay switching instruction is released after the hardware-in-the-loop (HIL) retest is passed. If the hardware-in-the-loop (HIL) retest fails, the delay switching instruction is maintained or a shadow partition loading blocking instruction is generated.

10. A vehicle-mounted software base application layer digital twin verification and OTA closed-loop system according to claim 7, characterized in that, When the final call state is the prohibited window occupancy state, the upgrade control module issues a shadow partition loading blocking command. When the application layer version to be verified has been loaded into the shadow partition and has not been switched, issue a shadow partition clearing command. If the application layer version to be verified has been switched and is running, a version rollback command is issued to restore the current running version of the vehicle electronic control platform to the application layer version before the application layer version to be verified was switched and ran.

Images