Distributed Computing Function Support Method for Airborne Embedded Systems

Abstract

An airborne embedded system distributed computing function support method is provided in an embodiment of the present disclosure, belonging to the field of airborne embedded system software. For application software with distributed computing requirements in an avionics system, based on the Actor model, according to specific requirements for distributed computing capabilities, a distributed computing cluster within a certain range is established, adopting a master-slave architecture. Through the distributed two-level management of Actors and the asynchronous message passing mechanism, the use of remote computing processing functions is supported to achieve the purpose of distributed computing of the application software.

Description

Technical Field

[0001] The present invention belongs to the field of airborne embedded system software, and particularly relates to a method for supporting distributed computing functions of an airborne embedded system. Background Art

[0002] Distributed computing is a network-based computing method, which is a collection of independent computers that can be interconnected via a network and cooperate to execute a certain task. It studies how to use the resources in this collection of computers to solve a problem that requires extremely huge computing power by means of paging governance.

[0003] Actor is a parallel computing model in the field of computer science. It is a concurrent programming model that does not share memory and relies on message passing, effectively avoiding situations such as resource contention and deadlocks. This model encapsulates Actors as the smallest communication units and serves as a general parallel computing primitive: an Actor responds to the received messages, makes local decisions, can create more Actors (sub-Actors), or send more messages; at the same time, it prepares to receive the next message. The communication process is as shown in the appendix. Figure 1 As shown. Each Actor manages its own state, behavior, and mailbox, and provides a unique mailbox address externally. Its property definitions are as follows:

[0004] State: The information of the variables managed by the Actor to avoid lock and memory atomicity problems;

[0005] Behavior: The internal computing logic of the Actor, i.e., the functions that can be executed and implemented;

[0006] Mailbox: The unique message reception queue address of the Actor.

[0007] Distributed parallel computing implemented based on the asynchronous message passing of the Actor model has an isolation mechanism, distributed and location transparency, and good isolation between computing nodes. With the development of computers and information technology, airborne electronic systems are developing towards hardware modularization and functional softwareization. The software scale is getting larger and the functions are getting more complex. A single computing node can no longer meet the requirements, and more and more applications need to be distributed and run on multiple computing nodes simultaneously, that is, the resources of a single node cannot meet the running requirements of complex software. For the current airborne embedded system, due to the high-security and high-reliability requirements of the field, the distributed computing method has not been used in the airborne avionics system. Summary of the Invention

[0008] In view of this, embodiments of the present disclosure provide a method for supporting distributed computing functions in an airborne embedded system. By closely integrating with the partitioning mechanism of the ARINC653 standard, a method for supporting distributed computing functions in an airborne embedded system based on the Actor model is proposed, providing a software support framework for application functions that require distributed computing in the airborne embedded system.

[0009] A method for supporting distributed computing functions in an airborne embedded system is applicable to the distributed computing of airborne avionics system data. The sum of all the hardware computing resources used in the avionics system serves as a distributed computing cluster. A cluster has multiple computing nodes, and each node includes an Actor model. The smallest management unit in the Actor model is used as an Actor. All the computing node Actors include a first Actor, and the first Actor is the set of all Actors in the distributed computing cluster; the node proxy software manages a second Actor, which is the set of all Actors on each node. The first Actor includes multiple second Actors. The method includes:

[0010] According to functions, it is divided into a registration center software module, a node proxy software module, and a message queue management software module. Among them: the registration center software module realizes data interaction between the registration center software module and the node proxy through the message queue management software. Among them:

[0011] The registration center software is used to manage all Actors in the distributed computing cluster, and the management method is based on the dimensions of the functions and status attributes of all Actors;

[0012] The node proxy software module is used to manage all local Actors on its resident node;

[0013] The message queue management software module is used to manage all Actor message interactions by means of a method that supports a load balancing mechanism. Through the joint management of the registration center software module, the node proxy software, and the message queue management software, the distributed execution and calculation process of complex software within the cluster is supported.

[0014] Beneficial effects

[0015] Based on the Actor model and under the partitioning mechanism of the ARINC653 standard, the present invention realizes a support framework for distributed computing functions in an airborne embedded system composed of three parts: a registration center, a node proxy, and a message queue management component. Taking the Actor as the smallest communication unit, the support and management of the distributed computing function of the application software are realized through the interaction of the states and functions between local and remote Actors. It supports the distributed deployment and remote call of computing processing capabilities, realizes distributed computing under resource integration; adopts a distributed call process based on asynchronous message communication functions, and has a good fault isolation mechanism;

[0016] The partition mechanism adapted to the ARINC653 standard hierarchically manages messages and function carriers, with good spatio-temporal isolation; supports load balancing of resources of each computing node in the cluster; supports dynamic addition and replacement of nodes in the cluster, and has strong scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0018] Appendix Figure 1 Actor model communication process;

[0019] Appendix Figure 2 Actor state change diagram;

[0020] Appendix Figure 3 Distributed computing function support software message transmission frame format;

[0021] Appendix Figure 4 Format of content of message to be processed;

[0022] Appendix Figure 5 Format of content of reply message;

[0023] Appendix Figure 6 Format of content of Actor state update message;

[0024] Appendix Figure 7 Format of content of Actor discovery message;

[0025] Appendix Figure 8 Format of content of Actor publish message;

[0026] Appendix Figure 9 Format of content of broadcast message;

[0027] Appendix Figure 10 Message management process;

[0028] Appendix Figure 11 Distributed computing support software information transfer;

[0029] Appendix Figure 12 Actor registration process;

[0030] Appendix Figure 13 Actor deregistration process;

[0031] Appendix Figure 14Actor Function Discovery / Publishing Process;

[0032] Appendix Figure 15 Function Actor Invocation Process;

[0033] Appendix Figure 16 Distributed Computing Service Usage and Running Process. Specific Embodiments

[0034] The following describes the embodiments of the present disclosure in detail with reference to the accompanying drawings.

[0035] The following illustrates the embodiments of the present disclosure through specific examples. Those skilled in the art can easily understand other advantages and effects of the present disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present disclosure without creative efforts belong to the scope of protection of the present disclosure.

