Airborne system ICD changing method and system

Abstract

The invention provides an airborne system ICD change method and system, and relates to the field of airborne systems.The airborne system ICD change method comprises the following steps that S1, an airborne system ICD change management environment is initialized, and an interface dependency relationship model is established; s2, receiving a change request, analyzing the change request, and identifying a change type; s3, calling the interface dependency relationship model, executing change influence analysis based on the change type, and generating a change influence report; s4, performing change review and implementation based on the change influence report to obtain a change result; and S5, verifying the change result, and generating a change closed-loop report. The problems that in the ICD changing process of an existing airborne system, the flow is not standard, changing analysis is not comprehensive, different types of ICD changing lacks a targeted method, and changing system collaboration is insufficient are solved, the scientific, controllable, efficient and accurate changing method and system are provided, and the compatibility and reliability of the changed system are guaranteed.

Description

TECHNICAL FIELD

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

[0002] Modern aircraft (such as civil passenger aircraft, military transport aircraft) is an integrated platform composed of multiple airborne systems, and the core systems include avionics systems (such as communication and navigation), electromechanical systems (such as hydraulic and environmental control), flight control systems, etc. These systems need to work cooperatively through physical connection and message interaction to complete the flight task. For example, the "rudder deflection command" issued by the cockpit needs to be transmitted to the flight control system through the avionics system, and at the same time, the hydraulic subsystem of the electromechanical system needs to provide power support for the rudder.

[0003] The interaction between each airborne system depends on standardized interfaces, and the definition file is called interface control document, which is the top-level technical document of aircraft design. According to the interface characteristics, ICD can be divided into FICD, MICD, EICD and EoICD, and EoICD is further divided into direct connection and network connection. The control interface description document is an important technical document for describing the interface characteristics between systems, and plays a key role in ensuring the correct interaction and cooperative work between systems.

[0004] With the continuous improvement of airborne system functions, the continuous upgrading of technology and the changes in user needs, ICD inevitably needs to be changed. At present, there are many problems in the process of changing airborne system ICD. The change process is not standardized, and there is a lack of systematic change analysis and evaluation mechanism, which leads to inaccurate change influence range judgment and easy occurrence of new interface problems. In terms of change analysis, there is no effective breadth traversal and summary checking method, which makes it difficult to fully discover the chain reaction that may be caused by the change. At the same time, there is a lack of special change processing method for different types of ICD, which makes the change efficiency low and the change quality difficult to guarantee. In addition, the existing ICD change system lacks cooperation in input, processing, storage and output, and cannot provide efficient and reliable support for the change process.

[0005] Especially after the complexity of the system increases, the defects of the traditional method are more prominent: manual dependence leads to missing associated interfaces, no automated tool support for multiple rounds of verification, no linkage mechanism for cross-type ICD change, and easy out-of-sync change. Therefore, a standardized, systematic and differentiated ICD change method and system is urgently needed to solve the above problems. SUMMARY

[0006] Therefore, the embodiments of the present application aim to solve the problems of non-standard process, non-comprehensive change analysis, lack of targeted methods for different types of ICD changes, and insufficient system coordination in the process of changing the existing airborne system ICD, and provide a scientific and controllable, efficient and accurate airborne system ICD change method and system to ensure the compatibility and reliability of the system after the change.

[0007] The embodiments of the present application provide the following technical solutions: an airborne system ICD change method, comprising the following steps: Step S1: initializing the airborne system ICD change management environment, and establishing an interface dependency relationship model; Step S2: receiving an ICD change request, and analyzing the ICD change request to identify the ICD change type; Step S3: calling the interface dependency relationship model, performing change impact analysis based on the ICD change type, and generating a change impact report; Step S4: based on the change impact report, performing change review and implementation to obtain a change result; Step S5: verifying the change result, and generating a change closure report.

[0008] The present application also provides an airborne system ICD change system for implementing the above method, comprising: An input module for receiving an ICD change request and basic data; A processing and storage module for storing an interface dependency relationship model and performing change identification, change impact analysis, and risk assessment operations; An output module for generating a change impact report and a change closure report.

[0009] Compared with the prior art, the above at least one technical solution adopted by the embodiments of the present application can achieve at least the following beneficial effects: The airborne system ICD change method process provided by the embodiments of the present application is standardized, and through steps such as change initiation, change analysis, change review, change implementation, and change verification, the systematicness and scientificity of the ICD change process are ensured, and the randomness and blindness in the change process are reduced.

[0010] The change analysis link of the embodiments of the present application introduces change impact analysis and iterative analysis, wherein the iterative analysis includes depth traversal and summary checking, which can comprehensively and accurately identify the possible impact of the change, and avoid incomplete change or causing new problems.

[0011] The embodiments of the present application provide special change methods for different types of ICDs, such as FICD, MICD, EICD, and EoICD, so that the change processing is more targeted and effective, and the change efficiency and quality are improved.

[0012] The airborne system ICD change system provided by the embodiment of the present application realizes effective input, processing, storage and output of information in the ICD change process through the cooperative work of the input module, the processing and storage module and the output module, provides efficient and reliable support for the change process, and facilitates the tracing and management of the change process. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0014] Fig. 1 is the ICD change flowchart of the embodiment of the present application; Fig. 2 is the change analysis sub-flowchart of the embodiment of the present application; Fig. 3 is the change verification flowchart of the embodiment of the present application. DETAILED DESCRIPTION

[0015] The embodiments of the present application will be described in detail below with reference to the drawings.

[0016] The abbreviations and key terms involved in the embodiments of the present application 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; ASML Airborne System Modeling Language; BFS Breadth-First Search; LRU Line Replaceable Unit; LRM Line Replaceable Module; BCU Brake Control Unit; HIL Hardware-In-the-Loop; DAL Development Assurance Level; WCET Worst-Case Execution Time; CCB Configuration Control Board; As shown in Figs. 1-3 The embodiment of the present application provides an airborne system ICD change method, which comprises the following steps: step S1: initializing an airborne system ICD change management environment, and establishing an interface dependency relationship model; step S2: receiving an ICD change request, and analyzing the ICD change request to identify an ICD change type; step S3: calling the interface dependency relationship model, performing change impact analysis based on the ICD change type, and generating a change impact report; step S4: based on the change impact report, performing change review and implementation to obtain a change result; and step S5: verifying the change result, and generating a change closed-loop report.

