Model-based avionics system architecture design method

Abstract

This invention discloses a model-based avionics system architecture design method, comprising the following steps: determining the design requirements of the avionics system architecture; establishing meta-models required by the avionics system domain in the functional layer, logical layer, physical layer, and message layer respectively; wherein, the meta-model includes model elements, model relationships, model attributes, and model constraints of the avionics system domain; constructing a mapping matrix between design requirements and functions, designing models for each layer, establishing vertical mapping relationships between models at each layer, and forming a complete avionics system architecture model; wherein, the layer models, from top to bottom, sequentially include a functional model, a logical model, a physical model, and a message model. This invention conducts avionics system architecture design modeling based on design requirements and meta-models at each layer, comprehensively implementing and covering requirements, and configuring resources on multi-layer models to ensure that the current system architecture meets requirements for security, reliability, and real-time performance.

Description

Technical Field

[0001] This invention relates to avionics system architecture design, and particularly to a model-based avionics system architecture design method. It is applicable to the distributed collaborative design of avionics system architecture, supports system architecture design and analysis from four layers: functional, logical, physical, and messaging, comprehensively implements, covers, simulates, and verifies requirements, and configures, evaluates, verifies, and analyzes resources on this four-layer architecture to ensure that the current system architecture meets the requirements of security, reliability, and real-time performance. Background Technology

[0002] Avionics systems have evolved from independent to integrated, comprehensive, and highly integrated systems, from independent subsystems to a hierarchical structure with centralized control and distributed processing.

[0003] The open, integrated modular avionics (IMA) system architecture is a major trend in avionics system development today, aiming to reduce aircraft lifecycle costs, integrate avionics system applications, improve system performance, and address the challenges of upgrading individual avionics system applications. Essentially, an integrated modular avionics system is a distributed computing system that employs an open architecture and standardized, universal design. This improves system compatibility and portability, and provides high scalability and maintainability, reducing lifecycle costs and integrating and supporting avionics system applications at different critical safety levels.

[0004] The Integrated Modular Avionics Platform (IMP) is a shared, flexible, and reusable platform of hardware and software resources. It can host various application software to perform a variety of aircraft onboard functions. The IMA system is a distributed real-time computer network that provides a shared resource, partitioned according to multiple avionics functions to improve the overall system's utilization of common resources, while employing redundancy mechanisms to enhance its reliability.

[0005] The continuous development and evolution of software and microelectronics technologies have introduced more and more new aircraft system functions, while also exponentially increasing the complexity of airborne systems. The original distributed architecture can no longer meet the requirements of modern commercial aircraft for "lightweight and integrated" systems. Therefore, a high-performance computing platform that can simultaneously host multiple applications using a set of distributed network architecture processors has emerged—namely, the IMA system.

[0006] The IMA system adopts a comprehensive, modular, and open system architecture, featuring a universal integrated processing cabinet, a universal operating system, universal fault-tolerant processing, central power supply, and flexible aircraft application interfaces. While it does not provide any aircraft-level functionality itself, it offers data computation, data transmission, and data conversion capabilities, and supports health monitoring and fault management.

[0007] English Technical Terminology Comparison Table

[0008] English technical terms Chinese technical terms Full English name IMA Integrated modular avionics Integrated Modular Avionics

[0009] English technical terms Chinese technical terms Full English name ICD Interface Control Document Interface Control Document ATA Air Transport Association Air Transport Association FDAL Functional Development Assurance Level Functional Development Assurance Level LRU field replaceable unit Line Replaceable Unit ADRU Atmospheric Data Reference Unit Air Data Reference Unit IDU Integrated display unit Integrated Display Unit PFD Main flight display Primary Flight Display

[0010] Existing avionics system architecture design and analysis processes utilize natural language to describe the system architecture and employ drawing tools such as Visio to visualize the visual effects, organizing and saving the data as a collection of files. However, this design approach lacks capabilities for atomic data storage, analysis, and simulation, and its support for collaborative design is relatively weak. Furthermore, during architecture analysis, some architectural information must be re-entered into other analysis tools before proceeding with subsequent work, resulting in a significant amount of repetitive work. Summary of the Invention

[0011] The objective of this invention is to provide a model-based avionics system architecture design method, through which:

[0012] 1. Build a domain-unified model, and under a unified model and semantics, determine system modeling guidelines and design processes;

[0013] 2. A hierarchical system design approach;

[0014] 3. Integrate the system architecture design and analysis processes, and design them in a unified data center, eliminating the need for data import, export, and conversion between different tools;

[0015] 4. Enable bidirectional loop and optimization iteration in system design and analysis, allowing for rapid design and feedback;

[0016] 5. Supports distributed system architecture design and team collaboration, accelerating the system design process.

[0017] The objective of this invention is achieved through the following technical solution:

[0018] 1. A model-based avionics system architecture design method, comprising the following steps:

[0019] Determine the design requirements for the avionics system architecture;

[0020] The meta-models required for the avionics system domain are established in the functional layer, logic layer, physical layer, and message layer, respectively. The meta-models include model elements, model relationships, model attributes, and model constraints of the avionics system domain.

[0021] Construct a mapping matrix between design requirements and functions, design models for each layer, establish vertical mapping relationships between each layer of models, and form a complete avionics system architecture model; the layer model contains, from top to bottom, functional models, logical models, physical models and message models; the avionics system architecture model contains at least two layers of models.

[0022] The beneficial effects of this invention are as follows:

