Airborne system ICD verification method and system

Abstract

The invention provides an airborne system ICD verification method and system, and relates to the technical field of airborne systems, and the method comprises the steps: obtaining one or more to-be-verified ICD data, and carrying out the standardization processing; semantic modeling is carried out on the standardized ICD data, and a digital twinborn model is constructed; identifying and associating the signals representing the same physical parameter to form a homologous signal group; performing multi-domain context association and risk identification on the homologous signal group according to the model, and generating a multi-dimensional static verification rule set and a formalized behavior verification plan; selecting a verification rule set according to the development guarantee level, and generating a structured verification plan; and executing comprehensive verification according to the verification plan, summarizing all verification results, and generating a structured report. According to the invention, full-life-cycle, multi-level and traceable automatic verification of airborne system functions, machinery, electricity, data and software and hardware interfaces is realized, the verification efficiency and confidence coefficient are significantly improved, the integration risk is effectively reduced, and airworthiness evidence obtaining is strongly supported.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of airborne system, and in particular to a verification method and system of airborne system ICD. BACKGROUND

[0002] Modern aircraft is a highly complex "system of systems", its safe and reliable operation depends on the seamless interaction of a large number of hardware and software components. In order to manage the interface between these components, a variety of types of interface control documents (ICD) are used in engineering, which respectively define the connection and interaction specifications of mechanical, electrical, data and function. However, in the traditional development mode, these ICDs are independently written and maintained by different professional teams, resulting in serious technical defects: Data islands and conflicts: there are often contradictions between mechanical (MICD), electrical (EICD) and data (EoICD) files describing the same physical interface. For example, the connector model in the electrical schematic may not match the mechanical three-dimensional model. These inconsistent errors are usually not discovered until the expensive physical integration stage, resulting in major rework and project delays.

[0003] Verification coverage is not complete and depth is insufficient: relying on manual review, it is difficult to find deep technical errors (such as electrical load mismatch, data protocol conflict), and it is also difficult to systematically verify the correctness of the interface between different system levels (for example, how a top-level functional requirement is finally implemented to a specific hardware pin).

[0004] Lack of systematicness and traceability: the traditional method lacks a unified, hierarchical verification perspective, making it difficult to comprehensively evaluate system-level characteristics (such as total power consumption, total bandwidth), and also difficult to establish a clear traceability path to prove to the airworthiness agency that the design fully meets the safety requirements.

[0005] Therefore, the industry urgently needs a systematic and automatic verification method to ensure the consistency, correctness and integrity of the massive ICD data, thereby reducing integration risks, improving development efficiency and supporting airworthiness certification. SUMMARY

[0006] In view of the problems of low efficiency, easy error, incomplete coverage and lack of traceability in the traditional manual verification method of complex airborne system ICD (interface control document), the present application provides a verification method and system of airborne system ICD. The present application is an automatic verification architecture based on requirement traceability and multi-dimensional analysis, which establishes a complete process of ICD data standardization processing, hierarchical verification strategy formulation, multi-dimensional comprehensive verification and structured report generation, which can be used to guide and support the whole life cycle interface management and compliance verification of airborne system in the research and development, integration and airworthiness certification stages.

[0007] The embodiment of the application provides the following technical scheme: a verification method of an airborne system ICD, comprising: Obtaining one or more ICD data to be verified from a configuration management database or a data source and performing standardized processing, classifying ICD parameter attributes into atomized attributes and textual attributes; Performing semantic modeling on the standardized ICD data, constructing a digital twin model of a system interface architecture; according to a predefined homologous mapping dictionary, identifying and associating signals representing the same physical parameter to form a homologous signal group; according to the digital twin model, performing multi-domain context association and risk identification on each signal in the homologous signal group to generate a multi-dimensional static verification rule set and a formal behavior verification plan for a high-security level interface; selecting a verification rule set for each homologous signal group according to a hierarchical strategy of a development guarantee level, and automatically generating a structured verification plan; According to the verification plan, performing comprehensive verification on the data of the atomized attributes, including static consistency, integrity and correctness verification, multi-physical field joint simulation and automatic fault injection and safety verification; for the data of the textual attributes, generating a structured check sheet; All verification results are summarized to generate a structured report and output an archive.

[0008] The application also provides an airborne system ICD verification system for implementing the above method, comprising: A strategy making module for defining the verification baseline of a project, an ICD hierarchical model, a verification rule and an error level; A data processing module for connecting a data source, calling an adapter to parse original ICD data in different formats, converting the original ICD data into a standardized internal data model, and performing attribute classification and relationship establishment; An interface verification module for receiving a verification instruction, dispatching and executing a verification algorithm according to a verification strategy, and processing manual review items; A report generation module for obtaining verification results and generating a structured report; A data storage module for persistently storing configuration information, a standardized ICD data model, verification results and generated reports.

[0009] Compared with existing technologies, the beneficial effects achieved by at least one of the above-mentioned technical solutions adopted in the embodiments of this specification include at least the following: Addressing the integration difficulties and airworthiness compliance challenges caused by complex interfaces and data silos in the development of modern airborne systems, the embodiments of this invention propose a systematic solution for the practical application of automated ICD verification in engineering: First, to address the challenge of fusion of multi-source heterogeneous ICD data, a data processing flow based on adapters and a unified data model is designed, realizing data standardization and the establishment of correlation relationships; Second, to address the complexity and configurability requirements of verification strategies, a multi-dimensional verification rule engine based on integration level, ICD type, and development assurance level is proposed; Third, to address the issue of combining automation and manual review, a dual-track verification mechanism is designed, consisting of atomic attribute automatic verification and textual attribute structured checklist generation. Combining the above three aspects, automated verification of the entire lifecycle, multi-level, and traceable aspects of airborne system functions, mechanics, electrical systems, data, and hardware / software interfaces can be achieved, significantly improving verification efficiency and confidence, effectively reducing integration risks, and strongly supporting airworthiness certification. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0011] Figure 1 This is a schematic diagram of the verification method for the airborne system ICD according to an embodiment of the present invention; Figure 2 This is a block diagram of the verification system according to an embodiment of the present invention; Figure 3 This is a flowchart of the multi-level ICD verification strategy according to an embodiment of the present invention; Figure 4 This is a flowchart of the comprehensive verification process of an embodiment of the present invention; Figure 5 This is a schematic diagram of the data processing and verification logic of Example 1 of the present invention. Detailed Implementation

[0012] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0013] The abbreviations and key terms used in this invention are defined in the table below:

[0014] The verification method for the airborne system ICD of this invention, in specific implementation, is as follows: Figures 1-4 As shown, the main steps include: Step 1, Extract and standardize data 1.1 Extract and clean data Firstly, call the interface reserved by the configuration management library, according to the user input or system configuration of the project code, model code and target baseline version number, retrieve the corresponding ICD document record, and perform version number verification on the matched baseline version, confirm that the data is in the "approved" or "frozen" state.

