Satellite multi-type hardware device service encapsulation and container deployment method

Abstract

The application discloses a satellite multi-type hardware device service encapsulation and container deployment method, comprising the following steps: constructing a JSON format unified configuration file, standardizing core information such as hardware serial port parameters and data analysis rules; adopting a double buffer area architecture to cache original data and structured data after analysis, and guaranteeing the safety of multi-thread access through a thread mutex; then encapsulating three types of standardized remote procedure call interfaces through a micro-service communication framework, realizing original data acquisition, analysis / average data output and device instruction control functions; and packaging hardware service code, dependent libraries and configuration files into a lightweight container image, and deploying the image on a satellite hardware board card to realize independent service running and resource isolation. The application solves the problems of traditional satellite hardware access adaptation difficulty and high maintenance cost, improves equipment access efficiency, data reliability and deployment flexibility, and provides an efficient solution for software and hardware loose coupling of an intelligent spacecraft integrated electronic system.

Description

Technical Field

[0001] This invention relates to the field of integrated electronic technology for intelligent spacecraft, specifically to a method for service-oriented packaging and container deployment of multiple types of satellite hardware devices. Background Technology

[0002] As intelligent spacecraft rapidly develop towards generalization, modularization, and intelligence, the types and quantities of onboard hardware are increasing daily. Diverse hardware devices such as star sensors, gyroscopes, micromechanical inertial navigation systems (MEMS), and flywheels have become core components of satellite attitude measurement and control systems. The effective management and data access of these hardware devices directly affect the execution efficiency and operational stability of satellite missions.

[0003] However, traditional satellite hardware and software development models often employ tightly coupled designs, leading to the following technical problems:

[0004] (1) Inconsistent interfaces and high difficulty in adaptation: The communication interfaces, data formats and control instructions of different hardware devices are significantly different. Upper-layer applications need to develop adaptation layer code separately for each type of hardware, resulting in a large workload and low code reuse rate.

[0005] (2) Dispersed configuration management and high maintenance costs: Hardware configuration information such as serial port parameters, polling intervals, and data parsing rules are scattered throughout the code. When the hardware is replaced or the parameters are adjusted, multiple parts of the code need to be modified and recompiled and deployed, which is difficult to adapt to the rapid iteration of research and development needs.

[0006] (3) Weak data processing mechanism and insufficient reliability: The existing scheme lacks effective cache management and data verification mechanism. Multi-threaded concurrent access is prone to data competition, high data transmission latency and large packet loss rate, which makes it difficult to meet the real-time requirements of satellite missions.

[0007] (4) Lack of abnormal handling mechanism and difficulty in fault diagnosis: There is a lack of effective detection and recovery mechanism for abnormal situations such as hardware communication timeout and data verification failure. Error information cannot be fed back in time, which makes fault location difficult and affects system availability.

[0008] (5) The deployment method is crude and the resource isolation is poor: multiple types of hardware services are directly deployed in the same system, which can easily lead to resource conflicts and dependency conflicts. Once a hardware service fails, it may spread to the entire satellite integrated electronic system, affecting the stability of mission execution. Service upgrades and maintenance require downtime operations, which reduces the availability of the system.

[0009] Domestically developed real-time operating systems (RTOS) for the aerospace field possess advantages such as high reliability, strong real-time performance, and customizability, and are increasingly widely used in satellite integrated electronic systems. However, there is currently a lack of hardware service-oriented encapsulation specifications for domestically developed ROS in the aerospace field. Existing service-oriented solutions fail to fully leverage their real-time scheduling and resource management capabilities, making it difficult to meet the development needs of loosely coupled software and hardware in intelligent spacecraft. Summary of the Invention

[0010] The purpose of this invention is to provide a service-oriented encapsulation and container deployment method for various types of satellite hardware devices. Through the integrated design of standardized configuration, service-oriented encapsulation, reliable data processing and containerized deployment, it enables flexible access and efficient management of satellite hardware devices, and solves technical problems such as inconsistent interfaces for various types of satellite hardware, tight coupling of software and hardware, and complex deployment and maintenance.

