Minimum sufficient evidence packet recording method and airbag control unit for a vehicle

Abstract

This invention relates to the field of software operation forensics and fault diagnosis technology, specifically to a method for recording a minimum sufficient evidence package for an airbag control unit and an automotive airbag control unit. The method is executed in a Classic AUTOSAR environment and includes: determining whether both anomaly symptom conditions and operational state time gating conditions are simultaneously met; if so, determining that the trigger condition is established; recording the trigger time; and freezing event information, path signatures, and key variable snapshots at the end of a predetermined window after triggering. Combined with the invariant assertion bitmap at the time of triggering, a minimum sufficient evidence package is generated. Compared with existing technologies, this invention can record a minimum sufficient evidence package with predictable and extremely low operational overhead, and has advantages such as not changing the airbag control logic path, not entering the ignition ISR critical segment, and retaining evidence even in power-down scenarios.

Description

Technical Field

[0001] This invention relates to the field of software operation forensics and fault diagnosis technology for automotive electronic control units, and in particular to a method for recording the minimum sufficient evidence package (MSEP) for airbag control units and an automotive airbag control unit. Background Technology

[0002] The airbag control unit is an ASIL-D level safety-critical ECU, and its collision algorithm and ignition control have strict real-time requirements. Existing post-accident analysis mainly relies on DTC fault codes, limited environmental data, and external onboard data recorders, making it difficult to reconstruct the task scheduling sequence, key data stream changes, and the actual execution path before and after the fault. Furthermore, general software tracing solutions introduce significant time jitter and storage overhead in high-frequency tasks, failing to meet the requirement of free and uninterrupted ignition timing. Under accident conditions, the vehicle's power supply may drop rapidly, further leading to the loss of operational evidence.

[0003] The Airbag Control Unit (ACU), as the core execution node of the vehicle's passive safety system, is a safety-critical ECU of ASIL-D level, representing the highest level of safety integrity requirements in the automotive electronics field. Its internal collision recognition algorithm needs to complete acceleration signal acquisition, collision type identification, and ignition decision within a millisecond-level time window. Any delay in task scheduling or data processing jitter can lead to false or false airbag activation, directly endangering the lives of occupants. Therefore, the periodic execution of the collision algorithm and the output timing of ignition control have extremely stringent deterministic constraints on real-time performance, typically requiring end-to-end response times within milliseconds, with time jitter controlled to the microsecond level.

[0004] However, current post-accident analysis methods for airbag control units still have significant limitations. Existing analysis mainly relies on three types of data sources: first, diagnostic fault codes (DTCs) stored internally in the ECU, which can only record detected, explicit fault states and lack continuous dynamic context information; second, a small number of environmental data frames frozen along with DTCs, containing extremely limited signal snapshots that cannot reflect the dynamic changes during the accident's development; and third, macroscopic vehicle data collected by external event data recorders (EDRs) or driving data recorders equipped in some vehicles, whose sampling granularity and coverage cannot penetrate to the internal software level of the ECU. The fundamental inadequacy of these data sources lies in their inability to reconstruct the actual scheduling sequence of tasks within the ECU before and after the accident, to trace the cycle-by-cycle changes of key signal data streams (such as acceleration sensor inputs, collision decision intermediate variables, ignition enable flags, etc.), and to reconstruct the actual code execution paths and branch jumps of the software before and after the fault was triggered. This makes accident liability determination, algorithm defect localization, and post-accident evidence of functional safety compliance extremely difficult.

[0005] At the software tracing technology level, there is a fundamental contradiction between general-purpose solutions and the specific needs of airbag control units. Traditional software instrumentation tracing, JTAG debugging interface logging, or operating system hook-based logging solutions all introduce significant timing jitter and additional storage access overhead when applied to high-frequency real-time tasks. Even lightweight tracing solutions may interfere with the timing of task execution beyond the error tolerance allowed by the ignition control loop, failing to meet the requirement of free from interference for critical ignition timings—that is, the tracing mechanism itself must not affect the timing correctness of the monitored function. Furthermore, the amount of tracing data generated by high-frequency tasks (such as millisecond-cycle collision detection tasks) is extremely large, and for embedded ECUs with extremely limited on-chip storage resources, storage overhead is equally significant.

[0006] An even more serious challenge arises from the rapid drop in power supply during accident scenarios. In real-world collisions, the vehicle battery voltage may drop drastically within a very short time due to mechanical damage, wiring harness breaks, or short circuits, compromising the normal operating voltage of the ECU. In this situation, if the tracking data has not yet been persistently written to non-volatile memory (such as EEPROM or Flash), the most critical operational evidence before and after the accident will be permanently lost due to the power failure. Existing power-loss protection mechanisms (such as backup capacitor power supply) typically only maintain ECU power for a limited time, and their energy reserves are primarily used to ensure the complete execution of airbag ignition functions, rather than the reliable preservation of tracking data. This objective limitation further exacerbates the risk to the integrity of operational evidence, making it precisely in extreme conditions where evidence is truly needed that data is most difficult to preserve intact.

[0007] Therefore, a data recording method is needed that can retain evidence without changing the airbag control logic path, without entering the critical ignition ISR segment, and even in power failure scenarios, in order to support post-accident fault analysis and root cause localization. Summary of the Invention

[0008] The purpose of this invention is to overcome the deficiencies of the prior art and provide a method for recording a minimum sufficient evidence package (MSEP) for an airbag control unit, as well as an automotive airbag control unit, that can record a minimum sufficient evidence package (MSEP) in a ClassicAUTOSAR (Classic Automotive Open System Architecture) airbag control unit (SRS ECU) with predictable and extremely low operating overhead.

[0009] The objective of this invention can be achieved through the following technical solutions: A method for recording a minimum sufficient evidence package for an airbag control unit, performed in a ClassicAUTOSAR environment, includes the following steps: S1. Determine whether the abnormal symptom condition and the running state time gating condition are met simultaneously. If yes, the trigger condition is determined to be met, and step S2 is executed. If no, step S1 is repeated. S2. Record the trigger time and freeze the event information, invariant assertion bitmap, path signature and key variable snapshot at the end of the predetermined window after the trigger, and generate the minimum sufficient evidence package; Specifically, the generation of the event information is as follows: Record the first information, including task identifier, unit identifier, relative time difference, event flag, and summary of key input parameters, at the entry point of the runnable entity to be scheduled for execution. At the point where the runnable exits, a summary of key output results is added to the first information and the event flag is updated to form the second information, which serves as the event information. The path signature includes the trigger-before-background path signature and the current window-freeze path signature, which are obtained by copying the current scroll path bitmap updated at a predefined witness point; The generation of the invariant assertion bitmap is specifically as follows: The predefined runtime invariants are checked in real time at runtime, and the identifiers of the violated invariants are recorded. The invariant assertion bitmap is then updated and generated.

[0010] Furthermore, the abnormal symptom condition is determined to be satisfied when any of the following conditions are met: a) Abnormal deployment decisions; b) The criteria for secondary collision confirmation and velocity change are inconsistent; c) Ignition circuit malfunction; d) Approaching the trigger threshold but not actually deployed; When both the preset operating state and the preset time window are met, it is determined that the operating state time gating condition is satisfied.

[0011] Furthermore, both the background path signature before triggering and the frozen path signature of the current window are composed of a Bloom filter bit array, and multiple hash functions are used to map a witness point identifier to the Bloom filter bit array and set the bit.

[0012] Furthermore, the predefined witness point is located at a critical branch edge or state transition point that can uniquely distinguish mutually exclusive execution paths.

[0013] Furthermore, the background path signature before triggering is obtained by copying the previous scrolling window when the triggering condition is met, and the current window freeze path signature is obtained by copying the current scrolling window when the predetermined window ends after triggering.