[0017] Step S1 includes: (Step 1 is a prerequisite, in which an interface dependency model is established in the early stage, and subsequent calls are only required) Step S101: Collect and integrate basic data, extract and transform all basic data into a unified meta-model to complete unified data modeling; the basic data includes ICD documents, system architecture design specifications, function lists, and function allocation lists, etc.; Step S102: Based on the basic data, establish a functional interface dependency model, including breadth-first traversal of calls between functional layers; Step S103: Based on the basic data, establish a physical dependency model, which includes dependencies of electronic, electrical, and mechanical layers, forming a full-link dependency from function to physical implementation, forming the interface dependency model with a four-layer model including functional, electronic, electrical, and mechanical layers; Step S104: Set dependency strength quantification rules.

[0018] Step S2 includes: Step S201: Receive and parse the ICD change request to obtain a structured change object; map the change object to the interface dependency model based on a unique identifier; Step S202: Compare the old and new ICD files based on the unique identifier to identify the ICD change type, which includes addition, deletion, and attribute modification; Step S203: Form a change dataset based on the list of change objects, the change type, and the position of the change object in the interface dependency model.

[0019] Step S3 includes: Step S301: Invoking the interface dependency model, based on the change dataset, starting from the initial level of the change, performing layered and cross-layer dependency traversal to obtain an impact item list; Step S302: Calculating the direct impact scope of the change based on the impact item list, generating a layered direct impact list, including the list of affected interfaces and the affected system modules and corresponding physical devices; Step S303: Analyzing the indirect impact and multi-dimensional risks of the change based on the impact item list, including risks related to functional compatibility, timing, resources, and interface conflicts, generating a risk analysis matrix table organized by layer-risk dimension; Step S304: Analyzing the cross-layer propagation path of the change based on a breadth-first search algorithm to form a full-link impact diagram; Step S305: Generating a traceable change impact report based on the impact item list, the direct impact list, the risk analysis matrix table, and the full-link impact diagram.

[0020] Step 4 includes: Step 401, organizing a Change Control Committee (CCB) meeting to conduct compliance checks and risk discussions based on the change impact analysis report; Step 402, forming a decision and establishing tracking items; Step 403, developing an implementation plan, including document updates, configuration changes, software and hardware modifications, etc.; Step 404, performing system integration and functional testing to verify the effects of the changes.

[0021] Step 5 includes: Step 501, performing functional and performance tests to verify whether the changes meet functional requirements; Step 502, performing system-level compatibility tests to verify the impact of the changes on the overall system functionality; Step 503, generating a change closure report to confirm the effectiveness and reliability of the changes.

[0022] In one specific embodiment, this embodiment provides an airborne system ICD change management method based on an interface dependency model, and the specific implementation steps are as follows: Step 1: Initialize the change management environment and establish a four-layer interface dependency model; Step 101: Collect and integrate basic data 1. Data source identification and collection: Functional definition documents: System Requirements Specification (SyRS), Software Requirements Specification (SRS), Functional Requirements Document (FRD), Functional Assignment Document (FAD).

[0023] Interface definition files: Interface Control Document (ICD), Mechanical Interface Control Document (MICD), Electrical Interface Control Document (EICD), Electronic Interface Control Document (EoICD).

[0024] Architecture design documents: System Architecture Design Document (SADD), Hardware Design Document (HDD), Wiring Harness Design Drawings, Mechanical Installation Drawings, 3D Model.

[0025] Standards and specifications: ARINC 429, ARINC 664p7 (AFDX), ARINC 653, DO-178C, DO-254, DO-160G and other industry standards.

[0026] 2. Unified data modeling: Extract and transform all data into a unified meta-model. Model-Based Systems Engineering (MBSE) approach is recommended, using SysML as the modeling language.

[0027] Create a unique instance for each entity in the model database and establish relationships. For example, create a function A, link it to the software component B that implements it, then to the LRU C it deploys, and finally to the electrical interface and mechanical mounting point of the LRU C. Output: A structured, interconnected system foundation database (built using the MBSE tool).

[0028] Step 102: Establish a functional interface dependency model 1. Functional Decomposition: Based on system requirements, decompose functions to form a functional architecture tree. 2. Functional Flow Analysis: Analyze the input-output relationships between functions and define logical interfaces (data flow, control flow). For example, the "Flight Management Function" outputs "Predetermined Flight Track" data for use by the "Flight Control Function". 3. Resource Requirement Mapping: Allocate processing resources (e.g., CPU cores), computing power requirements (WCET), and memory requirements for each function. 4. Visualization: Use SysML activity diagrams or sequence diagrams to describe the interaction flow between functions. Use SysML internal block diagrams to describe the interface connections between functional modules.

[0029] Output: Functional layer dependency model (SysML model file), which clearly shows the logical interactions and dependencies of system functions.

[0030] Step 103: Establish a physical dependency model (electronic, electrical, and mechanical layers). 1. Function-Physical Assignment: Based on the function assignment list, assign the functions defined in step 102 to specific physical components.

[0031] Function -> Electronic Layer: Functions are assigned to specific LRUs or partitions. Electronic Layer -> Electrical Layer: LRUs are assigned specific electrical interfaces (e.g., ARINC 429 channels, discrete input / output pins). Electrical / Electronic Layer -> Mechanical Layer: LRUs and wiring harnesses are assigned physical mounting locations and connectors.

[0032] 2. Layered Modeling: Electronic Layer Model: Describes the communication relationships between LRUs (e.g., the flight control computer communicates with the atmospheric data inertial reference unit via the AFDX network). Represented using SysML internal block diagrams, attributes such as communication protocols, bandwidth, and latency are annotated.

