Modular design method for satellite communication terminal application software

Abstract

The invention discloses a satellite communication terminal application software modular design method, which is suitable for an ARM (Advanced RISC Machines) architecture Linux platform and aims to solve the core defects of traditional satellite terminal software. The method comprises the following steps of: firstly, dividing 14 independent modules by combining platform characteristics and business requirements, and interacting the modules through a standard interface adaptive to the bottom specification of the platform; secondly, a main process and multiple sub-threads framework is adopted, the main process initializes system resources and pulls up the sub-threads of all modules, and the sub-threads support dynamic loading / unloading and fault restarting through IPC cooperation, so that overall collapse is avoided; and finally, abstracting driving logic through a hardware interface module, realizing multi-hardware compatibility in combination with a common function of a common module, and monitoring the state by means of an alarm and log module to ensure stable operation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of satellite communication, specifically belongs to the category of software design and development of satellite communication terminals, and particularly relates to a modular design method of satellite communication terminal application software suitable for ARM architecture Linux platform. BACKGROUND

[0002] Satellite communication has become a core communication support means in key fields such as emergency rescue, ocean transportation, aviation navigation and communication in remote areas due to its wide coverage and technical advantages of not being limited by geographical environment. In recent years, with the development of satellite communication technology towards "low-orbit satellite constellation, terminal device miniaturization, and communication link broadband", satellite communication terminals have shown two major core trends: first, the hardware core chip architecture is transformed to ARM, which has the advantages of low power consumption and high integration compared with the traditional x86 architecture, and is more suitable for the design requirements of portable and vehicle-mounted light terminals. More than 70% of the new satellite communication terminals on the current market have adopted ARM architecture chips. Second, the hardware function integration has been significantly improved, and a single terminal needs to support functions such as radio frequency signal processing, protocol stack analysis, multi-type interface (such as UART, I2C, SPI, Ethernet) data interaction, and peripheral (fan, LED, WiFi module) control, which puts forward higher requirements on the hardware adaptation ability and function expansion ability of the supporting software.

[0003] However, the current design of satellite communication terminal application software is still mainly based on traditional architecture, which cannot adapt to the characteristics of ARM architecture Linux platform and cannot meet the needs of multi-scene applications. The main technical defects that need to be solved are as follows: 1. Poor hardware adaptation compatibility, high cross-model reuse cost The existing satellite communication terminal software generally adopts a monolithic architecture with "function and hardware strong binding", without layering abstraction and standardization packaging of hardware driver logic, resulting in significant limitations in hardware adaptation: On the one hand, independent driver calling code needs to be developed for different types of hardware modules (such as baseband processing units and external interface chips).

[0004] On the other hand, most traditional software is initially developed based on the x86 architecture or a dedicated real-time operating system (such as VxWorks), and is not optimized for the underlying call specifications of the ARM architecture Linux platform (such as device tree node configuration, IO memory mapping mechanism, and system call interface standard). After porting to the ARM architecture Linux platform, compatibility issues such as memory leaks (average memory leak rate of 5% / 24h), interface call timeouts (call failure rate of over 8%), and hardware initialization failures (initialization success rate of less than 90%) may occur, significantly reducing the stability of the software and making it unable to meet the use requirements of "7x24 continuous operation" of satellite communication terminals.

[0005] 2. High coupling degree of software modules, difficulty in maintenance and functional expansion Existing satellite communication terminal software does not have clear functional module division, and core functions such as startup control, AT command processing, device management, network configuration, and log recording are directly integrated into a single program. There is no standardized interface between modules, leading to many problems in software maintenance and expansion: First, the functional iteration risk is high. For example, when adding the "fan speed adaptive control" function, the nested code of the device management module and the alarm module needs to be modified (code coupling degree is over 70%), which not only prolongs the development cycle to 5-7 days, but also easily causes logic vulnerabilities in existing functions (such as an increase of 15% in the probability of false triggering of alarm thresholds); Second, the cost of module expansion is high. If a WEB remote operation and maintenance module needs to be added, the adaptation code of the device management module and the configuration management module needs to be redeveloped (the amount of adaptation code accounts for 60% of the development amount of the new module), and dynamic loading / unloading of modules cannot be supported. When an abnormality occurs in a non-core module (such as the log management module), it will cause the entire software to crash, interrupting satellite communication services, and the average fault recovery time is over 2 hours, seriously affecting communication continuity; Third, the code reuse rate is low. The same basic functions (such as data format conversion, error code analysis, and time synchronization) are repeatedly developed in different modules, with a code redundancy rate of over 30%. This not only increases the size of the software installation package (redundant code accounts for 25%), but also leads to an increase in subsequent maintenance costs and a software version iteration cycle of 10-15 days.

[0006] 3. Incomplete operation and maintenance mechanism, low fault handling efficiency Satellite communication terminals are often deployed in remote areas, ocean-going ships, aircraft, and other special scenarios. The existing operation and maintenance method cannot meet the efficient operation and maintenance requirements, and has the following shortcomings: First, the operation and maintenance means are single. Most software only supports local CLI command line operation and maintenance, lacks WEB remote operation and maintenance capability, and for terminals deployed on ocean ships and remote emergency sites, operation and maintenance personnel need to arrive on site for operation, the single operation and maintenance cost is more than 10,000 yuan, and the fault response is delayed (the average fault response time is more than 24 hours), which cannot handle emergency communication faults in time; Second, the log management capability is weak. The software can only record basic running logs (such as module start / stop state, key interface call results), cannot receive and store signaling logs sent by the CP side (physical layer / protocol stack hardware) through UDP broadcast, and the logs are only stored locally in the terminal FLASH, which need to be exported through a special tool. After a fault occurs, it is difficult to quickly trace the root cause of the problem, and the average fault locating time is more than 4 hours; Finally, the state monitoring and alarm mechanism is missing. The software has no independent alarm management module, and abnormal conditions such as hardware temperature being too high (more than 85℃), CPU memory occupation being too high (more than 90%), and network link interruption can only be fed back through the hardware indicator light, which cannot be pushed to the remote operation and maintenance platform in real time, which is easy to miss the best opportunity for fault handling, resulting in the communication interruption time being extended to more than 30 minutes.

[0007] 4. Configuration management is not flexible, and data security and reliability are insufficient The configuration management mode of the existing satellite communication terminal software does not meet the design requirements of "high reliability and easy maintenance", and the main problems are: First, the configuration format is not standardized. Binary files or.ini format are often used to store configuration parameters (such as core network IP address, antenna angle parameter, alarm threshold), which do not support real-time operations such as "add, delete, modify and query" of configuration parameters. After modifying the configuration, it needs to be restarted to take effect, which will interrupt the satellite communication service for 5-10 minutes each time, affecting the continuity of communication; Second, the configuration data is easy to lose. The power failure saving mechanism is not used, and after the terminal is powered off unexpectedly (such as power failure in emergency scenarios), the loss rate of key configuration parameters is more than 80%, which needs to be manually configured by operation and maintenance personnel, and the average configuration recovery time is more than 1 hour, which cannot quickly recover the communication service; Third, the configuration security is insufficient. The remote configuration interface lacks account authentication (such as username and password verification) and data encryption (such as AES encryption) mechanisms, which has the risk of configuration being illegally tampered with, which may cause the terminal to access illegal core networks, antenna parameter abnormalities, and other problems, which may cause communication interruption or data leakage.

[0008] In summary, the current satellite communication terminal application software has technical defects in ARM architecture Linux platform adaptation, modular design, operation and maintenance efficiency and configuration management, which has become a key bottleneck restricting the development of satellite communication terminals to lightweight, multi-scene and high reliability. Therefore, a software design method capable of realizing multi-model hardware compatibility, module decoupling, efficient remote operation and maintenance and flexible and reliable configuration is needed to meet the technical development needs of the satellite communication field. SUMMARY

[0009] In view of the four core pain points of the existing satellite communication terminal application software under the ARM architecture Linux platform: hardware adaptation difficulty (more than 70% of the core code needs to be modified for multiple hardware models, and the adaptation period is as long as 15-30 days), module coupling (function nesting leads to overall crash caused by single module exception, and high extension cost), low operation and maintenance efficiency (only local CLI operation and maintenance is supported, and log cannot receive CP side signaling data), and unreliable configuration (modification requires software restart, and power failure configuration loss rate is more than 80%), the purpose of the application is to provide a modular design method. Through standardized hardware interface, "main process + multi-subthread" architecture and accurate module function splitting, multi-hardware rapid adaptation, stable software operation, remote efficient operation and reliable configuration management are realized, and finally the needs of civil emergency communication, aerospace, ocean and other scenes for "lightweight, high compatibility and easy maintenance" of software are met.

[0010] In order to achieve the above purpose, the technical scheme adopted by the application is: a satellite communication terminal application software modular design method suitable for ARM architecture Linux platform, comprising the following steps: S1: function module splitting: based on the bottom running characteristics of ARM architecture Linux platform and the core business needs of satellite communication terminal, the software is split into 14 modules, and is divided into three categories according to the responsibilities: basic support type, business interaction type and operation and maintenance type; S2: running architecture construction: constructing a "main process + multi-subthread" software running architecture: the main process completes the system resource initialization of the ARM architecture Linux platform; after the main process initialization is completed, 14 independent subthreads corresponding to the modules are started respectively; S3: configuration standardized interaction interface: configuring a standardized interface for 14 modules to adapt to the bottom calling specification of ARM architecture Linux platform, and each module realizes data interaction through the standardized interface; at the same time, by abstracting the hardware driver calling logic under the ARM architecture Linux platform, combined with general tool functions, the application software realizes compatible adaptation to different models of satellite communication terminal hardware; S4: Establishing a running guarantee mechanism: through real-time monitoring of the running state of each sub-thread, the running log of each module is recorded; when any sub-thread appears abnormal, the main process triggers the fault restart mechanism to independently restart the abnormal sub-thread.

[0011] As a preferred mode of the application, all modules interact only through standardized interfaces: The basic support class includes a start management module, a public module and a hardware interface module; The business interaction class includes an AT command module, an antenna control module, an IP communication module, a device management module and a network management module; The operation and maintenance management class includes a configuration management module, an upgrade management module, an alarm management module, a log management module, a WEB proxy module and a CLI command line module; As a preferred mode of the application, the hardware interface module: as an intermediate layer between software and hardware, abstracts the driving logic through 5 standardized interfaces, including a hardware initialization interface, a FLASH driving interface, an I2C interface, an SPI interface and a UART serial port interface; The hardware initialization interface is used to complete the power-on detection, register configuration and initialization state feedback of the satellite communication terminal hardware when the application software starts; The FLASH driving interface is used to realize the read-write control of the FLASH memory chip, support power failure storage and reading of configuration parameters and log data; The I2C interface and the SPI interface are used to interact with sensors and peripheral chips in the satellite communication terminal; The UART serial port interface is used to adapt to the serial communication needs of the AT command module and provides a standardized serial data transmission channel.

[0012] As a preferred mode of the application, the AT command module: based on the UART serial port of the hardware interface module, realizes the whole process of AT command "reception-framing-sending-analysis-distribution", after the AT command module receives the AT command request of other modules, it encapsulates the command frame according to the preset format and sends it to the satellite communication terminal hardware through the UART serial port interface of the hardware interface module, at the same time, it receives the response frame returned by the hardware and completes the frame disassembly and analysis, and feeds back the analysis result to the request module; for the preset type of AT command execution result, the AT command module sends it to the sub-thread of other modules through unicast or multicast mode, if the response frame is abnormal, the log management module is triggered to record the abnormal information.

