A Resource Servitization Method for Multi-Platform Avionics Systems

Abstract

With the continuous advancement of modern science and technology, multi-platform avionics systems are playing an increasingly important role in collaborative tasks and resource scheduling. Traditional single-platform avionics systems exhibit significant shortcomings in performance, scalability, and resource sharing, making them unable to meet the requirements for systematized collaboration and efficient scheduling in future applications. This paper addresses the issues of heterogeneity, dynamics, and high coupling in multi-platform avionics systems by proposing a resource servitization method for such systems. This method realizes semantic abstraction and unified description of resource functions through a three-layer ontology modeling of resource, capability, and service, and designs a multi-level service management framework to support cross-platform resource discovery, invocation, and composition. Finally, in combination with a typical joint search task scenario, this paper constructs a prototype system and conducts function and performance verification. The experimental results show that the proposed method can effectively improve resource utilization and cross-platform collaboration efficiency, and can still ensure low response latency and high system stability in the case of node scale expansion and increased communication load, providing strong support for efficient collaborative operations in multi-platform systems.

1. Introduction

With the development of modern science and technology, multi-vehicle mission coordination plays a key role in collaborative tasks and resource scheduling [1]. However, due to the obvious limitations of traditional single-platform avionics systems in performance, scalability, and information sharing, network-based information exchange and resource scheduling have become the mainstream mode of multi-platform swarm operations [2]. Under this system, with the increasing number and complexity of avionics, higher requirements are put forward for processing, communication, storage, and energy efficiency, while simultaneously creating an urgent need for cross-platform information fusion and mission coordination [3]. Although multi-platform avionics systems have overcome the limitations of single platforms by enabling the integrated operation of diverse aircraft types such as manned aircraft and unmanned aerial vehicles (UAVs) through service sharing, their heterogeneity [4], dynamics, and high coupling [5] continue to pose significant challenges [6] for unified resource modeling, scheduling, and management.

Avionics refers to the application of electronic technologies in the aviation field to support aircraft flight and other aviation tasks [7]. Avionics systems are regarded as the central nervous system of aircraft, covering a variety of critical functions such as navigation, communication, sensing, and monitoring [8]. To meet both civilian and industrial demands, avionics systems have evolved from discrete to integrated, and subsequently to the current integrated modular avionics [9]. Integrated Modular Avionics [10] (IMA) represents the prevailing trend in avionics software system development [11]. As an innovative approach to avionics systems architecture, it can effectively enhance system efficiency and reduce system overhead [12]. Relevant software architecture specifications supporting IMA include the Generic Open Architecture [13], the standards system of the Joint Standard Avionics Architecture Council, and the Standard Interfaces for Avionics Application Software [14]. These emerging IMA architectures have achieved standardization in avionics systems [15].

With the development of avionics system architecture, servitization has gradually been adopted in avionics system development [16]. For the requirements of future systems in various industrial sectors, such as systematic coordination, resource sharing, etc., the domestic service-oriented avionics system architecture indicates that avionics systems need to develop towards integration, intelligence, and other directions. Steven proposed the design of a hypervisor architecture aligned with the Future Airborne Capability Environment (FACE) framework [17]. The study focused on extending the Xen open-source hypervisor to support ARINC 653 partitioning, providing both safety and security profiles required by the FACE Technical Standard. By integrating the ARINC 653 API into the hypervisor, the research effectively demonstrated how FACE-compliant avionics platforms can achieve modular isolation and certification readiness, thereby improving the openness, safety, and reusability of airborne software systems. Xiao et al. proposed a model transformation approach within the FACE architecture to enhance the reusability and portability of avionics software [18]. The study designed a metadata mapping-based transformation method from SysML system models to FACE data models, effectively bridging the semantic gap between model-based system engineering (MBSE) and FACE-compliant development. This approach established a coherent development process between system modeling and data modeling, thereby improving development efficiency and ensuring the consistency and reusability of avionics components across platforms.

In comparison to traditional methods like ARINC 653 partitioning or FACE-compliant middleware, which focus on safety, modularity, and certification but struggle with resource utilization and flexibility in dynamic environments, the proposed servitization method offers a more adaptable and scalable approach. While service-oriented architectures (SOA) provide modularization and dynamic resource allocation, they often suffer from high overhead and complex service discovery. DDS-based middleware, while effective in data-driven communication, faces challenges in resource orchestration and dynamic service allocation. In contrast, the proposed approach abstracts resources into capabilities and encapsulates them as services, enabling dynamic task scheduling and resource sharing across platforms, with improved scalability and flexibility. However, it may introduce some overhead in service orchestration compared to static models like ARINC 653 and FACE.

In response to the problems of heterogeneity, dynamics, and high coupling in multi-platform avionics systems, a resource servitization method for multi-platform avionics systems was proposed. Compared with existing systems that rely on platform-specific wrappers, static service registries, or communication-based middleware, the proposed method provides a unified semantic abstraction of heterogeneous resources and introduces dynamic task scheduling capabilities across platforms. Existing approaches often suffer from inconsistent resource descriptions, lack of runtime adaptability to dynamic environments, and poor scalability under high system load. The proposed method addresses these shortcomings by abstracting resource functions into capabilities and further encapsulating them as service interfaces. This approach enables consistent mapping and collaborative management of resources, capabilities, and services, aiming to enhance resource utilization and cross-platform task scheduling capability. The main contributions of this paper are as follows:

(1)

Aiming at the problems of resource heterogeneity and inconsistent descriptions in multi-platform avionics systems, this paper constructed an ontological model of resources, capabilities, and services from the semantic perspective. Existing methods typically struggle with cross-platform integration due to inconsistent resource descriptions and lack of formalization in resource modeling. By defining the five-tuple attribute of resources, the four-tuple attribute of capabilities, and the five-tuple attribute of services, the mapping and internal relationship between resources, capabilities, and services were established. The introduction of constraints such as uniqueness, availability, reliability, and source consistency ensures that resources are consistently described and uniformly represented across different platforms. This modeling technique eliminates the ambiguity inherent in traditional resource descriptions and provides a theoretical foundation for cross-platform resource sharing and scheduling.

(2)

On the basis of modeling, this paper proposed and implemented a multi-level service management framework. Traditional centralized service management systems often face performance bottlenecks as the number of services and platform nodes increases, making it difficult to scale. This framework consists of an agent-based service middleware, a single-node service manager, and a global service manager, supporting the registration, discovery, invocation, monitoring, and combination of resource services. Unlike traditional centralized architectures, this multi-level framework alleviates the load on a single management node by introducing service agents and dividing the management responsibilities. The service agent middleware adapts and forwards communication between intra-node and inter-node systems, shielding platform-specific differences. The single-node service manager ensures rapid response for local services, while the global service manager coordinates the scheduling and optimization across platforms. This architecture effectively solves the performance bottleneck problem of centralized single-node management, improving resource utilization and collaborative operational efficiency in multi-platform environments. In particular, the ability to scale across platforms while maintaining low latency and high stability, even under heavy communication load, is a key advantage of this framework.

2. System Model and Constraint Relationships

In this section, we first establish a three-layer ontology modeling framework of resource-capability-service in multi-platform avionics systems. Subsequently, we analyze the constraints and optimization objectives in resource scheduling, and abstract the research problems into a multi-constraint optimization problem toward servitization management.

2.1. System Model

Within the context of the avionics system in this article, capability is regarded as an inherent property of avionics resources, derived directly from the internal characteristics such as the structural composition, performance parameters, and control mechanisms of the resources, rather than depending on specific users or operational processes. Different types of resources have varying capabilities due to their design objectives and physical characteristics. For instance, sensors possess the ability to detect and identify targets, carrier platforms have the ability to fly and maneuver, and computing units can handle information processing and data fusion. It is precisely the differentiation and complementarity of these capabilities that enable multi-platform avionics systems to form synergies in complex environments.

However, the existing systems generally lack a unified semantic expression method in cross-platform applications, resulting in inconsistent levels of resource abstraction, a lack of commonality in capability descriptions, and insufficient interoperability of service interfaces, which severely limits resource sharing and reuse. To solve this problem, the resource, capability, and service in the system are modeled in a unified way, with the function of the resource firstly being abstracted into capabilities, and then encapsulated and published through service interfaces, thereby achieving a complete mapping link among resources, capabilities, and services. The relationship among the three is shown in Figure 1. The avionics resources provide corresponding capabilities, which are shared externally after being encapsulated by services, and services can further map and schedule the underlying resources, ultimately forming a closed-loop structure. In this chapter, resources, capabilities and services are modeled to enable multi-platform avionics systems to be discoverable, invocable and composable, thereby providing theoretical support and model basis for subsequent servitization management and cross-platform scheduling.

(1)

Resource modeling: In multi-platform avionics systems, resources are the most fundamental component, covering various hardware and functional units required for mission execution. Due to the complex sources and diverse architectures of different platforms, the resources exhibit significant heterogeneity in terms of form and attributes, posing challenges for unified modeling and cross-platform management. Therefore, this paper conducts a formal modeling of avionics system resources, to achieve unified semantic representation and sharing.

Let the resource set be $R=\{r_1,r_2,\dots ,r_m\}$, where $r_i\in \{R_s,R_c,R_m,R_u\}$, and $R_s,R_c,R_m,R_u$ represent the sets of sensing, computing, storage, and transport resources, respectively.

Sensing resources, such as radars, infrared/electro-optical detectors, are used for target detection and identification; computing resources, such as mission processors and embedded computing units, are responsible for information processing and decision-making calculations; storage resources, including data storage modules and cache units, are used for information storage and sharing; transportation resources, such as manned aircraft and UAV flight platforms, provide mobility and payload capacity. Each resource $r_i$ has a five-tuple attribute to describe its static characteristics and dynamic state, defined as follows:

$$r_i=\langle \mathrm{RID},\mathrm{RL},\mathrm{RP},\mathrm{RPC},\mathrm{RS}\rangle$$

(1)