[0023] 1. Achieve traceability between functions and requirements.

[0024] 2. Model reuse and improved efficiency: The meta-model supports specific modeling and improves efficiency; the output model can support hierarchical modeling.

[0025] 3. Consistency: Consistency between the output model and the ICD (Interface Control Document) and documentation.

[0026] 4. Relational databases are used to store modeling data, making all information atomic and abandoning the previous document-based system design; at the same time, the database supports access from different client tools for collaborative design.

[0027] 5. Domain design operations are modularized to reduce overly fragmented atomic designs and improve work efficiency; this is reflected in decomposition design, interaction design, and change design.

[0028] 6. By leveraging model specifications, inconsistencies in the design process can be identified in batches, which is far more efficient than document-based design. Document-based design relies heavily on manual review to uncover problems.

[0029] 7. By leveraging system simulation and simulating the dynamic design process, system design flaws can be uncovered more intuitively; the effect far surpasses that of static documents.

[0030] 8. Generate various reports in batches to ensure consistency between reports and design information, and allow designers to focus their energy on design and analysis, rather than writing various reports. Attached Figure Description

[0031] Figure 1 A flowchart of a model-based avionics system architecture design method.

[0032] Figure 2 A schematic diagram of a model-based avionics system architecture design method.

[0033] Figure 3 Design process of avionics system architecture meta-model.

[0034] Figure 4 Avionics system architecture model design process.

[0035] Figure 5 A schematic diagram of the avionics system architecture model in the model-based avionics system architecture design method.

[0036] Figure 6 Object relationships in avionics system architecture modeling.

[0037] Figure 7 Avionics system architecture design process.

[0038] Figure 8 Overall architecture diagram for modeling rule validation.

[0039] Figure 9 A diagram showing the progress and results of the model rule validation process.

[0040] Figure 10 A schematic diagram of the overall framework structure of the software system.

[0041] Figure 11 Navigation system function breakdown diagram.

[0042] Figure 12 Provides a breakdown of functions for calculating and outputting calibrated airspeed.

[0043] Figure 13 Provides a single-channel calculation and output function for calibrated airspeed.

[0044] Figure 14 Setting functional attributes.

[0045] Figure 15 Interactive diagram of the airspeed calibration function.

[0046] Figure 16 Functional parameter attribute settings.

[0047] Figure 17 Logical definition of atmospheric data system.

[0048] Figure 18 Logical definition of a single-channel atmospheric data system.

[0049] Figure 19 Logical interaction for calibrating airspeed display in atmospheric data systems.

[0050] Figure 20 Physical definition of an atmospheric data system.

[0051] Figure 21 The physical architecture connecting the Atmospheric System ADRU to the IMA Platform RDIU.

[0052] Figure 22 Physical architecture of atmospheric data system.

[0053] Figure 23 Physical architecture of the IMA system.

[0054] Figure 24 Message architecture model diagram.

[0055] Figure 25 A four-layer architecture model diagram of the airspeed indicator function. Detailed Implementation

[0056] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0057] Please see Figures 1-2 This embodiment provides a model-based avionics system architecture design method, which can be implemented in any computer language, and includes the following steps:

[0058] S100. Determine the design requirements for the avionics system architecture.

[0059] Design requirements include standard requirements, interface control documents, constraint requirements, and resource configuration requirements.

[0060] Specifically, the methods for determining the design requirements of avionics system architecture include:

[0061] Obtain standard requirements from avionics system architecture design standards, design information, and requirements specifications;

[0062] Taking the original requirements of the avionics system architecture as input, the functional interfaces and hardware / software interfaces of the avionics system architecture are defined from the perspective of implementation to form an Interface Control Document (ICD). The constraints (including performance, safety, etc.) and resource configuration requirements corresponding to each function, software, and hardware are obtained.

[0063] Design requirements are stored in DOORS, and compliance verification of design requirements is controlled by DOORS.

[0064] S200. Establish the meta-models required for the avionics system domain in the functional layer, logical layer, physical layer, and message layer, respectively. The meta-models include model elements, model relationships, model attributes, and model constraints of the avionics system domain.

[0065] Specifically, please see Figure 3 The method for establishing a meta-model includes the following steps:

[0066] Methods for establishing meta-models include:

[0067] S210. Define the meta-objects of each meta-model (e.g., define rectangles, squares, diamonds, etc.);

[0068] S220. Define the relationships between meta-models (it should be noted that the relationship between multiple meta-models is also a meta-model). The relationships between meta-models include the constraints between each layer in the four layers of functional, logical, physical, and message, as well as the constraints between layers. This can prevent the failure to meet requirements or the inability to make design adjustments in the architecture design and modeling of each layer, and prevent errors in the mapping matrix between layers;

[0069] S230. Define the attributes of the metamodel, set the constraint rules for the attributes (e.g., names must be longer than 8 characters, weight units must be kg or g, and values ​​must be positive), and classify the attributes (e.g., ID and name are common and are classified as general attributes; volume, weight, power consumption, reliability, availability, latency, and restart time are one type of attribute and are classified as performance attributes; security is one type of attribute and is classified as security attributes; processing resources, storage resources, and communication resources are one type of attribute and belong to resource attributes; ...).

[0070] S240. Establish a metamodel based on the objects, relationships, attributes, and constraints of the metamodel. The established metamodel is an avionics domain metamodel conforming to the SysML specification.

