An unmanned system open architecture and command and control method for generalization command and control

Abstract

The application provides an unmanned system open architecture for general command and control, comprising: at least one unmanned system, the unmanned system comprising at least one unmanned system instance, the unmanned system instance comprising at least one hardware component, and at least one application software running on part of the hardware components; a first unmanned system instance is used for sending a first message, the first message carrying first information, a sending address and a receiving address; a second unmanned system instance is used for, when the first message is received, adopting a data link message configuration file in a configuration file library to identify whether the message format of the first message is consistent with the message format adopted by the second unmanned system; when the message formats are inconsistent, calling a data element dictionary to convert the first message to obtain a second message, and forwarding the second message according to the receiving address in the first message. The unmanned system can realize general command and control of "multi-platform and multi-station".

Description

Technical Field

[0001] This invention belongs to the field of open architecture for unmanned systems, and in particular relates to an open architecture and command and control method for unmanned systems oriented towards generalized command and control. Background Technology

[0002] Since the beginning of this century, unmanned systems have been widely developed and applied in combat. Simultaneously, the issues of information exchange and collaborative operation between unmanned systems of different countries, domains, and models have become increasingly prominent, particularly the problems of cross-border joint operation, cross-domain collaborative operation, and the systematic application of heterogeneous platforms. Currently, to address the interoperability and universal command and control issues encountered between unmanned systems, various countries are increasingly eager to develop interoperability standards for unmanned systems and to create universal command and control systems capable of cooperating across multiple countries and operating various models of unmanned systems. Over the past two decades, major world powers have conducted research on related technologies and solutions. The United States' unmanned systems development roadmaps over the years have consistently mentioned developing interoperability between unmanned aerial vehicle (UAV) models, between cross-domain unmanned systems, and between armed and unmanned systems.

[0003] Currently, my country's unmanned system control stations are still in the homogeneous platform control stage, lacking a complete and unified open architecture. This makes it impossible to standardize the design and development of a universal command and control system for heterogeneous unmanned systems. The lack of defined standard message formats, protocols, and communication mechanisms for unmanned systems directly leads to tight vertical coupling based on system model. Different service definitions for various platforms and models fail to support cross-platform universal command and control requirements. Furthermore, there are no development tools or service tools that support open architectures and standard implementation. These problems will severely restrict the development of the systematic application of unmanned equipment. Summary of the Invention

[0004] This invention proposes an open architecture for unmanned systems oriented towards universal command and control, which is used to solve the problem of interconnection, interoperability and interoperability between the various components of unmanned systems, and can realize universal command and control of unmanned systems with "multi-platform and multi-station".

[0005] This invention provides an open architecture for unmanned systems oriented towards generalized command and control, comprising: at least one unmanned system, the unmanned system including at least one unmanned system instance, the unmanned system instance including at least one hardware component, and at least one application software running on some of the hardware components;

[0006] The first unmanned system instance is used to send a first message, which carries first information, a sending address, and a receiving address. The first information is generated by the first application software. The sending address is generated by the first application software that generates the first information, the first hardware component that forwards the first information, the first unmanned system instance, and the unified encoding address of the first unmanned system. The receiving address includes the unified encoding address of the second unmanned system, the second unmanned system instance, the second hardware component, and the second application software.

[0007] The second unmanned system instance is used to identify whether the message format of the first message is consistent with the message format used by the second unmanned system when the first message is received, using the data link message configuration file in the configuration file library; if they are inconsistent, the first message is converted by calling the data element dictionary to obtain the second message, and the second message is forwarded according to the receiving address in the first message; the second message is consistent with the message format used by the second unmanned system.

[0008] The second application software is used to execute the information carried in the second message when the second message is received.

[0009] Optionally, the sending address in the first message includes, in ascending order of bits, the first level code of the first unmanned system to which the first application software belongs, the second level code of the first unmanned system instance, the third level code of the first hardware component, and the fourth level code of the first application software.

[0010] The receiving address, in ascending order of bits, includes the first-level code of the second unmanned system to which the second application software belongs, the second-level code of the second unmanned system instance, the third-level code of the second hardware component, and the fourth-level code of the second application software.

[0011] Optionally, the second unmanned system instance is specifically used to: determine the data elements included in the first message; determine the required conversion path for each data element in the data element dictionary according to the message format adopted by the first and second messages; generate conversion code according to the conversion path; and run the conversion code to convert the message format of the first message to obtain the second message.

