A complex airborne equipment system integration test ICD management platform and management method

Abstract

This invention relates to the field of semi-physical simulation testing and experimental technology, and particularly to an ICD management platform and method for integrated testing of complex airborne equipment systems. The platform includes a client and a server. The client has modules for data design, version management, and permission management, while the server has modules for data access interface, data synchronization, and historical data management. This invention adopts an MVC architecture based on the EMF modeling framework. Through a data import unit, external XML or database data is mapped to EMF model instances, and a built-in verification framework is used for standardized verification. Specifically, the data export unit of this invention can automatically convert the EMF model into a Rhapsody architecture model or a Simulink simulation model, thus establishing a data link from interface definition to simulation testing.

Description

Technical Field

[0001] This invention relates to the field of semi-physical simulation testing and experimental technology, and in particular to an ICD management platform and management method for complex airborne equipment system integration testing. Background Technology

[0002] In the integration testing, final inspection, and military inspection of complex airborne equipment (such as aircraft electromechanical management systems and avionics systems), the definition and management of ICD data are fundamental to ensuring correct communication between various devices. ICD describes the communication protocols, data formats, electrical characteristics, and behavioral logic between airborne equipment or systems.

[0003] Currently, the closest existing technology is "a method for editing the interface definition of an electromechanical system." While this technology enables the electronic storage of ICD data, optimizes the integration testing process, and shortens the testing cycle to some extent, it still has significant limitations:

[0004] Insufficient model export capabilities: Existing technologies primarily focus on the static storage and editing of data, lacking adequate support for downstream simulation and testing tools. Modern airborne software development widely employs model-based development (MBD) methods, such as using Rhapsody for architecture design and Simulink for algorithm simulation. Existing technologies cannot automatically convert ICD data into model formats recognizable by these tools, forcing testers to manually and repeatedly enter data, which is inefficient and prone to introducing human error.

[0005] Version management and traceability are difficult: As model development progresses, ICD data undergoes frequent iterative changes. Existing document-based or simple electronic management methods struggle to accurately record the historical state of each modification, failing to achieve millisecond-level data snapshots and backtracking. This makes it difficult to pinpoint which ICD version caused the problem.

[0006] Lack of concurrency control and access control: In multi-user collaborative design scenarios, existing technologies lack conflict handling mechanisms for concurrent write operations by multiple users, and also lack fine-grained access control (such as hierarchical authorization of read-only, write, export, and version control), which poses security risks of accidental data deletion or unauthorized access.

[0007] Therefore, there is an urgent need for an ICD management platform with model export capabilities, comprehensive version management, and secure access control to solve the above problems. Summary of the Invention

[0008] To address the aforementioned problems, this application provides a complex airborne equipment system integration test (ICD) management platform, including a memory and a processor. The memory stores a computer program executable by the processor. When the processor executes the computer program, it implements the following modules:

[0009] The data design module is configured to provide a graphical user interface, responding to user operations to complete the creation, editing, retrieval, and export of ICD data, including ARINC429, ARINC664 bus, discrete quantities, and analog quantities.

[0010] The version management module is configured to record timestamps for project data and respond to commands to set version tags for project data, browse historical records, and compare version differences.

[0011] The access control module is configured to determine the legitimacy of user requests to access ICD data based on predefined access combinations.

[0012] The data access interface module uses object-relational mapping technology and is configured to perform CRUD operations on the underlying ICD database.

[0013] The data synchronization processing module is configured to support concurrent operations by multiple users and ensures data consistency in the ICD database through locking mechanisms or transaction processing.

[0014] The historical data management module is configured to store ICD data modification records with timestamps, providing a traceability mechanism for the entire data lifecycle.

[0015] A complex airborne equipment system integration test ICD management software architecture, adopting the MVC design pattern based on the EMF modeling framework, includes:

[0016] The presentation layer includes a menu bar, toolbar, a resource manager view displayed in a tree structure, and an ICD data editing area; the presentation layer is configured to receive user input and send data change requests to the business logic layer.