[0071] It's important to note that a metamodel defines model elements, classes, and instances. A metamodel is essentially a database, including data parameters and attributes. For example, the rotational speed of a helicopter (when its flight speed is 0) and the flight speed of a jet aircraft (when its rotational speed is zero) would require two separate metamodels. The cargo capacity and passenger capacity of an aircraft can be represented by one metamodel, or two metamodels can be defined based on experience.

[0072] S300: Construct a mapping matrix between design requirements and meta-models to obtain the models at each layer, establish the vertical mapping relationship between each layer model, and form a complete avionics system architecture model; the layer model contains, from top to bottom, a functional model, a logical model, a physical model, and a message model; the avionics system architecture model contains at least two layers of models.

[0073] This solution links functions and design requirements, enabling traceability from function to requirement. Establishing a vertical mapping relationship between each model layer ensures a complete traceability relationship: requirement <-> functional model <-> logical model <-> physical model <-> message model.

[0074] Specifically, please see Figures 5-6 In step S300, a mapping matrix from function to logic and a mapping matrix from logic to physical are also constructed, which facilitates model changes.

[0075] Please see below. Figures 4-6 ,as well as Figure 7 Step S300 specifically includes the following steps:

[0076] S310. Functional Architecture Design and Modeling: Based on design requirements, define the functions of the avionics system architecture using a functional hierarchy model and set the attributes of the functions; decompose the functions to obtain the functional decomposition diagram of the functional model, and decompose the design requirements into a hierarchical tree structure of functions; determine the functional parameters based on the results of defining and decomposing the functions, set the functional parameter attribute information, and perform functional interactions to obtain the functional interaction diagram of the functional model; define the interface information for interaction between functions, analyze the interaction mechanism when functions are abnormal, and supplement and update the interface information.

[0077] Please see Figures 5-7 In step S310, the functional decomposition diagram describes the functional components of the ATA system's internal functional decomposition after the aircraft-level functions are decomposed hierarchically down to the avionics system functions. Functional decomposition is used to decompose system requirements into a hierarchical, tree-like functional structure.

[0078] In a functional interaction diagram, the parameters of the functional interaction are first defined, and then the functional interaction relationships are constructed. Functional interaction relationships are used to describe the interaction of functional parameters between different functions.

[0079] Functional architecture design modeling also includes defining common functions of the avionics system to support reuse during iteration.

[0080] It should be noted that the purpose of functional architecture design is to achieve traceability and coverage of functional requirements, solve the problem of consistency between design and requirements, and solve the problem of maintaining interface information consistency among multiple subsystems by having avionics system suppliers, in conjunction with subsystem suppliers, define the implementation mechanism and information interface modeling process between subsystems according to the ARINC standard of the corresponding system.

[0081] S320 Logical Architecture Design and Modeling: Based on design requirements, the logical components of the avionics system architecture are defined using the meta-model of the logical layer, and the attributes of the logical components are set; functions are assigned to the logical components to obtain the logical definition diagram of the logical model; logical parameters are determined based on the definition and assignment results, the attributes of the logical parameters are set, logical interactions are performed, and the logical interaction diagram of the logical model is obtained; functional parameters are assigned to logical parameters, and the interfaces of functional interactions are assigned to the interfaces of logical interactions to obtain the logical interaction diagram of the logical model.

[0082] Please see Figures 5-7In step S320, the logic definition diagram describes the logical components (hardware and software configuration items) that implement the functions. Each hardware and software configuration item can carry multiple functions. If a function cannot be assigned to a specific hardware and software configuration item, it means that the function needs to be further decomposed. Here, logic refers to system configuration items, and logic decomposition decomposes the coarse-grained logic items into a tree structure.

[0083] In a logical interaction diagram, the parameters of the logical interaction are first defined, and then the logical interaction relationships are constructed to describe the data transmission and reception relationships between different logical items. A functional parameter can be decomposed into multiple logical parameters.

[0084] In step S320, the logical architecture design modeling can also create the message architecture's residency functionality.

[0085] In step S320, the logical architecture design modeling also includes defining common logical components of the avionics system to support reuse during iteration.

[0086] It should be noted that the purpose of logical architecture design is to ensure that all functions and their corresponding requirements are feasible, and to solve the problem of consistency between software interface parameters and system interface parameters by defining the boundaries and parameter interfaces between software.

[0087] S330. Physical Architecture Design and Modeling: Based on design requirements, the physical layer meta-model is used to define the physical equipment field replaceable units and common physical equipment of the integrated modular avionics platform of the avionics system architecture, and to set the attributes of the physical equipment; logical components are assigned to the physical equipment field replaceable units to obtain the physical definition diagram of the physical model; physical equipment cross-linking is performed based on the definition and assignment results to obtain the physical architecture diagram of the physical model, including: determining the physical bus and physical equipment type of the physical equipment of the avionics system architecture based on the physical equipment field replaceable units of the avionics system architecture, assigning the logical interaction interface to the bus interface of the physical equipment field replaceable units, setting the attributes of the physical bus and interface, and obtaining the physical architecture diagram of the physical model.

[0088] Further, please see Figures 5-7 In step S330, the avionics LRU class is described in the physical definition diagram, which describes the class of physical device entities in the system. The physical architecture diagram describes the connection status of the physical devices; the physical bus can be ARINC 664, ARINC 429, ARINC 825, analog, or discrete, etc. Physical device instances are constructed, device ports are created, and the connection relationships between physical devices are established using the bus. The message paths and parameters for interaction between physical devices are set, and the sending and receiving parameters of the message architecture are created.

