Airborne system ICD expression and conversion method and system

Abstract

The invention provides an airborne system ICD expression and conversion method and system, and relates to the field of airborne systems.The airborne system ICD expression and conversion method comprises the steps that an ICD source file is recognized and analyzed, ICD data are extracted and preprocessed, and a global unique identifier is generated for each element in the ICD data; mapping the processed ICD data into unified XML (Extensible Markup Language) middleware containing static logic and dynamic logic, and storing by taking a global unique identifier as an index; according to the target format, calling a corresponding conversion engine, and converting the XML middleware into a target file in the target format; and comparing the ICD source file with the target file, verifying the integrity and consistency of the data, and outputting the verified target file. According to the method, the problems of wrong information interaction and inconsistent attributes of different expression forms of the airborne system ICD are solved, the efficient expression of the design process of the airborne system ICD and the rapid conversion of various expression forms are realized, and the research and development efficiency of the airborne system ICD is improved.

Description

Technical Field

[0001] This invention relates to the field of airborne systems and data management technology, specifically to a method and system for expressing and converting ICDs in airborne systems. Background Technology

[0002] In the development of airborne systems, the Interface Control Document (ICD) is a crucial technical document ensuring the seamless operation of various systems and devices. The ICD includes the definition, verification, data exchange, and change management of system interfaces. However, existing ICD management and conversion methods have numerous problems.

[0003] First, ICD data is typically stored in various heterogeneous formats such as Excel, Word, and ASML (Airborne Systems Modeling Language) models based on SysML, leading to inefficient collaboration and data exchange between systems. Second, conversions between different formats, such as from Excel to ASML, rely heavily on manual operation, which is cumbersome, time-consuming, and error-prone, easily resulting in information loss or errors, severely impacting subsequent system integration and testing. Furthermore, existing data representation formats, such as basic XML and Excel, are insufficient to effectively represent the dynamic logic in the system architecture, such as redundancy switching, status monitoring, and power supply constraints, limiting the accurate description and automated verification of complex airborne systems. Finally, the lack of a unified interface standard between airborne systems makes interface integration and maintenance between different systems exceptionally complex.

[0004] Existing technology (CN109063362B) discloses a model-based interface design and management system that supports electronic management of interface data and generation of ICD documents in Word, PDF, Excel, and other formats. However, its conversion format range is limited, failing to cover ASML or SysML formats, and its support for dynamic logic is insufficient. Existing technology (CN107066243B) provides a general method for parsing and packaging airborne bus interface control documents, but it focuses on message packaging of bus communication interfaces, does not involve mutual conversion between multiple formats such as XML / ASML / Word, and similarly lacks support for the expression of dynamic logic and a unified data middleware layer. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method and system for expressing and converting airborne system ICDs, which can realize the expression and conversion of airborne system ICDs such as XML expression, mutual conversion between ASML and XML, mutual conversion between XML and EXCEL, and XML to Word. It solves the problems of information interaction errors and attribute inconsistencies in different expression forms such as ASML, XML, EXCEL, and Word of airborne system ICDs, realizes efficient expression in the airborne system ICD design process, rapid conversion of various expression forms, and improves the R&D efficiency of airborne system ICDs.

[0006] This application provides the following technical solution: a method for expressing and converting an airborne system ICD, comprising: Identify and parse ICD source files, extract ICD data from the ICD source files, and perform data cleaning and standardization processing. Based on the ICD data, a globally unique identifier is generated for each ICD element in the ICD data according to the combination of system name, ICD type and ICD element characteristics; The processed ICD data is mapped to a unified XML middleware containing static and dynamic logic, and stored using the globally unique identifier as an index; wherein, the static logic maps the inherent attributes of ICD elements, and the dynamic logic expresses the complex interaction logic between elements through dedicated XML tags; Based on the target format, the corresponding conversion engine is invoked to convert the unified XML middleware into a target file of the target format; The ICD source file is compared with the target file to verify the integrity and consistency of the data, and the target file that passes the verification is output.

[0007] According to one embodiment of this application, the ICD type includes Functional Interface Control Document (FICD), Electrical Interface Control Document (EICD), Electronic Interface Control Document (EoICD), and In-device Hardware and Software Interface Control Document (IICD). The ICD element features are differentiated and combined according to the ICD type. For the Functional Interface Control Document (FICD), it includes signal direction, signal name, period, and source / receiving system. For the Electrical Interface Control Document (EICD), it includes device, connector, pin number, signal direction, and signal name. For the Electronic Interface Control Document (EoICD), it includes source / destination software, physical port, logical port, signal direction, and signal name. For the In-device Hardware / Software Interface Control Document (IICD), it includes device, configuration item, software / hardware interface, signal direction, and signal name.

[0008] According to one embodiment of this application, the dedicated XML tags for the dynamic logic include: Used to express redundant logic <redundancy>The tag must include at least the main element and the backup element; Used to express monitoring logic <monitoring>Tags, whose attributes include at least monitoring metrics and thresholds; Used to express power supply constraint logic <powerconstraint>The label must include at least the maximum and minimum voltages, and the maximum and minimum currents.