[0017] The business logic layer includes a data import unit, a data export unit, a permission determination unit, and a version control unit. The data import unit is configured to map external ICD files to internal EMF model instances using an XML parsing engine. The data export unit is configured to serialize the EMF model instances into standard XML files conforming to a preset schema, or to convert the data into Rhapsody / Simulink model format. The permission determination unit is configured to intercept business operation requests and return a determination result based on the matching relationship between user roles and data levels.

[0018] The persistence layer includes a database access interface and a historical data repository. The database access interface is configured to shield the differences between the underlying databases through ORM technology. The historical data repository is configured to store data snapshots with timestamps to support the backtracking and export of any historical version.

[0019] A method for managing integrated circuit detection (ICD) systems for complex airborne equipment, implemented based on the aforementioned software architecture, includes the following steps:

[0020] S1: In response to the user's import command, read the external ICD data source; map the read data into an internal unified EMF model instance through the EMF modeling framework, and use the built-in verification framework to perform standardization verification on the instance data;

[0021] S2: Display the tree structure of ICD data in the graphical interface; respond to the user's request to edit data of a specific node, call the permission management module to determine whether the user has write permission for that node; if the user has permission, allow the user to modify the data attributes and relationships through the wizard or editor, and store the modification operation with the timestamp.

[0022] S3: In response to the user's version release command, the current ICD data snapshot is tagged with a version label and fixed; in response to the user's comparison command, data snapshots from two different historical moments or different version labels are extracted, differential analysis is performed, and a comparison report is generated.

[0023] S4: In response to user export commands, convert ICD data into standard XML format files, or automatically convert it into Rhapsody models or Simulink models, for use by downstream integration testing, final inspection, or military inspection systems.

[0024] Preferably, the data design module is further configured with a Lazy mode retrieval tree construction unit, which is configured to allow users to customize the hierarchical relationship of the retrieval structure and dynamically load the child node data under the node when the user expands the tree node.

[0025] Preferably, the business logic layer also includes a plug-in management unit, configured to load new bus protocol parsers or non-bus quantity processing logic through a standardized plug-in interface, in order to support the dynamic expansion and reuse of ICD data for different aircraft models.

[0026] Preferably, the permission allocation rules executed by the permission determination unit include:

[0027] The system administrator has complete control over all data;

[0028] By default, project administrators have read permissions for the data of their assigned project and can assign read and write permission combinations for that project to ordinary users.

[0029] The read / write permission combination includes readable permission, writable permission, data export permission, and version control permission;

[0030] Data export permissions take effect only if read permissions are available.

[0031] Preferably, the external ICD data source in step S1 includes an XML file conforming to a predefined XMLSchema, or a relational data table containing data packet name, parameter name, offset, and length information; the standardization verification in step S1 includes data type verification, value range verification, and integrity verification of association relationships.

[0032] Preferably, the standard XML format file exported in step S4 has a hierarchical element structure, including system elements, preset value elements, and unit type elements as top-level elements; wherein the system elements include device elements, bus port elements, data block elements, signal elements, and domain elements at each level, and each element is configured with a unique ID identifier.

[0033] Preferably, the device is also equipped with an automatic backup module, which automatically triggers a database backup operation and stores the backup file to an off-site disaster recovery node when a structural change in the database is detected or a preset time interval is reached.

[0034] Preferably, step S2 further includes a user session management step: when a user accesses the server through a client, a user session connection is established and maintained; when a user is detected to have been inactive for a long time or has been abnormally disconnected, the system resources occupied by the session are released.

[0035] Beneficial effects of the present invention

[0036] Model-driven, seamless integration: Through the EMF modeling framework, the automatic conversion of ICD data to Rhapsody and Simulink models is realized, opening up the link from interface definition to simulation testing, avoiding errors from manual transcription, and greatly improving the efficiency of model-based development.

