Device management and control communication method and system of domestic operating system satellite in weak network environment

Abstract

This invention discloses a device management and communication method and system for a domestically developed operating system in a satellite weak network environment. The method includes: after a system cold start or reset, performing initialization operations, loading a pre-compiled object model by the cloud platform, and transmitting the object model data to the device; the device collects data and monitors temperature changes in real time; when the temperature change exceeds a preset threshold, the collected data is simplified and encoded based on the object model, and the encoded data is transmitted to the cloud platform; when the cloud platform needs to perform instruction scheduling, it transmits the instruction and a globally unique token to the device, which verifies the token and executes the instruction after successful verification; the device transmits the result of the instruction execution as a response data to the cloud platform, and the cloud platform parses the response data to obtain the instruction execution result. This invention can improve communication efficiency in a satellite weak network environment and enhance the reliability and controllability of device management and communication.

Description

Technical Field

[0001] This invention relates to the field of satellite equipment management and communication technology, specifically to a method and system for equipment management and communication in a weak satellite network environment using a domestically developed operating system. Background Technology

[0002] With the increasing application of IoT technology in national strategic and security fields such as emergency communications, ocean navigation, and border patrols, satellite internet has become an indispensable communication method. Satellite links constitute a typical ultra-narrowband weak network environment, characterized by extremely narrow bandwidth (as low as 2.4kbps), high latency, large jitter, and high cost. Under this environment, terminal devices based on domestically developed mobile operating systems (such as HarmonyOS and Kylin OS Mobile Edition) face severe challenges in device management and communication.

[0003] Existing management and control solutions based on general IoT protocols (such as standard MQTT over TCP / TLS) did not fully consider such extreme network conditions in their initial design. Their high protocol redundancy and cumbersome heartbeat and retransmission mechanisms easily lead to frequent connection interruptions, lost control commands, and exhaustion of system resources (power, computing power) in ultra-narrowband environments, severely restricting the informatization and intelligentization of equipment in related fields.

[0004] Currently, existing technologies for device management and communication of domestically developed mobile operating systems in weak satellite network environments have the following main drawbacks: Low communication efficiency: The widely used JSON over MQTT / HTTP solutions have extremely high redundancy in their text format and protocol headers. At a bandwidth of 2.4kbps, the effective data transmission rate is extremely low, with most of the bandwidth being occupied by protocol overhead.

[0005] Reliability mechanism performance bottleneck: The QoS 2 level in the standard MQTT protocol, which guarantees "exactly once" delivery, requires four network handshakes. In the high-latency environment of satellite links, the delay of a single command interaction can reach several seconds, which cannot meet the requirements of real-time management and control. While QoS 1 has lower latency, it cannot solve the problem of repeated command execution.

[0006] Insufficient adaptability to weak networks: General protocols lack intelligent compensation mechanisms for ultra-narrowband environments, such as dynamic aggregation and priority scheduling, and perform poorly when the network fluctuates, failing to guarantee the priority delivery of critical instructions within limited bandwidth.

[0007] Poor compatibility with domestic mobile operating systems: The general communication library fails to be deeply integrated with the underlying network stack and power management of domestic mobile operating systems, making it impossible to accurately perceive network status and coordinate the scheduling of system resources, which affects the terminal's battery life and communication stability. Summary of the Invention

[0008] The technical problem to be solved by this invention is to provide a device management and communication method and system for a domestically developed operating system in a weak satellite network environment, thereby improving communication efficiency and enhancing the reliability and controllability of device management and communication in a weak satellite network environment.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A device management and communication method for a domestically developed operating system in a weak satellite network environment. The method is applied to a device management and communication system, which includes a cloud platform, device terminals, and a communication network for communication between the cloud platform and the device terminals. The method includes the following steps: S1. After a system cold start or reset, an initialization operation is performed, in which the cloud platform loads the pre-compiled object model and transmits the object model data to the device. S2, the device collects data and monitors temperature changes in real time. When the temperature change exceeds the preset threshold, the collected data is simplified and encoded based on the object model, and the encoded data is transmitted to the cloud platform. S3: When the cloud platform needs to schedule instructions, it transmits the instructions and a globally unique token to the device. The device verifies the token and executes the instructions after the verification is successful. S4, the device transmits the result of the command execution as a response data to the cloud platform, and the cloud platform parses the response data and obtains the command execution result.