[0013] As a preferred mode of the application, the antenna control module: calls the antenna driver through the SPI interface of the hardware interface module, establishes an interaction channel with the antenna based on the UDP protocol, and realizes the transmission of instructions for adjusting the angle of the antenna, controlling the signal gain and detecting the state; The antenna control module receives external control instructions, generates corresponding UDP control messages, sends the UDP control messages to the antenna hardware through a standardized interface, receives UDP state messages fed back by the antenna, analyzes the signal strength and connection state real-time data, and feeds back the data to the device management module.

[0014] As a preferred mode of the application, the IP communication module: based on the TCP / IP protocol stack of the ARM architecture Linux platform, establishes a communication connection with the adjacent CP hardware, and builds a data transmission and message forwarding channel for satellite communication. The IP communication module receives the request of the demand module, encapsulates data packets according to the protocol specification, and forwards the data packets to the target CP hardware through the network interface, receives the data packets sent by the CP hardware, distributes the data packets to the corresponding modules after unpacking, supports data fragmentation transmission, retransmission mechanism and flow control, and does not involve the processing of CP side service logic.

[0015] As a preferred mode of the application, the device management module: is used to manage the hardware device information and system resource state of the satellite communication terminal, the hardware device information includes device model, hardware version and running time, and the system resource state includes temperature, CPU occupancy and memory occupancy. The device management module collects sensor data through the I2C interface or SPI interface of the hardware interface module, regularly stores the information in the database of the configuration management module, supports the control logic of the fan, LED and WiFi, can receive external control instructions and drive the corresponding hardware to perform actions through the hardware interface module, and supports the control logic of the fan, LED and WiFi. The device management module also supports querying device information and system resource state through the CLI command line module or WEB proxy module.

[0016] As a preferred mode of the application, the network management module: monitors the network connection state under the ARM architecture Linux platform, including network link on-off, IP address configuration and gateway state, receives messages sent by the AT command module sub-thread, and based on the IP address and routing parameter information issued by the core network carried in the messages, completes the dynamic configuration of the data communication route. If the network link is disconnected, the network management module triggers the reconnection mechanism, and sends a network exception alarm through the alarm management module; the network management module also supports dynamically modifying network parameters through the configuration management module.

[0017] As a preferred mode of the application, the configuration management module: uses a JSON format configuration file to store all configuration parameters of the application software, and the configuration parameters include module running parameters, hardware adaptation parameters and network configuration parameters. The configuration management module realizes power-off saving of the configuration file through a FLASH drive interface of the hardware interface module, and supports adding, deleting, modifying and inquiring operations on the JSON configuration file.

[0018] As a preferred mode of the application, the upgrade management module: receives a remote upgrade package through the IP communication module, checks the integrity and compatibility of the upgrade package based on version information of an ARM architecture Linux platform, upgrades each module in a preset order if the check passes, records the upgrade progress through the log management module during the upgrade process, triggers a rollback mechanism to restore to a version before the upgrade if the upgrade fails, and sends an upgrade failure alarm.

[0019] As a preferred mode of the application, the alarm management module: defines alarm levels, classifies and stores alarm information sent by each module according to the levels, and pushes the alarm information to a remote operation and maintenance platform through the IP communication module or a serial port; the alarm management module also supports dynamic configuration of alarm thresholds through the configuration management module.

[0020] As a preferred mode of the application, the log management module: is used to realize a whole process of "collection-storage-operation and maintenance" of multi-source logs, supports CP-side signaling log reception and WEB-side operation and maintenance, and specifically: records running logs of each module, including module startup logs, data interaction logs, exception logs and operation logs; receives signaling logs sent by the CP side through UDP broadcasting, and stores the signaling logs in a local storage unit after format checking; supports hierarchical storage and log filtering of logs, and only realizes uploading and downloading operations of logs through a WEB proxy module, without performing log uploading and downloading through a CLI command line module; the log format is adapted to a log analysis tool of the ARM architecture Linux platform.

[0021] As a preferred mode of the application, the WEB proxy module: constructs a WEB management interface, supports access by a remote operation and maintenance personnel through a browser; collects information required by a WEB page in advance, and stores the information in a memory or a lightweight SQLite database of the ARM architecture Linux platform; and performs UDP packetization and transparent transmission processing on information required by the WEB page, converts complex data into a standardized string format, and transmits the data to the WEB page.

[0022] As a preferred mode of the application, the CLI command line module: provides a command line interactive interface, and supports input of commands by an operation and maintenance personnel through a serial port or a remote terminal; The CLI command line module supports command auto-completion and syntax checking, and the command execution result is fed back through a standardized format, while the command operation log is recorded to the log management module.

[0023] The four core technical effects are realized in the satellite communication terminal application software of the ARM architecture Linux platform through the above-mentioned modular design method, which is significantly superior to the existing scheme: 1. Hardware adaptation efficiency is improved by more than 70% Through the 5-type standardized interface abstraction of the hardware interface module, multi-model hardware adaptation only needs to modify the interface configuration parameters (such as SPI rate, UART baud rate), without modifying the upper core code, and the adaptation period is shortened from 15-30 days to 1-2 days; at the same time, for the bottom optimization of the ARM architecture Linux platform, the occurrence rate of software compatibility problems (such as memory leakage, interface call failure) is reduced from 30% to less than 5%, and the average trouble-free running time is improved from 100 hours to more than 500 hours.

[0024] 2. Module expansion and maintenance cost is reduced by 60% The "main process + multiple sub-threads" architecture supports dynamic loading / unloading of modules, and the development cycle of new functions (such as the WEB proxy module) is shortened from 5-7 days to 1-2 days; 14 module functions are decoupled, and single module exception (such as log management module sub-thread exit) only needs to be restarted independently, without overall crash risk, and the fault recovery time is shortened from 2 hours to less than 500ms; the reuse rate of public module tool functions reaches 95%, and the code redundancy is reduced from 30% to less than 5%.

[0025] 3. Remote operation and maintenance response efficiency is improved by 90% The pre-caching and UDP transparent design of the WEB proxy module shortens the response time of the remote operation and maintenance page from 500ms to 50ms; supports WEB-side log query, configuration modification, and upgrade triggering, without the need for on-site operation, and the operation and maintenance cost of the terminal of the ocean, emergency site is reduced from single ten thousand yuan level to hundred yuan level, and the fault response time is shortened from 24 hours to less than 10 minutes; the log management module supports CP-side signaling log receiving and remote uploading, and the fault positioning time is shortened from 4 hours to 30 minutes.

[0026] 4. Configuration management reliability reaches 99.9% JSON configuration file + FLASH power saving mechanism, configuration parameter loss rate is reduced from 80% to 0; parameter modification takes effect in real time without restarting the software, and the communication interruption time is reduced from 5-10 minutes to 0; AES-128 encryption storage and HTTPS transmission, the risk of illegal tampering of configuration is reduced from 20% to 0, which meets the high requirements of satellite communication terminal on configuration reliability and security.

[0027] In conclusion, the application effectively solves the compatibility, expansibility, operation and maintenance efficiency and configuration reliability of the existing satellite communication terminal application software under the ARM architecture Linux platform, can be widely applied to civil emergency communication, aerospace, ocean and other scenes, and has significant practical value and industrialization prospect.

[0028] The application constructs a software architecture of "function modularization splitting-standardized interface interaction-main process+multi-subthread running", and optimizes the bottom layer calling specification of the ARM architecture Linux platform, solves the technical bottlenecks of the existing satellite communication terminal software in aspects of multi-model hardware adaptation, function extension maintenance, remote operation and maintenance response and configuration management reliability, and improves the software running stability and scene adaptation flexibility. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 It is a satellite communication terminal hardware connection schematic diagram used in the embodiment.

[0030] Figure 2 It is a satellite communication terminal internal ARM chip upper layer application software modularization schematic diagram used in the embodiment.

[0031] Figure 3 It is a satellite communication terminal upper layer application software startup management startup sequence schematic diagram used in the embodiment.

[0032] Figure 4 It is a satellite communication terminal upper layer application software common module sub-type schematic diagram used in the embodiment.

[0033] Figure 5 It is a satellite communication terminal upper layer application software AT command module and other module interaction schematic diagram used in the embodiment.

[0034] Figure 6 It is a satellite communication terminal upper layer application software antenna control module and other module interaction schematic diagram used in the embodiment.

[0035] Figure 7 It is a satellite communication terminal upper layer application software IP communication module and other module interaction schematic diagram used in the embodiment.

[0036] Figure 8 It is a satellite communication terminal upper layer application software device management module and other module interaction schematic diagram used in the embodiment.

[0037] Figure 9 It is a satellite communication terminal upper layer application software network management module and other module interaction schematic diagram used in the embodiment.

[0038] Figure 10This is a schematic diagram illustrating the interaction between the upper-layer application software configuration management module of the satellite communication terminal and other modules used in this embodiment.

[0039] Figure 11 This is a schematic diagram illustrating the interaction between the satellite communication terminal upper-layer application software upgrade management module and other modules used in this embodiment.

[0040] Figure 12 This is a schematic diagram of the core command classification in the CLI command line module of the upper-layer application software of the satellite communication terminal used in this embodiment.

[0041] Figure 13 This is a schematic diagram showing the functional verification results of the marine scenario in this embodiment.

[0042] Figure 14 This is a schematic diagram illustrating the performance verification results in the marine scenario of this embodiment. Detailed Implementation

[0043] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0044] This invention follows a progressive logic of "problem-solution-implementation-guarantee," constructing a four-layer technical system to form a complete solution: First layer: Functional module decomposition – decoupling core logic like Figures 1-2 As shown, based on the characteristics of the ARM architecture Linux platform (device tree, MTD driver framework, I2C / SPI subsystem) and the requirements of satellite communication services (signal control, data transmission, operation and maintenance management), the software is divided into 14 functionally simple and clearly defined modules, which are categorized into three types according to their responsibilities: 1. Basic Support Modules: Startup Management Module (Startup Process Scheduling), Common Module (General Utility Functions), Hardware Interface Module (Hardware Driver Abstraction) – Solving the problem of “inconsistent underlying support”; 2. Business Interaction Modules: AT Command Module (full-process processing of AT commands), Antenna Control Module (antenna angle / gain control), IP Communication Module (CP-side data forwarding), Device Management Module (hardware status acquisition + peripheral control), Network Management Module (core network parameter configuration) – solving the problem of “business logic coupling”; 3. Operations and Maintenance Management: Configuration Management Module (JSON configuration storage + real-time effect), Upgrade Management Module (remote upgrade + rollback), Alarm Management Module (tiered alarms + push), Log Management Module (multi-source log collection + WEB operations and maintenance), WEB Proxy Module (pre-caching + UDP pass-through), CLI Command Line Module (local command interaction) — solving the problem of "inefficient operations and maintenance configuration"; All modules interact only through standardized interfaces, without direct code dependencies, completely breaking the coupling barriers of traditional monolithic architecture.

