Model-based ICD management method, system, equipment and medium

Abstract

The invention provides an ICD management method, system and device based on a model and a medium, and relates to the field of interface management, and the method comprises the steps: extracting and defining a function interface, a physical interface, a relation interface, an energy interface and a message interface based on a demand-driven RFLP architecture model; the method comprises the following steps: defining an airborne system modeling language ASML, integrating the ASML into a modeling tool, constructing a system architecture interface model, introducing meta-models into interfaces of different hierarchies as a core framework, and creating an interface definition template; based on the meta-model and a pre-constructed ICD data dictionary, defining an interface verification rule, and monitoring and verifying interface data; and performing version control on the model-based ICD management process, generating and updating a baseline version at a project milestone node, and outputting an ICD document in a standard format. According to the method, the standardization level, design efficiency and quality of airborne system ICD design are improved, and technical guarantee is provided for standardized design and management and control of complex system interfaces.

Description

Technical Field

[0001] This invention relates to the field of complex system design and interface management technology, specifically to a model-based ICD management method, system, device, and medium. Background Technology

[0002] In complex systems fields such as aerospace, automotive, and communications, Interface Control Document (ICD) management is a critical aspect of system design. Traditional ICD management relies on manually written technical documents and data tables. However, with the continuous expansion of system scale, increasing complexity, and the deepening and breadth of team collaboration, the drawbacks of this traditional model become increasingly apparent. Firstly, the timely updating and transmission of text documents leads to inconsistencies in ICD information used by different design and development teams when system requirements change or interface designs are adjusted, due to the lack of an effective synchronization mechanism. Secondly, text-based ICDs have poor comprehensibility. Faced with numerous complex descriptions of interface names, attribute parameters, and signal flows, personnel with different professional backgrounds may have differing understandings, easily leading to ambiguity during interface consistency checks. Furthermore, traditional ICD management struggles to visually represent interface relationships and interaction flows. Developers cannot quickly and clearly understand the upstream and downstream relationships between interfaces of various system components, hindering cross-departmental communication, collaboration, and change analysis, severely restricting efficient project progress and quality assurance.

[0003] To address the above issues, model-based management methods have emerged. Existing technology (CN112784434B) discloses a model-based avionics design method; however, this method has limitations in its data interface storage format. When dealing with large-scale, complex systems, the query speed and data update frequency cannot meet the demands for efficient data interaction. Furthermore, this technology uses a top-down hierarchical design to define and generate interfaces. When upper-level interfaces are modified, lower-level interface files typically need to be manually updated, easily leading to data asynchrony or inconsistency between levels. Additionally, it suffers from insufficient tool integration, difficulties in cross-platform collaboration, and a lack of robust version control and change tracking. The prior art (CN104992022A) discloses a model-based interface management method for avionics systems. This method is instance- and template-oriented, focusing more on structured data management. It lacks a meta-model for unified abstraction and constraints on various levels, data types, and rules. Furthermore, since template and rule configurations are relatively independent, the dependencies between levels rely more on manual configuration and template conventions, making it difficult to automatically deduce or verify the consistency of cross-layer data flows and achieve global consistency checks. In addition, the data monitoring capabilities of this method are limited, making it impossible to continuously verify whether the data flow conforms to design constraints during the design process.

[0004] Therefore, although model-based methods have been proposed in existing technologies, problems still exist, such as low storage and query efficiency, asynchronous updates across levels, insufficient tool integration, lack of a unified framework driven by meta-models, and lack of dynamic data monitoring capabilities. Summary of the Invention

[0005] In view of this, embodiments of this application provide a model-based ICD management method and system to solve problems such as fragmented requirement descriptions, insufficient adaptability of modeling languages, low reusability of interface designs, difficulty in ensuring data compliance, and disordered version control in the design process of airborne system ICDs. This improves the standardization level, design efficiency and quality of airborne system ICD design, reduces interface collaborative design conflicts and life-cycle maintenance costs, and provides technical support for the standardized design and management of complex system interfaces.

[0006] This application provides the following technical solution: a model-based ICD management method, comprising: Based on the demand-driven RFLP architecture model, functional interfaces, physical interfaces, relational interfaces, energy interfaces, and message interfaces are extracted and defined to standardize the description of system requirements, equipment requirements, and hardware and software requirements. Define an airborne system modeling language ASML, which is formed by extending the metamodel of the system modeling language SysML; integrate ASML into modeling tools to build an airborne system architecture modeling platform; Based on the airborne system architecture modeling platform, a system architecture interface model is constructed. A meta-model is introduced as the core framework in the interfaces at different levels. Based on the meta-model, an interface definition template is created. Based on the meta-model and the pre-built ICD data dictionary, interface verification rules are defined; during the template instantiation process using the interface definition template, the interface data is monitored and verified according to the interface verification rules. Through the model update mechanism, the updated meta-model data and structural information are integrated into the knowledge base module of the airborne system architecture modeling platform; Version control is implemented for the model-based ICD management process. Baseline versions are generated and updated at project milestone nodes, ICD documents in standard format are output, and historical changes between different baseline versions are recorded.

[0007] This application also provides a model-based ICD management system, including: The interface definition module is used to extract and define functional interfaces, physical interfaces, relational interfaces, energy interfaces, and message interfaces based on the requirement-driven RFLP architecture model, and to provide standardized descriptions of system requirements, equipment requirements, and hardware and software requirements. The modeling platform module is used to define the airborne system modeling language ASML, which is formed by extending the metamodel of the system modeling language SysML; and to integrate ASML into the modeling tools to build an airborne system architecture modeling platform. The metamodel and template module is used to construct a system architecture interface model based on the airborne system architecture modeling platform, introduce the metamodel as the core framework in interfaces at different levels, and create interface definition templates based on the metamodel. The verification module is used to define interface verification rules based on the meta-model and the pre-built ICD data dictionary; during the template instantiation process using the interface definition template, the interface data is monitored and verified according to the interface verification rules. The update and storage module integrates the updated meta-model data and structural information into the knowledge base module of the airborne system architecture modeling platform through the model update mechanism. The version control and output module is used to perform version control on the model-based ICD management process, generate and update baseline versions at project milestone nodes, output standard format ICD documents, and record historical changes between different baseline versions.

