Safety verification method of BSW layer calibration variable under AUTOSAR CP platform and control unit thereof

Abstract

The invention relates to a safety verification method for a BSW layer calibration variable under an AUTOSAR CP platform, and belongs to the field of automobile electronic control unit (ECU) embedded software safety. According to the method, an independent real-time verification module is arranged on an ECU end basic software layer (BSW), and dual verification is carried out on a target address and a data length before an XCP calibration instruction is executed. And the verification module automatically generates a runtime verification table based on the compiling chain information to realize absolute synchronization with a software version. If the verification is passed, releasing the instruction; and if the verification fails, discarding the instruction, returning an error code and recording an error log. According to the method, the problem of memory cross-border tampering caused by A2L file errors, communication interference or version inconsistency is effectively solved, the safety and reliability of the calibration process are improved, and the method is suitable for various calibration scenes such as XCP on CAN and XCP on ETH.

Description

Technical Field

[0001] This invention relates to the field of embedded software security for automotive electronic control units (ECUs), specifically to a security verification method for the online calibration process of the BSW layer based on the AUTOSAR Classic Platform (CP) architecture and its control unit. Background Technology

[0002] Existing vehicle controllers commonly employ online calibration technology based on the XCP protocol (especially XCP on CAN). The security mechanisms of this protocol, such as Cyclic Redundancy Check (CRC), address range checks, and SEED&KEY encryption authentication, primarily rely on the collaborative implementation of the host computer software and the A2L description file. This architecture, dependent on external elements, has significant security flaws: First, the inherent reliability issues of CAN bus communication (such as packet loss and erroneous frames) can compromise instruction integrity, and protocol-level checks offer limited protection against such transmission errors. More critically, the XCP protocol modifies variables by directly manipulating memory addresses. During complex development and debugging cycles, the variable addresses and sizes defined in the A2L file are highly susceptible to inconsistencies with the actual software version compiled within the ECU. This mismatch can lead to calibration instructions accessing memory out of bounds, directly modifying non-target memory regions, and causing serious security risks such as functional failures or system crashes.

[0003] To address the core issue of inconsistencies between A2L files and software versions, the industry has proposed a "front-end eradication" approach. This involves automatically generating an A2L file that precisely matches the current software binary file using compiler chain information (such as linker output files). This solution effectively reduces the risk of version mismatches caused by manual A2L maintenance and represents a significant advancement in improving calibration security.

[0004] However, relying solely on the "front-end eradication solution" still has its inherent limitations: First, this solution cannot defend against data errors caused by electromagnetic interference, hardware failure, or malicious attacks during the communication transmission of calibration commands. Such errors can cause correct address and length information to become incorrect commands after transmission. Second, in a large-scale distributed R&D system, ensuring that all calibration engineers can instantly and accurately obtain the A2L file that is completely corresponding to the internal software version of each ECU faces challenges of complex processes and human error in actual operation. Even the slightest oversight in version management can render the "front-end eradication solution" ineffective.

[0005] In conclusion, existing technological systems still have security blind spots, and the mechanisms of the host computer and the protocol itself are insufficient to address risks across the entire chain. Therefore, establishing an additional real-time security verification mechanism within the controller (ECU), independent of the host computer and A2L files, as the last line of defense in depth, is crucial. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and provide a software-layer security mechanism for the ECU of the AUTOSAR CP platform. The core objective is to establish an intrinsic security barrier at the ECU level, independent of the host computer and A2L files, by independently and in real-time double-checking the target address and data length of the calibration instruction before execution of memory access instructions. This mechanism not only compensates for potential defects in the front-end toolchain but also effectively resists transmission errors in the communication link, achieving a deeper level of runtime security defense and fundamentally preventing unintended memory tampering.