[0012] Optionally, the conversion path may include at least: reference frame conversion, precision conversion, unit conversion, length conversion, and encoding method conversion.

[0013] Optionally, both the first and second messages include a message header and a message body; the message header includes the sender and receiver's encoded addresses, message code, and message attributes; the message body uses a variable-length font to carry the message content, and the messages include command, query, and notification types.

[0014] Optionally, the first and second messages can be sent using either point-to-point delivery or broadcasting.

[0015] Optionally, when the message set is transmitted via broadcast, the recipient address in the message header is a preset address.

[0016] Optional, unmanned systems include different types of drones, unmanned vehicles, unmanned boats, control stations, and unmanned underwater vehicles.

[0017] Technical effects of the invention:

[0018] This invention proposes a four-layer message routing information architecture model representation method consisting of an "unmanned system layer, an unmanned system instance layer, a hardware component layer, and an application software layer." It establishes a standard method for defining unmanned system service interfaces and constructs a complete, unified, and scalable open architecture and application mechanism for unmanned systems. This enhances the scalability and portability of unmanned systems, effectively solves the problem of effectively integrating new technologies such as artificial intelligence and big data applications, and addresses the challenges of information interconnection and application interoperability across multiple platforms and stations in systematic mission scenarios. It achieves "interconnection, interoperability, and interoperability" between heterogeneous unmanned platforms such as UAVs / unmanned vehicles / unmanned ships and ground command and control systems, as well as airborne / shipborne command and control systems. This significantly improves the generalized command and control level of unmanned systems across multiple platforms and stations, thereby enhancing the core capabilities of systematic mission execution based on information systems, and possesses significant versatility. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the identity definition mechanism for unmanned systems;

[0020] Figure 2 This is a schematic diagram of the representation method of the four-layer message routing information architecture model;

[0021] Figure 3 This is a schematic diagram of a layered decoupled message transmission mechanism for unmanned systems.

[0022] Figure 4 This is a flowchart of message format conversion;

[0023] Figure 5 This is a diagram illustrating the Service Interface Definition Language (SIL).

[0024] Figure 6 This is a schematic diagram of an unmanned system architecture design solution for generalized command and control. Detailed Implementation

[0025] The open architecture for generalized command and control of unmanned systems provided by the present invention will be further described in detail below with reference to the accompanying drawings.

[0026] To break down the barriers to universal command and control caused by siloed development, and addressing the low interoperability issues existing within various types of unmanned systems, between unmanned systems and command networks, between different unmanned systems, and between unmanned systems across different domains, this invention targets heterogeneous unmanned systems. With the goal of universal command and control across multiple platforms and stations, it constructs a modular, loosely coupled, and scalable information architecture encompassing unmanned platforms, control stations, and links, where each entity has a globally unique identity. It adopts a message-addressable information transmission structure, specifying data formats, communication protocols, and message format conversion mechanisms between nodes at different levels, achieving information transmission independent of technology, hardware, and operating systems. It organizes the main services in the unmanned systems domain, forming an industry-wide recognized service framework and service items, defining standardized interfaces for each service, and enabling message sharing among heterogeneous unmanned systems based on a unified universal message set (message header + message body). Finally, supplemented by software development kits and unified service tools, it realizes the practical application of unmanned system architecture specifications, message standards, and transmission mechanisms for universal command and control.

[0027] like Figure 1-6 As shown, the specific implementation method is as follows:

[0028] 1. A globally unified coding identity definition mode

[0029] A globally unified identity definition model layers the unmanned system, assigning unified numbers to the unmanned system layer (ID1), unmanned system instance layer (ID2), hardware component layer (ID3), and application software layer (ID4). Message interaction is entirely based on these numberings. For details on the identity definition model, please refer to [link to relevant documentation]. Figure 1 .

[0030] 1) The unmanned system layer contains ID1, and the unmanned system instance layer contains ID2. ID1 defines a unique number for different models, and ID2 is used to instantiate and number each model.

[0031] The model numbers of systems such as drones, unmanned vehicles, unmanned ships, and control stations are identified by ID1. The ID1 definition table is shown in the table below:

[0032] Table 1 ID1 Definition Table

[0033] Type 01 UAV 0x10 Type 02 UAV 0x14 Type 01 unmanned vehicle 0x20 Type 02 unmanned vehicle 0x24 Type 01 unmanned surface vessel 0x30 Type 02 unmanned surface vessel 0x34 …… 0x40~0x7c Type 01 control station 0x80 Type 02 control station 0x84 …… 0x88~0xfc