[0008] This application also provides a computing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the model-based ICD management method described above.

[0009] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the model-based ICD management method described above.

[0010] Compared with the prior art, the beneficial effects that at least one technical solution adopted in the embodiments of this specification can achieve include at least: This invention provides a model-driven ICD management method: it introduces a model-based approach to manage the entire lifecycle of ICDs, from model creation, interface definition, data association, verification to document publishing and updating, forming a complete and systematic ICD management process. This breaks through the limitations of traditional text document management, significantly improves the efficiency and quality of ICD management, reduces manual management and maintenance costs, and reduces errors caused by human operation. The interface definition mechanism based on the meta-model in this invention provides a visual and structured interface definition method in the system model, which can define the interface name, type, parameters, signal flow and other multi-dimensional attributes in detail and accurately, and intuitively display the connection and interaction relationship between the interface and system components in a graphical form, making the interface information clearer and easier to understand, providing accurate interface specifications for subsequent system design, development and integration, and avoiding system integration problems and rework risks caused by vague or incomplete interface definitions; The application of version control function in ICD management in this embodiment of the invention: The version control module is introduced to manage the version of ICD, record the historical changes of ICD, support operations such as version creation, storage, comparison, and rollback, facilitate users to trace and restore the historical version of ICD, maintain the integrity and stability of interface information, provide strong support for the evolution and upgrade of the system, and reduce the risks and costs caused by version chaos. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating the model-based ICD management method of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the ICD management method of the present invention; Figure 3 This is a schematic diagram of the model-based ICD management system of the present invention; Figure 4 This is a schematic diagram of the structure of the computer device of the present invention. Detailed Implementation

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

[0014] The abbreviations and key terms involved in the embodiments of this invention are defined as follows: ICD (Interface Control Document): Interface control document; RFLP (Requirement, Function, Logical, Physical): Requirements, Functions, Logical, Physical; ASML (Airbone Systems Modeling Language): An airborne system modeling language based on SysML (System Modeling Language), mainly used to describe the architecture and interfaces of complex airborne systems; UML (Unified Model Language): Unified Modeling Language; SysML (System Modeling Language): A system modeling language; EoICD (Electronic Interface Control Document): Electronic interface control document.

[0015] like Figure 1 As shown, this invention provides a model-based ICD management method, including: S101. Based on the demand-driven RFLP architecture model, extract and define functional interfaces, physical interfaces, relational interfaces, energy interfaces and message interfaces, and standardize the description of system requirements, equipment requirements and software and hardware requirements. S102. Define the Airborne System Modeling Language ASML, which is formed by extending the metamodel of the System Modeling Language SysML; integrate ASML into the modeling tools to build an airborne system architecture modeling platform; S103. Construct a system architecture interface model based on the airborne system architecture modeling platform, introduce a meta-model as the core framework in interfaces at different levels, and create an interface definition template based on the meta-model; S104. Based on the meta-model and the pre-built ICD data dictionary, define interface verification rules; during the template instantiation process using the interface definition template, monitor and verify the interface data according to the interface verification rules; S105. Through the model update mechanism, the updated meta-model data and structural information are integrated into the knowledge base module of the airborne system architecture modeling platform; S106. Implement version control for the model-based ICD management process, generate and update baseline versions at project milestone nodes, output standard format ICD documents, and record historical changes between different baseline versions.

[0016] This invention primarily addresses the ICD design problem in complex systems, providing a model-based strategy and method. For example... Figure 2 As shown, the overall plan includes the following steps: Step 1: Based on the demand-driven RFLP four-layer architecture model, extract and define five layers of interfaces: functional interface, physical interface, relational interface, energy interface, and message interface, and standardize the description of system requirements, equipment requirements, and hardware and software requirements. Step 2: Define the airborne system modeling language ASML. By integrating specific model elements, relation types, and semantic rules defined by ASML into the UML modeling tool, the modeling capabilities of the tool are expanded, and an airborne system architecture modeling platform is built. Step 3: By extracting and organizing the model experience from previous projects, construct best practices such as ICD data dictionary and expert database, and import them into the knowledge base module of the tool platform as a reference for building the meta-model; Step 4: Construct the system architecture interface model, introducing a metamodel as the core framework into interfaces at different levels. This metamodel covers interface elements, attributes, and send / receive relationships. Based on the metamodel, create interface definition templates, specifying the elements and attributes that the interface must include, such as name, type, and parameters. Step 5: Based on the metamodel and data dictionary, define interface validation rules, covering mandatory attribute field checks, attribute value type validation, and attribute value range limits. During template instantiation, monitor the interface data and remind designers to correct any missing or incorrect attributes in a timely manner. Step 6: Through the model update mechanism, integrate the key data and structural information of the latest metamodel into the knowledge base module of the modeling tool platform, and supplement the original entries to ensure the timeliness of the knowledge base content; Step 7: Implement version control for the model-based ICD management process. After each milestone, update the baseline version uniformly and output it as an ICD document in a standard format. At the same time, record the historical changes between different baseline versions.

[0017] In specific implementation, step 1 involves using a systems engineering approach to further develop a five-layer interface structure—"functional interface - physical interface - relational interface - energy interface - message interface"—based on the layered system development process of functional definition, logical interaction, and physical implementation, providing target objects and data foundation for ICD design.

