Airborne system ICD definition and confirmation method and system

Abstract

The invention provides an airborne system ICD definition and confirmation method and system, and relates to the technical field of airborne systems. The method comprises the steps of defining and confirming a functional interface, defining and confirming static information of a mechanical interface, defining and confirming dynamic information of the mechanical interface, defining and confirming an electrical interface, defining and confirming attributes of an electronic interface and defining and confirming software and hardware interfaces in equipment. Through function parameter ternary classification, equipment multi-dimensional classification, forward quantization derivation, dynamic protocol type selection and equipment internal interface definition, full-level, full-factor and full-life-cycle ICD closed-loop management is realized. According to the method, the problems of interface level splitting, experience dependence, black box difficulty, low management efficiency and the like in the prior art are effectively solved, and the accuracy, the consistency and the maintainability of airborne system interface development are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of airborne system, and particularly relates to an airborne system ICD definition and confirmation method and system. BACKGROUND

[0002] Interface Control Document (ICD) is a basic technical specification in the integration of avionics system, which defines and restricts the electrical characteristics, data protocol, functional logic and operation boundary of the interface between subsystems, devices or across systems through standardized format, ensuring the interoperability and communication reliability between avionics systems. In the research and development of complex airborne systems (such as avionics and flight control systems), clear, accurate, consistent and verifiable interfaces are crucial to ensure system safety, reliability, interoperability and improve development efficiency.

[0003] However, the existing technology has significant limitations and systematic pain points in the definition, management, confirmation and verification methods of the interface, which seriously restricts the development quality and integration efficiency of modern complex airborne systems, specifically in the following aspects: 1. The interface definition lacks a unified parameter system and traceability mechanism, resulting in hierarchical fragmentation and information fault; 2. The device interface definition is extensive, lacks multi-dimensional classification and dedicated attribute templates, and relies on manual experience; 3. ICD management highly depends on documents and manual work, with inefficient processes and difficulty in ensuring consistency; 4. The confirmation and verification method is highly subjective, lacking structured and automated means; 5. The internal interface of the device is ignored, becoming a "black box" for system integration and verification.

[0004] These pain points collectively result in: interface problems becoming the main obstacle to system integration, with high rectification costs; the quality and reliability of system interfaces overly relying on the individual ability and experience of designers, making it difficult to guarantee and replicate; severely restricting the development quality, integration efficiency and long-term maintainability of airborne system interfaces. Although the existing technology (CN109063362 A and CN112784434 A) proposes related management systems and methods, there are still problems such as lack of device classification standards, imperfect parameter derivation process, not covering end-to-end link analysis and internal device interfaces, and insufficient dynamic verification capabilities. SUMMARY

[0005] Therefore, the embodiment of the present application provides an airborne system ICD definition and confirmation method and system, aiming to solve the problems of hierarchical definition fragmentation caused by the lack of unified parameter system and traceability mechanism, insufficient physical implementability caused by rough equipment interface definition, low efficiency and consistency caused by the high dependence of management process on manual work and documents, and integrated "black box" problem caused by ignoring internal equipment interface, and the like. The ultimate goal of the present application is to build an airborne system ICD closed-loop definition and confirmation capability covering all levels, all elements and the whole life cycle, to improve the accuracy, consistency, verifiability and maintainability of interface development from the root, to completely avoid integration risks, to ensure system safety, and to significantly improve the research and development efficiency.

[0006] The embodiment of the present application provides the following technical solutions: an airborne system ICD definition and confirmation method, comprising: defining and confirming the functional interface, comprising: identifying functional parameters according to a system function list and requirements, classifying the functional parameters into three categories according to energy, control and power; assigning a globally unique identifier to each functional parameter, and defining a corresponding attribute set for each type of functional parameter; confirming the integrity, unique identification and attribute compliance of the functional interface based on preset confirmation rules; defining and confirming the static information of the mechanical interface, comprising: dividing the airborne system entity equipment into multiple categories according to the mechanical interface function and installation characteristics; designing a dedicated mechanical static attribute template for each category of equipment; calculating the mechanical static parameters based on the energy class parameters in the upstream functional interface and system requirements; confirming the assembly feasibility, tolerance compliance and interface matching of the mechanical interface static information based on the preset confirmation rules; defining and confirming the dynamic information of the mechanical interface, comprising: dividing the airborne system equipment into multiple categories according to the dynamic behavior characteristics; defining a dedicated motion envelope parameter for each category of equipment; generating adaptive dynamic parameters of the equipment under all working conditions based on working condition parameterization expression and response surface fitting technology; confirming the dynamic characteristics, motion trajectory accuracy and fault tolerance capability of the dynamic information of the mechanical interface based on the preset confirmation rules; defining and confirming the electrical interface, comprising: dividing the airborne system equipment into multiple categories according to the electrical interface characteristics; designing a dedicated electrical attribute template for each category of equipment; performing linkage optimization on electrical, thermal and electromagnetic compatibility parameters through inter-domain sensitivity transfer matrix based on the power class parameters in the upstream functional interface and system requirements; confirming the parameter correctness, electromagnetic compatibility compliance and power supply matching of the electrical interface based on the preset confirmation rules; The electronic interface protocol selection process includes: real-time acquisition of functional conditions, environmental conditions, and equipment health constraints via airborne bus; construction of a multi-objective weighted optimization model, dynamic allocation of weights based on flight phases, scoring of candidate protocols, and outputting a combination of main and redundant protocols; and verification of the selection results in three dimensions of electromagnetic compatibility, topology, and timing, with the introduction of a digital twin model for self-verification. The electronic interface is defined and validated, including: constructing a dynamic adaptation matrix for flight phase and protocol attributes so that attribute parameters can be dynamically adjusted according to operating conditions; realizing automatic inheritance and conflict resolution of attributes from functional interfaces to electronic interfaces through a cross-level attribute mapping engine; designing fault tolerance enhancement mechanisms for key attributes; and validating and iteratively optimizing attributes through an automated toolchain that includes simulation, hardware-in-the-loop testing, and compliance checks. Define and validate the hardware and software interfaces within the device, including: defining device configuration items, functional interface allocation, hardware-hardware interfaces, software-hardware interfaces, software-software interfaces, and complex electronic interfaces within the device or hardware application; and validating the integrity, logical consistency, physical implementability, and traceability with external interfaces of the hardware and software interfaces within the device based on preset validation rules.

[0007] This application also provides an airborne system ICD definition and verification system for implementing the above method, including: The input module is used to receive and parse the system function list, aircraft-level and system-level requirements, as the top-level input for the ICD definition; The database module is used to store and manage general and specific attribute parameters of various devices; Support modules are used to provide support for N-nature analysis, toolchain integration, system architecture design guidance, and the invocation and compliance checks of standard and specification clauses; The processing module is used to define the functional interface, mechanical interface, electrical interface, electronic interface and internal hardware and software interface of the device in sequence according to the output of the input module, and realize cross-level parameter association and attribute inheritance; the processing module also includes an iterative design unit, which is used to automatically trace and trigger the iterative optimization of the corresponding upper-level interface when the downstream interface definition is incompatible with the upstream interface definition; The output module is used to generate and export various interface control document files.

[0008] Compared with the prior art, the beneficial effects that the above-mentioned at least one technical solution adopted in the embodiments of this specification can achieve include at least the following: By constructing a structured ICD management system covering all levels of "function-mechanical-electrical-electronic-interface", all elements of "static-dynamic-protocol-load", and the entire process of "definition-derivation-verification-iteration", the embodiments of this invention achieve a systematic breakthrough in addressing the pain points of the prior art. The core beneficial effects are as follows: 1. Break down barriers between cross-level interfaces to eliminate the risk of information gaps and inconsistencies.