[0009] According to one embodiment of this application, after generating the globally unique identifier, the uniqueness of the globally unique identifier is verified, including: calculating the hash value of the globally unique identifier and performing conflict detection; if a conflict exists, the globally unique identifier is iteratively corrected according to a preset rule until it becomes unique.

[0010] According to one embodiment of this application, the unified XML middleware is organized using a hierarchical XML structure, which sequentially includes the globally unique identifier, the ICD system, the ICD type, a parallel static data area, and a dynamic data area.

[0011] According to one embodiment of this application, the ICD source file is compared with the target file to verify the integrity and consistency of the data, including: verifying the consistency of the number of ICD elements, the integrity of key attributes, the consistency of values, and the consistency of dynamic logic between the ICD source file and the target file; when the verification fails, the corresponding ICD elements are re-converted.

[0012] According to one embodiment of this application, the ICD source file includes an ASML model file, an Excel spreadsheet, or an XML file. According to another embodiment of this application, extracting ICD data from the ICD source file and performing data cleaning and standardization includes: performing unit and numerical conversions on the ICD data based on a pre-set unit conversion rule base; the unit conversion rule base defines the conversion relationships between different physical quantity units and converts numerical descriptions with tolerances into minimum and maximum values ​​for storage.

[0013] This application also provides an airborne system ICD expression and conversion system for implementing the above method, comprising: The source file parsing and data preprocessing module is used to identify and parse ICD source files, extract ICD data from the ICD source files, and perform data cleaning and standardization processing. A globally unique identifier generation module is used to generate a globally unique identifier for each ICD element in the ICD data based on the ICD data, according to a combination of system name, ICD type and ICD element characteristics; A dual-logic XML construction module is used to map the processed ICD data into a unified XML middleware containing static and dynamic logic, and store it using the globally unique identifier as an index. The target format adaptive generation module is used to call the corresponding conversion engine according to the target format and convert the unified XML middleware into a target file of the target format; The closed-loop verification and output module is used to compare the ICD source file with the target file, verify the integrity and consistency of the data, and output the target file that has passed the verification.

[0014] According to one embodiment of this application, the system adopts a three-layer architecture of application layer, logic layer and data layer; the logic layer includes the source file parsing and data preprocessing module, the globally unique identifier generation module, the dual logic XML construction module, the target format adaptive generation module and the closed-loop verification and output module; each module performs data transmission and state synchronization through a task bus.

[0015] Compared with the prior art, the beneficial effects that can be achieved by the above-mentioned at least one technical solution adopted in the embodiments of this specification include at least the following: the embodiments of this invention realize the unified expression of various ICDs of airborne systems through XML, solving the problem that traditional formats (such as scattered documents and tables) are difficult to manage in a unified manner; through conversion with ASML, EXCEL and Word, the needs of modeling analysis (ASML), manual editing (EXCEL) and formal delivery (Word) are taken into account, thereby improving the management efficiency and consistency of airborne system ICDs. 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 schematic diagram of the expression and conversion method of the airborne system ICD of the present invention; Figure 2 This is a schematic flowchart of an airborne system ICD expression and conversion method 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 involved in the embodiments of this invention are defined as follows: ICD (Interface Control Document): A specification that describes the interfaces between systems.

[0021] FICD (Functional Interface Control Document): Functional Interface Control Document EICD (Electrical Interface Control Document): Electrical Interface Control Document EoICD (Electronic Interface Control Document): Electronic Interface Control Document IICD (Internal Interface Control Document): Internal hardware and software interface of a device. AFDX (Avionics Full-Duplex Switched Ethernet): Avionics Full-Duplex Switched Ethernet XML (eXtensible Markup Language): An extensible markup language widely used to describe data structures, especially suitable for the standardized expression of documents and information.

[0022] ICDFullName: A unique identifier, in the format [system][ICD type][element].

[0023] EA (Enterprise Architect): One of the commonly used tools for parsing and editing SysML models. ASML (Airborne Systems Modeling Language): An airborne systems modeling language based on SysML (Systems Modeling Language), primarily used to describe the architecture and interfaces of complex airborne systems.

[0024] like Figure 1 As shown, this embodiment of the invention provides a method for expressing and converting an airborne system ICD, including: S101. Identify and parse the ICD source file, extract ICD data from the ICD source file, and perform data cleaning and standardization processing; S102. Based on the ICD data, generate a globally unique identifier for each ICD element in the ICD data according to the combination of system name, ICD type and ICD element characteristics; S103. The processed ICD data is mapped to a unified XML middleware containing static and dynamic logic, and stored using the globally unique identifier as an index; wherein, the static logic maps the inherent attributes of ICD elements, and the dynamic logic expresses the complex interaction logic between elements through dedicated XML tags; S104. Based on the target format, call the corresponding conversion engine to convert the unified XML middleware into a target file of the target format; S105. Compare the ICD source file with the target file to verify the integrity and consistency of the data, and output the target file that has passed the verification.