[0010] Furthermore, in step S1, during the initialization operation, the network environment is actively detected by calling the network awareness API provided by the domestic operating system. Upon detecting typical satellite network characteristics, the optimal underlying transmission protocol is automatically selected based on network quality. These typical satellite network characteristics include one or more of high latency, specific DNS, and manual configuration. Specifically, the automatic selection of the optimal underlying transmission protocol based on network quality includes: When network quality is acceptable, choose MQTT over TLS for bidirectional communication and the publish / subscribe model; When an MQTT connection fails due to a network firewall or extreme instability, choose HTTPS long polling. If the operating system supports it and the network jitter is extremely high, then QUIC's 0-RTT connection will be used.

[0011] Furthermore, in step S2, when performing simplified encoding based on the object model, the data is specifically serialized into a TLV message, wherein the TLV message includes one or more of the following: sequentially connected hexadecimal data tags, data length, and data value.

[0012] Furthermore, in step S3, when the cloud platform needs to perform instruction scheduling, transmitting the instruction and a globally unique token to the device specifically includes: The cloud platform generates a globally unique idempotent token, token_1, in the format {Device ID}{Timestamp}{Random Number}. The instructions are serialized into TLV messages based on the physical model; Publish MQTT messages at QoS 1 level and place the idempotent token token_1 in the UserProperty field of the MQTT protocol.

[0013] Furthermore, in step S3, the token verification performed by the device specifically includes: After receiving the instruction, the device checks whether the idempotent token_1 exists in the local database. If the token does not exist, the device persists the idempotent token_1 to the local database and executes the instruction. If the token already exists, it indicates that the instruction is a duplicate instruction caused by network retransmission. The device then directly returns a success response message to the cloud platform and skips the execution of the instruction.

[0014] Furthermore, the method also includes weak network compensation scheduling, specifically including: real-time monitoring of the packet loss rate of the current satellite link during data transmission; when the packet loss rate is higher than a preset threshold, temporarily storing the data that needs to be transmitted within a preset time period in a buffer; and aggregating two or more independent data into a single data packet for unified transmission to reduce transmission overhead.

[0015] Furthermore, the communication protocols of the communication network include MQTT, HTTPS, and QUIC. The device-side protocol adapter is configured according to the currently used communication protocol to achieve multi-protocol adaptation of the data to be transmitted. Specifically, this includes: When the communication protocol uses HTTPS, the TLV payload corresponding to the data to be transmitted is directly used as the HTTP request body. The TLV payload format and the idempotent token are declared in the HTTP header to achieve HTTPS protocol adaptation. When the communication protocol uses MQTT, the TLV payload corresponding to the data to be transmitted is directly used as the application message body of the MQTT message, and the TLV payload format and the carrying idempotent token are declared in the attributes of the MQTT message to achieve MQTT protocol adaptation. When the communication protocol uses QUIC, the TLV payload corresponding to the data to be transmitted is directly used as the data sent in the QUIC Stream. The TLV payload format and the idempotent token are declared in the header of the Stream to achieve QUIC protocol adaptation.

[0016] A device management and communication system for a domestically developed operating system in a weak satellite network environment includes a cloud platform, a communication network, and device terminals; The cloud platform is used for unified modeling, command scheduling, status management, communication access, and function output of devices; The communication network is used to provide a cross-network data transmission channel between the cloud platform and the device. The device is used to complete device data acquisition, instruction execution, and communication adaptation under a domestic operating system environment; The cloud platform and the device communicate bidirectionally through the communication network to achieve reliable management and control of the device in a weak satellite network environment.