[0036] It should be noted that the following describes various aspects of the embodiments within the scope of the appended claims. It should be obvious that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is illustrative only. Based on the present disclosure, those skilled in the art should understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement a device and / or practice a method. In addition, this device and / or this method can be implemented using other structures and / or functions in addition to one or more of the aspects described herein.

[0037] The core content of the present invention:

[0038] 1. Adopt a master-slave architecture. In the distributed computing cluster, the resident node of the registration center serves as the master node, and the resident node agents of other computing nodes serve as slave nodes;

[0039] 2. Adopt a two-level decision-making mechanism. The two levels of roles are the registration center and the node agent, which are respectively responsible for implementing the distributed computing-related functions of the system management layer and the node agent layer;

[0040] 3. Adopt a distributed invocation process based on asynchronous message communication function, which has a good fault isolation mechanism;

[0041] 4. The partition mechanism that adapts to the ARINC653 standard hierarchically manages messages and function carriers, with good spatio-temporal isolation;

[0042] 5. Support the distributed deployment and remote invocation of computing processing capabilities;

[0043] 6. Support the load balancing of resources of each computing node within the cluster;

[0044] 7. Support the dynamic addition and replacement of nodes within the cluster, with strong scalability.

[0045] Such as Figure 1 The method for supporting the distributed computing function of the airborne embedded system shown is applicable to the distributed computing of airborne avionics system data. The sum of all the hardware computing resources used in the avionics system is used as the distributed computing cluster. A cluster has multiple computing nodes, and each node includes an Actor model. The smallest management unit in the Actor model is used as an Actor. All the computing node Actors are included in the first Actor, and the first Actor is the set of all Actors in the distributed computing cluster; the node agent software manages the second Actor, which is the set of all Actors of each node. The first Actor includes multiple second Actors. The method includes:

[0046] According to functions, it is divided into a registration center software module, a node agent software module, and a message queue management software module. The registration center software module realizes the data interaction between the registration center software module and the node agent through the message queue management software. Among them:

[0047] The registration center software is used to manage all Actors within the distributed computing cluster, and the management method is based on the dimensions of the functions and status attributes of all Actors. For example, the function management of the working state and data comparison;

[0048] The node agent software module is used to manage all local Actors on the node where it resides;

[0049] The message queue management software module is used to support the load balancing mechanism to manage the message interaction of all Actors. Through the joint management of the registration center software module, the node agent software, and the message queue management software, the distributed execution calculation process of complex software within the cluster is realized.

[0050] As the specific implementation manner provided in this case, the registration center software module is configured with an Actor status management function. The registration center software module can obtain the update of the status information of all Actors in the distributed computing cluster in real time. The Actor status information includes: Actor status, node location information, the number of Actors resident on the node, and the list of Actor information resident on the node;

[0051] 1) The conditions for triggering the status management function include:

[0052] a) Actor registration: When receiving the online registration messages of some Actors in each second Actor sent by nodes in the cluster, mark in the node list corresponding to the first Actor in the registration center software, and the quantity information in the node list corresponding to the first Actor;

[0053] b) Actor deregistration: When receiving the offline deregistration messages of some Actors in the second Actor sent by nodes in the cluster, query and delete the information of the offline Actors in the node list corresponding to the first Actor in the registration center software, and the quantity information in the node list corresponding to the first Actor;

[0054] c) Heartbeat anomaly: When within a preset time, A does not receive the heartbeat information sent by the B supervision node, (it is considered that the node has failed and can no longer perform data transmission processing operations), delete the list of the second Actor corresponding to the node with the heartbeat anomaly in the node list corresponding to the first Actor; (the total list corresponding to the first Actor in the registration center software module, the sub - list of all Actors in the faulty node, and delete it in the total list);

[0055] 2) The method for monitoring the heartbeat monitoring information of the monitoring node includes that the heartbeat monitoring information of the node includes all node agent heartbeat reports and the registration center heartbeat monitoring. Among them,

[0056] The node agent software module reports the heartbeat of all second Actors (periodically sends heartbeat report information to the registration center), and the registration center software module monitors the heartbeat of the first Actor; the registration center software module records the heartbeat report information of each node.

[0057] The registration center software module has the Actor function management function, and updates according to the changes in the status of all second Actors. The updated published function information content includes: the update of the function information list of the registration center software module, and the function information list includes sub - tables corresponding to multiple Actors with different functions. Among them:

[0058] 1.1) The registration center software management module resides in the function information list of the second Actors on all nodes in the cluster. The function information list includes function name, number of function Actors, function Actor information list, number of registered nodes, and registered node information list;

[0059] 1.2) The registration center software has the first Actor publishing function. When the registration center receives a request for function discovery from the node proxy software module, it conducts a global query for the requested function and sends the sub-table corresponding to the found function to the requesting node to complete the function publishing operation;

[0060] 1.3) The registration center software has the function of updating and publishing function information. Specifically, when the state of the second Actor in the cluster changes, the registration center software module sends a function information update to other nodes. The other nodes are: the nodes that have sent requests for the corresponding function. The registration center software module sends the updated sub-table (for example, the updated content) to the node proxy software module. The situations where the state of the second Actor in the cluster changes are as follows: The state change includes the addition or reduction of function nodes or the failure of function nodes, where:

[0061] a) Addition of function nodes: When receiving the online registration message of the second Actor sent by a node in the cluster, it is necessary to update the corresponding function sub-table and publish the update information to all users (nodes that have sent requests for the corresponding function);

[0062] b) Reduction of function nodes: When receiving the cancellation message of the second Actor sent by a node in the cluster, query and delete the function information of the corresponding Actor in the corresponding sub-table and publish the update information to all nodes using this function;

[0063] c) Failure of function nodes: When the heartbeat information sent by the supervision node is not received within the preset time, it is considered that the node has failed and can no longer perform data transmission processing operations. Therefore, delete the corresponding information list of this node and publish the update information to all nodes using this function.

[0064] As a specific implementation method provided in this case, the node proxy software module manages the locally resident Actor, that is, manages the state of the second Actor, and discovers the information of the first Actor used by the node for the function (discovery means: global discovery). The locally resident second Actor requests the function it needs to use from the node proxy software. The node proxy software sends a request to the registration center. The registration center software module responds to the request of the node proxy software module and returns the function information corresponding to the corresponding first Actor;