[0025] In some embodiments, a method for representing and converting ICD data in an airborne system enables the processing and multi-format conversion of multi-source ICD data, such as... Figure 2 As shown, it includes the following steps: 1. Source File Parsing and Data Preprocessing: Identify source file formats such as ASML / Excel / XML, extract ICD data, and clean it (unit standardization, numerical conversion). Specifically, this includes: performing unit and numerical conversions on the ICD data based on a pre-defined unit conversion rule library; the unit conversion rule library defines the conversion relationships between different physical quantity units and converts numerical descriptions with tolerances into minimum and maximum values ​​for storage.

[0026] 2. Generate a unique ICDFullName identifier: Generate a globally unique identifier based on dimensions such as ICD type. The ICDFullName generation rule is: system (e.g., high lift system) + ICD type (FICD, EICD, EoICD, IICD) + element; For FICD, the elements include signal direction, signal name, period, and source / receiving system; For EICD, the elements include device, connector, pin number, signal direction, and signal name; For EoICD, the elements include the source / destination software, physical port, logical port, signal direction, and signal name; For IICD, the element display includes device, configuration items, software / hardware interface, signal direction, and signal name.

[0027] 3. Construct static / dynamic dual-logic XML: Static logical XML mapping: Maps elements and attributes to standardized XML tags.

[0028] Dynamic logic XML mapping: Maps relationships (including complex logic) to XML tags, and uses dedicated XML tags to express complex logic. redundancy <redundancy>Including Primary, Backup, etc.; monitor <monitoring>This includes metrics, thresholds, etc. Power supply constraints <powerconstraint>This includes maxVoltage (maximum voltage), minVoltage (minimum voltage), maxCurrent (maximum current), and minCurrent (minimum current).

[0029] Build a unified XML middleware: integrate static / dynamic data to generate a hierarchical XML structure, and store it using ICDFullName as the index.

[0030] 4. Adaptive generation of target format Automatic conversion selection: The corresponding conversion engine is called based on the target format (ASML / XML / Excel / Word).

[0031] Target file generation: Excel: Design table headers according to ICD dimensions, and populate data and version history; Word: Automatically fill templates and generate standardized documents; ASML: Map to ASML blocks and state machine diagrams; XML: Directly output middleware structure.

[0032] 5. Closed-Loop Verification and Output: Compare the ICD source file with the target file to verify the integrity and consistency of the data, including: verifying the consistency of the number of ICD elements, the integrity of key attributes, numerical consistency, and dynamic logic consistency between the ICD source file and the target file; when verification fails, the corresponding ICD elements are re-converted. Generate a difference report and output ASML, XML, Excel, and Word files.

[0033] This embodiment also provides an airborne system ICD expression and conversion system for implementing the above method, including: a source file parsing and data preprocessing module (module 1), a globally unique identifier generation module (module 2), a dual logic XML construction module (module 3), a target format adaptive generation module (module 4), and a closed-loop verification and output module (module 5).

[0034] In practice, the source file parsing and data preprocessing module is used to achieve standardized extraction and cleaning of multi-source ICD data, providing a unified data foundation for subsequent processing.

[0035] enter: Multiple source file formats: ASML model files, Excel spreadsheets, XML files, etc.; Auxiliary configuration: Unit conversion rule library (such as "mV→V" "s→ms"), data validation rules (such as numerical range, required fields).

[0036] Processing flow: a. Format recognition and parsing: ASML file parsing: Call the SysML modeling tool API (such as Enterprise Architect SDK) to extract elements such as blocks, properties, relationships, and state machine diagrams from the model and convert them into a structured dictionary; Excel file parsing: Identify the system, ICD type and elements through the table header, extract row data and map it into key-value pairs (such as "device=GNSS module" "signal direction=output"); XML file parsing: If the XML is not in the specification of this invention, locate elements, attributes and relationship nodes using XPath and convert them into intermediate data structures; Word file parsing: Extracting interface information based on document structure (such as chapter titles and tables).

[0037] b. Data cleaning and standardization: Unit standardization: Convert units according to the rule base (e.g., "5000mV" → "5V"); Numerical conversion: Convert text descriptions to numerical values ​​(e.g., "5±0.5V" → "minVoltage=4.5V,maxVoltage=5.5V"). Anomaly handling: Mark missing values ​​(e.g., "N / A") and out-of-range values ​​(e.g., voltage "31V" exceeds the standard 28V±2V), and generate a cleaning log.

[0038] Output: Standardized intermediate dataset (e.g., JSON format), including ICD type, element attributes, relationship information, etc.; data cleaning report (including a list of abnormal data and processing suggestions).

[0039] The ICDFullName generation module (the aforementioned globally unique identifier generation module) of the airborne system ICD is used to generate a globally unique ICDFullName for all ICD elements, serving as an index key for cross-format conversion.

[0040] Input: Standardized intermediate dataset (from Module 1); naming rules configuration (system hierarchy, element separator, etc.).