[0045] Second layer: Run architecture building - ensure stable operation Adopting the "main process + multiple sub-threads" architecture, adapting to the resource scheduling characteristics of ARM architecture Linux, realizing "fault isolation, dynamic expansion": Main process: assuming the role of "scheduling center", only responsible for 3 core tasks: ① System resource initialization (CPU priority configuration, memory allocation by 4KB page, hardware driver loading); ② Sub-thread life cycle management (priority pull, 100ms period monitoring state, abnormal automatic restart); ③ Cross-module communication coordination (maintain IPC message queue index) - do not participate in specific business logic to avoid main process overload; Sub-thread: 14 modules each corresponding to an independent sub-thread, created based on the pthread library of the ARM platform, supporting: ① Dynamic loading / unloading (through the dlopen / dlclose function, load new modules without restarting the software); ② Exception independent recovery (when the sub-thread exits, the main process is reconstructed through the fork function, with a recovery time ≤500ms); ③ Resource isolation (each sub-thread is allocated independent memory space to avoid memory overflow); Collaborative mechanism: IPC communication is achieved through "message queue + shared memory": short data (alarm signal, configuration instruction) uses message queue (each module has an independent queue to avoid data confusion), and long data (ephemeris file, log) uses shared memory (divided according to ARM memory page size, with semaphore mutual exclusion access).

[0046] Third layer: Interface standardization design - break through adaptation barriers To solve the problems of "hardware adaptation difficulty, module communication disorder", two types of interface specifications are developed: Hardware interface specification: hardware interface module encapsulates 5 types of standardized interfaces, all of which follow the ARM architecture Linux driver framework: ① Hardware initialization interface (device tree node parsing + register configuration); ② FLASH driver interface (MTD specification, supporting NAND / NOR FLASH); ③ I2C interface (I2C subsystem, rate 100 / 400kHz); ④ SPI interface (SPI subsystem, rate 1-10Mbps); ⑤UART serial interface (8250 driver framework, baud rate 9600-115200bps) - upper module calling interface does not need to pay attention to hardware model, only need to modify the configuration parameters; Module interface specification: define a unified data interaction format: ① AT command according to 3GPP TS 27.007 specification (start symbol AT+, end symbol \r\n, LRC check); ② Log according to the format of "timestamp (millisecond) - module ID - level (DEBUG / INFO / ERROR) - content"; ③ Configuration parameters in JSON key-value pair format - ensure "plug and play" between modules.

[0047] The fourth layer: running guarantee mechanism - closed-loop risk control Build a "monitoring-recording-recovery-operation" whole process guarantee system to solve the problems of "fault difficult to trace and slow response to operation and maintenance": Monitoring: The alarm management module monitors the state of the sub-thread (whether it is alive) and the hardware parameters (temperature, signal strength) in real time, and triggers three levels of alarm (emergency, important, general); Recording: The log management module collects module running logs and CP side UDP broadcast signaling logs, and stores them locally and uploads them remotely via WEB; Recovery: The main process automatically restarts the abnormal sub-thread, the configuration management module saves the parameters after power failure, and the upgrade management module supports failure rollback; Operation and maintenance: The WEB proxy module realizes remote configuration / log / upgrade, and the CLI command line module supports local emergency operation, covering all scene operation and maintenance needs.

[0048] Basic support module: build a solid foundation (1) Hardware interface module - hardware adaptation "translator" As the intermediate layer between software and hardware, it abstracts the driving logic through 5 types of standardized interfaces, realizes "hardware independence", and the details are as follows: Hardware initialization interface: 1. Implementation logic: When the software starts, the interface reads the ARM device tree " / dev / hw_init" node configuration (such as baseband interrupt number IRQ10), and performs a "three-step process": ① Power-on detection (send 0x01 command, wait 100ms to receive response, no response is judged as hardware offline); ② Register configuration (write frequency, baud rate, etc. according to device tree parameters); ③ State feedback (return 0x00 success / 0x01 failure, generate alarm signal when failure); 2. Abnormal processing: if the temperature sensor is unresponsive, send "hardware initialization failure (module: temperature sensor, code: 0x02)" to the alarm management module through the IPC message queue, triggering an emergency alarm (red LED flashing + remote push).

[0049] FLASH drive interface: 1. Specification adaptation: follow the ARMMTD driver specification, register the device node (such as / dev / mtdblock0) through the "mtd_device_register" function, support NANDFLASH (capacity 128MB-1GB) and NORFLASH (capacity 8MB-64MB); 2. Function landing: provide "write_FLASH" (write rate > 10MB / s, maximum single write 4KB, match ARM memory page), "read_FLASH" (read delay < 1ms) interface for configuration management module; provide "append_FLASH" interface for log management module (append log by block, each block 64KB, avoid covering old log); 3. Reliability guarantee: perform CRC32 check before writing (calculate data check value and compare with hardware return value), retry 3 times if check fails, still fail to send "FLASH write exception" alarm to the alarm management module.

[0050] I2C / SPI / UART interface: 1. I2C interface: based on ARMI2C subsystem, communicate with peripherals through "i2c_read", "i2c_write" functions: ① Temperature sensor (GX21M15, address 0x48): read temperature every 5 seconds, accuracy ±0.5℃, trigger alarm if temperature exceeds 85℃, voltage sensor (CAD2719, address 0x44): passive trigger to read voltage and current, also can control voltage threshold; ② LED drive chip (PCA9685, address 0x40): control 4-way LED, support on / off (high level 1.8V / low level 0V), flashing frequency (1-5Hz adjustable) - provide peripheral control channel for device management module; 2. SPI interface: follow SPI subsystem protocol, communicate with high-speed peripherals through "spi_sync" function: WiFi module (ESP8266): rate 5Mbps, send WiFi start / stop command (0x01 start / 0x00 stop) - provide high-speed data channel for antenna control module and device management module; 3. UART serial interface: based on 8250 serial port driver, supporting baud rate 9600-115200bps (dynamically modified through configuration management module), built-in 4KB ring buffer (solves transient data congestion and avoids packet loss), provides "uart_send" (send timeout 500ms), "uart_recv" (receive timeout 1s) interface - provides AT command module with AT command transmission channel, data frame format is fixed as "8-bit data bit + 1-bit stop bit + no parity bit".

[0051] Each interface follows the underlying driver specification of the ARM architecture Linux platform, so that the application software can adapt to different types of hardware without modifying the core code, and only the driver configuration parameters of the corresponding interface of the hardware interface module need to be updated.

[0052] (II) Start management module - start process "commander" Adapt to ARM architecture Linux startup sequence (kernel -> root file system -> application), realize software orderly startup, as shown in Figure 3 , details as follows: Start trigger: after the kernel starts, the module is called through the " / etc / init.d / start_app" script, which first initializes its own memory (allocates 2MB for storing startup logs and sub-thread PID); Priority scheduling: pull up sub-threads in the order of "basic support class -> business interaction class -> operation and maintenance class", specific order and basis: Batch 1: public module (provides tool functions, dependent on subsequent modules) -> hardware interface module (loads driver, dependent on hardware interaction); Batch 2: AT command module (AT command processing), antenna control module (antenna initialization), IP communication module (CP side connection establishment) -> device management module (state acquisition dependent on hardware interface), network management module (routing configuration dependent on AT command); Batch 3: configuration management module (parameter loading), upgrade management module (upgrade detection), alarm management module (state monitoring), log management module (log recording) -> WEB proxy module (remote operation and maintenance dependent on configuration), CLI command line module (local operation and maintenance); State verification: after pulling up a sub-thread, the initialization result is waited through the "pthread_join" function (timeout 3 seconds), if failed: ① Log (module XX failed to start, reason: timeout / return error code 0x03); ② Send alarm (important level, prompt operation and maintenance personnel to check hardware / configuration); ③ Try 2 times, still failed, skip this module (does not affect the startup of other modules).

[0053] (3) Common Modules – Function Reuse "Toolbox" Provides common utility functions for the ARM platform for 14 modules to avoid redundant development, such as Figure 4 As shown, the details are as follows: Data processing function library: ①data_convert: Enables conversion between hexadecimal and ASCII codes (e.g., 0x12 → "18"), and adapts to AT command parsing; ②crc32_check: Calculates the CRC32 checksum of the data (polynomial 0xEDB88320), used for FLASH writing and UDP packet verification; ③json_parse: Parses JSON format configuration (such as {"uart_baud":115200}), providing support for the configuration management module; Resource management function library: ①mem_alloc: Allocates memory in 4KB ARM memory page sizes (to avoid memory fragmentation), and triggers an out-of-memory warning when it returns NULL; ②mem_free: Safely release memory (set to NULL first, then release to prevent dangling pointers); ③time_sync: Synchronizes system time based on ARMRC clock (accuracy ≤1ms), adapting to log timestamps; Error handling function library: ①err_code_map: Error code and description mapping (0x00 → success, 0x01 → hardware exception, 0x02 → communication timeout); ②err_log_record: Calls the log management module to record error information (automatically fills in the module ID and timestamp); Calling method: All functions are encapsulated in a static library "libcommon.a", and other modules call them by linking with "-lcommon", which increases code reusability to 95% and reduces redundant code by 25%.

[0054] Business interaction modules: Core application scenarios (1) AT command module - instruction interaction "processor" Based on the UART serial port of the hardware interface module, the entire process of AT command "reception-framing-transmission-parsing-distribution" is realized, such as... Figure 5 As shown, the details are as follows: Command receiving: Receive request through IPC message queue (queue ID = 0x01), request format is "module ID (1 byte) + command type (1 byte: 0x01 query / 0x02 control) + parameter length (2 bytes) + parameter content (N bytes)", for example, the device management module sends "query hardware version" request: module ID = 0x04, command type = 0x01, parameter length = 0x08, parameter content = "HW_VERSION"; Command framing: Frame according to 3GPP TS 27.007 specification, structure is "AT + [command parameter]? \ r\n [LRC check]", for example, the query hardware version frame: "AT + HW_VERSION? \ r\n 0x3A" (LRC check is the sum of frame content ASCII code modulo 256); Command sending: Call the "uart_send" interface of the hardware interface module to send frame data, and start a timeout timer (timeout time can be set by the configuration management module, default 500ms), if the timeout is not received, then: ① Record "AT command timeout (command: HW_VERSION)" log; ② Send an alarm to the alarm management module; Response analysis: Receive hardware response frame (such as "+HW_VERSION:V1.2\r\nOK\r\n"), perform "three-step analysis": a. Split the industrial control head (+HW_VERSION:), data segment (V1.2), status code (OK); b. Check the status code (OK = success, ERROR = failure); c. Extract the data segment (hardware version V1.2); Result distribution: ① Feedback request module: Send the result to the original request module (device management module) through the IPC message queue; ② Multicast associated module: For "network registration status" "signal strength" and other preset commands (a total of 12 types), send to the network management module, alarm management module through UDP multicast (multicast address 224.0.0.1, port 10002), for example, "network registration status: registered, signal strength: -85dBm".

[0055] (2) Antenna control module - antenna operation "controller" Based on the SPI interface of the hardware interface module and the UDP protocol, precise antenna control is realized, as shown in the following figure: Figure 6 Details are as follows: Instruction receiving: receive the control instruction of the device management module (IPC message queue ID=0x02), the instruction format is "control type (1 byte: 0x01 angle / 0x02 gain) + angle value (2 bytes, 0-90°) + gain value (2 bytes, 0-30 dB) + check code (2 bytes, CRC16)", for example "adjust angle 30°, gain 20 dB": control type=0x03 (control at the same time), angle value=0x001E, gain value=0x0014, check code=0x5A8F; Instruction encapsulation: encapsulated in a custom UDP packet format, total length 48 bytes: ①Header (16 bytes): instruction type (2 bytes), packet sequence number (2 bytes, increment to prevent packet loss), CRC32 check (4 bytes), timestamp (8 bytes); ②Data segment (32 bytes): angle value (4 bytes), gain value (4 bytes), reserved bits (24 bytes); Instruction sending: call ARM platform socket interface (SOCK_DGRAM type) to send UDP packet, target IP is antenna hardware IP (read through configuration management module, default 192.168.2.10), port 10003, and record "antenna control instruction (angle 30°, gain 20 dB) sent successfully" log after sending; State feedback: receive the UDP state packet returned by the antenna (including current angle, gain, signal strength), and after analysis: ①Send to the device management module (for WEB page display); ②Judge signal strength (≤-90dBm triggers "antenna signal weak" alarm, sent to the alarm management module); ③Record state log (such as "antenna state: angle 30°, gain 20 dB, signal strength -82dBm").