[0037] Full lifecycle traceability: Utilizing a timestamp mechanism to record every data change, it supports data backtracking, exporting, and comparison at any historical moment, providing a solid data foundation for fault location and version management.

[0038] A secure and controllable collaborative environment: A multi-level permission system including read, write, export, and version control is designed. Combined with a data synchronization processing module, it not only ensures data consistency for concurrent operations by multiple users, but also ensures the security of core data and prevents unauthorized operations.

[0039] High scalability and maintainability: Adopting a plug-in mechanism and MVC design pattern, it supports rapid expansion of new bus protocols (such as ARINC664) and non-bus quantities (discrete quantities, analog quantities), adapting to the ICD management needs of different aircraft models. Attached Figure Description

[0040] Figure 1This is a schematic diagram of the scalable framework structure of the ICD management platform in an embodiment of the present invention.

[0041] Figure 2 This is a schematic diagram of the module division and server architecture of the ICD management platform in an embodiment of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below with reference to the accompanying drawings. In the drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The described embodiments are only some, not all, of the embodiments of this application. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0043] ICD design is an essential and crucial component in the design of complex airborne equipment systems. It encompasses the establishment and management of the ICD database and the generation of standardized ICD documents. To this end, this invention constructs a professional ICD data management platform, such as... Figures 1-2 As shown, this software aims to effectively manage the ICD database and automatically generate ICD documents based on testing requirements. Compared to traditional document management methods, this ICD management software not only provides efficient database query functions but also integrates rich data management and maintenance mechanisms, significantly improving the security, reliability, and design efficiency of the ICD database. Furthermore, the platform introduces a model-based data-driven mechanism, describing ICD characteristics through the import and export of model files. This completely changes the previous reliance on document-based delivery, greatly improving the development efficiency of complex airborne equipment systems and fundamentally avoiding the ambiguity and human error caused by document-based ICDs.

[0044] This complex airborne equipment system integration test ICD management platform, as an advanced ICD data design and management hub, possesses the following core features:

[0045] Supports the design of multiple bus ICDs, covering mainstream airborne bus protocols such as ARINC429 and ARINC664;

[0046] It supports the design and management of various non-bus variables, including fine-grained definitions of discrete and analog signals;

[0047] The search tree using the Lazy mode provides a flexible mechanism that allows users to define the search structure arbitrarily, dynamically loading data only when nodes are expanded, thus optimizing system response speed;

[0048] It has an automatic ICD document generation function, which can output standardized documents that meet the specifications with one click;

[0049] It provides comprehensive project data version management and version comparison functions, and supports the retrospective of data snapshots;

[0050] The built-in model export mechanism can automatically convert ICD data into Rhapsody architecture models or Simulink simulation models, thus bridging the design and testing link.

[0051] Equipped with a graphical editor for data blocks and signals, the design process for ICD data blocks and signals is intuitive and convenient;

[0052] A complete management system has been built, covering multiple dimensions such as access control, version control, project management, account management, and data management;

[0053] Build a secure and reliable data management platform, relying on a secure and reliable user account management system and automatic database backup function to protect core data assets;

[0054] It possesses excellent scalability and maintainability, and adapts to future technological evolution through a plugin development mechanism and the MVC design pattern.

[0055] The application of ICDs typically exhibits significant inheritance, often reusing design achievements from previous models to a certain extent during the development of new models. Furthermore, new models' ICDs may introduce different types of data or even adopt entirely new bus protocols. Therefore, the ICD management platform for complex airborne equipment system integration testing must possess strong scalability to enable rapid reuse of existing ICD data. This scalability extends beyond software functionality and interface extensions to include underlying extensions of data structures and even database structures. Through a scalable platform, it is possible to quickly respond to the specific needs of different models, customize new bus types and non-bus data types, and rapidly update the database structure.

