A safeTpack functional safety closed loop method and apparatus

Abstract

The application discloses a SafeTpack functional safety closed-loop method and device, relates to the technical field of vehicle-mounted controller basic software, and the method comprises an Autosar starting architecture decoupling and reconstruction process, which comprises the following steps: decomposing the EcuM peripheral initialization timing, identifying and separating peripheral modules meeting the SafeTpack safety mechanism test from the original sequence, and placing the peripheral modules in front of the SafeTpack safety mechanism test; replacing a multi-core parallel starting function for calling based on a preset serial multi-core starting link, and shielding the multi-core parallel starting function; and synchronously completing the setting of an inter-core synchronization state machine in the process of starting each core. The application is decoupled and reconstructed in a targeted manner, a closed-loop system is constructed, architecture conflicts are eliminated, and it is ensured that the ECU can enter a determined safety state under any starting abnormal condition.

Description

Technical Field

[0001] This application relates to the field of basic software technology for vehicle controllers, specifically to a SafeTpack functional safety closed-loop method and apparatus. Background Technology

[0002] With the increasing complexity of automotive electronic systems, modern automotive ECUs generally adopt multi-core processor architectures for MCUs and the AUTS standard architecture. The current mainstream AUTS software boot system typically initializes the various peripheral driver modules in the ECU module, then starts the MCU cores in parallel, followed by OS core synchronization to complete the OS and task scheduling table startup, thus allowing the software to enter normal operating mode. The entire boot system prioritizes performance and efficiency, and the inter-core relationship is one-way control of slave cores by the master core.

[0003] The above system represents the standard startup architecture for AUTSAR software. If the ECU is required to meet ISO 26262 ASIL-C / D level functional safety requirements, then functional safety software packages such as SafeTpack must be integrated. SafeTpack's role is to perform hardware safety mechanism tests on each core within the MCU during the power-on initialization phase. This presents two sharp contradictions.

[0004] First, there's a conflict in the boot logic: conventional parallel boot systems cannot meet SafeTpack's strict requirements of testing only one core at a time, booting the next core only after the previous one passes, and having some tests executed interleaved by other cores. Forced integration can lead to disordered kernel boot order, resulting in system crashes.

[0005] Second, there is a lack of fault response: the Autosar standard startup system does not have the ability to classify and handle faults that fail SafeTpack self-test, nor can it provide a safe system response to anomalies during the startup process, which leads to system failure in fault conditions and violates the core principles of functional safety.

[0006] Therefore, to address the above issues and meet practical needs, a SafeTpack functional safety closed-loop technology is proposed. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the purpose of this application is to provide a SafeTpack functional safety closed-loop method and apparatus. By decoupling and reconstructing the AUTSAR startup process in a targeted manner, and constructing a closed-loop system with components such as multi-core startup, safety testing, inter-core synchronization, fault diagnosis, and safety state locking, the system eliminates architectural conflicts and ensures that the ECU can enter a defined safe state under any abnormal startup conditions.

[0008] To achieve the above objectives, the technical solution adopted in this application is as follows: In a first aspect, this application provides a SafeTpack functional safety closed-loop method, the method comprising the following steps: The method includes an Autosar startup architecture decoupling and refactoring process, which includes the following steps: The EcuM peripheral initialization sequence is disassembled, and the peripheral modules that meet the SafeTpack security mechanism test requirements are identified and separated from the original sequence and placed before the SafeTpack security mechanism test. The original multi-core parallel startup function of Autosar is replaced by a preset serial multi-core startup chain for calling, and the multi-core parallel startup function is hidden. The inter-core synchronization state machine is set up synchronously during the startup process of each core.

[0009] Based on the above technical solution, the method further includes a serial multi-core boot link construction process, which includes the following steps: Embed the SafeTpack startup test function interface for each core before the EcuM initialization function; Each core's SafeTpack startup function interface encapsulates five execution logic functions: initializing the peripheral modules that the current core depends on for SafeTpack execution, setting the running mode of the previous core, testing the SafeTpack security mechanism, setting the inter-core synchronization state machine of the current core after the test passes, and calling the OS core startup interface to activate the next core.

[0010] Based on the above technical solution, the method includes a SafeTpack security testing process, which includes the following steps: Detect potential faults in the internal digital logic circuitry of the MCU; The integrity of basic modules such as the processor core, memory, and clock is checked after the software is reset. Detect potential faults in the power supply system, such as undervoltage and overvoltage. To test the effectiveness of the internal temperature monitoring safety mechanism of the MCU; Test the functional integrity of the SMU module; Check the integrity of critical register values.

[0011] Based on the above technical solution, the method further includes a fault diagnosis and closed-loop control process, which includes the following steps: Based on control commands, the system enters notification reporting mode. When SafeTpack detects a fault, it directly reports the fault information to the application layer. Based on the control command, the system enters the safety reset and lockout mode. When SafeTpack detects a fault, it records the corresponding fault identifier based on the corresponding fault information and records the number of resets corresponding to the fault identifier in the non-volatile memory. Then, it triggers the MCU software reset. If the same fault triggers a reset continuously, and the number of resets accumulates to a preset threshold, when the software corresponding to the fault is reset and started again, the corresponding software will remain in the BootLoader running state.

[0012] Based on the above technical solution, the method further includes an inter-core synchronization and timeout protection process, which includes the following steps: After completing the decoupling and refactoring process of the Autosar startup architecture, subsequent module initialization and configuration are performed along the EcuM initialization path until the Autosar OS startup phase is entered.

[0013] Secondly, this application provides a SafeTpack functional safety closed-loop device, the device comprising: The Autosar startup architecture decoupling and refactoring module is used to decompose the EcuM peripheral initialization sequence, identify and separate the peripheral modules that meet the SafeTpack security mechanism test requirements from the original sequence, and place them before the SafeTpack security mechanism test. The Autosar startup architecture decoupling and reconstructing module is also used to replace the original multi-core parallel startup function of Autosar with a preset serial multi-core startup link for calling, and to shield the multi-core parallel startup function. The Autosar startup architecture decoupling and reconfiguration module is also used to synchronously complete the setting of the inter-core synchronization state machine during the startup process of each core.