[0056] (3) IP communication module - CP side interaction "repeater" As shown in Figure 7 , the IP communication module is mainly responsible for the request and response of TCP and UDP communication according to business needs, mainly including the following two directions: Transmission direction: Receive forwarding requests from modules such as the antenna control module and upgrade management (e.g., the antenna control module requests to send ephemeris files). First, the data is fragmented (fragment size 1KB, adapted to the TCPMSS value of ARM architecture Linux, avoiding IP fragmentation). Each fragment is appended with a header containing "fragment sequence number (2 bytes) + total number of fragments (2 bytes) + data length (2 bytes) + CRC16 checksum (2 bytes)". Data is sent fragment by fragment through the established TCP connection. After each fragment is sent, the system waits for "fragment reception confirmation" (ACK) from the CP side. If no ACK is received within a timeout (default 1 second), the fragment is retransmitted. If the retransmission fails 3 times, a "CP side data transmission failure" alarm (important level) is triggered, and the failed fragment sequence number is recorded in the log management module. Receiving direction: Receive TCP data (such as satellite signal strength data and signaling logs) sent by the CP side, and reassemble the complete data according to the fragment headers. ① Extract the fragment sequence number and total number of fragments to determine whether the data has been received completely; ② Perform CRC16 verification on the reconstructed data. After successful verification, distribute the data to the corresponding modules according to data type: - Signal strength data (format: timestamp + signal value) → Device management module; - Signaling log (format: CP module ID + signaling content) → Log management module; - Service control command (format: command type + parameters) → AT command module; ③ If the verification fails or the data type is unknown, discard the data and log "Invalid data on the CP side"; Boundary limitation: It is only responsible for the "reception-fragmentation / reassembly-forwarding" of data, and does not parse the CP-side business logic (such as the meaning of protocol stack signaling, satellite data content), to ensure that the module has a single function and avoid coupling with the CP-side business. When the CP-side business logic changes, there is no need to modify the IP communication module code.

[0057] (4) Device Management Module – Hardware Status Monitoring Officer It integrates hardware status acquisition and peripheral control functions, and is implemented based on multiple types of interfaces in the hardware interface module, such as... Figure 8 As shown, the details are as follows: Status acquisition: 1. System resource status: Read through system files of ARM architecture Linux: ① The " / proc / stat" file (read every 1 second): parses the "cpu" line data to calculate CPU usage (formula: (user+nice+system+irq+softirq) / (user+nice+system+idle+irq+softirq)×100%), with an accuracy of ≤1%; ② " / proc / meminfo" file (read every 1 second): calculate the memory occupancy rate through "MemTotal" and "MemFree" (formula: (MemTotal-MemFree) / MemTotalx100%), precision≤1%; collect data and update to shared memory (address 0x80000000, capacity 4KB) in real time for WEB proxy module and alarm management module to read; 2. Hardware temperature: communicate with DS18B20 temperature sensor through I2C interface of hardware interface module: ① send "temperature conversion" instruction (0x44), and send "read data" instruction (0xBE) after waiting for 100 ms; ② receive 16-bit temperature data (high 8 bits + low 8 bits), and calculate the actual temperature according to the formula "temperature=(high 8 bits<<8|low 8 bits) / 16" (such as 0x0550→13.625℃), precision±0.5℃; when the temperature≥85℃, send "hardware overheating" alarm to the alarm management module through the IPC message queue; 3. Hardware version and status: collect through sending preset AT commands by AT command module: ① "AT+HWVER?": query hardware version (such as "V1.2"); ② "AT+RFSTATUS?": query radio frequency status ("normal / abnormal"); ③ "AT+WIFISTATUS?": query WiFi connection status ("connected SSID:XXX / not connected"); collect every 30 minutes, and store the collection result to the JSON configuration file "device_status" field of the configuration management module, and update the WEB proxy module cache at the same time; Peripheral control: 1. Fan control: receive control instructions (such as "fan_speed=50%") of WEB proxy module or CLI command line module: ① parse the instruction to get the target speed (50% corresponds to duty cycle 50%); ② send PWM control signal (frequency 25kHz, duty cycle 50% corresponds to high level 1.65V) through SPI interface of hardware interface module; ③ 1 second after control, read fan speed feedback (such as "2000RPM") through I2C interface, if the deviation from the target speed is >10%, adjust the PWM duty cycle again until the deviation≤10%; 2. LED control: control 4-way LED through I2C interface (PCA9685 chip) of hardware interface module: ① Power LED (GPIO0): always on (high level) indicates normal power supply, off indicates abnormal power supply; ② Network LED (GPIO1): 1Hz flashing (on 500ms / off 500ms) indicates normal network connection, 2Hz flashing indicates network exception; ③ Alarm LED (GPIO2): red always on indicates emergency alarm, 1Hz flashing indicates important alarm, off indicates no alarm; ④ Running LED (GPIO3): green 1Hz flashing indicates normal software running, off indicates software exception; LED control instructions are dynamically adjusted through the "led_config" parameter of the configuration management module; 3. WiFi control: send WiFi control instructions through the SPI interface of the hardware interface module: ① "0x01": start WiFi, send "AT+WIFICONN?SSID=XXX&PWD=XXX" instruction through AT command module to trigger connection after 3 seconds of startup; ② "0x00": turn off WiFi, clear WiFi connection status after shutdown; when connection fails (no "connected" feedback within 30 seconds), trigger "WiFi connection exception" alarm and record failure reason (such as "SSID does not exist / password error") to the log management module; Data synchronization and log: synchronize collected state data (CPU, memory, temperature, peripheral state) to: ① Log management module: record "device state log" (format: timestamp+CPU:25%+memory:30%+temperature:75℃+fan:50%); ② WEB proxy module: update memory cache and SQLite database to ensure real-time data display on WEB page; ③ Alarm management module: for judging whether to trigger resource threshold alarm (such as CPU≥90% triggering "CPU overload" alarm).

[0058] (5) Network management module - Datacom configuration "configurator" Based on the message feedback of the AT command module, the core network realizes IP address allocation for satellite terminals and dynamic configuration of parameters, adapting to the network management characteristics of ARM architecture Linux, such as Figure 9 as shown, details as follows: Parameter receiving and analysis: receive core network parameter messages sent by the AT command module through thread IPC / ITC communication, messages are JSON format strings; Parse parameters through the "json_parse" function of the public module, perform legality verification: ①IP address: Determine whether it conforms to the format "xxx.xxx.xxx.xxx", and each segment value is 0-255; ②Subnet mask: Determine whether it is a standard subnet mask (such as 255.255.255.0); ③Gateway / DNS: Determine whether it is in the same network segment (gateway) and legal format (DNS) as the IP address; if the verification fails, discard the message and record the "core network parameter illegal" log; Route configuration and effectiveness: 1. Network card configuration: call the "ifconfig" command of ARM architecture Linux to configure the Ethernet network card (pcie1): ① "ifconfig pcie1 down": first close the network card; ② "ifconfig pcie1 192.168.1.100 netmask 255.255.255.0": set IP and subnet mask; ③ "ifconfig pcie1 up": re-enable the network card; after configuration, verify the configuration result by "ifconfig pcie1" command, and if the IP / subnet mask is not consistent with the target value, reconfigure; 2. Gateway configuration: add the default gateway through the "iproute" command: ① "iproute del default": delete the existing default gateway (if exists); ② "iproute add default via 192.168.1.1 dev pcie1": add a new default gateway; verify whether the gateway is added successfully through the "iproute show" command; 3. DNS configuration: modify " / etc / resolv.conf" file: ① Clear the original content; ② Add "nameserver 8.8.8.8" "nameserver 8.8.4.4"; after saving, verify whether the DNS resolution is normal through "ping www.baidu.com -c1"; 4. Configuration verification: after completing all configurations, perform three verifications: ① "ping 192.168.1.1 -c3": ping the gateway, and 0% packet loss is normal; ② "ping 8.8.8.8 -c3": ping the DNS, and 0% packet loss is normal; ③ "ping 10.10.1.180": ping the IP address of the test PC hung under the core network; If any of the verifications fails, it is determined that the configuration is abnormal, a "network configuration failure" alarm is triggered, and the configuration process is re-executed after 30 seconds; State monitoring and reconnection: network state detection is performed every 5 seconds: 1. Network card state detection: check the network card state through "iplink show pcie1", if "state DOWN", execute "ifconfig pcie1 up" to restart the network card, and trigger a "network card abnormal" alarm if the restart fails; 2. Link connectivity detection: ping the gateway through "ping 192.168.1.1 -c1", if there are 3 consecutive packet losses, it is determined that the link is interrupted, and the reconnection process is executed: ① Reconfigure IP / gateway / DNS; ② Rebuild TCP connection with CP side; ③ Notify the device management module to update the network status; 3. TCP connection detection: check if the TCP connection with the CP side is in the "ESTABLISHED" state through "netstat -an | grep :10001 | grep ESTABLISHED", if it is "CLOSED", trigger the reconnection (call the connection establishment function of the IP communication module); Manual parameter configuration: support modifying network parameters (such as manually adjusting DNS to 114.114.114.114) through the configuration management module: ① After receiving the modification request, the configuration management module sends the new parameters to the network management module through the IPC message queue; ② The network management module executes the operation according to the "parameter analysis-configuration-verification" process, without the need to restart the network service; ③ After the configuration takes effect, feedback "network parameter modification success" to the configuration management module, and update the network state cache of the WEB proxy module.

