Search

CN-121996212-A - Spacecraft star software App software platform architecture design method based on Lua

CN121996212ACN 121996212 ACN121996212 ACN 121996212ACN-121996212-A

Abstract

The invention discloses a method for designing an App software platform architecture of spacecraft star software based on Lua, by embedding the Lua interpreter in the star software, a star-loaded App running environment supporting on-orbit dynamic loading and hot updating is constructed. The method mainly comprises six parts of Lua interpreter transplanting and cutting, star software and Lua interpreter interface definition and realization, app code uploading management, app storage management, lua virtual machine and App memory management and App running management. The invention greatly improves the adaptability and expansibility of the system and enhances the autonomous operation capability of the spacecraft under the unattended condition.

Inventors

  • LIU GUANGHUI
  • SHI LIWEN
  • ZHANG HAO
  • ZHOU JUN

Assignees

  • 西北工业大学

Dates

Publication Date
20260508
Application Date
20260115

Claims (10)

  1. 1. A spacecraft star software App software platform architecture design method based on Lua is characterized by comprising the following steps: step 1, transplanting and cutting of a Lua interpreter; Transplanting the Lua interpreter source code into a star service operation system, and reserving and cutting the Lua interpreter source code according to the requirements of the satellite-borne software on resources, reliability and functions; Step 2, defining and realizing interfaces of the star software and the Lua interpreter; opening an interactive interface between the Lua interpreter and the star software, and defining and realizing two interfaces of data and functions; Step 3, app code uploading management; Uploading an App code to a spacecraft by using breakpoint continuous transmission through a remote control data injection instruction during the overtaking period of the spacecraft; Step 4, app code storage management; the method comprises the steps of safely storing an App code into a special storage area preset by an NVRAM external memory; Step 5, lua virtual machine and App memory management; replacing a dynamic memory allocation mechanism defaulted by the Lua interpreter by a controlled allocation mode based on a pre-allocation memory pool by constructing a static memory pool model, and integrating a real-time memory allocation algorithm in the controlled allocation mode; step 6, app operation management; Defining the running state and the logic conversion relation of the state of the App, and designing an abnormality real-time monitor of the App.
  2. 2. The method for designing the appized software platform architecture of the spacecraft star software based on Lua according to claim 1, wherein the step 1 is specifically: step 1-1, lua source code acquisition and version selection; Downloading official source codes suitable for a star service operating system; Step 1-2, compiling configuration of an environment; Configuring a cross compiling environment, configuring a configuration header file luaconfg.h of a Lua language aiming at a hardware architecture of a 32-bit processor, defining a macro to adapt to a star operating system platform, configuring an integer type as an int type, configuring a floating point type as a float type, and defining a maximum value and a minimum value of the integer and the floating point type; Step 1-3, cutting a source code file, reserving a core function module of a Lua interpreter, namely a related file of a Lua virtual machine, removing a Lua independent interpreter file lua.c and an independent byte code compiler file luac.c for compiling a Lua script, and removing unnecessary standard library files; and step 1-4, after the transplanting, cutting and memory optimization of the Lua interpreter are finished, the interactive interface between the satellite software and the Lua interpreter and the design of the satellite-borne App subtask are finished, and finally, the Lua interpreter subjected to cutting and memory optimization is used as a core component library of the satellite software to be integrated, and a satellite-borne software entity is constructed in a way of integral compiling and static linking.
  3. 3. The method for designing the App software platform architecture of the spacecraft star software based on Lua according to claim 1, wherein the version of the official source code is Lua5.3.6.
  4. 4. The method for designing the appized software platform architecture of the spacecraft star software based on Lua according to claim 2, wherein the step 2 is specifically: Step 2-1, a data interface provides standardized star service data and instruction interaction channels for various apps through a unified memory access mechanism; The remote control instruction pool is used for directly forwarding an uplink remote control instruction to a corresponding App, and before each App operates, a data interface mechanism maps memory base addresses of all the data pools into a Lua stack operating environment, and the App can be directly called in the Lua stack; Different apps access the data and instructions respectively required by the apps through standardized interface functions and data offset addresses according to the functional requirements of the apps; step 2-2, defining a standardized function interface mechanism based on a Lua interpreter, and providing unified and safe bottom system service and hardware function call channels for a satellite-borne App; in the initialization stage of a satellite-borne App subtask, the satellite software registers a custom function library which is packaged in a C language in advance to a Lua global running environment through a Lua C API; The function library realizes the access logic to the core service and hardware equipment of the star system, exposes the corresponding functions to the upper-layer App in the form of Lua functions, and directly calls the registered functions when each App is executed in the Lua environment.
  5. 5. The method for designing the appized software platform architecture of the spacecraft star software based on Lua according to claim 4, wherein the step 3 is specifically: Compiling the App which passes the test into a binary operation code on the ground by utilizing the general idea of breakpoint continuous transmission, subdividing the binary operation code into a plurality of script code uploading blocks according to a preset size, orderly packaging the script code uploading blocks according to a transmission protocol, and transmitting the script code uploading blocks to a spacecraft remote control and telemetry transponder through an uplink remote control link during the over-roof period of the spacecraft.
  6. 6. The method for designing the appized software platform architecture of the spacecraft star software based on Lua according to claim 5, wherein the step 4 is specifically: step 4-1, storing the binary operation code file compiled by the App in an external NVRAM; Step 4-2, dividing the App storage area of the whole NVRAM into a plurality of sub storage areas with fixed sizes, namely storage grooves, reserving a space which is consistent with each storage groove and is only used for storing a main backup file of a complete App script code, backing up the main backup file for replacing the main backup file for running after the main backup is abnormal, and when the system function is required to be added or the existing function is required to be upgraded, only a remote control instruction is required to control the Lua virtual machine to unload the original App, then the App code file in the groove is updated, and the update of the App can be completed without restarting the system.
  7. 7. The method for designing the appized software platform architecture of the spacecraft star software based on Lua according to claim 6, wherein the step5 is specifically: Step 5-1, a static memory pool construction and isolation mechanism; In the system initialization stage, an independent and continuous fixed area is allocated from the physical memory of the spaceborne computer and used as a exclusive memory pool for running the Lua virtual machine and the App, wherein the base address and the size of the memory pool are determined at the compiling time and kept fixed during the running time, so that the memory isolation from other modules of the spaceborne system is realized in a physical space; step 5-2, realizing a deterministic memory allocation algorithm based on a two-stage isolation adaptation algorithm; The memory allocation and release are completed in constant time (O (1)) through a two-stage index structure and a separation linked list, and the memory allocation and release have a determined worst execution time upper bound; Step 5-3, replacing and binding the bottom layer of the Lua virtual machine memory distributor; And when the Lua virtual machine instance is created, the customized memory allocator is bound with the Lua virtual machine instance, so that all memory application and release operations in the running process of the virtual machine are strictly limited in a static memory pool, and the complete controllability and predictability of the memory behavior are realized.
  8. 8. The method for designing the appized software platform architecture of the spacecraft star software based on Lua according to claim 7, wherein the step 6 is specifically: Step 6-1, creating a satellite-borne App subtask; A periodic task execution frame is preset in a satellite software system, the frame divides the system period into a plurality of fixed time slices with different lengths, and each time slice corresponds to an execution window of a specific satellite-borne subtask; on the basis, the system creates an independent execution window-a satellite-borne App subtask for the satellite-borne App, wherein the subtask is provided with an independent stack and an operation context and is distributed to be executed in a fixed time segment; step 6-2, initializing a satellite-borne App subtask; 1) Establishing a Lua virtual machine state instance as a core running environment for subsequent App execution; 2) Loading a necessary Lua standard function library to provide basic function support; 3) Registering a user-defined function library; Registering customized function libraries pre-packaged by star software into a Lua environment, wherein the customized function libraries encapsulate standardized calling interfaces for collecting bottom system functions and hardware resources for on-board time, bus communication, memory access and equipment states, and provide unified system services and hardware resource access channels for an App; 4) Initializing a coroutine support environment; in order to support concurrent execution of a plurality of apps, a coroutine management mechanism is established in the Lua environment, and a corresponding main coroutine is established for an App slot in each NVRAM, so that each App can run in an independent execution context, and isolation between tasks and system stability are ensured; 5) Loading an initial App; Reading apps preset in an on-satellite NVRAM, loading the apps into a constructed Lua virtual environment, enabling the apps to be in a starting state, and waiting for subsequent execution; this initialization flow is only performed once when the on-board App management subtask is started; step 6-3, defining the running state of App and the logic conversion relation of the state, and summarizing 5 kinds of idle state, loading state, starting state, running state and abnormal state; the idle state is that the App is uploaded to the NVRAM, but is not loaded to the Lua virtual machine, and exists only as a static script file, and does not occupy any runtime resource at this time, and waits for a loading instruction or App update; the loading state is that after the system receives a remote control loading instruction, the App is loaded from the NVRAM to the Lua virtual machine, but the App does not actually run, and the App starts or unloads the instruction; After receiving a remote control starting instruction, the loaded App is switched into a starting state and enters an executable queue, and the star-loaded App subtask is waited to allocate an execution time slice for the star-loaded App subtask; The running state is that after the star-borne App subtask distributes execution resources, the virtual machine starts to interpret and execute App byte codes, and the App is in the running state at the moment; The system triggers a backup replacement strategy, loads backup to take over the running of the main part, returns to the original state after processing, and changes to an idle state to wait for the updating or deleting of the ground when the processing fails or the backup is abnormal; the state transition is driven by definite trigger conditions, namely, a remote control instruction triggers a loading state and a starting state, a satellite-borne App subtask operation control event triggers an operation state, execution completion triggers a return starting state, and various error events trigger an abnormal state; Step 6-4, an operation control mechanism of the App; In a fixed time slice of a satellite-borne App subtask, the system realizes cooperative parallel operation of multiple Apps based on Lua cooperative distance; the system takes the corresponding cooperative program of the App as an operation unit, and performs non-preemptive cooperative scheduling according to the priority, wherein each App is endowed with a fixed priority on the ground, and the App cooperative program which is in a starting state and is released is selected to be sequentially executed according to the priority order; Step 6-5, an App real-time monitor; An App monitoring and fault-tolerant mechanism of cross-heterogeneous language based on cooperation of a hardware timer and a Lua debugging hook is designed; 1) Before executing the App, starting a hardware timer from a C language level, and prescribing that the hardware timer triggers an interrupt after setting the worst execution time of the App; 2) In the interrupt processing stage, the timed interrupt service routine identifies a Lua cooperative program corresponding to a timeout App at a C language level, and a lua_ sethook function is called by a Lua C API to set a debugging hook for the Lua cooperative program, wherein parameters of the lua_ sethook function call comprise a target cooperative program, a callback function and an event mask; The event mask is set to be a LUA_ MASKCOUNT mode, which represents that a hook is triggered based on the instruction number, and an instruction counting threshold value is set to be 1, so that a coroutine triggers the hook when the executed first Lua virtual machine instruction is restored; 3) In the exception recovery stage, when the executed Lua cooperative program is recovered to run the next Lua instruction, triggering the event debugging hook at the Lua level, calling a lua_yield function through a Lua C API in a hook callback function, enabling the Lua cooperative program to actively call the hook callback function to execute legal suspension operation at the Lua level so as to relieve occupation of virtual machine resources; 4) In the state cleaning stage, after the abnormal App is suspended, a debugging hook of the abnormal App is cleaned by a C language layer through a Lua C API, and a hardware timer is reset; 5) The system comprises a monitoring system, a backup switching stage, a backup switching process and a system control system, wherein the monitoring system detects and suspends an abnormal App, the system starts the backup switching process, the system prestores two versions of each App, namely a main version and a backup version, at the moment, the system uninstalls the abnormal main version App and loads the backup version of the corresponding App from NVRAM, the backup version and the main version are consistent in function, but are realized by using different codes or subjected to differential verification, so that the backup version can still work normally when a specific logic defect occurs in the main version, and after the switching is finished, the system continues to provide corresponding services based on the backup version, so that autonomous fault tolerance and continuous service are realized under the condition of not depending on ground intervention.
  9. 9. An electronic device comprising a processor and a memory, the memory for storing a computer program, the processor for executing the computer program stored by the memory to cause the electronic device to perform the method of any one of claims 1 to 8.
  10. 10. A computer readable storage medium, on which a computer program is stored, which computer program, when being executed by a processor, implements the method according to any one of claims 1 to 8.