[0089] In step S330, the physical architecture design modeling also includes defining common physical devices for the IMA platform to support reuse during iteration.

[0090] It should be noted that the purpose of physical architecture design is to ensure full coverage of functional interface requirements and to solve the problem of maintaining physical connection coordination between multiple subsystem devices by defining the boundaries and bus interfaces between physical device units.

[0091] S340. Message Architecture Design and Modeling: Based on design requirements and the attributes of logical components, determine the residing functions and applications of the message model, and set the attributes of the message model; configure the residing functions and applications of logical components, and assign the residing functions and applications to the physical equipment field replaceable units; determine the sending parameters and receiving parameters of the message model based on the attributes of the physical equipment field replaceable units and the logical parameters transmitted between logical components, and set their attributes; package the messages of the avionics system architecture according to the bus type of the physical equipment field replaceable units when transmitting sending and receiving parameters.

[0092] Please see Figures 5-7 In step S340, the message architecture design modeling also includes: assigning residency functions to physical devices and assigning send and receive parameters to bus interfaces.

[0093] It should be noted that the purpose of message architecture design is to provide a model foundation for ICD design. This is achieved by mapping logical components to resident functions and defining the send and receive parameters used to compose ARINC 664, ARINC 429, ARINC 825, analog, and discrete message packet structures. Essentially, it abstracts the data transmission and reception between terminal nodes, providing input for the message packet assembly and resource configuration processes in the ICD design process. The message architecture describes the network links through which data interacts between the resident functions of the sender and receiver. Furthermore, the message frame encoding format for this data will be confirmed in subsequent design steps.

[0094] When designing the models of each layer, if one of the layer models cannot meet the design requirements and / or the design requirements are adjusted, the architectural design and modeling of the layer model above that layer is traced back to, and the layer model above is modified and adjusted. The adjustments include adjusting the model attribute information, merging and splitting model elements, and adjusting the vertical allocation relationship of the model.

[0095] In step S320, if the logical architecture design model cannot support the implementation of the function, or if design adjustments occur, the process will be reversed back to the functional architecture design model in step S310.

[0096] In step S330, if the physical architecture design model cannot support the logical implementation or if design adjustments occur, the process will revert to the logical architecture design model in step S320.

[0097] In step S340, if a message path cannot be built or a design adjustment occurs during message architecture design modeling, the process will revert to the physical architecture design modeling in step S330.

[0098] It should be noted that the purpose of going back in time is to make changes so that the system conforms to the design concept from top to bottom. However, it is permissible to first draft the physical architecture of the publication based on project needs, and then carry out the design of functions, logic and messages.

[0099] The following steps are included after step S300:

[0100] S400 verifies the architecture model of the avionics system and generates a verification report. It categorizes and integrates the data of the architecture model of each avionics system according to the data types in each layer of the model, exports the model description interface control document, and generates resource configuration.

[0101] S500 performs calculations and evaluations on resource allocation to determine whether it meets requirements such as real-time performance and reliability.

[0102] S600: Import the required resource configuration information into the architecture model;

[0103] S700: Obtain the configuration data of the current avionics system architecture model, compare the current avionics system model with the previous baseline avionics system architecture model, and generate a baseline data comparison report.

[0104] This embodiment uses a four-layer architecture as an example. In practical applications, each layer can be further subdivided. For example, the functional architecture design can be changed to an avionics-level functional architecture design or an avionics system functional architecture design, or other subdivision methods can be used. Different subdivision methods are used to express different purposes. The four-layer architecture proposed in this embodiment is a more general approach that can support more situations. The avionics system architecture model designed through this embodiment can meet the following requirements:

[0105] (a) Support for model changes:

[0106] In step S300, model changes are mainly used to describe the adjustment of model hierarchy, model merging, and model splitting in the functional layer and logic layer, while also taking into account the readjustment of vertical allocation relationships.

[0107] (1) Scenario 1: Functional Merging

[0108] Specifically, the following steps are included:

[0109] 1. Select two functions to be merged;

[0110] 2. Click the merge menu;

[0111] 3. Define the merging party and the merged party, and confirm the primary and secondary relationships;

[0112] 4. Preview of functional decomposition relationships, showing the effect diagrams before and after the merger;

[0113] 5. Display of affected elements, mainly including: affected model diagrams, affected functions, and affected parameters;

[0114] 6. Adjust the vertical relationship of the model, adjusting the allocation relationship between functions and logic;

[0115] 7. Confirm model adjustments;

[0116] 8. Update the model data and model diagram.

[0117] Furthermore, the adjustment of the vertical relationship of the model in step 6 specifically includes the following steps:

[0118] Based on the logic in step 5, extract all affected functions;

[0119] Extract the leaf node functions from these functions; only the leaf node functions will be mapped to logical items.

[0120] Display the mapping table from functionality to logic, and adjust it according to the actual mapping relationship;

[0121] Check the mapping relationship between functional ports and logical ports, check whether the relationship is maintained, and supplement any missing ones.

[0122] Furthermore, regarding step 7, the following adjustments are made:

[0123] Adjust the hierarchical relationship of the model to ensure that the hierarchical relationship of the model is adjusted according to the merged relationship;

[0124] Adjust the model interaction relationships to ensure that the interaction relationships of the models are carried out according to the new model hierarchy.

[0125] (2) Scenario 2: Functional decomposition

[0126] Specifically, the following steps are included:

[0127] 1. The user selects a function;