[0041] Processing flow: a. Dimensional decomposition: Extract three core dimensions from the intermediate dataset: "System Name", "ICD Type", and "Element Features"; b. Hierarchical naming generation: Basic format: [System Name].[ICD Type].[Element Feature Combination], where element features are combined differently according to ICD type: FICD: Signal Direction. Signal Name. Period. Source / Receiving System; Example: High Lift System.FICD. Output. Flap Position Signal. 100ms. Main Flight Control System; EICD: Device. Connector. Pin Number. Signal Direction. Signal Name; Example: Communication System. EICD. VHF Radio. J3.B-1. Output. Modulated Signal; EoICD: Source / Destination Software.Physical Port.Logical Port.Signal Direction.Signal Name; Example: Navigation System.EoICD.GNSS Driver.COM1.PORT2.Input.Latitude and Longitude Data; IICD: Device. Configuration Item. Software Interface / Hardware Interface. Signal Direction. Signal Name; Example: Main Flight Control System. IICD. FCU Module. Processing Software. Software Interface. Input. Attitude Angle Command.

[0042] c. Uniqueness check: Duplicate ICDFullName is detected by a duplicate detection algorithm (such as a hash algorithm). If a conflict is found, a serial number is added to the signal name (such as signal 2).

[0043] Output: Enhanced intermediate dataset with ICDFullName (each element is associated with a unique identifier); naming conflict report (including conflicting elements and their resolution).

[0044] The static / dynamic dual-logic XML building block (Module 3) of the airborne system ICD is used to convert enhanced intermediate datasets into standardized XML middleware containing static attributes and dynamic logic.

[0045] Input: Enhanced intermediate dataset with ICDFullName (from Module 2); XML tag mapping rules (static / dynamic tag definitions).

[0046] Processing flow: a. Static logical XML mapping: For FICD, the element should include signal direction, signal name, cycle, etc., and the attribute is the specific value of the element.

[0047] For EICD, the element should include Equipment, Connector, Pin number, signal direction, signal name, etc., and the attribute is the specific value of the element.

[0048] For EoICD, the element should include PhysicalPort, LogicalPort, signal direction, signal name, etc., and the attribute is the specific value of the element.

[0049] For IICD, elements should include device, configuration item, software interface / hardware interface, signal direction, signal name, etc., and attributes are the specific values ​​of the element.

[0050] Static data mapping focuses on the "inherent attributes" of ICDs (elements / attributes without interactive logic), and completes the transformation by "field extraction → type mapping". 1. Extract the fields related to the "static attributes" from the "enhanced intermediate dataset with ICDFullName" output from Module 2. 2. Based on the element definitions of each ICD type, differentiate the mapping of fields to XML tags / attributes. The table below uses FICD as an example to illustrate the mapping process.

[0051]

[0052] b. Dynamic logical XML mapping: Basic Relationship Tags <relation>: Describes the relationships between elements, including Source, Target, and relationships (such as "data flow"); Special tags for complex logic: Redundancy logic, such as Primary="Name1" Backup="Name2" SwitchCondition="Fault duration 300ms" Monitoring logic, such as Metric="Voltage" Monitored="Name3" Threshold=">12.5V" Alarm="Audible and visual alarm" Power constraint logic PowerConstraint, such as MaxVoltage="28V" MinVoltage="26V" Dynamic data mapping focuses on the "interaction logic" of ICD (including relationships, redundancy, monitoring, etc.), and completes the transformation by "field extraction → type mapping". 1. Extract the fields related to "dynamic attributes" from the "enhanced intermediate dataset with ICDFullName" output by Module 2. 2. Map the extracted dynamic fields to dedicated XML tags to ensure the integrity of logical semantics. The following table uses power supply constraints as an example to illustrate the mapping process.

[0053]

[0054] c. Unified XML middleware construction: Hierarchical structure: <icdfullname>ICD unique identifier → <icdsystem>ICD system → <icdtype>ICD type → <staticdata>Static information + <dynamicdata>Dynamic Information → <element>element / <relation>relation; Index optimization: A global index table is created for ICDFullName to accelerate tag location during subsequent conversions.

[0055] An example of an XML hierarchical structure is shown below: <icdfullname> <icdsystem> <icdtype> <staticdata> <element / > < / staticdata> <dynamicdata> <relation / > < / dynamicdata> < / icdtype> < / icdsystem> < / icdfullname> Output: A complete XML middleware file (.xml); an XML validation report (including tag integrity and logical consistency check results).

[0056] The target format adaptive generation module (module four) of the airborne system ICD is used to automatically call the conversion engine according to user needs and convert the XML middleware into the target format.

[0057] Input: XML middleware file (from Module 3); target format parameter (user-specified: ASML / Excel / Word / XML); format template (such as Word document template, Excel header template).

[0058] Processing flow: a. Conversion Engine Selection: Activate the corresponding engine based on the target format: Excel engine (e.g., based on the Apache POI library), Word engine (e.g., based on the python-docx library), ASML engine (e.g., based on the SysML modeling tool API), XML engine (directly reuse middleware). b. Target file generation: Excel format: Divide into tables by ICD type (e.g., "FICD Interface Table" "EICD Interface Table"); Header design: ICDFullName + ICDSystem + static attribute columns (name, attributes, etc.) + dynamic logical columns (relationships, redundant conditions, etc.); Additional information: Record the conversion time and source file version in the "Version History" table.