[0011] The technical solution to achieve the objective of this invention is: a method for service-oriented encapsulation and container deployment of multi-type satellite hardware devices, comprising the following steps:

[0012] 1) Define a JSON configuration file specification, which includes parameters such as the serial port path of the hardware device, baud rate, data bits, stop bits, parity bits, polling interval, application request interval, and maximum number of cache groups.

[0013] 2) Initialize the hardware serial port based on the configuration file parameters, configure the serial port's verification method, data bit length, number of stop bits, and set the serial port read / write timeout rules;

[0014] 3) Construct a dual-buffer architecture. The first buffer caches the raw data frames from the hardware device, and the second buffer caches the parsed structured data. The buffer capacity is dynamically calculated and expanded according to the application request interval and polling interval. Cache operations are thread-safe through mutex locks.

[0015] 4) Based on the microservice communication framework, three types of standardized remote procedure call interfaces are encapsulated: raw data acquisition interface, parsed / average data acquisition interface, and device command control interface.

[0016] 5) Construct a hardware data processing thread, send data acquisition instructions to the hardware according to the configured polling interval, and perform frame header verification, checksum verification, and length verification after receiving the data frame returned by the hardware. If the verification passes, complete the raw data caching and structured parsing. If the verification fails, count the error type and the number of times.

[0017] 6) Package the encapsulated hardware service code, dependency libraries, and configuration files into a lightweight container image and deploy it on the satellite hardware board.

[0018] Furthermore, the JSON configuration file specification in step 1) supports default parameter fallback. When the configuration file is missing or parameters are not configured, preset default values ​​are automatically used, including the default serial port path, default baud rate, default data bits, default stop bits, and default parity bits. During the configuration file reading process, file length verification and JSON format verification mechanisms are used to avoid initialization failures caused by corrupted configuration files.

[0019] Furthermore, step 2) requires defining the serial port initialization process, which specifically includes the following steps:

[0020] 21) Open the serial port device file, set it to read / write mode, and ensure that the serial port is in non-control terminal mode;

[0021] 22) Set the baud rate via the ioctl interface;

[0022] 23) By obtaining and setting the serial port terminal configuration, configure the serial port frame format, including parity bit, data bits, and stop bits;

[0023] 24) Set the serial port to raw input mode and configure the read / write timeout.

[0024] 25) Clear the serial port buffer, output an error log and support a retry mechanism when initialization fails.

[0025] Furthermore, step 3) requires defining the dynamic expansion rules for the dual buffers, specifically including the following steps:

[0026] 31) The formula for calculating cache capacity is: Cache capacity = ceil(application request interval ms / polling interval ms), and the calculation result is not less than 1;

[0027] 32) If the maximum number of cache groups is defined in the configuration file and is greater than 0, then the smaller value between the calculated value and the maximum number of groups is taken as the final cache capacity;

[0028] 33) Cache writes use a circular queue to maintain write index pointers, which are incremented cyclically after each data write;

[0029] 34) Use a thread mutex lock to lock cache read and write operations. The data processing thread acquires the write lock when writing data to the cache, and the remote procedure call service thread acquires the read lock when reading cache data.

[0030] 35) When the application request interval or polling interval parameter is dynamically adjusted, the cache capacity is recalculated and new memory space is requested. While holding the mutex lock, the original cache area is atomically replaced and the old cache area memory is released.

[0031] Furthermore, step 4) requires defining three types of standardized service communication interfaces, specifically including:

[0032] The raw data acquisition interface returns the binary data of the raw hardware data frame;

[0033] The parsing / mean data retrieval interface returns the mean of the parsed structured data or cached data based on the request parameters, where request parameter 0 represents real-time data and 1 represents mean data;

[0034] The device command control interface uses a two-byte protocol [mode, value]. mode=0 is for power switch control, value=0x11 is on, and value=0x00 is off. mode=1 is for reset enable control, value=0x11 is enabled, and value=0x00 is disabled. The interface returns the command execution result.

[0035] The aforementioned device instruction control interface is compatible with single-byte protocols. When receiving single-byte data, the byte is processed as the value of a reset enable control instruction, thus achieving backward compatibility.