[0007] To achieve the above objectives, the AUTOSAR CP platform-based BSW layer calibration variable security verification method and its control unit are as follows: The main feature of this security verification method for BSW layer calibration variables under the AUTOSAR CP platform is that the method includes the following steps: (a) Initialize the security verification module when the BSW starts and bind it to the instruction parsing interface of the XCP protocol stack; (b) Parse the linker file and extract the global starting address CaliBaseAddr and length CaliSize of the calibrated storage area in the non-volatile memory; (c) Based on the symbol table generated by compilation, construct a runtime verification table, recording the absolute address VarAddr and physical size VarSize of all calibration variables in it; (d) Intercept the write combination command CMD[0] == 0xF6 and CMD[1] == 0xF0 of the XCP protocol stack, and execute: - Parse the target address TargetAddr = CMD[0].data[4:7] and the request data length ReqLen = CMD[1].data[1]; - Perform double verification: (i) Address validity check: Determine whether the target address TargetAddr belongs to the range [CaliBaseAddr,CaliBaseAddr + CaliSize]; (ii) Length consistency check: Determine whether the data length ReqLen is equal to the physical size VarSize corresponding to the target address TargetAddr in the check table; (e) If the double verification passes, the instruction is allowed to proceed to the XCP protocol stack for subsequent standard verification procedures; (f) If any verification fails, the instruction is immediately discarded and its transmission to the XCP protocol stack is blocked. At the same time, an error response code is returned through the XCPNRC interface.

[0008] Preferably, the security verification module is independent of the host computer calibration tool and A2L description file, and establishes a real-time intrinsic security barrier within the ECU.

[0009] Preferably, the runtime verification table mentioned in step (c) is automatically generated during the software build phase by parsing the debug information file or symbol table generated by the compilation toolchain, ensuring that the verification data is strictly consistent with the current software version.

[0010] Preferably, the error response code described in step (f) is 0x22, which conforms to the ISO 14229-1 standard, and the action of discarding the instruction takes precedence over the physical layer verification performed by the XCP protocol stack.

[0011] Preferably, step (f) further includes: writing key information of the verification failure event into a non-volatile memory to form a queryable error log, wherein the key information includes at least one or more of the following: target address, request length, and timestamp.

[0012] Preferably, the runtime verification table also records the type information of the calibration variable. When the calibration variable is an array or a structure, it supports verification of write operations on specific elements or members within it.

[0013] Preferably, the initialization order of the security verification module is earlier than the initialization of the XCP protocol stack, and its scheduling period is less than or equal to the scheduling period of the main function of the XCP protocol stack.

[0014] Preferably, the linker file is an .icf file or an .ld file, the parsing process is completed during the compilation stage, and the extracted calibration region metadata is integrated into the final executable file.

[0015] Preferably, the dual verification process is performed in real time in the data path between the CAN interface module and the XCP protocol stack, thereby intercepting and verifying each calibration write command.

[0016] Preferably, the runtime verification table is implemented using a hash table structure, with the absolute address of the calibrated variable as the key and the physical size of the variable as the value, to achieve fast address lookup and comparison.

[0017] Preferably, the method is implemented in the AUTOSAR CP software architecture, and the security verification module is an independent service module of the BSW layer, which interacts with the CAN Interface module and the XCP module through a standard interface.

[0018] Preferably, the method is applicable to online calibration systems based on XCP on CAN, XCP on Ethernet, or XCP on FlexRay protocols.

[0019] Preferably, the error log can be read through the UDS diagnostic service for the purpose of identifying and analyzing abnormal events.

[0020] The main feature of this automotive electronic control unit is that it operates internally using a safety verification method for BSW layer calibration variables under the AUTOSAR CP platform as described above.

[0021] The safety verification method and control unit for BSW layer calibration variables in the AUTOSAR CP platform of this invention achieve the following beneficial effects: (1) It pioneered a dual real-time verification mechanism (address + length) on the ECU side, without relying on calibration tools, to block out-of-bounds memory tampering caused by A2L errors or communication interference from the root, and meet the ISO 26262 ASIL-B level safety target; (2) By automatically extracting compilation chain files to generate verification tables, it can be adapted to any AUTOSAR CP toolchain, reducing deployment costs by more than 40%, significantly improving calibration testing efficiency, and shortening the development cycle; (3) It is decoupled from the XCP protocol stack, has strong portability, and can be seamlessly adapted to high-speed calibration scenarios such as XCP on ETH and XCP on FlexRay.