[0018] Functional interface design addresses the description of system functional requirements, clarifying the specific functions the system should implement and the hierarchical relationships between functions; physical interface design addresses the deployment and connection of hardware devices and components, determining the layout and connection methods of hardware devices to ensure the physical feasibility of the system; relational interface design addresses the association and interaction between various modules and components within the system, clarifying the dependencies and interactions between different parts of the system and optimizing the system structure; energy interface design addresses energy supply, distribution, and management issues to improve energy utilization efficiency; and message interface design addresses the description of information transmission and communication mechanisms, ensuring smooth communication of the system by defining information transmission paths and protocols.

[0019] 1. Input: System requirements, RFLP four-layer architecture model System modeling method: Based on the ASML modeling language, the complex structure and relationships of the system are presented in a graphical and standardized manner.

[0020] Design standards and specifications: aviation regulations such as airworthiness regulations.

[0021] 2. Handling: (1) Functional interface identification Requirements Analysis: Based on the system requirements, identify all the functions that the system should have, such as the aircraft's environmental control system needing to regulate cabin temperature, humidity, and pressure.

[0022] Functional decomposition: The system functions are decomposed layer by layer into more detailed sub-functions, such as the environmental control system function being decomposed into temperature control subsystem, pressure control subsystem, and humidity control subsystem, etc.

[0023] Interaction identification: Analyze the interaction relationships between various functional units to identify the nodes where data or information needs to be exchanged. For example, the temperature control subsystem sends adjustment commands to the air conditioning unit, and the air conditioning unit provides feedback on the adjustment status; these interaction points are the potential locations of functional interfaces.

[0024] Parameter definition: For each identified functional interface, determine its input and output parameters. For example, the input parameters of the temperature control interface are the temperature setpoint and the actual value, and the output parameters are the adjustment command, etc.

[0025] (2) Physical interface identification Hardware inventory: Collect a list of all hardware devices involved in the system, including information such as model, specifications, function, and quantity. Examples include engine models and fuselage structural components.

[0026] Device connection method analysis: Analyze the connection methods between devices, including wired connections (such as serial cables, power cords, network cables, etc.) and wireless connections (such as Wi-Fi).

[0027] Connection port identification: Identify the physical ports on the device used for connecting to other devices, and clarify parameters such as port type, pin definition, and electrical characteristics.

[0028] Connection establishment: Based on the connection method and port information of the devices, establish a connection diagram between hardware devices, clarify the connection path and connection method between each device and other devices, and thus identify the location and type of physical interfaces.

[0029] (3) Relationship Interface Identification System module division: The system is divided into multiple functional modules or component modules, each with relatively independent functions and responsibilities. For example, a flight control system is divided into an autopilot module, a flight instrument module, etc.

[0030] Module interaction analysis: This analyzes the interaction relationships between modules, including the direction of data flow, data type and content, and the triggering conditions for interaction. For example, the autopilot module sends flight attitude data to the flight instrument module, and the flight instrument module provides feedback to the autopilot module regarding the adjusted status.

[0031] Dependency Analysis: Analyze the dependencies between modules to determine which modules are prerequisites for the normal operation of other modules. For example, the flight planning module depends on the navigation database module; the formulation of flight plans requires obtaining navigation data such as airports, routes, and navigation beacons from the navigation database module.

[0032] Interface Definition and Specification: Based on the interactions and dependencies between modules, define the names, functions, input and output parameters, and calling methods of the relational interfaces. For example, when the flight planning module formulates or modifies a flight plan, it sends a query request to the navigation database module via the avionics bus. The navigation database module returns the corresponding query results, using a standardized database query protocol.

[0033] (4) Energy interface identification Energy Demand Analysis: This involves analyzing the energy demand of each component or device in the system to determine its required energy type (e.g., electrical, hydraulic, pneumatic), power range, voltage / current requirements, etc. Examples include the fuel demand of an engine and the power demand of onboard electronic equipment.

[0034] Energy Supply System Overview: This involves reviewing the system's energy supply system, including power supply equipment (such as generators and batteries), energy transmission lines (such as wires and pipes), and energy distribution equipment (such as switches, relays, and transformers). Understand the energy supply system's topology, capacity, and performance parameters. For example, a fuel system includes the fuel tank, fuel pump, and fuel lines.

[0035] Energy distribution and transmission path analysis: This involves analyzing the distribution and transmission path of energy from the supply source to various components or devices to identify the locations of energy interfaces. The energy transmission path typically involves physical connection components such as power sockets, terminal blocks, and plugs / sockets; these components constitute the energy interfaces.

[0036] Energy interface parameter determination: For the identified energy interfaces, determine their parameter requirements, such as voltage, current, frequency, power capacity, connection method (plug-in, soldered, etc.), and electrical characteristics (such as contact resistance, insulation strength, etc.). These parameters need to match the specifications of the energy supply equipment and the energy-consuming equipment to ensure reliable energy transmission and normal equipment operation, such as the pressure and flow rate of fuel interfaces, and the voltage and current of electrical interfaces.

[0037] (5) Message interface identification Information transmission requirements analysis: Analyze the types and content of information that need to be transmitted between various components or modules in the system, including control commands, status information, data updates, event notifications, etc., such as flight attitude information in a flight control system.

[0038] Communication protocol selection: Choose a suitable communication protocol based on the characteristics of different information transmission requirements (such as real-time performance, reliability, transmission distance, bandwidth requirements, etc.). Common communication protocols include ARINC429, ARINC 664, CAN, and other bus protocols.