[0017] Furthermore, the cloud platform includes an object model management module, an instruction scheduling engine module, a device status management module, and a communication gateway service module; The object model management module is used to define the object model structure of the device, maintain the mapping relationship between the device identifier and the model field, perform version control of the object model, and send the object model configuration corresponding to the device to the device end; The instruction scheduling engine module is used to manage device control instructions in a queue, generate unique instruction identifiers for control instructions, perform timeout checks on control instructions, and schedule control instructions according to instruction priority. The device status management module is used to maintain the online status information of the device, record the historical operating status of the device, synchronize the device status between the cloud platform and the device, and generate device shadow data corresponding to the device. The communication gateway service module is used to provide message middleware services, adapt to multiple communication protocols, perform load balancing of communication links, and perform security authentication for device access. The cloud platform also includes a function output module, which is used to uniformly encapsulate the processing results of the object model management module, instruction scheduling engine module, device status management module and communication gateway service module, and output control instructions, device status and device lifecycle information to the outside world with a unified data contract and bidirectional communication semantics.

[0018] Furthermore, the device side includes: a device management and communication engine SDK and a device business application module; The device management and communication engine SDK includes a physical model encoding module, a weak network compensation and scheduling module, a reliability assurance module, and a protocol adapter module. The object model encoding module is used to serialize and encode device data, synchronize device data using a differential method, and compress the data to be transmitted. The weak network compensation and scheduling module is used to dynamically aggregate the data to be sent, schedule the data according to the service priority, and perform predictive retransmission based on the link status. The reliability assurance module is used to verify the uniqueness of instructions, deduplicate duplicate instructions, and persistently store device status. The protocol adapter module is used to select the corresponding communication protocol for data transmission according to the communication network conditions, including one or more of the following: MQTT client, HTTP client, and QUIC client; The device business application module is used to collect device operation data and execute control commands from the cloud platform.

[0019] Compared with the prior art, the advantages of the present invention are as follows: This invention unifies device data structure and communication semantics by sending a pre-compiled object model from the cloud platform to the device during system initialization, reducing runtime parsing overhead on the device and improving system startup efficiency. During device operation, a data reporting mechanism triggered by a temperature change threshold simplifies and transmits collected data only when critical state changes occur, effectively reducing data transmission volume and significantly improving communication efficiency and stability in weak satellite network environments. By introducing a globally unique token for scheduling commands and verifying it on the device, the uniqueness and reliability of command execution are ensured, avoiding the risks of repeated execution. The cloud platform parses the response data returned by the device and obtains the command execution results, enabling closed-loop control of device status from the cloud, improving the reliability and controllability of device management communication, and is suitable for satellite weak network application scenarios under domestic operating systems. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a device management and communication method for a domestically developed operating system in a weak satellite network environment, as described in an embodiment of the present invention.

[0021] Figure 2 This is a flowchart illustrating a device management and communication method for a domestically developed operating system in a weak satellite network environment, as shown in a specific application example.

[0022] Figure 3 This is a comparison chart of TLV and JSON formats in a specific application example.

[0023] Figure 4 This is a flowchart illustrating the instruction issuance process (from device to cloud platform) after adding weak network compensation scheduling in a specific application embodiment.

[0024] Figure 5 This is a comparison diagram of the "QoS 1 + application layer idempotency" mechanism and the standard QoS 2 mechanism in a specific application embodiment.

[0025] Figure 6 This is a schematic diagram of the framework structure of a device management and communication system for a domestically developed operating system in a weak satellite network environment, as shown in a specific application embodiment. Detailed Implementation

[0026] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0027] Example 1 like Figure 1 As shown in this embodiment, the device management and communication method for a domestically developed operating system in a weak satellite network environment is applied to a device management and communication system. The system includes a cloud platform, a device, and a communication network for enabling communication between the cloud platform and the device. The method includes the following steps: S1. After a system cold start or reset, an initialization operation is performed, in which the cloud platform loads the pre-compiled object model and transmits the object model data to the device. S2, the device collects data and monitors temperature changes in real time. When the temperature change exceeds the preset threshold, the collected data is simplified and encoded based on the object model, and the encoded data is transmitted to the cloud platform. S3: When the cloud platform needs to schedule instructions, it transmits the instructions and a globally unique token to the device. The device verifies the token and executes the instructions after the verification is successful. S4, the device transmits the result of the command execution as a response data to the cloud platform, and the cloud platform parses the response data and obtains the command execution result.