[0033] Electrical Layer Model: Describes how the wiring harnesses connect to the electrical interfaces of each LRU. It uses SysML internal block diagrams, labeling signal types, voltages, currents, and pin numbers. Mechanical Layer Model: Describes the physical installation and connection relationships of LRUs, brackets, and wiring harnesses. It uses SysML parametric diagrams to describe attributes such as weight and center of gravity, and establishes a connection with the 3D CAD model. End-to-End Traceability: Establishes a complete traceability chain in the model from function -> software components -> (electronic) hardware -> electrical interfaces -> mechanical installation. Output: An integrated four-layer physical dependency model (SysML model file), achieving end-to-end visualization from function to physical implementation.

[0034] Four-layer interface model attribute association rules I. Functional Layer (FICD) Attribute Association Rules 1. Deep correlation with energy-related attributes Media type: Mechanical layer: selection of sealing materials and piping materials; Electrical layer: conductivity / insulation requirements; Functional layer: compatibility constraints with other media; Pressure + Flow: Electrical layer: Pump motor power calculation (power = pressure × flow / efficiency); Mechanical layer: Pipeline strength design, connector pressure rating; Electronic layer: Sensor range selection, monitoring task parameter settings; Temperature + Purity: Mechanical layer: thermal expansion compensation, filtration grade selection; Electrical layer: temperature resistance rating of insulation materials; Functional layer: quality control algorithm parameters; Failure threshold + continuous supply capability: Electronic layer: monitoring and alarm threshold settings; Electrical layer: backup system switchover time requirements; Functional layer: degradation mode activation conditions; 2. Deep association of power-related attributes Voltage + Current + Frequency: Electrical layer: Cable specification selection, protection device settings; Electronic layer: Power supply monitoring parameters, equipment operating range verification; Mechanical layer: Thermal management design basis; Waveform distortion rate + fluctuation range: Electrical layer: filter circuit design, power quality requirements; Electronic layer: ADC accuracy requirements, signal processing algorithm; Functional layer: analysis of the impact on control accuracy; Grounding methods: Electrical layer: grounding system design, EMC performance; Mechanical layer: grounding connection point design, corrosion protection measures; 3. Control the deep association of class attributes Parameter name + data type: Electronic layer: message identifier definition, data format conversion; Functional layer: interface compatibility check; Accuracy + Range: Electronic layer: Data bit allocation calculation (bits = log2(range / accuracy)); Mechanical layer: Actuator accuracy matching; Functional layer: Control algorithm parameter optimization; Update cycle + delay time: Electronic layer: Task cycle setting, scheduling analysis; Electrical layer: Signal transmission delay budget; Mechanical layer: System response time verification; Failure Modes + Priorities: Electronic Layer: Task priority allocation, fault tolerance mechanisms; Electrical Layer: Protection circuit design; Functional Layer: Safety state machine design; II. Complete Association of Mechanical Layer (MICD) Attributes 1. Static information attribute association Equipment List Index Code: All Layers: Unique Identifier Traceability, Configuration Management; Functional Layer: Function-Physical Allocation Verification; Connector Model + Protection Level: Electrical Layer: Interface Compatibility, Environmental Adaptability; Mechanical Layer: Installation Space Verification, Maintenance Accessibility; Installation Coordinates + Positioning Tolerances: Mechanical Layer: Interference Inspection, Thermal Deformation Analysis; Electronic Layer: Signal Transmission Distance Calculation; Functional Layer: System Layout Optimization; Flange Diameter + Seismic Bracing: Mechanical Layer: Structural Strength Analysis, Vibration Transmission; Electrical Layer: Impact of Connection Reliability; 2. Dynamic information attribute association Vibration Environment Level + Shock Tolerance Spectrum: Mechanical Layer: Fatigue Life Analysis, Resonance Avoidance; Electronic Layer: Component Selection Basis, Fixing Method Selection; Electrical Layer: Connection Reliability Assessment; Trajectory Repeatability Accuracy + Acceleration Envelope: Functional Layer: Control Performance Limit Determination; Mechanical Layer: Wear Prediction, Maintenance Cycle Calculation; Electronic Layer: Sensor Accuracy Requirements; Multi-Field Coupling Equations: Functional Layer: Error Compensation Algorithm Design; Mechanical Layer: Structural Optimization Basis; Electronic Layer: Calibration Parameter Setting; Life Prediction Model: All Layers: Reliability Analysis, Maintenance Plan Formulation; Functional Layer: Degradation Strategy Design; III. Complete Association of Electrical Layer (EICD) Attributes 1. General Electric Attribute Association Power supply type + rated parameters: Functional layer: power budget allocation; Electronic layer: equipment selection basis; Mechanical layer: heat dissipation design input; Connector model + grounding method: Mechanical layer: mounting interface design; Electronic layer: signal integrity assurance; Functional layer: reliability impact analysis; 2. Specialized equipment attribute association High-power equipment: Current rating + bus transients: Electrical layer: Protection device settings, cable specifications; Mechanical layer: Enhanced thermal management; Functional layer: Startup sequence optimization; Avionics digital equipment: Impedance matching + Shielding requirements: Electrical layer: PCB layout constraints; Mechanical layer: Installation isolation requirements; Electronic layer: Signal quality assurance; RF communication equipment: Characteristic impedance + Voltage standing wave ratio (VSWR): Electrical layer: Antenna design, matching network; Mechanical layer: Installation location optimization; Functional layer: Communication performance budget; Electromechanical actuation equipment: Back EMF + Braking energy: Electrical layer: Protection circuit design; Mechanical layer: Mechanical braking coordination; Functional layer: Safe shutdown strategy; IV. Complete Correlation of Electron Layer (EoICD) Attributes 1. ARINC429 protocol attributes are fully associated Port layer attributes: Port identifier + LRU location; Mechanical layer: Physical location traceability; Electrical layer: Connector assignment; Connector type + Transmission rate; Electrical layer: Signal integrity requirements; Mechanical layer: Installation space verification; Data layer attributes: Label + encoding format + data bits: Functional layer: parameter identification mapping; Electronic layer: protocol stack configuration; SSM encoding + scaling factor: Functional layer: state mapping, range conversion; Electronic layer: error handling mechanism; 2. Full association of ARINC664 protocol attributes Logical port attributes: Port identifier + Physical port binding: Electrical layer: Network interface design; Mechanical layer: Cabling path planning; Bandwidth limitation + Direction definition: Electronic layer: Traffic shaping configuration; Functional layer: Data flow planning; Virtual link attributes; BAG + Maximum frame length + Jitter requirements: Electronic layer: Scheduling analysis, buffer design; Functional layer: Real-time verification; Redundancy mechanism + Scheduling priority: Functional layer: Reliability requirement mapping; Electronic layer: Fault tolerance design; 3. ARINC825 protocol attribute full association Channel attributes: Data transmission rate + Sampling point configuration: Electrical layer: Bus termination design; Electronic layer: Controller configuration; Message attributes: Message ID + Data field length: Functional layer: Signal identifier mapping; Electronic layer: Filter settings; Transmission interval + Node identifier: Electronic layer: Scheduling strategy; Functional layer: Timing coordination; V. Cross-level attribute derivation relationship 1. Performance Attribute Derivation Chain Functional layer update cycle + Functional layer accuracy requirements; Electronic layer.Task cycle + Electronic layer.Data bit width; Electrical layer bandwidth requirements + Electrical layer signal quality; Mechanical layer: responsiveness + Mechanical layer: manufacturing precision; System-level performance verification; 2. Reliability Attribute Derivation Chain Functional layer: Integrity requirements + Functional layer: Availability requirements; Electronic layer redundancy design + electronic layer monitoring mechanism; Electrical layer: Protection circuit + Electrical layer: Backup power supply; Mechanical layer life prediction + Mechanical layer maintenance strategy; System-level reliability assessment; 3. Security Attribute Derivation Chain Functional layer.Failure mode + Functional layer.Priority; Electronic layer fault tolerance mechanism + electronic layer security monitoring; Electrical layer. Fail-safe + Electrical layer. Isolation measures; Mechanical layer. Fail-safe + Mechanical layer. Degradation mode; System-level security authentication; VI. Attribute Conflict Detection Rules 1. Direct attribute conflict; 2. Indirect attribute conflict; 3. Environment-related conflict. Step 104: Set Dependency Strength Quantization Rules Dependency strength should be determined based on the severity of the potential consequences of changes and the fault tolerance of the system architecture, as shown in the table below.