[0009] This invention relies on the defined ternary classification (P / C / E) of FICD functional parameters and a globally unique identification system (such as "FP-XXXX-T / RP / C / E-XXX" encoding), combined with the hierarchical definition of MICD (Mechanical Static / Dynamic), EICD (Electrical), EoICD (Electronic Protocol), and IICD (Inter-device Interface), to achieve automatic association and traceability of "FICD parameters → downstream interface attributes" (e.g., FICD's P-class energy parameters are directly inherited to MICD media characteristic attributes, and C-class control parameters are mapped to EoICD protocol data precision attributes). Simultaneously, the closed-loop iteration mechanism of the processing module can automatically trace and trigger upstream interface (such as MICD device power attributes) optimization when conflicts are detected at downstream interfaces (such as EICD load allocation), completely solving the problems of "hierarchical fragmentation and parameter asynchrony" in existing technologies, and avoiding the risk of interface inconsistency from the source.

[0010] 2. Replace reliance on human experience, improving the accuracy and efficiency of ICD compilation.

[0011] This invention, through its pioneering "demand-specification-numerical" positive vectorization derivation process (e.g., MICD static parameters are calculated based on the physical field sensitivity coefficient matrix, and EICD electrical parameters are optimized based on the inter-domain sensitivity transfer matrix), transforms traditional "experience-based compensation" into a calculable and traceable mathematical derivation. Parameter values ​​(e.g., positioning pin position accuracy ±0.1075mm, electrical surge current 18A) are all linked to upstream requirements and industry standards (ASME Y14.5, DO-160G), avoiding errors from manual configuration. Simultaneously, the database module uniformly stores device-specific / exclusive attribute templates (e.g., exclusive attributes for MICD dynamic four-category devices and EICD eight-category devices), reducing repetitive data entry. The automated decomposition function of the processing module (FICD→MICD→EICD→EoICD) significantly reduces manual intervention. Compared to existing document-based management models, ICD compilation efficiency is improved by over 40%, and the parameter error rate is reduced to below 0.1%.

[0012] 3. Solve the "black box" problem of equipment and improve system integration and maintenance capabilities.

[0013] This invention is the first to incorporate the internal hardware and software interfaces (IICD) of a device into the unified management of the ICD, clearly defining the constraints of hardware-to-hardware interfaces (SPI / PCIe bus parameters), software-to-hardware interfaces (API function definitions, hardware BIT access rules), software-to-software interfaces (shared memory / ARINC 653 port communication protocol), and complex electronic interfaces (FPGA register mapping), filling the gap in existing technologies for managing internal device interfaces. This transforms the device from a "black box" into a "transparent module," enabling rapid fault location during integration testing (such as FPGA logic errors or driver call failures). Later upgrades do not require reconstructing the entire device interface; only internal local interface parameters need adjustment. This reduces system maintenance cycles by 30% and maintenance costs by 25%.

[0014] 4. Establish a closed-loop management system for the entire lifecycle to adapt to the needs of complex airborne systems.

[0015] The "input-database-support-processing-output" system architecture defined in this invention achieves full lifecycle coverage of ICD, from top-level requirement input (system function list), hierarchical definition (FICD to IICD), automated verification (multi-toolchain), iterative optimization (closed-loop feedback), to final document output (various ICD reports). The support module provides N-type analysis and standard specification invocation (such as MIL-STD-704F) capabilities, adapting to the interface requirements of different airborne system configurations (such as civil airliners and military aircraft). The processing module's dynamic adaptation function (such as adjusting attributes of the EoICD protocol according to flight phases) meets the rapid iteration requirements of aviation equipment, providing a standardized and replicable solution for interface management of modern complex airborne systems (such as IMA integrated modular avionics). Attached Figure Description

[0016] 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.

[0017] Figure 1 This is a flowchart illustrating the definition and verification process of FICD according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the definition of requirements, specifications, and numerical values ​​in an embodiment of the present invention. Figure 3 This is a diagram showing the distribution and verification of electrical loads according to an embodiment of the present invention; Figure 4 This is a definition and verification system diagram of the airborne system interface control document (ICD) according to an embodiment of the present invention. Detailed Implementation

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

[0019] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The abbreviations and key terms used in this invention are defined as follows: ICD (Interface Control Document); FICD (Functional Interface Control Document); MICD (Mechanical Interface Control Document); EICD (Electrical Interface Control Document); EoICD (Electronic Interface Control Document); FMS (Flight Management System); FCC (Flight Communication Center); IMA (Integrated Modular Avionics); AFDX (Avionics Full-Duplex Switched Ethernet); EMI (Electro-Magnetic Interference); APU (Auxiliary Power Unit); SSPC (Solid State Power Controller); TRU (Transformer Rectifier Unit); EMC (Electro-Magnetic Compatibility); TVS (Transient Voltage Suppressor); MOV Metal Oxide Varistor; LRU (Line Replaceable Unit); EICAS (Engine Indication and Crew Alerting System); GPIO (General-Purpose Input / Output); API (Application Programming Interface); DS (Data Structure); DP / RP (Delivered Parameter / Received Parameter).

[0021] like Figures 1-4As shown, this invention provides an ICD definition and verification method, particularly an ICD definition and verification method for airborne systems, which specifically includes eight steps. The core content and key requirements of each step are as follows: 1. Definition and Validation of FICD: Based on the function list and aircraft-level and system-level requirements, sort out the function list and performance requirements (update cycle, accuracy, failure mode, etc.), and identify the functional parameters exchanged across systems / equipment; classify the functional parameters into three categories: energy (P), control (C), and power (E), define a minimum set of attributes (mandatory) and scalable attributes (optional) for each type of parameter, and design a globally unique identifier in the format of "FP-ATA code-transmit / receive type-parameter category-serial number" (e.g., FP-2750-TC-007); during the validation phase, verify the coverage of P / C / E class parameters (100% coverage of critical function DAL A / B level parameters), ID uniqueness (0% duplication rate), and the matching of attributes with requirements (100% matching rate). Ensure the integrity and correctness of FICD through the "function + functional parameter" traceability method.

[0022] 2. Definition and Confirmation of MICD Static Information: Based on the energy (P) functional parameters and attributes in FICD, and combined with system requirements, airborne system physical equipment is categorized into five types according to mechanical interface functions and installation characteristics: avionics computing equipment, electromechanical actuation equipment, sensor equipment, network communication equipment, and other equipment (pipelines / cables). A dedicated attribute template is designed for each type of equipment (e.g., avionics computing equipment requires defining a cabinet assembly relationship matrix, and electromechanical actuation equipment requires defining flange flatness). A positive vectorization derivation process of "requirements-specifications-numerical values" is adopted, using the physical field sensitivity coefficient matrix (…). The mechanical parameters are mathematically calculated (e.g., the position of the locating pin is ±0.1075mm). During the confirmation phase, the assembly feasibility (interference rate 0), tolerance compliance (cumulative error of key interfaces ≤0.05mm) and interface compatibility (100% accessory compatibility) need to be verified.

[0023] 3. Definition and Validation of MICD Dynamic Information: For equipment with moving parts or dynamic sensitivity, it is classified into four types according to dynamic behavior characteristics: vibration-sensitive, motion-execution, environment-coupled, and maintainable activity-based. Specific motion envelope parameters are defined for each type of equipment (e.g., vibration-sensitive equipment requires a resonant frequency avoidance zone, and motion-execution equipment requires a motion trajectory equation). Based on the "parametric expression of operating conditions + response surface fitting" technology, the operating condition is deconstructed into three dimensions: load intensity, duration, and number of cycles. Full-condition adaptive parameters are generated through multi-body-finite element co-simulation and a quadratic response surface model. During the validation phase, dynamic characteristics (vibration / shock conforms to DO-160G standards), motion trajectory accuracy (DAL A-level equipment trajectory deviation ≤ ±0.1°), and fault tolerance (100% BIT pass rate after impact) must be verified.

[0024] 4. Definition and Validation of EICD: Based on the power (E) functional parameters and attributes in FICD, airborne electrical equipment is categorized into eight types according to electrical characteristics: high-power power, avionics digital bus, analog sensing / actuation, radio frequency communication, discrete quantity / relay, electromechanical actuation / motor, recording / media, and backup / emergency. Dedicated electrical attributes are designed for each type of equipment (e.g., high-power power requires defining bus transient response time, and avionics digital bus requires defining impedance matching). The "inter-domain sensitivity transfer matrix" is used to achieve coordinated optimization of electrical, thermal, and EMC parameters, avoiding single-domain compliance but multi-domain failure. During the validation phase, the correctness of electrical parameters (deviation between measured and defined values ​​≤5%, key parameters ≤2%), EMC compliance (compliant with DO-160G §20), and power supply matching (allowable cable current carrying capacity ≥ 1.2 times the equipment's rated current) must be verified.

[0025] 5. EICD Electrical Load Allocation and Verification: Loads are classified using a three-dimensional labeling system of "functional attributes + electrical characteristics + safety level" (e.g., flight critical, avionics support, DO-254 A~D levels); following the principle of "safety baseline priority - dynamic load following - redundant hot standby support," a load priority calculation model is used (…). ), power capacity allocation formula ( The quantitative allocation is achieved using the cable selection formula (Sj=Inom,j×Lj / (K×ΔUmax)); multi-dimensional verification (power balance, voltage stability, heat dissipation, fault tolerance) is carried out, and priority reordering or redundancy coefficient adjustment is triggered when the verification fails, forming an iterative optimization closed loop.

[0026] 6. EoICD Definition and Protocol Selection: Inheriting the functional parameters and attributes of the control class (C) in FICD, it collects three types of constraints—functional operating conditions, environmental operating conditions, and equipment health—in real time via the airborne bus; constructs a "multi-objective weighted optimization model," dynamically allocating weights based on the flight phase (e.g., a 70% weight for "real-time performance + safety" during the taxiing phase), scoring candidate protocols such as ARINC429 / 664 / 825, TSN, and 1553B, and outputting a "main protocol + redundant protocol" combination; conducts three-dimensional compatibility verification of "EMC - topology - timing," avoiding conflicts through CST simulation, architecture diagram checks, and Matlab / Simulink timing modeling; introduces a digital twin model to reproduce operating conditions and inject faults (such as port disconnection) for self-verification; if the pass rate is ≥95%, the selection is frozen.

[0027] 7. EoICD Attribute Definition and Validation: Construct a dynamic adaptation matrix for "Flight Phase - Protocol Attributes," adding dynamic attribute groups for real-time performance (update cycle, latency threshold), fault tolerance (redundancy switching time, bit error rate threshold), and energy consumption (bus wake-up current), which are automatically adjusted according to operating conditions (e.g., ARINC429 update cycle of 10ms during taxiing and 20ms during cruise). Utilize a "cross-level attribute mapping engine" and knowledge graph to achieve automatic attribute inheritance from FICD to EoICD, resolving mapping conflicts through priority rules (DAL A-level mandatory protocol adjustment) and compromise rules (DAL C-level optimized parameters). Design fault-tolerant enhancement attributes (dual check bits, dual redundant channels), and build an automated toolchain for "simulation - HIL testing - compliance" to verify attributes, forming an iterative closed loop of "test data - attribute optimization" (deviation ≤ 5%).

[0028] 8. Internal Hardware and Software Interface Definitions: Taking the device LRU / application HA as the object, six types of interface definitions are covered: First, device configuration item description (hardware list, mechanical assembly drawing, software architecture diagram); second, internal functional interface allocation (function-hardware / software mapping matrix); third, hardware-hardware interface (electrical parameters, protocol standards, such as SPI impedance 100Ω±10%); fourth, software-hardware interface (API functions, hardware BIT access rules); fifth, software-software interface (shared memory, ARINC 653 port communication); sixth, complex electronic interface (FPGA register mapping, SPI frame format). During the verification phase, the interface integrity (100% coverage of hardware and software configuration item association), logical consistency (software-software interface packet loss rate ≤0.1%), physical feasibility (electrical parameter deviation ≤5%), and external traceability (100% coverage of EICD / EoICD mapping) must be verified to meet the DO-254 (hardware) and DO-178C (software) airworthiness requirements.

[0029] Finally, a definition and verification system for the airborne system ICD is established, comprising a program for all the above steps, including an input module, a database module, a support module, a processing module, and an output module: Input module: Used to receive and parse system function list, aircraft-level and system-level requirements, as the top-level input for ICD definition; Database module: Used to store and manage the general attribute parameters and specific attribute parameters of various devices; Support modules: These provide support for N-type analysis, toolchain integration, system architecture design guidance, and the invocation and compliance checks of standard and specification clauses.

[0030] Processing module: Based on the input, the FICD is first defined, and then the FICD is decomposed layer by layer to define the MICD, EICD, and EoICD in sequence, finally completing the definition of the device's internal hardware and software interface (IICD) and realizing cross-level parameter association and attribute inheritance; it also includes iterative design. When the downstream interface definition (such as EICD or EoICD) is found to be incompatible or conflicting with the upstream interface definition, it can automatically trace back and trigger the iterative optimization of the corresponding upper-level interface (such as MICD or EICD), forming a closed-loop forward design process; Output module: Used to generate and export various ICD files; In practice, the specific steps of this embodiment are as follows: 1. Step 1 - Definition and Confirmation of FICD 1.1 FICD Definition Method The main task is functional requirements capture. Based on aircraft-level and system requirements, a list of functions and performance requirements (update cycle, accuracy, failure modes, etc.) is compiled. Functional parameters that need to be exchanged between different systems / equipment (such as airspeed, altitude, engine speed, flap position, alarm status, and control commands) are identified, and the functional parameters and attribute parameters of the functional interfaces are defined. Example: The FMS needs to send a roll command to the FCC every 50 ms, with an accuracy of ±0.1°.

[0031] The defined functional parameters are classified according to their functional type, specifically into energy, control, and power. Energy type refers to parameters such as hydraulic system supplying hydraulic pressure, fuel system supplying fuel, and environmental management system providing bleed air, denoted as P; control type refers to parameters such as avionics transceiver information parameters, flight control transceiver attitude and airspeed parameters, denoted as C; power type refers to parameters such as power supply system supplying power, denoted as E.

[0032] Based on the functional parameter type, a globally unique ID is defined within the system. Different attribute parameters are defined for different types of functional parameters. Each type of functional parameter attribute includes a minimum set of attributes (the attributes that must be defined) and extensible attributes (the attributes that can be selected).

[0033] 1.2 FICD Confirmation Rules The objectives to be verified are: completeness of FICD function parameters (no missing P / C / E class parameters), uniqueness of identifiers (no duplicate global IDs), and compliance of attributes (meeting functional requirements and aviation regulations).

[0034] Confirmation criteria: Coverage of P / C / E class parameters is ≥99%, and coverage of key function (DAL A / B level) parameters is 100%; ID duplication rate is 0, and the encoding format conforms to the rule "FP-XXXX-T / RP / C / E-XXX"; attribute matching rate with requirements is 100%, and no attribute values ​​deviate from requirements or standards.

[0035] 2. Step 2 - Definition and Confirmation Method of MICD Static Information: 2.1 MICD Static Information Definition Method Aircraft avionics systems can be classified into five categories based on their mechanical interface functions and installation characteristics: avionics computing equipment, electromechanical actuators, sensor equipment, network communication equipment, and other equipment (such as pipelines and cables).

[0036] For avionics computing equipment, it refers to electronic processing units that adopt modular chassis packaging and need to meet high-density rack assembly requirements, such as IMA core processing modules and remote data concentrators. Their mechanical interfaces need to define compact shell dimensions, rack rail assembly tolerances, and blind plugging positioning accuracy. For electromechanical actuators, which are devices that output power through mechanical transmission mechanisms, such as flap servo motors and fuel pumps, the interfaces must be required to specify the flatness of the flange assembly surface, the coaxiality compensation of the actuator rod, and the coordinates of the positioning pins for the load transmission path. For sensor-type devices, which refer to measurement units that rely on physical references for positioning, such as inertial navigation devices and angle-of-attack sensors, their interfaces must include a list of accessories such as probe assembly angle vectors, calibration reference hole position tolerances, and impact-resistant mounting brackets. For network communication equipment, which refers to data exchange devices that require maintaining channel isolation, such as AFDX switches and satellite data links, the interfaces need to define the fiber optic slot anti-misinstallation key positions, the assembly guide slot dimensions of hot-swappable modules, and the installation coordinates of the grounding plates.

[0037] a. Demand capture: Hierarchical deconstruction of multiple constraints; Breaking away from the traditional "single requirement for assembly precision," a two-tiered structure of "primary constraints + secondary coupling constraints" is established: Primary constraints: system-level assembly functional requirements (such as "the gap between the control surface and the wing is 0.1~0.3mm"), directly related to the core functions of the product; Secondary coupling constraints: hidden requirements are extracted through "failure mode reverse derivation" (such as "due to thermal expansion, gap deviation will cause aerodynamic noise, so the gap change must be limited to ≤0.05mm under a temperature difference of -40~85℃"), related to product reliability; Output: "Multi-field constraint hierarchy table", which clarifies the quantitative thresholds and associated weights of primary / secondary constraints (primary constraint weight 0.6, secondary constraint weight 0.4).

[0038] b. Standard Mapping: A Quantitative Coordination Mechanism for Conflicting Standards Addressing the industry pain point of "parameter inconsistencies when multiple standards are cross-referenced," we pioneered the "standard fit function": Fit S = (Number of standard-covered constraints / Total number of constraints) × 0.5 + (Standard-to-operating-condition matching degree) × 0.5; (Note: Operating condition matching degree = the overlap rate between the standard's applicable environmental parameters and the actual operating condition parameters. For example, if ASME Y14.5 has a 0% coverage of -40℃ low temperature, then its S value will decrease under low temperature operating conditions).

[0039] c. Numerical Derivation: Calculation Model for Coupling Sensitivity Coefficient Breaking away from the traditional "single simulation + empirical correction" approach, a mathematical derivation formula is established: The final static parameter P = the basic parameter P0 × Σ (physical field sensitivity coefficient K) i ×Working Condition Influence Factor F i ); where: K i The sensitivity coefficient of the i-th type of physical field (obtained through orthogonal experiments, such as the thermal field K). t =0.3, vibration field K v =0.2); F i : The operating condition influence factor of the i-th type of physical field (such as thermal field F) t =ΔT / ΔT0, where ΔT is the actual temperature difference and ΔT0 is the standard temperature difference.

[0040] d. Compliance Verification: Multi-stage Iterative Validation of Digital Twins Construct a closed-loop verification chain of "parameters-physical field-performance": input the derived parameters into the digital twin, simulate three types of extreme working conditions (room temperature assembly, -40℃ thermal deformation, and 10g impact); extract key performance indicators (such as gap change and positioning error) and compare them with the required threshold; if the requirements are not met, correct the sensitivity coefficient K in reverse. i (Through least squares iteration) until the parameters meet all operating conditions; Output: A verification report containing the "sensitivity coefficient calibration curve" to prove the traceability of the parameter derivation.

[0041] 2.2 MICD Static Information Confirmation Rules Verification Objectives: Verify the assembly feasibility (no mechanical interference), tolerance compliance (meets assembly standards), and interface compatibility (connector / fastener compatibility) of the MICD's static properties. Verification Standards: Assembly interference rate is 0%; clearance at critical interfaces (e.g., servo-bracket) is ≥0.1mm (compliant with ASME Y14.5); cumulative assembly error is ≤ standard threshold; cumulative error at critical interfaces (DAL A / B level equipment) is ≤0.05mm; 100% accessory compatibility, with no risk of installation failure due to accessory incompatibility.

[0042] 3. Step 3 - Definition and confirmation methods for MICD dynamic information: 3.1 MICD Dynamic Information Definition Method Aircraft avionics systems and equipment can be classified into four categories based on their dynamic behavior characteristics: vibration-sensitive equipment, motion-actuating equipment, environmentally coupled equipment, and maintainable mobile equipment.

[0043] a. Demand Capture: Dimensional Modeling of Operating Condition Parameters Breaking away from the traditional approach of "classifying operating conditions by flight phase", the operating condition is deconstructed into three quantifiable dimensions: load intensity (g): peak value of random vibration acceleration; duration (s): duration of the load; number of cycles (n): number of times the operating condition occurs throughout the entire life cycle.

[0044] b. Standard mapping: Standard operating condition range matching method To address the issue that "general standards are difficult to cover extreme operating conditions," the concept of "standard effective range" is proposed: each dynamic standard (such as DO-160G) corresponds to a three-dimensional effective range [g1,g2]×[t1,t2]×[n1,n2]. When the actual operating condition parameters fall outside the range, the parameter range needs to be extended through the "standard extrapolation algorithm" (such as extrapolating the 12g upper limit of DO-160G to 15g, with the extrapolation coefficient = safety margin under 12g / simulation margin under 15g).

[0045] c. Numerical Derivation: Parameter Generation of the Response Surface Model Breaking through the limitations of "single-condition simulation," a continuous functional relationship between dynamic parameters and operating conditions is established: 1. Five typical operating conditions are selected (e.g., 3g / 3600s / 30000 cycles, 5g / 1000s / 30000 cycles…15g / 10s / 30000 cycles), and the corresponding dynamic parameters are obtained through multibody-finite element co-simulation (ADAMS+ANSYS); 2. The quadratic response surface method is used to fit the function; 3. Parameters under any operating condition can be directly calculated through the function without repeated simulation.

[0046] d. Compliance Validation: Parameter Robustness Testing for Accelerated Fatigue Verification The reliability of dynamic parameters is evaluated using the "parameter robustness index": 1. Robustness index R = 1 - (parameter fluctuation / demand threshold) (e.g., if the positioning error fluctuates within ±0.05mm and the demand threshold is 0.5mm, then R = 1 - 0.05 / 0.5 = 0.9, and ≥0.8 is acceptable); 2. Test method: Apply 1.2 times the design load to the vibration table in an "accelerated fatigue test" (number of cycles = 30,000 × 1.2), monitor the parameter fluctuation, and ensure that R ≥ 0.8.

[0047] 3.2 MICD Dynamic Information Confirmation Rules Confirmation Target: Confirm that the dynamic characteristics of the MICD dynamic attributes meet the standards (vibration / shock conforms to the standard), motion trajectory accuracy (no deviation), and fault tolerance (normal function after shock / vibration); Confirmation Standard: Vibration response 100% conforms to MICD tolerance, no resonance frequency falling within the 200-300Hz avoidance zone; trajectory deviation ≤ ±0.1° (DAL Class A equipment), repeatability ≤ ±0.05mm; equipment BIT pass rate 100% after impact, no functional failure or performance degradation.

[0048] 4. Step 4 - Definition and Confirmation of EICD 4.1 EICD Definition Method Airborne system equipment can be classified into eight categories according to their electrical interface characteristics: high-power power type, avionics digital bus type, analog sensing / actuator type, radio frequency communication type, discrete quantity / relay type, electromechanical actuation / motor type, recording / media type, and backup / emergency type.

[0049] a. Requirement capture: Relationship modeling of multi-domain constraints Breaking away from the approach of "independently listing multi-domain requirements", a "constrained and associated directed graph" is established: Nodes: Electrical (I=20A), Thermal (ΔT=15K), EMC (E=54dBμV / m) requirements; Directed edges: Labeled inter-domain influence coefficients (e.g., influence coefficient of I→ΔT=0.8, that is, when I increases by 1A, ΔT increases by 0.8K; influence coefficient of I→E=5dBμV / m / A, that is, when I increases by 1A, E increases by 5dBμV / m).

[0050] b. Standard Mapping: Dynamic Weight Adjustment of Airworthiness Constraints To address the issue that "fixed weights cannot adapt to different flight phases," a "phased weighting coefficient" is proposed: Takeoff / Landing Phase (High Risk): Electrical safety standard weight 0.6, EMC / thermal standard weight 0.3 / 0.1; Cruise Phase (Low Risk): Electrical safety standard weight 0.4, EMC / thermal standard weight 0.3 / 0.3; Dynamic weight switching logic: The weights are automatically adjusted through the "phase signals" of the aircraft avionics system (such as receiving a "landing instruction") to ensure that the parameter design matches the risk level.

[0051] c. Numerical Derivation: Multi-Domain Cooperative Solution via Reverse Iteration Breaking away from the serial optimization model of "optimizing a single domain and then verifying other domains", a parallel optimization algorithm is established: Initialize parameters: I=20A (satisfying MIL-STD-704F), calculate ΔT=18K (exceeding UL 1581), E=60dBμV / m (exceeding DO-160G); Construct the objective function: min [0.6×(I / 20) + 0.3×(E / 54) + 0.1×(ΔT / 15)] (landing phase weights); Reverse Iterative Correction: Step 1: Reduce I to 18A, ΔT = 18 2 ×0.05×0.05 / 10=0.081K (qualified), E=52dBμV / m (still exceeds); Second step: Based on inter-domain correlation, add an EMC filter (capacitor C=10μF) to make E=52dBμV / m (qualified). At this time, the objective function value = 0.6×(18 / 20)+0.3×(52 / 54)+0.1×(0.081 / 15)=0.54+0.296+0.0004=0.836 (≤1 is qualified); d. Compliance Confirmation: Verification of the multi-domain synchronous testing platform Establish a synchronous testing platform for "electrical-thermal-EMC": Electrical module: simulates 28V power supply and surge current; Thermal module: monitors the temperature field distribution of cables in real time; EMC module: synchronously collects radiated emissions from 30MHz to 1GHz; Verification indicators: all three parameters must meet the standards simultaneously (deviation ≤5%), and the "parameter adjustment - performance change" curve must be recorded to prove the effectiveness of the collaborative optimization.

[0052] 4.2 EICD Confirmation Rules Verification Objectives: Verify the correctness of EICD electrical attribute parameters (voltage / current meets requirements), EMC compliance (electromagnetic compatibility meets standards), and power supply matching (power capacity meets load requirements). Verification Standards: Measured electrical parameter values ​​deviate from EICD defined values ​​by ≤5%, and key parameters (such as power supply voltage for DAL A-level equipment) deviate by ≤2%; all EMC tests comply with DO-160G§20, with no radiation exceeding limits or immunity failure; cable allowable current carrying capacity ≥ 1.2 times the equipment's rated current, and power supply circuit voltage drop ≤ 1V (compliant with MIL-STD-704F).

[0053] 5. Step 5: Dynamic Allocation of Electrical Loads by EICD Focusing on the three-dimensional coupling relationship of "power supply-load-operating condition", a complete framework is constructed, including an electrical load classification system, dynamic allocation logic principle, quantitative calculation model and multi-dimensional verification mechanism, to achieve accurate matching between electrical load and airborne power system.

[0054] 5.1 Electrical Load Distribution Logic Principle Breaking away from the traditional method of classifying by equipment type, we adopt a three-dimensional classification system of "functional attributes + electrical characteristics + safety level".

[0055] 5.2 Electrical Load Quantization Allocation Model Load priority calculation model, principle: calculate priority based on three dimensions: comprehensive safety level, urgency of power demand, and impact of faults, and determine the power supply sequence.

[0056]

[0057] Weighting coefficients: (During the skiing phase, α=0.5, β=0.3, γ=0.2; during the cruising phase, α=0.3, β=0.2, γ=0.5). SDAL: Security Level Coefficient (Level A = 1.0, Level B = 0.8, Level C = 0.5, Level D = 0.2); Uurgent: Urgency factor (real-time load = 1.0, periodic load = 0.6, non-real-time load = 0.3); Fimpact: Failure impact factor (fatal failure = 1.0, serious failure = 0.7, minor failure = 0.3).

[0058] Power capacity allocation formula Principle: Based on load priority and the rated capacity of the power module, calculate the allocation ratio between the main power supply and the redundant power supply.

[0059] 1. Maximum power that can be allocated to a single module:

[0060] : Rated power of the i-th power module (e.g., 2000W); Conversion efficiency (0.92 for DC / DC module, 0.88 for AC / DC module). Thermal redundancy coefficient (0.2 for high temperature environment, 0.1 for normal temperature).

[0061] Actual power distributed to the load:

[0062] : Rated power of the j-th load (e.g., 300W required by FCC); Redundancy coefficient (Level A = 0.3, Level B = 0.2, Level C / D = 0.1); : Load safety level coefficient.

[0063] Power module load rate verification:

[0064] M i : The set of loads carried by the i-th power module.

[0065] Current distribution and cable selection formula: Principle: The wire diameter and current carrying capacity are calculated based on the power distribution to meet the voltage drop constraint.

[0066] Rated operating current:

[0067] Nominal voltage (e.g., 28V DC); Power factor (resistive load = 1.0, inductive load = 0.7~0.9).

[0068] Cable cross-sectional area calculation:

[0069] Cable length (m); K: Conductivity coefficient (57 S·m / mm² for copper cable) 2 ); Maximum permissible voltage drop (≤3%×U_{nom}, e.g., ≤0.84V for a 28V system).