[0065] The message queue management software module includes message processing operations. When each Actor is managed, a corresponding mailbox is assigned to it. The mailbox includes the message content processed by the Actor and the number of its messages;

[0066] The node proxy software module manages the state of the locally resident Actor, including the management of the local Actor state information and the management of the local Actor state change:

[0067] The content included in the local second Actor status information is: (The second Actor includes multiple local Actors) the number of the Actor, the Actor function name, the Actor status, and the status includes registration and the number of messages to be processed;

[0068] The node agent software module manages the changes in the status information of the second Actor resident locally. Specifically, its status information list is dynamically established as the second Actor is registered, and during the operation of the airborne avionics system, including operations such as stopping, starting, and deregistering the second Actor, the real-time status is managed and maintained. The specific process is as follows:

[0069] The node agent software module manages and maintains the Actor in real time according to the operations of the Actor (the operations include, for example, the Actor actively registering, starting, stopping, and deregistering);

[0070] a) Steps for the registration of the second Actor: Establish the second Actor status information table. The specific work includes:

[0071] i. Record the location and attributes of the avionics system for task deployment initiated according to the registration behavior. The avionics system location includes the processor core number and partition number, and the attributes include the name information corresponding to the function;

[0072] ii. Update the current Actor status in the second Actor to indicate that it is registered;

[0073] iii. Initialize and set the number of messages to be processed to "0";

[0074] b) Actor startup: The Actor function starts and the content changes (the content includes: local and registration center status information), including:

[0075] i. Send a "second Actor registration" message to the registration center software module to complete the "go online" operation of the second Actor in the distributed computing cluster, and the registration center software module updates its own status information list;

[0076] ii. Update the current status of the second Actor to "running";

[0077] iii. If the first Actor of the second Actor in the node starts, trigger the "periodic heartbeat reporting" operation of the starting node;

[0078] iv. Start the message processing operation.

[0079] c) Actor stop: The Actor function stops and the content changes (the content includes: local and registration center status information)), including:

[0080] i. Send a "cancellation of the Actor performing the second operation" message to the registration center software module, and the Actor performing the operation performs an "offline" operation in the first Actor;

[0081] ii. Update the status of the Actor currently executing the operation to "stop";

[0082] iii. Process the unprocessed messages in the mailbox and stop the message processing operation.

[0083] d) Actor deregistration: Releases all storage, computing, and communication resources used by the Actor, including:

[0084] i. Suspend the corresponding processing process; Actor, as a software process, suspends the process when it receives the deregistration instruction issued by Actor;

[0085] ii. Clear the mailbox contents;

[0086] iii. Delete all relevant second Actor status information managed by the node agent.

[0087] As a specific implementation method provided in this case, the node agent software discovers and calls the actor information of the function used by the second actor. The function actor information manages the first actor that provides the function required by the second actor. The function actor information is stored in the function actor information table. The function actor information includes: function name, the number of first actors that can provide the function required by the second actor, a list of information about the first actors that provide the function required by the second actor, and the currently used node, where:

[0088] The node agent software module discovers the functional actor information used by the second actor, including the information source of the functional actor information table is the function release message of the registration center software module. When the local node makes a function discovery request, the node agent software module obtains the information of all current first actors that can provide the required function through message communication and updates the content of the processing node functional actor information table; when receiving the message of updating the released functional information issued by the registration center software module, the node agent software module synchronously updates and maintains the local functional actor information table. The specific process is as follows:

[0089] a) The second actor includes the local application actor, which proposes processing function requirements;

[0090] b) The node agent software module sends a "function discovery" request to the registration center software module and receives the "function publication" message from the node agent software module;

[0091] c) The node agent software module records the message content published by the registration center software module in the function Actor information table.

[0092] Furthermore, it also includes the node agent software calling the function Actor used by the local application Actor. The process is as follows: (After function discovery, the application Actor sends a function call request, and the distributed computing function support software completes the specific call work). Specifically:

[0093] a) The local application Actor sends a "function call" request;

[0094] b) The node agent software module queries in the function Actor information table, finds the content of the corresponding function item, and performs local / remote function calls in the form of message sending;

[0095] c) If the call of the corresponding function item has a return value, after the node agent software module receives the information content, it notifies the local application Actor of the execution result.

[0096] As the specific implementation method provided in this case, the message queue management software module is responsible for the receipt and management of all messages of the first Actor. The message queue management software is used to support the load balancing mechanism to manage all Actor message interactions in a method, including the pre - definition of message type definition, message frame format definition, and message queue management. The pre - definition differentiates message types according to different usage scenarios and defines the message frame format according to content information. Message type definition: includes message type and message frame format, where:

[0097] Message type: All Actors appearing below are the first Actor or the second Actor. Communication messages between the first Actor and the second Actor; Status update messages of the first Actor or the second Actor; Heartbeat reporting messages; Discovery / publishing messages of the first Actor or the second Actor; Information change broadcast messages;

[0098] Message frame format definition: The message queue management software defines the internal message frame format, including three items: destination node ID, message type, and message content. The specific content filled in the "message content" part has its own message frame format according to different message types. The specific content definition is as follows:

[0099] a) Actor - to - Actor communication messages: include messages to be processed and reply messages;

[0100] i. Message to be processed: The content format is source node ID, source Actor ID, destination Actor ID, length of data to be processed, data to be processed;

[0101] ii. Reply message: The content format is source node ID, source Actor ID, destination Actor ID, length of reply information data, reply information;

[0102] b) Actor status update message: For the registration and cancellation of Actors in the registration center, the message sender is the node proxy software module, and the receiver is the registration center software module. The message content format includes the Actor deployment node ID, number, status, and function names available;

[0103] c) Heartbeat reporting message: For the heartbeat reporting operation of the node proxy, the message sender is the node proxy software module, and the receiver is the registration center software module. The message content format is the node ID where the node proxy software is located;

[0104] d) Actor discovery / publishing message: To implement function discovery and publishing operations, information interaction between the node proxy software and the registration center software is required. Among them:

[0105] i. Function Actor discovery message: The message sender is the node proxy software, and the receiver is the registration center software. The message content format includes the source node ID and the name of the required function item;

[0106] ii. Function Actor publishing message: When the message sender is the registration center software and the receiver is the node proxy software, the message content format includes the receiving node ID, the published function name, the number of Actors providing the function, and the information list of the function Actors;

[0107] Broadcast message: The registration center performs function information update and publishing. The message content format includes the change type, function name, and function Actor information. The change type is the addition or reduction of function Actors.

[0108] Furthermore, the message queue management software module uniformly manages the message queues on the nodes, uses the circular buffer mechanism to implement the basic functions of message push and pop in the message queue, and in order to adapt to the partition mechanism, the message queues are established in the shared data area, and each partition has an independent message queue. Among them:

[0109] Message management content includes five parts: message sending, message receiving, message parsing, message encapsulation, and message distribution, which realizes message parsing of the received messages and putting them into their respective message queues, as well as encapsulating the messages taken out from the message queues and sending the messages. Among them:

[0110] Message sending and message receiving involve the message queue management software managing the message sending and receiving processes. Specifically, message receiving polls for messages through a periodic task; message sending is triggered through interface calls. The sources / destinations of received / sent messages are of two types, namely local messages (applications in the node proxy software module's actor) and remote messages (registry center software module, node proxy software module), with the differences as follows:

[0111] a) Remote messages are messages transmitted via the underlying communication medium, and the communication transceiver interface can be called;

[0112] b) The sending and receiving of local messages require the support of the message queue management software. The information transmitted by the sending interface is temporarily stored and the receiving process is notified to receive the message, completing the transmission process of local messages.

[0113] Furthermore, it also includes the management of message parsing and message encapsulation. According to the message type, the message to be sent is encapsulated according to the message frame format; the received message is parsed to distinguish between communication messages between actors and actor management messages, where:

[0114] c) Communication messages between actors: are placed in their corresponding message queues according to the ID information of the destination actor in the message;

[0115] d) Actor management messages: The registry center software module and the node proxy software module process according to the message type, and the processing methods are as follows:

[0116] i. Actor status update message: The registry center parses the message and updates the actor status information table;

[0117] ii. Heartbeat reporting message: The registry center updates the heartbeat information of the sending node;

[0118] iii. Functional actor discovery message: The registry center queries the function list and returns the actor publishing information;

[0119] iv. Functional actor publishing message: The node proxy parses the message and updates the local function list;

[0120] v. Information change broadcast message: The node proxy parses the message and updates the local function list.

[0121] The message queue management software manages the message distribution process. The message distribution process distributes messages for different actors in the same partition buffer, including:

[0122] a) Obtain the first message information in the partition message queue and put it into the message buffer area of the corresponding Actor;

[0123] b) Obtain messages in the buffer area in this way. When the Actor buffer area parsed is not empty, suspend the message distribution work;

[0124] In some or all of the above solutions, the distributed computing function support method supports a load balancing mechanism (the purpose is: while managing messages, implement the load balancing mechanism of the computing resources of the avionics system), as follows:

[0125] During the process of calling a functional Actor, if there are multiple functional Actors available for selection, a static round-robin dispatching algorithm can be adopted to achieve the load balancing of each processing node. The dispatching process is as follows: The Actor information list includes multiple available functional Actors, and each functional Actor is used as an item, where:

[0126] a) After the application Actor sends a request for a function call requirement to the node proxy software module, the node proxy software module responds to the request and queries the corresponding functional Actor information list through the function name input by the application Actor to the node proxy software module;

[0127] b) If there are multiple callable functional Actors in the current function list, the node proxy software module obtains the item of "current used node" in the functional Actor information list and sends the call request to the next functional Actor item;

[0128] c) After the message is sent, set the item of "current used node" to the node that sent the call request.

[0129] Embodiment

[0130] 2.1 Registration center software

[0131] The registration center software manages all Actor information in the cluster, mainly including the update of cluster Actor status information in Actor status management and the heartbeat monitoring of registered Actor nodes in the cluster; function publishing in Actor function management and the change of function list information published according to the change of Actor status.

[0132] 2.1.1 Cluster Actor status management

[0133] For the registry, the Actor status is divided into two types: {online, offline}. The cluster Actor status management software records and manages the online Actor information resident on all nodes in the cluster. The information list is organized by node, and the content of each node list is shown in Table 1, including node location information, the number of Actors resident on the node, the list of Actor information resident on the node, and the heartbeat monitoring information of the node.

[0134] Table 1 Registry Actor Status Information Management Table

[0135]

[0136] Table 1

[0137] The above cluster Actor status information management table can be dynamically added and deleted during the system operation. Only when the registry receives the Actor online message, will it establish the corresponding status table and monitor and update its status.

[0138] 2.1.1.1 Actor Status Information Update

[0139] The information update of the cluster Actor status information management table is mainly divided into the following three situations:

[0140] a) Actor registration: When receiving the Actor online registration message sent by a node in the cluster, add the corresponding Actor information to the corresponding node list and update the Actor quantity information;

[0141] b) Actor cancellation: When receiving the Actor offline cancellation message sent by a node in the cluster, query and delete the corresponding Actor information in the corresponding node list and update the Actor quantity information;

[0142] c) Heartbeat anomaly: When the heartbeat information sent by the supervision node is not received within the preset time, it is considered that the node has failed and data transmission processing operations cannot be performed, so the corresponding information list of the node is deleted.

[0143] 2.1.1.2 Heartbeat Monitoring Mechanism

[0144] The heartbeat monitoring mechanism is to achieve fault isolation in the distributed computing cluster. This mechanism is mainly divided into two parts:

[0145] a) Heartbeat reporting of registered nodes: For the nodes in the cluster that have registered the Actor online in the registry, they need to periodically send heartbeat reporting information to the registry;

[0146] b) Heartbeat monitoring of the registration center: The registration center needs to record the heartbeat reporting information of each node. If the time interval during which a certain node does not send heartbeat reporting information exceeds the set threshold, it is considered that the node has failed.