where RID represents the unique identifier of the resource; the format can be a string, such as “Radar001”, an integer, such as 1, 2, or 3, or a globally unique identifier (GUID). The format of RID depends on the system’s database or resource management architecture. RL indicates the spatial location of the resource, typically represented as GPS coordinates, such as latitude: 40.748817, longitude: −73.985428; relative positions, such as ($x=10$, $y=5$, $z=0$) relative to a base platform; or abstract identifiers, such as “ZoneA” to represent a specific geographical area. RP denotes the performance parameters, which depend on the resource type. For example: For a radar system, RP may include detection range of 100 km, resolution of 1 m, frequency band of X-band, etc. For a processor, RP may include processing speed of 3.5 GHz, memory size of 16 GB, and number of cores of 8 cores. For a UAV platform, RP may include flight speed of 250 km/h, maximum payload of 20 kg, and endurance of 5 h. RPC represents the energy consumption characteristics, such as power consumption, for example, 200 W for a radar system, or operational conditions, like temperature range, for a UAV with an operational temperature range of −20 °C to 50 °C. RS represents the operational status of the resource, such as “active” or “idle,” and records the last maintenance date. For example, a radar system might have an operational status of “active” and a maintenance date of “2026-01-01.”

(2)

Capability modeling: In multi-platform avionics systems, capability is the functional abstraction of resources, used to express the role that the resource can play in a particular environment and state. Different categories of resources tend to have differentiated capabilities. For example, sensors have the ability to detect and identify targets; computing units have data processing capabilities; storage devices enable data preservation and sharing capabilities; and carrier platforms have flight and maneuvering capabilities. Through capability modeling, the physical attributes of resources can be elevated to an abstract semantic layer, thereby supporting unified description and mission matching across platforms.

Let the system capability set be $C=\{c_1,c_2,\dots ,c_k\}$, where each capability $c_i$ is provided by a specific resource category to support subsequent servitization encapsulation. As an intermediate layer, the capability model maps underlying physical resources to unified functional semantics while enabling the encapsulation and composition of upper-layer services, which facilitates the transition from resource-driven to capability-driven. This modeling approach enables multi-platform avionics systems to dynamically invoke and schedule resources with greater flexibility in battlefield environments, enhancing mission execution adaptability and coordination. Each capability $c_i$ possesses a four-tuple attribute to describe its characteristics, defined as follows:

$$c_i=\langle \mathrm{CID},\mathrm{CTY},\mathrm{CR},\mathrm{CE}\rangle$$

(2)

where $CID$ represents the capability number; $CTY$ is the capability type; $CR$ indicates the capability reliability; $CE$ describes the capability’s applicable environment.

(3)

Service modeling: In multi-platform avionics systems, services are the external encapsulation and publication form of capabilities. By abstracting capabilities into services, the system enables cross-platform resource invocation and composition, addressing issues such as inconsistent interface standards and low resource utilization in traditional architectures. Servitization modeling not only ensures resource discoverability, reusability, and manageability but also lays the foundation for subsequent task scheduling and collaborative operations.

Let the system service set be $S=\{s_1,s_2,\dots ,s_l\}$, where each service $s_i$ is encapsulated by a capability $c_i\in C$ and provides an invocation interface to external users. The introduction of servitization architecture transforms resources from physical entities into invocable entities, reducing the complexity for users to understand and utilize underlying resources while enhancing the system’s interoperability and scalability across platforms. Each service $s_i$ possesses a five-tuple attribute to describe its characteristics, defined as follows:

$$s_i=\langle \mathrm{SID},\mathrm{STY},\mathrm{SS},\mathrm{SN},\mathrm{SE}\rangle$$

(3)

where SID is the service identifier, STY represents the service type, SS denotes the service source, SN is the service name, and SE denotes the service’s extensible field.

Service modeling in multi-platform avionics systems involves encapsulating capabilities as services to facilitate cross-platform resource invocation and composition. This servitization approach addresses challenges such as inconsistent interface standards and low resource utilization in traditional architectures. Beyond ensuring resource discoverability, reusability, and manageability, it also lays the foundation for task scheduling and collaborative operations across platforms.

In addition to the static characteristics, it is crucial to consider the dynamic nature of services within multi-platform avionics systems. The dynamic aspects refer to the potential for services to change their operational states or configurations in response to varying environmental conditions, mission requirements, or resource availability. This adaptability is essential for maintaining system performance under real-time constraints. To address these dynamic needs, the service model incorporates mechanisms for real-time service monitoring, updating service metadata, and dynamically adjusting service allocations. This approach ensures that the system remains responsive and optimized as it adapts to new challenges during mission execution.

2.2. Constraint Relationships

In multi-platform avionics systems, hierarchical mapping relationships exist not only among resources, capabilities, and services, but also diverse interactive relationships within each layer. Through ontology-based modeling, these relationships can be clearly described using formalized formulas.

Each resource within the system possesses not only physical attributes and performance parameters, but also inherently provides one or more functions, which are abstracted as capabilities. For instance, radar resources may provide detection capability; processor resources may offer computational capability, while UAV platforms may deliver manoeuvrability capability. Thus, resources form the fundamental carriers of capabilities, with capabilities representing the semantic abstraction and mapping of resources. The relationship whereby resources provide capabilities describes the correspondence between resources and capabilities, expressed formally as follows:

$$r_i\to c_i$$

(4)

Capabilities themselves represent abstract descriptions of resource functions, but in order to achieve cross-platform invocation and sharing, it is necessary to further encapsulate them in the form of services. Services not only inherit the functional characteristics of capabilities but also include additional information such as service identifiers, interface parameters, and quality metrics, which endow them with characteristics of discoverability, invocability, and composability. For instance, detection capability may be encapsulated as a target detection service, while manoeuvring capability may be encapsulated as a trajectory planning service. Thus, services represent the external manifestation of capabilities, serving as the direct interface through which systems provide functions. The relationship of capability being encapsulated as services describes the transformation process from capability to service, expressed formally as follows:

$$c_i\to s_i$$

(5)

The resource connection relationship is used to describe whether there is a communication or data interaction link between two resources. A value of 1 indicates that there is an effective connection between the two resources, enabling information transmission or collaborative operations; a value of 0 indicates that there is no connection. For example, the communication link between a UAV and a ground station can be recorded as 1, while the connection between two UAVs without interoperable equipment can be recorded as 0. The formula is expressed as follows:

$$\mathrm{Connection}(r_i,r_t)\to \{0,1\}$$

(6)

The resource dependency relationship describes whether the operation of one resource category relies on the support of another resource category. A value of 1 indicates a dependency exists, while a value of 0 indicates no dependency. For example, precision strikes by a weapon system depend on navigation and guidance resources, where the dependency value is 1. The formula is expressed as follows:

$$\mathrm{Dependency}(r_i,r_t)\to \{0,1\}$$

(7)

The capability composite relationship describes new composite capabilities combined from two or more capabilities. For example, a sensor’s detection capability and a processor’s data processing capability can be combined to form target recognition capability. The formula is expressed as follows:

$$\mathrm{CapabilityCombination}(c_i,c_t)\to c_l$$

(8)

The capability hierarchy relationship describes the hierarchical inclusion relationship among capabilities. For example, information processing capability can be further divided into data fusion capability and task allocation capability; flight capability can be further divided into track planning capability and formation maintenance capability. Through this hierarchical relationship, it is able to carry out more granular modeling for capabilities. The formula is expressed as follows:

$$\mathrm{CapabilityHierarchy}(c_i,c_t)\to \{0,1\}$$

(9)

The service composition relationship describes the composition relationship among services, that is, multiple basic services are combined to form more complex composite services through sequential or parallel invocation. For example, the target detection service and the data processing service can be combined to form the target recognition service; the track planning service and the formation maintenance service can be combined to form the formation track control service. The formula is expressed as follows:

$$\mathrm{ServiceComposition}(s_i,s_t)\to [0,1]$$

(10)

The service dependency describes the dependency situation among different services. A value of 1 indicates that the execution of a certain service requires the support of another service, while a value of 0 indicates independent operation. For example, the target strike service needs to rely on the target detection service to execute, and in this case, the dependency relationship value is set to 1. The formula is expressed as follows:

$$\mathrm{ServiceDependency}(s_i,s_t)\to \{0,1\}$$

(11)

The aforementioned relationships form semantic links among and between the three layers of resources, capabilities, and services. However, in the actual operation process, only the definition of the relationship is not enough to ensure the orderly operation of the system, the corresponding constraints should also be introduced to limit the use scope and interaction modes of resources, capabilities, and services. Constraints are proposed from the three levels of resources, capabilities, and services. In multi-platform avionics systems, resources, capabilities, and services all need to be unique to avoid confusion and conflicts during registration, scheduling, and invocation, and the identifier of each resource, capability, and service must have a unique number to ensure accuracy in system matching. The constraints are as follows:

$$\left\{\begin{array}{c}RID\left(r_i\right)\ne RID\left(r_j\right),\hfill \\ CID\left(c_i\right)\ne CID\left(c_j\right),\hfill \\ SID\left(s_i\right)\ne SID\left(s_j\right),\hfill \end{array}\right.$$

(12)

The resource availability constraint stipulates that a resource can only be assigned capabilities by the system when its operational status $RS$ is active. Resources in a fault or inactive state will be excluded from the scheduling process. This constraint ensures that the resources selected for task execution are always in an available state, thereby enhancing the reliability of the system. If this constraint is violated, the system will trigger re-scheduling, prioritizing resources that are in an active state. The re-scheduling process requires dynamic monitoring of resource states and the application of scheduling optimization algorithms.

$$\left\{\begin{array}{c}{r}_i\to c_i,RS\left(r_i\right)=Active\hfill \\ r_i\nrightarrow c_i,RS\left(r_i\right)\ne Active\hfill \end{array}\right.$$

(13)

The reliability constraint of capabilities requires that the reliability $CR$ of each capability must be no less than the minimum reliability threshold $C{R}_{min}$ required by the system. This constraint ensures that the capabilities scheduled can maintain sufficient stability and accuracy in complex battlefield environments. When the reliability of a capability falls below the threshold, the system automatically performs conflict detection and reallocates the capability to ensure stable task execution.

$$CR\left(c_i\right)\ge C{R}_{min}$$

(14)

The source consistency constraint for services requires that the source $SS$ of each service must point to a specific resource instance. That is, the functionality of a service must be based on the capabilities provided by the resource and cannot be arbitrarily defined. If this constraint is violated, the system will trigger conflict resolution, re-matching services and resources to ensure consistency.

$$SS\left(s_i\right)\in r$$

(15)

To ensure the proper operation of the system, algorithms for constraint checking, conflict detection, and resolution strategies are necessary. The system should continuously monitor the status of resources, capabilities, and services, detect potential conflicts, and take appropriate actions. When resources, capabilities, or services violate any constraints, the system should automatically perform re-scheduling or reallocating tasks to maintain smooth system operation. If conflicts cannot be resolved, the system will notify the user and suggest possible solutions.

For example, when multiple tasks compete for the same resource, the system will detect the conflict and resolve it by either allocating the resource to the task with the highest priority or triggering a re-scheduling to balance resource utilization.

3. Multi-Platform Avionics System Resource Servitization Management Framework

Based on the formal description of the modeling and constraint relationships of resources, capabilities, and services in the previous chapter, this chapter further proposes a resource servitization management framework for multi-platform avionics systems. This framework aims to achieve unified scheduling and efficient utilization of cross-platform heterogeneous resources through service encapsulation and multi-level management mechanisms, thereby supporting the multi-platform collaborative requirements under complex tasks.

3.1. Service Management Framework

The service management framework is the core part of the resource servitization management for multi-platform avionics systems, responsible for the full life cycle management of resources services, including registration, publication, discovery, invocation, and recycling of services. Its goal is to convert the underlying heterogeneous resources into standardized service interfaces through unified modeling and semantic processing, thereby achieving resource sharing and efficient utilization in a cross-platform environment. As shown in Figure 2, the service management framework consists of three parts: service publisher, service subscriber, and service management center, and realizes the encapsulation, scheduling, and invocation of services through middleware modules.

The service publishers consist of various providers of resources and capabilities. Internally, publishers contain multiple functional modules: the resource adaptation middleware is used to achieve unified access to heterogeneous resources; the status monitoring module monitors the running status of the resources in real time; the service registration module is responsible for registering the services to the service management center; the information parsing module is used to convert the underlying resource capabilities into semantic descriptions to ensure the uniformity and identifiability of the services.

The service subscribers are the main entities for task execution. Subscribers initiate service requests externally by the invocation management module, and process the returned service information through the information parsing module, eventually completing the function invocation required. This mechanism ensures that users can quickly and accurately obtain the required services without having to worry about the heterogeneity of the underlying resources.

The service management center serves as the global control node of the system, responsible for handling the registration, discovery, and scheduling of all services. Its internal components include the request parsing module, service metadata module, service scheduling module, service management module, and service monitoring module, which respectively undertake functions such as service request processing, directory maintenance, service selection and allocation, service lifecycle management, and service operation status monitoring.

Service request matching and service discovery is a core functionality in the service management framework. The service management center matches service requests to available services using several criteria. These include exact matching, where the system checks whether the service parameters requested by the user exactly match the capabilities provided by the service. If exact matching is not possible, semantic similarity matching is applied, which uses the semantic descriptions of services and resources to match them based on functionality. Additionally, Quality of Service (QoS) matching criteria are used, where services are chosen based on performance metrics such as response time, reliability, and throughput, to ensure that the task’s needs are met.

The computational complexity of service discovery depends on the number of services and the complexity of the matching criteria. Efficient matching algorithms are crucial to reduce computation time and improve the efficiency of service discovery.

The service allocation module is responsible for selecting and allocating services based on task requirements and system constraints. It considers factors such as task priority, resource availability, and the required quality of service. The allocation process aims to maximize resource utilization and minimize delays. It does so by employing optimization algorithms that balance task requirements with available resources, ensuring tasks are completed in the most efficient manner possible.

When a service request is received, the service management center checks whether the requested service can be fulfilled by available services. If no exact match is found, it uses the semantic similarity or QoS-based criteria to find the best available service. If multiple services meet the criteria, the service management center will choose the one that best matches the task requirements, while considering resource availability and load balancing.

In case of conflicts, such as when multiple tasks compete for the same resource, the system triggers conflict detection mechanisms. The system uses task priority and available resources to resolve conflicts and ensure that the task execution continues without interruption. If a conflict cannot be resolved within the current scheduling, the system may trigger a re-scheduling process to ensure that the task is completed by allocating other available resources.

This comprehensive service management framework enables efficient cross-platform resource sharing, service discovery, and task execution, while minimizing resource contention and optimizing the overall system performance.

3.2. Multi-Level Management Based on Service Agents

In view of the heterogeneous nature of avionics systems, and in order to relieve the workload pressure of a single-level management center, this paper designs and implements a multi-level service management framework that manages services through multiple-level service management centers. The multi-level service management framework is shown in Figure 3 and consists of a service agent middleware, a single-node service manager, and a global service manager.

Firstly, at the lowest level, each platform is equipped with a single-node service management center, which is used to manage local resources and their encapsulated services, such as navigation, flight control, radar, etc. The single-node service manager can complete the registration, status maintenance, and invocation of local services, ensuring rapid response in local tasks without relying on external platforms.

Secondly, a service agent middleware is deployed at the upper layer of the single-node service manager. The agent acts as an intermediary node maintaining interaction with the local single-node service manager and is responsible for collecting the semantic descriptions of local resources and services. In addition, it communicates with the global service manager to report local services and dispatch global tasks. Through the service agent, the differences in the underlying platform can be effectively shielded, enabling transparent access to services across platforms.

Finally, a global service manager is set at the top level of the architecture. As the global control node, it maintains a complete service catalog and uniformly handles the registration, matching, and selection of services. The global service manager interacts with various service agents to obtain service information distributed on different platforms, and performs resource scheduling based on task requirements and constraints, thereby achieving cross-platform task coordination and optimized resource utilization. The structure and functions of these three parts will be introduced respectively in the following part, so as to provide a better understanding of the organization and collaborative working mode of the entire framework.

(1)

Service agent middleware: The service agent enables communication between intra-node and inter-node communication systems. As shown in Figure 4, it mainly consists of five parts: the intra-node agent module, the inter-node agent module, the forwarding management module, the time agent module, and the code-driven module.

The intra-node agent module and the inter-node agent module are mainly used to receive the data published by the corresponding DDS system applications and forward the data converted by the corresponding DDS system applications forwarding management module [19]. The forwarding management module is primarily used to convert attribute data types from the intra-node DDS system applications into data types from inter-node NetDDS system applications. The time agent module is used to publish the system time of the agent in both the intra-node and inter-node agent module, and the service management middleware can subscribe to the time objects published by the agent when needed. The code-driven module controls the operational flow of the service agent by calling methods in the intra-node agent module, the inter-node agent module, and the forwarding management module, including operations such as initialization, issuing a subscription relationship statement, data forwarding, and so on.

(2)

The single-node service manager: The structure of the single-node service manager is shown in Figure 5, consisting of five parts: the information parsing module, the front-end of the management center, the service representation module, the service allocation module, and the service management monitoring module.

When the single-node service manager receives different types of requests, it will complete the parsing and processing through the corresponding modules. When receiving a service registration request, it parses and verifies the service model, assigns a unique number, and stores the information. When receiving an external invocation request, if the service exists locally, it is directly executed with the result returned; otherwise, it forwards the request to the global service manager for service location. When receiving a service management request, it forwards it to the service management module for suspension, awakening, or deletion operations, and synchronizes the update results to the global service manager to ensure the consistency of service information.

(3)

The global service manager: The structure of the global service manager is shown in Figure 6. For the global service manager, the global services accessed directly through the global service management middleware and the global services accessed through the single-node service manager are equivalent in the system. The global service manager also regards the single-node service manager as a service management middleware.

In actual operation, the global service manager is responsible for maintaining the global service information and needs to assist the single-node service manager in corresponding service management. When receiving service registration information from other single-node platforms, the request parsing module will verify the registration information and then forward it to the service registration module. This registration information may be a single service or a composite service composed of multiple services. The registration module allocates service identifiers based on the registration information and stores the basic information of the service. The basic information includes the address information of the single-node platform where the service is located, and then, the registration result is returned to the single-node platform. When the service information of the single-node platform changes, the global service manager will receive a service management request from the single-node platform. After the request parsing module parses the request and completes the verification, it forwards the request to the service management module, which will modify the service accordingly based on the request information.

4. Prototype System Construction and Verification for Joint Search Task Scenarios

Combining the joint search task scenario, this chapter constructs a prototype system of multi-platform avionics resource servitization to carry out simulation experiments, and verifies the effectiveness of the research on resource encapsulation with abstraction and on resource servitization management of the multi-platform avionics system.

4.1. Introduction to the Joint Search Task Scenario

The entire scenario involves a formation of 2 manned aircraft and 8 unmanned aerial vehicles conducting a comprehensive search along a designated coastline. Once the target is detected, two aircraft are immediately dispatched to intervene in the operation. Upon identification of the target within the search range, the system coordinates the resources, capabilities, and services required for the mission based on the described scenario.

This scenario serves as an example to demonstrate the effectiveness of the proposed framework. However, the approach is highly generalizable to other mission types. For instance, the same framework can be applied to tasks such as surveillance, data collection, and environmental monitoring, where similar principles of resource allocation, task decomposition, and service interaction apply. The service management and orchestration methods used in the framework are adaptable to various mission requirements, ensuring scalability and flexibility across different operational environments.

Based on the components’ composition of the above scenario, the software and hardware structure to verify the environment includes Windows, VxWorks, and ARINC653 operating systems. This can verify the effectiveness and usability of the method in resource encapsulation with abstraction and in resource servitization management for multi-platform avionics systems proposed in this paper. The verification environment is shown in

Table 1. Verification environment configuration.

Environment	Context
Hardware and network environment	5 high-performance PCs, P2020 boards, 1000 M local area network
operating system environment	Windows 10, ARINC653 operating system, virtual ARINC653 operating system, virtual VxWorks operating system
application software	Protégé modeling program, service management center program, service management middleware

.

Virtual ARINC653 Operating System: This system is based on the ARINC653 standard and implements the 653 interface and scheduling mechanism on Windows. It follows the 653 specification and can support the target system code running on Windows. This system is adopted to restrict all open architectures, applications, and services to comply with the 653 specification. Virtual VxWorks Operating System: This system simulates the interfaces and scheduling mechanisms of VxWorks and supports target system code based on the VxWorks environment, running in the Windows environment.

4.2. Response Latency Testing and Analysis of the Service Management Framework

In order to verify the effectiveness and stability of the service management framework, this section conducts a test on the response latency of its components. The system deployment is shown in Figure 7. The service management center is located on node a of the Windows system, node b is a virtual Vxworks operating system, node c is an ARINC653 operating system running on the P2020 board, and node d is a virtual ARINC653 operating system.

In the service registration response latency test, there were five test cases for each of the nodes a, b, c, and d. Each test case sent one service registration message to the service management center every 10 ms, and 100 tests were conducted. The goal of the test was to verify whether all services could be successfully registered under this condition and to measure the time required for each service registration. The results showed that all the test results of each node were within 60 ms, and the average latency of 500 test cases for each node was less than 10 ms. The specific results are shown in

Table 2. Service registration response latency.

Node	a	b	c	d
maximum latency	31.47	24.16	54.97	19.14
average latency	4.81	6.15	5.87	5.74
minimum latency	2.97	3.07	3.42	3.54

.

In the test of service acquisition response latency, five test cases were conducted for each node (a, b, c, and d). For each test case, a service acquisition request was sent to the service management center every 10 ms, and 100 tests were carried out. The goal of the test was to verify the time required for service callers to obtain service addresses under this condition. The results showed that all the test results of each node were within 30 ms, and the average delay of each node’s 500 test cases was less than 10 ms. The specific test results are shown in

Table 3. Service acquisition response latency.

Node	a	b	c	d
maximum latency	16.88	16.04	29.17	15.76
average latency	2.82	4.05	5.14	4.25
minimum latency	0.12	0.26	0.40	0.24

.

In the test of service management response latency, five test cases were conducted for each of the nodes (a, b, c, and d). For each test case, a management command was sent to the service management center every 10 ms, and 100 tests were carried out. The goal of the test was to verify the time required for the service management center to process service management commands and return processing results under this condition. The results showed that all the test results of each node were within 20 ms, and the average latency of each node’s 500 test cases was less than 10 ms. The specific test results are shown in

Table 4. Service management response latency.

Node	a	b	c	d
maximum latency	9.09	10.01	15.23	19.51
average latency	4.03	4.22	5.34	4.97
minimum latency	1.73	1.89	2.75	2.86

.

The component response latency mainly includes three parts: (1) the latency for logical processing at the application layer and service layer, (2) the latency for data transmission in the transport layer, and (3) the latency caused by task scheduling and context switching in the system. For the same service, the latency for logical processing at the application layer and the service layer is generally not significantly different. Therefore, it can be concluded that it is the latency of the other two parts that causes the large difference between the peak and minimum latency values in each table. This also indicates that, in the current test environment and scenario, the latency generated by the logical processing at the application layer and the service layer accounts for a relatively small proportion of the total latency. The above test results indicate that the service management center operates with high efficiency and reliability when handling various service requests. The servitization management framework layer in the prototype system can meet the real-time communication and coordination requirements of multi-platform avionics systems in complex environments. Through these comprehensive performance tests, the stable operation and efficient service management of multi-platform avionics systems can be ensured, providing strong support for achieving efficient collaborative operations. It is important to note that these tests are based on a self-comparison where the performance of the same system is compared under different operational conditions. Specifically, the tests compare the system’s response times with different communication frequencies, where in one case the heartbeat interval is 100 ms and in the other it is 10 ms, simulating different load scenarios. This comparison focuses on how changes in system load affect the platform’s performance in terms of response latency and efficiency, without comparing the system to external systems.

4.3. Response Latency Testing and Analysis of Multi-Level Service Management

In order to verify the alleviating effect of hierarchical service management on the workload pressure of the service management center within the multi-platform avionics resource servitization system, the same air scenario was implemented using both single-level and multi-level service management architectures. Scenario A is the air scenario implemented in Section 5.1 of this paper. In this scenario, there are 56 service publishers, with a single-node service manager on two nodes. To maintain a stable traffic level of the system, only the service publishers in the scenario are activated, and the service management center will only receive the heartbeat frames sent by all the service publishers at a fixed time (100 ms). Scenario B, based on Scenario A, changes the frequency of fixed heartbeat frames sent by the service publishers to 10 ms.

In Scenario B, the heartbeat interval was modified from 100 ms to 10 ms, which simulates a scenario where the communication frequency between service publishers and the service management center is significantly higher. The purpose of this modification is to increase the system’s communication load, thus testing how the service management framework, particularly the multi-level service management architecture, performs under higher data transmission rates and more frequent service requests. This change aims to evaluate the responsiveness and efficiency of the system when faced with higher communication demand, as well as to observe how the system adapts to increased load.

The key difference between Scenario A and Scenario B lies in the frequency of service requests and the resulting system load. While Scenario A represents a typical operational environment with moderate communication frequency, Scenario B provides a high-demand scenario where the system is required to handle more frequent interactions, which better reflects the challenges of large-scale, high-load environments. The comparison of response latency under four conditions is shown in Figure 8, while the specific values of the maximum, minimum, and average latency are presented in

Table 5. Response latency under four conditions (ms).

Test Environment	Scenario A		Scenario B
	Multi-Level Service Management	Single-Level Service Management	Multi-Level Service Management	Single-Level Service Management
maximum latency	19.43	10.51	18.30	29.69
average latency	5.02	4.50	4.87	10.13
minimum latency	3.55	1.65	2.99	6.12

.

In the above response latency test, the performance of single-level service management and multi-level service management in two different scenarios (A and B) were compared. The results obtained from Scenario B, where the heartbeat interval was reduced to 10 ms, demonstrated a significant increase in system load and communication frequency compared to Scenario A. This higher load allowed us to assess how the multi-level service management architecture performs under more demanding conditions. The results show that in such high-load scenarios, the multi-level service management architecture provides better performance by reducing communication delays and improving response times, as it effectively distributes the load across multiple service managers. In contrast, the single-level service management architecture struggled to maintain performance due to the increased data volume and higher communication frequency, highlighting the scalability and efficiency advantages of the multi-level approach in complex, high-demand environments.

It is important to note that in Scenario A, the average latency of multi-level service management is higher than that of single-level service management due to the additional layers of service request forwarding and processing. Although the multi-level architecture offers better scalability and load balancing in high-load scenarios, it introduces some overhead in low-load conditions where requests are processed through multiple levels. In contrast, the single-level architecture handles all requests at a single node, leading to lower latency in this particular case.

The data also indicates that when the system comprises a relatively small number of nodes, the performance difference between single-level and multi-level service management is not significant. However, when the number of system nodes increases and the communication load grows, multi-level service management significantly outperforms single-level service management. Specifically, in Scenario B, the multi-level service management architecture reduced the maximum latency by approximately 6.4%

This comparative experiment verified the significant role of multi-level service management in enhancing the performance and efficiency of the system. By effectively reducing the amount of data entering the global service management center, multi-level service management minimizes unnecessary data transmission and communication costs, thereby improving the overall performance of the system. This indicates that in complex multi-platform avionics systems, adopting multi-level service management is an effective strategy that can better adapt to large-scale and high-load communication demands and ensure the efficient operation of the system.

5. Conclusions

5.1. Summary of Contributions

This paper proposed a resource servitization method for multi-platform avionics systems to address the challenges of heterogeneity, dynamics, and high coupling inherent in distributed airborne environments. Through ontology-based modeling, the research established a unified semantic framework consisting of three layers—resource, capability, and service—thereby achieving standardized description, mapping, and constraint definition for heterogeneous avionics resources.

Building on this modeling foundation, a multi-level service management framework was designed and implemented. The framework integrates service agents, single-node service managers, and a global service manager to realize hierarchical registration, discovery, and invocation of avionics resource services. This architecture effectively alleviates the workload of centralized management, enhances the autonomy and responsiveness of local nodes, and improves the overall coordination and efficiency of cross-platform operations.

To validate the proposed method, a prototype system was constructed and tested under a joint operational scenario. Experimental results demonstrated that the framework ensures low response latency, stable operation, and efficient resource utilization even under increased system scale and communication load. The comparison between single-level and multi-level management confirmed that hierarchical management significantly improves performance under high-load conditions, verifying the scalability and robustness of the proposed approach.

5.2. Limitations and Future Work

Future research will focus on extending the servitization framework toward intelligent resource orchestration and adaptive service composition in dynamic environments. Incorporating reinforcement learning and knowledge-driven reasoning into the service management layer will further enhance autonomous decision-making, adaptability, and situational awareness in next-generation multi-platform avionics systems.

Additionally, the current experimental evaluation primarily focuses on response latency, which, while providing valuable insights, is not sufficient to fully validate the claimed contributions. To address this, future experiments will incorporate a broader set of metrics, including resource utilization rates, system throughput under varying loads, fault tolerance, and recovery time. These metrics will help to demonstrate how the framework effectively improves resource utilization, as claimed in the abstract. Furthermore, scalability tests with a larger number of services will be conducted to assess the performance of the system as the number of registered services increases from 56 to 500 or 5000, as well as to evaluate the maximum throughput of the global service manager. These additions will allow for a more comprehensive validation of the system’s capabilities and scalability in realistic multi-platform collaborative scenarios.