[0034] The identity address of an unmanned platform is 0 to 0x7F, where 0x7F is not used as a single-machine designated identity, but as a broadcast address. Therefore, if a broadcast is performed to all unmanned platforms within a group, the ID1 / ID2 address of the unmanned platform must be filled with 0x7FFF, that is, the high byte is filled with 127 (0x7F) and the low byte is filled with 255 (0xFF).

[0035] The control station identity address ranges from 0x80 to 0xFF, where 0xFF is not used as the designated identity for a single control station but as the broadcast address. Therefore, if a broadcast is required to all control stations, the receiver address ID1 / ID2 must be filled with 0xFFFF, i.e., both the high and low bytes must be 255.

[0036] The number of unmanned systems such as drones, unmanned vehicles, and unmanned ships is identified by ID2, ranging from 0 to 0xFF, with a maximum of 255 units allocated to each model. For example, the ID2s of drones 01 and 02 of model 01, which have an ID1 of 0x10, are 0x01 and 0x02, respectively.

[0037] 2) The hardware component layer (ID3) defines the specific hardware components inside each unmanned system, such as UAVs, unmanned ships, unmanned vehicles, and control stations, including general display and control consoles, flight control systems, power systems, and mission systems.

[0038] 3) The application software layer (ID4) is bound to the hardware component layer, defining the specific software within the unmanned system. Each software with interactive capabilities has an independent ID4, such as message processing, platform control, propulsion control, and positioning and navigation software. Interoperability and collaborative applications between the unmanned system's software and hardware layers can be achieved through the unique IDs of each layer.

[0039] Taking unmanned surface vessels as an example, the definitions of ID3 and ID4 are shown in the table below:

[0040] Table 2 ID3 / ID4 Definition Table

[0041]

[0042]

[0043] 4) Proxy ID3 and ID4 Definitions: In practical use, if there are situations where information delivery is not broadcast but also does not need to be delivered to a specific entity's hardware or software, i.e., entity ID3 / ID4 is not required. To meet usage requirements, proxy node ID3 / ID4 is added to the ID3 / ID4 allocation tables for both the UAV platform and control station, as shown in Table 3. When allocating ID3 / ID4 for entity hardware or software, the use of proxy node ID3 / ID4 should be avoided.

[0044] Table 3. Definitions of Agent ID3 and ID4

[0045]

[0046] 2. A layered and decoupled message transmission mechanism

[0047] 1) Message Definition

[0048] A layered, decoupled message transmission mechanism is based on a unified identity definition pattern. According to the identity identifier defined in the message header, it supports both point-to-point delivery and broadcasting for message transmission. A unified message format is defined, consisting of a message header and a message body. The representation method of the four-layer message routing information architecture model is described in [link to documentation]. Figure 2 .

[0049] The message header defines the sender and receiver addresses, message code, and message attributes, as detailed in the table below:

[0050] Table 4 Message Header Definitions

[0051] 1 Message Attributes Unsigned short 2 2 Command Code / Core Message Unsigned short 2 3 Target application ID byte 1 4 Destination Hardware Component ID byte 1 5 Target Unmanned System Instance ID byte 1 6 Destination Unmanned System ID byte 1 7 Source Application ID byte 1 8 Source Hardware Component ID byte 1 9 Source Unmanned System Instance ID byte 1 10 Source Unmanned System ID byte 1 11 Data control (bytes) Unsigned short 2 12 Serial Number Unsigned short 2 Total bytes 16

[0052] For example, the sender and receiver addresses can also be arranged in descending order of bits as ID1, ID2, ID3, ID4.

[0053] The message body uses a variable-length font to carry the message content. For example, messages can be categorized into command, query, and notification types, with message codes and content formats defined for 10 main messages in each category. See the table below for detailed message code definitions:

[0054] Table 5 Message Body Code Definitions

[0055]

[0056]

[0057] 2) Message transmission

[0058] Messages are transmitted using two methods: point-to-point delivery and broadcasting.

[0059] a) Point-to-point delivery: The receiver is uniquely identified in the message header as ID1 / ID2 / ID3 / ID4. The message will be correctly delivered to the receiver, and interaction occurs between the sender and receiver. When used for data exchange, it is necessary to identify both the sender's and receiver's IDs. Identifying the unique data receiver through these IDs significantly reduces the burden of handling invalid data and improves the interaction flow. Figure 3 .