[0039] Message format definition: Defines the format of messages in the message interface, including the structure and content of the message header, message body, and message trailer. The message header typically contains information such as message type, source address, destination address, message length, and timestamp; the message body contains the actual data content; and the message trailer may contain information such as a checksum to ensure message integrity and accuracy.

[0040] Interface call method determination: Determine the calling method of the message interface, such as whether it is a synchronous or asynchronous call, a one-way send or a request-response mode, etc. Synchronous calls are usually used in scenarios that require immediate results, such as when a client sends a request to a server and waits for the server to return a response; asynchronous calls are suitable for scenarios where real-time requirements are not high, but where it is necessary to decouple the sender and receiver, such as log uploading and event notification.

[0041] 3. Output: (1) Functional interface: Describe the system functional architecture in detail, including the functional list, functional hierarchy, input and output of functional modules and functional logic, as well as functional model diagrams (functional structure diagram, data flow diagram, etc.), to provide a functional blueprint for subsequent design and development.

[0042] (2) Physical interface: It covers the equipment selection list, physical layout diagram, equipment installation location and connection method description, as well as physical interface definition document (interface signal type, pin definition, communication protocol, etc.) to guide the hardware system construction and equipment installation.

[0043] (3) Relationship interface: Presents the component relationship model, clarifies the data dependency and control relationship between components, and includes interface design documents (software interface and hardware interface definition, integration method, etc.) to ensure smooth system integration.

[0044] (4) Energy interface: includes energy demand analysis report (power consumption of each component, overall energy demand of the system), energy allocation scheme (power allocation of the power supply system to each component), energy management strategy (energy monitoring and optimization methods) to ensure stable and reliable energy supply of the system.

[0045] (5) Message interface: Describe in detail the data flow analysis results (data source, path, destination, characteristics) and message transmission mechanism (message format, transmission protocol, routing rules) to achieve efficient and reliable data transmission within the system.

[0046] Step 2: Define the airborne system modeling language ASML. By integrating specific model elements, relation types, and semantic rules defined by ASML into the UML modeling tool, the modeling capabilities of the tool are expanded, and an airborne system architecture modeling platform is built. ASML provides a unified airborne system modeling framework that covers the entire lifecycle from functional requirements to physical implementation; supports traceability and verification between all levels (functional, logical, and physical) of airborne systems; standardizes airborne system interface definitions, including functional interaction, physical connection, energy flow, and message passing; and supports automatic analysis and verification of system architecture.

[0047] 1. ASML's extension framework for SysML ASML extends the metamodel of SysML, reusing the core capabilities of basic elements such as Block, Property, and FlowPort in SysML. It also provides customized extensions for the domain characteristics of airborne systems, including the following methods: (1) Define new configurations (Stereotype) to extend SysML basic elements: add airborne domain-specific attributes (such as "device model", "airworthiness rating", "bus protocol version") to each extended element.

[0048] (2) Introduce new relation types to describe the unique associations of airborne systems: supplement the airborne system-specific relations not covered by SysML (such as "redundancy backup relation" and "fault isolation relation") to express the special associations between system elements.

[0049] (3) Establish specific semantic rules to ensure model consistency: Combine aviation industry standards to define semantic constraints to avoid logical conflicts in model design (such as physical bus interface type mismatch).

[0050] (4) Define dedicated diagram types to support specific views of airborne systems: such as adding "system architecture overview diagram" and "energy distribution topology diagram" to meet the view requirements of different design stages (such as scheme review and interface protocol confirmation).

[0051] The ASML metamodel adds five core extension packages to SysML. These packages collaborate through dependencies, forming a complete metamodel system for airborne system modeling. (1) Functional interface package: Focuses on the functional layer modeling of airborne systems, including elements such as functional blocks, functional parameters, and functional flow specifications, and supports functional requirement decomposition and interactive definition.

[0052] (2) Physical interface package: Hardware layer modeling, covering elements such as physical devices, bus interfaces, and physical connection relationships, supporting hardware device selection and bus topology design, and adapting to mainstream airborne bus types such as A429 and CAN.

[0053] (3) Relationship Management Package: This package manages the relationships between different levels of the system, including hierarchical decomposition, cross-level allocation, and requirement traceability. It is the core package for achieving full-link traceability of "requirement-function-logic-physical".

[0054] (4) Energy interface package: Designed for the energy supply characteristics of airborne systems, it includes elements such as energy type, energy flow specifications, and energy distribution nodes, and supports energy load calculation and power supply redundancy design.

[0055] (5) Message Interface Package: Models message passing between system elements, defines message format, passing rules, quality attributes, etc., and supports message structure description of airborne dedicated communication protocols such as ARINC429 and AFDX.

[0056] 2. Definition of ASML core elements (1) Basic element expansion

[0057] (2) Extension of relation type elements

[0058] (3) Flow specification extension

[0059] 3. Modeling Platform Setup Process The construction of an airborne system architecture modeling platform based on ASML extensions includes the following steps: (1) SysML tool extension Implement ASML stereotype definitions in the SysML tool, add new properties (such as "device model" and "bus protocol") to each stereotype, and configure the property editing controls.

[0060] (2) Model library construction Develop a general model library for airborne systems, build standard component and interface libraries, and establish typical system architecture templates (such as single-redundancy architecture, dual-redundancy architecture, and triple-redundancy architecture), including preset element associations and interface definitions, for rapid construction of basic architecture.

[0061] (3) Model Integration Integrate the core ASML extension package into the SysML model to implement a model consistency check mechanism. Develop a consistency check plugin that supports manual triggering (e.g., when an engineer clicks the "Check" button) and automatic triggering (e.g., when the model is saved). Check dimensions include element attribute integrity, relationship rationality, interface compatibility, etc. The check results are output in report form, indicating the error location, cause, and repair suggestions.