[0147] 2.1.2 Cluster Actor Function Management

[0148] The cluster Actor function management software mainly realizes the recording and management of all information related to Actor functions in the cluster, and records all function information in the cluster in units of function items. The specific content of each function item list is shown in Table 2, including the function name, the number of Actors in the cluster that can implement this function, the list of Actor information in the cluster that can implement this function (used to mark its specific location), and the number of users and specific information using this function in the current cluster.

[0149] Table 2 Processing Node Function Information List

[0150]

[0151] Table 2

[0152] The establishment of the cluster Actor function list is also dynamic. When the Actor information list is established, its functions are classified, that is, the corresponding function list is formed. Based on the establishment of the function list, the cluster Actor function management software realizes the function publishing and information update publishing functions.

[0153] 2.1.2.1 Function Publishing

[0154] The function publishing function of the registration center is triggered by the function discovery message of the node. When the registration center receives a function discovery request from a node in the cluster, it conducts a global query of the requested function and sends the found function list to the requesting node to complete the function publishing operation.

[0155] 2.1.2.2 Function Information Update Publishing

[0156] When the status of an Actor in the cluster changes, the corresponding function list information also changes. Therefore, the registration center needs to publish the update of the function information to the function-using nodes in real time. The update of the node function information is related to the change of the Actor status in the cluster and also has the following three situations:

[0157] a) Function node addition: When receiving the Actor online registration message sent by a node in the cluster, it is necessary to update the corresponding function list information and publish the update information to all nodes using this function;

[0158] b) Reduction of functional nodes: When receiving an Actor cancellation message sent by a node within the cluster, query and delete the corresponding Actor information in the corresponding node list, and publish the updated information to all nodes using this function;

[0159] c) Failure of functional nodes: When the heartbeat information sent by the supervision node is not received within the preset time, it is considered that the node has failed and can no longer perform data transmission processing operations. Therefore, delete the corresponding information list of this node and publish the updated information to all nodes using this function.

[0160] 2.2 Node proxy software

[0161] The node proxy software is mainly used to manage the status of Actors resident locally, as well as discover, record, and call the information of functional Actors used by the node.

[0162] 2.2.1 Actor status management

[0163] For the node proxy, an Actor has four states: {registered, running, stopped, cancelled}. The following describes the four states and their transformation relationships respectively.

[0164] 2.2.1.1 Actor attribute information

[0165] The attributes of the local Actor information recorded by the node proxy software include the Actor location number, Actor function name, Actor current state, and the number of pending messages in the mailbox, as shown in Table 3.

[0166]

[0167] Table 3

[0168] The local Actor attribute information table is dynamically established with the registration of local Actors, and during the operation of the system, it is managed and maintained according to the real-time state of the Actors.

[0169] 2.2.1.2 Actor registration

[0170] During the registration process of an Actor, the establishment of the local Actor information table is mainly completed. The specific work includes:

[0171] a) Record information such as the processor core number, partition number, and function name according to the deployment location and attributes of the task initiated by the registration behavior;

[0172] b) Update the current Actor state to "registered";

[0173] c) Initialize the mailbox and set the number of pending messages to "0".

[0174] 2.2.1.3 Actor Startup

[0175] The Actor startup completes the process of changing the Actor status to "Running". The local "Running" status of the Actor corresponds to the "Online" status in the registration center. Therefore, the specific tasks during the Actor startup process include:

[0176] a) Sending an "Actor Registration" message to the registration center to complete the "going online" operation of the Actor in the distributed computing cluster;

[0177] b) Updating the current Actor status to "Running";

[0178] c) If the Actor is the first to start in the node, triggering the "periodic heartbeat reporting" operation of the startup node;

[0179] d) Starting the message processing operation.

[0180] 2.2.1.4 Actor Shutdown

[0181] The Actor shutdown completes the process of changing the Actor status to "Stopped". The local "Stopped" status of the Actor corresponds to the "Offline" status in the registration center. Therefore, the specific tasks during the Actor shutdown process include:

[0182] a) Sending an "Actor Deregistration" message to the registration center to complete the "going offline" operation of the Actor in the distributed computing cluster;

[0183] b) Updating the current Actor status to "Stopped";

[0184] c) Processing the unprocessed messages in the mailbox and stopping the message processing operation.

[0185] 2.2.1.5 Actor Deregistration

[0186] Actor deregistration means releasing all storage, computing, and communication resources used by the current Actor. The specific tasks include:

[0187] a) Suspending the corresponding processing tasks;

[0188] b) Clearing the content of the mailbox;

[0189] c) Deleting all relevant attribute information managed by the node proxy.

[0190] 2.2.1.6 Actor Status Change

[0191] The Actor status change is as shown in the appendix Figure 2 as follows. The status trigger operations and change situations are as follows:

[0192] a) The Actor registration is successful: change to the "registered" state;

[0193] b) The Actor registration fails: the distributed computing function fails to start;

[0194] c) The Actor starts: "registered" -> "running", "stopped" -> "running";

[0195] d) The Actor stops: "running" -> "stopped";

[0196] e) The Actor deregisters: "registered" -> "deregistered", "stopped" -> "deregistered";

[0197] 2.2.2 Actor Function Management

[0198] The Actor function management software of the node agent mainly manages the information of the distributed providers of the functions used by this node, that is, the information of the function Actors, including two parts: function discovery and function invocation.

[0199] 2.2.2.1 Function Attribute Information

[0200] The information table of the function Actors available for the processing node is mainly used to record the relevant information of the callable function Actors required. The specific content is shown in Table 4, including the function name, the number of Actors that can provide this function, the function Actor information list (Actor location information), and the function node currently in use.

[0201]

[0202] Table 4

[0203] The information source of the information table of the function Actors available for the processing node is the function publishing message of the registration center. When the local node sends a function discovery request, the node agent obtains the information of all the Actors that can currently provide the required function through message communication and updates it to the information table of the function Actors available for the processing node; when receiving the function information update message published by the registration center, the node agent synchronously updates and maintains the local function Actor information table. Specific Implementation Manner