[0056] Based on the above design concept and according to the design and management requirements of ICD, the logical architecture of the complex airborne equipment system integration test ICD management platform can be divided into two layers: client and server. The client mainly includes three functional modules: ICD data design, user permission management, and version management; the server is divided into four core support modules: data access interface, data synchronization processing, historical data management, and user session management.

[0057] The data design module primarily handles the creation, editing, retrieval, and export of various ICD data. This module interacts with users through a graphical interface, guiding them to input and set data attribute information and relationships. On the backend, it accesses the database to perform CRUD operations on various ICD data. Simultaneously, the access permission management module determines user permissions for various resources in real time, ensuring data security.

[0058] The version management module focuses on managing ICD data modification history and project data versions. This module interacts with users through a graphical interface, providing historical browsing, version settings, and version data comparison. By accessing the ICD database and version information repository, it stores and updates data snapshots, enabling full lifecycle data traceability.

[0059] The access control module is responsible for setting and determining user access permissions. This module interacts with users through a graphical interface, supporting user management, permission creation, permission allocation, and permission determination. It also achieves persistent storage of permission information through database access and provides standardized access interfaces, offering real-time permission determination services to the data design and version management modules.

[0060] The data access interface module adopts mature object-relational mapping (ORM) technology, which encapsulates the complexity of underlying database operations and is used for effective and reliable access to the ICD database, improving the system's portability.

[0061] The data synchronization processing module supports concurrent operations of the ICD database by multiple users through an efficient data synchronization processing mechanism. It uses locking mechanisms or transaction management to ensure data consistency and avoid conflicts in editing by multiple users.

[0062] The historical data management module stores timestamps for ICD data modifications, providing a precise time stamp for each data change record and a traceability mechanism for the entire lifecycle of ICD data, supporting data state recovery at any point in time.

[0063] The user session management module provides a session management mechanism for all users accessing the server through the ICD client, maintains user login status, ensures that multiple users can access the ICD database reasonably and normally online, and prevents unauthorized intrusion.

[0064] The ICD data editing interface serves as the primary entry point for ICD designers, and its rational design significantly impacts software usability. The ICD management software's interface layout employs a classic four-zone structure:

[0065] The menu bar is located at the top of the editing interface and provides various software function operation options in the form of multi-level drop-down menus, such as file operations, editing tools, view switching, and help documentation.

[0066] The toolbar is located below the menu bar and provides quick access to some key software functions in the form of icons, such as frequently used operations like creating, saving, importing, and exporting, thereby improving operational efficiency.

[0067] The ICD data editing area, located at the bottom right of the toolbar, is the core working area. The system dynamically loads dedicated editors based on different ICD data types (such as bus, data block, signal, etc.), providing a professional editing environment for data attribute information and relationships.

[0068] The Resource Manager view, located at the bottom left of the toolbar, is the main entry point for users to access ICD data. It flexibly displays all ICD data and their hierarchical relationships in a tree structure, supporting drag-and-drop operations. This view employs a lazy loading mode, allowing users to flexibly define the search structure; the system only loads sub-data when nodes are expanded, effectively reducing the initial loading load on the system.

[0069] The database resource view on the main interface of the ICD management software serves as the primary entry point for users to input ICD data, providing a navigation structure for all ICD data. This view mainly contains data types such as project, system, device, bus, data block, signal, and domain.

[0070] A project is the highest-level ICD management unit specified by the ICD management software. Users need to design subsystems and various types of ICD data under the project. A project is usually equivalent to a specific aircraft model.

[0071] A system refers to various airborne systems (such as electromechanical systems and avionics systems), which have attributes such as specification number, name and description, and support nested subsystem definitions to adapt to complex system architectures.

[0072] Devices are defined within a system, and a system can contain multiple devices. Each device has attributes such as specification number, name, and description. Each device node contains various software and hardware information and is the core carrier of ICD definition.