[0014] Furthermore, the predefined operational invariants include multiple variables from the following: consistency of the trigger states of the secondary collision confirmation sensor and the primary collision sensor; integral monotonicity of the velocity change; minimum interval between coaxial dual-stage airbag ignitions; ignition circuit resistance range; and power rail voltage range.

[0015] Furthermore, in the invariant assertion bitmap, the corresponding bit of each invariant is kept at 0 under normal circumstances, and the corresponding bit is set to 1 when the invariant is violated.

[0016] Furthermore, the key variables include multiple items from the following: the current state of the collision secondary confirmation sensor, the calculated value of the most recent speed change, the deployment decision flag, the measured value of the ignition circuit resistance, the battery voltage, the energy storage capacitor voltage, the invariant assertion logic version number, the trigger condition number, and its threshold calibration ID.

[0017] Furthermore, the method also includes: The evidence packet is written to the non-volatile memory Flash when the energy storage capacitor voltage is higher than the Flash programming threshold and the write energy budget is met; otherwise, the evidence packet is retained in the volatile storage area that is maintained after reset.

[0018] Furthermore, the method also includes: The minimum sufficient evidence package is output through the standard diagnostic service interface to achieve fault diagnosis.

[0019] The present invention also provides an automotive airbag control unit, including a monitoring module configured to perform the method described above.

[0020] Compared with the prior art, the present invention has the following beneficial effects: 1. Combination of Timeline Recording and Dual-Window Path Signature: Based on the Classic AUTOSAR standard architecture, this invention does not add new tasks or change the schedule when monitoring settings. It combines timeline event recording of the AUTOSAR RTE (Runtime Environment) layer with dual-time-window call path fingerprints, enabling the recording of software execution paths and logical state evidence under fixed and predictable resource overhead. Unlike traditional automotive EDR methods that primarily record raw sensor signals and event results, this invention reconstructs the execution background before and after a fault based on timeline events, assertion bitmaps, and dual-window path fingerprints. This narrows down the range of candidate logic branches and locates the earliest Runnable or critical branch point where the anomaly occurred.

[0021] 2. Anomaly Initiation Marking Based on Key I / O Digests: By calculating hash digests of key inputs and outputs at the entry / exit points of each Runnable, a "fingerprint" comparison mechanism for input / output behavior is established. In the event of a fault, these digests can be used to quickly identify the earliest module or data deviating from the normal trajectory, thus pinpointing the root cause to a very small area. This anomaly detection method based on I / O digests effectively improves the targeting of problem localization and, in conjunction with Bloom filter fingerprints, forms a strong chain of evidence.

[0022] 3. Dedicated Operational Assertions and Triggering Strategies for Airbag Systems: Addressing the safety requirements of airbag control systems, a series of operational assertion checks were designed, including collision secondary confirmation synchronization, monotonic speed change ΔV, two-stage ignition interval, loop resistance, and voltage range. The results are directly used to trigger evidence recording. This domain-specific invariant monitoring and triggering strategy ensures that the recorded evidence is highly relevant and explanatory for accident analysis, significantly different from the stray data in general ECU data records that has low correlation with faults.

[0023] 4. Non-intrusive monitoring implementation under Classic AUTOSAR: This invention is entirely based on the Classic AUTOSAR standard architecture, implementing monitoring functions through RTE hooks and carefully selected witness points. It achieves ASIL-D level non-intrusive monitoring with minimal and predictable time and storage overhead, without adding new tasks or changing the schedule. This adds powerful forensic capabilities while ensuring the real-time performance of security functions, representing a significant improvement over traditional ECU design.

[0024] 5. Evidence Data Extraction and Management Based on UDS Standard Channel: This invention outputs evidence package data through a standard diagnostic service interface, supplemented by dedicated DID and extended DTC management, achieving seamless integration with existing repair and diagnostic processes. The evidence data extraction process undergoes security authentication and integrity verification, complying with vehicle network communication specifications. This solution facilitates the acquisition of ECU internal data by after-sales and accident investigation teams, demonstrating high engineering practical value.

[0025] In summary, the present invention significantly improves the ability to analyze accidents and complex faults while ensuring the functional safety and real-time performance of the airbag ECU. Its dual-window Bloom fingerprint path recording, assertion-driven triggering, and non-intrusive implementation with multi-layer protection are novel and practical, and are applicable to embedded systems that require high safety levels and post-accident diagnosis, such as battery management systems (BMS) and advanced driver assistance systems (ADAS) controllers. It is of great significance for fault diagnosis and functional safety in the automotive electronics industry. Attached Figure Description

[0026] Figure 1 This is a flowchart of the evidence package recording method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the system architecture framework of an embodiment of the present invention; Figure 3 This is a flowchart illustrating fault location in an embodiment of the present invention. Detailed Implementation

[0027] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0028] Example 1 This embodiment provides a minimum sufficient evidence package recording method for airbag control units. This method is executed in a Classic AUTOSAR environment and includes the following steps: S1. Determine whether the abnormal symptom condition and the running state time gating condition are met simultaneously. If yes, the trigger condition is determined to be met, and step S2 is executed. If no, step S1 is repeated. S2. Record the trigger time, and freeze the event information, invariant assertion bitmap, path signature and key variable snapshot at the end of the predetermined window after the trigger, and generate a minimum sufficient evidence package containing integrity verification information.

[0029] The Minimum Sufficient Evidence Package (MSEP) includes the following three core data categories: 1) Runtimeline (RTE Timeline): Records the execution sequence and timestamp information of entry events for each task and runnable during system operation, and backfills the output result summary and exit flag when the runnable exits into the corresponding event record. Each event information includes the task ID, runnable ID, relative time difference Δt, and a summary of key input parameters and an output result summary (obtained through hash calculation). By reconstructing this entry event timeline and combining it with the exit backfill status, the system task scheduling sequence and key data flow changes can be intuitively restored, helping to determine the timing of anomalies.

[0030] 2) Invariant Assertion Bitmap: Contains a built-in set of runtime invariant checks (assertions) for the airbag control logic. These assertions are continuously monitored during system operation without interfering with the control flow. If an assertion condition is violated, the corresponding bit in the global assertion bitmap is set to 1 (normally remaining 0). These assertions reflect the unique physical constraints and safety logic in airbag control and are used to capture abnormal states. The evidence package contains a complete assertion result bitmap, which can be used to determine which safety assumptions of the system were broken when a fault occurred, thereby assisting in locating the root cause of the anomaly.

[0031] 3) Dual-Time-Window Path Signature: A dual-window Bloom filter structure is used to record the function call "fingerprints" of the fault-triggered neighborhood. Specifically, witness points are implanted at several key functions or branches in the software. When the program execution passes through these witness points, multiple hash functions are used to map the witness point ID to the bit array of the Bloom filter and set the bit. The system maintains the bit arrays corresponding to the previous complete scrolling background window and the current window where the trigger occurs in parallel. When the trigger condition is met, the call signature corresponding to the previous complete scrolling background window is extracted as call_pre; when the predetermined window ends after the trigger, the call signature of the current scrolling window where the trigger occurs up to the freeze time is extracted as call_post. call_pre is used to represent the execution fingerprint of the background window before the trigger, and call_post is used to represent the path fingerprint of the current scrolling window where the trigger occurs at the freeze time; by combining the common bits and newly added bits of both and the timeline, the suspected code area can be narrowed down.

[0032] The path signature includes a pre-trigger background path signature and a current window freeze path signature, obtained by copying the current scroll path bitmap updated at a predefined witness point. The pre-trigger background path signature is copied from the previous scroll window when the trigger condition is met. The previous scroll window is the most recent complete 200ms scroll window, and the scrolling period of both the previous and current scroll windows is fixed at 200ms. The current window freeze path signature is copied from the current scroll window when the window ends 20000us after the trigger, and represents the call signature of the current scroll window where the trigger occurred up to the freeze time.