Description

Spacecraft star software App software platform architecture design method based on Lua Technical Field The invention belongs to the technical field of spacecrafts, and particularly relates to a method for designing an App software platform architecture of spacecrafts based on Lua. Background With the continuous development of the aerospace technology, the spacecraft plays an indispensable role in the fields of communication, navigation, remote sensing, meteorological observation and the like. The star software is used as a core for star management and control of the spacecraft, is responsible for task scheduling and comprehensive information processing of the spacecraft, and is a key for ensuring functions, performance and operation quality of the spacecraft. The on-orbit operation of the spacecraft faces multiple dynamic requirements, the evolution of a task target possibly generates new functional requirements, unpredictable changes in the actual flight environment require a system to adaptively adjust a control strategy, and sudden abnormal conditions require on-board autonomous handling capability. The satellite software is used as the only component part capable of being modified on orbit in the spacecraft system, and the importance of the satellite software is increasingly highlighted. The application scenes are urgent to require that the satellite software has on-orbit dynamic adjustment capability, and can realize the rapid update and architecture reconstruction of functions through remote uploading, so that the complex and changeable on-orbit requirements can be flexibly met. Currently, most of the mainstream star software is developed by adopting C, ada and other compiled languages, and an on-orbit updating mechanism is subject to remarkable restriction. The on-orbit function updating and the on-orbit function expanding are mainly realized through two ways of integral uploading and dynamic linking compiling library, but have obvious limitations that the former is required to be completely recompiled through software and restarted by an on-board computer system, the flow is complex, the time consumption is long, the on-orbit maintenance cost is high and the operation risk is prominent due to limited satellite-ground communication bandwidth and short-lived communication window, the latter can avoid the problems of integral recompilation and system restarting, but the dynamic linking module can access various core resources of the satellite software without distinction and interfere with scheduling logic, and potential error behaviors are easy to spread to the whole system, thereby seriously threatening the running stability and safety of the satellite software. In this context, the introduction of Lua-interpreted scripting language to build the spacecraft software "appized" platform architecture becomes a key technical direction. The Lua interpreter is embedded into the satellite-borne software, and an App virtual running environment isolated from the original satellite-borne task is constructed. Based on this, the star functions can be packaged as a plurality of independent star function modules written using Lua scripts, collectively referred to as apps, interpreted by the Lua interpreter. The App can bear part of functions of the original satellite software, and can expand the functions of the satellite software according to the changes of the external environment and the internal state of the spacecraft. The App can realize dynamic loading, replacement and unloading through remote injection under the conditions of not restarting the system and not modifying the star software, namely, a complete on-orbit updating mechanism is supported. The method not only remarkably reduces the complexity and operation risk of on-orbit software updating, but also fully exerts the reconfigurable potential of the on-orbit software, thereby greatly improving the on-orbit autonomous running capability and task adaptability of the spacecraft. Disclosure of Invention In order to overcome the defects of the prior art, the invention provides a spacecraft star software App software platform architecture design method based on Lua, which constructs a star-borne App running environment supporting on-orbit dynamic loading and thermal updating by embedding a Lua interpreter in star software. The method mainly comprises six parts of Lua interpreter transplanting and cutting, star software and Lua interpreter interface definition and realization, app code uploading management, app storage management, lua virtual machine and App memory management and App running management. The invention greatly improves the adaptability and expansibility of the system and enhances the autonomous operation capability of the spacecraft under the unattended condition. The technical scheme adopted for solving the technical problems is as follows: step 1, transplanting and cutting of a Lua interpreter; Transplanting the Lua interpreter source code