[0035]

[0036] Output: "Interface Dependency Strength Quantification Rules", which should be integrated into subsequent automated analysis tools.

[0037] Step 2: Receive and analyze change requests, and identify the change type. The input change requests are standardized, parsed, and classified to accurately pinpoint the initial scope and level of their impact, laying the foundation for subsequent in-depth impact analysis.

[0038] Step 201: Receive and parse the change request Execution steps: 1. Standardized Input: Mandate that all change requests (CRs) be submitted through standardized forms; 2. Machine-readable parsing: While human description is necessary, key information (such as change object identifiers) should be machine-readable.

[0039] Use XML or Excel format to encapsulate the core metadata of change requests, making it easier for the toolchain to process them automatically.

[0040] Example: A request to modify the CR of the FCC_A_APP software module may contain the following XML format:<affected_item type="software"> PROJ1::FCC::APP::FCC_A_APP< / affected_item> Label.

[0041] Output: A structured change request object containing machine-readable information.

[0042] Step 202: Perform change comparison and classification based on unique identifiers. 1. Identifier Mapping: Map the changed objects mentioned in the change request to the corresponding entities in the four-layer dependency model established in step 1. This is the most crucial step.

[0043] For example, the change object "FCC_A_APP" is mapped to a software component in the model, thereby finding its function, deployed LRU, and electrical interface used.

[0044] 2. Change type identification: Add: New entities that do not exist in the model (such as new features, new LRUs, new signals).

[0045] Remove: Removes an existing entity from the model.

[0046] Modify: Changes the attributes of an existing entity.

[0047] Functional layer modifications: Algorithm logic, interface protocol, and data format changes. Electronic layer modifications: Hardware version upgrades and resource requirement changes. Electrical layer modifications: Voltage, current, and pin definitions changes. Mechanical layer modifications: Installation method, weight, and materials changes.

[0048] 3. Automated comparison: If it is based on document changes (such as ICD version upgrade), use tools to compare the old and new versions of XML / Excel format ICD files and automatically extract the list of "added, deleted, and modified" signals.

[0049] 4. Determine the “originating level” of the change: Based on the content of the change, determine the level at which the change initially occurred (functional, electronic, electrical, mechanical), which will determine the starting point and focus of subsequent impact analysis.

[0050] Output: A change dataset that clearly describes the change type, a list of changed objects, and the location of these objects in the four-layer model.

[0051] Step 3: Perform a change impact analysis and generate a change impact report. Step 301: Call the four-layer interface dependency model to perform layered dependency traversal; 1. Input preparation: Change log: Clearly define the initial level and specific object of the change (e.g., the navigation control law algorithm was changed at the functional level).

[0052] Four-layer interface dependency model: Functional layer model: describes system functions, functional parameters, data flow, logical interfaces (such as ARINC 429 data words, ARINC 664), and calling relationships.

[0053] Electronic layer model: describes how functions are mapped to electronic hardware (LRU, LRM), the interaction between hardware components (CPU, FPGA, memory), and bus controllers (such as AFDX end systems, CAN controllers).

[0054] Electrical layer model: describes the electrical connections between electronic devices, wiring harnesses, pinouts, signal types (discrete, analog, serial data), power distribution, and grounding.

[0055] Mechanical layer model: describes the physical installation of the equipment (mounting bracket, cooling plate), connectors (model, number of pins), cable routing, weight, center of gravity, and cooling method (air cooling / liquid cooling).

[0056] 2. Layered traversal (Breadth-First Search (BFS)): Principle: The impact of changes will permeate downwards along the path of "functional layer (F) -> electronic layer (Eo) -> electrical layer (E) -> mechanical layer (M)," and will also propagate within the same layer.

[0057] Startup: Begin BFS from the level at which the change occurred.