[0014] Based on the above technical solution, the device further includes: A serial multi-core boot link building module, which is used to embed the SafeTpack boot test function interface of each core before the EcuM initialization function; The serial multi-core boot link construction module is also used to encapsulate five execution function logics into the SafeTpack boot function interface of each core: initialization of peripheral modules that the current core depends on for executing SafeTpack, setting the running mode of the previous core, SafeTpack security mechanism testing, setting the inter-core synchronization state machine of the current core after the test passes, and calling the OS core boot interface to activate the next core.

[0015] Based on the above technical solution, the device further includes: The SafeTpack safety test module is used to detect potential faults in the internal digital logic circuits of an MCU. The SafeTpack security testing module is also used to detect the integrity of basic modules such as the processor core, memory, and clock after a software reset; The SafeTpack safety test module is also used to detect potential faults in the power system, such as undervoltage and overvoltage. The SafeTpack safety test module is also used to test the effectiveness of the internal temperature monitoring safety mechanism of the MCU; The SafeTpack security test module is also used to test the functional integrity of the SMU module; The SafeTpack security testing module is also used to detect the integrity of critical register values.

[0016] Based on the above technical solution, the device further includes: The fault diagnosis and closed-loop control module is used to enter the notification and reporting mode based on control commands. When SafeTpack detects a fault, it will directly report the fault information to the application layer. The fault diagnosis and closed-loop control module is also used to enter the safety reset and lockout mode based on control commands. When SafeTpack detects a fault, it records the corresponding fault identifier based on the corresponding fault information and records the number of resets corresponding to the fault identifier in the non-volatile memory. Then, it triggers the MCU software reset. If the same fault triggers a reset continuously, and the number of resets accumulates to a preset threshold, when the software corresponding to the fault is reset and started again, the corresponding software will remain in the BootLoader running state.

[0017] Based on the above technical solution, the device further includes: The inter-core synchronization and timeout protection module is used to perform subsequent module initialization and configuration along the EcuM initialization path after the Autosar startup architecture decoupling and reconstruction process is completed, until the Autosar OS startup phase is entered.

[0018] Compared with the prior art, the advantages of this application are: This application decouples and reconstructs the Autosar startup process in a targeted manner, and builds a closed-loop system with components such as multi-core startup, safety testing, inter-core synchronization, fault diagnosis and safety state locking to eliminate architectural conflicts and ensure that the ECU can enter a defined safe state under any abnormal startup conditions. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating the steps of the SafeTpack functional safety closed-loop method according to an embodiment of this application. Figure 2 This is a structural block diagram of the SafeTpack functional safety closed-loop device according to an embodiment of this application. Detailed Implementation

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

[0022] The embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0023] This application provides a SafeTpack functional safety closed-loop method and apparatus. By decoupling and reconstructing the AUTSAR startup process in a targeted manner, and constructing a closed-loop system with components such as multi-core startup, safety testing, inter-core synchronization, fault diagnosis and safety state locking, the system eliminates architectural conflicts and ensures that the ECU can enter a defined safe state under any abnormal startup conditions.

[0024] To achieve the aforementioned technical effects, the overall concept of this application is as follows: A SafeTpack functional safety closed-loop method includes an Autosar startup architecture decoupling and refactoring process, wherein the Autosar startup architecture decoupling and refactoring process includes the following steps: A1. Deconstruct the EcuM peripheral initialization sequence, identify and separate the peripheral modules that meet the SafeTpack security mechanism test requirements from the original sequence, and place them before the SafeTpack security mechanism test. A2. Replace the original multi-core parallel startup function of Autosar with a preset serial multi-core startup link for calling, and shield the multi-core parallel startup function; A3. During the startup process of each core, the inter-core synchronization state machine is set up synchronously.

[0025] The embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0026] Firstly, see [the following] Figure 1 As shown in the figure, this application provides a SafeTpack functional safety closed-loop method, which includes an Autosar startup architecture decoupling and refactoring process. The Autosar startup architecture decoupling and refactoring process includes the following steps: A1. Deconstruct the EcuM peripheral initialization sequence, identify and separate the peripheral modules that meet the SafeTpack security mechanism test requirements from the original sequence, and place them before the SafeTpack security mechanism test. A2. Replace the original multi-core parallel startup function of Autosar with a preset serial multi-core startup link for calling, and shield the multi-core parallel startup function; A3. During the startup process of each core, the inter-core synchronization state machine is set up synchronously.

[0027] It should be noted that the technical solution of this application embodiment is used for the basic software development of Autosar, an on-board controller that needs to meet the functional safety level requirements of ISO26262 ASIL-C / D. SafeTpack is used to achieve functional safety goals and is a safety software package for the MCU, implementing the MCU's built-in safety mechanism testing. This invention aims to solve a fundamental technical contradiction faced by the existing Autosar standard architecture when facing the ISO26262 ASIL-C / D level requirements: the conflict at the system architecture level between the "serialized, isolated, and cross-processing" hardware self-test timing required by the SafeTpack safety software package and the "multi-core parallel, main core unidirectional control" startup logic designed by Autosar for efficiency. In addition, the existing technology lacks a fault classification and processing component that can form a closed-loop management of safety self-test failures, inter-core synchronization anomalies, and the final safety state of the system. The above contradictions and deficiencies will directly lead to the software failing to start, or the system falling into an uncontrollable state after startup failure, thus failing to meet functional safety requirements.

[0028] Therefore, the purpose of this invention is to provide a closed-loop control system that, by decoupling and reconstructing the AUTSAR startup process in a targeted manner, and constructing an organic closed-loop system with components such as multi-core startup, safety testing, inter-core synchronization, fault diagnosis, and safety state locking, fundamentally eliminates the above-mentioned architectural conflicts and ensures that the ECU can enter a defined safe state under any abnormal startup conditions.