[0073] Bus definitions are located under the device's "Software" - "Output" directory, supporting the definition of various bus types such as 1553B bus, 422 / 485 bus, and CAN bus. Within the bus definition, source and destination device attributes can be set, specifying the data flow direction. Multiple data blocks and signal information can be defined under the bus definition.

[0074] Signals are typically divided into several parts to represent different logical meanings; this logical division is called a domain. A domain is the basic unit of signal analysis, defining the physical meaning of a specific bit.

[0075] To ensure the standardization of ICD data, the platform has built-in multi-dimensional ICD verification rules, including:

[0076] Invalid character input validation: For example, some data attributes can only be entered as numbers, and other characters are considered invalid and blocked.

[0077] Data length validity check, for example, the total length of the ARINC422 signal cannot exceed the agreed length of the 422 data block to which it belongs;

[0078] Data content validity checks, such as ensuring that signal definitions under data block 422 are not empty, ensure data integrity.

[0079] The validation results are displayed centrally in the Issue View. The Issue View uses a list format to comprehensively list all potential syntax or logic problems. The list is typically divided into two columns: the first column lists the names of the problematic data, and the second column provides a detailed description of the potential problem. Users can quickly open the corresponding data editor by double-clicking on an issue record in the Issue View to manually review and correct the displayed issues.

[0080] Before conducting system integration testing of complex airborne equipment, it is essential to collect and manage the ICD information for the entire model. This information includes A664 bus data from the backbone network and A429, discrete, and analog data from subnets, typically stored in XML files, databases, and other discrete ICD files. To address this issue, this invention employs EMF (Eclipse Modeling Framework) technology, an open-source Java framework and code generation tool for building applications based on structured models. The platform utilizes EMF to convert data specifications into Ecore models. This conversion automatically generates code for reading and writing XML-formatted ICD data. A precise mapping exists between data specifications and Ecores; for example, constrained data type declarations can be mapped to Ecore EAttributes. Through this mapping, EMF provides the ability to automatically convert data specifications into Ecores, thereby enabling the automatic generation of XML file reading and writing code. This mechanism effectively ensures the correctness of XML data access and guarantees the integrity and consistency of the imported data's data type and content.

[0081] The above export procedure ensures the smooth import of XML-formatted ICD data related to complex airborne equipment systems into the ICD editing tool, enabling storage and management according to the ICD model architecture and data format provided by the tool. XML-formatted ICD data covers a wide range of information, including A664 bus definitions, ARINC429 protocols, A664 network virtual link control files, A664 end-system configuration files, and discrete and analog signal data. The EMF framework not only provides modeling capabilities but also enhances the fine-grained data sharing capabilities between tools and applications, achieving robust integration at the user interface and file level.

[0082] For data stored in an external database, the platform accesses the database via its API and retrieves data from the tables. The database typically stores ICD information in tabular form. Taking the A429 data definition table as an example, detailed analysis of the table reveals crucial information required for ICD definition, such as packet names, parameter names, offsets, and lengths. This information allows for the reconstruction of ICD data. Furthermore, by mapping the data to the data structure of the ICD editing tool, the data is accurately imported into the tool. The imported data model is based on the EMF model framework, which provides a complete verification framework for validating instance data. By automatically converting data specifications into a model, constraints and specifications can be directly transformed into verifiable conditions. These established model constraints enable automated data verification.

[0083] To provide a standard data interface for integrated testing of complex airborne equipment, the platform supports exporting ICD data in standard XML format. This not only provides direct input for complex airborne equipment testing platforms but also serves as a standard interface file format for other exciters or simulation environments involved in the integration. The data format in the XML file fully reuses the data format defined in the ICD editing tool, and data export is implemented programmatically.

[0084] The top-level data elements of the project data file mainly include (sub)system, preset values, and unit type information. The (sub)system element contains subsystem and equipment information; the preset value element contains parameter settings such as system status; and the unit type element contains several unit definition information. The specific content structure is as follows:

[0085] In (sub)system elements, with<Core:ISystem...> It begins with an element identifier, whose child elements include subsystems and devices;

[0086] In the device element, with<devicesID=""...> The first element is the identifier, and its child elements contain the bus ports;

[0087] In the bus port element, with<softwareAdaptersxsi:type=""ID=""...> The first element is the identifier, and its child elements contain data blocks or non-bus signals.

[0088] In the data block element, with<blocksID=""Name=""...> The first element is the identifier, and its child elements contain signals;

[0089] In signal elements, with<signalsID=""Name=""...> The first element is the identifier, and its child elements contain fields.

[0090] In the domain element, with<fieldsxsi:type="Core:BcdField"ID=""... / > Used as a marker for the beginning element;

[0091] In the preset value element, with<Core:InitValuekey=""> The starting element identifier contains preset parameter content.<valuesindex=""value="" / > .

[0092] Access control is a key feature of this platform, allowing users to set different permission combinations for different levels of ICD data to ensure data security.

[0093] Permission definitions include the following four categories:

[0094] Read access definition: Allows users to view various attributes or related information of ICD data;

[0095] Writable permission definition: Allows users to modify the attributes or associations of existing ICD data. In addition, it also allows the creation of the included ICD data.

[0096] Data export permission definition: Allow users to export Word documents and XML files;

[0097] Version control permission definition: Allows users to manage project data in versions, including setting version tags and viewing historical data.

[0098] The permission assignment process follows these steps:

[0099] First, select the target data that needs to be set. The target data can be a project, system, or device node. Then, select the "Permission Settings" function.

[0100] In the pop-up permissions dialog box, set permission combinations for each user, such as read, write, data export, or version control.

[0101] The specific rules for permission allocation are as follows:

[0102] All ICD data has three states: invisible, readable, and writable.

[0103] All project data is not visible to regular users by default;

[0104] Except for "Administrator," which is the default system administrator, all other accounts are ordinary users by default.

[0105] System administrators can grant "administrator" privileges to other users, making them system administrators.

[0106] System administrators can grant other users "management" permissions based on projects, making them project administrators;

[0107] The system administrator is responsible for assigning operation permissions to other users;

[0108] Project administrators have read permissions for project data by default, and can also set various read and write permissions for their respective projects for ordinary users;

[0109] System administrators or project administrators can set permissions based on three data levels: project, system, and device. System permissions can be nested, allowing different combinations of read and write permissions to be set for ordinary users.

[0110] Export permission settings for Word documents and XML files: If export permissions are set for ordinary users, then those users can perform export operations on any data for which they have read permissions;

[0111] Regarding version control permission settings: If version control permissions are set for ordinary users, those users can perform version setting operations, while browsing historical data is determined based on readability permissions. The above description is merely a specific implementation 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 scope of the technology 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 complex airborne equipment system integration test ICD management platform, characterized in that, include: The data design module is configured to provide a graphical user interface, responding to user operations to complete the creation, editing, retrieval, and export of ICD data, including ARINC429, ARINC664 bus, discrete quantities, and analog quantities. The version management module is configured to record timestamps for project data and respond to commands to set version tags for project data, browse historical records, and compare version differences. The access control module is configured to determine the legitimacy of user requests to access ICD data based on predefined access combinations. The data access interface module uses object-relational mapping technology and is configured to perform CRUD operations on the underlying ICD database. The data synchronization processing module is configured to support concurrent operations by multiple users and ensures data consistency in the ICD database through locking mechanisms or transaction processing. The historical data management module is configured to store ICD data modification records with timestamps, providing a traceability mechanism for the entire data lifecycle.