[0028] In specific application embodiments, after a device cold start or reset, system initialization and adaptive protocol selection are performed. First, a pre-compiled object model description file is loaded from the secure storage area. This file is stored in binary format and defines all capability units of the device, for example: Tag=0x01: Attribute, Name="Temperature", Data Type=uint8 (range 0-100), Permission=Read-only, Reporting Policy=Change Reporting (threshold=5). Tag=0x02: Service, Name="Device Restart", Parameters=None, Permissions=Write Only.

[0029] In this embodiment, during the initialization operation in step S1, the network environment is actively detected by calling the network awareness API provided by the domestic operating system. When typical satellite network characteristics are detected, the optimal underlying transmission protocol is automatically selected based on network quality. Typical satellite network characteristics include one or more of high latency, specific DNS, and manual configuration. The decision logic for automatically selecting the optimal underlying transmission protocol based on network quality specifically includes: When network quality is acceptable, use MQTT over TLS for bidirectional communication and a publish / subscribe model; When an MQTT connection fails due to a network firewall or extreme instability, choose HTTPS long polling. If the operating system supports it and network jitter is extremely high, then an aggressive mode is adopted, taking advantage of QUIC's 0-RTT connection.

[0030] In this embodiment, during step S2, when performing simplified encoding based on the object model, the data is specifically serialized into a TLV message. The TLV message includes one or more of the following: sequentially connected hexadecimal data tags, data length, and data value.

[0031] In specific application embodiments, such as Figure 2 As shown, the specific steps for efficient data transmission (from device to cloud platform) are as follows: Data Acquisition and Triggering: The device detects that the temperature changes from 17 to 25, and the change amount exceeds the "change reporting" threshold (e.g., 5) defined in the object model, triggering the reporting process; TLV serialization: The object model encoding module serializes the data into a TLV message structure according to the mapping relationship. TAG=0x01 (Battery level) LENGTH = 0x01 (1 byte) VALUE = 0x19 (hexadecimal 25) The final message is [0x01][0x01][0x19], only 3 bytes. Compared to the functionally equivalent JSON format {"temperature": 25} (approximately 20 bytes), the data size is reduced by about 80%. For example, the message size is reduced by approximately 80%. Figure 3 As shown in the diagram, this embodiment uses a physical model as a unified data contract, directly mapping device capabilities to binary tags, and employing TLV format for unified encoding of uplink data and downlink commands. It can be understood that through innovative data encoding and compression technologies, the interactive data (attributes, services) managed by the device is defined as a simplified binary TLV format based on the physical model, replacing text formats such as JSON. Furthermore, it supports differential synchronization at the protocol level, significantly reducing the data volume of a single communication, enabling stable operation in bandwidth environments of 2.4kbps and below, achieving ultimate communication efficiency.

[0032] In this embodiment, step S3, when the cloud platform needs to perform instruction scheduling, specifically includes transmitting the instruction and a globally unique token to the device: The cloud platform generates a globally unique idempotent token, token_1, in the format {Device ID}{Timestamp}{Random Number}. The instructions are serialized into TLV messages based on the physical model; Publish MQTT messages at QoS 1 level and place the idempotent token token_1 in the UserProperty field of the MQTT protocol.

[0033] In this embodiment, step S3, where the token verification is performed by the device, specifically includes: After receiving the instruction, the device checks whether the idempotent token_1 exists in the local database. If the token does not exist, the device persists the idempotent token_1 to the local database and executes the instruction. If the token already exists, it indicates that the instruction is a duplicate instruction caused by network retransmission. The device then directly returns a success response message to the cloud platform and skips the execution of the instruction.