[0029] In this embodiment, the Autosar startup process is decoupled and reconstructed in a targeted manner, and a closed-loop system is built with components such as multi-core startup, safety testing, inter-core synchronization, fault diagnosis and safety state locking to eliminate architectural conflicts and ensure that the ECU can enter a certain safe state under any abnormal startup conditions.

[0030] Furthermore, the method also includes a serial multi-core boot link construction process, which includes the following steps: B1. Embed the SafeTpack startup test function interface for each core before the EcuM initialization function; B2. Each core's SafeTpack startup function interface encapsulates five execution function logics: initialization of peripheral modules that the current core depends on for SafeTpack execution, setting the running mode of the previous core, SafeTpack security mechanism testing, setting the inter-core synchronization state machine of the current core after the test passes, and calling the OS core startup interface to activate the next core.

[0031] Furthermore, the method includes a SafeTpack security testing process, which includes the following steps: C1. Detect potential faults in the internal digital logic circuits of the MCU; C2. Check the integrity of basic modules such as processor core, memory and clock after software reset; C3. Detect potential faults in the power supply system, such as undervoltage and overvoltage. C4. Test the effectiveness of the MCU's internal temperature monitoring safety mechanism; C5. Test the functional integrity of the SMU module; C6. Check the integrity of critical register values.

[0032] Furthermore, the method also includes a fault diagnosis and closed-loop control process, which includes the following steps: D1. Based on control commands, enter the notification reporting mode. When SafeTpack detects a fault, it will directly report the fault information to the application layer. D2. Based on control commands, enter the safety reset and lockout mode. When SafeTpack detects a fault, it records the corresponding fault identifier based on the corresponding fault information and records the number of resets corresponding to the fault identifier in the non-volatile memory. Then, it triggers the MCU software reset. If the same fault triggers a reset continuously, and the number of resets accumulates to a preset threshold, when the software corresponding to the fault is reset and started again, the corresponding software will remain in the BootLoader running state.

[0033] Furthermore, the method also includes an inter-core synchronization and timeout protection process, which includes the following steps: E1. After completing the decoupling and reconstruction process of the Autosar startup architecture, proceed with the subsequent module initialization and configuration along the EcuM initialization path until the Autosar OS startup phase is entered.

[0034] In summary, the key technical points of the technical solutions in this application are as follows: (1) Decoupling and reconstructing of the Autosar startup architecture for functional safety: The core is to reconstruct the startup mode from conventional parallel startup to serial startup that is deeply bound to the safety test results. This includes a reverse control mechanism for the slave core to meet the dual-core lockstep cross test, as well as precise separation and rearrangement of peripheral initialization, to ensure that the Autosar software can start normally after passing a complete safety self-test.

[0035] (2) Achieving a fault classification diagnosis and safety lock mechanism that forms a closed loop with multi-core startup and synchronization: Its core is to link chained serial startup, safety mechanism testing, graded fault handling, inter-core synchronization and timeout monitoring into a seamless closed loop, ensuring that the Autosar software can enter a safe state under any abnormality.

[0036] Based on the technical solution of this application, in specific implementation, a SafeTpack functional safety closed-loop system under the Autosar architecture can be constructed. Its core is to build a safe startup and fault management closed-loop framework that is compatible with serial, isolated, and cross-testing requirements on the basis of the standard Autosar architecture. The system is structured as follows: Decoupling and Restructuring Components for Startup Architecture: Decoupling the Autosar EcuM startup sequence, separating and rearranging peripheral drivers according to the necessary prerequisites for security testing, shielding native parallel startup functions, and establishing a chain-like multi-core startup control with "self-test-startup" cascading.

[0037] SafeTpack security testing component: Performs tests on the MCU's built-in security mechanisms, including independent test items and dual-core lockstep cross test items, achieving complete coverage of all kernel hardware security mechanisms, and outputs test results for use by other components.

[0038] Fault diagnosis and closed-loop control components: Embedded with security testing and inter-core synchronization, enabling real-time monitoring and graded handling of anomalies such as test failures and synchronization timeouts, forming a closed loop of "test-diagnosis-decision-response", ensuring that the software can be guided to a definite safe state under any abnormal startup branch.

[0039] Inter-core synchronization and timeout protection components: After all cores pass the test and are started, the Autosar OS inter-core synchronization state machine ensures that each core can achieve synchronization after serial startup and complete the OS startup; and provides timeout protection through timers to ensure that the software can enter a safe state in case of synchronization failure.

[0040] First, initiate the architectural decoupling and refactoring components: Generally, the MCU core defaults to core 0 as the master core, with subsequent cores 1, 2, 3, etc., as slave cores. Autosar's conventional EcuM multi-core boot system follows a three-stage architecture: serial initialization of peripherals by the master core, parallel boot of multiple cores, and unified synchronization of the OS. First, the master core obtains and verifies the pointer to the peripheral driver initialization structure, completing the peripheral driver initialization of the master core. Second, each core is booted in parallel, and the inter-core synchronization state machine of each core is set up. Each slave core will start running from the Cstart startup function, executing the EcuM process such as peripheral initialization of its own core. Third, the OS inter-core synchronization is completed, and the software starts task scheduling and execution.

[0041] As a core safety component for achieving the ISO 26262 functional safety objectives, SafeTpack's operating mechanism presents three structural conflicts with the aforementioned conventional boot systems. First, SafeTpack's safety monitoring function can only cover the monitoring and testing of a single core at a time, requiring a sequential "test one, start one" approach, which contradicts Autosar's multi-core parallel boot mode. Second, SafeTpack's test programs rely on underlying peripheral modules such as the MCU clock, ports, and interrupt vector tables for operational support. These modules must be initialized before SafeTpack boots, a timing constraint not met in conventional boot systems. Third, SafeTpack's memory test MBIST and critical register flip-flop mechanism test RegMonitor, due to their inherent hardware security characteristics, must employ a dual-core lockstep redundancy verification mechanism. This means the slave core gains control of the master core during the testing phase, achieving a temporary inter-core power reversal, directly altering the standard Autosar architecture's unidirectional control mechanism over slave cores.