[0128] 2. Select function splitting;

[0129] 3. Input the functions to be added and confirm the allocation relationship of the function parameters;

[0130] 4. Preview the functional decomposition relationship to see the effects before and after the decomposition;

[0131] 5. Display of affected elements, mainly including: affected model diagrams, affected functions, and affected function parameters;

[0132] 6. Adjust the vertical relationship of the model, adjust the allocation relationship between functions and logic to ensure that the model rules are not violated (one function corresponds to only one logic, and one logic can correspond to multiple functions);

[0133] 7. Confirm model adjustments;

[0134] 8. Update the model data, including updating the content of the affected model diagrams.

[0135] Furthermore, the adjustment of the vertical relationship of the model in step 6 specifically includes the following steps:

[0136] Based on the logic in step 5, extract the affected functions;

[0137] Extract the leaf node functions from these functions; only the leaf node functions will be mapped to logical items.

[0138] Display a mapping interface, showing the original mapping relationship, which the user can adjust themselves;

[0139] Check the mapping relationship between functional ports and logical ports, check if the relationship is still maintained, and supplement any missing ones.

[0140] Furthermore, regarding step 7, the following adjustments are made:

[0141] Adjust the hierarchical relationship of the model to ensure that the hierarchical relationship of the model is adjusted according to the relationship after decomposition;

[0142] Adjust the model interaction relationships to ensure that the interaction relationships of the models are carried out according to the new model hierarchy.

[0143] (3) Scenario 3: Logical merging

[0144] The ideas and functions are similar.

[0145] (4) Scenario 4: Logical decomposition

[0146] The approach and functional breakdown are similar.

[0147] (5) Scenario 5: Model hierarchy adjustment

[0148] Specifically, the following steps are included:

[0149] 1. Select a function in the function breakdown diagram;

[0150] 2. Adjust the hierarchy to select a new parent for the chosen function;

[0151] 3. Preview of functional decomposition relationship, showing the effect diagrams before and after adjustment;

[0152] 4. Display the affected elements, the affected model diagram, functional elements, and functional parameters;

[0153] 5. Click "Confirm" to adjust the data organization and model diagram display.

[0154] (ii) Supporting model consistency:

[0155] In step S700, please combine Figure 8 Understand this, and based on the system architecture modeling rules, perform a self-check on the models within the entire system to analyze whether they conform to the modeling rules.

[0156] If all models involved in a rule meet the requirements, then the rule status is PASS; if any model does not meet the requirements of the rule, all models that do not meet the requirements of the rule will be listed and displayed in the form of logs and reports.

[0157] (1) System Design

[0158] The overall functionality consists of two modules: a model rule validation library and a model rule validation plugin. The library and plugin exchange data via a plugin interface. The library primarily provides the definition and validation functionality for model rules. The plugin offers the user interface for model rule validation, including configuration, a checklist, the validation process and results, and the ability to export validation results (document generation). Both the library and plugin utilize the framework's SDK to implement database access and logging operations.

[0159] (2) Model rule validation library

[0160] The model rule validation library is divided into three main parts: model validation rule definition, validation data provision module, and plugin interaction interface. Specifically:

[0161] The model validation rule definition is mainly used to define the standard inputs, outputs, and behaviors of rule validation, and to provide the function of calling external (third-party) rules, and to define the mapping relationship of model validation rules.

[0162] The verification data provider module provides model information data sources for verification tasks, optimizes data allocation, and centrally acquires and distributes data to verification tasks when different verification rules use the same data source, thereby reducing the performance overhead of frequent data access.

[0163] The plugin interaction interface provides a plugin access interface for plugins to obtain the model rule verification list and request model verification tasks. The model verification tasks are executed asynchronously, and the verification progress and status are fed back using callbacks.

[0164] Regarding the definition of verification rules

[0165] 1. Definition of Validation Rules

[0166] The validation rule definition describes the specific implementation of the system's rule checks. It is used for mapping between the model and validation rules, decoupling the model and validation rule implementations, and is also part of the model validation checklist returned. The validation rule definition includes the rule number, rule description, supplementary information, the DLL (Dynamic Link Library) to which the rule belongs, the rule validation namespace, the rule validation implementation class, the rule model data source (validation rule data structure definition), and the rule validation parameter types.

[0167] 2. Implementation of Validation Rules

[0168] The validation rule implementation is the actual code implementation of model rule validation. It is divided into general rules, model type-specific rules, etc., to achieve a unified validation entry point. The rule number is bound to the validation rule definition, and the reflection factory provides instances of the rule implementation class.

[0169] 3. External (third-party) rule invocation

[0170] External rule invocation refers to the invocation of model rule validation algorithms implemented by a third party. This is achieved by wrapping the external rule algorithm invocation process within the system's validation rules.

[0171] 4. Model validation rule mapping

[0172] The model validation rule mapping defines the specific rules for model validation. It binds the model to the validation rule definition and uses instances of rule implementation classes provided by the reflection factory to complete the validation of the specific rules. The model validation rule mapping uses a parent class inheritance approach to implement multi-level model validation definitions.

[0173] Regarding the validation data provider module (i.e., the data source for model rule validation)

[0174] 1. Definition of validation rule data structure

[0175] The validation rule data structure definition integrates model data of multiple rules belonging to the same category into a single data source. A unified structure type definition is used for this data source to bind the rule model data source when defining validation rules.

[0176] 2. Model Information Data Query