[0059] Operation and maintenance class module: reduce operation and maintenance cost (1) Configuration management module - parameter management "housekeeper" Adopt JSON format to realize the "storage-operation-effectiveness" full life cycle management of configuration parameters, ensure no loss of power failure, real-time modification effect, such as Figure 10 shown, details as follows: Configuration storage design: 1. Storage medium: Store the JSON configuration file "spark_app_cfg.json" to the non-volatile partition of FLASH ( / dev / mtdblock1, capacity 16MB) through the "write_FLASH" interface of the hardware interface module. This partition is read-only mounted (only the configuration management module can write through the driver interface), preventing other modules from mistakenly modifying it; 2. Configuration structure: The JSON file is divided into levels by module and contains all configurable parameters, 3. Backup mechanism: Automatically create a configuration backup every day at 0 o'clock. The backup file is named "spark_app_cfg_YYYYMMDD.bak" (e.g., "spark_app_cfg_20240520.bak") and stored in the FLASH backup partition ( / dev / mtdblock2). The latest 10 backup files are retained. When the configuration modification fails or the file is damaged, automatically restore from the latest backup file. After recovery, record the "configuration recovery success" log; Configuration operation functions: 1. Operation trigger: Support two triggering methods: ① WEB proxy module: The operation and maintenance personnel input new parameters through the WEB page form, and submit them to the configuration management module through the HTTPS protocol; ② CLI command line module: The operation and maintenance personnel input the "cfgset[module].[parameter][value]" command (e.g., "cfgsetalarm.temp_threshold_c80"), triggering the modification operation. All operations need to pass through permission verification (WEB side needs to log in with an administrator account, and CLI side needs to input an administrator password); 2. Add, delete, modify and query: ① Add parameters: Add the "wifi_ssid" parameter to the "hardware_interface" level, specify the parameter name, default value, and data type (string / numeric), and automatically write to the JSON file after adding; ② Delete parameters: Only "custom extended parameters" (such as the user-added "test_param") can be deleted, and system default parameters (such as "uart_baud") are prohibited from deletion; ③ Modify parameters: After inputting the new value, first verify the data type and range (such as "temp_threshold_c" which needs to be an integer from 0 to 125), and update the JSON file after verification; ④ Query parameters: Support querying by module ("cfggethardware_interface") or single parameter ("cfggetalarm.cpu_threshold_pct"), returning the current value and default value of the parameter; 3. Syntax validation: The modified JSON file must pass syntax validation (by calling the "json_validate" function of the public module). If there are syntax errors (such as missing commas or mismatched quotation marks), the file will be rejected and the error location will be returned (such as "line 10 is missing a right parenthesis"), while the original configuration file will be retained. Real-time activation mechanism: 1. Parameter Synchronization: After configuration is modified and saved, the configuration management module pushes the new parameters to the corresponding module sub-thread via IPC message queue according to the "module-parameter" mapping relationship. ① “uart_baud” → Hardware interface module + AT command module; ②“temp_threshold_c” → Device Management Module + Alarm Management Module; ③ "dns_primary" → Network management module; After each module's sub-thread receives the data, it immediately updates the internal parameter variables (without restarting the sub-thread). For example, the hardware interface module updates the UART serial port baud rate to the new value, and all subsequent AT command transmissions and receptions use the new baud rate. 2. Activation Feedback: After the module sub-thread updates the parameters, it returns a confirmation signal of "Parameter [XXX] Activated successfully". The configuration management module records the modification log (format: timestamp + operator + module. parameter + old value + new value + result). If no feedback is received within 1 second, the activation is deemed to have failed, triggering a "Configuration activation failed" alarm, prompting the operation and maintenance personnel to check the module status. Security Guarantee: 1. Encrypted storage: The configuration file is stored using the AES-128 encryption algorithm. The encryption key is read through the secure storage unit of the hardware interface module (such as ARMTrustZone) to prevent the key from being illegally obtained. During decryption, the configuration management module obtains the key through the hardware interface module, and loads the parameters into memory after decryption. 2. Encrypted transmission: When remotely modifying the configuration (WEB proxy module), data is transmitted via HTTPS protocol (TLS 1.2 encryption implemented based on the OpenSSL library) to prevent theft or tampering during transmission; 3. Operation Audit: All configuration operations (CRUD operations) are recorded in audit logs, including the operator, operation time, IP address, operation content, and result. The logs are immutable and stored in the audit partition of FLASH ( / dev / mtdblock3), and retained for 180 days for maintenance personnel to trace illegal operations.

[0060] (2) Upgrade Management Module – Software Iteration "Upgrade Officer" like Figure 11 As shown, the upgrade management module includes the processes of receiving upgrade packages, verifying upgrade packages, executing upgrades, and verifying upgrades: Upgrade package receiving: 1. Receive trigger: "version query" request format is {"current_version":"V2.1","device_id":"SAT-202405001","platform":"ARM-Linux"}, if there is a higher version (such as V2.2) on the remote platform, trigger the upgrade package push; 2. Receive process: the upgrade package is in.tar.gz compressed package (including 14 new binary files, configuration update script update.sh, version information file version.info), received by IP communication module TCP connection block (2MB per block), real-time calculation of MD5 value during receiving process; after receiving is completed, the upgrade package is temporarily stored in / tmp / update directory to avoid occupying FLASH core partition space; 3. Integrity check: read the version.info file (records target version, compatible platform, MD5 value) in the upgrade package, compare the locally calculated MD5 value with the recorded MD5 value in the file, consistent then determine the receiving is complete, inconsistent then delete the temporary package and request to resend, more than 3 times of failure to resend then trigger "upgrade package receiving failure" alarm.

[0061] Upgrade package verification: 1. Compatibility check: parse the version.info file and verify two compatibilities: ① Platform adaptation: confirm that the "platform" field is "ARM-Linux", consistent with the current terminal platform; ② Version compatibility: confirm that the current version (such as V2.1) is in the "compatible_versions" list (such as ["V2.0", "V2.1"]), if the current version is V1.9, then determine incompatible, refuse to upgrade and record "version incompatible" log; 2. Content verification: decompress the upgrade package to / tmp / update / unpack directory, check whether it contains all required files: ① 14 binary files of modules (such as libstart.so "start management module", libhwif.so "hardware interface module"); ② Executable update.sh script (permission needs to be 755); ③ rollback.sh rollback script (used for recovery when upgrade fails); missing any file will be determined as upgrade package damaged, discarded and request to resend.

[0062] Upgrade execution flow: 1. Pre-upgrade backup: Before performing the upgrade, backup the core file of the current software to the upgrade backup partition of FLASH ( / dev / mtdblock4): ①Backup the binary files of 14 modules to / dev / mtdblock4 / backup / lib; ②Backup the current JSON configuration file to / dev / mtdblock4 / backup / spark_app_cfg.json; ③Backup the log file before the upgrade to / dev / mtdblock4 / backup / logs.tar.gz; After the backup is completed, verify the integrity of the backup file to ensure that it can be restored normally when rolling back; 2. Execute the upgrade script: Run the / tmp / update / unpack / update.sh script, and the script performs the upgrade in the order of "basic support class → business interaction class → operation and maintenance class": ①Stop the sub-thread of the module to be upgraded (such as stopping other modules outside the startup management module first to avoid resource occupation); ②Replace the old binary file (copy the new file from / tmp / update / unpack / lib to / usr / lib / sat_app directory, overwrite the old file); ③Update the configuration (if update.sh contains configuration adjustment instructions, such as adding the "wifi_ssid" parameter, then automatically modify the JSON configuration file); ④Restart the module sub-thread (re-launch the sub-thread of each module in the order of startup); 3. Progress feedback: During the upgrade process, after completing the upgrade of each module, feedback the progress to the WEB proxy module through the IPC message queue (such as "Upgrade progress: 30%, completed public module, hardware interface module upgrade"), and the WEB page displays the progress bar and the current operation in real time, which is convenient for operation and maintenance personnel to monitor; Upgrade verification and rollback: 1. Upgrade verification: After all modules are upgraded, perform three verifications: ①Version verification: Call the "version query" interface of each module (such as get_module_version("hwif")), confirm that all modules have been updated to the target version (V2.2); ②Function verification: Send test instructions (such as sending "AT+TEST?" through the AT command module, and collecting temperature through the device management module), verify the normality of core functions; ③Stability verification: Monitor for 10 minutes to observe whether each sub-thread is alive and there is no memory leakage (monitor the memory changes through / proc / meminfo); 2. Rollback mechanism: If any verification fails (e.g., a module version is not updated, a function test is not responsive), immediately perform rollback: ① Run the / tmp / update / unpack / rollback.sh script to stop all module sub-threads; ② Restore old binary files and configuration files from the backup partition; ③ Restart each module sub-thread to restore to the pre-upgrade version (V2.1); After rollback is complete, send an "upgrade failed, rolled back to V2.1" alarm to the remote platform and record the failure reason (e.g., "AT command module new binary file execution error: segment error"); 3. Upgrade success ending: After verification, delete the temporary files in the / tmp / update directory, update the / etc / sat_app_version file (record the current version as V2.2), send an "upgrade successful, current version V2.2" log to the log management module, and notify the operation and maintenance personnel through the WEB proxy module that the upgrade is complete.

[0063] (3) Alarm management module - abnormality monitoring "sentinel" Implement the "trigger-storage-push" whole process of hierarchical alarm to ensure that abnormalities are discovered and handled in a timely manner. Details are as follows: Alarm level and type definition: 1. Level division: ① Emergency alarm (red, highest priority): such as hardware offline (voltage module unresponsive), software overall crash (main process exception), FLASH storage failure; ② Important alarm (orange, medium priority): such as network link interruption, CP side connection failure, upgrade failure; ③ General alarm (yellow, lowest priority): such as AT command timeout, WiFi connection exception, log upload failure; 2. Type definition: 20 types of alarms are preset, each type corresponds to a unique code (e.g., 0x01 = hardware initialization failure, 0x02 = CPU overload, 0x03 = network configuration failure), and the alarm type and code mapping relationship is stored in the "alarm_type_map" field of the configuration management module. Support adding custom alarm types (e.g., 0x21 = custom sensor exception) through the WEB proxy module.

[0064] Alarm triggering mechanism: 1. Active reporting: When an exception is detected by a module sub-thread, an alarm request is sent through the IPC message queue. The request format is {"level":"emergency","type_code":0x01,"module_id":"hwif","content":"voltage module unresponsive","timestamp":"20240520164500","detail":"no response after sending initialization instruction 0x01 for 100ms"}; for example, when the hardware interface module detects that the voltage module is unresponsive, an emergency alarm is immediately reported; 2. Active detection: The alarm management module performs global detection every 2 seconds: ① Sub-thread survival detection: Get the PIDs of the 14 module sub-threads from the main process, and determine whether they are alive by kill-0$PID. If a sub-thread PID does not exist, trigger an "abnormal exit of module sub-thread" alarm (important level); ② Hardware parameter detection: Read the temperature, CPU / memory usage from the device management module. If the temperature is ≥85°C, trigger an "hardware overheating" emergency alarm, and if the CPU is ≥90%, trigger a "CPU overload" important alarm; ③ Network status detection: Read the link status from the network management module. If the link is interrupted, trigger an "network link exception" important alarm; Alarm storage and display: 1. Local storage: Store alarm information in the format of "timestamp_alarm level_type code.json" to the alarm partition of FLASH ( / dev / mtdblock3), such as 20240520164500_urgent_0x01.json. The storage content includes the complete alarm request field. At the same time, maintain an "unhandled alarm list" in memory, which is updated in real time with unprocessed emergency / important alarms for quick query; 2. Local display: Control the alarm LED light to display the alarm level through the device management module: ① Emergency alarm: Red LED always on; ② Important alarm: Red LED 1Hz flicker; ③ General alarm: Yellow LED 1Hz flicker; At the same time, support inputting "alarmshowunhandled" through the CLI command line module to view unhandled alarms. The output format is "timestamp|level|type|module|content", such as "20240520164500|urgent|hardware initialization failure|hardware interface module|voltage module unresponsive"; Alarm pushing and processing: 1. Remote pushing: Push alarm information to the remote operation and maintenance platform through the IP communication module, supporting two pushing protocols: ① HTTP protocol (default): push address is the "alarm_push_url" parameter of the configuration management module (such as https: / / ops.example.com / alarm / receive), and the push data format is JSON; ② MQTT protocol (optional): connect to a remote MQTT server (address / port set through configuration), publish to the "satellite / alarm" topic; push strategy: emergency alarm real-time push (retry every 10 seconds for a total of 10 times after failure), important alarm batch push within 5 minutes, general alarm batch push within 30 minutes; 2. Alarm elimination: two elimination methods are supported: ① Automatic elimination: after the alarm trigger condition disappears (such as network link recovery, CPU utilization drops below 90%), the alarm management module automatically marks the alarm as "eliminated" and pushes a "alarm elimination" notification to the remote platform; ② Manual elimination: the operation and maintenance personnel find the uneliminated alarm through the WEB proxy module, click the "confirm elimination" button, input the processing remarks (such as "replace the voltage module"), the system records the elimination person, time and remarks, and completes the alarm closed loop; Alarm threshold configuration: 1. Dynamic adjustment: modify the alarm threshold parameters through the configuration management module (such as changing "temp_threshold_c" from 85℃ to 80℃ and "cpu_threshold_pct" from 90% to 85%), the parameters take effect immediately after modification, without the need to restart the alarm management module; for example, after lowering the CPU overload threshold, the alarm management module will immediately judge whether to trigger an alarm based on the new threshold when it detects next time; 2. Threshold linkage: some alarm thresholds have linkage relationships, which are automatically synchronized when modified: for example, when "signal_threshold_dbm" (antenna signal strength threshold) is modified, it is automatically synchronized to the signal judgment logic of the antenna control module, ensuring that the alarm trigger is consistent with the module function judgment standard.