[0042] Based on the above analysis, the technical solution of this application proposes a functional safety-oriented Autosar startup architecture decoupling and refactoring component. The core operations of this component include: The EcuM peripheral initialization timing is finely decomposed, and peripheral modules that meet the pre-dependencies of SafeTpack testing are identified and separated from the original sequence and moved to before SafeTpack testing. The original multi-core parallel startup function call of Autosar is blocked, and replaced with a serial multi-core startup chain based on the "self-test-startup" cascading relationship; At the same time, the inter-core synchronization state machine is set up during the startup of each core to ensure compatibility with the OS's subsequent inter-core synchronization mechanism.

[0043] Specifically, the working mechanism of this component is as follows.

[0044] After entering the EcuM initialization function, the Autosar software completes the acquisition and consistency verification of peripheral driver and hardware abstraction module initialization pointers on the main core according to the conventional path. Subsequently, the architecture decoupling and refactoring components are officially started, and the program enters the pre-initialization phase for SafeTpack testing, prioritizing the initialization of necessary peripheral modules supporting security mechanism testing.

[0045] The MCU clock module provides a clock reference for all tests, the Port module ensures the controllability of the I / O channels required for testing, and the interrupt and Trap vector table ensures that abnormal response paths are reachable during testing. In particular, the Gpt timer module has an inter-core initialization order dependency that is easily overlooked by conventional integrated systems: the module's data structure is created during master core initialization. If the slave core's Gpt initialization is called before the master core's Gpt initialization, accessing the master core's data structure before it is ready will trigger a null pointer trap. In a conventional boot sequence, the master core always completes initialization before the slave cores, so there is no issue; however, in the boot component refactored to adapt to SafeTpack, the peripheral initialization sequence of each core no longer follows a fixed order. Therefore, this component includes the master core Gpt module in the pre-initialization sequence, ensuring that it completes initialization before all slave core Gpts. This precise separation and rearrangement of peripheral modules based on security test dependencies and hardware constraints is one of the key technical features that distinguishes the technical solution of this application embodiment from conventional AUTOSAR integrated systems.

[0046] The SafeTpack safety testing component performs item-by-item checks of the built-in safety mechanism tests on core 0 based on functional safety system requirements and software requirements, and controls core 0 to perform cross-tests on slave cores. Upon completion of the tests and without detected faults, the startup architecture decoupling and refactoring component sets the core 0 test completion flag, indicating that core 0 has passed the SafeTpack self-test. Subsequently, this component sets the inter-core synchronization state machine of core 0, putting core 0 into an inter-core synchronization standby state. Afterwards, this component calls the AutosarOS core startup interface, setting the current program's PC pointer to jump to the Cstart startup function of core 1, completing the startup of core 1. It should be noted that because SafeTpack's critical register monitoring and memory monitoring tests involve dual-core lockstep cross-verification, this component sets core 0 to a delayed waiting state, pausing the execution of subsequent instructions, waiting for core 1 to complete its cross-tests on core 0 and subsequent core self-tests.

[0047] After core 1 starts, it enters its own processing branch along the EcuM initialization process. Since the master core has already completed the acquisition and consistency verification of peripheral driver and hardware abstraction module initialization pointers, this step is not repeated for any slave cores. Core 1 directly performs its own peripheral driver initialization. Subsequently, the startup architecture decoupling and refactoring component controls core 1 to perform a critical step that does not exist in the conventional AUSAR architecture—setting core 0 to idle mode, temporarily suspending it. This reverse suspension operation initiated by the slave core to the master core stems from the hardware security mechanism requirements of MBIST and RegMonitor tests: when core 1, as an external core, performs tests on the memory and registers of core 0, core 0 must be in a completely static state without accessing its own tested resources. In the standard AUSAR master-slave relationship framework, core 0, as the master core, has control over its own running state; however, in this specific test scenario, core 0 cannot provide exclusive access to the tested resources while maintaining operation. Therefore, this component breaks through the conventional AUSAR master-slave relationship, granting the slave core executing cross-tests temporary reflexive control permissions, with core 1 forcibly suspending core 0 to ensure the safe execution of the test.

[0048] After core 1 completes the cross-testing of core 0 and its own SafeTpack security mechanism testing, if all tests pass, the startup architecture decoupling and refactoring component sets the core 1 test completion flag and the inter-core synchronization state machine, calls the Autosar OS kernel startup interface, sets the current program's PC pointer to the Cstart startup function of core 2, and completes the startup of core 2. Similarly, except for the last core to be started, all other slave cores in the chain execute the same pattern: suspend the previous core to put it into an idle state, complete its own SafeTpack test, set the test completion flag and the inter-core synchronization state machine, and start the next core. When the last core completes all SafeTpack tests and sets the corresponding flags, the component wakes up all suspended cores from idle mode to running mode. At this point, the startup architecture decoupling and refactoring component has completed the serial startup control of all kernels and resumes the subsequent EcuM initialization process.

[0049] It should be noted that the operation of "identifying and separating peripheral modules that meet the prerequisites for SafeTpack testing from the original sequence" is a targeted design driven by the specific hardware testing requirements of SafeTpack. In standard AUTSAR development, the default sequence generated by the AUTSAR toolchain configuration is generally used directly, without arbitrarily disassembling and rearranging the initialization timing. However, SafeTpack's test program requires that specific peripherals such as the MCU clock, ports, and interrupt vector tables be available before running. In addition, the Gpt timer module also has a specific inter-core initialization order, and the initialization positions of these modules in the default AUTSAR initialization sequence do not meet the testing conditions of SafeTpack.