2. A complex airborne equipment system integration test ICD management software architecture, characterized in that, The MVC design pattern, based on the EMF modeling framework, is adopted, including: The presentation layer includes a menu bar, toolbar, a resource manager view displayed in a tree structure, and an ICD data editing area; the presentation layer is configured to receive user input and send data change requests to the business logic layer. The business logic layer includes a data import unit, a data export unit, a permission determination unit, and a version control unit. The data import unit is configured to map external ICD files to internal EMF model instances using an XML parsing engine. The data export unit is configured to serialize the EMF model instances into standard XML files conforming to a preset schema, or to convert the data into Rhapsody / Simulink model format. The permission determination unit is configured to intercept business operation requests and return a determination result based on the matching relationship between user roles and data levels. The persistence layer includes a database access interface and a historical data repository. The database access interface is configured to shield the differences between the underlying databases through ORM technology. The historical data repository is configured to store data snapshots with timestamps to support the backtracking and export of any historical version.

3. A method for managing the integrated circuit detection (ICD) of complex airborne equipment systems, implemented based on the equipment described in claim 1 and the software architecture described in claim 2, characterized in that... Includes the following steps: S1: In response to the user's import command, read the external ICD data source; map the read data into an internal unified EMF model instance through the EMF modeling framework, and use the built-in verification framework to perform standardization verification on the instance data; S2: Display the tree structure of ICD data in the graphical interface; respond to the user's request to edit data of a specific node, call the permission management module to determine whether the user has write permission for that node; if the user has permission, allow the user to modify the data attributes and relationships through the wizard or editor, and store the modification operation with the timestamp. S3: In response to the user's version release command, the current ICD data snapshot is tagged with a version label and fixed; in response to the user's comparison command, data snapshots from two different historical moments or different version labels are extracted, differential analysis is performed, and a comparison report is generated. S4: In response to user export commands, convert ICD data into standard XML format files, or automatically convert it into Rhapsody models or Simulink models, for use by downstream integration testing, final inspection, or military inspection systems.

4. The complex airborne equipment system integration test ICD management platform according to claim 1, characterized in that, The data design module is also configured with a Lazy mode retrieval tree building unit, which is configured to allow users to customize the hierarchical relationship of the retrieval structure and dynamically load the child node data under the node when the user expands the tree node.

5. The ICD management software architecture for complex airborne equipment system integration testing according to claim 2, characterized in that, The business logic layer also includes a plug-in management unit, configured to load new bus protocol parsers or non-bus quantity processing logic through a standardized plug-in interface to support the dynamic expansion and reuse of ICD data for different aircraft models.

6. The ICD management software architecture for complex airborne equipment system integration testing according to claim 2, characterized in that, The permission allocation rules executed by the permission determination unit include: The system administrator has complete control over all data; By default, project administrators have read permissions for the data of their assigned project and can assign read and write permission combinations for that project to ordinary users. The read / write permission combination includes readable permission, writable permission, data export permission, and version control permission; Data export permissions take effect only if read permissions are available.

7. The ICD management method for complex airborne equipment system integration testing according to claim 3, characterized in that, The external ICD data source in step S1 includes an XML file conforming to a predefined XMLSchema, or a relational data table containing data packet name, parameter name, offset, and length information; the normative verification in step S1 includes data type verification, value range verification, and integrity verification of association relationships.

8. The ICD management method for complex airborne equipment system integration testing according to claim 3, characterized in that, The standard XML format file exported in step S4 has a hierarchical element structure, including system elements as top-level elements, preset value elements, and unit type elements; The system elements are hierarchically divided into device elements, bus port elements, data block elements, signal elements, and domain elements, and each element is configured with a unique ID.

9. The complex airborne equipment system integration test ICD management platform according to claim 1, characterized in that, The device is also equipped with an automatic backup module, which automatically triggers a database backup operation and stores the backup file to an off-site disaster recovery node when a structural change in the database is detected or a preset time interval is reached.

10. The ICD management method for complex airborne equipment system integration testing according to claim 3, characterized in that, Step S2 also includes user session management steps: when a user accesses the server through a client, a user session connection is established and maintained; when a user is detected to have been inactive for a long time or has been abnormally disconnected, the system resources occupied by the session are released.

Images