[0036] Furthermore, step 4) of the microservice communication framework's server-side deployment process includes: creating a server instance and configuring the service name; registering three types of service communication interfaces to the server instance; binding the network port and starting the service; and handling client requests through a synchronous multiplex I / O wait mechanism to achieve networked access to hardware services.

[0037] Furthermore, step 5) requires defining data frame verification rules and error statistics mechanisms, specifically including: frame header verification, verifying whether the first byte of the data frame is a preset value; length verification, verifying whether the actual number of received bytes is equal to the hardware data frame length; checksum verification, calculating the sum of all bytes except the last byte and comparing it with the checksum of the last byte; error statistics include the number of frame header errors, checksum errors, length errors, and serial port resets, and support exposing error statistics information to the outside world through the service communication interface.

[0038] Furthermore, the hardware data processing thread in step 5) also includes an exception handling mechanism, specifically including: when the number of instruction sending timeouts reaches a threshold, if reset is enabled, the serial port is automatically reinitialized and the number of resets is counted; if reset is disabled, only a warning log is output. The timeout threshold is n times. When an instruction is sent n times consecutively without receiving a complete response, exception handling is triggered. When the hardware device is detected to be in a power-off state, the sending of data acquisition instructions to the hardware is stopped to avoid invalid communication and resource waste.

[0039] Furthermore, in step 6), containerized deployment includes: packaging hardware service code, dependency libraries, and configuration files into a container image. The container image adopts a lightweight design, with the image size controlled within 12MB. The container is started on the hardware board through the container runtime, and the serial port device file and configuration file directory are mounted to achieve resource isolation between the hardware service and the host system. The container image supports parameterized configuration and can be adapted to at least one satellite hardware device among micromechanical inertial navigation systems (MEMS), star sensors, flywheels, and gyroscopes by mounting different configuration files.

[0040] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0041] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the above-described method.

[0042] This invention, based on the core design principles of configuration standardization, service-oriented encapsulation, and containerized deployment, proposes a hardware device management method adapted to satellite scenarios. This method better guides the development and maintenance of integrated electronic systems for intelligent spacecraft, with the following specific advantages:

[0043] (1) Based on the characteristics of aerospace hardware access, the hardware configuration, interface encapsulation and deployment process are standardized during the development stage to realize the modular development of hardware services. During runtime, incremental access of hardware devices is supported in a pluggable manner. The development process is more flexible and conducive to the reuse of software components.

[0044] (2) During the data processing stage, data reliability is ensured by a dual-buffer architecture and a triple data verification mechanism, data first-in-first-out and efficient use of cache space are ensured by a circular queue cache design, and multi-threaded concurrent access is ensured by a mutex lock mechanism.

[0045] (3) During the deployment and maintenance phase, containerized deployment enables independent operation and resource isolation of hardware services, supports on-demand deployment and online upgrades of services, and eliminates the need for downtime operations, thereby improving the stability and maintainability of the satellite system. Attached Figure Description

[0046] Figure 1 The overall process flowchart shows the entire process of configuration file reading, serial port initialization, dual buffer management, service communication interface encapsulation, data processing thread, and container deployment.

[0047] Figure 2 This is a diagram of a dual-buffer data management architecture, showing the structure of the raw data buffer and the parsed data buffer, the circular queue writing logic, and the mutex lock protection mechanism.

[0048] Figure 3 A schematic diagram of the encapsulation logic for service communication interfaces is provided, illustrating the input parameters, processing logic, and output data formats of three types of standardized interfaces.

[0049] Figure 4 This is a schematic diagram of a containerized deployment architecture, showing the composition of container images, the interaction between container runtime and the host system, and the mounting methods of hardware devices.

[0050] Figure 5 This is a workflow diagram for the data processing thread, showing the complete process of data sending, receiving, triple verification, error statistics, and exception handling. Detailed Implementation

[0051] The present invention will be further described in detail below with reference to the accompanying drawings. Taking the domestically developed real-time operating system SylixOS as an example, the specific implementation of the satellite multi-type hardware device service-oriented encapsulation and container deployment method of the present invention will be explained.

[0052] The hardware environment of this invention is as follows:

[0053] 1) Satellite hardware boards running the SylixOS real-time operating system, equipped with serial communication interfaces, network communication interfaces, and container runtime environments;

[0054] 2) Various types of satellite hardware devices, including micromechanical inertial navigation systems (MEMS), star sensors, flywheels, gyroscopes, etc., are connected to the satellite board via RS422 serial ports;

[0055] 3) Ground monitoring terminal, used for remote monitoring and command issuance;

[0056] 4) Container runtime environment: A lightweight container runtime adapted to the SylixOS system, supporting the deployment and management of container images.

[0057] The technology proposed in this invention can be applied to integrated electronic systems for intelligent spacecraft. A typical scenario is that a satellite carries various hardware devices, such as a micromechanical inertial navigation system (MEMS) for attitude measurement, a flywheel for attitude control, and a star sensor for attitude determination. Upper-layer applications need to obtain various hardware data or send control commands through a unified interface. This method achieves standardized access and service-oriented encapsulation of hardware devices. Upper-layer applications do not need to concern themselves with hardware details and can complete data interaction through RPC interfaces. Containerized deployment ensures that each hardware service runs independently, avoids resource conflicts, supports online service upgrades and fault isolation, and guarantees the stable execution of satellite missions.

[0058] The present invention will be further described in detail below with reference to the accompanying drawings.

[0059] A framework for a software support platform that supports the service-oriented encapsulation and container deployment method for multi-type satellite hardware devices proposed in this invention is as follows: Figure 1 As shown. This platform comprises five core modules: a configuration file module, a serial port initialization module, a dual buffer module, a service communication interface module, and a container deployment module. The data flow and dependencies between these modules are as follows: Figure 1 As shown.

[0060] 1) Development and Maintenance Support: The tasks that need to be completed during the development and maintenance process include the following:

[0061] Define a JSON configuration file specification to provide a standardized configuration template for each type of hardware device, including parameters such as serial port path, baud rate, data bits, stop bits, parity bits, polling interval, application request interval, and maximum number of cache groups;

[0062] Define a dual-buffer architecture, such as Figure 2 As shown, a raw data frame buffer (area A) and a parsed structured data buffer (area B) are constructed, using a circular queue writing method and a mutex lock protection mechanism;

[0063] Define three types of standardized service communication interfaces, such as Figure 3 As shown, it includes a raw data acquisition interface, a parsed / average data acquisition interface, and a device command control interface, and implements networked access based on a microservice communication framework;

[0064] Define the operating mechanism of the hardware data processing thread, including polling interval control, data transmission and reception, triple verification, error statistics and exception handling;

[0065] Define a containerized deployment scheme, such as Figure 4 As shown, this includes container image building, container runtime configuration, device mounting, and resource configuration.

[0066] 2) Operational Support: When the system is put into operation, the operational support system provides support in the following ways: Figure 5 The illustrated process supports the operation of the satellite hardware device management system:

[0067] For data access, the hardware data processing thread sends data acquisition instructions to the hardware according to the configured polling interval, and receives the data frames returned by the hardware through a synchronous multiplex I / O waiting mechanism;

[0068] Data processing involves performing triple verification on the received data frames (frame header verification, length verification, and checksum verification). If the verification passes, the raw data is buffered and structured parsing is completed. If the verification fails, the error type and number of errors are counted.

[0069] For exception handling, when the number of instruction sending timeouts reaches the threshold, the serial port is reinitialized based on the reset enable status; when the hardware device is detected to be in a power-off state, instruction sending is stopped to avoid resource waste.

[0070] The service provider offers three types of standardized services to upper-layer applications through the service communication interface: raw data acquisition, parsed / averaged data acquisition, and device command control.

[0071] Container isolation enables the independent operation and resource isolation of various hardware services through containerized deployment, supporting independent service upgrades and maintenance.

[0072] It should be noted that the above are suggested implementation schemes for the application of the present invention. For those skilled in the art, several improvements can be made without departing from the principle of the present invention, and these improvements should also be considered within the scope of protection of the present invention.

[0073] Example