[0059] Word format: Apply template: follow the chapter structure of "1. Overview → 2. FICD (ICDFullName + ICDSystem + Static Logical Attributes + Dynamic Logical Attributes) → 3. EICD → 4. EoICD → 5. IICD"; Content population: Static and dynamic logical information are presented in a three-line table; Standardized format: Apply standard aviation document styles (font, page numbers, headers).

[0060] ASML format: Static data mapping: <element>→ASML block. <attribute>→Block attributes; Dynamic logical mapping: <redundancy>→State machine diagram (including primary and backup state nodes and switching condition edges). <relation>→ Inter-block connection lines; XML format: Directly output formatted XML middleware (such as indentation and comment optimization).

[0061] Output: Target format file (ASML / Excel / Word / XML); Transformation log (records engine calls and data mapping details).

[0062] The closed-loop verification and output module (module five) of the airborne system ICD is used to verify the consistency and integrity of the data before and after the conversion, and finally output a qualified document.

[0063] Input: source file (raw input), target format file (from module 4), XML middleware; validation rule base (completeness, consistency, format specification).

[0064] Processing Flow: a. Integrity Verification: Compare the number of ICDs in the source file and the target file (e.g., if the source file has 100 ICDs, the target file should contain 100 ICDFullNames); check for missing key attributes (e.g., ICDFullName, signal direction, data type); b. Consistency Verification: Numerical Consistency: Compare the numerical values ​​in the source file and the target file (e.g., whether the voltage "28V" is consistent); Logical Consistency: Check whether dynamic logic (e.g., redundancy switching conditions) is completely converted (e.g., whether "fault duration 300ms" is accurately presented). c. Format Specification Verification: Check whether the target file conforms to the specification standards (e.g., whether the Excel header is complete). d. Result Processing and Output: Generate a difference report: list missing elements, inconsistent values, and format errors (e.g., "3 items are missing from the 'Pinhole Number' column in the EICD table"). Output of qualified files: Store the verified target files to the specified path (batch naming is supported, such as "Xml to Excel_20250818.xlsx"); Error handling: If verification fails, trigger module four to re-convert (for erroneous items).

[0065] Output: Validated target format file (ASML / Excel / Word / XML); closed-loop validation report (including pass items, difference items, and handling suggestions).

[0066] Through the collaborative work of the above five modules, the system achieves full automation of the "parsing-standardization-conversion-verification" process for multi-source ICD data, ensuring the consistency and integrity of data across different formats and significantly improving the management efficiency of airborne system ICDs.

[0067] In one embodiment, this embodiment targets the ICD management scenario of airborne systems, and refines the technical parameters, tool configurations, anomaly handling and industry adaptation details around the entire process of "multi-source data standardization - unique identifier generation - dual logic XML construction - multi-format conversion - closed-loop verification".

[0068] 1.1 Source File Parsing and Data Preprocessing This step utilizes a "format recognition engine + standardized rule base + anomaly handling mechanism" to achieve unified extraction and cleaning of multi-source ICD data. Key details are as follows: 1.1.1 Format Recognition and Parsing ASML file parsing: Use Enterprise Architect's `EA.Repository` COM API to extract data using the following steps: 1. Model Loading: Call `Repository.OpenFile("D: / Airborne ICD / ASML Model.eap")` to open the local EAP / EAPX model file. If you are concerned that a large model may cause blocking, you should implement a timeout mechanism at the call layer (e.g., call it in a separate thread / task and stop or log the error after the timeout).

[0069] 2. Block Extraction: Traverse the "Airborne System ICD Model" package and its sub-packages under `Repository.Models`, and extract `Element.Name` (device / interface name), `Element.Note` (description), and `Element.TaggedValues` (attributes) using `Element.Stereotype.ToLower() == "block"`. 3. Relation Extraction: Iterate through `Repository.Connectors`, filter `Connector.Type == "Association"` (association relationship), map `Connector.SourceID` / `Connector.TargetID` to the `Element.ElementID` of the source / target block, map `Connector.Name` to the relationship type (such as "data flow direction"), and map `Connector.Notes` to the relationship description.

[0070] Excel file parsing: Refine field mapping rules by matching ICD types using table header features:

[0071] XML file parsing: For XML that is not in the specification of this invention (such as traditional ICD's `<?xml version="1.0" encoding="GBK"?> `), through lxml's `etree` parsing, refine the XPath path and encoding processing: 1. File reading and encoding conversion: Identify the statement: Read the file header<?xml version="1.0" encoding="..."> Confirm the code.

[0072] If the original XML is GBK encoded, use `etree.parse(file, parser=etree.XMLParser(encoding='gbk'))` to avoid garbled characters; Field extraction: Static information mapping <equipment>→Equipment, <pin>→Pinhole number; <input> / <output>→ Input and output signals, <cycle>→ Signal period; <source> / <target>→ Source / Destination <port>→ Logical / physical ports; <connector>→ Connector <signal>→ signal name Dynamic logic mapping: ` / / ICD / Dynamic / Redundancy / Primary` → mapped to "Primary Name", ` / / ICD / Dynamic / Redundancy / SwitchCondition` → mapped to "Switch Condition"; 1.1.2 Data Cleaning and Standardization Unit conversion rule base:

[0073] Numerical conversion and exception handling: 1. Range description conversion: "Voltage 5±0.5V" → split into "minVoltage=4.5V" and "maxVoltage=5.5V", and stored in the "min_value" / "max_value" fields of the "attribute" table; 2. Enumeration value normalization: "Signal direction: in" → mapped to "input", "Signal direction: out" → mapped to "output"; 3. Outlier detection: If the voltage is abnormal: if "voltage = 31V", check the standard (28V±2V), determine it as "overvoltage 1V", mark `is_abnormal=1`, and `abnormal_reason`="exceeds the 28V±2V standard"; Output of this step: Standardized intermediate dataset (XML standard middleware, including `data_id` (unique identifier), `system_name`, `icd_type`, `elements` (element dictionary), and `attributes` (attribute dictionary)); Data cleaning report (e.g., Markdown format, including abnormal data `data_id`, abnormal type, and handling method; example: `data_id=1001, abnormal type=voltage overvoltage, handling method=marked for manual confirmation`).

[0074] 1.2 Generate a unique ICDFullName identifier This step, based on "three-dimensional hierarchical naming + validation + conflict iteration handling," generates a globally unique ICDFullName, detailed as follows: 1.2.1 Dimension Decomposition and Naming Rules Extract `system_name` (system name), `icd_type` (ICD type), and `elements` (element features) from the standardized intermediate dataset, and determine the element combination order according to ICD type (priority: core identifier → functional attribute → associated information):

[0075] Naming format constraints: Separator: Use "". uniformly and prohibit special characters (such as "_" or "-" to avoid XML tag parsing errors); Length limit: ≤128 characters (complies with XML attribute length specifications to avoid database field overflow); Case sensitivity: The first letter of the system name and ICD type should be capitalized (e.g., "High Lift System" or "FICD"), and the rest should be lowercase (e.g., "Output" or "100ms").

[0076] 1.2.2 Uniqueness Verification and Conflict Handling 1. Uniqueness check: For the generated ICDFullName, calculate the hash value, use the hash value as the Redis `Key`, and use the ICDFullName as the `Value`, and set the expiration time to 72 hours (covering the entire conversion process). Batch verification: For multiple ICDFullName entries, use Redis's `MGET` function to batch query the hash value. If a `Key` exists, it is considered a conflict.

[0077] 2. Conflict resolution: If a conflict is detected (e.g., "Communication System.EICD.VHF Radio.J3.B-1.Output.Modulation Signal" already exists), iterative correction is performed according to the following rules:

[0078] 3. Conflict report generation: Record the conflicting `data_id`, the original ICDFullName, the conflict hash value, and the corrected ICDFullName.

[0079] This step outputs: an enhanced intermediate dataset (with a new `icd_fullname` field, associated with `data_id`); and a naming conflict report (in Excel format, including conflict details and resolution results).

[0080] 1.3 Constructing Static / Dynamic Dual-Logic XML This step, based on the XML Schema (XSD) specification, implements a structured XML construction based on "static elements - dynamic logic - index optimization," refining XSD constraints and tag mapping rules: 1.3.1 Static Logical XML Mapping First, define `icd_schema.xsd` (full constraint). Static logic focuses on the inherent attributes of the ICD (such as device, period, etc.) and maps them according to the "ICDFullName→ICDSystem→ICDType→StaticData→Element" hierarchy, specifying the element type, required fields, and format restrictions.

[0081] 1.3.2 Dynamic Logical XML Mapping Dynamic logic focuses on the interaction relationships and complex logic of ICDs (such as data flow and redundancy switching).

[0082] Relation tag: The source / target must be an existing ICDFullName, verified via a Redis query. Example: ` <relation source="通信系统.EICD.VHF电台.J3.B-1.输出.调制信号" target="通信系统.EICD.发射天线.J1.A-3.输入.射频信号" type="数据流向" description="调制信号经电缆传输至天线" / > `; The redundancy tag `primary` and `backup` must be of the same ICD type (e.g., both are EICD). If the primary element is FICD and the backup element is EICD, the exception "Primary and backup elements have inconsistent ICD types" will be triggered. Monitoring tag: `threshold` must contain a comparison operator (e.g., ">28V""≤5s"), and pass regular expression validation. If it is "28V" (missing comparison operator), add the default comparison operator "≥" (requires manual confirmation). The PowerConstraint tag states that `maxVoltage` must be greater than `minVoltage`. If `maxVoltage=26V` and `minVoltage=28V`, the exception "Maximum voltage is less than minimum voltage" will be triggered.

[0083] 1.3.3 Unified XML Middleware Construction Based on the static mapping in 1.3.1 and the dynamic mapping in 1.3.2, the complete XML middleware is assembled according to the "ICDFullName→ICDSystem→ICDType→StaticData / DynamicData" hierarchy, while the index is optimized to improve the efficiency of subsequent transformations.

[0084] 1.3.3.2 Index Optimization (Improving Subsequent Conversion Efficiency) To accelerate tag location during target format conversion, an ICDFullName-XML node mapping table is generated and stored in Redis or an XML index file.

[0085] This mapping table allows the subsequent transformation engine to directly locate the target node, avoiding a full traversal of the XML and improving processing efficiency.

[0086] 1.3.4 XML Validation and Output Verify structural integrity and logical consistency based on the revised XSD specification.

[0087]

[0088] This step outputs: an XML middleware file conforming to the XSD specification (`.xml`, containing `xsi` references, supporting automatic validation); an XML validation report (including validation tools (such as XMLSpy 2025), validation results (pass / fail), and error location (such as "Row 15, Column 20: pinNumber format error")).

[0089] 1.4 Adaptive Generation of Target Format This step involves using a dedicated engine to generate files based on the target format, and refining tool parameters and format specifications.

[0090] 1.4.1 Conversion Engine Configuration 1.4.2 Generation of target files in various formats, including Excel, Word, ASML, and XML.

[0091] 1.5 Closed-loop verification and output This step ensures data consistency through "triple verification + anomaly iteration handling" and refines verification items, tools, and report templates.

[0092] Abnormal iteration handling: If there are inconsistencies (such as "power field 25W→24W"), trigger the "target format generation module" to reconvert the ICDFullName corresponding to the `data_id` and re-verify until consistency is achieved; If there are format errors (such as Excel cell type errors), automatically repair (such as changing text type to numeric type via `openpyxl`) or prompt for manual repair, and regenerate the file after repair.

[0093] Final output: Validated target format file (storage path: ` / Airborne ICD / Validated / 20250818 / `, filename includes "Validated", such as `Airborne ICD_FICD_20250818_Validated.xlsx`); closed-loop validation report (e.g., PDF format, including electronic signature field, for archiving); exception handling log.

[0094] The airborne ICD representation and conversion system in this embodiment is based on "modular deep decoupling + full-link data traceability + scenario-based adaptation". It refines component responsibilities, data interaction formats, anomaly handling strategies, and performance optimization schemes to ensure that each module can independently complete its specific task while also efficiently collaborating through standardized interfaces. Ultimately, it achieves automated and highly reliable processing of multi-source ICD data "from input to output". The system adopts a three-layer architecture of "application layer - logic layer - data layer". Each layer further decomposes into sub-components, clearly defining responsibilities and boundaries. Simultaneously, a "task bus" enables cross-layer data flow and status synchronization. The logic layer includes the system's five core functional modules (parsing and preprocessing, unique identifier generation, dual-logic XML construction, target format conversion, and closed-loop verification).

[0095] The collaboration and data flow between modules in this system (detailed interaction details) are illustrated using "EICD source file → Excel target file" as an example, detailing the entire collaboration process: 1. Task Startup: Users upload the EICD Excel source file via the web interface, select the target format "Excel", and click "Submit". The task scheduling center generates `TaskID=ICD-Task-123e4567-e89b-12d3-a456-426614174000-20250820`, sets the status code to `00-Pending`, and pushes the task information to the "Source File Parsing Module".

[0096] 2. Parsing Preprocessing (Module 1 → Module 2): After Module 1 completes parsing, it generates standardized data (including `DataID=EICD-008`) and updates the status code to `10-Parsing Complete`. Data is pushed to Module 2 via an HTTP POST request. The request body contains `TaskID` and standardized JSON data. After Module 2 receives the data, the status code is updated to `20 - Identifier Generating`.

[0097] 3. Unique Identifier Generation (Module 2 → Module 3): Module 2 generates ICDFullName, and the status code is updated to `21 - indicating generation complete`. The enhanced data (including `ICDFullName`) is stored in the intermediate database. Module 3 retrieves the data from the database using `TaskID`, and the status code is updated to `30 - XML ​​building`.

[0098] 4. XML Construction (Module 3 → Module 4): Module 3 generates the XML middleware and passes validation; the status code is updated to `31 - XML ​​construction complete`. The XML file path (e.g., ` / XML / 20250820 / ICD-Task-xxx.xml`) is pushed to Module 4. After Module 4 receives it, the status code is updated to `40-Format conversion in progress`.

[0099] 5. Format Conversion (Module 4 → Module 5): Module 4 generates an Excel target file, and the status code is updated to `41-Format conversion complete`. The path to the Excel file is pushed to Module 5. After Module 5 receives it, the status code is updated to `50-Verification in progress`.

[0100] 6. Closed-loop verification and output (Module 5 → User): Module 5 verification passed, status code updated to `99-Verification passed`; Generate a PDF version of the discrepancy report, push the Excel file and report to the user via the web, and archive them to a file repository.

[0101] Example of abnormal collaboration: If the XML validation of Module 3 finds an error of "voltage=31V", the status code is set to `32-XML build failed`. The task scheduling center sends an alarm email to the user (including error details). After the user reviews and corrects it to "27V", Module 3 is triggered to rebuild the XML, and the process continues.

[0102] This system achieves fully automated, highly reliable, and scenario-based processing of airborne ICD data by refining module components, processing flows, and data interaction. Each module focuses on specific capabilities (such as parsing, identification, and modeling) and collaborates through standardized interfaces, solving the pain points of traditional manual processing such as "inconsistent formats, easy data loss, and low efficiency." It can directly adapt to the ICD management needs of airborne systems and provide full-process technical support for interface design, verification, and delivery.

[0103] 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.< / signal> < / connector> < / port> < / target> < / cycle> < / output> < / pin> < / equipment> < / relation> < / redundancy> < / attribute> < / element> < / relation> < / element> < / dynamicdata> < / staticdata> < / icdtype> < / icdsystem> < / icdfullname> < / relation> < / powerconstraint> < / monitoring> < / redundancy> < / powerconstraint> < / monitoring> < / redundancy>

Claims

1. An expression and translation method of an airborne system ICD, characterized by, The method comprises: identifying and parsing an ICD source file, extracting ICD data from the ICD source file and performing data cleaning and standardization; based on the ICD data, generating a globally unique identifier for each ICD element in the ICD data according to the combination of system name, ICD type and ICD element characteristics; mapping the processed ICD data into a unified XML intermediate product containing static logic and dynamic logic, and storing it with the globally unique identifier as an index; wherein the static logic maps the inherent attributes of the ICD elements, and the dynamic logic expresses the complex interaction logic between elements through special XML tags; according to the target format, calling the corresponding conversion engine to convert the unified XML intermediate product into a target file in the target format; comparing the ICD source file with the target file to verify the integrity and consistency of the data, and outputting the target file that passes the verification.

2. The method for expressing and converting an airborne system ICD according to claim 1, wherein the ICD types include functional interface control document (FICD), electrical interface control document (EICD), electronic interface control document (EoICD) and in-device software and hardware interface control document (IICD); the ICD element characteristics are combined differently according to the ICD types, including signal direction, signal name, period and source / receiving system for the FICD, device, connector, pin number, signal direction and signal name for the EICD, source / destination software, physical port, logical port, signal direction and signal name for the EoICD, and device, configuration item, software interface / hardware interface, signal direction and signal name for the IICD.

3. The method of expression and translation of airborne system ICDs of claim 1, wherein, the special XML tags of the dynamic logic include: For expressing redundant logic <redundancy>tags whose attributes at least include main elements and backup elements;< / redundancy> For expressing monitoring logic <monitoring>tags whose attributes at least include monitoring indicators and thresholds;< / monitoring> For expressing power constraint logic <powerconstraint>tags whose attributes at least include maximum voltage and minimum voltage, maximum current and minimum current.< / powerconstraint> 4. The method of expression and translation of airborne system ICDs of claim 1, wherein, After generating the globally unique identifier, the uniqueness of the globally unique identifier is verified, including calculating the hash value of the globally unique identifier and performing conflict detection, and if there is a conflict, iteratively modifying the globally unique identifier according to a preset rule until it is unique.

5. The method of expression and translation of airborne system ICDs of claim 1, wherein, The unified XML intermediate product adopts a hierarchical XML structure, and its structure includes the globally unique identifier, ICD system, ICD type, parallel static data area and dynamic data area in turn.

6. The method of expression and translation of airborne system ICDs of claim 1, wherein, Comparing the ICD source file with the target file to verify the integrity and consistency of the data includes verifying the ICD element quantity consistency, key attribute integrity, numerical consistency and dynamic logic consistency of the ICD source file and the target file; when the verification fails, the corresponding ICD elements are re-converted.

7. The method of expression and translation of airborne system ICDs of claim 1, wherein, The ICD source file includes an ASML model file, an Excel table or an XML file.

8. The method of expression and translation of airborne system ICDs of claim 1, wherein, ICD data in the ICD source file is extracted and data cleaning and standardization processing is performed, including: performing unit conversion and numerical conversion on the ICD data based on a preset unit conversion rule library; the unit conversion rule library defines conversion relationships of different physical quantity units, and converts a numerical description with a tolerance into minimum and maximum values for storage.

9. An airborne system ICD expression and translation system implementing the method of any of claims 1 to 8, characterized by, Comprise: a source file analysis and data preprocessing module, configured to identify and analyze ICD source files, extract ICD data in the ICD source files, and perform data cleaning and standardization processing; a globally unique identifier generation module, configured to generate a globally unique identifier for each ICD element in the ICD data based on the ICD data, according to a combination of system names, ICD types, and ICD element characteristics; a dual-logic XML construction module, configured to map the processed ICD data into a unified XML intermediate product containing static logic and dynamic logic, and store the unified XML intermediate product with the globally unique identifier as an index; a target format adaptive generation module, configured to convert the unified XML intermediate product into a target file in a target format according to the target format by calling a corresponding conversion engine; a closed-loop verification and output module, configured to compare the ICD source file with the target file, verify the completeness and consistency of the data, and output a target file that passes the verification.

10. The airborne system ICD expression and translation system of claim 9, wherein, The system adopts a three-layer architecture of an application layer, a logic layer, and a data layer; the logic layer includes the source file analysis and data preprocessing module, the globally unique identifier generation module, the dual-logic XML construction module, the target format adaptive generation module, and the closed-loop verification and output module; each module performs data transmission and state synchronization through a task bus.

Images