[0060] b) Broadcast transmission method: In order to improve the efficiency of information delivery between unmanned systems, this message transmission mechanism supports broadcast transmission capability. Address 255 (FFh) is defined as "broadcast address". When the ID of the receiver is 255, the message will be transmitted in the form of broadcast. All receivers that meet the conditions can receive the message, avoiding network pressure caused by multiple applications having to send and receive at the same time.

[0061] 3. Message format conversion

[0062] Message format conversion is used to convert between different message formats. First, the data link message configuration file in the configuration file library is used to determine whether the received message is consistent with the message format used by this unmanned system instance. If they are inconsistent, message format conversion is performed. Then, the converted message is encapsulated and sent to the application software.

[0063] When an unmanned system instance is a node such as a control station or a drone, the unmanned system instance can store a configuration file library. The configuration file library contains unified protocol description files for various message formats, stored in XML format. The XML format files are generated by a protocol description tool and can describe the data frame structure, data element relationships, and receiving / sending rules of the message format.

[0064] The unmanned system instance receiving the message extracts the XML format files for the two message formats requiring conversion from the configuration file library. Based on the information in the XML format files, it parses the message to obtain a set of data elements. The conversion path for each data element is determined in the data element dictionary. The specific steps are as follows: 1) Determine the mapping relationship between data elements in the two message formats based on their meanings; 2) Query detailed information about the data elements based on their encoding, including reference frame, precision, unit, length, and encoding method; 3) Determine the conversion path for each data element, including reference frame conversion, precision conversion, unit conversion, length conversion, and encoding method conversion, and extract the execution code blocks for each conversion from the data element dictionary. These blocks are then combined to generate conversion code for the two message formats; 4) Run the conversion code to implement the message format conversion; 5) Encapsulate the converted data elements into the message format adopted by this unmanned system instance based on the XML format files. Detailed steps are as follows... Figure 4 As shown.

[0065] 4. A method for defining service interfaces for generalized command and control

[0066] The core objective of the open architecture for unmanned systems is to achieve universal control between the control station and different unmanned platforms. This invention defines the messages and protocols used by various services in the unmanned system to achieve message transmission. By standardizing message sets and related protocols based on unified message header and message body definitions, interoperability within the unmanned system is ensured.

[0067] This invention defines six major service categories, each a set of standard application layer interfaces, providing methods for communication and coordination within and outside the hardware or software entities of unmanned systems. The service interfaces for generalized command and control mainly include six categories: platform monitoring, action planning, information processing, information access, situation display, and comprehensive management.

[0068] For application software running on hardware components, each application software defines at least one of the above six types of service interfaces.

[0069] When an application receives a message, it can distribute and process the message according to the service interface corresponding to the message content.

[0070] Each service definition is identified in the form of a text file and an XML file containing the service interface. Each service definition includes seven parts: service identifier, description, scope, external references, constant definitions, type definitions, and message definitions. See [link to documentation]. Figure 5 .

[0071] The meanings of each part are as follows:

[0072] Service Identifier: Defines a service's identifier;

[0073] Description: A text-based description of the service;

[0074] Scope of use: Text type, assumptions about the service usage environment, usage conditions, usage constraints, etc.;

[0075] External references: Define the external variables and files referenced by this service;

[0076] Constant definition: Defines the set of constants used by this service;

[0077] Type definition: Defines the format of the custom data type used by this service;

[0078] Message definition: Defines the message format used by this service, including input and output formats, and uses the standard format of message header + message body.

[0079] 5. Software development / service toolkit based on unified standards

[0080] The architecture software development kit uses a C++ application definition interface and builds a fully open-source codebase under the standard architecture version. It provides common core services and message sets for command and control of unmanned systems. Software developers can view all the code and modify it adaptively as needed. It provides a simplified state machine model and supports customized combination of architecture services. Through the event service message engine, it can dynamically configure the hardware and software components of unmanned systems and support the early verification of the architecture design results of unmanned systems.

[0081] It provides a graphical modeling approach, supporting top-down architecture services and message modeling from "system-hardware-software," primarily including all fields and functions of the standard architecture. This allows for the rapid generation of code needed by developers, enabling them to generate architectural code for messages in unique formats, styles, and even languages. Through a software development / service toolkit based on unified standards, it provides solutions for the architecture design of unmanned systems for generalized command and control. Figure 6 .