[0015] Then the retrieved ICD original data is extracted to the local temporary storage area in the form of data stream or file set for subsequent processing. In the extraction process, the source path of the file, the extraction timestamp, is recorded for traceability and tamper prevention.

[0016] After that, the ICD data from different sources will be format-identified (supporting data formats such as ASML, XML, CSV, PDF, DOCX, etc.), and the identified multiple format data will be uniformly converted to XML format data, and duplicate records will be removed (based on the combination key of interface identifier, parameter name and version number).

[0017] In addition, the numerical value type parameters need to be unified in attribute units, such as: voltage unified as volt (V); air pressure unified as hundred P (HPa); hydraulic pressure unified as psi; speed unified as knots (kts).

[0018] Record all cleaning and conversion operation logs in the whole process of data extraction and cleaning for problem tracking and configuration review.

[0019] 1.2 Attribute classification Take the data in step 1.1 as input, and classify the ICD attributes into atomized attributes and textual attributes. Among them, atomized attributes refer to attributes with clear, single, and machine-directly-parsable and comparable attributes, such as maximum range, transmission rate, rated voltage, etc. While textual attributes refer to attributes described in natural language, containing design intent, notes, references to standards, etc., which are difficult for automated tools to directly judge the correctness of their semantics, such as interface function description, notes, etc.

[0020] Step 2, Develop strategy and generate plan 2.1 Semantic modeling and identification of homologous signal group (HSG) signals 2.1.1 Automated parsing and standardized data representation Firstly, all types of Interface Control Documents (ICD), including Functional Interface Control Document (FICD), Mechanical Interface Control Document (MICD), Electrical Interface Control Document (EICD), and Electronic Interface Control Document (EoICD), are input into the system through an automated parser. The system parses and converts the content of these semi-structured documents into a normalized, object-oriented, Airborne System Modeling Language (ASML) internal data model. Each property defined in the original ICD (e.g., rated voltage / range for EICD, vibration environment level for MICD, BAG interval for ARINC 664 in EoICD, etc.) is mapped as a property of an object in the corresponding data model, thus building a digital twin model covering the entire airborne system interface architecture.

[0021] 2.1.2 Identification and Linking of Homologous Signal Groups (HSG) One of the core innovations of the system is the ability to automatically identify and associate signals defined in different bus protocols, different ICDs, but representing the same physical parameter. This process is achieved through a pre-configured, user-maintainable "Homologous Mapping Dictionary". The dictionary defines the semantic mapping relationship between signals in different bus protocols and the underlying physical parameters in a structured form.

[0022] A typical dictionary entry looks like this: {'Physical Parameter': 'Indicated Airspeed', 'A429_Tag': '204', 'A664_DS_Parameter': 'AIRSPEED_INDICATED'} During the model building process, the system scans all parsed signal objects using the dictionary. When signals belonging to different protocols but mapping to the same physical parameter are identified, the system will create a "Homologous Signal Group" (HSG) object. The HSG object serves as a central node, linking all related signal objects through reference relationships, for example, aggregating ARINC 429 DP / RP objects, ARINC 664 DP / RP objects, and related functional control parameter objects in FICD that represent Indicated Airspeed. By creating HSGs, this implicit, human-dependent association is transformed into an explicit, automatically processable part of the system model.

[0023] 2.1.3 Multi-domain Context Association and Model Enrichment After identifying and establishing HSGs, the system traces back each logical signal in the HSG to its physical and electrical environment by traversing the integrated system-wide data model.

[0024] Specifically, for any signal in HSG (e.g. AIRSPEED_INDICATED), the system performs the following trace and link operations: Logic-to-Device Trace: Starting from the DP / RP object defined in EoICD, the system traces up to the A664_DS (Data Structure) or A429_Channel (Channel) that the object belongs to, and further traces to the LogicPort or A429_Port that carries the channel, and finally locates to the Line Replaceable Unit (LRU) that the port belongs to, e.g. “Air Data Computer”.

[0025] Device-to-Physical / Electrical Property Link: Once the specific LRU object is located, the system automatically associates the properties of the LRU defined in MICD and EICD. For example, the “Air Data Computer” LRU object is linked with the vibration environment level (e.g. DO-160 Sect 8 Category), shock tolerance spectrum defined in MICD, and the power supply type, grounding method, EMI suppression defined in EICD.

[0026] 2.1.4 Potential Risk Identification and Rule Generation Based on Causal Reasoning 2.1.4.1 Integration of Engineering Failure Knowledge Base The system is built-in with a structured, extensible engineering failure knowledge base. The knowledge base encodes the failure propagation logic and engineering experience across physical domains in the form of “IF-THEN” rules. For example, a typical knowledge entry is: IF (vibration environment level. resonance frequency overlaps with connector model. mechanical resonance point) THEN (potential risk: fretting wear leads to increased contact resistance, which in turn can cause signal integrity degradation).

[0027] 2.1.4.2 Automatic Scanning and Identification of Causal Chains The system traverses the entire multi-domain model, matching the entity properties in the model (e.g. vibration level of LRU, connector model, signal BER requirement) with the failure knowledge base. When multiple properties satisfy the premise of a knowledge, a potential risk causal chain is identified.

[0028] 2.1.4.3 Dynamic Synthesis of Ad-hoc Verification Rules For each identified risk cause-effect chain, the system automatically generates a provisional, context-specific verification rule. The rule contains three parts: Trigger condition: explicit risk context (e.g., "when LRU-X is in high-vibration region VIB-Zone-1"). Verification goal: quantified assertion (e.g., "assert that the CRC error rate increment of signal S1 <1e-9"). Recommended verification method: based on the risk nature and DAL level, the most suitable verification method is recommended (e.g., "perform dynamic mechanical-signal integrity co-simulation" or "submit to connector expert for focused review").

[0029] 2.2 Generation and application of multi-domain static consistency rule set 2.2.1 Rule set 1: Cross-protocol conversion and equivalence verification (EoICD layer) This rule set directly responds to the user's core requirement for ARINC 429 and ARINC 664 homologous signal consistency confirmation, and through a series of specific, quantifiable technical indicators, it gives the verification process significant novelty and creativity. For each HSG in the model, the system will automatically execute the following series of verification rules: Periodicity and rate equivalence verification: This rule aims to ensure that homologous signals on different buses can meet the system's requirements for data freshness. The rule first compares the update period of the ARINC 429 data word (Update_Period, unit: ms) with the bandwidth allocation gap (BAG, unit: ms) of the ARINC 664 virtual link. The verification logic is: This inequality ensures that the rate at which modern subsystems based on ARINC 664 provide data is at least not lower than the expected rate of traditional ARINC 429 subsystems that rely on that data. The rule also contains a configurable tolerance (e.g., 20%) to accommodate reasonable time margins introduced by system architecture differences (such as gateway processing delays).