[0070] 5.3 Multi-dimensional verification mechanism for electrical loads Power balance verification: Purpose: To ensure that the total load does not exceed the total capacity of the power system and to reserve emergency redundancy.

[0071] Total power system capacity (e.g., 10kW); Emergency redundancy coefficient (≥0.2) Qualification standard: Total load ≤ 80% of total capacity.

[0072] Voltage stability verification: Purpose: To verify that the voltage fluctuation at the load end is within the allowable range; Voltage drop verification: (R) j (For cable resistance); Dynamic voltage fluctuation: Voltage drop ≤10%Unom when sudden load is applied, recovery time ≤100ms (verified by PSpice simulation).

[0073] Thermal dissipation verification: Purpose: To prevent cables and power modules from overheating.

[0074] Cable temperature rise: ≤ 30K (≤ 55℃ at an ambient temperature of 25℃); Power module temperature rise: ≤ 40K (P) loss,i For module power loss, C th (For thermal resistance).

[0075] Fault tolerance verification: Objective: To verify the load-bearing capacity of a redundant system under single-power-supply failure.

[0076]

[0077] M f : Fault module set; P spare,k : Remaining capacity of the backup module; Qualification standard: After failover, the load rate is ≤90% of the backup capacity.

[0078] Iterative optimization process: 1. When the verification fails (e.g., power exceeds the limit), trigger priority reordering: reduce the priority of Class D loads (e.g., reduce the Pload of the cabin entertainment system from 0.3 to 0.15); reduce the redundancy factor of non-critical loads (e.g., reduce the Kredun of Class C from 0.1 to 0).