[0050] Therefore, the unique operation process of this application includes: (1) identifying which underlying peripherals are modules that SafeTpack testing must rely on; (2) removing the initialization interfaces of these modules from the original initialization sequence and encapsulating them in a newly defined peripheral initialization function interface, which is called before SafeTpack security mechanism testing to complete the initialization of these modules in advance.

[0051] Furthermore, the serial multi-core boot sequence is a targeted design driven by the specific hardware testing requirements of SafeTpack. In standard AUTSAR development, the default sequence generated by the AUTSAR toolchain configuration is generally used directly, without arbitrarily disassembling and rearranging the initialization timing. However, SafeTpack's test program requires that specific peripherals such as the MCU clock, ports, and interrupt vector tables be available before running. In addition, the Gpt timer module also has a specific inter-core initialization order, and the initialization positions of these modules in the default AUTSAR initialization sequence do not meet SafeTpack's testing conditions.

[0052] Therefore, the unique operation process of the technical solution in this application includes: (1) identifying which underlying peripherals are modules that SafeTpack testing must rely on; (2) removing the initialization interfaces of these modules from the original initialization sequence and encapsulating them in a newly defined peripheral initialization function interface, which is called before SafeTpack security mechanism testing to complete the initialization of these modules in advance.

[0053] This series of operations does not exist in conventional AUSAR integration development, but is a specific design step introduced in this application embodiment to adapt to SafeTpack.

[0054] Second, the SafeTpack security testing component: This component is responsible for systematically testing the built-in security mechanisms of critical hardware components within the MCU. Its fundamental goal is to ensure the CPU operates in a safe state, reducing the threat of single points of failure and potential faults to system security. In this implementation case, the component implements a multi-dimensional, multi-layered hardware security check matrix, covering multiple test units such as logic circuit self-test, firmware power-on self-test, critical register flip-flop mechanism testing, memory testing, secondary power supply monitoring, temperature monitoring, SMUAlive Alarm security mechanism testing, and critical register monitoring. These security mechanism self-tests are executed centrally during the program startup phase, performing item-by-item anomaly monitoring of critical security attributes such as chip power integrity, lockstep core synchronization status, firmware integrity, memory health, register logic correctness, digital logic circuit reliability, and program flow legality.

[0055] The functional positioning and implementation mechanism of each test unit are described below.

[0056] Lbist, a logic circuit self-test, is used to detect potential faults in the digital logic circuits inside the MCU. FirmwareCheck is a firmware power-on self-test used to check the integrity of basic modules such as the processor core, memory, and clock after a software reset. MonBist, a secondary power monitoring system, is used to detect potential faults in power systems, such as undervoltage and overvoltage. The temperature monitoring DTS Result Test is used to test the effectiveness of the internal temperature monitoring safety mechanism of the MCU. SMU Alive Alarm security mechanism testing ensures the functional integrity of the SMU module and guarantees that the system can respond correctly in the SMU alarm state. Critical register monitoring uses CRC32 to check the integrity of critical register values.

[0057] The Lbist, FirmwareCheck, MonBist, Dts Result Test, SMU Alive Alarm, and critical register CRC monitoring mentioned above can all be completed independently by the main core without cross-core coordination.

[0058] It is worth elaborating on the critical register flip-flop mechanism test RegMonitor and the memory test Mbist. These two tests differ significantly from other tests in their implementation mechanisms. RegMonitor targets critical registers in the MCU using a triple-modal redundancy architecture, verifying the registers' correctness and fault tolerance by activating their underlying flip-flop trigger mechanism. Mbist directly performs hardware-level read-write comparison tests on the MCU's internal SRAM and FLASH memory arrays to verify the physical integrity of the memory cells. Both of these self-tests require direct and destructive read-write operations on registers and memory cells during operation. If the tested core itself performs the tests, the modification of registers and memory during the test process will cause severe resource contention and data consistency issues with the program context running on the current core, inevitably leading to software malfunctions. Therefore, the SafeTpack safety testing component employs a dual-core lockstep redundancy verification mechanism for RegMonitor and Mbist, ensuring that the test core and the tested core are different cores, with the test core performing cross-verification while the tested core is in a static state. In this implementation case, core 0, as the master core, undertakes the RegMonitor and Mbist self-tests of all slave cores (core 1, core 2, core 3, etc.); while core 1, as a slave core, undertakes the cross-validation of the corresponding test units of core 0. This cross-testing architecture is the only technical path to achieve effective coverage of the above two types of security mechanism tests, and it is also the underlying technical motivation for introducing the slave core reverse suspending master core mechanism in the startup architecture decoupling and refactoring components.

[0059] The SafeTpack safety testing component makes branching decisions based on the test results of each test unit. If the test passes, the component returns a success status to the startup architecture decoupling and refactoring component, which then continues according to the chained startup process defined in the startup architecture decoupling and refactoring component. If the test fails, the component passes the fault type to the fault diagnosis and closed-loop control component through the fault reporting interface, which then executes the corresponding safety response based on the functional safety system requirements and software requirements.

[0060] Third, fault diagnosis and closed-loop control components: The test results of each SafeTpack test item are uniformly stored in a specified array structure, and a dedicated function interface is provided for external modules to read. The fault diagnosis and closed-loop control component obtains the SafeTpack self-test results in real time by calling this interface. To ensure the real-time nature of fault response, the diagnostic processing function of this component is embedded in the error handling callback function provided by the SafeTpack safety testing component, and is triggered immediately after a test anomaly occurs. Based on the functional safety system requirements and software requirements, the fault diagnosis and closed-loop control component defines two graded response strategies for faults reported by SafeTpack safety testing. The specific strategy selection can be flexibly configured through scalarization to adapt to the differentiated trade-offs between safety and availability in different application scenarios.