[0030] Resolution and accuracy consistency verification: This rule aims to prevent data accuracy loss due to bus protocol conversion. For an HSG, the rule automatically calculates the effective resolution of the ARINC 429 signal. For example, for a BNR (binary) encoded signal, its resolution can be calculated as: The resolution is then compared to the resolution of the ARINC 664 side- homogenous signal. For ARINC 664 signals using standard data types (e.g. Float32, Int16), the resolution is jointly determined by the data type itself and the resolution (scaling factor) defined in the ICD. The verification criterion is that the effective resolution of the ARINC 664 signal must be less than or equal to (i.e. higher precision or equal) the resolution of the ARINC 429 signal, ensuring that no critical information is lost in the data conversion or gateway transmission.

[0031] Semantic State Mapping Verification: This rule goes beyond simple syntax checking, delving into the semantic layer of signal states. It verifies that the logical mapping between the ARINC 429 Symbol / State Matrix (SSM) and the ARINC 664 parameter's Status Indication field (ParameterStatus) is correct. The system uses a configurable "State Mapping Table" to define the legal correspondences. For example, the table can stipulate that when the A429 SSM is 'Failure Warning', the corresponding A664 Status field must be 'Invalid' or 'Functional Test', but not 'Normal Operation'. This check ensures that the system consistently and accurately communicates critical information about data validity and device status across different bus domains, which is crucial for fault diagnosis and system fault tolerance.

[0032] Delay and Jitter Compatibility Verification: This rule focuses on the real-time nature of signals, ensuring that the transmission delays of modern network architectures do not violate the timing assumptions of legacy systems. The rule verifies that the maximum end-to-end transmission jitter (Jmax) of the ARINC 664 virtual link, plus the network transmission delay (which can be estimated or specified based on network topology and switch parameters), should not exceed the maximum transport delay (Max_Transport_Delay) allowed for the homogenous ARINC 429 data parameter. That is: This ensures that critical data arrives within the defined time window at the receiving end, even through complex switched networks, meeting the requirements of hard real-time systems.

[0033] 2.2.2 Rule Set Two: Physical-to-Logical Integrity Verification (across MICD / EICD to EoICD layers) This rule set introduces an innovative verification dimension, establishing a formal link between the physical working environment and the logical data integrity. This idea is inspired by the concept of multi-physics coupling analysis, which suggests that the reliability of logical data depends not only on its definition but also on the performance of the physical hardware that carries it in the real working environment.

[0034] Vibration-induced data integrity rule: For any HSG belonging to DAL A or DAL B class (determined by ARP4754A safety assessment process), this rule automatically checks whether the physical design of its host LRU meets the high integrity requirement. The rule extracts the vibration environment class (e.g. DO-160 Section 8 categories S, M, or U) and shock tolerance spectrum properties of the LRU from MICD. Then, these properties are compared against a pre-defined library of environmental suitability specifications for high safety class systems. If the environment class of the LRU is lower than the specification requirement, the system will generate a warning indicating that the physical design might not be able to guarantee the integrity of the critical data it carries under severe vibration or shock conditions.

[0035] Electromagnetic compatibility (EMC) rule: For critical signals of DAL A / B class, this rule ensures that adequate EMC protection measures are specified for the LRU and its connectors that carry these signals by cross-referencing EICD. The rule checks whether properties such as EMI suppression, RF shielding, and proper grounding methods (e.g. single-point grounding or multi-point grounding) are explicitly defined in EICD. This rule links abstract safety requirements (data not disturbed) to concrete engineering design (shielding, grounding) to ensure that critical data links are protected from electromagnetic interference (EMI) or radio frequency interference (RFI) damage.

[0036] Thermal drift-data validity coupling rule: This rule is a typical embodiment of the multi-physical field verification idea, mainly applied to signals that are acquired by analog sensors and digitized as A429 / A664 parameters. The rule first extracts the multi-field coupling equation from the “environmentally coupled device” property section of MICD, such as the relationship between drift and vibration and temperature changes: . Then, using the LRU operating temperature range (Temperature Cycle Range) and vibration level defined in ICD, the maximum potential parameter drift caused by temperature changes is calculated. Finally, the rule compares this maximum drift with the resolution (i.e. the value of the least significant bit LSB) of the signal defined in EoICD. The verification criterion is: Must be less than the signal resolution. If the potential temperature drift is greater than one LSB, it means that changes in environmental temperature can cause the data value to produce an indistinguishable error jump, and the system will flag this as a high-risk inconsistency.

[0037] 2.2.3 Rule Set Three: Functional-to-Physical Resource Allocation Verification (across FICD to MICD / EICD layers) This rule set ensures that the physical resources (such as power supply, computing power, bandwidth) defined in MICD and EICD are sufficient to support the functional requirements (defined in FICD) allocated to the corresponding hardware.

[0038] Power Budget Aggregation Rule: The system first identifies all functions allocated to a specific LRU. Then, it aggregates the Power attribute values of these functions from the FICD to calculate the total functional power demand of the LRU . Next, it extracts the power supply interface attributes of the LRU from the EICD, including Rated Voltage and Rated Current, to calculate its maximum power supply capability . The verification rule is: where is a configurable safety margin (e.g., 80%). This rule can automatically discover LRU power overrun issues due to function addition or change.

[0039] Data Throughput and Bus Capacity Rule: For a specific bus node (e.g., a port of an ARINC 664 switch), the system identifies all virtual links (VLs) passing through the port. By aggregating the bandwidth demand of each VL (which can be calculated by the formula ), it obtains the total data throughput demand of the port. Then, it compares this total demand with the physical capacity of the port (e.g., 10 Mbps or 100 Mbps). This automated network calculus analysis can discover network congestion risk points in advance, ensuring that the network architecture can carry the designed data traffic.

[0040] 2.3 Formal Behavioral Verification of Critical Interfaces (DAL A / B) 2.3.1 Generation of Abstract State Machine Model For each HSG identified as DAL A or DAL B level, the system will automatically generate an abstract finite state machine model for it. This model aims to capture all possible state combinations and their transition relationships between homogenous signals.

[0041] State Definition: Each state of the model represents a combination of all signal state attributes in the HSG. For example, for an HSG containing A429 and A664 signals, its state space may include: {A429 state='Normal Operation', A664 state='Valid'}, {A429 state='Functional Test', A664 state='Functional Test'}, {A429 state='Fault Warning', A664 state='Valid'}, etc.

[0042] Transition Definition: Transitions between states are triggered by key events in the system, including periodic updates of signals, update timeouts, status change, etc. These transition relations together form the dynamic model of the signal interaction behavior.

[0043] 2.3.2 Automatic generation of temporal logic properties The system has a built-in library of extensible property templates, which encode key cross-protocol behavioral requirements using formal languages such as Linear Temporal Logic (LTL) and Computation Tree Logic (CTL). During verification, the system automatically instantiates these templates based on the specific properties of the HSG (e.g., update period, delay requirements), generating a set of formal properties that need to be proven.

[0044] 2.3.3 Model checking execution and counterexample generation The system will automatically invoke an integrated model checker tool. This tool receives the abstract state machine generated in Section 2.3.1 and the temporal logic properties generated in Section 2.3.2 as input. The model checker will exhaustively explore all possible execution paths of the state machine, rigorously proving mathematically whether the state machine satisfies all given properties.