[0062] The validation rules primarily focus on four dimensions: mandatory fields, format, range, and matching. They cover mandatory attribute field checks, attribute value type validation, and attribute value range limitations. Furthermore, nested data structures and dependency validation must be considered to ensure the accuracy and completeness of the interface data. All rules are implemented through the modeling platform's automatic checking mechanism, supporting error location and repair guidance. The core validation rules are as follows: (i) Integrity rules All function blocks must be assigned: Unassigned function blocks are marked as "Error", prompting "Please assign the function block to the corresponding component to ensure that the function can be implemented", and providing a "Quick Assign" button (listing available components for selection).

[0063] All logical components must be deployed to at least one physical device: logical components that are not deployed are marked as "error" and prompted "Please deploy the logical components to a physical device to ensure that the logic is implemented".

[0064] (ii) Consistency rules The parameter types and units of all types of interactions must match each other. If there is a mismatch in types, it should be marked in time and prompts and suggestions should be given to unify the type or convert the type.

[0065] (iii) Traceability rules All design elements must be traceable to their source of requirements: elements that cannot be traced back to requirements (such as function blocks or physical devices) are marked as "Warning" with the message "It is recommended to associate the requirement item to ensure that the design meets the requirements"; critical elements that are not traceable are marked as "Error" and are required to be associated.

[0066] All changes must be recorded and their impact assessed: elements for which change information is not recorded are marked as "Warning" with the message "Please supplement the change record for traceability"; if the impact of a change is not assessed after it is made, it is marked as "Warning" and potentially affected elements are automatically listed.

[0067] Interface changes must trigger the re-verification of related elements: When interface elements such as physical bus interface and message format change, the related connection and interaction relationships are automatically marked as "to be verified", prompting "interface changes require re-verification of compatibility", and triggering the interface compatibility check tool.

[0068] Step 3 involves introducing best practices such as the ICD data dictionary and expert library into the system architecture modeling platform to support modeling platform reuse. Through the platform's import function, the interface definitions in the best practices can be directly converted into interface elements in the model.

[0069] This step is not mandatory. In the initial modeling process on the platform, if there is a lack of experience data, this step can be skipped temporarily, and subsequent modeling steps can be prioritized. Once the model architecture has reached a certain scale, the knowledge base can be iteratively optimized.

[0070] The ICD data dictionary contains detailed definitions of the interfaces, such as function names, input / output parameter names, source, and terminal. Using Excel format as an example, it lists the attributes of each interface in a table format, as shown in the table below.

[0071]

[0072] Step 4: Construct the system architecture model, introducing a metamodel as the core framework. This metamodel covers interface elements, attributes, and send / receive relationships. Based on the metamodel, create interface definition templates, specifying the elements and attributes that the interface must include, such as name, type, and parameters.

[0073] Inputs: Functional interface documentation, physical interface documentation, relational interface documentation, energy interface documentation, and message interface documentation. Output: Metamodel definition template.

[0074] In the field of civil aircraft, the meta-model based on the five-layer interface model can be specifically illustrated using the flight control system as an example: Functional Interface: Includes an attitude adjustment module, whose function name is "Attitude Adjustment," input is "Attitude Angle," output is "Adjustment Command," priority is "High," and trigger condition is "Real-time Adjustment." The attitude adjustment module relies on the position information provided by the navigation system and operates in parallel with the autopilot.

[0075] Elements: Functional modules (such as posture adjustment modules); Attributes: Function name (attitude adjustment), input (attitude angle collected by sensors), output (adjustment command for flight control actuators), priority (high priority), trigger condition (attitude adjustment is required in real time); Relationships: Dependency (attitude adjustment depends on the location information provided by the navigation system), Parallelism (attitude adjustment and autonomous driving share some data but operate independently); Physical Interface: Utilizes the ARINC664 bus interface, type "Electrical," conforming to the "ARINC664 standard," with "Bidirectional" orientation and following the "ARINC664 Communication Protocol." This interface connects the flight control computer and the autopilot, and is compatible with both the flight control hardware and the autopilot hardware.

[0076] Elements: Flight control computer, connectors (such as ARINC664 bus interface); Attributes: Type (electrical), Specification (compliant with ARINC664 standard), Directionality (bidirectional), Protocol (ARINC664 communication protocol); Relationships: Connectivity (connects the flight control computer and the autopilot), compatibility (compatible with both flight control hardware and autopilot hardware); Relationship Interface: The relationship interface describes the logical relationships between components, such as data flow and control dependencies. The flight control computer, as a core component, is named "Flight Control Computer," is of type "Processor Unit," and its connection to the sensors is "Sensor to Flight Control Computer," with a "Strong Dependency" connection strength. The flight control computer contains an attitude adjustment module, which works in conjunction with the navigation module, and attitude adjustment takes precedence over non-real-time diagnostics.

[0077] Elements: Components (flight control computer), connections (data flow between the flight control computer and sensors); Attributes: Component name (flight control computer), component type (processor unit), connection direction (sensor to flight control computer), connection strength (strong dependency); Relationships: Include (the flight control computer includes an attitude adjustment module), Combine (the attitude adjustment module and the navigation module work together), Priority (attitude adjustment takes precedence over non-real-time diagnostics). Energy Interface: The energy interface relates to the system's energy supply and consumption. A 28VDC power supply serves as the energy source, classified as a "DC power supply" with a capacity of "10A" and a status of "normal power supply." The flight control computer's processor, as the energy consumption point, has a supply relationship with the power supply and feeds back the load status to it.