[0079] 2. Recalculate the power distribution and cable parameters, and repeat the verification steps. Output the "Electrical Load Distribution Scheme", including: power module-load distribution matrix, cable selection table (cross-sectional area, length, voltage drop), load power curves for each flight phase, fault tolerance verification report, etc.

[0080] 6. Step 6: EoICD Protocol Selection A "dynamically constrained intelligent selection framework" is constructed, which achieves automated and precise selection through a four-layer logic of "perception-optimization-verification-self-verification". The specific process is as follows: 1. Real-time operating condition perception and constraint extraction Three types of core constraint data are collected in real time via airborne system buses (such as AFDX, 1553B, etc.) to form a selection input matrix: Functional operating condition constraints: real-time characteristics of functional parameters in the FICD (e.g., the flight control command update cycle is reduced from 20ms to 10ms during takeoff, and the cabin entertainment data bandwidth requirement is reduced from 10Mbps to 2Mbps during cruise), and the dynamic rate of change of parameters is obtained through sensors and the EICAS system; Environmental constraints: Collect current flight environment parameters (such as bus signal attenuation rate at high altitude and low temperature (-55℃), EMI level in strong electromagnetic interference scenarios), and dynamically adjust the protocol anti-interference requirements in combination with DO-160G §8 / §20 standard; Device health constraints: Obtain the health status of device interfaces through the LRU's built-in BIT system, and determine the protocol fault tolerance priority by combining FMEA (Failure Mode and Effects Analysis) data.