[0045] For each property, the model checker will output a clear "True" or "False" verification result. If the result is "False", i.e., the model does not satisfy a certain property, the model checker will generate a specific counterexample. The counterexample is a clear sequence of events that shows how the system evolves from the initial state step by step, eventually violating the property. For example, for the bounded response property, the counterexample may show a path where after the A429 signal is updated, the A664 signal still does not update after the time threshold.

[0046] This mathematical proof-based verification method can find design flaws caused by complex timing and concurrent interactions, and applies formal methods to interface consistency verification between different bus protocols. It provides a technical means that can be used as audit evidence to meet the verification requirements of high safety level software in DO-178C / DO-333 standards.

[0047] 2.4 Rule selection and verification plan generation for DAL hierarchy 2.4.1 Mapping of Development Assurance Level (DAL) The system first needs to obtain the output from the system safety assessment process, mainly the results of the Functional Hazard Analysis (FHA) and the Preliminary System Safety Assessment (PSSA). These documents define the failure impact level of aircraft-level functions (such as catastrophic, dangerous, etc.), and accordingly assign a Functional Development Assurance Level (FDAL) to each function.

[0048] The system establishes traceability links between functions and the interface signals supporting them through its internal integrated data model. Through these links, the system is able to propagate the FDAL of a function down to each HSG, assigning it a corresponding DAL. For example, if the FDAL of the "primary flight display" function is A, then the HSGs providing it with critical parameters (such as attitude, speed, altitude) will also be assigned the DAL A rating.

[0049] 2.4.2 Hierarchical application of verification rule sets The system intelligently selects and applies verification rule sets of different rigor according to the DAL rating assigned to the HSG, following a configurable strategy. This hierarchical strategy embodies the core idea of ARP 4754A: applying the most rigorous engineering activities to the system elements with the highest risk.

[0050] DAL A / B: For the highest safety-rated interfaces, the system will perform the most comprehensive verification.

[0051] All static consistency rule sets (2.2.1, 2.2.2, 2.2.3) are enforced.

[0052] Formal behavioral verification (2.3) is enforced to mathematically prove the correctness of its dynamic interactions.

[0053] DAL C: For medium safety-rated interfaces, the focus of verification is on ensuring the correctness of their basic functionality and the adequacy of resources.

[0054] Cross-protocol conversion and equivalence verification (2.2.1) and function-to-physical resource allocation verification (2.2.3) are enforced. Physical-to-logical integrity verification (2.2.2) is marked as "recommended to perform" at the discretion of the engineer. Formal behavioral verification (2.3) is not required.

[0055] DAL D: For interfaces with minimal impact on failure, only the most basic verification is performed to ensure basic data exchange capabilities. Only a subset of the 2.2.1 rule set is applied, such as checking data range and unit consistency.

[0056] 2.4.3 Generation and output of verification plans Finally, the system will generate a detailed, executable verification plan based on all the information above. This plan is output in a structured data format (such as XML or JSON) and contains the following key information: Verification Object List: List all the HSGs being analyzed and their contained signals. Safety Criticality: Explicitly mark the DAL level of each HSG. Application Rules: List all the verification rule entries to be performed for each HSG in detail. Task Type: Automatically mark each verification task as either "fully automatable" (e.g. all static checks and formal verification) or "human review required" (e.g. root cause analysis on counterexamples generated by model checkers). Execution Order: Define the recommended execution order of tasks, usually putting high-automation basic checks (e.g. unit, range consistency) at the front to detect and fix low-level errors as early as possible.

[0057] This automatically generated plan not only provides a clear roadmap for the verification activities, but also itself is an important, ARP 4754A-compliant, traceable development process product. It clearly shows the verification strategy adopted for each interface and its correspondence with safety risks to the certification authority, greatly simplifying the compliance verification and certification process. This intelligent approach of integrating safety analysis, rule definition, and plan generation ensures the systematic, efficient, and certifiable nature of the verification process.

[0058] Step 3, Execute the comprehensive verification process 3.1 Perform consistency, completeness, and correctness verification This sub-step is the highest assurance level verification for the dynamic behavior of the Homogeneous Signal Group (HSG) signals. It utilizes the formal model and properties generated in Step 2.3, through mathematical exhaustive checking, to verify the logical correctness and timing safety of critical interfaces under all possible scenarios, meeting the stringent requirements of DO-178C / DO-333 standards for high safety level (DAL A / B) systems.

[0059] 3.1.1 Load formal model and instantiate property specifications This phase is the preparation work for formal verification, aiming to transform the abstract verification tasks defined in Step 2 into specific inputs executable by model checkers.

[0060] 1. Model and specification inputs: The system automatically loads the formal model file converted from the HSG abstract state machine model (generated by Step 2.3.1). This model is usually described in a specialized input language of a model checker (e.g. NuSMV, SPIN), precisely defining the system's states, variables, initial state, and transition relationships between states. The system also loads the set of temporal logic properties for this HSG generated by Step 2.3.2. These properties are in the form of Linear Temporal Logic (LTL) or Computation Tree Logic (CTL) formulas, representing the dynamic behavior requirements that the system must satisfy.

[0061] 2. Binding of model to context: The system binds abstract variables and events in the formal model to specific ICD parameters in the multi-domain semantic model. For example, the "A664_Update" event in the state machine is bound to the actual update mechanism of the ARINC 664 signal and its timing attributes such as BAG and Jmax^3^, ensuring that the verification results can be accurately traced back to specific design elements.

[0062] 3. Final instantiation of property specification: The system uses the bounded specific ICD parameter values ​​to finally assign values ​​to the templated attributes. For example, the T_max variable in the bounded responsiveness attribute template G (A429_Update → F≤T_max A664_Update) will be replaced with a specific millisecond value calculated based on the network topology and gateway latency, forming a complete specification that can be executed and verified.

[0063] 3.1.2 Execution Model Detection and State Space Analysis This stage is the core computational process of formal verification, where the model checker performs an exhaustive analysis of the system behavior.

[0064] 1. Invoking the Model Checker Engine: The system automatically invokes the integrated model checker, taking the prepared formal model and instantiated attribute reduction as input. The entire invocation process is completed through automated scripts, requiring no manual intervention.

[0065] 2. State Space Generation and Traversal: The model checker begins operation, systematically generating and traversing all possible reachable states corresponding to the formal model using algorithms such as fixed-point computation, constructing a complete state space diagram of the system. During this process, the checker considers all possible initial states, event interleaving sequences, and concurrent behaviors, ensuring comprehensive analysis that surpasses any verification method based on finite test cases.

[0066] 3. Attribute Validation and Judgment: For each loaded LTL / CTL attribute, the model checker searches the state space to mathematically prove (verify) whether the attribute is true in all possible execution paths. Attribute validation includes safety attribute validation and liveness attribute validation, which are respectively verified by the checker to verify that "some bad things will never happen" (e.g., G !(A429_Status = Normal&A664_Status = Invalid)) and to verify that "some good things will eventually happen" (e.g., G (Request → F Response)).