[0034] In a specific application embodiment, the reliable interaction process for command delivery (from the cloud platform to the device) is as follows: Figure 4 As shown, its end-to-end data stream is as follows Figure 2 As shown, the specific steps are as follows (taking device restart as an example): Platform-side command generation: When maintenance personnel trigger a "device restart" command on the platform, the platform command scheduling engine performs the following operations: Generate a globally unique idempotent token token_1, in the format {device ID}{timestamp}{random number}; Based on the object model, the instruction is serialized into a TLV message: [0x02][0x00] (2 bytes), where Tag=0x02 represents restarting the service and Length=0x00 indicates no additional parameters; Publish MQTT messages at QoS level 1 and place the idempotent token token_1 in the UserProperty field of the MQTT protocol; Reliable execution on the device side: After receiving the instruction, the device-side reliability assurance module performs the following steps: Token verification: Check if token_1 exists in a local lightweight database (such as SQLite); New instruction processing: If the token does not exist, perform the following atomic operations: persist token_1 to the database and execute the hardware restart process; Duplicate command handling: If the token already exists, it indicates that this is a duplicate command caused by network retransmission. The module directly replies to the platform with a success response message [0xC0][0x07][0x00][token_1], and skips the actual restart operation.

[0035] like Figure 5The diagram shows a comparison between the standard QoS 2 mechanism and the "QoS 1 + application layer idempotency" mechanism of this embodiment. It can be understood that the mechanism of this embodiment ensures that instructions are executed "exactly once" at the service layer, avoiding the high latency caused by the four-way handshake in the standard MQTT QoS 2 mechanism. The low-overhead, highly reliable service instruction transmission mechanism of this embodiment can significantly reduce transmission latency while avoiding duplicate instruction execution.

[0036] In this embodiment, the method also includes weak network compensation scheduling, specifically including: real-time monitoring of the packet loss rate of the current satellite link during data transmission; when the packet loss rate is higher than a preset threshold, temporarily storing the data that needs to be transmitted within a preset time period in a buffer; and aggregating two or more independent data into a single data packet for unified transmission to reduce transmission overhead.

[0037] Specifically, the weak network compensation scheduling module can monitor the current satellite link packet loss rate in real time. If the packet loss rate reaches 20%, to avoid the failure of individual small message transmissions, the module temporarily stores this temperature reporting TLV message in the sending buffer. Within a 100ms time window, the subsequently generated "GPS location" message (Tag=0x03) is successfully aggregated. Finally, the two independent TLV messages are aggregated into a single data packet for unified transmission, reducing the handshake overhead from two times to one, significantly improving transmission efficiency under poor network conditions. It can be understood that weak network compensation (message aggregation, priority scheduling) enables the communication system to perceive network changes and dynamically adjust communication strategies to maintain connection stability and the timeliness of critical commands.

[0038] In this embodiment, the communication protocols of the communication network include MQTT, HTTPS, and QUIC. The device-side protocol adapter is configured according to the currently used communication protocol to achieve multi-protocol adaptation of the data to be transmitted. Specifically, this includes: When the communication protocol uses HTTPS, the TLV payload corresponding to the data to be transmitted is directly used as the HTTP request body. The TLV payload format and the idempotent token are declared in the HTTP header to achieve HTTPS protocol adaptation. When the communication protocol is MQTT, the TLV payload corresponding to the data to be transmitted is directly used as the payload (application message body) of the MQTT message, and the TLV payload format (e.g., through content-type or custom attributes) and the idempotency token (e.g., using the idempotency-key attribute) are declared in the attributes of the MQTT message (such as the User Properties of MQTT 5.0) to achieve MQTT protocol adaptation. When the communication protocol uses QUIC, the TLV payload corresponding to the data to be transmitted is directly sent as data in the QUIC Stream. The TLV payload format and the carrying idempotent token are declared in the header of the Stream (for example, by defining a fixed-length metadata field in the application layer protocol, or by using the QUIC application error handling mechanism in the first frame of the Stream), thus achieving QUIC protocol adaptation.