[0177] The model information data query and analysis task involves all validation rule definitions in the model model data source, organizing and merging all necessary data sources, and executing a unified query. This reduces frequent database access.

[0178] Regarding the plugin interaction interface

[0179] 1. Generation of Model Rule Validation Checklist

[0180] The model rule validation checklist is generated by requesting validation requests from the plugin to calculate the model rule validation checklist from the validation rule definition. This checklist calculates the validation rules associated with all requests based on the model validation rule mapping definition, outputting a tree-structured checklist based on the parent-child relationships in the model validation rule mapping. The checklist contains the specific model and its corresponding validation rule definition.

[0181] 2. Model rule validation task allocation

[0182] Model rule validation task allocation is based on the validation list submitted by the plugin. Tasks are executed asynchronously, including progress and status feedback. The main behaviors of task execution include: data source request, hierarchical execution of validation in a tree structure, and simultaneous calculation of multiple rule validations at the same level using separate threads.

[0183] (3) Model rule validation plugin

[0184] The model rule validation plugin provides a user interface for model rule validation, including model rule validation configuration, model rule validation checklist display, model rule validation process and result display, and export of model rule validation results (document generation).

[0185] 1. Model rule validation configuration

[0186] The model rule validation configuration provides users with options for configuring constant parameters and validation schedule tasks for rule validation.

[0187] 2. Model rule validation checklist display

[0188] The model rule validation checklist displays the results generated by the model rule validation checklist, and users can filter the rule items to be validated in the final step.

[0189] 3. The progress and results of the model rule validation process are displayed as follows: Figure 9 As shown.

[0190] 4. Exporting model rule validation results

[0191] The model rule validation results can be exported in document formats such as validation logs, data tables (Excel), and reports (Word / PDF).

[0192] Please see Figure 10 This is a diagram of the overall framework of the software system.

[0193] Users of the avionics subsystems are responsible for modeling the overall four-layer architecture of their respective subsystems. They then perform architectural analysis, comparison, trade-offs, model changes, architectural model compliance checks, and baseline comparisons on the designed models, generating various reports. During this process, the software system provides various auxiliary tools to help users reduce design complexity, minimize repetitive work through batch processing, improve efficiency, and accelerate the system architecture design process. Key plugin functions include:

[0194] 1. Core Basic Plugins

[0195] Responsible for interfacing with the configuration center's data interface to obtain various configuration data; providing basic functions such as model encapsulation;

[0196] 2. The architecture design supports plugins.

[0197] It assists users in designing the architecture of avionics systems, supporting functional architecture, logical architecture, physical architecture, and message architecture.

[0198] 3. Architecture analysis supports plugins

[0199] Activity diagrams and state diagrams are used to analyze the functional and logical architectures to identify various defects in the design, improve the requirements confirmation, and then feed the analysis results back to the functional and logical architectures for further improvement.

[0200] 4. Architecture Model Change and Impact Analysis Plugin

[0201] The architecture model change and impact analysis plugin supports the model change wizard process, such as splitting, merging, adjusting hierarchy, and modifying attributes of model elements, and displays the affected diagrams, elements, and attributes. It also allows users to batch modify the affected diagrams, elements, and attributes based on their selections.

[0202] 5. Architecture and requirement-related plugin support

[0203] It supports users in establishing a traceability relationship between the features they build and the requirements in the requirements management tool (DOORS), and also supports establishing a traceability relationship between plugins and user-created features obtained from the requirements management tool (DOORS), which facilitates the analysis of the impact of requirement changes and feature changes in the later stage.

[0204] 6. Architecture Model and XML Standards Check Plugin

[0205] The system checks the architecture model and the XML-based model files exported from it according to specified rules, generates an inspection report, and helps users quickly locate the problematic model and make changes to fix it.

[0206] 7. Architecture Model Version Comparison Plugin

[0207] By analyzing and comparing the technical performance parameters of multiple architectures, a better technical architecture solution can be determined.

[0208] 8. Baseline Release Process Impact Analysis Plugin

[0209] The system compares the current model information with the previous baseline model, generating a comparative analysis report to inform the user of model changes. This report primarily includes information on model additions, modifications, deletions, interactive changes, and attribute adjustments.

[0210] 9. Model design templates and model reuse plugins

[0211] It supports importing existing architecture models from other projects for reuse and customization, and allows designers to design model templates that can be directly imported into projects for reuse.

[0212] The following examples illustrate the system architecture design methodology.

[0213] According to the Air Transport Association (ATA) regulations, avionics systems may include subsystems such as display systems (ATA 31), flight management systems (ATA 34), airborne maintenance systems (ATA 45), integrated surveillance systems (ATA 34), communication systems (ATA 23), navigation systems (ATA 34), IMA systems (ATA 42), air data inertial reference systems (ATA 34), and cabin information systems (ATA 46).

[0214] Regarding the acquisition requirements in step S100:

[0215] Requirements for avionics systems are captured from standards, system architecture design information, and host requirements specifications.

[0216] Taking indicated airspeed as an example, it is known that indicated airspeed is measured by an indicating airspeed gauge. The indicating airspeed gauge works by the deformation of an open diaphragm under dynamic pressure, which drives a pointer to indicate the airspeed. The angle of the pointer's deflection depends entirely on the magnitude of the dynamic pressure, i.e., the magnitude of the indicated airspeed.

[0217] The airspeed of an aircraft is normalized to the speed of the aircraft relative to the air at standard sea level, that is, the airspeed without considering the variation of atmospheric parameters with altitude at the aircraft's location. The indicated airspeed is only related to dynamic pressure, as shown in the following formula.