[0033] like Figure 1 As shown, during the operation of the SRS ECU, event record writing points are generated at the entry and exit points of the runnable unit. The path signature is updated at the witness point, and key state variables are saved simultaneously. Online continuous execution of event timeline recording, operational status and invariant monitoring, and witness point path signature maintenance is performed. When predefined trigger conditions are met, the trigger time is recorded, and the event timeline, assertion bitmap, and dual-window path signature are frozen at the end of a fixed time window after the trigger, forming the MSEP evidence package. The entire scheme complies with ASIL-D level functional safety requirements. The monitoring process has the characteristic of being free and non-interfering with the original control flow, that is, it does not change the original control logic path and does not affect the key timing of the airbag ignition circuit. It can continuously capture key evidence information during system operation without affecting the airbag control logic and real-time performance, providing a reliable basis for post-accident fault analysis and cause localization.

[0034] In other embodiments, refer to Figure 1As shown, the ECU provides a data reading interface for the evidence package through the vehicle diagnostic channel (UDS standard service). When the energy storage capacitor voltage (VCAP voltage) is higher than the Flash programming threshold and the write energy budget is met, the evidence package data is written to the ECU's non-volatile Flash memory to retain evidence data under a complete power-down scenario. When the write conditions are not met, the evidence package is stored in the NoInit segment and read through the diagnostic interface after a subsequent reset and startup without RAM power loss. Offline analysis tools use the evidence package to reconstruct the system's runtime timeline and, combined with Bloom filter signatures, infer the function call paths before and after the fault, pinpointing the cause of the fault to a few runnable entities or function modules, providing support for engineers to locate the root cause of the problem. The entire solution complies with ASIL-D level functional safety requirements, and the monitoring process has the characteristic of being free and non-interfering with the original control flow: it does not change the original control logic path and does not affect the critical timing of the airbag ignition circuit.

[0035] The following sections will provide a detailed explanation of this solution, covering aspects such as system architecture, assertion design, data structure, instrumentation implementation, triggering and data acquisition, offline analysis, performance impact, and functional safety guarantees.

[0036] I. System Architecture and Task Scheduling Design The airbag control unit (SRS ECU) used in this embodiment operates based on the Classic AUTOSAR architecture, such as... Figure 2 As shown, the algorithm comprises multiple periodic tasks that handle collision detection, fault diagnosis, and communication functions, respectively. The task partitioning and scheduling parameters for this embodiment are as follows: 1. CrashAlgoTask, a collision detection task: 1 millisecond (1kHz) cycle, high priority, non-preemptive. This task mainly executes core algorithms such as collision detection and airbag deployment decisions. The code contains only very short critical sections and uses fixed-point or integer arithmetic to ensure determinism and real-time performance. CrashAlgoTask includes several key Runnable objects: • Algo_CrashConfirm: Collision secondary confirmation decision algorithm, which performs cross-validation based on independent collision secondary confirmation sensor signals to prevent false triggering.

[0037] • Algo_DeltaV: ΔV (change in velocity) calculation or integration logic.

[0038] • Algo_DeploymentDecision: Deployment (airbag ignition) decision logic.

[0039] • Ignition_Supervisor: Ignition monitoring / arbitration logic, ensuring that ignition conditions are met and the ignition circuit is healthy, etc.

[0040] 2. DiagTask, Fault Diagnosis Task: 10 milliseconds cycle, medium priority. This task is used for diagnostic fault code (DTC) management and status monitoring, and includes the following Runnables: • Diag_SquibLine_Ohm: Ignition circuit resistance monitoring, used to detect resistance to determine open / short circuit status.

[0041] • Diag_ShortToBat / Gnd: Detection of short circuits between the sensor or actuator circuit and the power supply / ground.

[0042] • Diag_Sensor_Range: Monitoring the effectiveness of sensor signal range, etc.

[0043] 3. ComTask, Communication Task: Period 20 milliseconds, Low Priority. A task used to handle external communication (UDS diagnostic requests, CAN network messages), containing the following Runnables: • Dcm_Process: The processing function of the Diagnostic Communication Management Module (DCM), used to parse UDS requests, etc.

[0044] • Com_TxSignals: Periodic signal transmission processing for the communication interface, etc.

[0045] In a specific implementation, the above method forms monitoring code, which is then embedded into the software architecture through instrumentation. This must strictly adhere to the principle of non-intrusive monitoring instrumentation to ensure that the original system's real-time scheduling and security functions are not compromised. Specifically: 1) Instrumentation Location Selection: Monitoring code is placed only at the entry / exit points of each Runnable in the AUTOSAR RTE schedule, and inside a few functions closely related to the decision-making strategy as witness points. That is, brief logging operations are inserted at the start and end of each Runnable function; additionally, witness points are placed at certain key decision branches to record function call signatures. No other monitoring logic is inserted elsewhere.

[0046] 2) Avoiding Critical Timing Segments: Monitoring code is not inserted into the hard real-time critical segment of airbag ignition, nor is it executed in interrupt service routines (ISRs) for potentially delayed operations. No recording instructions are inserted into the ISR that triggers airbag ignition, and no time-consuming operations such as memory copying, complex calculations, or Flash access are performed. All recording actions that may affect the airbag ignition timing are executed within the task context and deferred until after the ignition action is completed.

[0047] 3) Instrumentation overhead is predictable and has a clear upper bound: All instrumentations are implemented using pre-allocated data structures and fixed execution paths. Their longest execution time is measured using GPT / cycle counters and locked within the corresponding task budget. The recording process does not involve dynamic memory allocation, does not call blocking functions, and does not change task priorities or trigger new scheduling. For operations requiring atomicity protection (such as updating the circular buffer index and setting bit flags), atomic instructions (atomic OR, atomic swap) are used to ensure data consistency and ensure that the impact on system scheduling is negligible. The monitoring code forms a monitoring module, which is completely isolated from the application algorithm implementation during operation. It continuously collects runtime evidence without interfering with the original control algorithm logic and strict real-time requirements. Even in multi-task concurrency, each OS task only maintains an index of its most recent entry record. This index is written upon entry, and the same record is backfilled by task_id upon exit, thus avoiding record misalignment due to task preemption.

[0048] During the RTE code generation phase, a unique runnable_id is assigned to each Runnable, and the corresponding input whitelist field set and output whitelist field set are simultaneously assigned. Hash digest calculations for key inputs and outputs are performed only according to a preset field order, without runtime searching or dynamic dispatching. The runtime entry hook only reads the GPT (General Purpose Timer) timestamp, obtains the pre-allocated event slot by writing to the circular pointer, writes to dt_us / task_id / runnable_id / flags, calculates the whitelist input hash for the Runnable, and saves the most recent event index for the task. The exit hook directly locates the index by task_id and backfills out_hash and exit flags, without performing a global search. The event buffer, Bloom bitmap, and msep_t double buffer are all statically allocated with fixed lengths. Witness points are fixed to perform 4 hash mixing operations and 4 atomic bit setting operations. CRC32 calculation, evidence packet organization, and Flash writing are all moved to the end of the trigger window or executed in ComTask.

[0049] II. Checking the operational invariants of the airbag system To address the specific operating conditions of airbag control, this invention designs a set of runtime invariant assertions for real-time monitoring of the consistency of key physical quantities and logical states. These assertions are formulated based on the safety requirements of the airbag system and are continuously checked during system operation, but do not interfere with the control flow; they only internally record the assertion results as flag bits. Assertion checks are not performed by new monitoring tasks, but are embedded in the corresponding Runnable of existing periodic tasks and completed at fixed intervals. Collision criterion-related assertions are checked within CrashAlgoTask, while loop resistance and voltage-related assertions are checked within DiagTask. Judgment and recording are completed using a fixed instruction sequence without introducing new scheduling. When an assertion is not satisfied, the control flow continues to execute the original control algorithm, only setting the corresponding assertion bitmap flag to 1 and writing it into the evidence package via atomic set instructions. Once an assertion is violated, the relevant flag setting is recorded in the evidence package for post-event analysis. The main assertions and their significance are as follows: 1) Collision Secondary Confirmation Threshold Consistency: The triggering state of the primary collision sensor (e.g., accelerometer) should be synchronized with the triggering state of the independent collision secondary confirmation sensor. If the detected vehicle longitudinal acceleration signal a_front exceeds the deployment threshold, but the triggering flag of the collision secondary confirmation sensor is not set within the specified very short time (<2ms), this assertion is considered violated. This invariant check ensures the triggering consistency of the dual redundant sensors.