[0205] During the operation of the system, the Actor can play two roles, namely, function provider and function user. The information interaction between Actors realizes the process of function provision and use; while the registration center, as the system manager, realizes the overall planning and management of all Actor information in the distributed computing cluster. The information transfer and operation relationship among the above three is as shown in the appendix Figure 11 as follows.

[0206] The basic operation process after the distributed computing function support software is started is as follows:

[0207] a) The Actors on each processing node are registered and started, and an "Actor registration" message is sent to the registration center;

[0208] b) During the operation of the Actor, the node agent reports periodic "heartbeat information" to maintain the continuously online state;

[0209] c) When external function support is required during the operation of the Actor task, a "function discovery" request is sent to the registration center;

[0210] d) The registration center provides function information to the requester of the "function discovery" request for "function publishing";

[0211] e) When the Actor task makes a "function call", the node agent queries the function table and sends processing information;

[0212] f) The Actor that receives the information to be processed executes the function. If there is a return message, the "processing result" is returned;

[0213] g) The Actor stops and deregisters, and sends an "Actor deregistration" message to the registration center;

[0214] h) The registration center sends the deregistered Actor information to the nodes that have interacted with it for "Actor information update";

[0215] The function implementation involved in the above process has been described in the technical solution. Next, the dynamic processes of "Actor deregistration / registration", "Actor function discovery / publishing", and "function Actor call" with multi-level interactions are described.

[0216] 1. Actor Registration / Deregistration

[0217] The Actor registration and deregistration processes described in this section refer to the state change behaviors in the registration center. The Actor registration process is as shown in the appendix Figure 12 as follows:

[0218] a) The application calls the local "Actor registration" interface, and the node agent software establishes its local management information to complete local registration;

[0219] b) The application calls the "Actor start" interface. After the node agent updates its local state, it sends a status information update message of "Actor registration" to the registration center;

[0220] c) The registration center adds the actor information to the cluster actor status information list and establishes the corresponding actor function list to complete the registration within the cluster.

[0221] The actor cancellation process is as attached Figure 13 as shown:

[0222] a) The application calls the "Actor Stop" interface, and the node proxy software updates its local management information.

[0223] b) The application calls the "Actor Deregistration" interface. After the node proxy deletes the local information of the deregistered actor, it sends a status information update message of "Actor Deregistration" to the registration center.

[0224] c) The registration center deletes the actor information from the cluster actor status information list and deletes the corresponding actor function list to complete the deregistration within the cluster.

[0225] 2. Actor Function Discovery / Publishing

[0226] Actor function discovery / publishing is the interaction between the registration center and the function users. The process is as attached Figure 14 as shown:

[0227] a) The application calls the "Function Discovery" interface, and the node proxy software sends the function discovery message to the registration center to complete the function discovery process.

[0228] b) The registration center conducts function search and sends the found information to the node proxy through the function publishing message.

[0229] c) After receiving the function publishing message, the node proxy parses the content and establishes the corresponding local function information table to complete the function publishing process.

[0230] 3. Functional Actor Invocation

[0231] The functional actor invocation process is the interaction between the registration center and the function providers. The process is as attached Figure 15 as shown:

[0232] a) The application calls the "Function Invocation" interface, and the node proxy software queries in the local function information list to find the available function node information.

[0233] b) The node proxy of the function user node sends the data message to be processed to the remote node proxy of the function provider node. The remote node proxy queries in the local actor information list to find the specific location of the processing actor.

[0234] c) The remote node agent passes the information to be processed to the functional Actor for processing operations, completing the call to the functional Actor;

[0235] d) If the call fails or there are other return messages, the return data is reversely replied to the application Actor that initiated the function call through the above process.

[0236] 4. The distributed computing service uses the operation

[0237] Based on the functional design and description of the above distributed computing function support software, the operation process of the distributed computing service using this support software is described. The flowchart is shown in the appendix Figure 16 Among them, the distribution function node, the processing function node, and the integration function node respectively refer to the processing nodes that host the distribution function Actor, the processing function Actor, and the integration function Actor. These nodes can be deployed in different cores of the same processor, or can be deployed in different processors and different modules to achieve distributed computing within different scopes.

[0238] In the appendix Figure 16 In each node, the application Actor and the node agent software are not functionally differentiated, so the internal interaction between the application and the node agent software is not described in the figure. During the distributed computing process, the specific interaction process between each processing node and the registration center is as follows:

[0239] a) The distribution function Actor, the processing function Actor, and the integration function Actor respectively send "Actor registration" messages to the registration center for in-cluster registration;

[0240] b) According to the received registration messages, the registration center respectively establishes the Actor information table of each processing node and the function list of each function item;

[0241] c) The distribution function node sends a message request of "processing function discovery". After querying by the registration center, the Actor information of the processing function node A and the processing function node B is "functionally published";

[0242] d) The processing function node sends a message request of "integration function discovery". After querying by the registration center, the Actor information of the integration function node is "functionally published";

[0243] e) After the distribution function Actor distributes tasks, it calls the "function call" interface and sends the message to be processed to the processing function Actor on each processing function node for data processing;

[0244] f) After each processing function Actor completes data processing, it calls the "function call" interface to send the processed data to the integration function Actor on the integration function node for data integration;

[0245] g) After the integration Actor completes data integration, it returns or reports the data according to the pre-designed process, completing a basic distributed computing process.