[0218]

[0219] Since the dynamic pressure is the difference between the total pressure and the static pressure, the indicated airspeed can be calculated after obtaining the dynamic pressure and the static pressure.

[0220] The requirements and information for this case study primarily come from standards, system architecture design information, and host requirements specifications.

[0221] Table 1. Explanation of Design Requirements for Indicating Airspeed

[0222]

[0223]

[0224] Regarding the construction of the meta-model in step S200

[0225] The avionics meta-model used in this case study is a previously constructed meta-model that supports the IMA platform and its dwell functions, displays, flight management, airborne maintenance, communications, navigation, integrated surveillance, atmospheric data and inertial reference features. It can serve different projects and also support this project.

[0226] It should be noted that if the project does not use the IMA architecture, the existing metamodel will need to be modified as needed.

[0227] Regarding the functional architecture design modeling in step S300

[0228] Functional breakdown:

[0229] The functions are decomposed based on the functions of each ATA subsystem of avionics.

[0230] Taking the ATA34 navigation system as an example, the atmospheric data system can be decomposed into ADS (Action Data System) and SADS (Single-channel ADS) functions [the two are heterogeneous designs to improve system reliability], such as Figure 11 The diagram shows the functional breakdown of the navigation system.

[0231] ADS and SADS provide functions for calibrating airspeed, broken down as follows: Figure 12 The diagram shown is an exploded view of the functions for calculating and outputting calibrated airspeed. Figure 13 The diagram shown is an exploded view of the functions for calculating and outputting single-channel calibrated airspeed.

[0232] After functional decomposition, attributes such as the Functional Development Assurance Level (FDAL) can be set for each function. Figure 14 The settings for the functional attributes shown.

[0233] The ATA 31 display system can be broken down into providing primary flight display functionality and providing backup display functionality, among others.

[0234] Functional Interaction:

[0235] The parameters for interaction between functions are called function parameters. Based on the function definitions and decompositions, the functional interaction between the sender and receiver is determined, and the function parameters are also determined. Here, the function parameter is L206_Indicated_airspeed. See details below. Figure 15 The diagram shows the interactive functionality for calibrating airspeed.

[0236] Based on system requirements, design the functions and supplement the attribute information of the functions, such as... Figure 16 The attribute settings for the function parameters shown.

[0237] Regarding the logical architecture design and modeling in step S300

[0238] Logical definition:

[0239] Define the logical components of the design and assign functionality to them.

[0240] Based on the functional architecture information and the architecture information of the atmospheric data system, single-channel atmospheric data system, and display system, please refer to... Figure 17 The atmospheric data system at the transmitting end defines five logical components: total pressure sensor, static pressure sensor, atmospheric total pressure data conversion, atmospheric static pressure data conversion, and atmospheric data processing. The five blue boxes in the second row of the diagram correspond to these five defined logical components. Please refer to [link to relevant documentation]. Figure 18 The single-channel atmospheric data system defines five logical components: a single-channel total pressure sensor, a single-channel static pressure sensor, a single-channel atmospheric total pressure data converter, a single-channel atmospheric static pressure data converter, and a single-channel atmospheric data processing unit. The receiving end's display system defines two logical components: a primary flight display (PFD) and a backup display.

[0241] Logical interaction:

[0242] Based on the logical definitions and allocations, define the information for interaction between logical components. For example, ... Figure 19 The diagram illustrates the logical interaction for calibrating airspeed displays using an atmospheric data system. After constructing the logical interaction, the properties of the logical parameters can be set.

[0243] Regarding the physical architecture design modeling in step S300

[0244] Physical definition:

[0245] Define avionics physical unit LRUs and assign logical components to LRUs, as shown in Table 2 below. Figure 20 As shown.

[0246] Table 2 Physical Entities and Their Corresponding Classes and Instances

[0247]

[0248] Physical architecture:

[0249] Based on the communication requirements of avionics physical equipment with other equipment, the configured physical ports are determined and connected through a physical bus to form a physical architecture.

[0250] Taking the airspeed indicator function as an example, based on standards and previous design experience, the communication data characteristics are analyzed, and the physical bus interface of the LRUs in the ATA34 and ATA31 subsystems is designed. A429 physical ports are established for the physical entities of the transmitting and receiving ends, and then the transmitting and receiving ends are physically connected. The physical bus is constructed according to the naming rules of A429 messages, ultimately forming the physical bus connection relationship, such as... Figures 21-23 As shown.

[0251] Regarding the message architecture design and modeling in step S300

[0252] 1) Based on the logical and physical architecture, design the hosted function of the message architecture, assign logical components to the hosted function, and bind the hosted function to LRU.

[0253] 2) When LRU is the message sender, the logical parameters published by the interface are designed as the sending parameters of the message architecture; when LRU is the message receiver, and the sending parameters corresponding to the interface have been created, the logical parameters received by the interface are designed as the receiving parameters of the message architecture, and the relationship between the receiving parameters and the sending parameters is established.

[0254] 3) Fill in the attributes for the resident function class and instance.

[0255] 4) Fill in the attributes for the received and sent parameters.

[0256] 5) After the send and receive parameters are constructed, the messages are packaged according to the corresponding bus type.

[0257] The message architecture model diagram for the logical parameter L206_Computed_Airspeed_Data, from ATA34 NAV to ATA 31CDS, is as follows: Figure 24 As shown.