[0067] 3.1.3 Analyze counterexamples and locate design flaws When the model checker finds that the property is not satisfied, the counterexample output by the model checker is the key to locate and fix the deep design flaws.

[0068] 1. Counterexample analysis and visualization: The system receives the counterexample generated by the model checker. The counterexample is a specific sequence of states: S0→ S1→ S2→...→ Sn, where the state Sn violates the property being verified. The system converts each step in this sequence back to engineering terms in the HSG state machine and multi-domain semantic model, and presents it to the engineer in the form of a visual timeline or sequence diagram, making it easy to understand.

[0069] 2. Root cause mapping: The system deeply correlates the counterexample sequence with the multi-domain semantic model to pinpoint the root design elements that lead to the violation. For example, the counterexample might show that, due to a mismatch between the BAG setting of a certain ARINC 664 virtual link and the update period of an ARINC 429 signal, a T_max timeout occurs under certain bus load conditions, thus violating the bounded response property.

[0070] 3. Defect report generation and repair suggestions: Based on the root cause analysis, the system automatically generates a detailed defect report. The report not only describes the violation phenomenon, but also clearly shows the chain of events that led to the violation, and may provide preliminary repair suggestions (such as "suggest adjusting the BAG value of VL" or "review the state mapping table"). This report will be directly fed back to the development process to guide the designer to make targeted modifications, thus realizing the closed loop of verification and design.

[0071] 3.2 Perform multi-physical field joint simulation: analyze failure modes under cross-domain coupling This sub-step aims to dynamically couple and verify the statically associated physical environment attributes in the multi-domain semantic model with the logical interface behavior. By performing joint simulation, we actively discover and quantify the logical layer "emergence" faults such as signal integrity, timing deviation caused by mechanical vibration, temperature change and other physical environment stresses under real harsh working conditions, which are extremely difficult to reproduce in isolated environmental tests or logic tests. Configure joint simulation environment: The system automatically configures a joint simulation environment according to the verification plan. This environment couples multiple physical domain simulation models associated in the multi-domain semantic model through standard interfaces (such as FMI), forming a unified solution framework.

[0072] 3.2.1 Configure joint simulation environment and inject physical domain parameters This phase is the preparation work for simulation verification, and the core is to convert the static attributes defined in the multi-domain semantic model into input conditions and model parameters required to drive dynamic simulation.

[0073] 1. Automatic assembly of simulation workflow: The system automatically instantiates a co-simulation manager according to the verification plan. The manager links the associated simulation models in different domains (e.g. structural dynamics model, thermal conduction model, circuit / signal integrity model) into a co-solved simulation workflow through standards such as Functional Mock-up Interface (FMI).

[0074] 2. Assign environmental loads and boundary conditions: The simulation manager automatically extracts the physical environment parameters defined in MICD and EICD from the models and sets them as inputs to the corresponding simulation models. Structural simulation: inject vibration environmental levels (e.g. DO-160G Sect 8 curves), shock tolerance spectrum as mechanical boundary conditions. Thermal simulation: inject operating temperature range, temperature rate of change as thermal boundary conditions. Electrical simulation: inject parasitic parameters of connector types defined in EICD, cable impedance characteristics, etc.

[0075] 3. Configure monitoring and evaluation metrics: The system sets probes and monitors in the simulation models according to the key attributes of the HSG under verification, defines the output quantities that need to be observed. For example, for an ARINC 664 signal, monitor its eye diagram margin, bit error rate, end-to-end jitter, etc., and compare them with the thresholds specified in the EoICD.

[0076] 3.2.2 Perform coupled simulation and physical effect transfer This stage is the core execution process of the simulation, through data exchange between solvers, realize the cross-domain transfer and coupled calculation of physical effects.

[0077] 1. Start co-solution: The co-simulation manager coordinates the stepping of solvers in different domains (e.g. ANSYS Mechanical, Fluent, SPICE) to ensure that the simulation is pushed forward synchronously on a unified time axis.

[0078] 2. Data exchange between physical fields: The system transfers physical quantities between simulation models according to the risk causal chain identified in step 2.1.4. A typical "vibration-electrical" coupled simulation process is as follows: Mechanical response solution: The structural solver calculates the dynamic response of the LRU and its connectors under the given vibration spectrum, outputs the time-domain displacement / acceleration data of the key mounting points, especially the micro-displacement δ(t) between the connector pins.

[0079] Failure physics model calculation: The system takes the micro-displacement δ(t) as input, calls the built-in micro-displacement wear model, and calculates the increment ΔRc(t) of the contact resistance in real time.

[0080] Circuit performance solving: The circuit solver receives the time-varying contact resistance ARc(t) as a varying element in the circuit network, re-solves the differential link carrying the ARINC 664 signal, and outputs the time-domain results such as signal waveforms, signal-to-noise ratio, etc.

[0081] 3. Performance degradation monitoring and recording: Throughout the simulation time course, the system continuously records the monitored KPIs. The simulation manager pays special attention to the degradation of logical signal performance in the most severe environmental stress periods (such as resonance points, temperature extreme points), and captures any events that violate the ICD threshold.

[0082] 3.2.3 Analyzing simulation results and generating design feedback This stage post-processes and analyzes the simulation data, converting the observed physical phenomena into explicit engineering conclusions and design actions.

[0083] 1. Performance compliance determination: The system automatically compares the final performance indicators (such as maximum bit error rate, jitter value) output by the simulation with the tolerances defined in the EoICD, and gives a "pass" or "fail" verification conclusion.

[0084] 2. Causal chain tracing and root cause analysis: For cases where verification fails, the system generates a cross-domain impact analysis report. The report not only points out performance violations, but also presents a complete evidence chain from "environmental input" to "logical failure" (example: "Under the vibration excitation at frequency f0, the connector C1 micro-displacement reaches X μm, causing the contact resistance to increase Y Ω, which in turn causes the signal S1 eye diagram to close Z%, ultimately causing the bit error rate to exceed the threshold, violating the Mth requirement of the EoICD.") 3. Generate design improvement suggestions: Based on root cause analysis, the system provides quantitative and targeted design optimization suggestions (example: "Suggest replacing the connector C1 with the K series with higher anti-vibration level", or "Suggest adding a pre-emphasis circuit to the drive end of signal S1 to compensate for the high-frequency loss caused by increased resistance"), which are directly fed back to the design personnel to guide the revision of MICD, EICD or EoICD, achieving design iteration optimization based on physical models.

[0085] 3.3 Perform automated fault injection and safety verification This sub-step aims to verify the fault-tolerant mechanisms and safety boundaries of the system in a dynamic environment by actively introducing faults. Based on the system topology and functional association provided by the multi-domain semantic model, it systematically simulates various component failures to confirm that the system as a whole or the key homogenous signal group (HSG) can still meet the pre-defined safety properties under partial functional failure, thereby providing active verification evidence for the safety evaluation process to meet ARP 4761.