[0058] Same-level traversal: Within the current level, analyze the direct and indirect logical dependencies of the change point.

[0059] Lower-level traversal: Analyze the impact of changes in the current level on the next level.

[0060] Upper-level traversal (optional): In some cases, changes in the lower level can also limit the upper level (e.g., mechanical mounting space limits the size of the LRU, thus limiting the capabilities of the electronic and functional layers).

[0061] Output: A hierarchical list of affected items with parent-child relationships, clearly indicating the level (F, Eo, E, M) to which each affected item belongs.

[0062] Step 302: Calculate the direct impact scope of the change (expanded by layer) Based on the output of step 301, organize the directly affected areas by layer: 1. List of Functional Layer Impacts: Affected upstream and downstream functional modules / software components. List of changed logical interfaces, messages, and signals. Affected functional requirements and security requirements (such as DAL level).

[0063] 2. List of Electron Layer Effects: List of affected LRUs (Line Replaceable Units), LRMs (Line Replaceable Modules), and boards. Affected hardware resources include CPU load, memory usage, FPGA logic resources, and bus bandwidth. Affected electronic interfaces include changes to bus addresses and memory mapping addresses.

[0064] 3. Electrical Layer Impact List: Affected harness numbers and wire lists. Affected electrical interfaces: changes in pin assignments and signal types (e.g., from discrete to analog). Affected power loads and ground loops.

[0065] 4. List of mechanical layer impacts: Affected connectors (model, number of pins). Affected physical equipment installation layout (mounting points, brackets). Changes in weight, center of gravity, and thermal design (heat dissipation paths, cooling requirements).

[0066] Output: Four lists of direct impacts, each corresponding to one of the four levels.

[0067] Step 303: Analyze the indirect impacts and multidimensional risks of the changes (analysis by layer characteristics) For each affected project, a risk analysis was conducted based on the characteristics of its respective level, as shown in the table below:

[0068] Functional layer security risk analysis must be based on the ARP4754A system security assessment standard, DO-178C software security specification, and SAEARP4761 fault analysis guide. Through end-to-end risk identification, quantitative assessment, and closed-loop verification, it must be ensured that the changed functions meet the preset Development Assurance Level (DAL) requirements. Specific implementation steps are as follows: (1) Security analysis input preparation and scope definition Input data collection: Extract safety requirements documents (including functional safety objectives and DAL levels), four-layer interface dependency model (functional-electronic-electrical-mechanical layer relationships), ICD change dataset (functional modules and parameters affected by changes), and historical fault database (failure cases of similar functions); Boundary analysis: Define the scope of safety-critical functions (only including DAL Level C and above functions) and the full operational condition coverage list (normal flight, takeoff / landing, extreme environment).

[0069] (2) Failure Mode Identification and Propagation Path Construction FMEA analysis: Conduct failure mode traversal for each sub-module of the functional layer (instruction generation, data verification, redundancy switching, etc.), identify potential failures in the input, processing, and output stages, and record the causes of failures and their impact on downstream levels; HAZOP analysis: Identifies systematic deviations by combining "lead words + parameters" (such as "delay + command cycle" or "error + data precision") and analyzes the chain reaction of deviations on flight safety. (3) Risk Quantitative Assessment Severity (S) classification: According to the ARP4754A standard, the consequences of failure are classified into 1-10 levels (level 10 is a catastrophic consequence, such as loss of brake command leading to a crash; level 1 is a minor consequence, such as a deviation in the accuracy of non-safety signals). Occurrence (O) Quantification: Combining reliability simulation (Simulink tool) and accelerated life test data, the failure probability is divided into 1-10 levels (level 1 corresponds to ≤10). -9 Flight hours, Level 10 corresponds to ≥10 -5 / flight hours); Detectability (D) assessment: Detection capability is divided into 1-10 levels based on test coverage (Level 1 is 100% real-time detection, Level 10 is extremely difficult to detect and requires flight test verification). FTA analysis: For high-risk items with severity ≥ 8, construct a fault tree, calculate the probability of the top event (such as "complete failure of the braking system") through minimum cut sets, and verify whether the DAL level threshold is met.

[0070] (4) Risk prioritization and mitigation measure design Risk Level Classification: Based on risk priority RPN = S × O × D and the FTA top event probability, risks are divided into four levels: extremely high (RPN ≥ 100), high (50 ≤ RPN < 100), medium (20 ≤ RPN < 50), and low (RPN < 20). Among them, the DALA / B level function has a top event probability exceeding 10. -9 Flight hours should be automatically upgraded to high risk; risk mitigation strategies should be developed.

[0071] (5) Verification of mitigation measures and confirmation of closed-loop mechanism Multi-scenario verification: The effectiveness of the measures was confirmed through static code analysis (100% branch coverage), HIL bench fault injection (verifying redundancy switching time ≤100ms), extreme environment testing on the iron bird bench (-55℃ to 85℃ operating conditions), and full-aircraft test flight (short runway landing scenario). Compliance confirmation: After verification, the probability of the top event must be ≤ DAL level threshold, forming a security requirement traceability matrix (covering the entire chain of security objectives → design → measures → testing). Document output: Generate "FMEA Report", "FTA Analysis Report" and "Mitigation Measures Verification Report", and incorporate them into the configuration management system to achieve full lifecycle traceability.

[0072] The electronic layer reliability risk analysis focuses on three core risks: insufficient hardware derating, changes in mean time between failures (MTBF), and overheating. Based on the MIL-HDBK-217F aerospace component reliability standard, the DO-160G environmental adaptability specification, and the ARP4754A system reliability requirements, a closed-loop process of "stress quantification - risk assessment - measure verification" is used to ensure that the electronic components after ICD modification meet the long-term stable operation requirements of the airborne system. The specific implementation steps are as follows: (1) Analysis of input preparation and risk boundary definition Input data acquisition: 1. Electronic layer interface dependency model: Model specifications, rated parameters (rated load, rated current, rated junction temperature) and topology of core components (CPU, DC-DC power module, bus transceiver, FPGA); 2. ICD change dataset: Electrical stress parameters and thermal stress parameters before and after the change; 3. Component technical manual: Component derating curve, MTBF baseline failure rate (λ0), temperature-life factor; 4. Environmental test data: Environmental stress parameters such as vibration acceleration and humidity of the electronic compartment.