[0065] (4) Log management module - problem trace "archive" Realize the "collection-storage-operation" whole process of multi-source logs, support CP side signaling log receiving and WEB side operation, details as follows: Log collection: 1. Module running log: Receive the running log sent by the 14 module sub-threads through the IPC message queue, and the log format is "timestamp (YYYYMMDDHHMMSSfff) | module ID (2-byte hexadecimal) | log level (DEBUG / INFO / WARN / ERROR) | log content", for example "20240520165000123 | 0x02 | INFO | Public module tool function library loading completed"; When each module sends a log, the timestamp and module ID are automatically filled in, and manual splicing is not required; 2. CP-side signaling log: Receive the signaling log sent by the CP side through the UDP broadcast interface (bind port 60500, receive buffer 16KB) of the ARM architecture Linux, and the log format is "timestamp | CP module ID (such as 0x01 = physical layer) | signaling type (such as 0x0A = cell search) | signaling content (hexadecimal string)", for example "20240520165005 | 0x01 | 0x0A | 0x12345678"; After receiving, perform CRC32 verification (the verification value is carried at the end of the signaling content), and if the verification fails, discard and record an "CP-side signaling log verification failed" ERROR-level log; 3. Operation log: Record all operation and maintenance operations: ① WEB proxy module operation (such as configuration modification, log upload, upgrade triggering), record the operator account, IP address, and operation content; ② CLI command line module operation (such as state query, peripheral control), record the operation terminal IP, command content; The operation log format is "timestamp | operation source (WEB / CLI) | operator | operation content | execution result (success / failure)", for example "20240520165500 | WEB | admin | modify alarm.temp_threshold_c = 80 | success"; Log storage: 1. Local storage strategy: Append the log to the log partition of the FLASH ( / dev / mtdblock4, capacity 64MB) through the "append_FLASH" interface of the hardware interface module, and divide the storage area according to the log level: ① ERROR-level log: stored independently in / dev / mtdblock4 / error directory, retained for 30 days; ② WARN-level log: stored in / dev / mtdblock4 / warn directory, retained for 14 days; ③ INFO / DEBUG-level log: stored in / dev / mtdblock4 / info_debug directory, retained for 7 days; The log file is divided by day (such as 20240520_error.log), to avoid a single file being too large; 2. Hierarchical storage extension: If the terminal is equipped with an SD card (whether the SD card is mounted is detected by the hardware interface module), the INFO / DEBUG level logs are automatically synchronized to the / sdcard / sat_logs directory of the SD card, which is retained for 90 days to release the pressure on the FLASH storage; the synchronization frequency is once every 30 minutes, and if the synchronization fails, a "SD card log synchronization failure" WARN level log is recorded; Log operation and maintenance functions: 1. Log query: only WEB proxy module is supported for query, and multiple condition combination filtering is provided: ① Time range (e.g. 2024052016:00-17:00); ② Module ID (select from the drop-down menu, e.g. 0x03 = AT command module); ③ Log level (multiple selection, e.g. ERROR / WARN); ④ Keyword (e.g. "voltage module"); the query result is displayed in table form, supports ascending / descending order sorting by timestamp, and provides "export as TXT" function (packaging query result as.txt file for download); CLI command line module query is not supported to avoid local operation occupying CPU / memory resources; 2. Log upload: both manual and automatic upload methods are supported: ① Manual upload: the operation and maintenance personnel select the log level and time range on the WEB page, click the "Upload" button, and the log management module packs the corresponding logs into a.tar.gz file (split by 200MB), which is uploaded to the remote address specified by the "log_upload_url" parameter of the configuration management module through the HTTPS protocol; ② Automatic upload: INFO / DEBUG level logs are uploaded at regular intervals according to the "log_remote_upload_interval_sec" parameter (default 3600 seconds / 1 hour) of the configuration management module, and ERROR / WARN level logs are uploaded in real time; after uploading, the "upload success" confirmation from the remote platform is received, and if not confirmed, it is retried 3 times; 3. Log cleaning: two cleaning methods are supported: ① Automatic cleaning: expired logs are automatically deleted according to the storage period (e.g. logs older than the retention period are deleted at 0:00 every day), and after cleaning, an "automatic log cleaning completed" INFO level log is recorded (including log level, number cleaned); ② Manual cleaning: the operation and maintenance personnel initiate a cleaning request through the WEB proxy module, and only INFO / DEBUG level logs are allowed to be cleaned (ERROR / WARN level logs are protected and cannot be manually deleted), a preview is displayed before cleaning (time range, file size, and number of logs to be cleaned), and an administrator password is required for confirmation before execution to avoid accidental deletion; Log security and collaboration: 1. Access Control: Log query, upload, and cleanup operations all require account authentication through the WEB agent module. Administrator accounts have full permissions, while ordinary operation and maintenance accounts can only query INFO / DEBUG level logs and do not have upload or cleanup permissions; operation logs are recorded throughout the process to ensure traceability. 2. Collaboration with the alarm module: When the alarm management module triggers an emergency / important alarm, it automatically generates an "alarm-related log package", which contains logs from relevant modules for 10 minutes before and after the alarm trigger (such as logs from the hardware interface module and AT command module associated with the "voltage module no response" alarm). The package is stored in the / dev / mtdblock4 / alarm_related directory and simultaneously uploaded to the remote platform, making it easier for maintenance personnel to quickly locate the root cause of the alarm. (5) WEB Agent Module – Remote Operation and Maintenance “Interaction Officer” UDP packet pass-through and page simplification: 1. Data Transmission Logic: When a web page initiates a real-time data query request (such as "get current antenna angle" or "query CPU utilization"), the web proxy module does not need to call the corresponding module (such as the antenna control module or device management module) in real time. Instead, it directly reads the pre-collected data from the memory cache and assembles it into UDP packets according to a preset format. The packet structure is defined as "parameter type (2 bytes) + data length (2 bytes) + normalized string (N bytes)". Example 1: Antenna angle query result message: Parameter type 0x05 (antenna angle) + data length 0x04 ("30°" in 4 bytes) + normalized string "30°"; Example 2: CPU utilization query result message: Parameter type 0x02 (CPU utilization) + data length 0x04 ("25%" in 4 bytes) + normalized string "25%"; 2. Simplified page design: The web page only needs to parse the standardized strings in the UDP packet, without performing complex logic such as data format conversion (e.g., binary to decimal) and multi-parameter correlation calculation; For example, after receiving the string "30°", it is directly displayed in the "Antenna Angle" field on the page, and after receiving "25%", it is directly filled into the "CPU Utilization" progress bar. The page response time is shortened from the traditional 500ms to less than 50ms, which greatly improves the efficiency of remote operation and maintenance.

[0066] Core functions of remote operation and maintenance: 1. Module Status Management: Displays the real-time status of each module on a web page ("Running" in green / "Abnormal" in red / "Not Loading" in gray), supporting: ①Module start / stop: Click the "start" / "stop" button, the WEB proxy module sends a control command to the main process through the IPC message queue, and the main process executes the child thread start / terminate operation, and the operation result is fed back to the page in real time; ②Dynamic loading / unloading: For modules that support dynamic expansion (such as the WEB proxy module itself and the CLI command line module), provide "load module" / "unload module" buttons. After uploading the module binary file (.so format), the operation is completed through the dlopen / dlclose function of ARM architecture Linux. After successful loading, the module state is updated to "running"; 2. Configuration parameter management: Provide a visual configuration interface to display all configurable parameters (such as UART baud rate of hardware interface module and temperature threshold of alarm management module) by module classification: ①Parameter modification: Modify the parameter value directly in the page input box / drop-down selection box (such as changing the UART baud rate from 9600 to 115200). After clicking "save", send it to the configuration management module through HTTPS protocol. The parameter takes effect in real time, and the page automatically refreshes to display the new value; ②Parameter reset: Provide the "restore default value" function. After clicking, the parameters are restored to the system default configuration (such as restoring the temperature threshold to 85°C), avoiding the inability to backtrack after mistaken modification; 3. Remote upgrade control: Display the current software version and the latest version of the remote platform on the WEB page, supporting: ①Upgrade trigger: Click the "check update" button. The WEB proxy module sends a version query request to the upgrade management module. If there is a new version, display the upgrade package information (version number, size, update content). Click "start upgrade" to trigger the upgrade process; ②Upgrade monitoring: Real-time display of upgrade progress (percentage), current operation (such as "backup old version" "upgrade AT command module"), and "one-key rollback" button when upgrade fails to trigger the upgrade management module to execute the rollback process; ③Upgrade record: Display historical upgrade records (upgrade time, target version, result, operator), and support to view upgrade logs (link to the upgrade-related logs of the log management module); Security and performance guarantee: 1. Account authentication and permission control: Adopt "username + password" dual authentication mechanism: ①Username and password storage: Passwords are stored in the FLASH secure partition after being encrypted by the SHA256 algorithm, and no plaintext is stored; ②Permission classification: Administrator accounts have all operation and maintenance permissions, and ordinary operation and maintenance accounts can only view status and query logs, without configuration modification and upgrade trigger permissions; 2. Data transmission encryption: All data exchanged between the web client and software modules (such as configuration modification commands, upgrade control signals, and log data) is transmitted in encrypted form via HTTPS protocol. The TLS 1.2 encryption algorithm is implemented using the OpenSSL library based on the ARM architecture Linux to prevent data from being stolen or tampered with during transmission. 3. Performance Optimization: Optimize web services to take advantage of the lightweight nature of the ARM platform. ① Use a lightweight version of Nginx (memory usage ≤10MB) to avoid resource overload; ②Preload static page resources (such as CSS, JS, and images) into the memory cache to reduce the number of Flash reads; ③ Limit the number of concurrent connections per IP (default ≤ 5) to prevent malicious requests from consuming bandwidth.

[0067] (6) CLI command-line module – local emergency "operation and maintenance officer" As a supplement to the WEB agent module, it provides local command-line operation and maintenance capabilities for scenarios with no network or abnormal WEB services, focusing on "emergency query and control", as detailed below: Command-line interface design: 1. Interactive Entry Point: Launched via an ARM architecture Linux terminal (such as bash, busyboxash), with the command-line prompt fixed at "sat_cli>", supporting: ① Command auto-completion: Enter the command prefix (such as "dev") and press the Tab key to automatically complete the relevant command (such as "devstatus" "devcontrol"); ② Syntax hints: If an incorrect command is entered (such as "devstat"), the system will return "Command does not exist, similar command: devstatus"; ③ Help information: Enter "help" or "-h" to display a list of all supported commands and brief descriptions (e.g., "devstatus: query device status"). 2. Command hierarchy: A three-level naming convention of "module abbreviation + function type + specific parameters" is adopted to simplify input complexity. Core commands are categorized as follows: Figure 12 As shown: 1. Implementation of core emergency response functions: Emergency Status Inquiry: Focus on critical operational data and avoid redundant queries. a. Module status query: Input “sysstatusmodule”, the output format is “Module ID (name): Status [PID]”, for example: “0x01 (Startup Management Module): Running