[0050] 2) Monotonicity of ΔV Integral: Within the time window on which deployment decisions are based, the cumulative velocity change ΔV should be monotonically non-decreasing. If the ΔV value decreases compared to the previous period (exceeding the range of minor numerical errors), it usually indicates an algorithm calculation anomaly (numerical precision error and logical error). In this case, the assertion fails and is recorded. In implementation, a tolerance threshold eps_dv is set, where eps_dv is the minimum resolution of the ΔV increment. When the ΔV drop is less than eps_dv, the assertion is not set, thus eliminating false alarms caused by minor drops introduced by sampling jitter and numerical rounding.

[0051] 3) Coaxial Dual-Stage Airbag Ignition Mutual Exclusion: For dual-stage airbags configured along the same axis, a minimum time interval of at least 5ms is required between two ignition actions; simultaneous or close triggering is not permitted. This assertion ensures that the dual-stage airbags are deployed sequentially according to the designed timing, preventing excessive instantaneous power drops or abnormal superposition of airbag forces. If a violation is detected (the interval between the two ignition stages is less than 5ms), the assertion is recorded as failed.

[0052] 4) Ignition circuit health status: Before issuing the airbag ignition deployment command, the resistance value of the ignition circuit (detonation line) must be within the legal range (1.8Ω–3.2Ω, as specified in the design). If an abnormal resistance (open circuit or short circuit exceeding the threshold range) is detected just before ignition, an assertion of failure is made and recorded.

[0053] 5) Power Rail Voltage Legality: At the moment the deployment decision is made, the corresponding power rails (battery voltage VBAT, energy storage capacitor voltage VCAP) must be within the specified safety threshold range. If a voltage exceedance is detected at this moment, a failure is asserted and recorded for post-deployment analysis to determine if the vehicle power supply anomaly affected the deployment.

[0054] Each assertion corresponds to a predefined bit in the global assertion bitmap. During system operation, the corresponding bit is set from 0 to 1 only when an assertion condition is violated (it remains 0 if the condition is always met). When a trigger event occurs and the evidence package is frozen, the accumulated assertion bitmap is stored in the MSEP evidence package along with other data. To ensure that subsequent analysis can correctly interpret the meaning of the assertions, the evidence package also stores the version and configuration identifier of the assertion checking logic, corresponding to the specific software version and threshold parameters.

[0055] III. Data Structure and Storage of MSEP Evidence Package In the Classic AUTOSAR environment, MSEP employs a compact data structure to organize and store evidence data, ensuring complete recorded information and convenient reading and parsing. In this embodiment, the core structure is defined as follows (in C language style): typedef struct { uint32_t dt_us; / / Time difference (in microseconds) relative to the previous event uint16_t runnable_id; / / Runnable identifier ID (uniquely mapped to a specific function) uint8_t task_id; / / OS task ID uint8_t flags; / / Event flags: 0x01 = entry point, 0x02 = normal exit, 0x04 = abnormal exit (flags is 0x05 when entry point and abnormal exit are combined). uint64_t in_hash; / / Summary of key input parameters at runtime (64-bit hash value) uint64_t out_hash; / / Outputs a digest (64-bit hash value) when the executable exits. } rte_evt_t; / / Single event record, fixed size 24 bytes #define BLOOM_BITS 1024 / / Length of the Bloom filter bit array (fixed to 1024 bits) typedef struct { uint32_t w[BLOOM_BITS / 32]; } bloom_t; / / Bloom filter bit array structure (1024 bits consisting of 32 32-bit words) typedef struct { uint32_t magic; / / Magic number identifier, fixed at 0xABCDEEFF uint32_t seq; / / Trigger sequence number (increments with each trigger) uint32_t len; / / Total length of the data packet (in bytes), fixed at sizeof(msep_t) uint32_t crc32; / / CRC32 checksum (overrides all fields except itself) uint64_t t_trigger_us; / / Absolute timestamp (microseconds) of the triggered event. uint64_t inv_bitmap; / / Bitmap of invariant assertion results (64-bit) bloom_t call_pre; / / Bloom call signature of the window before triggering bloom_t call_post; / / Bloom call signature of the window after triggering uint16_t evt_count; / / Number of valid event entries (<=256) uint16_t evt_trigger_idx; / / Index of the trigger event in the evts circular array uint16_t evt_wr_idx; / / The write index (next write position) of the evts circular array when frozen. uint16_t rsvd; / / Reserved field, fixed at 0 rte_evt_t evts

[256] ; / / Snapshot of the event circular buffer (256 entries) uint8_t snapshot

[128] ; / / Snapshot area for critical variables (128 bytes) msep_t; #define MSEP_MAGIC 0xABCDEEFFU #define MSEP_DID 0xF2A0U #define MSEP_POST_WINDOW_US 20000U #define MSEP_BLOOM_ROLL_US 200000U #define MSEP_NVM_BLOCK_SIZE 8192U / * Compile-time verification * / STATIC_ASSERT(sizeof(rte_evt_t) == 24); STATIC_ASSERT(sizeof(bloom_t) == (BLOOM_BITS / 8)); STATIC_ASSERT(sizeof(msep_t) == 6568); The msep_t structure described above contains all the contents of the evidence package, and the meanings of each field are as follows: • Event record array (evts): A fixed-size circular buffer snapshot used to store the most recent 256 Runnable execution events before and after the event was triggered. Each event record contains the relative time difference dt_us, RunnableID, task ID, entry / exit flags, input digest hash in_hash, and output digest hash out_hash. dt_us is used to recover the timeline by accumulation; runnable_id is mapped to the specific function using an identifier constant table generated by AUTOSAR; flags indicate entry, normal exit, and abnormal exit. in_hash and out_hash are obtained by calculating 64-bit hashes on key input / output signals within a whitelist, preserving data change fingerprints while controlling storage size and avoiding exposure of sensitive raw data.

[0056] • Trigger Time and Assertion Information: `t_trigger_us` records the absolute timestamp (in microseconds) when the trigger event occurred, used to align the timeline to a real-time reference; `inv_bitmap` summarizes the check results of all runtime invariant assertions up to the trigger time, with each bit corresponding to a type of assertion, and a value of 1 indicating that the assertion was violated. Combining the assertion bitmap and `evt_trigger_idx` allows us to determine which safety assumptions failed when the fault occurred, and the specific location of the trigger event in the timeline.

[0057] • Bloom filter call signature: In this embodiment, `call_pre` is the copy of `g_bloom_prev` when the trigger condition is met, and `call_post` is the copy of `g_bloom_cur` when the 20000us window ends after the trigger. `g_bloom_prev` stores the call signature of the most recent complete 200ms scrolling window before the trigger, and `g_bloom_cur` stores the call signature of the current 200ms scrolling window where the trigger occurred up to the freeze time. Both have a bit array length of 1024 bits. Four hash mixing functions are used to map the witness point ID to four bit positions and set them to represent the set of critical paths traversed by the program within the corresponding window. During offline analysis, this signature is compared with the candidate path signature generated by static code analysis to infer the range of code paths actually executed. This call signature consists of a fixed-length bit array and a fixed number of hash mappings, and no dynamic memory allocation is performed at runtime; each `CALL_WITNESS` only performs a constant number of hash calculations and a constant number of bit setting operations, and the CPU overhead has a constant upper bound.