[0082] Based on existing technologies such as generalized ground station system architecture and IP network routing, this invention proposes a four-layer message routing information architecture model representation method consisting of an "unmanned system layer, unmanned system instance layer, hardware component layer, and application software layer." It establishes a standard unmanned system service interface definition method and constructs a complete, unified, and scalable open architecture and application mechanism for unmanned systems. This enhances the scalability and portability of unmanned systems, effectively solves the problem of effectively integrating new technologies such as artificial intelligence and big data applications, and addresses the challenges of information interconnection and application interoperability across multiple platforms and stations in systematic mission scenarios. It achieves "interconnection, interoperability, and interoperability" between heterogeneous unmanned platforms such as UAVs / unmanned vehicles / unmanned ships and ground command and control systems, as well as airborne / shipborne command and control systems. This significantly improves the generalized command and control level of unmanned systems across multiple platforms and stations, thereby enhancing the core capabilities of systematic mission execution based on information systems.

[0083] This invention proposes a solution for interoperable and collaborative applications and generalized command and control of unmanned systems. By defining globally unified coded identity identifiers, hierarchically decoupled message addressing methods and message formats, a message conversion mechanism based on a unified data element dictionary, and an information transmission mechanism where messages and transmissions are independent, it moves from the traditional platform-station bundled identification to a system-wide hardware and software definition with unified coded identifiers. Furthermore, by guiding the development of unmanned systems through a unified development toolkit, it enables the full-element network information transmission, processing, and sharing of unmanned systems, achieving generalized command and control across multiple platforms and stations. This completely solves the problem of information interconnection and application interoperability across multiple platforms and stations in systematic mission scenarios.

[0084] The present invention has the following five main technical features:

[0085] (1) Construct a globally unified coding unmanned system identity definition mode. By dividing the unmanned system functional layers, it is divided into four layers from top to bottom: unmanned system layer, unmanned system instance layer, hardware component layer, and application software layer. Each entity has a globally unique identity, which supports any node within the unmanned system and between unmanned systems to provide or obtain services to each other.

[0086] (2) Define a layered decoupled message addressing method between unmanned systems, specify the data format and communication method between nodes (the message header defines the common characteristics of all messages), and support point-to-point data distribution and broadcast data transmission through the definition of the message header.

[0087] (3) An automated message format conversion method based on a data element dictionary is proposed. By querying the mapping relationship, detailed information and conversion path of data elements in the data element dictionary, the code for message format conversion is generated, and the conversion between message formats is automatically completed.

[0088] (4) Design a unified service interface definition for unmanned systems, including six major categories of services such as platform monitoring, action planning, information processing, information access, situation display, and comprehensive management. The unified service interface definition provides a stable and scalable system architecture. Unmanned systems in various fields can realize information sharing, process invocation and other generalized command and control activities through the service interface. Ultimately, it enables the sharing of data, information and materials within the UAV system, between UAV systems, and between UAV systems and other external systems, and to work effectively together. This is an important manifestation of collaborative capability.

[0089] (5) Based on a unified standard software development toolkit and service tools, it provides standardized middleware for the software of each unmanned system in the system, which facilitates the standardization of software and data interaction and operation with other standardized systems and software. It supports the rapid deployment of customized software based on this architecture in unmanned systems, facilitates top-down graphical modeling of customized architecture services and messages, and improves the efficiency of architecture code generation.

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

[0091] (1) A complete information architecture specification for generalized command and control of heterogeneous unmanned systems was proposed, which clarified the multi-level addressing mode, sorted out and formulated the relevant general message format according to the message type, formed a globally unique standard identity identifier and a standard message data format, solved the problem of inconsistent information architecture and inconsistent data format caused by different research and development units and different implementation technology approaches of unmanned systems, and broke down the barrier to generalization.

[0092] (2) An automated message format conversion method based on a data element dictionary is proposed to automate the complex and cumbersome message format conversion work. As a general conversion method, it can be applied to the conversion between various types of message formats, greatly improving the efficiency of message format conversion.

[0093] (3) A service interface definition method for generalized command and control is proposed. By providing a set of standard application layer interfaces, it provides a mechanism and means for communication and coordination within and outside the hardware or software entities of unmanned systems. This reduces the problems caused by protocol or interface conversion and data format parsing for unmanned system design and development units. It can promote complete and barrier-free communication and control between systems, improve the collaboration efficiency between unmanned systems, and quickly combine to form a "multi-platform and multi-station" unmanned system, thereby enhancing the systematic mission execution capability of unmanned aerial vehicles.