[1234] |0x03 (AT Command Module): Running

[1236] ”; b. Hardware status query: input "devstatus temp", output "Current hardware temperature: 75°C (threshold 85°C)"; input "devstatus antenna", output "Antenna angle: 30°, gain: 20dB, signal strength: -82dBm (threshold -90dBm)"; c. Network status query: input "netstatus ip", output "Current IP: 192.168.1.100, subnet mask: 255.255.255.0, gateway: 192.168.1.1"; 2. Emergency control of peripherals: provide basic control capabilities for key peripherals that affect terminal operation: a. Fan control: input "devcontrol fan 50%", CLI module sends control instructions to device management module through IPC message queue, returns "Fan speed has been set to 50%, current feedback speed: 2000RPM" after successful execution; b. LED control: input "devcontrol alarm off", return "Alarm LED has been turned off"; input "devcontrol run 1Hz", return "Run LED has been set to 1Hz flashing"; c. Module emergency restart: input "sys restart module at", send AT command module sub-thread restart instruction to main process, return "AT command module restart complete, new PID: 1567" after successful restart; 3. Emergency configuration viewing: only support viewing key configuration parameters, do not support modification (avoid local misoperation affecting system stability): input "cfg show uart baud", output "Current UART serial port baud rate: 115200bps (default 9600bps)"; input "cfg show alarm.temp_threshold", output "Current hardware temperature alarm threshold: 85°C (default 85°C)".

[0068] Emergency guarantee mechanism: 1. Permission control: when executing key commands such as module restart and peripheral control, administrator password needs to be input (password verification is valid for 10 minutes after verification, need to be re-input after timeout); after 3 times of password verification failure, CLI module is locked for 5 minutes to prevent unauthorized personnel from operating; 2. Operation restriction: strictly limit function boundary, do not support log query (avoid occupying CPU / memory), upgrade trigger (high risk), configuration modification (easy misoperation) and other resource-consuming or high-risk functions, ensure that emergency operation and maintenance capabilities can still be provided stably in extreme scenarios (such as WEB proxy module exception, memory shortage); 3. Operation log: All CLI command operations are recorded in the operation log of the log management module, in the format "timestamp | operation source CLI | operator admin | command sysrestartmoduleat | result success", to facilitate subsequent tracing of local operation behavior.

[0069] The core application scenarios of the application include fields with high requirements for terminal software lightweight, hardware compatibility, and remote operation efficiency, including but not limited to civilian emergency communication terminals (such as earthquake and flood disaster site communication equipment), aerospace satellite data terminals (such as unmanned aerial satellite communication modules and spacecraft data transmission terminals), and ocean communication terminals (such as ocean ship satellite communication equipment).

[0070] The technical solution will be introduced in detail through a specific embodiment.

[0071] The application is suitable for ocean scenarios (such as ocean freighter satellite communication terminals), which need to solve the following problems: ① Interface instability problem caused by hardware corrosion in high salt mist environment; ② Log local caching and later transmission needs under long-term offline (no ground network) of freighters; ③ Antenna signal fluctuation compensation problem caused by ship pitching.

[0072] The implementation process will be described in detail in combination with the scenario to improve the scenario coverage of the solution.

[0073] Implementation scenario: ocean scenario (ocean freighter satellite terminal) Core requirements of ocean scenario: ① Hardware interface corrosion resistance adaptation (salt mist environment easily causes SPI / I2C interface contact failure, interface verification needs to be strengthened); ② Offline log caching (no ground network when freighters cross the ocean, logs need to be cached locally for ≥30 days); ③ Antenna signal fluctuation compensation (ship pitching causes antenna angle deviation, gain needs to be automatically adjusted).

[0074] Hardware configuration of this embodiment: ARM Cortex-A72 architecture (1.5 GHz, industrial-grade corrosion-resistant design), Linux 5.10 kernel, supporting hardware: marine reinforced antenna (model: MAR-6G, angle adjustment range 0-90°, anti-pitching), industrial-grade temperature / humidity sensor (SHT30, anti-salt mist), large-capacity FLASH (512 MB, supporting long-term log storage).

[0075] Implementation steps: scenario adaptation and function landing (1) Hardware interface module corrosion resistance adaptation For the problem of unstable interface in salt spray environment, the hardware interface module needs to strengthen communication verification and fault retry mechanism: Parameter pre-set: add anti-interference parameters in the configuration management module JSON file; Interface verification implementation: SPI interface: After each data transmission, an additional 4-byte CRC32 check value is sent, and when the receiving end verification is inconsistent, a retry is triggered (up to 5 times), and if the retry fails, the backup SPI interface is switched to (the cargo ship terminal reserves 2 SPI interfaces, and the main and backup switching time is ≤200ms); I2C interface: For SHT30 sensor data acquisition, a "double reading comparison" mechanism is used (reading data twice in succession, with a deviation of ≤0.5℃ / 5%RH being valid), to avoid single reading errors caused by salt spray; Hardware protection: After enabling the "salt_fog_protect" mode, the hardware interface module sends an "interface detection" command (such as SPI interface sending 0xAA detection frame) every hour to detect interface connectivity, and triggers a "hardware interface exception" alarm (important level) when abnormal.

[0076] (2) Antenna control module roll compensation Ship roll causes antenna angle deviation (maximum ±5°), which needs to be automatically adjusted to compensate for signal loss, and the implementation process is as follows: Signal fluctuation detection: The antenna control module receives signal strength data (such as -88dBm) from the antenna every 100ms, calculates the fluctuation amplitude (such as ±3dBm) of the last 10 data, and determines that it is "signal fluctuation caused by roll" when the fluctuation amplitude is ≥2dBm; Compensation logic execution: Angle fine tuning: Send "angle compensation" command (such as current angle 30°, compensation +2° to 32°) through UDP message, and add "roll level" field (0-2 levels, 2 for severe roll) to the message; when severe roll occurs, enable "fast adjustment" mode (adjustment interval is shortened from 500ms to 200ms); Gain compensation: When signal strength decreases by 1dBm, automatically increase gain by 1dB (such as from 22dB to 24dB), to ensure that signal strength is stable above -85dBm; if the gain reaches the upper limit (30dB) and still cannot be compensated, trigger an "antenna signal weak" emergency alarm to notify the crew to manually adjust the antenna installation position; State feedback: After compensation is completed, the adjustment results (angle 32°, gain 24dB, signal strength -83dBm) are synchronized to the device management module, and "antenna roll compensation success" INFO level log is recorded.

[0077] (3) Log management module offline cache and retransmission Cargo ship transoceanic voyage (up to 15 days without ground network), the log needs to be cached locally and transmitted after the network is restored. Implementation process: Offline cache configuration: Set log cache strategy in configuration management module; Offline cache execution: Hierarchical cache: ERROR / WARN level logs are stored in FLASH (512MB), and INFO / DEBUG level logs are stored in external SD card (32GB, salt spray resistant industrial grade), to avoid FLASH capacity shortage; File segmentation: Log files are segmented by 10MB (such as 20240520_info_01.log), which facilitates later block transmission, and "cache identifier" is added to the segmented file (such as file header adds 0x01 identifier for "to be transmitted"); Network recovery transmission: After the cargo ship approaches the port and restores the network (core network IP is detected to be reachable through the network management module), the log management module executes: Cache scanning: Scan "to be transmitted" log files in FLASH / SD card, generate transmission list (including file size, creation time); Block transmission: Upload in "ERROR first, then INFO" order through IP communication module (2MB per block), and mark the file as "transmitted" after uploading (change file header to 0x02); Continuation of transmission: When the transmission is interrupted (such as temporary network interruption), record the uploaded block number, and continue uploading from the breakpoint when the network is restored, to avoid repeated transmission.

[0078] Multi-module collaborative business: cargo ship remote monitoring data transmission Ocean cargo ships need to transmit "ship state data" (temperature, humidity, cargo hold pressure) to the ground station, which involves multi-module collaboration. Implementation process: Data collection: Device management module collects SHT30 sensor data (temperature 25℃, humidity 60%RH) through I2C interface and cargo hold pressure sensor data (101kPa) through SPI interface, every 5 minutes; Data encapsulation: Device management module encapsulates data into JSON format: {"timestamp":"20240520203000","temp":25,"humidity":60,"cabin_pressure":101}, and sends it to IP communication module through IPC message queue; Data forwarding: After receiving the data, the IP communication module encapsulates it according to the TCP protocol (target IP: ground station 192.168.3.100:10005). Considering the limited bandwidth of the ocean network (≤512kbps), the "data compression + batch sending" mechanism is adopted (compressed data is sent in batches every 30 minutes, with a compression rate of ≥60%). State monitoring: The network management module monitors the TCP connection status in real time and triggers the "data transmission interruption" alarm when the connection is interrupted. At the same time, it notifies the IP communication module to cache the data locally (to be transmitted later when the network is restored). Log recording: Throughout the process, the log management module records the "data collection-encapsulation-forwarding" whole link log, including data size, transmission time, and success or failure, which facilitates the later tracing of data loss problems.

[0079] Ocean scene fault simulation and emergency handling Fault: I2C interface salt spray corrosion interruption (1) Fault trigger By simulating the SHT30 sensor I2C interface contact failure (communication success rate ≤50%), the interface failure caused by salt spray corrosion is simulated.

[0080] (2) Emergency handling process Fault detection: When the device management module reads SHT30 data, it still fails after 5 consecutive retries (I2C retry count is configured as 5), triggering the "I2C interface communication interruption" alarm (important level), notifying the hardware interface module; Interface switching and recovery: After receiving the alarm, the hardware interface module automatically switches to the backup I2C interface (2 I2C interfaces are reserved on the cargo ship terminal), reinitializes the interface parameters (address 0x44, rate 400kHz), and the switching time is 180ms; Data recovery: After the backup interface is restored, the device management module recovers the last 3 missing temperature / humidity data (based on historical data trend estimation, error ≤1℃ / 10%RH), avoiding data link interruption; Operation and maintenance notification: The WEB proxy module pushes the "I2C interface switched to backup, main interface needs maintenance" notification to the cargo ship central control system, prompting the crew to replace the main interface connector after docking.

[0081] Fault: Log recovery timeout after long offline (1) Fault trigger After simulating the cargo ship offline for 15 days and restoring the network, the log recovery is timed out (default 300 seconds) due to the bandwidth limitation of the ground station (≤256kbps) and the single log file (10MB).

[0082] (2) Emergency handling process Timeout detection: The log management module detects that the upload is timed out, automatically splits the file into smaller blocks (from 2MB to 512KB), and reduces the upload pressure of a single block; Priority adjustment: The priority of the ERROR level log is raised to the highest, and the upload of the INFO / DEBUG level log is suspended to ensure the transmission of the fault related log; Breakpoint resume: The progress is recorded once for every 1 block uploaded, and the next block after the uploaded block is continued after timeout to avoid repeated transmission; Local backup: If the network is interrupted again during the retransmission, the log management module retains the "unuploaded" mark, and continues the retransmission when the network is recovered next time, ensuring that there is no loss of logs within 30 days.

[0083] Implementation verification results of marine scenarios The function verification is as shown in Figure 13 The performance verification is as shown in Figure 14 .