[0061] Strategy 1 is the notification and reporting mode: When SafeTpack (Automotive Functional Safety Library) detects a fault, the fault diagnosis and closed-loop control components do not intervene at the low level. Instead, they directly report the fault information to the application layer, where the application software responds based on the current operating conditions and the severity of the fault. The fault diagnosis and closed-loop control components only act as fault propagation components, maintaining the current startup process. Generally, this strategy is suitable for scenarios where the fault itself does not affect the core functional safety integrity of the underlying software, and where the application layer can maintain the system in a safe state through functional degradation.

[0062] Strategy 2 is a safe reset and lock mode: When SafeTpack detects a fault, the fault diagnosis and closed-loop control component immediately records the fault identifier and the corresponding number of resets in non-volatile memory, subsequently triggering a MCU software reset. If the software triggers resets consecutively due to the same fault, and the cumulative number of resets reaches a preset threshold, the component will permanently set a software failure flag. When the software resets and restarts again, the BootLoader detects that the software failure flag is set in an early stage and will refuse to jump to the application program, causing the controller to permanently remain in the BootLoader running state and enter a safety lockout state. Generally, this strategy is suitable for scenarios where faults may compromise the core functional safety assumptions of the underlying software and where a safe state cannot be maintained through functional degradation or other means.

[0063] The detailed implementation mechanism of the two strategies is centered on the more complex Strategy 2. Before triggering a software reset, the fault diagnosis and closed-loop control component first sets the fault flag corresponding to the current fault, and then accumulates the number of software resets caused by the fault, storing the count in a non-volatile memory area to avoid reset. After completing the fault state recording, the component calls the MCU reset interface of the Mcal layer to trigger a software reset. After the software restarts, if SafeTpack does not detect the fault again in the current startup test, it indicates that the fault is an intermittent transient fault. The component restores the corresponding fault flag to the normal state, clears the software reset count for the fault to zero, and the software continues to execute normally. If the same fault is still detected after the reset, the above cycle of fault recording, reset count accumulation, and software reset is repeated. When the number of consecutive resets caused by the fault reaches the calibrated threshold, the component sets the software failure flag. After the software resets again, the BootLoader detects that the flag is valid, stops the jump to the application program, and the controller enters a safety lock state.

[0064] In particular, the faults reported by the logic circuit self-test (Lbist) have unique characteristics in their hierarchical handling. The Lbist self-test itself has already performed sufficient fault filtering and debouncing at the hardware level, eliminating the need for repeated fault count accumulation and confirmation at the software diagnostic layer. Therefore, when the fault diagnosis and closed-loop control components detect a fault reported by Lbist, they will directly skip the reset count accumulation judgment step, immediately trigger the software reset process, and ultimately enter a safety lockout state. This hierarchical design, which sets differentiated response paths for different fault types, reflects the balance between the system's refined fault management and engineering practicality.

[0065] Fourth, inter-core synchronization and timeout protection components: After each core completes the SafeTpack security mechanism test and starts, its corresponding inter-core synchronization state machine has been synchronously set by the startup architecture decoupling and reconfiguration components during the serial startup process. The software continues to initialize and configure subsequent modules along the EcuM initialization path, eventually entering the Autosar OS startup phase. In this phase, the OS sequentially performs general configuration initialization, OS instance initialization for each core, and sets key flags such as the OS context flag and core activation status flag. During the OS initialization process, the Autosar OS calls the inter-core synchronization function multiple times. This function reads the inter-core synchronization state machine value set when SafeTpack starts each core and compares it with the expected synchronization state of the currently activated core. Before the synchronization state of all cores is matched, each core will remain in a while loop waiting. When the OS determines that the synchronization states of all cores are consistent, each core exits the waiting loop, the OS scheduler starts, and the system officially enters the periodic task scheduling phase.

[0066] The aforementioned inter-core synchronization mechanism harbors a systemic risk that is absent in the conventional parallel boot mode but only becomes apparent in the SafeTpack serial chain boot mode. Because the SafeTpack serial boot chain is highly dependent on the correct execution of each step, the preceding core must complete the test and correctly set its synchronization state machine before the next core can boot. If any core in the chain fails to boot due to an unrecoverable hardware failure, or if it boots successfully but fails to correctly set its own synchronization state flag due to a test failure, the remaining cores that have passed the test and are waiting for synchronization in the while loop will be trapped in an infinite loop because they cannot meet the exit condition of consistent synchronization states across all cores. The system will not function properly and will not enter the expected safe state, violating the core requirement of ISO 26262 for a deterministic safe state.

[0067] Therefore, in the technical solution of this application embodiment, the inter-core synchronization and timeout protection component introduces a timer timeout and fault linkage protection mechanism during the inter-core synchronization waiting phase. This component sets a monitoring window with a defined time boundary within the originally unprotected while loop. Specifically, while the inter-core synchronization waiting while loop starts, the component starts a Gpt timer interrupt independent of the running state of each core for background timing. This is one of the underlying technical motivations for the main core Gpt initialization pre-setup in 5.1.1. If all cores complete synchronization state matching and exit normally within the preset timeout threshold, subsequent operation is not affected; if synchronization is not completed when the timeout period arrives, the component diagnoses the timeout event as a system-level startup fault and calls strategy two (safe reset and lock mode) of the fault diagnosis and closed-loop control component to unconditionally trigger an MCU software reset. If the fault still exists after the reset, the reset count is incremented until the threshold is reached, at which point the system enters the BootLoader safe lock state.

[0068] The inter-kernel synchronization and timeout protection component transforms the conventional AUTSAR inter-kernel synchronization wait from an unprotected open process into a closed-loop process with strict time boundaries and a defined fault response path. This ensures that the software can enter a defined safe state within a finite time frame should any kernel startup or synchronization failure occur. This component, along with the startup architecture decoupling and refactoring component, the SafeTpack safety testing component, and the fault diagnosis and closed-loop control component, are organically linked into a complete closed-loop system, forming the final safeguard of the SafeTpack functional safety closed-loop system under the AUTSAR architecture.