[0073] Risk boundary definition: The analysis object is clearly defined as electronic components directly related to ICD changes, and the risk types are limited to "insufficient hardware derating", "excessive MTBF change", and "overheating failure", covering the reliability impact of the entire component life cycle (design, testing, operation and maintenance).

[0074] (2) Reliability risk identification Based on the input data, the "stress comparison method" and "failure mode traversal method" are used to locate the specific manifestations of three types of risks, including the identification of insufficient hardware derating risk, the identification of MTBF change risk, and the identification of overheating failure risk.

[0075] (3) Quantitative assessment of reliability risks The "parameter calculation method" and "model simulation method" are used to quantify the three types of risks and output comparable risk indicators: Insufficient quantification of hardware de-rated data: The formula for calculating the "derating margin" of the modified component is: Derating margin = (rated parameter value - actual parameter value) / rated parameter value × 100%.

[0076] According to the MIL-HDBK-217F classification: 1. A reduction margin of ≥30% is considered acceptable; 2. A reduction margin of 15% ≤ 30% is considered slightly deficient; 3. A reduction margin of <15% is considered severely deficient.

[0077] MTBF change quantification: The steps for calculating the MTBF before and after the change based on the MIL-HDBK-217F model are as follows: 1. Consult the component datasheet to obtain the reference failure rate. ; 2. Calculate the stress correction factor (temperature coefficient) Power coefficient Current coefficient wait); 3. Calculate the actual failure rate

[0078] 4. Calculate MTBF = 1 / Compare the changes before and after the change: a change of ≤30% is acceptable; a change of 30% < change of ≤50% is slightly exceeding the standard; a change of >50% is seriously exceeding the standard.

[0079] Quantification of overheating failure: 1. Calculate "Temperature Exceedance Value" = Actual Temperature - Rated Temperature (or DO-160G Limit); 2. Based on the "10°C rule" (for every 10°C increase in temperature, the lifespan of the component is halved), the impact of overheating on lifespan is quantified.

[0080] (4) Risk Priority Ranking Based on the quantitative results, the risk level is classified according to "risk level = deviation of quantitative indicator + scope of impact", and the priority of handling is clarified: (5) Design of risk mitigation measures For extremely high / high-risk items, design technically feasible mitigation measures to ensure that aviation reliability requirements are met.

[0081] (6) Verification and closed-loop management of mitigation measures Multi-dimensional verification: 1. HIL bench verification; 2. Accelerated life testing; 3. Thermal simulation verification; 4. MTBF recalculation.

[0082] Closed-loop confirmation: 1. Verify risk indicators; 2. Output "Electron Layer Reliability Risk Analysis Report" (containing quantitative data, mitigation measures, and verification results) and "MTBF Calculation Report" (with appendix). The basis for table lookup and the process of stress coefficient calculation are incorporated into the configuration management system to achieve full-chain traceability.

[0083] Output: A risk analysis matrix organized by tiers and risk dimensions, including risk descriptions, levels, and mitigation measures.

[0084] Step 304: Analyze the cross-layer propagation path of the change and form a full-link impact diagram.

[0085] 1. Construct a cross-layer influence diagram: Starting from the change point, nodes of different colors represent entities at the functional (F), electronic (Eo), electrical (E), and mechanical (M) levels.

[0086] Connect entities with dependencies using arrows, where the direction of the arrow indicates the direction of dependency or influence.

[0087] Pay special attention to cross-layer arrows, as they represent key transitions that influence the transition from the logical world to the physical world.

[0088] 2. Mark key information: Label the entity name and its level on the node (e.g., F: Nav Algorithm, E: Flight ControlComputer).

[0089] Label the nature of dependencies on the connections (e.g., Deploys on, Connects via, Draws Power).

[0090] High-risk and critical paths (such as those affecting direct access to the mechanical layer or the highest security level) are highlighted.

[0091] 3. Analyze the propagation path: Visually trace how a simple functional change eventually leads to the need to replace connector models and wiring harnesses. Identify which paths are "amplification paths" (small logical changes triggering large physical changes) and focus on these. Output: A clear, end-to-end impact map showing how the impact propagates across the four-layer architecture.

[0092] Step 305: Generate a traceable change impact analysis report.

[0093] Step 4: Conduct change review and implementation Step 401: Organizational Change Control Board (CCB) review and decision-making; Based on the Change Impact Analysis Report, a multi-dimensional, multi-role joint review will be conducted to make a final decision on whether to implement the change, and to clarify all preconditions and follow-up matters. Output: CCB Review Decision Document.

[0094] Step 402: Develop a tiered implementation and verification plan. Break down approved changes into specific, actionable, traceable, and verifiable tasks, and strictly manage versions of all deliverables.

[0095] Step 5: Complete the change verification and confirm the effect of the change.

[0096] Step 501: Perform functional and performance tests In the most realistic possible environment, verify whether the changes accurately meet the requirements without introducing performance degradation.

[0097] Execution steps: Functional testing: Based on the updated requirements specification, execute complete forward and reverse (fault injection) test cases to verify all new features and affected old features.

[0098] Performance testing: Timing tests: Rigorously measure worst-case execution time (WCET), task scheduling cycle, bus communication latency, and jitter to ensure they remain within the required constraints.

[0099] Resource testing: Monitor and confirm that resource metrics such as CPU load, memory usage, and stack depth are within acceptable limits.

[0100] Test evidence collection: All test results must be objective and recordable as evidence for airworthiness certification.

[0101] Outputs: Functional Test Report and Performance Test Report (including raw data records).

[0102] Step 502: Perform system-level compatibility and reliability testing. The modified system, as a whole, is verified to be stable, compatible, and reliable when working in conjunction with other aircraft systems.

[0103] Execution steps: Compatibility testing: Connect the modified system with related systems (such as flight control, avionics, and power) to verify that the data interaction, electrical interfaces, and mechanical interfaces are completely correct and conflict-free.