[0039] In specific application embodiments, one of the core advantages of this invention lies in its protocol independence. For example, if the on-site network policy requires the use of the HTTPS protocol, no modification to any business logic code is needed; only configuration at the protocol adaptation layer is required. The TLV payload [0x02][0x00] of the above restart command can be directly used as the HTTP Request Body; Set in the HTTP Header: Content-Type: application / delta-tlv (declaration payload format) Idempotency-Key: token_1 (carrying the idempotency token); The communication system automatically handles details such as connection management and request retries with the HTTPS server, remaining completely transparent to the upper-layer object model encoding module and reliability guarantee module, achieving the same business results. TLV serialization and weak network compensation algorithms can be encapsulated as service modules independent of the underlying communication protocol (MQTT / HTTPS / QUIC), achieving seamless integration by adapting the header fields of different protocols.

[0040] Example 2 like Figure 6 As shown, the device management and communication system for a domestically developed operating system in a weak satellite network environment in this embodiment includes a cloud platform, a communication network, and a device terminal; The cloud platform is used for unified modeling of devices, command scheduling, status management, communication access, and function output; Communication networks are used to provide cross-network data transmission channels between cloud platforms and device terminals; The device side is used to complete device data acquisition, command execution, and communication adaptation under a domestic operating system environment; The cloud platform and the device communicate bidirectionally through a communication network to achieve reliable management and control of the device in a weak satellite network environment.

[0041] In this embodiment, the cloud platform includes a physical model management module, an instruction scheduling engine module, a device status management module, and a communication gateway service module; The object model management module is used to define the object model structure of the device, maintain the mapping relationship between the device identifier and the model field, perform version control of the object model, and send the object model configuration corresponding to the device to the device. The instruction scheduling engine module is used to manage device control instructions in a queue, generate unique instruction identifiers for control instructions, perform timeout checks on control instructions, and schedule control instructions according to instruction priority. The device status management module is used to maintain the online status information of the device, record the historical operating status of the device, synchronize the device status between the cloud platform and the device, and generate device shadow data corresponding to the device. The communication gateway service module is used to provide message middleware services, adapt to multiple communication protocols, perform load balancing of communication links, and perform security authentication for device access. The cloud platform also includes a function output module, which is used to uniformly encapsulate the processing results of the object model management module, instruction scheduling engine module, device status management module and communication gateway service module, and output control instructions, device status and device lifecycle information to the outside world with a unified data contract and bidirectional communication semantics.

[0042] In this embodiment, the device side includes: a device management and communication engine SDK and a device business application module; The device management and communication engine SDK includes a physical model encoding module, a weak network compensation and scheduling module, a reliability assurance module, and a protocol adapter module. The object model encoding module is used to serialize and encode device data, synchronize device data using a differential method, and compress the data to be transmitted. The weak network compensation and scheduling module is used to dynamically aggregate the data to be sent, schedule the data according to the service priority, and perform predictive retransmission based on the link status. The reliability assurance module is used to verify the uniqueness of instructions, deduplicate duplicate instructions, and persistently store device status. The protocol adapter module is used to select the appropriate communication protocol for data transmission based on the communication network conditions, including one or more of the following: MQTT client, HTTP client, and QUIC client; The equipment business application module is used to collect equipment operation data and execute control commands from the cloud platform.

[0043] The system in this embodiment integrates communication capabilities as a system service, improving overall energy efficiency and performance. By encapsulating the data layer (TLV format and differential synchronization) and algorithm layer (weak network compensation) into the native communication engine of a domestic mobile operating system, it achieves collaborative optimization with the underlying system and deep adaptation to the domestic mobile operating system. For instructions requiring reliable delivery, it combines "at least once" delivery at the transport layer with idempotency verification at the service layer to achieve "exact once" semantics at the business layer and significantly reduce transmission latency. Furthermore, it can deeply collaborate with the operating system's network stack and power management module to achieve network awareness and resource scheduling optimization.