[0069] It should be noted that the technical solution of the embodiments of this application differs from the prior art described above in that: 1. This application embodiment constructs a functional safety closed-loop system consisting of four parts: a startup architecture decoupling and reconfiguration component, a SafeTpack safety testing component, a fault diagnosis and closed-loop control component, and an inter-core synchronization and timeout protection component. It innovatively embeds mechanisms such as graded fault handling, synchronization timeout monitoring, and safety status locking into the entire chain of serial chain startup, safety mechanism testing, and multi-core inter-core synchronization, forming a complete closed loop of "self-test-startup-synchronization-diagnosis-decision-safety status", which effectively ensures the safe operation of the entire Autosar software.

[0070] 2. This application's embodiments integrate the SafeTpack safety software package on top of the standard AUTSAR software, and develop corresponding fault diagnosis and closed-loop control components. SafeTpack enables testing of the safety mechanisms of each core within the MCU, effectively reducing the negative impact of various latent faults on MCU operation. The fault diagnosis and closed-loop control components enable real-time monitoring and graded handling of test failure anomalies, ensuring that the software can be guided to a defined safe state, meeting the ISO26262 ASIL-D level functional safety objectives.

[0071] 3. This application's embodiments implement SafeTpack core-by-core self-testing and serial booting under the Autosar framework. Combined with precise separation and rearrangement of Mcal initialization, it represents a deep decoupling and reconstruction of the boot timing of the conventional mature Autosar standard. The slave core reverse control of the master core mechanism under the dual-core lockstep cross-test requirement addresses specific technical issues arising from the hardware testing mechanism, differing from conventional inter-core interrupt pause methods. During development, numerous engineering challenges, such as timing compatibility and state consistency, were overcome. It is not an obvious or natural extension based on existing parallel booting or simple sequential booting.

[0072] Furthermore, the technical solution based on the embodiments of this application has the following technical advantages: This application embodiment realizes the integrated development of SafeTpack based on Autosar software, enabling the standard Autosar software to systematically meet the core requirements of ISO26262 ASIL-D for safety self-testing, fault response and safety status, and realize the relevant functional safety system requirements and software requirements.

[0073] The embodiments of this application ensure the robustness of complex startup processes. Through the chain-like transmission and reflexive control of "self-test before startup" and the abnormal monitoring of the entire process, the risk of system startup failure or state uncertainty caused by factors such as security testing and improper coupling is eliminated.

[0074] This application provides a complete, closed-loop, and configurable fault classification and handling mechanism, which not only provides a flexible and calibrable fault management strategy, but also ensures that the system can be forced into and maintained in a safe locked state under the most extreme fault conditions, thereby enhancing the core competitiveness of the product's functional safety.

[0075] Secondly, see Figure 2 As shown, this application provides a SafeTpack functional safety closed-loop device, which includes: The Autosar startup architecture decoupling and refactoring module is used to decompose the EcuM peripheral initialization sequence, identify and separate the peripheral modules that meet the SafeTpack security mechanism test requirements from the original sequence, and place them before the SafeTpack security mechanism test. The Autosar startup architecture decoupling and reconstructing module is also used to replace the original multi-core parallel startup function of Autosar with a preset serial multi-core startup link for calling, and to shield the multi-core parallel startup function. The Autosar startup architecture decoupling and reconfiguration module is also used to synchronously complete the setting of the inter-core synchronization state machine during the startup process of each core.

[0076] In this embodiment, the Autosar startup process is decoupled and reconstructed in a targeted manner, and a closed-loop system is built with components such as multi-core startup, safety testing, inter-core synchronization, fault diagnosis and safety state locking to eliminate architectural conflicts and ensure that the ECU can enter a certain safe state under any abnormal startup conditions.

[0077] Furthermore, the device also includes: A serial multi-core boot link building module, which is used to embed the SafeTpack boot test function interface of each core before the EcuM initialization function; The serial multi-core boot link construction module is also used to encapsulate five execution function logics into the SafeTpack boot function interface of each core: initialization of peripheral modules that the current core depends on for executing SafeTpack, setting the running mode of the previous core, SafeTpack security mechanism testing, setting the inter-core synchronization state machine of the current core after the test passes, and calling the OS core boot interface to activate the next core.

[0078] Furthermore, the device also includes: The SafeTpack safety test module is used to detect potential faults in the internal digital logic circuits of an MCU. The SafeTpack security testing module is also used to detect the integrity of basic modules such as the processor core, memory, and clock after a software reset; The SafeTpack safety test module is also used to detect potential faults in the power system, such as undervoltage and overvoltage. The SafeTpack safety test module is also used to test the effectiveness of the internal temperature monitoring safety mechanism of the MCU; The SafeTpack security test module is also used to test the functional integrity of the SMU module; The SafeTpack security testing module is also used to detect the integrity of critical register values.

[0079] Furthermore, the device also includes: The fault diagnosis and closed-loop control module is used to enter the notification and reporting mode based on control commands. When SafeTpack detects a fault, it will directly report the fault information to the application layer. The fault diagnosis and closed-loop control module is also used to enter the safety reset and lockout mode based on control commands. When SafeTpack detects a fault, it records the corresponding fault identifier based on the corresponding fault information and records the number of resets corresponding to the fault identifier in the non-volatile memory. Then, it triggers the MCU software reset. If the same fault triggers a reset continuously, and the number of resets accumulates to a preset threshold, when the software corresponding to the fault is reset and started again, the corresponding software will remain in the BootLoader running state.

[0080] Furthermore, the device also includes: The inter-core synchronization and timeout protection module is used to perform subsequent module initialization and configuration along the EcuM initialization path after the Autosar startup architecture decoupling and reconstruction process is completed, until the Autosar OS startup phase is entered.

[0081] In summary, the SafeTpack functional safety closed-loop device provided in this application embodiment has the same technical principle as the SafeTpack functional safety closed-loop method provided in the first aspect in terms of technical problems, technical solutions and technical effects, so it will not be described in detail here.