[0074] The following example of service-oriented encapsulation and container deployment of satellite micromechanical inertial navigation system (MEMS) hardware further illustrates the present invention. This example is based on the domestic real-time operating system SylixOS.

[0075] The steps of the method of this invention enable the service-oriented packaging and container deployment of MEMS hardware as follows:

[0076] Define configuration file: Specify the JSON configuration file for the MEMS hardware, with the following content:

[0077] { "device": " / dev / ttyS0",

[0078] "baudrate":115200,

[0079] "poll_interval_ms":500,

[0080] "app_request_interval_ms": 2000,

[0081] "data_bits": 8,

[0082] "stop_bits": 1,

[0083] "parity": "O",

[0084] "cache_max_groups": 0}

[0085] Where `device` is the serial port path, `baudrate` is the baud rate (115200), `poll_interval_ms` is the polling interval (500ms), `app_request_interval_ms` is the application request interval (2000ms), `data_bits` is the data bit limit (8 bits), `stop_bits` is the stop bit limit (1 bit), `parity` is the parity (odd), and `cache_max_groups` is the maximum number of cache groups. If the configuration file is missing, the default parameters will be used automatically.

[0086] Define the serial port initialization process: such as Figure 1 The serial port initialization module in the diagram uses the SylixOS open, ioctl, and tcsetattr interfaces to complete serial port initialization. It opens the serial port device file / dev / ttyS0 and sets the mode to O_RDWR|O_NOCTTY; it sets the baud rate to 115200 using ioctl; it configures the serial port frame format to odd parity, 8 data bits, and 1 stop bit using tcgetattr and tcsetattr; it sets the serial port to raw input mode and configures VTIME=10 (1-second timeout); and it clears the serial port buffer to ensure the real-time performance and accuracy of serial port data reading and writing.

[0087] Define a dual-buffer architecture: such as Figure 2 As shown, a raw data frame buffer (area A) and a parsed structured data buffer (area B) are constructed. The buffer capacity is dynamically calculated based on the application request interval and polling interval, with buffer capacity = ceil(2000ms / 500ms) = 4. The raw buffer stores the latest MEMS_Frame raw data frame (44 bytes), and the parsing buffer stores four sets of parsed MEMS_Info structured data. Buffer writes use a circular queue approach, maintaining a parsed_write_idx write index pointer. The pointer increments cyclically with each data write, and new data automatically overwrites the oldest data when the buffer is full. A pthread_mutex_t mutex lock ensures safe concurrent access for data processing threads and RPC interface threads.

[0088] Data parsing method defined: The 44-byte data frame returned by the MEMS hardware contains angular increment data in 24-bit two's complement format and integration time in 16-bit big-endian format. The data parsing module implements a 24-bit two's complement to 32-bit integer conversion algorithm, performing sign extension when the highest bit of the 24-bit data is 1; it also implements a big-endian to little-endian conversion algorithm, combining the high byte and low byte into a 16-bit unsigned integer. The formula for calculating the angular increment physical quantity is: Angular increment = (original value × 1024) / (integration time × scaling factor) - zero bias / 3600, where the scaling factor and zero bias are pre-calibrated MEMS device parameters.

[0089] Define a data processing thread: such as Figure 5 As shown, a separate `poll_thread` is created to acquire data at a 500ms polling interval. Commands 0x55 and 0x68 are sent to the MEMS hardware to receive data via the `select` mechanism, with a total timeout of 1 second and polling every 100ms. After receiving a 44-byte data frame, a triple check is performed: verifying that the frame header is 0x97, that the received length is 44 bytes, and calculating the sum of all bytes except the last byte and comparing it with the checksum of the last byte. If the check passes, the raw data is written to the `raw_frame` buffer, and the `mems_data_extraction` function is called to complete data parsing. The parsed data is written to the `parsed_cache` buffer. If the check fails, the corresponding frame header error count `memsHeaderErrCnt`, checksum error count `memsCheckErrCnt`, and length error count `memslengthErrCnt` are recorded.