[0081] 2. Selection of Multi-Objective Optimization Engine A "multi-objective weighted optimization model" is constructed, which dynamically allocates weights through the Analytic Hierarchy Process (AHP) and a historical selection knowledge base (machine learning training), and outputs the optimal protocol combination (supporting single protocol or multi-protocol fusion): Target dimensions definition: Set 5 core targets (real-time performance, security, cost, compatibility, and energy consumption), and associate each target with quantitative indicators (such as real-time performance = end-to-end latency, security = fault detection rate, and energy consumption = bus wake-up current). Dynamic weight allocation: The weights are adjusted based on real-time operating conditions (e.g., "real-time performance + safety" accounts for 70% of the weight during takeoff and "cost + energy consumption" accounts for 50% during cruise). The weight matrix is ​​optimized by training an LSTM model (inputting historical flight conditions and selection data from 300+ sorties). Protocol scoring and screening: Candidate protocols (ARINC429 / 664 / 825, TSN, 1553B) are scored according to the target dimension, and the combination of "main protocol + redundant protocol" is output (e.g., main protocol = ARINC429 (100kbps) for takeoff phase, redundant protocol = TSN (500kbps) for cruise phase, and main protocol = ARINC825 (250kbps) for cruise phase). Multi-protocol fusion determination: When a single protocol cannot meet the needs of multiple objectives, the fusion logic is triggered (e.g., ARINC429 is used to ensure the real-time performance of flight control data, ARINC664 is used to transmit fault logs for synchronization, and time synchronization between protocols is achieved through Time Sensitive Network (TSN).

[0082] 3. Redundancy compatibility check To address electromagnetic interference and topology conflicts when multiple protocols coexist, a "three-dimensional compatibility check" is added: Electromagnetic compatibility (EMC) verification: Electromagnetic coupling of multi-protocol buses (such as ARINC429 and ARINC825) in the same harness is simulated using CST simulation software to ensure that the interference voltage is ≤50mV (compliant with MIL-STD-461G). Topology compatibility verification: Based on the system architecture diagram, check whether the protocol topology matches (e.g., whether the ARINC664 switch ports support TSN time synchronization, and whether the ARINC825 nodes exceed the limit of 32). Timing compatibility verification: Build a timing model using Matlab / Simulink to verify whether there is a conflict in the time windows of multi-protocol data transmission (e.g., the overlap rate of the transmission time slots of ARINC429 command frames and ARINC664 log frames is ≤5%).

[0083] 4. Self-verification of selection results A digital twin model of the airborne system is introduced to verify the selection results through full-scenario simulation. Operating condition reproduction: Reproduce real-time flight conditions (such as takeoff, turbulence, and landing) in a twin environment to simulate the performance of the protocol under dynamic load; Fault injection test: Inject scenarios such as port failure and bus interference (such as ARINC429 port disconnection) to verify that the redundant protocol switching time is ≤10ms; Result output: Generate a "Protocol Selection Verification Report". If the pass rate is ≥95%, the selection is frozen; otherwise, it returns to the optimization engine for recalculation.

[0084] 7. Step 7: EoICD Attribute Definition and Confirmation The following is the specific process for constructing an attribute definition system that features "dynamic adaptation, cross-level tracing, and enhanced fault tolerance": 1. Construction of dynamic attribute adaptation matrix Establish a "flight phase - protocol attribute" adaptation matrix to enable attribute parameters to dynamically change with operating conditions: Attribute Dimension Expansion: In addition to the original hierarchical attributes (physical port / logical channel / data word / DP / RP), a new "dynamic attribute group" has been added (including real-time parameters: update cycle, latency threshold; fault tolerance parameters: redundancy switching time, bit error rate threshold; energy consumption parameters: bus wake-up current, sleep cycle). Adaptation matrix definition: Attribute values ​​are assigned according to flight phase (takeoff / climb / cruise / approach / landing), and the matrix is ​​associated with DO-178C DAL level (e.g., dynamic adjustment of DAL A level parameters requires airworthiness pre-verification).

[0085] Attribute adjustment triggering mechanism: When the twin model detects a change in operating conditions (such as switching from cruise to approach), it automatically sends an attribute adjustment command to the EoICD management system without manual intervention.

[0086] 2. Automatic mapping and conflict resolution of cross-level attributes Build a "cross-level attribute mapping engine" to achieve automatic parameter inheritance and conflict resolution based on knowledge graphs: Knowledge Graph Construction: Establish a FICD (Functional Parameters) - EoICD (Protocol Attributes) association graph and define mapping rules (e.g., in FICD, Class C parameter "precision ±0.1°" → ARINC429 data word "minimum effective unit 0.05°", and in FICD, "update period 20ms" → ARINC664 VL "BAG=20ms"). Automatic mapping execution: Input FICD parameter ID (e.g., FP-2750-TC-007), and the engine will automatically retrieve the map and generate a draft of EoICD attributes; Intelligent conflict resolution: When a mapping conflict occurs (e.g., FICD requires a latency of ≤5ms, while the ARINC825 protocol has a default latency of ≥8ms), the rules engine is triggered. Priority rule: If the conflicting parameter is DAL A level (such as flight control command), then the protocol attribute will be forcibly adjusted (such as changing ARINC825 to ARINC429). Compromise rule: If it is DAL C level (such as status feedback), then the requirements will be met through parameter optimization (such as compressing the ARINC825 frame length); Traceability chain generation: Generates a "FICD requirement-protocol attribute-standard clause" traceability chain for each EoICD attribute, supporting full lifecycle traceability.

[0087] 3. Fault-tolerant enhancement attribute design To address the high reliability requirements of airborne systems, a "failure mode-attribute redundancy" correlation design is implemented: Fault Mode Analysis: Based on the FMEA report, identify key protocol fault modes (such as ARINC429 parity error, ARINC664 VL frame loss). Redundancy attribute configuration: Design redundancy mechanisms for critical attributes (such as adding "double check bits" (odd check + CRC) to ARINC429 data words, configuring "dual redundant channels" (primary channel VL001, backup channel VL002) for ARINC664 VL, and adding "backup value fields" to DP parameters (the primary field stores the real-time value, and the backup field stores the value of the previous period)). Fault recovery attribute definition: Add "Fault recovery time" and "Number of retries" attributes (e.g., after the ARINC429 port fails, the number of retries = 3, and the recovery time ≤ 10ms) to ensure that attributes are quickly restored after a fault.

[0088] 4. Automated verification toolchain Build an integrated toolchain for "simulation-testing-compliance" to automate verification: Simulation verification: Output a simulation report using the VxWorks real-time system simulation protocol properties; HIL testing confirms: Inject real signals (such as the FCC sending the SlatCmdFlap1 command) into the hardware-in-the-loop (HIL) platform, collect the actual performance of EoICD attributes (such as latency and bit error rate), and compare them with the design values; Compliance verification: The toolchain automatically calls standard databases (such as ARINC429-19, MIL-STD-704F) to check whether the attributes conform to the specifications (such as whether the BAG value of ARINC664 VL is a standard value of 4 / 8 / 16ms, etc.). Confirmation result quantification: Output "confirmation pass rate" (e.g., 98%). Items that fail are automatically associated with the conflict resolution module, triggering attribute iteration.

[0089] 5. Iterative optimization closed loop Build a closed loop of "test data - attribute optimization" to continuously improve attribute accuracy: Data Acquisition: Collect actual EoICD attribute data (such as median delay and bit error rate statistics) during simulation, HIL testing, and flight testing phases. Deviation analysis: Compare actual data with design values ​​to identify deviations (e.g., ARINC429 actual delay 6ms > design value 5ms). Optimize execution: Adjust attribute parameters using the gradient descent algorithm (e.g., increase the ARINC429 baud rate from 100kbps to 200kbps), and re-verify until the deviation is ≤5%; Version management: Generates new versions for optimized attributes, associates iteration reasons with test data, and supports version rollback.

[0090] 8. Step 8 - Specific methods for defining the hardware and software interfaces within the device. 8.1 Definition of Hardware and Software Interfaces within the Device Taking LRU devices and HA applications as objects, this paper describes the relationships and necessary attributes of the internal hardware and software interfaces of the devices, providing inputs and constraints for further capturing hardware and software interface requirements.

[0091] a. Describe the equipment configuration items, systematically outlining the overall picture of the equipment's internal hardware and software interfaces. A detailed list of internal hardware modules and boards should be compiled, clearly specifying their models, quantities, and key connector information; the mechanical assembly relationships and spatial layout between modules should be clearly expressed using engineering drawings such as exploded views, isometric views, or three-view diagrams; simultaneously, an internal hardware interface connection diagram should be drawn to visually demonstrate signal flow and physical interconnections. On the software side, a software architecture diagram should be provided illustrating the hierarchical relationships between the operating system, drivers, middleware, and applications, and an application residency table should be used to specifically illustrate the hardware platform and system software environment upon which each software component relies, laying the foundation for subsequent interface design.

[0092] b. Based on the various functions of the equipment decomposed from the system requirements, define the functional interfaces within the equipment and their allocation. A functional interface relationship table needs to be compiled, defining the sending end, receiving end, interface signal name, and meaning of each function; simultaneously, a function allocation table needs to be developed, clearly assigning the identified functions to specific hardware platforms, platform software, and application software to ensure clear responsibility for function implementation. Subsequently, an allocation relationship matrix between functional interfaces and underlying hardware and software interfaces needs to be established, tracing each functional signal back to its implementing hardware signal, driver call, or inter-software message, and summarizing this to form a master table of electrical connections between modules within the equipment, thus completing the full mapping from function to implementation.

[0093] c. Define hardware-hardware interfaces to achieve electrical interconnection. First, the mapping between the device's external interface (EICD) and internal interface must be completed. Using a lookup table, the host-defined EICD signals (including connector type, pin number, and signal FullName) are precisely linked to the internal connectors and pin definitions. Next, each internal connector's pin signals, electrical parameters (such as level and impedance), power consumption characteristics (operating voltage and current), and system memory mapping addresses (various control status registers and memory address space allocation) are defined in detail for each module. Finally, the electrical and protocol standards for various interfaces must be specified, such as open / ground thresholds for discrete quantities, timing parameters for LVDS video, and electrical specifications for PCIe / SPI / I2C buses, ensuring that design and acceptance are based on sound principles. This section does not apply to LRU / HA devices without internal electronic hardware and without external connectors.

[0094] d. Define the software-hardware interface to standardize how software accesses hardware. For software-hardware interfaces without platform software, this refers to operations configured for reading / writing I / O or communicating via bus ports during bare-metal programming, such as calling GPIO ports, performing serial communication, or direct memory access. For software-hardware interfaces with platform software, this refers to the interface between hardware drivers and the hardware. This section should specifically list the software access interfaces for all device hardware BITs (built-in test), including status reading, test start control commands, etc., to support system health management.

[0095] e. Define software-to-software interfaces to coordinate the collaborative work of various internal software programs. Software-to-software interfaces primarily define interfaces between application layer and platform software layers. System applications refer to applications that perform resource management and internal processing functions on platform resources, while resident applications refer to applications that use platform resources to implement specific functions. First, establish a traceability relationship between internal software interfaces and external EoICD signals to ensure that every data parameter requested by the host can be mapped to a specific software signal or message. Second, define the interaction mechanisms between application software running on the same or different hardware, including queue / sampling messages based on the ARINC 653 port, network communication based on sockets, or data synchronization through APIs such as shared memory and semaphores provided by the operating system. Furthermore, define data exchange interfaces between different partitions of the operating system or system software on the same hardware platform, such as transmitting status, configuration, or log information through shared memory areas, and specify the data format, address, and access permissions.

[0096] f. Define complex electronic interfaces, specifically designed for programmable logic devices such as FPGAs and CPLDs. First, define the underlying bus protocol for communication with these devices, such as the SPI frame format (address, command, data segment division), read / write timing, and bit width. Based on this, provide a complete register list, including the name, offset address, and read / write attributes of each functional register; and provide detailed bit-level definitions for each register, explaining the function, valid value, initial value, and physical meaning of each bit (e.g., status bit, control bit, data field). Finally, create a precise interface control document for software-driven development and hardware logic verification, ensuring the reliable implementation of complex electronic functions.

[0097] 8.2 Rules for Confirming Hardware and Software Interfaces Within the Equipment The objectives to be verified are: to verify the completeness of the hardware and software interfaces within the equipment (no missing hardware-to-hardware / software-to-hardware / software-to-software interfaces), logical consistency (no conflicts in interface interaction), physical feasibility (electrical / protocol parameters conform to hardware capabilities), external traceability (accurate mapping with EICD / EoICD external interfaces), and to verify that the equipment meets the airworthiness requirements of DO-254 (hardware) and DO-178C (software).

[0098] Confirmation Criteria: 100% coverage of associated hardware and software configuration items, with no "orphan configuration items" (unassociated hardware / software); compatibility between software components and hardware platforms conforms to supplier specifications (e.g., servo control software supports TI TMS570 CPU); deviation between measured electrical parameter values ​​and defined values ​​in step 8 ≤ 5%; power supply line voltage drop ≤ 1V; bus timing 100% conforms to hardware specifications; 100% success rate of software-to-hardware interface driver calls; 100% BIT fault detection rate; consistency deviation between API output and input parameters ≤ 1% (e.g., PWM duty cycle call 50%, measured 49.8%); packet loss rate of software-to-soft interface communication ≤ 0.1%, error rate = 0; 100% consistency of shared memory data; ARINC 653 port message update cycle deviation ≤ 1ms; 100% FPGA register read / write accuracy; 100% PCIe bus speed conforms to 5Gbps / channel; signal eye diagram parameters conform to PCIe Gen2 specifications; 100% traceability coverage of external and internal interfaces; 100% internal interface functionality supports external interface requirements.

[0099] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for defining and verifying an airborne system ICD, characterized in that, include: The functional interfaces are defined and confirmed, including: identifying functional parameters based on the system function list and requirements, and classifying the functional parameters into three categories: energy, control, and power; assigning a globally unique identifier to each functional parameter within the system, and defining a corresponding attribute set for each type of functional parameter; and confirming the integrity, uniqueness of the identifier, and compliance of the attributes of the functional interfaces based on preset confirmation rules. Define and verify the static information of the mechanical interface, including: classifying the airborne system physical equipment into multiple categories according to the mechanical interface function and installation characteristics; designing a unique mechanical static attribute template for each category of equipment; calculating the mechanical static parameters based on the energy parameters and system requirements in the upstream functional interface; and verifying the assembly feasibility, tolerance compliance and interface matching of the mechanical interface static information based on preset verification rules. The dynamic information of the mechanical interface is defined and verified, including: classifying airborne system equipment into multiple categories according to dynamic behavior characteristics; defining exclusive motion envelope parameters for each category of equipment; generating adaptive dynamic parameters of the equipment under all operating conditions based on the parameterized expression of operating conditions and response surface fitting technology; and verifying the dynamic characteristics, motion trajectory accuracy and fault tolerance of the dynamic information of the mechanical interface based on preset verification rules. The electrical interfaces are defined and validated, including: classifying airborne system equipment into multiple categories according to their electrical interface characteristics; designing dedicated electrical attribute templates for each category of equipment; optimizing electrical, thermal, and electromagnetic compatibility parameters in conjunction with the inter-domain sensitivity transfer matrix based on power parameters in upstream functional interfaces and system requirements; and validating the correctness of electrical interface parameters, electromagnetic compatibility compliance, and power supply matching based on preset validation rules. The electronic interface protocol selection process includes: real-time acquisition of functional conditions, environmental conditions, and equipment health constraints via airborne bus; construction of a multi-objective weighted optimization model, dynamic allocation of weights based on flight phases, scoring of candidate protocols, and outputting a combination of main and redundant protocols; and verification of the selection results in three dimensions of electromagnetic compatibility, topology, and timing, with the introduction of a digital twin model for self-verification. The electronic interface is defined and validated, including: constructing a dynamic adaptation matrix for flight phase and protocol attributes so that attribute parameters can be dynamically adjusted according to operating conditions; realizing automatic inheritance and conflict resolution of attributes from functional interfaces to electronic interfaces through a cross-level attribute mapping engine; designing fault tolerance enhancement mechanisms for key attributes; and validating and iteratively optimizing attributes through an automated toolchain that includes simulation, hardware-in-the-loop testing, and compliance checks. Define and validate the hardware and software interfaces within the device, including: defining device configuration items, functional interface allocation, hardware-hardware interfaces, software-hardware interfaces, software-software interfaces, and complex electronic interfaces within the device or hardware application; and validating the integrity, logical consistency, physical implementability, and traceability with external interfaces of the hardware and software interfaces within the device based on preset validation rules.

2. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, Also includes: Dynamic allocation and verification of electrical loads, including: classifying electrical loads using three-dimensional labels of functional attributes, electrical characteristics, and safety levels; Based on the load priority calculation model, power capacity allocation formula and cable selection formula, the system realizes the quantitative allocation of electrical loads; the allocation results are verified in multiple dimensions such as power balance, voltage stability, heat dissipation and fault tolerance, and iterative optimization is triggered when the verification fails.

3. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, In the three-element classification of the functional parameters, energy parameters are based on fluids, and their core attributes include medium type, pressure, flow rate, and temperature; control parameters are based on information, and their core attributes include data type, accuracy, update cycle, and delay time; and power parameters are based on electrical energy, and their core attributes include voltage, current, frequency, and power.

4. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, Calculate the mechanical static parameters, including: Demand capture: Establish a two-layer structure of primary constraints and secondary coupled constraints, and output quantized thresholds and associated weights; Standard mapping: Conflicting standards are reconciled by quantifying the standard fit function, which is calculated based on the number of standard coverage constraints and the degree of matching between the standard and the operating conditions; Numerical Derivation: Based on the physical field sensitivity coefficient matrix, through the formula Calculate the final mechanical static parameters, where Basic parameters, Let be the sensitivity coefficient of the i-th type of physical field. Let be the operating condition influence factor of the i-th type of physical field.

5. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, The response surface fitting technique specifically involves decomposing the working condition into three dimensions: load intensity, duration, and number of cycles. Multiple typical working conditions were selected and the corresponding dynamic parameters were obtained through joint simulation. The quadratic response surface method was used to fit the continuous functional relationship between the dynamic parameters and the working condition dimension.

6. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, The inter-domain sensitivity transfer matrix is ​​used to construct a constrained directed graph of electrical, thermal, and electromagnetic compatibility parameters, and the parameters are optimized through a multi-domain collaborative solution algorithm with reverse iteration.

7. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, The load priority calculation model is as follows: Where SDAL is the safety level coefficient, Uurgent is the urgency coefficient, Fimpact is the failure impact coefficient, and α, β, and γ are weighting coefficients that are dynamically adjusted according to the flight phase.

8. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, The target dimensions of the multi-objective weighted optimization model include real-time performance, safety, cost, compatibility, and energy consumption. The weights of each dimension are dynamically allocated based on the flight phase using a machine learning model.

9. The method for defining and verifying an airborne system ICD according to claim 1, characterized in that, The definition of the complex electronic interface includes the underlying bus communication protocol, register list, and bit-level definition for programmable logic devices.

10. An airborne system ICD definition and verification system for implementing the method as described in any one of claims 1-9, characterized in that, include: The input module is used to receive and parse the system function list, aircraft-level and system-level requirements, as the top-level input for the ICD definition; The database module is used to store and manage general and specific attribute parameters of various devices; Support modules are used to provide support for N-nature analysis, toolchain integration, system architecture design guidance, and the invocation and compliance checks of standard and specification clauses; The processing module is used to define the functional interface, mechanical interface, electrical interface, electronic interface and internal hardware and software interface of the device in sequence according to the output of the input module, and realize cross-level parameter association and attribute inheritance; the processing module also includes an iterative design unit, which is used to automatically trace and trigger the iterative optimization of the corresponding upper-level interface when the downstream interface definition is incompatible with the upstream interface definition; The output module is used to generate and export various interface control document files.

Images