[0094] (4) An open architecture application model for unmanned systems oriented towards generalized command and control is proposed, providing unmanned system architecture developers with the fastest software solution, allowing project developers and engineers to focus on the areas they know best, and ensuring that developers can deploy an effective generalized architecture solution for unmanned systems within a short development time.

Claims

1. An open architecture for unmanned systems oriented towards generalized command and control, characterized in that, include: At least one unmanned system, the unmanned system including at least one unmanned system instance, the unmanned system instance including at least one hardware component, and at least one application software running on some of the hardware components; The first unmanned system instance is used to send a first message, which carries first information, a sending address, and a receiving address. The first information is generated by the first application software. The sending address is generated by the first application software that generates the first information, the first hardware component that forwards the first information, the first unmanned system instance, and the unified encoding address of the first unmanned system. The receiving address includes the unified encoding address of the second unmanned system, the second unmanned system instance, the second hardware component, and the second application software. The second unmanned system instance is used to identify whether the message format of the first message is consistent with the message format adopted by the second unmanned system when the first message is received, using the data link message configuration file in the configuration file library; if they are inconsistent, the first message is converted by calling the data element dictionary to obtain the second message, and the second message is forwarded according to the receiving address in the first message; The second message uses the same message format as the second unmanned system; The second application software is used to execute the information carried in the second message when the second message is received; The sending address in the first message includes, in ascending order of bits, the first-level code of the first unmanned system to which the first application software belongs, the second-level code of the first unmanned system instance, the third-level code of the first hardware component, and the fourth-level code of the first application software. The receiving address, in ascending order of bits, includes the first-level code of the second unmanned system to which the second application software belongs, the second-level code of the second unmanned system instance, the third-level code of the second hardware component, and the fourth-level code of the second application software.

2. The open architecture for unmanned systems oriented towards generalized command and control as described in claim 1, characterized in that, The second unmanned system instance is specifically used to: determine the data elements included in the first message; determine the required conversion path for each data element in the data element dictionary according to the message format adopted by the first and second messages; generate conversion code according to the conversion path; and run the conversion code to convert the message format of the first message to obtain the second message.

3. The open architecture for unmanned systems oriented towards generalized command and control as described in claim 2, characterized in that, The conversion path includes at least: reference frame conversion, precision conversion, unit conversion, length conversion, and encoding method conversion.

4. The open architecture for unmanned systems oriented towards generalized command and control as described in claim 1, characterized in that, Both the first and second messages include a message header and a message body. The message header includes the sender and receiver's encoded addresses, the message code, and message attributes. The message body uses a variable-length font to carry the message content, and messages include command, query, and notification types.

5. The open architecture for unmanned systems oriented towards generalized command and control as described in claim 1, characterized in that, The first and second messages are sent using both point-to-point transmission and broadcasting methods.

6. The open architecture for unmanned systems oriented towards generalized command and control as described in claim 5, characterized in that, When a message set is transmitted via broadcast, the recipient address in the message header is a preset address.

7. The open architecture for unmanned systems oriented towards generalized command and control as described in claim 1, characterized in that, Unmanned systems include different types of drones, unmanned vehicles, unmanned ships, control stations, and unmanned underwater vehicles.

8. A general-purpose command and control method for an open architecture of an unmanned system as described in any one of claims 1 to 7, characterized in that, By defining globally unified coded identity identifiers, layered and decoupled message addressing methods and message formats, a message conversion mechanism based on a unified data element dictionary, and an information transmission mechanism where messages and transmissions are independent, the system moves from traditional platform-station bundled identifiers to independent definition and unified coded identifiers for all system hardware and software. Furthermore, by using a unified development toolkit to guide the development of unmanned systems, the system achieves full-element network information transmission, processing, and sharing, enabling universal command and control across multiple platforms and stations.

9. The command and control method according to claim 8, characterized in that, The unmanned system is designed with a general command and control system, which provides interoperability services for the messages and protocols used in message transmission. The service interfaces mainly include six categories: platform monitoring, action planning, information processing, information access, situation display, and comprehensive management.

10. The command and control method according to claim 9, characterized in that, Each service definition is identified in the form of an XML file containing text and service interfaces. Each service definition includes seven parts: service identifier, description, scope, external references, constant definition, type definition, and message definition.

11. The command and control method according to claim 10, characterized in that, For application software running on hardware components, each application software is configured with at least one of the above six types of service interfaces.

12. The command and control method according to claim 11, characterized in that, When the application software receives a message, it distributes and processes the message according to the service interface corresponding to the message content.

Images