[0022] (4) By automatically generating a verification table during the construction phase, the verification data and the software version are absolutely synchronized, eliminating errors that may be introduced by manual maintenance and improving the engineering practicality of the solution.

[0023] (5) The newly added error log recording function provides an effective tool for anomaly location during the calibration process and significantly improves the efficiency of problem investigation. Attached Figure Description

[0024] Figure 1 This is a schematic diagram showing the deployment of the security verification module of the present invention in the AUTOSAR CP software architecture.

[0025] Figure 2This is a flowchart illustrating the program execution of the security verification method for BSW layer calibration variables under the AUTOSAR CP platform of the present invention in a specific embodiment. Detailed Implementation

[0026] To more clearly describe the technical content of the present invention, the following description is provided in conjunction with specific embodiments.

[0027] Before describing the embodiments of the present invention in detail, it should be noted that, in the following, the terms “comprising,” “including,” or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0028] The technical problem this solution aims to solve is that, during XCP on CAN calibration on the AUTOSAR CP platform, existing security mechanisms (such as address range verification defined in the A2L file) suffer from serious security flaws because they rely on the host computer and cannot cover underlying communication risks. Specifically: (1) When the A2L file is inconsistent with the actual memory mapping of the ECU (e.g., incorrect variable size or address offset definition), the protocol layer verification fails; (2) The existing mechanism cannot intercept instruction execution in real time at the ECU end. Once an address out of bounds occurs, it will directly lead to non-target memory tampering and is difficult to locate.

[0029] Typical scenario example: A certain calibrated value has an actual address of 0x20430000 and a physical size of 1 byte, but its size is mistakenly defined as 4 bytes in the A2L file. When the host computer sends a write command, the ECU will write out of bounds into the memory area 0x20430002-0x20430003, corrupting adjacent variable data and causing uncontrollable functional safety risks.

[0030] To address the aforementioned issues, this invention designs a hardware-independent real-time calibration instruction verification mechanism in the ECU-side basic software layer (BSW). The specific steps are as follows: (1) Initialize the verification module The verification module is loaded when the AUTOSAR BSW layer starts up, and the instruction parsing interface of the XCP protocol stack is bound.

[0031] (2) Extract metadata of the calibration area Parse the linker file (such as .icf or .ld) to obtain the global starting address (CaliBaseAddr) and calibration area length (CaliSize) of the calibration variables in Flash.

[0032] (3) Construct the runtime verification table Based on the memory layout information generated during software compilation, a runtime verification table is automatically constructed. This verification table records the absolute address (VarAddr) and physical size (VarSize) of all calibrated variables (including array and structure members) for subsequent real-time comparison.

[0033] (4) Command interception and dual verification Intercept the write combination command (CMD[0] == 0Xf6 && CMD[1] = 0xF0) before the XCP instruction enters the protocol stack: a. Parse instruction parameters: target address (data[4:7] of CMD[0]), request data length (data[1] of CMD[1]); b. Perform verification: Address validity: (TargetAddr belongs to [CaliBaseAddr to (CaliBaseAddr +CaliSize)]); Length consistency: (ReqLen = VarSize corresponding to TargetAddr in the validation table); (5) Verification Pass Process If the double verification passes, release the instruction to the XCP protocol stack to perform subsequent standard verifications (such as PID / CRC).

[0034] (6) Protection against verification failures If any check fails: a. Immediately discard the instruction and prevent it from being passed into the XCP protocol stack; b. Returns error code 0x22 ("Parameter out of range") via the XCP NRC (Negative Response Code) interface, conforming to ISO 14229-1 standard; c. Call the NVM interface to store key data such as the address and size when an error occurs into NVM. The logs can be queried through the UDS service.