[0084] Implementation summary In combination with the implementation verification of the above scenarios, the modular design of the application has the following core values: Strong scene adaptability: For special requirements (low power consumption, salt spray resistance, and anti-interference) of different scenarios, only 10%-20% of configuration parameters and local logic of the module (such as hardware interface verification and log cache strategy) need to be modified, which can be quickly migrated, and the adaptation cycle is ≤3 days; High fault tolerance: Through mechanisms such as "primary and backup interface switching", "independent restart of sub-thread", and "log breakpoint resume", the recovery time of a single module / hardware failure is ≤200ms, and the overall software has no risk of crashing, meeting the high reliability requirements of key scenarios; Optimal resource controllability: The memory occupation under ARM architecture is ≤35MB, the FLASH occupation is ≤64MB, supporting lightweight deployment, and can be expanded to large capacity storage (such as SD card cache in marine scenarios) through configuration; Low operation and maintenance cost: Remote WEB operation and maintenance + local CLI emergency operation and maintenance cover all scenarios, offline log retransmission, low bandwidth adaptation and other designs greatly reduce the number of on-site operation and maintenance (such as reducing the number of on-site operation and maintenance of ocean cargo ships from 4 times to 1 time per year).

[0085] In summary, the application can be widely applied to multiple scenarios of satellite communication terminals, solving the core problems of traditional software "difficult to adapt, fragile to failure, and expensive to operate and maintain", and having significant industrialization and commercialization value.

[0086] The foregoing is considered as illustrative only of the principles of the application. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the application to the exact construction and operation described. Accordingly, all such variations are intended to be included within the scope of the present application as defined in the claims below and their equivalents.

Claims

1. A satellite communication terminal application software modular design method, suitable for ARM architecture Linux platform, characterized in that, The method comprises the following steps: S1: function module splitting: based on the underlying running characteristics of the ARM architecture Linux platform and the core business requirements of the satellite communication terminal, the software is split into 14 modules, and is divided into three categories according to the responsibilities: basic support type, business interaction type and operation and maintenance type; S2: running architecture construction: the software running architecture of "main process + multiple sub-threads" is constructed: the system resource initialization of the ARM architecture Linux platform is completed through the main process; after the main process initialization is completed, the independent sub-threads corresponding to the 14 modules are respectively started; S3: standardized interface configuration: the standardized interfaces suitable for the underlying calling specifications of the ARM architecture Linux platform are configured for the 14 modules, and the modules realize data interaction through the standardized interfaces; at the same time, the hardware driver calling logic under the ARM architecture Linux platform is abstracted, and the universal tool functions are combined to realize the compatible adaptation of the application software to different types of satellite communication terminal hardware; S4: establishment of running guarantee mechanism: the running states of the sub-threads are monitored in real time, and the running logs of the modules are recorded; when any sub-thread appears abnormal, the main process triggers the fault restart mechanism to independently restart the abnormal sub-thread.

2. The design method according to claim 1, wherein: in the S1, the basic support type includes a startup management module, a public module and a hardware interface module; the business interaction type includes an AT command module, an antenna control module, an IP communication module, a device management module and a network management module; the operation and maintenance type includes a configuration management module, an upgrade management module, an alarm management module, a log management module, a WEB proxy module and a CLI command line module; and all the modules only interact through the standardized interfaces.

3. The design method according to claim 1, wherein: in the S2, the main process: assumes the role of a dispatching center, is responsible for three core tasks: system resource initialization, including CPU priority configuration, memory allocation according to 4KB pages and hardware driver loading; sub-thread life cycle management, including priority pulling, 100ms period state monitoring and abnormal automatic restart; and cross-module communication coordination, including maintaining the IPC message queue index, not participating in specific business logic and avoiding main process overload; and the sub-thread: 14 modules each correspond to an independent sub-thread, is created based on the pthread library of the ARM platform and supports: dynamic loading and dynamic unloading; abnormal independent recovery: when the sub-thread exits, the main process is reconstructed through the fork function, and the recovery time is less than or equal to 500ms; resource isolation: each sub-thread is allocated an independent memory space; and cooperative mechanism: IPC communication is realized through "message queue + shared memory": short data uses the message queue, and long data uses the shared memory.

4. The design method according to claim 2, wherein: in the S3, two types of interface specifications are formulated: hardware interface specification and module interface specification. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ Hardware interface specification: hardware interface module encapsulates 5 types of standardized interfaces, all of which comply with the ARM architecture Linux driver framework: including hardware initialization interface, FLASH drive interface, I2C interface, SPI interface and UART serial interface; Module interface specification: define a unified data interaction format.

5. The design method of claim 1, wherein: In S4, a "monitoring-recording-recovery-operation and maintenance" whole-process guarantee system is constructed: Monitoring: the alarm management module monitors the sub-thread state and hardware parameters in real time, and triggers three-level alarms; Recording: the log management module collects module running logs and CP side UDP broadcast signaling logs, and stores them locally and uploads them remotely via WEB; Recovery: the main process automatically restarts abnormal sub-threads, the configuration management module saves parameters after power failure, and the upgrade management module supports failure rollback; Operation and maintenance: the WEB proxy module realizes remote configuration / log / upgrade, the CLI command line module supports local emergency operation, and covers all-scenario operation and maintenance requirements.

6. The design method of claim 2, wherein: The startup management module triggers the initialization process of the application software after the ARM architecture Linux platform is started, wakes up other modules in the preset priority order, and checks the initialization state of each module. If a module fails to initialize, the alarm management module sends an initialization failure alarm; The priority order is: "basic support type→ business interaction type→ operation and maintenance type", and the specific order is: The first batch: public module→ hardware interface module; The second batch: AT command module→ antenna control module→ IP communication module→ device management module→ network management module; The third batch: configuration management module→ upgrade management module→ alarm management module→ log management module→ WEB proxy module→ CLI command line module.

7. The design method of claim 2, wherein: The public module provides general tool functions for 14 modules under the ARM architecture Linux platform, including data processing function library, resource management function library and error handling function library.

8. The design method of claim 2, wherein: The hardware interface module is an intermediate layer between software and hardware, which abstracts the driving logic through 5 types of standardized interfaces, including hardware initialization interface, FLASH drive interface, I2C interface, SPI interface and UART serial interface; The hardware initialization interface is used to complete the power-on detection, register configuration and initialization state feedback of the satellite communication terminal hardware when the application software is started; The FLASH drive interface is used to realize the read-write control of the FLASH memory chip, and supports power failure storage and reading of configuration parameters and log data; The I2C interface and SPI interface are used for data interaction with sensors and peripheral chips in the satellite communication terminal; The UART serial interface is used to adapt to the serial communication requirements of the AT command module, and provides a standardized serial data transmission channel.

9. The design method of claim 2, wherein: The AT command module: based on the UART serial port of the hardware interface module, realizes the whole process of "receiving-framing-sending-parsing-distributing" of AT commands, after receiving the AT command request of other modules, the AT command module encapsulates the command frame according to the preset format and sends it to the satellite communication terminal hardware through the UART serial port interface of the hardware interface module, at the same time, receives the response frame returned by the hardware and completes the frame disassembly and analysis, and feeds back the analysis result to the request module; for the preset type of AT command execution result, the AT command module sends it to the sub-thread of other modules by unicast or multicast mode, if the response frame is abnormal, the log management module is triggered to record the abnormal information.

10. The design method of claim 2, wherein: The antenna control module: calls the antenna driver through the SPI interface of the hardware interface module, establishes an interactive channel with the antenna based on the UDP protocol, and realizes the transmission of instructions for adjusting the angle of the antenna, controlling the signal gain and detecting the state; After receiving the external control instruction, the antenna control module generates the corresponding UDP control message, sends it to the antenna hardware through the standardized interface, receives the UDP state message fed back by the antenna, analyzes the real-time data of the signal strength and connection state, and feeds back to the device management module.

11. The design method of claim 2, wherein: The IP communication module: based on the TCP / IP protocol stack of the ARM architecture Linux platform, establishes a communication connection with the adjacent CP hardware, and builds a data transmission and message forwarding channel for satellite communication; After receiving the request of the demand module, the IP communication module encapsulates the data packet according to the protocol specification and forwards it to the target CP hardware through the network interface, receives the data packet sent by the CP hardware, unpacks it and distributes it to the corresponding module; the IP communication module supports data fragmentation transmission, retransmission mechanism and flow control, and does not involve the processing of CP side business logic.

12. The design method of claim 2, wherein: The device management module: used for managing the hardware device information and system resource state of the satellite communication terminal, the hardware device information includes device model, hardware version and running time, the system resource state includes temperature, CPU occupancy and memory occupancy; The device management module collects sensor data through the I2C interface or SPI interface of the hardware interface module, stores the information in the database of the configuration management module regularly, supports the control logic of fan, LED and WiFi, can receive external control instructions and execute actions on the corresponding hardware through the hardware interface module; The device management module also supports querying device information and system resource state through the CLI command line module or WEB proxy module.

13. The design method of claim 2, wherein: The network management module: monitors the network connection state under the ARM architecture Linux platform, including network link on-off, IP address configuration and gateway state, receives the message sent by the AT command module sub-thread, and completes the dynamic configuration of the data communication route based on the IP address and route parameter information issued by the core network carried in the message; If the network link is disconnected, the network management module triggers the reconnection mechanism, and sends a network exception alarm through the alarm management module; the network management module also supports dynamic modification of network parameters through the configuration management module.

14. The design method of claim 2, wherein: The configuration management module: uses a JSON format configuration file to store all configuration parameters of the application software, and the configuration parameters include module running parameters, hardware adaptation parameters and network configuration parameters; The configuration management module realizes power failure saving of the configuration file through the FLASH drive interface of the hardware interface module, and supports add, delete, modify and query operations on the JSON configuration file.

15. The design method of claim 2, wherein: The upgrade management module: receives a remote upgrade package through the IP communication module, and checks the integrity and compatibility of the upgrade package based on the version information of the ARM architecture Linux platform; if the check is passed, the upgrade management module upgrades each module in a predetermined order, records the upgrade progress through the log management module during the upgrade process, and if the upgrade fails, triggers a rollback mechanism to restore to the previous version and sends an upgrade failure alarm.

16. The design method of claim 2, wherein: The alarm management module: defines alarm levels, classifies and stores alarm information received from each module according to the levels, and pushes the alarm information to a remote operation and maintenance platform through the IP communication module or the serial port; the alarm management module also supports dynamic configuration of alarm thresholds through the configuration management module.

17. The design method of claim 2, wherein: The log management module: is used to realize the whole process of "collection-storage-operation and maintenance" of multi-source logs, supports CP side signaling log reception and WEB side operation and maintenance, and specifically: Records the running logs of each module, including module startup logs, data interaction logs, exception logs and operation logs; Receives the signaling logs sent by the CP side through UDP broadcast, and stores the signaling logs in the local storage unit after format verification; Supports hierarchical storage and log filtering of logs, and only realizes uploading and downloading operations of logs through the WEB proxy module, without uploading and downloading logs through the CLI command line module; The log format is adapted to the log analysis tool of the ARM architecture Linux platform.

18. The design method of claim 2, wherein: The WEB proxy module: constructs a WEB management interface, supports remote operation and maintenance personnel to access through a browser; collects information required by a WEB page in advance, stores the information into a memory of an ARM architecture Linux platform or a lightweight SQLite database; and performs UDP packet transmission processing on information required by the WEB page, converts complex data into a standardized string format, and then transmits the data to the WEB page.

19. The design method of claim 2, wherein: The CLI command line module: provides a command line interactive interface, supports operation and maintenance personnel to input commands through a serial port or a remote terminal; The CLI command line module supports command automatic completion and syntax checking, the command execution result is fed back through a standardized format, and the command operation log is recorded to the log management module.

Images