[0044] Compared with the prior art, the present invention has the following beneficial effects: Communication efficiency is significantly improved: By using object model-driven TLV encoding and differential synchronization, the data volume of typical device control commands is reduced by more than 75%, enabling it to operate stably and efficiently on the 2.4kbps satellite link; differential updates are used, and updated data is only reported when needed. Communication reliability is guaranteed with low overhead: Through the "QoS 1 + application layer idempotency" mechanism, the end-to-end transmission latency of critical instructions is reduced by more than 60% compared with the standard QoS 2, while ensuring that the business semantics of the instruction are executed "exactly once". Reduced system resource consumption: Efficient coding and intelligent weak network compensation algorithms reduce network activity frequency and data volume. Combined with deep integration with domestic mobile operating systems, it significantly reduces system (CPU, memory) and power consumption during communication. Highly flexible and compatible: The protocol-independent design enables this system to quickly adapt to various communication protocols and cloud platforms, greatly improving the applicability and ease of implementation of the technical solution.

[0045] The present invention can implement all or part of the processes in the methods of the above embodiments, or it can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. Computer-readable media include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0046] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A device control and communication method for a domestically developed operating system in a weak satellite network environment, characterized in that, The method is applied to a device management and communication system, which includes a cloud platform, a device terminal, and a communication network for enabling communication between the cloud platform and the device terminal. The method includes the following steps: S1. After a system cold start or reset, an initialization operation is performed, in which the cloud platform loads the pre-compiled object model and transmits the object model data to the device. S2, the device collects data and monitors temperature changes in real time. When the temperature change exceeds the preset threshold, the collected data is simplified and encoded based on the object model, and the encoded data is transmitted to the cloud platform. S3: When the cloud platform needs to schedule instructions, it transmits the instructions and a globally unique token to the device. The device verifies the token and executes the instructions after the verification is successful. S4, the device transmits the result of the command execution as a response data to the cloud platform, and the cloud platform parses the response data and obtains the command execution result.

2. The device control and communication method for a domestically developed operating system in a weak satellite network environment according to claim 1, characterized in that, In step S1, during the initialization operation, the network environment is actively detected by calling the network awareness API provided by the domestic operating system. When typical satellite network characteristics are detected, the optimal underlying transmission protocol is automatically selected based on network quality. The typical satellite network characteristics include one or more of high latency, specific DNS, and manual configuration. The automatic selection of the optimal underlying transmission protocol based on network quality specifically includes: When network quality is acceptable, choose MQTT over TLS for bidirectional communication and the publish / subscribe model; When an MQTT connection fails due to a network firewall or extreme instability, choose HTTPS long polling. If the operating system supports it and the network jitter is extremely high, then QUIC's 0-RTT connection will be used.

3. The device control and communication method for a domestically developed operating system in a weak satellite network environment according to claim 1, characterized in that, In step S2, when performing simplified encoding based on the object model, the data is specifically serialized into a TLV message. The TLV message includes one or more of the following: sequentially connected hexadecimal data tags, data length, and data value.

4. The device control and communication method for a domestically developed operating system in a weak satellite network environment according to claim 1, characterized in that, In step S3, when the cloud platform needs to perform instruction scheduling, transmitting the instruction and a globally unique token to the device specifically includes: The cloud platform generates a globally unique idempotent token, token_1, in the format {Device ID}{Timestamp}{Random Number}. The instructions are serialized into TLV messages based on the physical model; Publish MQTT messages at QoS 1 level and place the idempotent token token_1 in the User Property field of the MQTT protocol.

5. The device control and communication method for a domestically developed operating system in a weak satellite network environment according to claim 1, characterized in that, In step S3, the token verification performed by the device specifically includes: After receiving the instruction, the device checks whether the idempotent token_1 exists in the local database. If the token does not exist, the device persists the idempotent token_1 to the local database and executes the instruction. If the token already exists, it indicates that the instruction is a duplicate instruction caused by network retransmission. The device then directly returns a success response message to the cloud platform and skips the execution of the instruction.