[0078] Elements: Energy source (28VDC power supply), energy consumption point (processor of flight control computer); Attributes: Type (DC power supply), Capacity (10A), Status (normal power supply); Relationship: Supply (power supply to the flight control computer), Consumption-feedback (the flight control computer feeds back its load status to the power supply). Message Interface: The message interface primarily describes message passing between system components. The flight control computer's control command generation node serves as the message node, and the ARINC664 bus acts as the message channel. The node name is "Control Command Generation Node," the channel bandwidth is "1Mbps," the protocol follows the "ARINC664 protocol," and the message format is "binary encoding." The flight control computer sends control commands to the autopilot via the bus, with a message transmission delay of 1ms.

[0079] Elements: Message node (message generation node of flight control computer), message channel (ARINC664 bus); Attributes: Node name (control command generation node of flight control computer), node type (message generation node), channel bandwidth (1Mbps), protocol (ARINC664 protocol), message format (binary encoding); Relationship: Send-receive (the flight control computer sends control commands to the autopilot via the bus), delay (the message transmission time delay is 1ms).

[0080] Step 5: Based on the meta-model and data dictionary, define interface validation rules. During template instantiation, monitor the interface data and remind designers to correct any missing or incorrect attributes.

[0081] Based on the attribute constraints of the metamodel (such as "required" and "data type") and the standardization requirements of the data dictionary (such as "format specification" and "range limitation"), four types of core validation rules are defined to cover scenarios such as "required fields, types, and ranges" mentioned by users, and additional correlation validation is added to ensure the closed loop of interface logic.

[0082] 1. Attribute Required Field Validation Rules Objective: Ensure that no key attributes are missing (attributes marked "required" in the metamodel).

[0083] Define the logic: Extract all attributes with "constraint = required" from the metamodel (such as "ID" and "name" of all interfaces, "interface type" of functional interfaces, etc.). Rule format: {Attribute path: [Full name of attribute], Validation type: "Required", Error message: "[{Attribute name}] is a required field, please complete it"}.

[0084] 2. Attribute value type validation rules Objective: Ensure that the data type of attribute values ​​conforms to the metamodel definition (avoiding problems such as "filling in strings for numbers" or "filling in incorrect enumeration values").

[0085] Define the logic: based on the "data type" field of the metamodel (such as string, enumeration, integer, floating point); for enumeration types, the allowed value range must be clearly defined (extracted from the metamodel, such as the enumeration values ​​of "interface type": data input / output / control signal). Rule format: {Attribute path: [Full attribute name], Validation type: "Type", Expected type: [Type], Allowed values: [List of enumerated values], Error message: "[{Attribute name}] Type error, should be {Expected type}, Allowed values: {Allowed values}"}.

[0086] 3. Attribute value range / format validation rules Objective: Ensure that attribute values ​​comply with business rules or industry standards (such as "power cannot be negative" and "ID format is consistent").

[0087] Definition logic: based on the standardized requirements of the data dictionary (such as ID format, parameter range) and industry specifications (such as the transmission rate range of the ARINC 429 protocol). Rule format: {Attribute path: [Full name of attribute], Validation type: "Scope / Format", Constraint condition: [Expression / Regular expression], Error message: "[{Attribute name}] does not meet the requirements, {Specific constraint}"}.

[0088] 4. Relevance Validation Rules Objective: Ensure that the relationships between interface elements are valid (e.g., "interface mappings must be associated with existing functional interfaces and physical interfaces").

[0089] Definition logic: "Relationship" definition based on metamodel (e.g., interface mapping needs to associate functional interface ID and physical interface ID); Rule format: {Relationship: [Relationship Name], Validation Type: "Relationship", Constraint: "[Source Attribute] must exist in [Target Element Library]", Error message: "[{Relationship}] Error, {Source Attribute} does not exist in {Target Element Library}"}.

[0090] Step 6: Through the model update mechanism, integrate the key data and structural information of the latest metamodel into the knowledge base module of the modeling tool platform, and supplement the original entries to ensure the timeliness of the knowledge base content; 1. Data integration (1) Parse the metamodel update log: identify module or interface changes. For example, when the metamodel of the flight control system is updated, it may involve changes to the interface definition of the attitude adjustment module, such as the adjustment of signal frequency or the addition of control signals.

[0091] (2) Locating the corresponding entry in the knowledge base: Matching is performed using unique identifiers such as interface name and type to find the matching entry in the knowledge base. For example, for the attitude signal interface of the flight control system, the corresponding entry is located in the knowledge base by its interface name.

[0092] (3) Update field content: Based on the preset metamodel rules, update the key data and structural information of the updated metamodel to the knowledge base entries. For example, update the signal frequency of the attitude adjustment module interface from 100Hz to 200Hz to ensure that the data in the knowledge base is consistent with the metamodel.

[0093] (4) Record version history: When updating knowledge base entries, automatically record the update timestamp. For example, record the update time of the attitude signal interface as "2025-08-26 14:30:00". If the knowledge base already has a field containing a timestamp, the newer data will be used first. For example, if there are two entries about the attitude signal interface in the knowledge base, recorded as "2025-08-25" and "2025-08-26" respectively, the latter data will be used first. For entries with serious conflicts, trigger manual confirmation. For example, if there is a large difference between the metamodel update and the historical data in the knowledge base, experts will conduct manual review and judgment to decide the final data to be adopted.

[0094] 2. Knowledge base verification (1) Consistency check: Check whether the updated interface definition in the knowledge base is completely consistent with the definition in the meta-model. For example, verify whether the signal type, frequency, amplitude and other parameters of the attitude signal interface are the same as those in the meta-model.

[0095] (2) Impact assessment: Analyze the impact of the updated knowledge base entries on the core systems. For example, assess whether changes to the attitude signal interface will affect the functionality and compatibility of core systems such as the flight control computer and autopilot, and ensure that the update does not introduce new risks or incompatibility issues.