[0086] 3.3.1 Define fault injection set and safety monitoring specification This phase is the planning phase of the fault injection test, aiming to generate well-defined and comprehensive fault scenarios and judgment criteria based on system model and safety analysis.

[0087] 1. Generate fault scenario library: The system traverses the multi-domain semantic model, focusing on HSGs that support DAL A / B level functions and their associated physical and logical components. Call the built-in FMEA knowledge base to automatically match the typical failure modes for each critical component (such as power supply in EICD, virtual link in EoICD, and functional parameters in FICD), forming a structured fault scenario library.

[0088] 2. Instantiate safety monitoring properties: The system loads the top-level safety property templates (usually expressed in LTL / CTL) related to the current verification context from the safety requirement library. Instantiate the abstract variables in these templates as specific signals and states in the multi-domain semantic model, generating formal specifications that can be directly used for runtime monitoring.

[0089] 3. Configure injection and monitoring tasks: The system specifies the injection point, injection time, and duration of each fault scenario in the joint simulation environment. At the same time, bind the safety property specifications that need to be monitored and the key performance indicators that need to be recorded for each injection test, forming an executable verification task list.

[0090] 3.3.2 Execute fault injection and runtime verification This phase is the core execution link of the fault injection test, by dynamically introducing faults in the joint simulation environment, and using formal methods for real-time behavior monitoring to verify the safety of the system under abnormal conditions.

[0091] 1. Start controlled fault injection cycle: The system starts the joint simulation manager and loads the verification task list generated in step 3.3.1. The manager strictly follows the predefined sequence and applies the fault effect dynamically and controllably to the corresponding components of the multi-domain semantic model when the simulation runs to the specified time point or the system enters a specific state.

[0092] For example, when the simulation time reaches the high vibration phase, the system will accurately modify the contact resistance parameter of a connector defined in a certain EICD to a maximum value to simulate an open circuit; or when the network traffic reaches the peak value, force to discard a certain number of consecutive data packets of a key ARINC 664 virtual link to simulate network congestion or hardware transient fault.

[0093] 2. Perform runtime verification based on formal specifications: Throughout the entire duration of each fault injection and in subsequent simulations, the integrated runtime verification monitor is synchronously activated. The core task of this monitor is to perform real-time logical judgments on the macroscopic behavior of the system based on the formal security specifications (LTL / CTL formulas) instantiated in step 3.3.1. The monitor continuously monitors the signals and state changes related to the specifications in the multi-domain semantic model, rigorously checking whether security attributes such as "G (fault_Primary → F≤T_switchover valid_Backup)" (i.e., after a primary system failure, a switch to a valid backup system must be made within time T) are violated at any time. This method elevates security verification from passive post-processing of results to proactive, online behavioral compliance judgment.

[0094] 3. Recording Key Data and Violation Events: Throughout the process, the system synchronously records complete simulation data, including the precise timing of fault injection, the evolution sequence of key system states, fluctuations in performance metrics, and all judgment results from the runtime verification monitor. Once the monitor detects any violation of safety protocols, the system immediately captures and saves a complete data snapshot and event sequence before and after the violation, providing a detailed chain of evidence for generating precise counterexamples. Simultaneously, for injection scenarios that do not trigger violations, the system also records their final state as positive evidence of the system's effective fault tolerance.

[0095] 3.3.3 Analyze the results and generate safety assessment evidence. This stage is a comprehensive analysis of the results of the fault injection test, aiming to draw conclusions about the system's safety and provide evidence for design improvements or safety certification.

[0096] 1. Aggregation and Classification of Verification Results: The system aggregates the results of all fault injection experiments and classifies each scenario according to criteria such as "whether security attributes are violated" and "whether the system successfully tolerates faults".

[0097] 2. Generate a safety compliance report: For scenarios where all safety attributes are not violated, the system automatically generates safety compliance evidence, clearly recording under what fault conditions the system still meets its safety objectives. This report can directly support the System Security Assessment (SSA) process.

[0098] 3. Locating Design Flaws and Providing Counterexamples: For fault scenarios that lead to violations of safety attributes, the system generates a detailed counterexample analysis report. This report not only points out the violations but also, in conjunction with simulation data, fully depicts the fault propagation path and accurately locates the weak points in the fault-tolerant design, providing clear input for design iteration.

[0099] Subsequently, integrity verification is performed to check if all mandatory fields defined in the ICD are assigned; for fields referencing external standards or files, verify if the referenced files exist and version numbers match; topological analysis is performed on the inter-interfaces dependencies to ensure no missing links.

[0100] Step 4, Report generation and archiving 4.1 Aggregation of results and report generation Aggregation of verification results, structured report generation, including: metadata: verification date, ICD baseline version involved, person or system ID performing.

[0101] Results aggregation: clear list of each rule item execution results (pass / fail / manual review required). Problem details: for each "fail" item, provide precise problem location information (file name, interface name, attribute path, error description) to facilitate engineers to quickly fix. The generated report will be output in both PDF and machine-readable XML formats.

[0102] 4.2 Report archiving Archive the generated reports in both formats in the data storage module, supporting historical comparison and traceability.

[0103] As shown in Figure 5 Example 1: The flight control system receives the pitch angle signal sent by the inertial navigation system through ARINC 429.

[0104] Scenario: Verify that the inertial navigation device 1 (INS1) sends the interface of Label 311 (pitch angle signal) to the P3 connector Pin 22 and Pin 23 of the main flight control computer (FCC) through the ARINC 429 bus at the Pin 14 and Pin 15 of the J1 connector.

[0105] ICD general verification 1.1 Data acquisition and classification step 1.1.1 ICD file extraction: the system retrieves and extracts the following approved ICD files from the PDM / CMDB system according to the project code Project-X and the baseline version BL001: INS1_EICD_RevC.xml (defines the electrical characteristics of the J1 connector and pins); INS1_EoICD_RevB.xml (defines 429 label words and parameters); FCC_EICD_RevD.xml (defines the electrical characteristics of the P3 connector and pins); FCC_EoICD_RevC.xml (defines the reception of 429 parameters); FCC_HW_SW_ICD_RevA.xml (defines the internal 429 board card register mapping of FCC).

[0106] 1.1.2 Format recognition and conversion: The above XML file is parsed and converted into a system-internal uniform semantic data model based on Airborne System Modeling Language (ASML). Each interface parameter is mapped to an object property, e.g., ARINC 429 Label 311 is represented as an A429Word object with properties including Label=311, UpdatePeriod=50Hz, EncodingFormat=BNR, etc. A connector pin is represented as an ElectricalPort object with properties including Voltage=28V, Impedance=75Ω, etc.

[0107] 1.1.3 Property classification: Atomic properties: Voltage=28V, Impedance=75Ω, Label=311, UpdateRate=50Hz, Resolution=0.1 deg / bit, DataFormat=BNR, Range=-90 to 90 deg, RegisterAddress=0x8001F040.

