A microservice architecture compliant with the ARINC 661 standard
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINESE AERONAUTICAL RADIO ELECTRONICS RES INST
- Filing Date
- 2026-04-02
- Publication Date
- 2026-07-21
AI Technical Summary
In engineering applications, the ARINC661 standard results in a large overall code size, high coupling, inability to extend functionality in multiple dimensions simultaneously, and poor performance that fails to meet the requirements of complex display systems.
The system adopts a microservice architecture and implements the ARINC661 standard through basic and extended plugins. The plugin system includes the A661 kernel system, plugin management module, and plugins. Each plugin consists of extensions, extension points, and internal data structures. Isolation and data interaction are achieved through a message communication mechanism to ensure system stability and security.
It improves the ARINC661 software's ability to respond quickly and flexibly to changes in requirements, greatly enhances its scalability and robustness, and reduces project development costs and time.
Smart Images
Figure CN122431713A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software development and relates to a microservice architecture that conforms to the ARINC661 standard. It solves the problem that the ARINC661 standard requires a large number of customized functionalities in engineering applications, resulting in a large overall code size, high coupling, inability to expand functions in multiple dimensions simultaneously, and poor performance that cannot meet the requirements of complex display systems. Background Technology
[0002] The ARINC 661 standard aims to standardize the definition of cockpit display systems, standardizing the communication between cockpit display systems and users for managing avionics equipment. Its primary purpose is to standardize the interface between the CDS and UA. The Graphical User Interface (GUI) is entirely defined by binary DF files, while the cockpit display software manages the actual presentation window construction and monitors pilot-aircraft interaction through display system input devices. The ARINC 661 standard protocol reduces the development costs of new avionics display control systems, saves system integration time, reduces the cost of adding new display functions throughout the aircraft's lifecycle, and mitigates the risks and costs for application development departments in hardware selection and replacement under rapidly evolving display and control technologies. It also provides a standardized framework for HMI requirements for display control device design and research departments, enhancing specialization.
[0003] Currently, VAPS XT ARINC661, GL Studio ARINC661, and SCADE Display ARINC661 are all developed based on a single architecture pattern, resulting in a massive overall codebase that cannot be simultaneously expanded across multiple dimensions. While this architecture can address increased workloads by adding applications, the resulting massive data volume and additional resource requests can lead to excessive memory consumption, even exceeding the original system's limits, resulting in performance degradation. The SCADE Display ARINC661 R16 version has 300,000 lines of code, exhibiting poor functional scalability and compatibility. Adding new functional modules requires continuous version upgrades, significantly increasing development costs.
[0004] Microservice architecture designs a specific software application as a collection of independent services. Compared to traditional monolithic architectures, microservices divide a single project into independent services or plugins. Microservices break down complex, previously tightly coupled business logic into individual services, avoiding the original complex composite structure, distributing management to reduce unnecessary losses, and enabling the entire application, containing numerous functions, to respond quickly and flexibly to constantly changing business needs. Microservice architecture adheres to the design principles of high cohesion and low coupling. Functionality is broken down into independent plugins, and each plugin only needs to declare which functions it provides and which functions it receives. When a specific function is needed, it only needs to request it from the plugin management module, which automatically finds the plugin that provides the function and executes the corresponding function. This allows the system to quickly respond to changes in requirements and greatly improves the system's scalability and robustness. Summary of the Invention
[0005] The purpose of this invention is to provide a microservice architecture compliant with the ARINC661 standard. This architecture can meet project requirements through a series of basic plugins and can also meet new customized needs through extended plugins, significantly reducing project development costs and timelines. Simultaneously, the basic plugins will be continuously validated and improved during project application. With a sufficiently rich plugin library, selecting appropriate plugins can complete most of the design and development tasks for new projects, greatly reducing costs. Furthermore, the rich plugin library can provide a design basis for new projects. Designing display system functions based on the existing plugin library reduces the workload of developing customized plugins, creating a virtuous cycle and gradually leading to standardization.
[0006] The objective of this invention is achieved through the following technical solution:
[0007] An ARINC661 microservice architecture includes an A661 kernel system, a plugin system, and plugins. The plugins are characterized by including a series of basic plugins and extended plugins. The basic plugins implement a series of functions defined in the A661 standard, while the extended plugins implement specific required business functions.
[0008] The A661 kernel includes the A661 SERVER and a plugin management module. The A661 SERVER is used to implement DF file parsing, window configuration, ARINC661 parameter parsing, context creation, and to request plugin functional services from the plugin management module. The plugin management module is responsible for managing plugins at runtime.
[0009] The plugin system establishes a message communication mechanism that encapsulates the runtime context of the A661 kernel system and forwards it to plugins according to different scenario requirements.
[0010] Based on the above characteristics, a plugin consists of extensions, extension points, and internal data structures;
[0011] The internal data structure is used to store the plugin's data and serves as the data interaction carrier between extensions and extension points.
[0012] An extension is an interface provided by a plugin for other extension points to call. It is the functionality provided by the plugin to the outside world. After an extension is called, it first reads the data in its internal data structure, then executes the functional logic in combination with the context, and finally updates the internal data structure or outputs the result.
[0013] Extension points are where plugins receive external data or call other extension interfaces to implement functions;
[0014] If a plugin needs external data to supplement parameters, it receives the external data through an extension point, writes it into the internal data structure, and then the extension calls the data to complete the function. A plugin must have at least one extension, but it may not have internal data or an extension point.
[0015] Based on the above characteristics, in addition to the functional identification ID, interface definition, parameter list, and return value type, the extension point of a plugin also has the following two attributes:
[0016] Uniqueness: Indicates whether this extension point can only be functioned by one extension;
[0017] Necessity: This indicates whether an extension plugin must exist at this extension point. If it is necessary, at least one extension plugin must be configured for this extension point during the configuration phase. If it is not configured, the configuration phase check will fail. If it is not necessary, no extension plugin can be connected to this extension point. When applying for functionality for this extension point, a message indicating no functionality will be returned, and the process will be skipped.
[0018] Based on the above characteristics, the A661 SERVER is divided into an initialization module and a runtime module:
[0019] During the startup phase, the initialization module sequentially calls the platform adaptation extension point, the configuration file parsing extension point, and the DF file loading extension point. Initialization concludes after the plugin corresponding to each extension point has completed its specific function.
[0020] Platform adaptation extension points are used to set the system parameters and rendering environment of A661 SERVER. By loading different platform adaptation extension points, different system platforms can be adapted for A661 SERVER.
[0021] Configuration file parsing extension points are used to load configuration files of specific formats, including display layout, window configuration, UADF load address, and layer configuration. By loading different configuration file parsing extension points, different configuration files can be parsed.
[0022] DF file loading extension points are used to implement DF file loading. By loading different DF file loading extension points, different DF files can be loaded, and customized DF parameter verification can be performed during the loading process.
[0023] After the initialization module completes initialization, the runtime module executes periodically. Within each cycle, it sequentially calls the following plugin extensions through extension points to implement an A661 SERVER cycle function:
[0024] Call the loop start extension point: Execute the plugin at the beginning of each main loop iteration;
[0025] Calling the Input extension point: processes the input source and generates event triggers;
[0026] Call chain processing extension point: Handles the specified external data chain, and is generally used in conjunction with other plugins;
[0027] Call the A661 Widget logic extension point: execute the logic operations of each A661 Widget;
[0028] Call the Output extension point: Invoke the output plugin to send events or data to the outside world;
[0029] Call the rendering extension point: Execute the graphics rendering activity;
[0030] Call the overlay extension point: Call the overlay plugin to render the overlay graphics;
[0031] Call the loop end extension point: Execute the plugin at the end of each loop for some customized processing;
[0032] In addition, each extension point in A661 SERVER has a before and an after extension point, which are used to insert some extension plugins before and after a specific step.
[0033] Based on the above characteristics, the context provides plugins with the environmental information, status data, and resource interfaces required for functionality implementation. Simultaneously, it ensures the stability and security of the ARINC661 microservice architecture through access control and data validation. The context is categorized according to data ownership and access scope:
[0034] System-level context: Provides global environment support and a unified system operating benchmark, including platform basic information, server running status, and global configuration parameters. All plugins are read-only, and only the A661 server is writable.
[0035] Plugin-level context: Supports plugin lifecycle management and dependency verification, including plugin ID, version, registration status, dependency extension points, and allocated system resources. Only the plugin to which it belongs can write to it, while other plugins can only read it.
[0036] Widget-level context: Implements the logic execution and state management of the widget plugin, including all widget parameters, running state, and interaction event cache. Only the widget plugin to which it belongs can write to it, and others can only read it.
[0037] Extension point level context: Supports temporary data flow during extension point invocation, including extension point invocation parameters, execution status codes, and temporary input / output data. It is temporarily writable during the invocation and read-only after the invocation.
[0038] During the initialization phase: After the A661 SERVER starts, it creates a system-level context and loads the global configuration; when a plugin is registered, a plugin-level context is automatically created; when a Widget is initialized, a Widget-level context is generated and basic data is populated; during the runtime phase: in the system's main loop, each plugin reads the corresponding level context data through the context API, executes the functional logic, updates the context state, and the updated data is validated and synchronized to the associated level.
[0039] Based on the above characteristics, the plugin management module includes a plugin registration management module and an extension point matching and invocation module:
[0040] When the ARINC661 microservice architecture starts, the plugin registration management module receives registration requests from all plugins, collects the extensions provided by the plugins themselves and the extension points they require, establishes a mapping table of "extension → extension point", and records the plugin status.
[0041] When a plugin requests a function from a specific extension point, the extension point matching and invocation module processes the request according to the following procedure:
[0042] a) Obtain the extension point ID requested;
[0043] b) Locate all plugins that implement the extension point in the mapping table;
[0044] c) Invoke plugin extensions in the registration order and collect execution results;
[0045] d) Return the execution status to the requester.
[0046] Based on the above characteristics, the plugin system defines a standardized message format. When a plugin sends a request, it encapsulates the context into a standardized message and submits it to the plugin management module through the context API. After matching the target plugin, the plugin management module forwards the message and returns the result.
[0047] The beneficial effects of this invention are as follows: This invention provides a microservice architecture that conforms to the ARINC661 standard, which solves the problem that the ARINC661 standard requires a large number of customized functional requirements in engineering applications, resulting in a large overall code size, high coupling, inability to expand functions in multiple dimensions at the same time, and poor performance that cannot meet the requirements of complex display systems; it improves the ability of ARINC661 software to respond quickly and flexibly to changes in requirements, and greatly enhances scalability and robustness. Attached Figure Description
[0048] Figure 1 This is a schematic diagram of the ARINC661 microservice architecture.
[0049] Figure 2 This describes the structure of the PushButton Widget plugin.
[0050] Figure 3 This is a diagram illustrating the interaction between plugins.
[0051] Figure 4 This is a schematic diagram of the A661 kernel system.
[0052] Figure 5 A schematic diagram of initializing the A661 SERVER module.
[0053] Figure 6. Schematic diagram of the A661 SERVER runtime module.
[0054] Figure 7 shows a schematic diagram of the plugin execution process. Detailed Implementation
[0055] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.
[0056] An ARINC661 microservice architecture includes an A661 kernel system, a plugin system, and plugins, such as... Figure 1 As shown.
[0057] The plugins include a series of basic plugins and extended plugins. The basic plugins implement a range of functions defined in the A661 standard, such as A661 Widgets and the A661 messaging mechanism. The extended plugins, on the other hand, implement specific functions required by the specific display system project, such as the display style and logic of A661 Widgets, customized A661 Widgets, handling of specific links, and handling of new external interactive sources.
[0058] The A661 kernel system provides the basic functionalities necessary to support the normal operation of the entire ARINC661 microservice architecture. It is a foundational framework compliant with the ARINC661 standard, with business functions implemented by plugins at various extension points. The A661 kernel system includes the A661 SERVER and a plugin management module. The A661 SERVER implements basic logic functions such as DF file parsing, window configuration, and ARINC661 parameter parsing, creates contexts, and requests plugin functional services from the plugin management module. The plugin management module is responsible for managing plugins at runtime.
[0059] The core of the plugin system is to establish a message communication mechanism that encapsulates the runtime context of the A661 kernel system and exposes it to plugins according to different scenario requirements. The runtime context is a collection of encapsulated core environment data, state information, resource handles, etc., during the operation of the A661 kernel system, essentially acting as a "secure data bridge" for interaction between plugins and the A661 kernel system. Its core purpose is to provide plugins with the necessary information and resource access points to complete their functions, without allowing plugins to directly access the system's underlying code and raw data, while ensuring that core system data is not illegally tampered with by plugins. The message communication mechanism isolates the A661 kernel system and plugins, ensuring that plugins do not intrude into the A661 kernel system. By exposing the encapsulated context, A661 kernel system resources are securely and reliably provided to plugins for use.
[0060] (a) Plugin Design
[0061] Widgets, as the primary objects for communication between CDS and UA, are classified into several categories in the ARINC661 standard, mainly including Container, Graphics Representation, Text String, Interactive, MapManagement, Dynamic Motion, Utility, and UA Validation. Some widgets can be one or more of these categories, such as PushButton, which is both Interactive and GraphicRepresentation.
[0062] Each widget has multiple parameters describing its coordinates, appearance, and interaction information. Each widget also includes various states. Widget functionality is managed through state transitions, which can be categorized into four main types: visibility, availability, internal state, and visual presentation state.
[0063] Taking PushButton Widget as an example, we can implement a plug-in design. The parameters of PushButton Widget are shown in Table 1. Common parameters include Widget identifier, internal state, style, size and position, focus movement, and specific parameters include string parameters, etc.
[0064] Table 1 PushButton Parameters
[0065]
[0066] A plugin consists of extensions, extension points, and internal data structures, such as... Figure 2 As shown.
[0067] The internal data structure stores plugin data. For example, the parameters in Table 1 (WidgetIdent, Visible, PosX, etc.) are the "functional description data" of the PushButton Widget. These parameters are encapsulated in the plugin's internal data structure, becoming the basic input data for plugin operation. The internal data structure serves as the "data interaction carrier" for extensions and extension points; all extensions and extension points share this data.
[0068] An extension refers to an interface provided by a plugin for other extension points to call. It is the functionality that the plugin provides to the outside world. An extension can access the data of the plugin itself, as well as the data of the plugin that provides the functionality. After an extension is called, it first reads the data from its internal data structure, then executes specific functional logic in combination with the context, and finally updates the internal data structure or outputs the result.
[0069] Extension points are where plugins receive external data or call other extension interfaces to implement functionality. If a plugin needs external data to supplement parameters (such as dynamically updating a Label string), it receives the external data through an extension point, writes it into an internal data structure, and then the extension calls that data to complete the function. A plugin must have at least one extension to provide external calling functionality; internal data and extension points are optional.
[0070] Inter-plugin interaction, such as Figure 3 As shown.
[0071] When plugin A's extension Implemented the extension point of plugin B And expansion During operation, it will request extension points in A. The function of this expansion The operation process can be summarized into three operations:
[0072] 1) Through the expansion point Data of the plugin that performs the function;
[0073] 2) Manipulate the data in A;
[0074] 3) Application for implementation The functions within.
[0075] Extension points are the functionalities that a plugin needs to declare itself. They specify the plugin's identifier, interface definition, parameter list, return value type, etc. In addition, extension points also have the following two attributes:
[0076] 1) Uniqueness: This refers to whether this extension point can only be functionally accessed by one extension. If unique, this extension point can only connect to at most one extension plugin. During the configuration phase, a check will be performed to see if more than one is connected; if more are found, the check will fail. If not unique, this extension point can be extended by multiple plugins. When requesting functionality for this extension point, the connected extensions will be called sequentially according to the registration order.
[0077] 2) Necessity: This indicates whether an extension plugin must exist at this extension point. If necessary, at least one extension plugin must be configured for this extension point during the configuration phase. If not configured, the configuration check will fail. If not necessary, no extension plugins need to be connected to this extension point. When requesting functionality for this extension point, a "no functionality" message will be returned, and the request will be skipped.
[0078] (II) A661 Kernel System Design
[0079] The A661 kernel system can be divided into two parts: the A661 SERVER and the plugin management module. The A661 SERVER is responsible for the initialization and main loop scheduling of the ARINC661 microservice architecture; the plugin management module is responsible for managing plugins at runtime. The A661 kernel system design is as follows: Figure 4 As shown.
[0080] The A661 SERVER is further divided into two modules: initialization and runtime.
[0081] Initialization module: Used to initialize the A661 SERVER. The initialization module calls a series of extension plugins through extension points to initialize the ARINC661 microservice architecture, such as... Figure 5As shown. The initialization module is essentially a composite initialization process driven by extension points. It doesn't directly implement the initialization function itself, but instead defines three core extension points to clarify which external functions are needed during initialization (platform adaptation, configuration file parsing, and DF file loading), and defines the interface specifications (input parameters, return values, and call order) for each extension point. These functions are implemented by third-party plugins or plugins included in the ARINC661 microservice architecture. For example, the "DF file loading extension point" is extended by the DF file loading plugin (implementing loading logic for different DF file formats). The initialization module completes DF file parsing by calling this extension. The specific process is: Initialization module starts → calls "platform adaptation extension point → configuration file parsing extension point → DF file loading extension point" in sequence → the plugin corresponding to each extension point executes its specific function → all extensions are executed, and initialization ends.
[0082] Platform adaptation extension points: Platform adaptation extension points are used to set system parameters, rendering environment, etc. of A661 SERVER. By loading different platform adaptation extension points, A661 SERVER can be adapted to different system platforms.
[0083] Configuration file parsing extension point: This extension point is used to load configuration files of specific formats, including display layout, window configuration, UADF load address, layer configuration, etc. By loading different configuration file parsing extension points, different configuration files can be parsed.
[0084] DF file loading extension points: Implement DF file loading. Different DF file loading extension points can be used to load different DF files according to business needs, as well as to perform customized DF parameter verification during the loading process.
[0085] Runtime Module: After A661 SERVER completes initialization, it enters the runtime module, which executes periodically. Within each cycle, it sequentially calls the services of the following plugins to implement a cycle function of A661 SERVER, such as... Figure 6 As shown. The extension points of the runtime module (such as the Input extension point, A661 Widget logic extension point, rendering extension point, etc.) are all defined by A661SERVER itself, and their functionality is provided by the corresponding plugins (basic plugins or extension plugins).
[0086] Call the loop start extension point: Execute the plugin at the beginning of each main loop iteration;
[0087] Calling the Input extension point: processes the input source and generates event triggers;
[0088] Call chain processing extension point: Handles the specified external data chain, and is generally used in conjunction with other plugins;
[0089] Call the A661 Widget logic extension point: execute the logic operations of each A661 Widget;
[0090] Call the Output extension point: Invoke the output plugin to send events or data to the outside world;
[0091] Call the rendering extension point: Execute the graphics rendering activity;
[0092] Call the overlay extension point: Call the overlay plugin to render the overlay graphics;
[0093] Call the loop end extension point: Execute the plugin at the end of each loop for some customized processing;
[0094] In addition, each extension point in A661 SERVER has a before and an after extension point, which are used to insert some extended functions before and after a specific step.
[0095] The context is the standardized data interaction hub in the ARINC661 microservice architecture that runs throughout the entire system lifecycle. It is created, managed, and maintained uniformly by the A661 SERVER and is the core carrier for achieving "isolation between the A661 SERVER and plugins, and secure communication between plugins." Its core design goal is to provide plugins with the environmental information, status data, and resource interfaces required for functionality, while avoiding direct access to underlying system resources and raw data by plugins. Simultaneously, it ensures system stability and security through access control and data verification. Data is divided into four levels according to ownership and access scope: system level, plugin level, widget level, and extension point level. Each level of data is independently encapsulated, with only access interfaces for corresponding permissions exposed to avoid data chaos, as shown in Table 2.
[0096] Table 2 Context Hierarchy
[0097]
[0098] During the initialization phase: After the A661 SERVER starts, it creates a system-level context and loads the global configuration; when a plugin is registered, a plugin-level context is automatically created; when a Widget is initialized, a Widget-level context is generated and basic data is populated; during the runtime phase: in the main system loop, each plugin reads the corresponding level context data through the Context API, executes the functional logic, and updates the context state. The updated data is then validated and synchronized to the associated level (e.g., after the Widget-level context is updated, it is synchronized to the rendering extension point level context).
[0099] The context is created, managed, and maintained by the A661 SERVER, not by the plugin system. The specific creation timing is as follows:
[0100] System-level context: Created immediately after A661 SERVER starts, loading global configuration;
[0101] Plugin-level context: Automatically created by A661 SERVER during plugin registration, populating information such as plugin ID and version;
[0102] Widget-level context: Generated by the A661 SERVER during widget initialization, encapsulating widget parameters and runtime state;
[0103] Extension point-level context: Dynamically created when an extension point is invoked, it stores temporary input / output data.
[0104] Adjustments to the creation process: The microservice architecture design of this invention must be strictly followed. Key adjustments include:
[0105] Layered encapsulation: Divided into four levels according to data ownership, each layer is encapsulated independently, and only the corresponding permission interface is exposed (e.g., only A661 SERVER can write to the system-level context).
[0106] Access control: Through the A661 SERVER's verification logic, it is ensured that plugins can only access context data within their own permission scope, and direct manipulation of underlying resources is prohibited;
[0107] Lifecycle binding: The creation / update / destruction of the context is strongly bound to the lifecycle of the platform, plugin, and widget (e.g., the plugin-level context is destroyed when a plugin is uninstalled), to prevent data leakage.
[0108] The plugin management module is the "plugin scheduling hub" of the ARINC661 microservice architecture. Its core responsibilities include plugin registration, matching, invocation, and lifecycle management. Its main functions include:
[0109] 1) Plugin Registration Management Module
[0110] When the ARINC661 microservice architecture starts, it receives registration requests from all plugins (basic plugins and extension plugins), collects key information about the plugins, mainly including: the plugin's own "extensions" (externally callable functional interfaces, including interface ID, parameter list, and return value); and the plugin's required "extension points" (functional interfaces that need to be implemented by external plugins, including interface ID and uniqueness / necessity attributes). Simultaneously, it establishes a mapping table of "extension → extension point" (e.g., plugin 1's A functional extension corresponds to A functional extension point A in A661 SERVER), and records the plugin status (not loaded / loaded / running).
[0111] 2) Extension point matching and invocation module
[0112] When a plugin requests a feature from an extension point, it is processed according to the following procedure.
[0113] a) Receive request: Get the extension point ID of the request (e.g., "A Function Extension Point");
[0114] b) Matching query: Search the mapping table for all plugins that implement the extension point (based on the "uniqueness" attribute of the extension point: if unique, return 1 plugin; if not unique, return all registered plugins).
[0115] c) Invocation and execution: Invoke the extended functions of the plugins in the registration order and collect the execution results;
[0116] d) Result feedback: Return the execution status (success / failure) and result data to the requester;
[0117] (III) Plug-in System Design
[0118] The core design of the plugin system consists of two parts: a unified message communication mechanism and runtime context encapsulation. It is also responsible for plugin registration coordination and runtime interaction scheduling. The specific implementation is as follows:
[0119] Core Design 1: Unified Message Communication Mechanism
[0120] Function: To achieve secure isolation and data interaction between A661 SERVER and plugins, and between plugins themselves, and to prevent plugins from directly accessing the system's underlying code or raw data;
[0121] Implementation method: Define a standardized message format (including message ID, parameter type, and return value), and all interactions forward messages through the plugin management module to ensure the security and standardization of data transmission;
[0122] Key logic: When a plugin sends a request, it encapsulates the data into a standard message and submits it to the plugin management module via the context API; after the plugin management module matches the target plugin, it forwards the message and returns the result.
[0123] Core Design 2: Runtime Context Encapsulation
[0124] Function: Encapsulates the core environment data, status information, and resource handles of the ARINC661 microservice platform, providing a secure data access entry point for plugins;
[0125] Implementation method: Layered encapsulation at the system level, plugin level, widget level, and extension point level, with each layer only exposing access interfaces with corresponding permissions (e.g., the system-level context is writable only by A661 SERVER, and plugins are read-only).
[0126] Key logic: The plugin reads the parameters of the required level through the context API, and the updated data must be verified by A661SERVER to ensure that the core system data is not illegally tampered with.
[0127] Registration and runtime interaction
[0128] During the initialization phase, the plugin system organizes all plugins to register "extensions" (external functions) and "extension points" (required functions) with the plugin management module, establishing a mapping relationship. At runtime, plugins request extension point services through a message communication mechanism. The plugin management module matches the corresponding plugin's extension and executes it, and the result is fed back to the requester through the context.
[0129] by Figure 7 For example, during the plugin registration phase, the A661 SERVER registers initialization extensions and main loop function extensions with the plugin management module, and registers function extension points A and B. Taking plugin 1 and plugin 2 as examples, plugin 1 completes the initialization phase functions, such as loading and parsing DF files and configuration files; plugin 2 completes the cycle execution phase functions, such as A661 Widget logic processing. Plugin 1 registers function A and extension points with the plugin management module, and plugin 2 registers function B and extension points with the plugin management module.
[0130] During the initialization phase, A661 SERVER requests function A from the plugin management module. After plugin 1 executes function A, it reports the execution status back to A661 SERVER. After the initialization phase is complete, the system enters the periodic execution phase, where A661 SERVER requests function B from the plugin management module. After plugin 2 executes function B, it reports the execution status back to A661 SERVER.
[0131] 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. An ARINC 661 microservices architecture comprising an A661 kernel system, a plug-in system and a plug-in, characterized in that The plugins include a series of basic plugins and extended plugins. The basic plugins implement a series of functions defined in the A661 standard, while the extended plugins implement the specific required business functions. The A661 kernel includes the A661 SERVER and a plugin management module. The A661 SERVER is used to implement DF file parsing, window configuration, ARINC661 parameter parsing, context creation, and to request plugin functional services from the plugin management module. The plugin management module is responsible for managing plugins at runtime. The plugin system establishes a message communication mechanism that encapsulates the runtime context of the A661 kernel system and forwards it to plugins according to different scenario requirements.
2. The ARINC661 microservice architecture according to claim 1, characterized in that... A plugin consists of extensions, extension points, and internal data structures; The internal data structure is used to store the plugin's data and serves as the data interaction carrier between extensions and extension points. An extension is an interface provided by a plugin for other extension points to call. It is the functionality provided by the plugin to the outside world. After an extension is called, it first reads the data in its internal data structure, then executes the functional logic in combination with the context, and finally updates the internal data structure or outputs the result. Extension points are where plugins receive external data or call other extension interfaces to implement functions; If a plugin needs external data to supplement parameters, it receives the external data through an extension point, writes it into the internal data structure, and then the extension calls the data to complete the function. A plugin must have at least one extension, but it may not have internal data or an extension point.
3. The ARINC661 microservice architecture according to claim 2, characterized in that... In addition to the functional identifier ID, interface definition, parameter list, and return value type, the extension point of a plugin also has the following two attributes: Uniqueness: Indicates whether this extension point can only be functioned by one extension; Necessity: This indicates whether an extension plugin must exist at this extension point. If it is necessary, at least one extension plugin must be configured for this extension point during the configuration phase. If it is not configured, the configuration phase check will fail. If it is not necessary, no extension plugin can be connected to this extension point. When applying for functionality for this extension point, a message indicating no functionality will be returned, and the process will be skipped.
4. The ARINC661 microservice architecture according to claim 1, characterized in that... The A661 SERVER is divided into an initialization module and a runtime module: During the startup phase, the initialization module sequentially calls the platform adaptation extension point, the configuration file parsing extension point, and the DF file loading extension point. The initialization ends after the plugins corresponding to each extension point have completed their specific functions. in Platform adaptation extension points are used to set the system parameters and rendering environment of A661 SERVER. By loading different platform adaptation extension points, different system platforms can be adapted for A661 SERVER. Configuration file parsing extension points are used to load configuration files of specific formats, including display layout, window configuration, UADF load address, and layer configuration. By loading different configuration file parsing extension points, different configuration files can be parsed. DF file loading extension points are used to implement DF file loading. By loading different DF file loading extension points, different DF files can be loaded, and customized DF parameter verification can be performed during the loading process. After the initialization module completes initialization, the runtime module executes periodically. Within each cycle, it sequentially calls the services of the following plugins through the extension points to implement an A661 SERVER cycle function: Call the loop start extension point: Execute the plugin at the beginning of each main loop iteration; Calling the Input extension point: processes the input source and generates event triggers; Call chain processing extension point: Handles the specified external data chain, and is generally used in conjunction with other plugins; Call the A661 Widget logic extension point: execute the logic operations of each A661 Widget; Call the Output extension point: Invoke the output plugin to send events or data to the outside world; Call the rendering extension point: Execute the graphics rendering activity; Call the overlay extension point: Call the overlay plugin to render the overlay graphics; Call the loop end extension point: Execute the plugin at the end of each loop for some customized processing; In addition, each extension point in A661 SERVER has a before and an after extension point, which are used to insert some extension plugins before and after a specific step.
5. The ARINC661 microservice architecture according to claim 1, characterized in that: The context provides plugins with the environmental information, status data, and resource interfaces required for functionality, while ensuring the stability and security of the ARINC661 microservice architecture through access control and data validation; the context is divided according to data ownership and access scope: System-level context: Provides global environment support and a unified system operating benchmark, including platform basic information, server running status, and global configuration parameters. All plugins are read-only, and only the A661 server is writable. Plugin-level context: Supports plugin lifecycle management and dependency verification, including plugin ID, version, registration status, dependency extension points, and allocated system resources. Only the plugin to which it belongs can write to it, while other plugins can only read it. Widget-level context: Implements the logic execution and state management of the widget plugin, including all widget parameters, running state, and interaction event cache. Only the widget plugin to which it belongs can write to it, and others can only read it. Extension point level context: Supports temporary data flow during extension point invocation, including extension point invocation parameters, execution status codes, and temporary input / output data. It is temporarily writable during the invocation and read-only after the invocation. During the initialization phase: After the A661 SERVER starts, it creates a system-level context and loads the global configuration; when a plugin is registered, a plugin-level context is automatically created; when a Widget is initialized, a Widget-level context is generated and basic data is populated; during the runtime phase: in the system's main loop, each plugin reads the corresponding level context data through the context API, executes the functional logic, updates the context state, and the updated data is validated and synchronized to the associated level.
6. The ARINC661 microservice architecture according to claim 1, characterized in that... The plugin management module includes a plugin registration management module and an extension point matching and invocation module: When the ARINC661 microservice architecture starts, the plugin registration management module receives registration requests from all plugins, collects the extensions provided by the plugins themselves and the required extension points, establishes a mapping table of "extension → extension point", and records the plugin status. When a plugin requests a function from a specific extension point, the extension point matching and invocation module processes the request according to the following procedure: a) Obtain the extension point ID requested; b) Locate all plugins that implement the extension point in the mapping table; c) Invoke plugin extensions in the registration order and collect execution results; d) Return the execution status to the requester.
7. The ARINC661 microservice architecture according to claim 1, characterized in that... The plugin system defines a standardized message format. When a plugin sends a request, it encapsulates the context into a standardized message and submits it to the plugin management module through the context API. After the plugin management module matches the target plugin, it forwards the message and returns the result.