6. The device control and communication method for a domestically developed operating system in a weak satellite network environment according to any one of claims 1-5, characterized in that, The method also includes weak network compensation scheduling, specifically including: real-time monitoring of the packet loss rate of the current satellite link during data transmission; when the packet loss rate is higher than a preset threshold, temporarily storing the data that needs to be transmitted within a preset time period in a buffer; and aggregating two or more independent data into a single data packet for unified transmission to reduce transmission overhead.

7. The device control and communication method for a domestically developed operating system in a weak satellite network environment according to any one of claims 1-5, characterized in that, The communication protocols of the communication network include MQTT, HTTPS, and QUIC. The protocol adapter on the device is configured according to the currently used communication protocol to achieve multi-protocol adaptation of the data to be transmitted. Specifically, this includes: When the communication protocol uses HTTPS, the TLV payload corresponding to the data to be transmitted is directly used as the HTTP request body. The TLV payload format and the idempotent token are declared in the HTTP header to achieve HTTPS protocol adaptation. When the communication protocol uses MQTT, the TLV payload corresponding to the data to be transmitted is directly used as the application message body of the MQTT message, and the TLV payload format and the carrying idempotent token are declared in the attributes of the MQTT message to achieve MQTT protocol adaptation. When the communication protocol uses QUIC, the TLV payload corresponding to the data to be transmitted is directly used as the data sent in the QUIC Stream. The TLV payload format and the idempotent token are declared in the header of the Stream to achieve QUIC protocol adaptation.

8. A device control and communication system for a domestically developed operating system in a weak satellite network environment, characterized in that, This includes cloud platforms, communication networks, and device terminals; The cloud platform is used for unified modeling, command scheduling, status management, communication access, and function output of devices; The communication network is used to provide a cross-network data transmission channel between the cloud platform and the device. The device is used to complete device data acquisition, instruction execution, and communication adaptation under a domestic operating system environment; The cloud platform and the device communicate bidirectionally through the communication network to achieve reliable management and control of the device in a weak satellite network environment.

9. The device control and communication system for a domestically developed operating system in a weak satellite network environment according to claim 8, characterized in that, The cloud platform includes a physical model management module, an instruction scheduling engine module, a device status management module, and a communication gateway service module. The object model management module is used to define the object model structure of the device, maintain the mapping relationship between the device identifier and the model field, perform version control of the object model, and send the object model configuration corresponding to the device to the device end; The instruction scheduling engine module is used to manage device control instructions in a queue, generate unique instruction identifiers for control instructions, perform timeout checks on control instructions, and schedule control instructions according to instruction priority. The device status management module is used to maintain the online status information of the device, record the historical operating status of the device, synchronize the device status between the cloud platform and the device, and generate device shadow data corresponding to the device. The communication gateway service module is used to provide message middleware services, adapt to multiple communication protocols, perform load balancing of communication links, and perform security authentication for device access. The cloud platform also includes a function output module, which is used to uniformly encapsulate the processing results of the object model management module, instruction scheduling engine module, device status management module and communication gateway service module, and output control instructions, device status and device lifecycle information to the outside world with a unified data contract and bidirectional communication semantics.

10. The device control and communication system for a domestically developed operating system in a weak satellite network environment according to claim 8, characterized in that, The device side includes: a device management and communication engine SDK and a device business application module; The device management and communication engine SDK includes a physical model encoding module, a weak network compensation and scheduling module, a reliability assurance module, and a protocol adapter module. The object model encoding module is used to serialize and encode device data, synchronize device data using a differential method, and compress the data to be transmitted. The weak network compensation and scheduling module is used to dynamically aggregate the data to be sent, schedule the data according to the service priority, and perform predictive retransmission based on the link status. The reliability assurance module is used to verify the uniqueness of instructions, deduplicate duplicate instructions, and persistently store device status. The protocol adapter module is used to select the corresponding communication protocol for data transmission according to the communication network conditions, including one or more of the following: MQTT client, HTTP client, and QUIC client; The device business application module is used to collect device operation data and execute control commands from the cloud platform.

Images