[0035] This technical solution is implemented based on the AUTOSAR CP OS architecture, such as... Figure 1As shown, the verification module is deployed in the BSW layer, located between CAN IF and XCP. It ensures that the calibrated address and size are correct by parsing the data transmitted from CAN IF. In addition, the initialization of the verification module should be ensured to be earlier than the initialization of the XCP module.

[0036] The program flowchart of this method is as follows: Figure 2 As shown: 1. System Initialization and Scheduling Deployment: During system startup, the initialization function of the security verification module is called first. This function completes the binding with the XCP protocol stack interface and reads the calibration area metadata and runtime verification table integrated into the executable file. During system operation, it ensures that the call cycle of this module's main function is equal to or faster than the call cycle of the XCP module's main function (XCP_MainFunction).

[0037] 2. Information Extraction During the Compilation and Linking Stage: During the software compilation and linking stage, a post-processing script is built to parse the linker script file (such as .icf or .ld) and accurately extract the starting address and length of the storage area where the calibration variables reside. Simultaneously, debugging information generated by the compiler or linker (such as symbol segments in MAP files or ELF files) is parsed to obtain the absolute address of each calibration variable and the physical size corresponding to its data type. This information is then organized and a structured checksum table (e.g., using a hash table data structure) is generated and compiled into the software image as constant data.

[0038] 3. Real-time command interception: The security verification module continuously monitors the data stream from the CAN IF during runtime. When two consecutive bytes of 0xF6 and 0xF0 are detected (i.e., the "write combination command" identifier of XCP), it is determined to be a calibration write operation request, and the interception and verification process is then initiated.

[0039] 4. Parameter parsing: Parse the key parameters from the data frame: the target address (TargetAddr) is located in the 4th to 7th data bytes after the 0xF6 command byte; the requested data length (ReqLen) is located in the 1st data byte after the 0xF0 command byte.

[0040] 5. Double verification is performed: Address validity check: Determine whether the parsed TargetAddr falls within the address range [CaliBaseAddr, CaliBaseAddr + CaliSize] of the calibration area loaded in step 1. If it is not within this range, the check fails.

[0041] Length consistency check: If the address check passes, the corresponding variable record is searched in the runtime check table loaded in step 1, using TargetAddr as the key. If the search fails (the address does not exist in the check table), the check fails. If the search succeeds, the request length ReqLen is compared with the actual physical size VarSize of the variable recorded in the check table. If they are equal, the check passes; otherwise, the check fails.

[0042] 6. Verification result processing: Pass: If both checks pass, the security check module will pass the data frame to the XCP protocol stack as is, and the XCP protocol stack will perform subsequent standard checks such as PID and CRC and execute commands.

[0043] Failure: If either address verification or length verification fails, the security verification module immediately discards the data frame and stops transmitting it to the XCP protocol stack. Simultaneously, it returns error code 0x22 (parameter out of range) to the host computer by calling the Negative Response Code (NRC) interface provided by the XCP module. Furthermore, key information about this error event (such as TargetAddr, ReqLen, system timestamp, etc.) can be written to a specific area of ​​non-volatile memory via the NVM (Non-Volatile Memory) driver interface to form an error log.

[0044] 7. Error Log Query: Calibration or testing personnel can read the error log stored in NVM through standard UDS diagnostic services (e.g., using the 0x22 service to read the DID), thereby quickly locating whether the calibration failure is caused by A2L file mismatch, communication error or other reasons.

[0045] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0046] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device.

[0047] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0048] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0049] In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "embodiment," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0050] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

[0051] The safety verification method and control unit for BSW layer calibration variables in the AUTOSAR CP platform of this invention achieve the following beneficial effects: (1) It pioneered a dual real-time verification mechanism (address + length) on the ECU side, without relying on calibration tools, to block out-of-bounds memory tampering caused by A2L errors or communication interference from the root, and meet the ISO 26262 ASIL-B level safety target; (2) By automatically extracting compilation chain files to generate verification tables, it can be adapted to any AUTOSAR CP toolchain, reducing deployment costs by more than 40%, significantly improving calibration testing efficiency, and shortening the development cycle; (3) It is decoupled from the XCP protocol stack, has strong portability, and can be seamlessly adapted to high-speed calibration scenarios such as XCP on ETH and XCP on FlexRay.