[0104] Reliability testing (if applicable): Conduct long-term stability tests (e.g., continuous operation for 24-72 hours) and stress tests (e.g., injecting high-load data) to identify potential memory leaks, resource exhaustion, and other issues.

[0105] Environmental testing: If the change involves the electronic or mechanical layers, environmental adaptability testing (such as temperature, humidity, vibration, shock, and EMC tests according to DO-160G standards) must be carried out again or partially to prove that the change has not affected the physical reliability of the product.

[0106] Outputs: System Compatibility Test Report and Environment Test Report.

[0107] Step 503: Generate a change closure report Finally, it was confirmed that the changes had been successfully and safely implemented, and a final piece of evidence was generated that could be audited by the airworthiness authorities.

[0108] This invention also provides an airborne system ICD change system for implementing the above method, comprising: an input module for receiving ICD change requests and basic data; a processing and storage module for storing an interface dependency model and performing change identification, change impact analysis, and risk assessment operations; the processing and storage module integrates a Model-Based Systems Engineering (MBSE) modeling tool for constructing and maintaining the interface dependency model; and an output module for generating change impact reports and change closure reports. 3.3 Detailed Implementation During testing of a certain aircraft model, it was discovered that the wheel brake control required a faster control loop to improve short runway landing performance. A software change request was submitted, requesting that the transmission period of the brake control command (BrakeCommand) in the FICD be changed from 100 ms to 50 ms. See the table below.

[0110]

[0111] FICD: Parameter name, data type, unit, precision, period, range, delay time, failure mode, priority, integrity / availability requirements Step 1: Modeling work relies on the completion of the previous baseline. Step 2: Receiving and parsing change requests (Steps 201-202) Input: Change Request Form (CR-2023-BRK-001); ID: CR-2023-BRK-001; Title: Shorten the BrakeCommand signal period to 50ms to improve control response; Change Object: FP-BRK-SYS-C-001.Update_Period (signal unique identifier); Old Value: 100 ms; New Value: 50 ms; Reason for Change: Meet performance requirement PER-SRWY-001 (shorten landing distance); Associated File: FICD_Brake_System v2.5 Processing: Modify the management system to parse requests and extract key machine-readable information.

[0112] The changed entity is automatically located in the four-layer interface dependency model using the unique identifier FP-BRK-SYS-C-001. The automated tool compares the data with the database to confirm that this is an attribute modification.

[0113] The output is shown in the table below:

[0114] Step 2: Impact Analysis of Changes (Steps 301-305) Input: Modified dataset, four-layer interface dependency model (v3.0) Analysis and processing: 1. Model Traversal and Direct Impact Analysis (Steps 301-302) Functional Layer (FICD): Change Signal: BrakeCommand (FP-BRK-SYS-C-001); Key Attributes: Cycle: 100ms -> 50ms, Data Type: ARINC 429 BNR, Range: 0-100%, Failure Mode: Zeroing, Integrity: DALA; Sender Function: Brake Control Function (F-BRK-CTRL); Receiver Function: Anti-Slip Control Function (F-ASKID-CTRL) (located within the same BCU); Relationship: Deterministic relationship. BrakeCommand is the core input of the anti-slip algorithm, and its update frequency directly affects the control effect.

[0115] Electronic layer (EoICD): Sender: PARTITION_BRAKE software partition in BCU (H-BCU-001); Receiver: PARTITION_ANTI_SKID software partition in BCU (H-BCU-001); Communication mechanism: ARINC 653 port communication; Direct impacts: Task scheduling: The execution frequency of production tasks (TASK_BRAKE_CTRL) and consumer tasks (TASK_ASKID_CTRL) needs to be adjusted from 100ms to 50ms. CPU load: With the task scheduling frequency doubling, the CPU utilization of the BCU is expected to increase from 58% to 62%. Memory and ports: The message throughput of internal communication ports doubles; buffer depth needs to be checked.

[0116] Electrical Layer (EICD): No direct impact. Signals are transmitted within the BCU and do not involve changes to external electrical characteristics.

[0117] Mechanical Layer (MICD): Indirect Impact: Increased control frequency may lead to more frequent operation of the hydraulic actuator (M-HYD-ACT-BRK01), which is a non-deterministic relationship. Wear and thermal management (temperature rise) need to be monitored. Output: The list of direct impacts is shown in the table below.

[0118]

[0119] 2. Risk Analysis (Step 303) Timing Risk: Description: Doubling the task scheduling frequency within the BCU may cause critical tasks to exceed their worst-case execution time (WCET) limits, or high-priority tasks to preempt resources, leading to low-priority tasks starving. Mitigation Recommendation: Conduct a rigorous new schedule analysis to ensure all tasks still meet their time limits within a 50ms period.

[0120] Resource Risk: Description: BCU CPU utilization is expected to increase to 62%, requiring sufficient margin to cope with extreme operating conditions. Mitigation Recommendation: Set an acceptance threshold: peak CPU utilization ≤ 65%.

[0121] Performance Risk: Description: Actuator M-HYD-ACT-BRK01 may experience a temperature rise exceeding design values ​​due to high-frequency operation. Mitigation Recommendation: Conduct durability testing and monitor the temperature, requiring a stable temperature ≤ 85℃ (below the rated value of 105℃).

[0122] 3. Impact on dissemination and visualization Processing: Based on the dependency model, a full-link impact map is generated, visually demonstrating the path of change propagation from FP-BRK-SYS-C-001 to BCU task scheduling, ultimately potentially affecting actuator lifespan. Output: Change impact propagation map (visual file).

[0123] Step 4: Change Review and Decision Input: "Change Impact Analysis Report (CR-2023-BRK-001)" Outputs: Change Closed-Loop Report (CR-2023-BRK-001), updated project baseline.

[0124] This invention employs end-to-end interface dependency modeling: for the first time, a multi-dimensional interface dependency model encompassing functional, electronic, electrical, and mechanical layers is introduced into airborne system ICD change management, forming a full-link dependency tracing mechanism from system function to physical implementation. This model can simultaneously cover functional logic, hardware architecture, and physical interfaces in change analysis, achieving system-level comprehensiveness and consistency, overcoming the limitations of existing technologies that are limited to single-document or single-level analysis.