[0058] • Metadata Header: magic is fixed at 0xABCDEEFF, used to verify the structure's legality; seq is the current evidence package sequence number, its value is determined by the global trigger sequence counter after being written to the current msep_t during freezing, and is incremented by the global trigger sequence counter after the current evidence package is generated for use in the next trigger; len is fixed at sizeof(msep_t); crc32 is the checksum, used to overwrite the remaining fields of the current evidence package except for the crc32 field itself and ensure data integrity and reliability. evt_count indicates the number of valid event entries, evt_trigger_idx indicates the index of the trigger event in the evts circular array, and evt_wr_idx indicates the index written to the circular array during freezing.

[0059] • Key Variable Snapshot: Used to store the global state and key variable values ​​at the moment of triggering. In this embodiment, the total length of the snapshot is set to 128 bytes, and the following data is fixedly written in it: the current state of the collision secondary confirmation sensor, the most recent ΔV calculation value, the deployment decision flag, the ignition circuit resistance measurement value, VBAT voltage, VCAP voltage, the invariant assertion logic version number, the trigger condition number and its threshold calibration ID. The snapshot data is used to obtain the context information at the moment of triggering through offline analysis, which is used to reconstruct the fault scene.

[0060] The aforementioned evidence data resides in a fixed area of ​​the ECU's internal RAM. In this embodiment, the monitoring module maintains two msep_t buffers as a dual buffer, each msep_t being 6568 bytes in size, for a total of 13136 bytes. The event ring buffer evts

[256] occupies 6144 bytes, and the Bloom signatures call_pre and call_post each occupy 128 bytes. The system maintains a mapping table from RunnableID to specific functions and a hash whitelist definition. The offline analysis tool parses the meaning of events based on the mapping table and performs consistency verification on the hash digest.

[0061] IV. Details of Runtime Instrumentation Implementation In the AUTOSAR application layer code, a small amount of hook code is used to monitor and record runtime events and function paths, while ensuring that the original logic behavior is not changed. Instrumentation is divided into two categories: RTE entry / exit monitoring and function witness point call recording.

[0062] 1. RTE Inlet / Outlet Monitoring AUTOSAR's RTE schedules each Runnable periodically according to its configuration. By customizing the RTE template, monitoring hooks are inserted at the start and end of each Runnable's execution: a timeline event is created and recorded at the entry point, latching the timestamp and input digest `in_hash`; at the exit point, the output digest `out_hash` of the same event record is backfilled with the exit flag, forming an input-output digest pair that can be compared offline, without creating a separate exit timestamp event. The implementation of entry and exit monitoring is given below: 1) Entry monitoring (RTE_ENTER): static inline void MSEP_RteEnter(uint16_t rid) { uint64_t now; uint64_t prev; uint16_t slot; uint8_t task = (uint8_t)OS_GetTaskID(); SchM_Enter_MSEP(); / / Buffer time within the same extremely short critical section and reserve event slots now = GPT_ReadUs64(); prev = g_last_ts_us; g_last_ts_us = now; slot = rb_reserve_slot(); / / Atomic push circular write pointer, returns the slot index for the current event. g_task_last_evt[task] = slot; / / Register the slot for the most recent entry event of this task. SchM_Exit_MSEP(); rte_evt_t *e = &g_evt_rb[slot]; e->dt_us = (uint32_t)(now - prev); / / Calculate the time difference with the previous event e->task_id = task; / / Get the current task ID e->runnable_id = rid; / / Record the ID of the current Runnable e->flags = 0x01; / / Mark the entry point for the event type Runnable e->in_hash = HashInputsWhitelist(rid); / / Calculate the hash digest (64-bit) of the key input parameters of this Runnable. / * out_hash is filled in upon exit * / } #define RTE_ENTER(rid) MSEP_RteEnter(rid) 2) Export monitoring (RTE_EXIT): static inline void MSEP_RteExit(uint16_t rid) { rte_evt_t *e = rb_get_last_of_task(OS_GetTaskID()); / / Get the most recently written event record of the current task e->flags |= 0x02; / / Set the normal exit flag e->out_hash = HashOutputsWhitelist(rid); / / Calculate the hash digest (64 bits) of the key output of this Runnable. } #define RTE_EXIT(rid) MSEP_RteExit(rid) In the pseudocode above, the entry hook completes timestamp sampling, global last event time update, circular write pointer reservation, and g_task_last_evt[task_id] registration all within the same extremely short critical section. Therefore, the allocation order of event slots remains consistent with the actual order of event occurrence. Even if the entry hook rewrites task_id, runnable_id, and in_hash after exiting the critical section and is briefly interrupted by a high-priority task, the order of the event in the circular buffer will not change. rb_get_last_of_task(task_id) reads the slot index already registered for the task during the entry phase, so the same record can be backfilled upon exit without confusion with other tasks. Since the CrashAlgoTask task runs non-preemptively, the Runnables executed sequentially within it naturally do not overlap within the same task. For other tasks that may be interrupted by high-priority tasks, the above method also ensures a one-to-one correspondence between the entry record and the exit backfill. If an exception occurs within a Runnable and it fails to exit normally, the operating system's ErrorHook will retrieve the event slot corresponding to the most recent entry record of the task and add a 0x04 exception exit flag to the flags of the same record. Since each event record is fixed at 24 bytes, the write operation is based on a pre-allocated circular buffer and completed in a fixed instruction sequence. Its longest execution time has been verified by GPT / cycle counter and included in the task time budget to ensure that it will not change the task scheduling sequence.

[0063] 2. Function witness point call log Lightweight witness call logs are inserted within functions that significantly impact the control flow or at critical conditional branches. Whenever the program reaches these pre-selected locations, `CALL_WITNESS(site_id)` is called, mapping the corresponding ID to the current Bloom filter bit array. Implementation example below: static inline uint32_t fmix32(uint32_t h); static inline void CALL_WITNESS(uint32_t site) { / / Use a hash mix with 4 different offsets to map the witness point ID to 4 Bloom filter bits. uint32_t h1 = fmix32(site ^ 0x27d4eb2d); uint32_t h2 = fmix32(site ^ 0x85ebca6b); uint32_t h3 = fmix32(site ^ 0xc2b2ae35); uint32_t h4 = fmix32(site ^ 0x165667b1); BLOOM_SET(g_bloom_cur, h1); BLOOM_SET(g_bloom_cur, h2); BLOOM_SET(g_bloom_cur, h3); BLOOM_SET(g_bloom_cur, h4); } The BLOOM_SET operation described above sets the corresponding bit to 1 in the located bit array word. g_bloom_cur points to the currently active 200ms rolling window bit array. Using four different constants for mixed hashing can be considered as four independent hash functions, mapping a witness point ID to four bits, thus improving recognition accuracy.

[0064] Witness point deployment strategy: The set of witness points is determined by control flow graph analysis. Key branch edges and state transition points that can uniquely distinguish mutually exclusive execution paths are selected and placed at locations such as the TRUE and FALSE branches of deployment decisions, the state transition point where the collision secondary confirmation sensor changes from non-triggered to triggered, the entry point of the collision severity classification algorithm, and the pretensioner trigger logic entry point. Witness points are not placed in hardware interrupt service routines. For witness points with execution frequencies higher than 1kHz, a fixed 4-division sampling counter is used for control. The CALL_WITNESS bit is set only when the counter reaches 0, thus limiting the execution overhead of high-frequency witness points to within the time budget verified before release.