[0258] Following the above process, the avionics system architecture design for the airspeed indication function can be constructed. Taking the message sent by ADRU1 as an example, its function-logic-physical-message architecture is as follows: Figure 25 As shown, there are specific relationships between different architectural models.

[0259] It is understood that those skilled in the art can make equivalent substitutions or modifications to the technical solution and inventive concept of the present invention, and all such substitutions or modifications should fall within the protection scope of the appended claims.

Claims

1. A model-based avionics system architecture design method, characterized in that... Includes the following steps: Determine the design requirements for the avionics system architecture; The meta-models required for the avionics system domain are established in the functional layer, logic layer, physical layer, and message layer, respectively. The meta-models include model elements, model relationships, model attributes, and model constraints of the avionics system domain. Construct a mapping matrix between design requirements and functions, design models for each layer, establish vertical mapping relationships between each layer of models, and form a complete avionics system architecture model; the layer model, from top to bottom, includes a functional model, a logical model, a physical model, and a message model; the avionics system architecture model contains at least two layers of models. The design of a functional model includes the following steps: Based on design requirements, the functions of the avionics system architecture are defined using the functional layer model, and the attributes of the functions are set. Decompose the functions to obtain the functional decomposition diagram of the functional model, and decompose the design requirements into a hierarchical function tree structure. Based on the definition and decomposition of functions, determine the function parameters, set the function parameter attribute information, and perform function interaction to obtain the function interaction diagram of the function model. Define the interface information for interaction between functions, analyze the interaction mechanism when a function malfunctions, and supplement and update the interface information. The following steps are included when designing a logical model: Based on design requirements, the logical components of the avionics system architecture are defined using a logical layer meta-model, and the properties of the logical components are set. The functions are assigned to the logical components to obtain the logical definition diagram of the logical model; Based on the definition and allocation results, determine the logical parameters, set the attributes of the logical parameters, perform logical interactions, and obtain the logical interaction diagram of the logical model; The functional parameters are assigned to the logical parameters, and the interfaces for functional interaction are assigned to the interfaces for logical interaction, thus obtaining the logical interaction diagram of the logical model. The design of a physical model includes the following steps: Based on design requirements, the physical layer model is used to define the physical equipment of the avionics system architecture, the field replaceable units, and the common physical equipment of the integrated modular avionics platform, and the attributes of the physical equipment are set. The logic components are assigned to the replaceable units in the field of the physical device to obtain the physical definition diagram of the physical model; Based on the definition and allocation results, physical devices are interconnected to obtain the physical architecture diagram of the physical model, including: determining the physical bus and physical device type of the physical devices of the avionics system architecture based on the field replaceable units of the physical devices of the avionics system architecture, assigning the logical interaction interface to the bus interface of the field replaceable unit of the physical devices, setting the attributes of the physical bus and interface, and obtaining the physical architecture diagram of the physical model. The following steps are included when designing a message model: Determine the residing functions and residing applications of the message model based on design requirements and the attributes of logical components, and set the attributes of the message model. The logic components are configured with resident functions and resident applications, and the resident functions and resident applications are configured with physical equipment field replaceable units. The sending and receiving parameters of the message model are determined based on the attributes of the replaceable unit in the physical equipment field and the logical parameters passed between logical components, and the attributes of the message model are set. Based on the type of bus of the physical equipment field replaceable unit during the transmission of sending and receiving parameters, the messages of the avionics system architecture are packaged. The sending and receiving parameters are assigned to the bus interface of the replaceable unit in the physical device field to obtain the message architecture diagram of the message model.

2. The model-based avionics system architecture design method as described in claim 1, characterized in that... Design requirements include standard requirements, interface control documents, constraint requirements, and resource configuration requirements; Methods for determining the design requirements of avionics system architecture include: Obtain standard requirements from avionics system architecture design standards, design information, and requirements specifications; Taking the original requirements of the avionics system architecture as input, the functional interfaces and hardware / software interfaces of the avionics system architecture are defined from the perspective of implementation to form an interface control document, and the constraint requirements and resource configuration requirements corresponding to each function, software, and hardware are obtained.

3. The model-based avionics system architecture design method as described in claim 1, characterized in that... Methods for establishing meta-models include: Define the meta-objects for each meta-model; Define the relationships between metamodels; Define the attributes of the metamodel, set the constraint rules for the attributes, and classify the attributes; The metamodel is built based on the objects, relationships, attributes, and constraints of the metamodel.

4. The model-based avionics system architecture design method as described in claim 1, characterized in that... When designing the models of each layer, if one of the layer models cannot meet the design requirements and / or the design requirements are adjusted, the architectural design and modeling of the layer model above that layer is traced back to, and the layer model above is modified and adjusted. The adjustments include adjusting the model attribute information, merging and splitting model elements, and adjusting the vertical allocation relationship of the model.

5. The model-based avionics system architecture design method as described in claim 1, characterized in that... After obtaining the avionics system architecture model, verify the avionics system architecture model and generate a verification report. Classify and integrate the data of each avionics system architecture model according to the data types in each layer of the model, export the model description interface control document, and import the model description document as needed.

6. The model-based avionics system architecture design method as described in claim 1, characterized in that... After obtaining the avionics system architecture model, a baseline data comparison report for the multi-layer model is generated and sent, including: Obtain the configuration data of the current avionics system architecture model, compare the current model with the architecture model of the previous baseline avionics system, and generate a baseline data comparison report.

Images