[0108] Textual properties: SignalDescription="Pitch angle, angle between fuselage longitudinal axis and horizontal plane" Remark="Must be valid within 3 seconds after power-up".

[0109] 1.2 Strategy determination steps 1.2.1 Semantic modeling and Homogeneous Signal Group (HSG) identification: The system automatically parses all ICDs and constructs a multi-domain semantic model. Since this example only involves ARINC 429 protocol, no cross-protocol HSG is identified, but the system still establishes the association between signals and physical devices: traces Label 311 signal to source device INS1 and destination device FCC. Associates INS1 and FCC in the vibration environment level (DO-160 Sect 8 category) in MICD and EMC protection properties in EICD.

[0110] 1.2.2 Multi-domain static consistency rule set generation: The system automatically generates and applies the following rules based on the semantic model: Electrical characteristic consistency: Verify that the electrical characteristics of INS1 output (28V ±10%, 75Ω) are compatible with FCC input requirements (18-31V, 70-80Ω).

[0111] Physical-to-logical integrity: Vibration-induced data integrity rule: Check if the vibration environment levels of INS1 and FCC meet the DAL B requirement (this example assumes that the pitch angle signal is DAL B). Thermal drift-data validity coupling rule: Calculate the potential drift of INS1 operating temperature range on signal resolution (0.1 deg / bit) to ensure that the drift is less than the LSB.

[0112] Function-to-physical resource allocation: Verify if the power budget of FCC supports receiving and processing Label 311 signals.

[0113] 1.2.3 Formal behavioral verification plan generation: For Label 311 signals targeting DAL B, the system automatically generates formal verification tasks: create an abstract state machine model capturing state transitions (e.g., normal operation, timeout, fault) sent by INS1 and received by FCC.

[0114] Instantiate timing logic properties templates, e.g.: Bounded responsiveness: G (INS1_Update → F≤T_maxFCC_Update), where T_max is calculated as 10ms based on network latency. State precedence: G (FCC_Status =Invalid → (INS1_Status ≠ Normal U FCC_Status = Valid)).

[0115] 1.2.4 Verification plan output: The system generates a structured verification plan specifying: execution order: static rule checks first, then formal verification, and finally joint simulation. Task types: automated static checks, formal verification, text properties requiring human review.

[0116] 1.3 Comprehensive verification steps 1.3.1 Perform formal verification: The system invokes a model checker (e.g., NuSMV) to exhaustively verify the state machine model and timing properties of Label 311.

[0117] 1.3.2 Perform multi-physical-field joint simulation: The system configures a joint simulation environment coupling structural dynamics models (vibration), thermal models, and circuit models: inject INS1 and FCC vibration environment data (DO-160 Sect 8 curves) and temperature cycling ranges. Simulation shows: at resonance frequency points, connector micro-movement causes contact resistance to increase, but signal error rate remains below the EoICD threshold (1e-9). Result: pass physical-to-logical integrity verification.

[0118] 1.3.3 Perform automated fault injection: The system simulates the following fault scenarios: INS1 power supply transient (simulates EICD fault). ARINC 429 bus packet loss (simulates EoICD fault).

[0119] Runtime verification monitors check safety properties: G (FCC_Status = Invalid → F≤5msSystem_Fallback_Active). Result: All fault scenarios trigger the fault-tolerant mechanism, and the safety property is not violated.

[0120] 1.3.4 Manual review: Generate a structured checklist to prompt manual review of the textual property "Angle between fuselage longitudinal axis and horizontal plane" description for accuracy.

[0121] 2. EICD verification 2.1: EICD data acquisition 2.1.1: Extract EICD files: Extract INS1_EICD_RevC.xml and FCC_EICD_RevD.xml from the configuration library. 2.1.2: Parse electrical interface properties: Extract pin functions (TX+ / RX+), voltage, impedance, insulation resistance, etc. for J1-14 and P3-22. 2.1.3: Convert to standard model: Convert data to a standard electrical model with connector-pin topology relationships based on electrical standard MIL-DTL-38999.

[0122] 2.2: EICD baseline version internal verification 2.2.1: Build circuit topology network: Establish the connection relationship of INS1:J1-14 → FCC:P3-22 in the semantic model and associate vibration and EMC properties. 2.2.2: Electrical consistency verification: Perform hierarchical connectivity checks and apply multi-domain rules: Verify pin function matching (TX+ to RX+). Check if EMC protection measures (shielding, grounding) meet DAL B requirements. Result: Pass.

[0123] 2.3: EICD configuration version matching verification 2.3.1: Retrieve baseline standard: The baseline EICD version for this interface pair should be INS1_EICD_RevB and FCC_EICD_RevC from the baseline library. 2.3.2: Obtain actual version information: Identify that the current actual versions are RevC and RevD. 2.3.3: Perform comparison: Perform property-level comparison and find that the version change only involves adding notes on the FCC side, with no changes to electrical parameters. 2.3.4: Compatibility matrix check: Query the compatibility matrix, [RevB, RevC] and [RevC, RevD] are both allowed combinations. Decision: Version matching.

[0124] 2.4: Generate EICD verification strategy and tasks (Case A); Generate verification tasks: The system generates an integrated task plan including formal verification and joint simulation based on the DAL B level.

[0125] 3. EoICD verification 3.1: EoICD data acquisition 3.1.1: Extract EoICD files Extract INS1_EoICD_RevB.xml and FCC_EoICD_RevC.xml from the configuration repository. 3.1.2: Parse data interface attributes: Extract the name (PITCH_ANGLE), resolution (0.1), unit (deg), range (-90, 90), etc. of Label 311. 3.1.3: Convert to standard model: Data is converted to the unified message signal model.

[0126] 3.2: EoICD baseline version internal verification Data consistency verification: Perform semantic conflict detection, verify both units are deg, and both resolutions are 0.1. Apply multi-domain rules: Semantic conflict detection: Verify unit, resolution consistency. Timing compliance verification: Use formal methods to verify end-to-end delay ≤ 5ms. Result: Pass.

[0127] 3.3: EoICD configuration version matching verification 3.3.1: Retrieve baseline standard: The baseline EoICD versions should be INS1_EoICD_RevA and FCC_EoICD_RevB. 3.3.2: Acquire and compare actual versions: The actual versions are RevB and RevC. Comparison finds that the FCC end range has changed from ±180deg to ±90deg. 3.3.3: Compatibility matrix check: The matrix does not define combinations [RevA, RevB] and [RevB, RevC]. Initiate gray-scale assessment: Assessment considers the range reduction as a compatibility change with low risk. Decision: Version matching, attention advised.

[0128] 3.4: Generate EoICD verification strategy and tasks (Case A) Generate verification tasks: The system generates formal verification tasks to ensure signal state mapping and timing properties meet requirements.