[0065] Bloom filter window maintenance: The system maintains two Bloom filter bit array buffers, serving as the current window `g_bloom_cur` and the previous window `g_bloom_prev`, respectively. The window switching cycle is fixed at 200ms: every 200ms boundary, `g_bloom_cur` is copied to `g_bloom_prev`, and `g_bloom_cur` is cleared before collection restarts. When the trigger condition is met, the system copies the current `g_bloom_prev` to the evidence package `call_pre`; at the end of the 20000us time window after the trigger, only one snapshot copy of the current `g_bloom_cur` content is performed and written to the evidence package `call_post`, without changing the continued accumulation of the current scrolling window of `g_bloom_cur` or the subsequent 200ms boundary switching cycle. Thus, `call_pre` corresponds to the execution background fingerprint of the most recent complete 200ms time window before the trigger, and `call_post` corresponds to the path fingerprint of the current 200ms scrolling window where the trigger occurred up to the freeze time. Window clearing still only occurs at normal 200ms boundaries, thus maintaining the consistency of the dual-window semantics.

[0066] It's important to note that because witness points may execute concurrently in different task contexts, the BLOOM_SET operation employs a lock-free, thread-safe design. Typically, a single atomic instruction (such as an atomic OR) or a very short interrupt-free step is used to ensure that setting the bit array word is not interrupted, preventing bit loss due to concurrent setting. This ensures the integrity of the Bloom filter signature. With a sufficiently long bit array (1024 bits), even if the window contains dozens of witness point events, the probability of Bloom signature collisions is very low; therefore, call_pre and call_post can provide distinctive path fingerprints.

[0067] V. Triggering Conditions and Evidence Data Acquisition To avoid recording large amounts of normal operation data, the system triggers MSEP evidence packet freezing when a composite trigger condition is met: the composite trigger condition consists of an anomaly symptom condition and an operating state / time gating condition, wherein the evidence packet freezing is triggered when the anomaly symptom condition meets any one of the following, and the system is simultaneously in a preset operating state and falls within a preset time window. The trigger condition is designed based on the specific safety requirements of the airbag system, and the anomaly symptom condition includes: • Deployment decision anomaly: The deployment decision logic exhibits repeated TRUE / FALSE jitter within a short period; after an initial TRUE decision, subsequent arbitration logic rejects it without actual ignition. This anomaly indicates that the algorithm is on the verge of collapse and that there is inconsistency in the logic, triggering evidence logging.

[0068] • Collision secondary confirmation and ΔV criterion inconsistency: As stated in the aforementioned operational invariant assertion, when the collision secondary confirmation sensor trigger state is inconsistent with the main sensor ΔV cumulative result (one reaches the trigger threshold while the other does not), evidence recording is triggered.

[0069] • Ignition circuit failure: When an ignition circuit failure (sudden open / short circuit in the resistor, generating a related DTC fault code) is detected during or immediately after a collision, evidence logging is triggered to capture evidence that the circuit abnormality caused the failure to deploy properly.

[0070] • Severe collisions that approached the trigger threshold but were not actually deployed: In some collision scenarios, key sensing parameters were close to the deployment threshold but ultimately the airbag was not triggered (the secondary collision confirmation sensor activated but then reset). These near-miss situations are of significant analytical value and should be recorded for post-collision evaluation to determine whether the algorithm's robustness is sufficient or whether the parameter thresholds are reasonable.

[0071] When any of the above abnormal symptom conditions is met, and the preset operating state and preset time window are also satisfied, the system will quickly execute the following freeze procedure without affecting the current control task: 1) Freezing the Event Buffer: The monitoring module maintains two `msep_t` copies in RAM as a dual buffer. The active buffer continuously writes event records in a circular manner. When the trigger condition is met for the first time, `t_trigger_us` is recorded and `evt_trigger_idx` is locked; the active buffer continues to write event records within a 20,000µs window after the trigger. If the trigger condition occurs again within the same window, a new evidence package is not opened, nor are the initially locked `t_trigger_us` and `evt_trigger_idx` rewritten. Instead, the subsequent triggers are merged into the currently collected evidence package. When the window ends, the active buffer is frozen and metadata such as `evt_wr_idx` and `evt_count` are written to it. Then, it immediately switches to the backup buffer to continue recording the next round of regular monitoring events. Buffer switching is completed under interrupt-free protection, and the switching operation consists of a fixed instruction sequence to avoid affecting high-priority tasks.

[0072] 2) Capturing Bloom Signatures: When the trigger condition is met, `g_bloom_prev` is copied and written to the evidence package `call_pre` as the call signature of the most recent complete 200ms scrolling background window before the trigger. After the window expires after 20000us following the trigger, a snapshot of the contents of `g_bloom_cur` at that time is copied and written to the evidence package `call_post` as the call signature of the current scrolling window where the trigger occurred up to the freeze time. No additional zeroing is performed on the currently scrolling `g_bloom_cur`; subsequent scrolling transitions still follow the original 200ms boundary. `call_pre` and `call_post` are combined with the timeline to compare the path differences between the background window before the trigger and the current window where the trigger occurred at the freeze time.

[0073] 3) Record assertion bitmap, timestamp, and key variable snapshots: Copy the global assertion result bitmap to msep_t.inv_bitmap and record the absolute timestamp of the first trigger in the t_trigger_us field; simultaneously, copy the collision secondary confirmation status, the most recent ΔV calculation value, deployment decision flag, ignition loop resistance, VBAT, VCAP, invariant assertion logic version number, trigger condition number, and threshold calibration ID from the state cache that has been updated at the trigger time, and write them to the snapshot area according to the predefined field order. If there are subsequent triggers within the same trigger window, the trigger condition number in the snapshot remains unchanged from the number corresponding to the first trigger. The snapshot value is based on the most recent stable value corresponding to the first trigger latch time, used for cross-verification with the timeline and path signature during offline analysis.

[0074] 4) Calculate the checksum and mark as ready: After freezing, first write the current global trigger sequence counter value into the seq field of the evidence packet, then write magic into 0xABCDEEFF, write len into sizeof(msep_t), and calculate the CRC32 checksum for the current msep_t structure excluding the crc32 field itself, then fill it into the crc32 field; subsequently, set the internal flag msep_ready=1, and increment the global trigger sequence counter by 1 for use in the next trigger. The system records the seq and crc32 of this evidence packet in the DTC extended data for diagnostic equipment to detect new evidence.

[0075] After the evidence packet is frozen, the ECU provides a data reading interface through the UDS standard diagnostic service. The Diagnostic Data Identifier (DID) is fixed at 0xF2A0, corresponding to the byte sequence of the msep_t structure. When service personnel connect to the diagnostic equipment and send a read DID request (in a secure access authorization session), the ECU sends the complete evidence packet according to ISO-TP multi-frame transmission. Before transmission, the magic and crc32 are verified to ensure data reliability. The "MSEP evidence packet capture" event is recorded in DTC management and extended data is written, prompting after-sales personnel to retrieve the evidence. The diagnostic interface is protected by security mechanisms to prevent unauthorized access.

[0076] Non-volatile memory (NvM) backup: After the evidence package is frozen, msep_t is first stored in the double buffer of the NoInit segment. In this embodiment, a fixed-size data block is configured in NvM, with a block size of 8192 bytes, corresponding to MSEP_NVM_BLOCK_SIZE. Flash writing is performed by ComTask during a safe period outside the critical ignition timing segment. Interruptions are not prohibited during writing, and it is protected by operating system runtime monitoring. The ECU is configured with an energy storage capacitor VCAP for writing power supply after an accident; after freezing, ComTask reads the VCAP voltage and performs a write enable judgment based on the write energy budget. The write energy budget is the available energy storage calculated based on the current VCAP voltage, and is compared with the pre-calibrated minimum energy threshold and safety margin for a single Flash write to obtain the write permission conditions. When the VCAP voltage is higher than the Flash programming threshold and the energy budget for a complete write is met, NvM writing is performed to preserve evidence in a complete power failure scenario; otherwise, the write is skipped and a NoInit copy is retained for subsequent read via the diagnostic interface after a reset and startup without RAM power failure. In the double-buffered state machine, only one evidence packet is allowed to be in the ready-to-export state at any given time. After one buffer becomes ready, the other buffer continues to perform regular monitoring as the active buffer. If the ready buffer has not been fully read by UDS or has not been persisted to Flash, a new independent evidence packet freeze will not be initiated when the triggering condition is met again. Instead, the request to initiate a new packet will be suppressed, and the next round of independent capture will resume after the ready buffer is released. To avoid RAM being cleared due to software reset, the msep_t double buffer is placed in the NoInit segment and remains clear during the reset initialization phase. If only a software reset or a restart without losing RAM power occurs, the diagnostic tool can still read the evidence packets that have not been uploaded.