[0082] In the description of this application, it should be noted that the terms "upper," "lower," etc., indicating the orientation or positional relationship are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the system or component referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Unless otherwise expressly specified and limited, the terms "installed," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication between two components. For those skilled in the art, the specific meaning of the above terms in this application can be understood according to the specific circumstances.

[0083] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof 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 elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0084] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A SafeTpack functional safety closed-loop method, characterized in that, The method includes an Autosar startup architecture decoupling and refactoring process, which includes the following steps: The EcuM peripheral initialization sequence is disassembled, and the peripheral modules that meet the SafeTpack security mechanism test requirements are identified and separated from the original sequence and placed before the SafeTpack security mechanism test. The original multi-core parallel startup function of Autosar is replaced by a preset serial multi-core startup chain for calling, and the multi-core parallel startup function is hidden. The inter-core synchronization state machine is set up synchronously during the startup process of each core.

2. The SafeTpack functional safety closed-loop method as described in claim 1, characterized in that, The method further includes a serial multi-core boot link construction process, which includes the following steps: Embed the SafeTpack startup test function interface for each core before the EcuM initialization function; Each core's SafeTpack startup function interface encapsulates five execution logic functions: initializing the peripheral modules that the current core depends on for SafeTpack, setting the running mode of the previous core, testing the SafeTpack security mechanism, setting the inter-core synchronization state machine of the current core after the test passes, and calling the OS core startup interface to activate the next core.

3. The SafeTpack functional safety closed-loop method as described in claim 1, characterized in that, The method includes a SafeTpack security testing process, which includes the following steps: Detect potential faults in the internal digital logic circuitry of the MCU; The integrity of basic modules such as the processor core, memory, and clock is checked after the software is reset. Detect potential faults in the power supply system, such as undervoltage and overvoltage. To test the effectiveness of the internal temperature monitoring safety mechanism of the MCU; Test the functional integrity of the SMU module; Check the integrity of critical register values.

4. The SafeTpack functional safety closed-loop method as described in claim 1, characterized in that, The method further includes a fault diagnosis and closed-loop control process, which includes the following steps: Based on control commands, the system enters notification reporting mode. When SafeTpack detects a fault, it directly reports the fault information to the application layer. Based on the control command, the system enters the safety reset and lockout mode. When SafeTpack detects a fault, it records the corresponding fault identifier based on the corresponding fault information and records the number of resets corresponding to the fault identifier in the non-volatile memory. Then, it triggers the MCU software reset. If the same fault triggers a reset continuously, and the number of resets accumulates to a preset threshold, when the software corresponding to the fault is reset and started again, the corresponding software will remain in the BootLoader running state.

5. The SafeTpack functional safety closed-loop method as described in claim 1, characterized in that, The method further includes an inter-core synchronization and timeout protection process, which includes the following steps: After completing the decoupling and refactoring process of the Autosar startup architecture, subsequent module initialization and configuration are performed along the EcuM initialization path until the Autosar OS startup phase is entered.

6. A SafeTpack functional safety closed-loop device, characterized in that, The device includes: The Autosar startup architecture decoupling and refactoring module is used to decompose the EcuM peripheral initialization sequence, identify and separate the peripheral modules that meet the SafeTpack security mechanism test requirements from the original sequence, and place them before the SafeTpack security mechanism test. The Autosar startup architecture decoupling and reconstructing module is also used to replace the original multi-core parallel startup function of Autosar with a preset serial multi-core startup link for calling, and to shield the multi-core parallel startup function. The Autosar startup architecture decoupling and reconfiguration module is also used to synchronously complete the setting of the inter-core synchronization state machine during the startup of each core.

7. The SafeTpack functional safety closed-loop device as described in claim 6, characterized in that, The device further includes: A serial multi-core boot link building module, which is used to embed the SafeTpack boot test function interface of each core before the EcuM initialization function; The serial multi-core boot link construction module is also used to encapsulate five execution function logics into the SafeTpack boot function interface of each core: initialization of peripheral modules that the current core depends on for executing SafeTpack, setting the running mode of the previous core, SafeTpack security mechanism testing, setting the inter-core synchronization state machine of the current core after the test passes, and calling the OS core boot interface to activate the next core.

8. The SafeTpack functional safety closed-loop device as described in claim 6, characterized in that, The device further includes: The SafeTpack safety test module is used to detect potential faults in the internal digital logic circuits of an MCU. The SafeTpack security testing module is also used to detect the integrity of basic modules such as the processor core, memory, and clock after a software reset; The SafeTpack safety test module is also used to detect potential faults in the power system, such as undervoltage and overvoltage. The SafeTpack safety test module is also used to test the effectiveness of the internal temperature monitoring safety mechanism of the MCU; The SafeTpack security test module is also used to test the functional integrity of the SMU module; The SafeTpack security testing module is also used to detect the integrity of critical register values.

9. The SafeTpack functional safety closed-loop device as described in claim 6, characterized in that, The device further includes: The fault diagnosis and closed-loop control module is used to enter the notification and reporting mode based on control commands. When SafeTpack detects a fault, it will directly report the fault information to the application layer. The fault diagnosis and closed-loop control module is also used to enter the safety reset and lockout mode based on control commands. When SafeTpack detects a fault, it records the corresponding fault identifier based on the corresponding fault information and records the number of resets corresponding to the fault identifier in the non-volatile memory. Then, it triggers the MCU software reset. If the same fault triggers a reset continuously, and the number of resets accumulates to a preset threshold, when the software corresponding to the fault is reset and started again, the corresponding software will remain in the BootLoader running state.

10. The SafeTpack functional safety closed-loop device as described in claim 6, characterized in that, The device further includes: The inter-core synchronization and timeout protection module is used to perform subsequent module initialization and configuration along the EcuM initialization path after the Autosar startup architecture decoupling and reconstruction process is completed, until the Autosar OS startup phase is entered.

Images