[0246] As described above, the above are only specific embodiments of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present disclosure should be covered by the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A method for supporting distributed computing functions of an airborne embedded system, applicable to the distributed computing of airborne avionics system data. The sum of all the hardware computing resources used in the avionics system serves as a distributed computing cluster. A cluster has multiple computing nodes, and each node includes an Actor model. The smallest management unit in the Actor model is used as an Actor. It is characterized in that, All computing node Actors include the first Actor, which is the set of all Actors in the distributed computing cluster; the node proxy software manages the second Actor, which is the set of all Actors on each node. The first Actor includes multiple second Actors. The method includes: Divided into a registration center software module, a node proxy software module, and a message queue management software module according to functions. Among them: The registration center software module realizes data interaction between the registration center software module and the node proxy software through the message queue management software. Among them: The registration center software is used to manage all Actors in the distributed computing cluster, and the management method is based on the dimensions of the functions and status attributes of all Actors; the node proxy software module is used to manage all local Actors on its resident node; The message queue management software module is used to manage all Actor message interactions with a method to support the load balancing mechanism. Through the joint management of the registration center software module, the node proxy software, and the message queue management software, it realizes the distributed execution and calculation process of complex software in the cluster; Configure the registration center software module to have an Actor status management function. The registration center software module can obtain the update of the status information of all Actors in the distributed computing cluster in real time. The Actor status information includes: Actor status, node location information, the number of Actors resident on the node, and the list of Actor information resident on the node; 1) The conditions for triggering the status management function include: a) Actor registration: When receiving the online registration messages of some of the second Actors sent by the nodes in the cluster, mark them in the node list corresponding to the first Actor in the registration center software, and the quantity information in the node list corresponding to the first Actor; b) Actor cancellation: When receiving the offline cancellation messages of some of the second Actors sent by the nodes in the cluster, query and delete the offline Actor information in the node list corresponding to the first Actor in the registration center software, and the quantity information in the node list corresponding to the first Actor; c) Heartbeat anomaly: When the heartbeat information sent by the B monitoring node is not received by A within the preset time, delete the list of the second Actors corresponding to the node with the heartbeat anomaly in the node list corresponding to the first Actor; 2) The method for monitoring the heartbeat monitoring information of the monitoring node includes that the heartbeat monitoring information of the node includes the heartbeat reports of all node proxies and the heartbeat monitoring of the registration center. Among them, The node proxy software module reports the heartbeat of all the second Actors, and the registration center software module monitors the heartbeat of the first Actor; the registration center software module records the heartbeat report information of each node.

2. The method according to claim 1, wherein The registry software has an Actor function management function, which is updated according to the changes in all the second Actor states. The updated published function information content includes: the update of the function information list of the registry software module, and the function information list includes sub-tables corresponding to multiple Actors with different functions, where: 1.1) The registry software management module resides on all nodes in the cluster and manages the second Actor function information list, which includes function name, number of function Actors, function Actor information list, number of registered nodes, and registered node information list; 1.2) The registry software has a first Actor publishing function. When the registry receives a request for function discovery from the node proxy software module, it conducts a global query for the requested function and sends the sub-table corresponding to the found function to the requesting node to complete the function publishing operation; 1.3) The registry software has a function of updating and publishing function information. Specifically, when the state of the second Actor in the cluster changes, the registry software module sends function information updates to other nodes, and the other nodes are: the nodes that have sent requests for the corresponding function. The registry software module sends the updated sub-table to the node proxy software module. The situations where the state of the second Actor in the cluster changes are as follows: the state change includes the addition or reduction of function nodes or the failure of function nodes, where: a) Addition of function nodes: When receiving the second Actor online registration message sent by a node in the cluster, it is necessary to update the corresponding function sub-table and publish the update information to all users; b) Reduction of function nodes: When receiving the second Actor cancellation message sent by a node in the cluster, query and delete the function information of the corresponding Actor in the corresponding sub-table, and publish the update information to all nodes using this function; c) Failure of function nodes: When the heartbeat information sent by the supervision node is not received within the preset time, it is considered that the node has failed and can no longer perform data transmission processing operations. Therefore, delete the corresponding information list of this node and publish the update information to all nodes using this function.

3. The method according to claim 1, characterized in that The node proxy software module manages the Actors resident locally, that is, manages the state of the second Actor. The node discovers the information of the first Actor used for the function. The second Actor resident locally requests the function to be used from the node proxy software, and the node proxy software sends a request to the registry. The registry software module responds to the request of the node proxy software module and returns the function information corresponding to the corresponding first Actor; The message queue management software module includes message processing operations. Each Actor is assigned a corresponding mailbox when being managed, and the mailbox includes the message content processed by the Actor and its message quantity; The node proxy software module manages the state of the Actors resident locally, including the management of local Actor state information and the management of local Actor state changes: The content of the local second Actor status information includes: the Actor number, the Actor function name, the Actor status, and the status includes registration and the number of messages to be processed; The node agent software module manages the changes in the local resident second Actor status information. Specifically, its status information list is dynamically established as the second Actor is registered, and during the operation of the airborne avionics system, including operations such as stopping, starting, and deregistering the second Actor, the real-time status is managed and maintained. The specific process is as follows: The node agent software module manages and maintains the Actor in real time according to the Actor's operations; a) Steps for the second Actor to register: Establish the second Actor status information table. The specific work includes: i. Record the deployment avionics system location and attributes according to the task initiated by the registration behavior. The avionics system location includes the processor core number and partition number, and the attributes include the name information corresponding to the function; ii. Update the current Actor status in the second Actor to indicate registered; iii. Initialize the number of messages to be processed to "0"; b) Actor start: The Actor function starts and the content changes, including: i. Send a "second Actor registration" message to the registration center software module to complete the "online" operation of the second Actor in the distributed computing cluster. The registration center software module updates its status information list by itself; ii. Update the current second Actor status to "running"; iii. If the first Actor in the node starts, trigger the "periodic heartbeat reporting" operation of the start node; iv. Start the message processing operation; c) Actor stop: The Actor function stops and the content changes, including: i. Send a "deregistration of the Actor performing the operation of the second Actor" message to the registration center software module, and the Actor performing the operation performs an "offline" operation in the first Actor; ii. Update the status of the current Actor performing the operation to "stopped"; iii. Process the unprocessed messages in the mailbox and stop the message processing operation; d) Actor deregistration: Release all storage, computing, and communication resources used by the Actor, including: i. Suspend the corresponding processing process; As a software process, when the Actor receives the deregistration instruction sent by the Actor, it suspends the process; ii. Empty the content of the mailbox; iii. Delete all relevant second Actor status information managed by the node agent.