[0125] Based on the deterministic relationship change impact analysis framework, this paper proposes rules to classify interface dependencies into deterministic, non-deterministic, and no-relationship categories, and establishes corresponding evaluation criteria. This method transforms the vague qualitative judgments in traditional dependencies into measurable indicators, making the change impact assessment repeatable, comparable, and traceable, thereby improving the accuracy of the analysis results and the engineering operability.

[0126] Automated Change Identification and Difference Analysis: By comparing new and old ICD files using unique identifiers, this method can automatically identify three types of changes: additions, deletions, and attribute modifications, and generate a structured change dataset. This approach significantly improves the efficiency and accuracy of change identification, avoiding the inefficiency and errors caused by relying on manual comparison in existing methods.

[0127] A multi-dimensional change impact analysis mechanism combines an interface dependency model with a breadth-first search algorithm. This mechanism not only analyzes the direct impact of changes but also covers indirect impacts such as functional compatibility, timing conflicts, resource consumption, interface conflicts, bus bandwidth, and electromagnetic compatibility, forming a risk propagation path and a full-link impact diagram. This mechanism provides a comprehensive system-level impact assessment, enhancing the scientific and systematic nature of risk control.

[0128] A categorized ICD-specific change rule system: For four types of ICDs—Functional Interface Control Documents (FICD), Mechanical Interface Control Documents (MICD), Electrical Interface Control Documents (EICD), and Electronic Interface Control Documents (EoICD)—adaptive methods for adding, deleting, and modifying are proposed. Through differentiated strategy design, this invention enables targeted analysis and verification based on the characteristics of different interface types.

[0129] The entire closed-loop change process deeply integrates the interface dependency model into the entire change lifecycle, and builds a standardized process of "initial modeling - request analysis - impact assessment - review and implementation - verification closed loop", which ensures the standardization, systematization and traceability of the entire change process.

[0130] 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 modifying an airborne system ICD, characterized in that, Includes the following steps: Step S1: Initialize the airborne system ICD change management environment and establish an interface dependency model; Step S2: Receive the ICD change request and analyze the ICD change request to identify the ICD change type; Step S3: Invoke the interface dependency model, perform change impact analysis based on the ICD change type, and generate a change impact report; Step S4: Based on the change impact report, conduct a change review and implementation to obtain the change results; Step S5: Verify the change results and generate a change closure report.

2. The airborne system ICD modification method according to claim 1, characterized in that, Step S1 includes: Step S101: Collect and integrate basic data, extract and transform all basic data into a unified meta-model to complete unified data modeling; the basic data includes ICD documents, system architecture design specifications, function list and function allocation list; Step S102: Based on the aforementioned basic data, establish a functional interface dependency model; Step S103: Based on the basic data, establish a physical dependency model, which includes the dependencies of the electronic layer, electrical layer and mechanical layer; Step S104: Set the dependency strength quantification rules.

3. The airborne system ICD modification method according to claim 2, characterized in that, Step S102 includes: Based on system requirements, functions are decomposed to form a functional architecture tree; Based on the aforementioned functional architecture tree, analyze the input-output relationships between functions and define logical interfaces; Allocate processing resources, computing power requirements, and memory requirements for each function; Use SysML activity diagrams or sequence diagrams to describe the interaction flow between functions and generate the function interface dependency model.

4. The airborne system ICD modification method according to claim 2, characterized in that, It also includes integrating the functional interface dependency model and the physical dependency model according to the attribute association rules of each layer of the interface model to form the interface dependency model, which includes a four-layer model of functional layer, electronic layer, electrical layer and mechanical layer; the dependency strength quantification rule divides the interface dependency into deterministic relationship, non-deterministic relationship and no relationship.

5. The airborne system ICD modification method according to claim 4, characterized in that, Step S2 includes: Step S201: Receive and parse the ICD change request to obtain a structured change object; based on the unique identifier, map the change object to the interface dependency model; Step S202: Compare the old and new ICD files based on the unique identifier to identify the ICD change type, which includes addition, deletion and attribute modification; Step S203: Based on the list of changed objects, the change type, and the position of the changed objects in the interface dependency model, a change dataset is formed.

6. The airborne system ICD modification method according to claim 5, characterized in that, Step S3 includes: Step S301: Invoke the interface dependency model, and based on the change dataset, perform hierarchical and cross-level dependency traversal starting from the initial level where the change occurred to obtain a list of affected items; Step S302: Based on the list of impact items, calculate the direct impact scope of the change and generate a hierarchical list of direct impacts; Step S303: Based on the list of impact items, analyze the indirect impact and multidimensional risks of the changes, and generate a risk analysis matrix table organized by hierarchy and risk dimension; Step S304: Analyze the cross-layer propagation path of the change and form a full-link impact diagram; Step S305: Generate a traceable change impact report based on the impact item list, the direct impact list, the risk analysis matrix table, and the end-to-end impact diagram.

7. The airborne system ICD modification method according to claim 6, characterized in that, The dependency traversal in step S301 employs a breadth-first search (BFS) algorithm, a depth-first search (DFS) algorithm, or a hybrid algorithm combining BFS and DFS.

8. The airborne system ICD modification method according to claim 1, characterized in that, Differentiated change analysis methods are adopted for different types of ICDs; the types of ICDs include Functional Interface Control Document (FICD), Mechanical Interface Control Document (MICD), Electrical Interface Control Document (EICD), and Electronic Interface Control Document (EoICD).

9. An airborne ICD change system for implementing the method of any one of claims 1-8, characterized in that, include: The input module is used to receive ICD change requests and basic data; The processing and storage module is used to store the interface dependency model and perform change identification, change impact analysis, and risk assessment operations. The output module is used to generate change impact reports and change closure reports.

10. The airborne system ICD change system according to claim 9, characterized in that, The processing and storage module integrates a modeling tool based on Model Systems Engineering (MBSE) for building and maintaining the interface dependency model.

Images