[0129] 4. In-device software and hardware interface verification 4.1: In-device software and hardware ICD configuration version matching verification 4.1.1: Acquire version information: Identify that the FCC's 429 board card hardware configuration item version is HW_Rev2.1, which corresponds to the device driver software configuration item version SW_Rev1.3. 4.1.2: Retrieve and compare baseline: The baseline versions should be [HW_Rev2.0, SW_Rev1.2]. The actual versions [HW_Rev2.1, SW_Rev1.3] do not match the baseline. Trigger step 6.2. 4.2: Inconsistency identification and associated configuration item decision 4.2.1: Parse change report: Obtain change report from configuration library, parse change item as interrupt number (changed from 0x15 to 0x16). 4.2.2: Correlation configuration item lookup: Search in FCC software architecture with interrupt number = 0x16 as key, find that only 429 driver configuration item uses this interrupt. 4.2.3: Output final correlation list: Correlation list is empty (because the change does not affect other software configuration items).

[0130] 4.3: Generate software and hardware ICD verification strategy and tasks 4.3.1: Decision branch: Although version mismatch, "extra correlation configuration item list" is empty, so the decision is case A (perform complete verification). 4.3.2: Generate verification tasks (case A): Register access consistency verification (automated). Formal verification: Check if interrupt handling logic meets timing requirements (e.g. G (Interrupt_Trigger -> F <= 1ms ISR_Execution)). Fault injection: Simulate interrupt loss scenarios and verify system recovery mechanisms.

[0131] 5. Report generation step Summarize all verification results and generate a structured report: Contains: Metadata: Verification date, ICD baseline version, formal verification tool version.

[0132] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited to this. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A verification method for an airborne system ICD, characterized in that, include: Retrieve one or more ICD data to be verified from the configuration management database or data source and perform standardization processing, classifying ICD parameter attributes into atomic attributes and textual attributes; Semantic modeling is performed on the standardized ICD data to construct a digital twin model of the system interface architecture; based on a predefined homologous mapping dictionary, signals representing the same physical parameter are identified and associated to form homologous signal groups; based on the digital twin model, multi-domain context association and risk identification are performed on each signal in the homologous signal group to generate a multi-dimensional static verification rule set and a formal behavior verification plan for high-security-level interfaces; Based on the hierarchical strategy of development assurance level, a set of verification rules is selected for each of the same source signal groups, and a structured verification plan is automatically generated; According to the verification plan, comprehensive verification is performed on data with atomic attributes, including static consistency, integrity and correctness verification, multiphysics co-simulation, and automated fault injection and security verification; for data with textual attributes, a structured checklist is generated. Summarize all verification results, generate a structured report, and output it for archiving.

2. The verification method for airborne system ICD according to claim 1, characterized in that, Acquire one or more ICD data points to be verified and perform standardization processing, including: Retrieve and extract ICD raw data that is in an approved or frozen state based on the project code and baseline version number; convert ICD raw data of different formats into a predetermined standard format and remove duplicate records; Unify the attribute unit for numerical parameters; classify ICD parameter attributes into atomic attributes that can be directly parsed and compared, and textual attributes described in natural language.

3. The verification method for airborne system ICD according to claim 1, characterized in that, Based on the digital twin model, multi-domain context association and risk identification are performed on each signal in the homologous signal group, including: A cross-domain tracing link from logical signal to physical implementation environment is established for each of the aforementioned homogeneous signal groups; causal reasoning is performed based on the engineering failure knowledge base, potential risk causal chains are dynamically identified and context-dependent temporary verification rules are dynamically synthesized, and finally a multi-dimensional static verification rule set including at least logical data consistency, physical environment adaptability and resource supply and demand compliance is generated.

4. The verification method for an airborne system ICD according to claim 1, characterized in that, The multi-dimensional static verification rule set includes: A set of rules for cross-protocol conversion and equivalence verification is used to verify the equivalence and consistency of periodicity, rate, resolution, data range, state semantics, timing characteristics, and units of signals originating from different bus protocols. A set of physical-to-logical integrity verification rules is used to establish a formal relationship between the physical working environment and logical data integrity, and to verify the impact of vibration, electromagnetic compatibility (EMC), and thermal drift on data integrity. A set of rules for verifying the allocation of resources from function to physical resources, used to verify whether physical resources are sufficient to support the functional requirements allocated to the corresponding hardware.

5. The verification method for an airborne system ICD according to claim 1, characterized in that, The formal behavior verification plan for high-security-level interfaces includes: For the same source signal group identified as being of development assurance level A or development assurance level B, an abstract finite state machine model is automatically generated. Based on the built-in attribute template library, key cross-protocol behavioral requirements are encoded using temporal logic, and temporal logic attributes that need to be proven are automatically generated. The model checker is invoked to exhaustively verify the state machine model and the temporal logic properties, and a counterexample is generated when the properties are not satisfied.

6. The verification method for an airborne system ICD according to claim 1, characterized in that, According to the hierarchical strategy for development assurance levels, a set of verification rules is selected for each of the homologous signal groups, including: Assign a corresponding development assurance level to each of the aforementioned homogeneous signal groups; Based on the corresponding development assurance level, and according to the configurable strategy, different sets of verification rules with varying degrees of rigor are selected and applied. Specifically, all static verification rule sets and formal behavioral verifications are enforced for the interfaces of development assurance level A and development assurance level B, while the static verification rule sets of the corresponding settings are enforced for the interfaces of development assurance level C and development assurance level D, respectively.

7. The verification method for an airborne system ICD according to claim 1, characterized in that, The comprehensive verification execution steps include: Load the formal model and instantiated property specifications, perform model checking and state space analysis, analyze counterexamples and locate design defects; Configure the co-simulation environment and inject physical domain parameters, perform coupled simulation and physical effect transfer, analyze simulation results and generate design feedback; Define the fault injection set and security monitoring specifications, perform fault injection and runtime verification, analyze the results and generate security assessment evidence.

8. A verification system for an airborne system ICD implementing the method as described in any one of claims 1-7, characterized in that, include: The strategy formulation module is used to define the project's validation baseline, ICD hierarchy model, validation rules, and error levels. The data processing module is used to connect to the data source, call the adapter to parse raw ICD data in different formats, convert it into a standardized internal data model, and perform attribute classification and relationship establishment. The interface verification module is used to receive verification instructions, schedule and execute verification algorithms according to the verification strategy, and process items that require manual review. The report generation module is used to obtain verification results and generate structured reports; The data storage module is used to persistently store configuration information, standardized ICD data models, verification results, and generated reports.

9. The verification system for airborne system ICD according to claim 8, characterized in that, The data processing module includes multiple adapters for parsing ICD data in ASML, XML, CSV, PDF, and DOCX formats. The data processing module also automatically marks ICD parameter attributes as atomic attributes or textual attributes, and uses predefined rules to initially establish the association between interfaces.

10. The verification system for airborne system ICD according to claim 8, characterized in that, The verification algorithms scheduled and executed by the interface verification module include numerical comparison, logical judgment, string matching, and topological relationship checking. For textual attribute data, the interface verification module organizes the data into a structured checklist containing the path location of the parameters to be reviewed, the associated context, and historical review records.

Images