[0090] Define an exception handling mechanism: such as Figure 5 As shown, the data processing thread maintains a continuous timeout counter, `send_MEMSCmderCnt`. When the number of consecutive timeouts reaches the threshold of 10, if the reset enable flag `memsResetEnable` is true, the serial port is automatically reinitialized and the serial port reset count `memsUartResetCnt` is incremented, resetting the timeout counter; if the reset enable flag is false, only a warning log is output. Simultaneously, the thread monitors the power supply status flag `MEMS_OnOff_status`. When it detects that the hardware is in a power-off state (not 0x11), it stops sending data acquisition commands to the hardware to avoid invalid communication and resource waste.

[0091] Define an RPC interface: such as Figure 3As shown, three standardized interfaces are registered based on the VSOA communication framework. The ` / mems_raw_rpc` interface returns the binary data of the raw data frame `MEMS_Frame`; the ` / mems_parsed_rpc` interface receives a 1-byte request parameter, parameter 0 returns the latest parsed real-time `MEMS_Info` data, and parameter 1 returns the average X / Y / Z axis angle increments of four sets of data in the buffer. The average calculation avoids lock contention by copying data from the local buffer; the ` / mems_cmd` interface uses a two-byte protocol [mode, value]. `mode=0` controls the power switch, `value=0x11` for on and `0x00` for off; `mode=1` controls the reset enable, `value=0x11` for enable and `0x00` for disable. It is also compatible with single-byte protocols, processing the received single-byte data as the value of the reset enable control command. The interface returns the command execution result and counts `recv_cmd_total` (total number of commands) and `recv_cmd_valid` (number of valid commands).

[0092] Define containerized deployment: such as Figure 4 As shown, a SylixOS-compatible container base image is built, including dependencies such as the VSOA framework and the yyjson parsing library. The MEMS service code, dependency libraries, and configuration files are packaged into the image. A container startup script is written to automatically load the configuration file, initialize the serial port, and start the VSOA service and data processing thread upon startup. The container image adopts a lightweight design, keeping its size under 12MB. The container is started via a runtime environment, mounting the serial port device file / dev / ttyS0 and the configuration file directory / etc / mems / config.json to achieve interaction with the underlying hardware. The container image supports parameterized configuration, adapting to different types of hardware devices by mounting different configuration files.

[0093] At runtime, such as Figure 1As shown in the overall process, the system completes the entire process of configuration file reading, serial port initialization, dual buffer management, RPC interface encapsulation, data processing thread execution, and container deployment. Upper-layer services can obtain the latest structured data by calling the ` / mems_parsed_rpc` interface and passing parameter 0 via RPC; to obtain the average data, parameter 1 is passed; to control the power switch or enable the serial port reset function, the ` / mems_cmd` interface is called with the two-byte parameter `[mode, value]`, where `mode=0` is for power control, `mode=1` is for serial port reset enable control; `value=0x00` is for disabling, and `value=0x11` is for enabling (other values ​​are considered invalid instructions). After containerization deployment, the MEMS service runs independently, isolated from other hardware services. Even if a failure occurs, it will not affect the normal operation of other services, and online upgrades and maintenance are supported.

Claims

1. A method for service-oriented packaging and container deployment of multi-type satellite hardware devices, characterized in that, Includes the following steps: 1) Define the JSON configuration file specification. The configuration file includes parameters such as the serial port path of the hardware device, baud rate, data bits, stop bits, parity bits, polling interval, application request interval, and maximum number of cache groups. 2) Initialize the hardware serial port based on the configuration file parameters, configure the serial port's verification method, data bit length, number of stop bits, and set the serial port read / write timeout rules; 3) Construct a dual-buffer architecture. The first buffer caches the raw data frames from the hardware device, and the second buffer caches the parsed structured data. The buffer capacity is dynamically calculated and expanded according to the application request interval and polling interval. Cache operations are thread-safe through mutex locks. 4) Based on the microservice communication framework, three types of standardized service communication interfaces are encapsulated: raw data acquisition interface, parsed / average data acquisition interface, and device command control interface. 5) Construct a hardware data processing thread, send data acquisition instructions to the hardware according to the configured polling interval, and perform frame header verification, checksum verification, and length verification after receiving the data frame returned by the hardware. If the verification passes, complete the raw data caching and structured parsing. If the verification fails, count the error type and the number of times. 6) Package the encapsulated hardware service code, dependency libraries, and configuration files into a lightweight container image and deploy it on the satellite hardware board.

2. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, The JSON configuration file specification in step 1) supports default parameters as a fallback. When the configuration file is missing or the parameters are not configured, the preset default values ​​are automatically adopted, including the default serial port path, default baud rate, default data bits, default stop bits, and default parity bits.

3. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, The serial port initialization process described in step 2) includes the following steps: 21) Open the serial port device file in read / write mode, and do not use the device as a control terminal; 22) Set the baud rate via the ioctl interface; 23) Configure the serial port frame format, including parity bit, data bits, and stop bits, by obtaining and setting the serial port terminal configuration. 24) Set the serial port to raw input mode and configure the read / write timeout. 25) Clear the serial port buffer, output an error log and support a retry mechanism when initialization fails.

4. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, Step 3) requires defining the dynamic expansion rules and thread safety guarantee methods for the dual buffers, specifically including the following steps: 31) The formula for calculating cache capacity is: Cache capacity = ceil(application request interval / polling interval), and the calculation result is not less than 1; 32) If the maximum number of cache groups is defined in the configuration file and is greater than 0, then the smaller value between the calculated value and the maximum number of groups is taken as the final cache capacity; 33) Cache writes use a circular queue to maintain write index pointers, which are incremented cyclically after each data write; 34) Use a thread mutex lock to lock cache read and write operations. The data processing thread acquires the write lock when writing data to the cache, and the remote procedure call service thread acquires the read lock when reading cache data. 35) When the application request interval or polling interval parameter is dynamically adjusted, the cache capacity is recalculated and new memory space is requested. While holding the mutex lock, the original cache area is atomically replaced and the old cache area memory is released.

5. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, Step 4) requires defining three types of standardized remote procedure call interfaces, specifically including: The raw data acquisition interface returns the binary data of the raw hardware data frame; The parsing / mean data retrieval interface returns the mean of the parsed structured data or cached data based on the request parameters, where request parameter 0 represents real-time data and 1 represents mean data; The device command control interface uses a two-byte protocol [mode, value]. mode=0 is for power switch control, value=0x11 is on, and value=0x00 is off. mode=1 is for reset enable control, value=0x11 is enabled, and value=0x00 is disabled. This interface is compatible with single-byte protocols. When receiving single-byte data, the byte is treated as the value of the reset enable control command and the interface returns the command execution result.

6. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, The server-side deployment process of the microservice communication framework described in step 4) includes: creating a server instance and configuring the service name; registering three types of service communication interfaces to the server instance; binding the network port and starting the service; and handling client requests through a synchronous multiplex I / O wait mechanism to achieve networked access to hardware services.

7. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, Step 5) requires defining data frame verification rules, error statistics mechanisms, and exception handling mechanisms, specifically including: Frame header verification verifies whether the first byte of the data frame is a preset value; Length check: Verify whether the actual number of bytes received is equal to the hardware data frame length. Checksum verification calculates the sum of all bytes except the last byte and compares it with the checksum of the last byte. Error statistics include the number of frame header errors, checksum errors, length errors, and serial port resets, and support exposing error statistics information to the outside world through the service communication interface; When the number of command sending timeouts reaches the set threshold, if reset is enabled, the serial port will be automatically reinitialized and the number of resets will be counted; if reset is disabled, only a warning log will be output. When a hardware device is detected to be in a power-off state, data acquisition commands are stopped from being sent to the hardware to avoid invalid communication and waste of resources.

8. The satellite multi-type hardware device service-oriented packaging and container deployment method according to claim 1, characterized in that, Step 6) includes: Package the hardware service code, dependency libraries, and configuration files into a container image, keeping the image size under 12MB. The container is started on the hardware board through the container runtime, and the serial port device file and configuration file directory are mounted to achieve resource isolation between the hardware service and the host system. The container image supports parameterized configuration, allowing it to be adapted to at least one of the following satellite hardware devices: micromechanical inertial navigation system (MEMS), star sensor, flywheel, and gyroscope, by mounting different configuration files.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-8.

Images