4. The method according to claim 3, characterized in that, The node proxy software discovers and makes function calls to the Actor information of the second Actor's usage functions. The function Actor information management provides the first Actor with the functions required by the second Actor. The function Actor information is stored in the function Actor information table, and the function Actor information includes the following contents: function name, the number of the first Actors available to provide the functions required by the second Actor, the information list of the first Actors providing the functions required by the second Actor, and the currently used node, where: The node proxy software module discovers the function Actor information used by the second Actor, including that the information source of the function Actor information table is the function publishing message of the registration center software module. When the local node makes a function discovery request, the node proxy software module obtains the information of all the first Actors that can provide the required functions currently through message communication and updates the content of the processing node function Actor information table; when receiving the message of the updated published function information from the registration center software module, the node proxy software module synchronizes and updates the maintenance in the local function Actor information table. The specific process is as follows: a) The second Actor includes a local application Actor, and the local application Actor proposes a processing function requirement. b) The node proxy software module sends a "function discovery" request to the registration center software module and receives the "function publishing" message of the node proxy software module. c) The node proxy software module records the message content published by the registration center software module in the function Actor information table.

5. The method according to claim 4, wherein It also includes the node proxy software to call the function Actor used by the local application Actor, including: a) The local application Actor proposes a "function call" request. b) The node proxy software module queries in the function Actor information table, finds the content of the corresponding function item, and makes a local / remote function call in the form of message sending. c) If the call of the corresponding function item has a return value, after the node proxy software module receives the information content, it notifies the local application Actor of the execution result.

6. The method according to claim 5, characterized in that The message queue management software module is responsible for the sending and receiving management of all messages of the first Actor. The message queue management software is used to support the load balancing mechanism to manage all Actor message interactions by methods, including the pre - definition of message type definition, message frame format definition, and message queue management. The pre - definition differentiates the message types according to different usage scenarios and defines the message frame format according to the content information. The message type definition includes message type and message frame format, where: The communication message between the first Actor and the second Actor; the status update message of the first Actor or the second Actor; the heartbeat reporting message; the discovery / publishing message of the first Actor or the second Actor; the information change broadcast message. Message frame format definition. The message queue management software defines the internal message frame format, including three items: destination node ID, message type, and message content. The specific content filled in the "message content" part has its own message frame format according to different message types, and the specific content definition is as follows: a) Messages for communication between Actors: including messages to be processed and reply messages; i. Messages to be processed: The content format is source node ID, source Actor ID, destination Actor ID, length of data to be processed, and data to be processed; ii. Reply messages: The content format is source node ID, source Actor ID, destination Actor ID, length of reply information data, and reply information; b) Actor status update messages: Registration and cancellation of Actors in the registration center. The message sender is the node proxy software module, and the receiver is the registration center software module. The message content format includes Actor deployment node ID, number, status, and function name; c) Heartbeat reporting messages: Heartbeat reporting operation of the node proxy. The message sender is the node proxy software module, and the receiver is the registration center software module. The message content format is the node ID where the node proxy software is located; d) Actor discovery / publishing messages: Implement function discovery and publishing operations. This process requires information interaction between the node proxy software and the registration center software. Among them: i. Function Actor discovery messages: The message sender is the node proxy software, and the receiver is the registration center software. The message content format includes source node ID and name of the required function item; ii. Function Actor publishing messages: When the message sender is the registration center software and the receiver is the node proxy software, the message content format includes receiving node ID, published function name, number of Actors providing the function, and information list of function Actors; Broadcast messages: The registration center updates and publishes function information. The message content format includes change type, function name, and function Actor information. The change type is addition or reduction of function Actors.

7. The method according to claim 6, wherein The message queue management software module uniformly manages the message queues on the nodes, and uses the circular buffer mechanism to implement the basic functions of message push and pop in the message queue. To adapt to the partition mechanism, the message queue is established in the shared data area, and each partition has an independent message queue. Among them: Message management content includes five parts: message sending, message receiving, message parsing, message encapsulation, and message distribution, which realizes message parsing of received messages and putting them into their respective message queues, as well as encapsulating and sending messages taken out from the message queues. Among them: Message sending and message receiving include the message queue management software managing the message sending and receiving processes. Specifically, message receiving polls messages through periodic tasks; message sending is triggered by interface calls. The sources / destinations of received / sent messages are divided into two types: local messages and remote messages as follows: a) Remote messages are messages transmitted through the underlying communication medium, and the communication transceiver interface can be called; b) The sending and receiving of local messages requires the support of message queue management software. The information transmitted by the sending interface is temporarily stored and the receiving process is notified to receive the message, thus completing the transmission process of local messages.

8. The method according to claim 7, wherein It also includes the management of message parsing and message encapsulation. According to the message type, the message to be sent is encapsulated according to the message frame format; the received message is parsed to distinguish the communication messages between Actors and the Actor management messages, where: c) Communication messages between Actors: According to the ID information of the destination Actor in the message, it is placed in its corresponding message queue; d) Actor management messages: The registration center software module and the node proxy software module process according to the message type, and the processing methods are as follows: i. Actor status update message: The registration center parses the message and updates the Actor status information table; ii. Heartbeat reporting message: The registration center updates the heartbeat information of the sending node; iii. Functional Actor discovery message: The registration center queries the function list and returns the Actor publishing information; iv. Functional Actor publishing message: The node proxy parses the message and updates the local function list; v. Information change broadcast message: The node proxy parses the message and updates the local function list.

9. The method according to claim 8, characterized in that, The message queue management software manages the message distribution process. The message distribution process distributes messages for different Actors in the same partition buffer, including: a) Obtain the first message information in the partition message queue and place it in the message buffer of the corresponding Actor; b) Obtain the messages in the buffer in this way. When the parsed Actor buffer is not empty, pause the message distribution work; During the process of calling functional Actors, if there are multiple functional Actors to choose from, a static round-robin dispatching algorithm can be adopted to achieve the load balancing of each processing node. The dispatching process is as follows: The Actor information list includes multiple available functional Actors, and each functional Actor is an item, where: c) After the application Actor sends a request for a function call requirement to the node proxy software module, the node proxy software module responds to the request and queries the corresponding functional Actor information list through the function name input by the application Actor to the node proxy software module; d) If there are multiple callable functional Actors in the current function list, the node proxy software module obtains the "currently used node" item in the functional Actor information list and sends the call request to the next functional Actor item; e) After the message is sent, set the item of the "currently used node" to the node that sent the call request.

Images