[0052] In this specification, the invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations can be made without departing from the spirit and scope of the invention. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A method for safety check of a BSW layer calibration variable under an AUTOSAR CP platform, characterized in that, The method comprises the following steps: (a) initializing the security check module at the start of BSW and binding it to the instruction parsing interface of the XCP protocol stack; (b) parsing the linker file to extract the global start address CaliBaseAddr and length CaliSize of the calibration storage area in the non-volatile memory; (c) based on the symbol table generated by compilation, constructing a runtime check table to record the absolute address VarAddr and physical size VarSize of all calibration variables therein; (d) intercepting the write combination command CMD[0] == 0xF6 and CMD[1] == 0xF0 of the XCP protocol stack and performing: - parsing the target address TargetAddr = CMD[0].data[4:7] and the requested data length ReqLen = CMD[1].data[1]; - performing double-checking: (i) address validity check: judging whether the target address TargetAddr belongs to the range [CaliBaseAddr, CaliBaseAddr + CaliSize]; (ii) length consistency check: judging whether the data length ReqLen is equal to the physical size VarSize corresponding to the target address TargetAddr in the check table; (e) if the double-checking passes, releasing the instruction to the XCP protocol stack to perform the subsequent standard check process; (f) if any check fails, immediately discarding the instruction and blocking its transmission into the XCP protocol stack, while returning an error response code through the XCP NRC interface.

2. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized in that, The security check module is independent of the host calibration tool and the A2L description file, and establishes a real-time endogenous security barrier inside the ECU.

3. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized in that, The runtime check table in step (c) is automatically generated in the software construction phase by parsing the debugging information file or symbol table generated by the compilation tool chain, ensuring that the check data is strictly consistent with the current software version.

4. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized in that, The error response code in step (f) is 0x22, which conforms to the ISO 14229-1 standard, and the action of discarding the instruction takes priority over the physical layer check performed by the XCP protocol stack.

5. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, After step (f), there is further included: writing key information of the check failure event into the non-volatile memory to form an error log that can be queried, the key information including at least one or more of the target address, the request length, and the timestamp.

6. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The runtime check table also records the type information of the calibration variables, and when the calibration variables are arrays or structures, it supports checking the write operation of specific elements or members inside them.

7. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The initialization sequence of the security check module is earlier than that of the XCP protocol stack, and its scheduling period is less than or equal to the main function scheduling period of the XCP protocol stack.

8. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The linker file is an.icf file or an.ld file, and the parsing process is completed in the compilation phase and the extracted calibration area metadata is integrated into the final executable file.

9. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The double-checking process is implemented in real time in the data path between the CAN interface module and the XCP protocol stack, and each calibration write instruction is intercepted and verified.

10. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The runtime check table is implemented in a hash table structure, taking the absolute address of the calibration variable as the key and the physical size of the variable as the value, to realize fast address lookup and comparison.

11. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The method is implemented in the AUTOSAR CP software architecture, and the safety check module is an independent service module of the BSW layer, which interacts with the CAN interface module and the XCP module through a standard interface.

12. The method of claim 1, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The method is applicable to online calibration systems based on XCP on CAN, XCP on Ethernet or XCP on FlexRay protocols.

13. The method of claim 5, wherein the AUTOSAR CP platform under BSW layer calibration variable safety check method is characterized by, The error log can be read through the UDS diagnostic service for positioning and analysis of calibration abnormal events.

14. An automotive electronic control unit, characterized by, The internal operation of which is the safety check method of the calibration variable of the BSW layer under the AUTOSAR CP platform as claimed in any one of claims 1 to 13.

Images