[0077] VI. Offline Analysis and Fault Location Methods After obtaining the MSEP evidence package through the diagnostic interface, the data can be analyzed using specialized tools in a laboratory or engineering analysis environment to reconstruct the system's operational status and assist in fault location. For example... Figure 3As shown, the specific fault location process includes: 1) Reconstructing the runtime timeline: First, based on `evt_wr_idx` and `evt_trigger_idx`, the circular buffer is expanded into an event sequence that reflects the actual writing order. Then, the time difference between adjacent events is calculated by using `dt_us` in each event record, and `t_trigger_us` is used to align the trigger events to their trigger times, thereby calculating the absolute timestamps of each Runnable entry event. Since the entry event slots are atomically reserved within the same critical region as the timestamps during recording, the order of events in the circular buffer is consistent with the order in which events occur. Therefore, by combining the `task_id` information to concatenate event fragments from different tasks, a precise Runnable entry event time sequence can be reconstructed. This timeline does not record exit timestamps separately, but the exit result and output status of the corresponding Runnable are reflected through `flags` and `out_hash` in the same event record. A task scheduling event list or sequence diagram can be generated to observe the execution order, adjacency relationships, and time distribution before and after triggering of each Runnable entry for each task. Once the complete entry event timeline is reconstructed, it's possible to quickly identify which module the anomaly first occurred in by comparing it to normal conditions: by comparing the in_hash recorded at each Runnable entry point with the out_hash backfilled upon exit, and then comparing this with historical normal operation records or simulation expected values, the function or data where the earliest anomaly deviation occurred can be identified. If evidence shows that the input digest of Algo_DeltaV is still consistent with normal samples, but the output digest in its corresponding event record deviates from the normal value for the first time, it indicates that the anomaly first occurred in the computation logic of Algo_DeltaV or its internal state update.

[0078] 2) Call Chain Bloom Signature Comparison: The call signature bitmaps `call_pre` and `call_post` provided in the evidence package are compared with the candidate execution path set generated by the software static model or source code analysis. Specifically, for several suspicious functions or branches, their candidate paths are simulated offline. The list of witness point IDs traversed by each path is mapped to a simulated Bloom bitmap, which is then matched with `call_pre` and `call_post` in the evidence. Since `call_pre` represents the most recent complete 200ms background window before triggering, and `call_post` represents the path fingerprint of the current window where the trigger occurred up to 20,000us after the trigger, the offline analysis focuses on comparing the common and differing bits of both, and these differing bits are associated with suspicious Runnable or process segments within the current window where the trigger occurred, based on the timeline. If `call_pre` already contains witness points such as "collision secondary confirmation trigger" and "ΔV exceeding threshold," and `call_post` adds witness points such as "DeploymentDecision execution" and "pre-tightener activation," it can be inferred that the deployment decision and subsequent pre-tightener process are newly added suspicious paths relative to the background window before triggering. These inferences corroborate the task scheduling sequence in the timeline, which can greatly narrow down the scope of suspicion.

[0079] 3) Assertion Results Assist in Diagnosis: By combining the assertion bitmap, it's immediately clear which safety invariants were violated at the time of the accident. A 1-bit setting in the collision secondary confirmation consistency assertion bit indicates a desynchronization of the collision secondary confirmation sensors, while a 1-bit setting in the ΔV monotonicity bit indicates abnormal fluctuations in the ΔV calculation. This information helps quickly pinpoint the problematic subsystem (sensor synchronization issues, algorithm numerical problems, etc.). Engineers can then further focus on code inspection or testing of the relevant modules.

[0080] 4) Differential Replay and Verification: Based on the timeline reconstruction and inference path, engineers can replay the input (sensor data, triggering conditions) in a HIL (Hardware-in-the-Loop) or SIL (Software-in-the-Loop) test environment to verify whether the same fault can be reproduced. If a certain parameter threshold is suspected to be causing a misjudgment, the parameter can be adjusted and the test can be repeated to observe whether the fault disappears or the phenomenon is alleviated. Through this repeated experimentation, the root cause of the anomaly can be identified. If it is found that the anomaly no longer occurs as long as the collision secondary confirmation sensor threshold is slightly increased, the conclusion may be that the collision secondary confirmation threshold is set too low, causing false triggering.

[0081] 5) Generate a conclusion report: Based on the timeline, call signature comparison, assertion bitmap, and verification test results, a final incident analysis report is generated. The report lists the minimum set of factors that caused the anomaly (which could be a software logic error or a sensor malfunction) and corresponding improvement suggestions (such as adjusting thresholds, replacing sensors, modifying code logic, etc.). This evidence and conclusions can not only guide software improvement and product recall decisions but also provide technical support in incident regulatory investigations, demonstrating that the product design incorporates sufficient monitoring and recording methods.

[0082] VII. Performance Overhead and Real-Time Performance Analysis The above method is designed to keep monitoring overhead to an extremely low level, and actual testing has verified that its impact on system real-time performance is negligible. • CPU Time Overhead: Taking CrashAlgoTask running at 1kHz with 4 Runnables per cycle as an example, it generates 4000 Runnable entry event records per second (24 bytes per record, write speed 96KB / s). The recording process includes read time, write buffer, and hash digest calculation; when a Runnable exits, only the out_hash and exit flag are backfilled for the same event record, without creating a new independent exit event record. HashInputsWhitelist and HashOutputsWhitelist are implemented using fixed points and maintain a fixed execution path; the execution time of entry hooks, exit hooks, and CALL_WITNESS are all in the microsecond range, and their longest execution time has been confirmed by actual testing using GPT / cycle counters and meets the time budget of the corresponding task. For witness points with execution frequencies higher than 1kHz, a fixed 4-division frequency is used, without switching between 1:1 and 1:4 based on the runtime CPU load.

[0083] • Storage and Memory Usage: In this embodiment, the msep_t double buffer occupies 13136 bytes of RAM; g_bloom_prev and g_bloom_cur occupy 256 bytes of RAM; the assertion bitmap and state variables occupy 64 bytes of RAM. The monitoring code (hooks, hashes, assertion checks, CRC) occupies 10KB of Flash ROM. The evidence data block size in NvM is fixed at 8192 bytes. The evidence packet writing frequency is controlled by trigger conditions, and the Flash erase / write lifetime remains within the required range.

[0084] • Scheduling and Real-Time Performance: Monitoring instrumentation does not introduce new tasks or interrupts; all operations are completed within the existing task context. Each recorded interrupt-disabled or atomic interval lasts only tens of nanoseconds to a few microseconds, far shorter than the cycle requirements of high-priority tasks. No instances of task deadlines being lost due to monitoring were observed in actual testing. The system also incorporates a hardware watchdog and the operating system's time monitoring mechanism: if any high-priority task fails to feed the watchdog in time or exceeds its runtime due to unforeseen circumstances, a reset is immediately triggered, thus preventing the accumulation of errors in the monitoring logic from affecting system functionality. Overall, under the highest ASIL-D safety requirements, this solution achieves free and non-interfering operational monitoring: it does not impose additional burden on critical paths of airbag control (such as ignition control ISR), and the execution time jitter of periodic algorithm tasks is controlled within the nanosecond / microsecond range, without affecting the control system's timely response to sensor and actuator events.