[0096] Step 7: Implement version control for the model-based ICD management process. After each milestone, update the baseline version uniformly and output it as an ICD document in a standard format. At the same time, record the historical changes between different baseline versions.

[0097] 1. Build a version control system Assign a unique identifier to each baseline version, such as V1, V2, etc., to facilitate differentiation and management of different versions. Record key information, including version number, update time, and update content. Support version difference comparison and history rollback to quickly locate problems or restore to a previous version state when needed.

[0098] 2. Generate ICD document Define mapping rules: In the generation of civil aircraft ICD documents, the elements in the model are mapped to the standard fields of the ICD document. For example, the interface name in the model is mapped to the interface identifier field of the ICD document, the interface type is mapped to the interface category field, and the signal frequency is mapped to the signal characteristic field.

[0099] Automated scripts or tools for reading model data: Automated scripts or tools can be used to read model data, support the extraction of data from the model and the generation of ICD documents, generate standard-compliant ICD model files, and support exporting to specific formats such as XML.

[0100] 3. Record historical changes, including the time of change, the content of the change, the reason for the change, and the triggering point of the change.

[0101] In one embodiment, taking the Integrated Display Unit (IDU) of the Aircraft Display System displaying the fuel level of each fuel tank and the total fuel level as an example, the Fuel Measurement and Management Computer (FGMC) provides the fuel level of each fuel tank and the total fuel level to the Remote Data Conversion Unit (RDC) via the ARINC 429 bus, and provides fuel level data to the IDU via the avionics network: 1. Identify five layers of interfaces: functional interface, physical interface, relational interface, energy interface, and message interface. 2. ASML provides a unified airborne systems modeling framework. Based on the airborne systems modeling language ASML, custom ASML extensions are created for the core components (FGMC, RDC, IDU, avionics network) and interaction logic in the scenario.

[0102] (1) Define the scene construct Based on the element characteristics in the instance and basic elements such as Block and FlowPort in SysML, add exclusive stereotypes to scene components and define core properties.

[0103] (i) Define scene relationship types For the data flow and deployment relationship of "FGMC→RDC→Avionics Network→IDU" in the example, supplement the scenario-specific relationships not covered by SysML.

[0104] (ii) Establish scene semantic rules By combining aerospace standards (such as ARINC 429 and DO-178C) and the characteristics of the examples, semantic constraints are formulated to ensure model consistency and avoid design conflicts.

[0105] Protocol compatibility rules: FGMC's <<BusInterface_ARINC429> For interfaces of the same type as RDC, the transmission rate (100kbps) and data frame format must be consistent; otherwise, the model will prompt "ARINC 429 interface protocol mismatch, parameters need to be consistent"; Energy matching rules: The rated voltage attribute of FGMC / IDU must be consistent with the output voltage (28VDC) of the "Airborne Power Distribution System". If other voltages are input (such as 12V), it will be automatically marked "Energy parameters do not match, instance requires 28V DC". Installation compliance rules: The installation standard for FGMC must be selected as "ARINC 600", and the installation method for IDU must be selected as "Quick-install (3 positioning pins + 2 steel sleeves)", otherwise the message "Does not meet the instance hardware installation requirements" will be displayed. Message integrity rule: Fuel quantity messages must include four fields: "Fuel Tank Number, Fuel Quantity Value, Total Fuel Quantity, and Timestamp". If any field is missing, the model will trigger a "Message fields are incomplete, XX fields need to be added" prompt.

[0106] (iii) Create scene-specific graph types To meet the requirements for solution review and interface confirmation for the instance, a new scenario model diagram has been added.

[0107] Fuel quantity transmission architecture overview diagram: showing the physical connection relationship of FGMC→RDC (ARINC 429 bus)→avionics network→IDU, and marking the installation location of each component (such as FGMC installed on ARINC 600 bracket, IDU installed on cockpit panel) and power interface (28V DC).

[0108] Fuel quantity data message sequence diagram: It presents the complete sequence of "FGMC collects fuel quantity → sends ARINC 429 message → RDC receives and forwards → avionics network transmits → IDU displays", and marks the delay of each link (e.g., RDC forwarding delay ≤ 50ms).

[0109] Energy supply topology diagram: clearly mark the connection paths of FGMC (0.6A), IDU (5A) and airborne power distribution system, calculate the total energy consumption (5.6A), and verify whether it meets the power distribution system capacity.

[0110] 3. The system architecture modeling platform incorporates best practices such as the ICD data dictionary and supports interface reuse. The ICD data dictionary contains reusable static interface attributes and adopts a hierarchical classification and association mapping design. The main attributes are shown in the table below:

[0111] 4. Create a metamodel template Functional Interface Metamodel Definition Template:

[0112] Physical Interface Metamodel Definition Template:

[0113] Relationship Interface Definition Metamodel Template:

[0114] Energy Interface Definition Metamodel Template:

[0115] Message Interface Metamodel Definition Template:

[0116] 5. Define interface validation rules based on the meta-model and data dictionary. Functional interface verification:

[0117] Physical interface verification:

[0118] Relationship interface validation:

[0119] Energy interface verification:

[0120] Message interface verification:

[0121] 6. Through the model update mechanism, the key data and structural information of the latest metamodel are integrated into the knowledge base of the modeling tool platform.

[0122] To achieve the goal of integrating the key data / structure of the latest meta-model in the fuel display scenario into the modeling tool knowledge base, a closed-loop update mechanism needs to be constructed, which includes "meta-model change identification → key data extraction → verification and integration → knowledge base synchronization → tool activation".

[0123] 7. The output is an ICD document in a standard format, which also records the historical changes between different baseline versions.

[0124] like Figure 3 As shown, this embodiment of the invention also provides a model-based ICD management system 200, including: Interface definition module 201 is used to extract and define functional interfaces, physical interfaces, relational interfaces, energy interfaces and message interfaces based on the requirement-driven RFLP architecture model, and to standardize the description of system requirements, equipment requirements and software and hardware requirements. Modeling platform module 202 is used to define the airborne system modeling language ASML, which is formed by extending the metamodel of the system modeling language SysML; and to integrate ASML into the modeling tools to build an airborne system architecture modeling platform. Meta-model and template module 203 is used to construct a system architecture interface model based on the airborne system architecture modeling platform, introduce the meta-model as the core framework in interfaces at different levels, and create interface definition templates based on the meta-model. The verification module 204 is used to define interface verification rules based on the meta-model and the pre-built ICD data dictionary; during the template instantiation process using the interface definition template, the interface data is monitored and verified according to the interface verification rules. The update and storage module 205 integrates the updated meta-model data and structural information into the knowledge base module of the airborne system architecture modeling platform through the model update mechanism; The version control and output module 206 is used to perform version control on the model-based ICD management process, generate and update the baseline version at project milestone nodes, output standard format ICD documents, and record the historical changes between different baseline versions.

[0125] In one embodiment, a computer device is provided, such as Figure 4 As shown, it includes a memory 301, a processor 302, and a computer program stored in the memory 301 and executable on the processor 302. When the processor 302 executes the computer program, it implements the model-based ICD management method described above.

[0126] Specifically, the computer device can be a computer terminal, a server, or a similar computing device.

[0127] In this embodiment, a computer-readable storage medium is provided, which stores a computer program that performs the model-based ICD management method described above.

[0128] 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 model-based ICD management method, characterized in that, include: Based on the demand-driven RFLP architecture model, functional interfaces, physical interfaces, relational interfaces, energy interfaces, and message interfaces are extracted and defined to standardize the description of system requirements, equipment requirements, and hardware and software requirements. Define an airborne system modeling language ASML, which is formed by extending the metamodel of the system modeling language SysML; integrate ASML into modeling tools to build an airborne system architecture modeling platform; Based on the airborne system architecture modeling platform, a system architecture interface model is constructed. A meta-model is introduced as the core framework in the interfaces at different levels. Based on the meta-model, an interface definition template is created. Based on the meta-model and the pre-built ICD data dictionary, interface verification rules are defined; during the template instantiation process using the interface definition template, the interface data is monitored and verified according to the interface verification rules. Through the model update mechanism, the updated meta-model data and structural information are integrated into the knowledge base module of the airborne system architecture modeling platform; Version control is implemented for the model-based ICD management process. Baseline versions are generated and updated at project milestone nodes, ICD documents in standard format are output, and historical changes between different baseline versions are recorded.

2. The model-based ICD management method according to claim 1, characterized in that, Integrating ASML into modeling tools to build an airborne system architecture modeling platform includes: By integrating ASML-defined stereotypes for describing the functions, logic, and physical elements of airborne systems into the UML modeling tool, introducing relation types that describe the unique relationships of airborne systems, establishing semantic rules based on aerospace standards, and defining graph types that support specific views of airborne systems, the modeling capabilities of the UML modeling tool are expanded, and an airborne system architecture modeling platform is built.

3. The model-based ICD management method according to claim 1, characterized in that, The ASML extended framework includes a functional interface package focusing on modeling the functional layer of airborne systems, a physical interface package for modeling the hardware layer, a relationship management package for managing the relationships between different levels of the system, an energy interface package designed for the energy supply characteristics of airborne systems, and a message interface package for modeling message passing between system elements.

4. The model-based ICD management method according to claim 1, characterized in that, The metamodel defines the model elements, model attributes, and model relationships of each interface.

5. The model-based ICD management method according to claim 1, characterized in that, The interface validation rules include: mandatory attribute field checks, attribute value data type validation, attribute value range or format validation, and validation of the legality of the association between interface elements.

6. The model-based ICD management method according to claim 1, characterized in that, Version control is implemented for the model-based ICD management process, including: assigning a unique identifier to each baseline version, recording the version number, update time, update content and reason for change, and supporting version difference comparison and historical version backtracking.

7. The model-based ICD management method according to claim 1, characterized in that, Output standard format ICD documents, including: extracting data from the system architecture interface model and generating ICD documents using automated scripts or tools based on predefined mapping rules.

8. A model-based ICD management system, characterized in that, include: The interface definition module is used to extract and define functional interfaces, physical interfaces, relational interfaces, energy interfaces, and message interfaces based on the requirement-driven RFLP architecture model, and to provide standardized descriptions of system requirements, equipment requirements, and hardware and software requirements. The modeling platform module is used to define the airborne system modeling language ASML, which is formed by extending the metamodel of the system modeling language SysML; and to integrate ASML into the modeling tools to build an airborne system architecture modeling platform. The metamodel and template module is used to construct a system architecture interface model based on the airborne system architecture modeling platform, introduce the metamodel as the core framework in interfaces at different levels, and create interface definition templates based on the metamodel. The verification module is used to define interface verification rules based on the meta-model and the pre-built ICD data dictionary; during the template instantiation process using the interface definition template, the interface data is monitored and verified according to the interface verification rules. The update and storage module integrates the updated meta-model data and structural information into the knowledge base module of the airborne system architecture modeling platform through the model update mechanism. The version control and output module is used to perform version control on the model-based ICD management process, generate and update baseline versions at project milestone nodes, output standard format ICD documents, and record historical changes between different baseline versions.

9. A computing device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the model-based ICD management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the steps of the model-based ICD management method as described in any one of claims 1 to 7.

Images