[0085] 8. Functional safety assurance measures (ASIL-D compliance) The above method employs multiple measures during implementation to ensure compliance with the ASIL-D functional safety requirements of ISO 26262: • Memory and Data Isolation: Monitoring-related data structures and buffers are placed in a protected memory area, isolated from the data of the application control logic. The AUTOSAR MemMap mechanism allocates the msep_t buffer to the NoInit segment to prevent it from being zeroed during system initialization. The microcontroller configures the MPU (Memory Protection Unit) and sets memory access permissions: the MPU area containing the evidence buffer is configured for privileged read / write access by the monitoring module, while the application control logic has no read / write permissions to this area in a non-privileged state and completes writing through a controlled interface. This prevents unauthorized access or accidental out-of-bounds destruction of evidence data by application logic, thus achieving free and uninterrupted access.

[0086] • Time-based behavior monitoring: Hardware watchdog timers and operating system runtime monitoring are fully utilized. High-priority tasks must complete and feed the watchdog within their cycles; otherwise, the system will consider a fault to have occurred and execute a safety reset strategy. The monitoring code is designed not to block high-priority tasks under any circumstances, nor to extend task execution time beyond its design limits. If a task timeout occurs due to unforeseen circumstances (such as extremely rare long-term interrupt shutdowns or Flash operation delays), functional safety mechanisms will intervene promptly to ensure the system returns to a safe state.

[0087] • Diagnostic Interface Security: Data in the evidence package can only be read within a secure diagnostic session. Security access controls prevent unauthorized reading. The implementation also rigorously validates diagnostic read requests, ensuring that input address and length parameters are within allowed ranges and preventing security vulnerabilities such as buffer overflows caused by malicious requests.

[0088] • Resource Boundary and Security Protection: The system does not automatically reduce monitoring frequency or suspend monitoring points based on CPU load during runtime. This solution uses a GPT / cycle counter to measure resource boundaries and accordingly solidifies the whitelist field set, witness point set, and high-frequency witness point 4-way frequency division configuration. In the event of unforeseen execution timeouts or resource anomalies, security processing is triggered by operating system runtime monitoring and a hardware watchdog, without modifying the evidence collection set during runtime. This maintains the predictability of recorded content and execution overhead, and ensures that the core airbag function always has the highest priority.

[0089] • Critical Electrical Isolation: In terms of hardware design, the monitoring module never intervenes in the electrical control circuits related to airbag ignition. Specifically, the monitoring function does not add any hardware components or loads to the ignition drive circuit, and the software does not perform operations in the ignition ISR, ensuring that the ignition decision and execution process is solely guaranteed by the original control algorithm and hardware. Write operations to non-volatile memory (Flash) are scheduled during safe periods outside of critical ignition timing segments. Interruptions are not prohibited during write operations, and the write operation is protected by operating system runtime monitoring to ensure that the write operation does not enter the critical ignition timing segment. After freezing, the evidence package is first stored in the NoInit RAM segment; when the VCAP voltage and write energy budget meet the conditions, it is then copied and written to Flash by ComTask to preserve evidence under complete power-down scenarios; if the write conditions are not met, a copy of NoInit is retained for reading after a reset and startup in cases where RAM power failure has not occurred. In short, the monitoring and recording function does not affect the reliable execution of airbag ignition.

[0090] • Comprehensive Development, Testing, and Verification: The monitoring module itself underwent rigorous verification according to ISO 26262 requirements, including unit testing (100% statement and branch coverage, and key safety decisions meeting MC / DC coverage requirements), integration testing, and hardware-in-the-loop (HIL) testing. Timing and resource boundary testing was particularly emphasized: this included monitoring correctness under high-frequency task alternation, data integrity after buffer loopback, handling of simultaneous window merging when trigger condition jitter occurs, suppression and recovery of new packets when the ready buffer is occupied, and data retention during power-on / power-off processes. Fault injection testing was also conducted for various potential faults (such as sensor disconnection, short circuit, and asynchronous triggering of secondary collision confirmation), confirming that assertion detection and triggering mechanisms respond correctly. Finally, vehicle-level verification was performed in a real vehicle or high-fidelity HIL environment, and parameter thresholds were calibrated and optimized. The entire development and verification process is meticulously documented to ensure compliance with functional safety development procedures and support for product functional safety certification.

[0091] Example 2 This embodiment provides an automotive airbag control unit, including a monitoring module, which is configured to perform the method described in Embodiment 1.

[0092] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A method for recording a minimum sufficient evidence package for an airbag control unit, characterized in that, This method is executed in the Classic AUTOSAR environment and includes the following steps: S1. Determine whether the abnormal symptom condition and the running state time gating condition are met simultaneously. If yes, the trigger condition is determined to be met, and step S2 is executed. If no, step S1 is repeated. S2. Record the trigger time and freeze the event information, invariant assertion bitmap, path signature and key variable snapshot at the end of the predetermined window after the trigger, and generate the minimum sufficient evidence package; Specifically, the generation of the event information is as follows: Record the first information, including task identifier, unit identifier, relative time difference, event flag, and summary of key input parameters, at the entry point of the runnable entity to be scheduled for execution. At the point where the runnable exits, a summary of key output results is added to the first information and the event flag is updated to form the second information, which serves as the event information. The path signature includes the trigger-before-background path signature and the current window-freeze path signature, which are obtained by copying the current scroll path bitmap updated at a predefined witness point; The generation of the invariant assertion bitmap is specifically as follows: The predefined runtime invariants are checked in real time at runtime, and the identifiers of the violated invariants are recorded. The invariant assertion bitmap is then updated and generated.

2. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The abnormal symptom condition is determined to be met if any of the following conditions are met: a) Abnormal deployment decisions; b) The criteria for secondary collision confirmation and velocity change are inconsistent; c) Ignition circuit malfunction; d) Approaching the trigger threshold but not actually deployed; When both the preset operating state and the preset time window are met, it is determined that the operating state time gating condition is satisfied.

3. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The background path signature before triggering and the frozen path signature of the current window are both composed of a Bloom filter bit array, and multiple hash functions are used to map a witness point identifier to the Bloom filter bit array and set the bit. The background path signature before triggering is obtained by copying the previous scrolling window when the triggering condition is met, and the current window freeze path signature is obtained by copying the current scrolling window when the predetermined window ends after triggering.

4. The method for recording the minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The predefined witness point is located at a critical branch edge or state transition point that can uniquely distinguish mutually exclusive execution paths.

5. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The predefined operational invariants include multiple variables from the following: consistency of the trigger states of the secondary collision confirmation sensor and the primary collision sensor; integral monotonicity of the velocity change; minimum interval between coaxial dual-stage airbag ignitions; ignition circuit resistance range; and power rail voltage range.

6. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, In the invariant assertion bitmap, the corresponding bit of each invariant is kept at 0 under normal circumstances, and the corresponding bit is set to 1 when the invariant is violated.

7. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The key variables include multiple items from the following: the current state of the collision secondary confirmation sensor, the calculated value of the most recent speed change, the deployment decision flag, the measured value of the ignition circuit resistance, the battery voltage, the energy storage capacitor voltage, the invariant assertion logic version number, the trigger condition number, and its threshold calibration ID.

8. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The method also includes: The evidence packet is written to the non-volatile memory Flash when the energy storage capacitor voltage is higher than the Flash programming threshold and the write energy budget is met; otherwise, the evidence packet is retained in the volatile storage area that is maintained after reset.

9. The method for recording a minimum sufficient evidence package for an airbag control unit according to claim 1, characterized in that, The method also includes: The minimum sufficient evidence package is output through the standard diagnostic service interface.

10. A car airbag control unit, characterized in that, The method includes a monitoring module configured to perform the method as described in any one of claims 1-9.

Images