Satellite system software integrity guarantee design method based on DO-278A

Abstract

The invention discloses a design method for ensuring the integrity of satellite system software based on DO-278A. The method comprises the following steps: defining a satellite dedicated software security integrity level SSIL and mapping the satellite dedicated software security integrity level SSIL with a software integrity level SWIL of a DO-278A standard; constructing a satellite-ground cooperative dual V model containing a ground development V model and an on-orbit maintenance V model; designing a space software fault-tolerant architecture and carrying out a fault injection test; and establishing an on-orbit software health state monitoring and evidence collection closed-loop process. According to the method provided by the invention, the full life cycle of the satellite software is covered, the fault-tolerant capability and on-orbit maintainability of the satellite software are improved, the blank of an integrity guarantee scheme of the satellite exclusive software in the prior art is filled, and long-period and high-reliability operation of the satellite software is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application mainly relates to the field of aerospace software engineering and high-reliability system safety, and particularly relates to a satellite system software integrity guarantee design method based on DO-278A. BACKGROUND

[0002] In the field of aerospace, as the core equipment for performing key tasks such as space exploration, communication and navigation, the integrity of the system software of a satellite directly determines the success or failure of the task and the operation safety. Due to the long task cycle of the satellite, the harsh running environment and the explosive increase in on-orbit maintenance cost, the demand for high reliability, long service life and autonomous fault tolerance capability of the software is increasingly urgent.

[0003] DO-278A “Guidelines for Communications, Navigation, Surveillance and Air Traffic Management (CNS / ATM) Systems Software Integrity Assurance” is a recognized standard in the aviation field for ensuring the safety of critical software. Its core is to determine the rigor and its degree that need to be performed based on the risk level (software integrity level, SWIL) that may be caused by software failure through a structured life cycle process, so as to guarantee the software integrity.

[0004] However, there are many challenges in directly applying DO-278A to satellite products: first, the existing DO-278A standard does not develop protection strategies for space-specific risks of satellite operation. Second, once the satellite is launched into orbit, the maintenance operation cost is extremely high and the technical difficulty is extremely great, and the software needs to have autonomous fault tolerance capability and reliable remote on-orbit update capability, but DO-278A does not cover the processes and verification requirements related to on-orbit maintenance. At the same time, the life cycle design of DO-278A focuses on the ground development stage and does not cover the software management and control needs of the whole life cycle of the satellite. In addition, the existing SWIL level cannot be directly mapped to the task risk of the satellite, and the adapted satellite software safety integrity level needs to be redefined.

[0005] In summary, the current industry lacks a set of software integrity assurance guidelines that are specifically for the characteristics of satellite products, systematically integrate the concept of DO-278A standard and the needs of space application, so that the satellite system software is difficult to obtain a targeted integrity protection scheme in the process of design, development, verification and on-orbit maintenance, and the on-orbit software failure risk is high. Therefore, it is urgent to propose an optimized method based on DO-278A standard to adapt to the satellite application scenario to fill this technical gap. SUMMARY

[0006] Based on the prior art, the task of the present application is to propose a satellite system software integrity assurance design method based on DO-278A, which is based on the DO-278A standard and establishes a satellite-specific satellite software safety integrity level SSIL division standard. The software integrity assurance design method proposed by the present application in view of the characteristics of satellite products and the systematic integration of DO-278A concepts and space application requirements can fill the gap in the prior art and solve the problem that the existing standard is not strong in space application environment.

[0007] According to the content of the present application, the above-mentioned problem is solved by a satellite system software integrity assurance design method based on DO-278A.

[0008] In a first aspect of the present application, a satellite system software integrity assurance design method based on DO-278A is proposed, which comprises: Step S1, defining a satellite software safety integrity level SSIL, which is configured to be mapped with the software integrity level SWIL defined in the DO-278A standard; Step S2, constructing a star-ground cooperative double V model module, the star-ground cooperative double V model module comprising a ground development V model and an on-orbit maintenance V model, mapping and adaptive tailoring the targets and outputs in the DO-278A standard according to the satellite software safety integrity level SSIL defined in step S1, and applying the star-ground cooperative double V model; Step S3, constructing a space software fault-tolerant architecture module, which is configured to perform specific fault-tolerant design according to the satellite-specific risks identified by the system, and in the verification activity, increase the special test and fault injection test on the effectiveness of the above-mentioned fault-tolerant mechanism; and Step S4, constructing an on-orbit software health state monitoring and evidence collection closed loop process module, which is configured to continuously monitor and collect key data of satellite software runtime, and form a closed loop feedback for guiding possible on-orbit maintenance activities.

[0009] Further, in step S1, the satellite software safety integrity level SSIL is divided into 5 levels: SSIL-0: functional failure has no impact, the SSIL-0 is mapped to SWIL-1, and is configured to not apply the complete target or apply the corresponding partial target of SWIL-1; SSIL-1: functional failure causes task degradation or slight loss, the SSIL-1 is mapped to SWIL-2, and is configured to apply the corresponding target and output of SWIL-2 and perform adaptive tailoring; SSIL-2: a functional failure leading to primary mission failure or significant asset loss, which is mapped to SWIL-3, and is configured to apply the corresponding objectives and outputs of SWIL-3, and verify fault-tolerant design for satellite risk increase; SSIL-3: a functional failure leading to severe damage of satellite platform or permanent mission loss, which is mapped to SWIL-3 and SWIL-4, and is configured to apply all the objective requirements of SWIL-3 and SWIL-4; and SSIL-4: a functional failure leading to personnel casualty, other spacecraft damage or catastrophic ground hazard, which is mapped to SWIL-4, and is configured to apply all the objective requirements of SWIL-4, and increase the enhanced fault-tolerant measures and / or on-orbit monitoring requirements. Further, in step S2, the ground development V model includes the following stages: a top-level requirement definition stage, which is configured to define the top-level requirements and safety requirements in combination with the criticality of the satellite mission and its satellite software safety integrity level SSIL; a system design and software requirement analysis stage, which is configured to decompose the top-level requirements into a feasible system design scheme and / or software requirements; a high-level design and detailed design stage, which is configured to divide software function modules, confirm fault-tolerant architecture, and output design schemes; a coding and unit testing stage, which is configured to code the code unit modules, and carry out testing and / or function verification for each code unit; a software integration and integration testing stage, which is configured to assemble multiple unit modules into a complete software system, and carry out integration testing; and a system testing and acceptance testing stage, which is configured to carry out verification of software functions and risk response.

[0010] Further, in step S2, the on-orbit maintenance V model includes the following steps: an on-orbit requirement change analysis and impact evaluation stage, which is configured to evaluate the impact range of requirement change when the on-orbit requirement changes; a differential package design and generation stage, which is configured to design and generate a differential package for updating the software; a safety uploading and transmission stage, which is configured to transmit the differential package through a satellite-ground safety uploading link; an on-orbit loading and pre-activation verification stage, which is configured to complete the on-orbit loading of the differential package, and carry out pre-activation verification testing; an on-orbit testing and function confirmation stage, which is configured to carry out on-orbit testing on the loaded differential package, and verify whether the requirement change is implemented and whether the unchanged functions are affected; and During the status monitoring and feedback phase, it is configured to initiate a closed-loop process for monitoring the health status of on-orbit software and collecting evidence, collect key indicator data, and transmit it back to the ground. The ground end performs trend analysis on the transmitted data, and if an anomaly is detected, it triggers an early warning mechanism.

[0011] Further, in step S3, the space software fault-tolerant architecture module includes: The watchdog timer module is configured to monitor the task execution cycle, and trigger a system reset or security mode switch if it times out. The process health monitor module is configured to monitor the status, CPU usage, and stack usage of critical processes in real time. A memory scrubbing module is configured to periodically detect and correct soft errors in memory; The instruction redundancy execution module is configured to use a dual-core lockstep or instruction repetition execution mechanism for critical control flows; The configuration parameter protection module is configured to write-protect and periodically refresh critical registers and non-volatile memory; and The safety mode management module is configured to automatically switch to the minimum functional safety mode when a serious anomaly is detected.

[0012] Furthermore, in step S3, the fault injection test includes: simulating single-event upset (SEU) disturbances to memory or register bits in a hardware-in-the-loop (HIL) simulation test environment to verify whether the fault tolerance mechanism's detection and recovery capabilities and time metrics meet the design requirements.

[0013] Furthermore, in step S4, the closed-loop process of on-orbit software health status monitoring and evidence collection includes: Step S41: Data acquisition. Real-time acquisition of operational indicator data is conducted through onboard software monitoring points. Step S42: Telemetry downlink, transmitting the collected operational index data to the ground station; Step S43, Ground Processing and Analysis: The ground system parses, stores, and performs trend analysis on the received operational indicator data; Step S44, Anomaly Detection and Early Warning: Based on preset thresholds and / or machine learning algorithms, anomaly patterns are identified. If an anomaly occurs, an early warning mechanism is triggered. Step S45, Decision Support and Feedback: Based on the identification results of S44, decide whether to implement intervention; Step S46, Command Uploading and Execution: If, in step S45, it is decided to intervene, a security command and / or differential packet are generated, encrypted, verified, and then uploaded to the satellite for execution; and Step S47, Effect Verification and Closed-Loop Formation: After the intervention is implemented, operational indicator data are collected again to verify the effectiveness of the intervention and form a closed-loop control.

[0014] Furthermore, in step S41, the operational metrics data include: task execution cycle timeout count, watchdog reset count, memory ECC error correction / detection count, number of times safe mode is entered, abnormal fluctuations in CPU utilization of critical processes, and / or peak stack usage.

[0015] In a second aspect, the present invention provides a satellite system software integrity assurance system based on DO-278A, the system comprising: The SSIL standard module is configured to classify satellite-specific satellite software security integrity levels (SSIL) and map them to the software integrity levels (SWIL) defined in DO-278A, clarifying the software requirements corresponding to different levels. The satellite-ground collaborative dual V model module is configured to establish a lifecycle management mechanism for satellite software ground development and on-orbit maintenance; The space fault-tolerant architecture module is configured to ensure the stable operation of satellite software in the face of various risks; and The on-orbit software health status monitoring and evidence collection module is configured to continuously collect key data during software operation to achieve real-time monitoring and timely maintenance of the satellite software's on-orbit status.

[0016] Furthermore, the satellite-ground collaborative dual V-model module includes: The V-model for ground development is configured to cover the entire process from requirements gathering to integration testing, clearly defining the corresponding goals, inputs, outputs, and activities at each stage; and The V-model is maintained in orbit and is configured to cover the entire process from in-orbit requirement changes, differential package generation, security injection, in-orbit verification to activation.

[0017] This invention proposes a design method for ensuring the software integrity of a satellite system based on DO-278A, which has at least the following beneficial effects: First, the method described in this invention solves the problem that SWIL levels in the aerospace field cannot cover the criticality of diverse satellite missions by establishing a classification standard for satellite-specific Software Security Integrity Level (SSIL) and a mapping model with the Software Security Integrity Level (SWIL) in DO-278A. It can accurately define integrity requirements based on the consequences of satellite functional failure, and provide differentiated and targeted protection basis for satellite software with different levels of criticality.

[0018] Secondly, the dual V-model for satellite-ground collaboration constructed by the method described in this invention retains the structured and rigorous ground development process in the DO-278A standard, while adding full-process control of on-orbit maintenance. It is suitable for satellite mission cycles of 10-15 years or even longer, and solves the problem that traditional standards only focus on ground development and cannot cope with the difficulties of on-orbit maintenance and technological aging of satellites. It ensures the integrity and controllability of satellite software throughout the entire process from development to on-orbit operation.

[0019] Furthermore, the closed-loop process for on-orbit software health status monitoring and evidence collection constructed by the method not only enables dynamic monitoring and timely intervention of on-orbit software integrity, but also provides a traceable and objective chain of evidence to ensure that the software continuously meets integrity requirements during on-orbit operation, thus satisfying the compliance and auditability requirements of high-security-critical software in the satellite field.

[0020] In summary, the method described in this invention adapts and enhances the DO-278A standard to form a software integrity assurance framework tailored to the characteristics of satellite products. This framework covers all aspects of satellite software products from design and development to application, including design, development, verification, and on-orbit maintenance. It provides a universal and highly reliable integrity assurance solution for the system software of spacecraft and other spaceflight products, filling the gap in the industry for satellite-specific software integrity assurance guidelines and possessing broad industry application and promotion value. Attached Figure Description

[0021] To further illustrate the advantages and other features of the various embodiments of the present invention, a more specific description of the embodiments of the present invention will be presented with reference to the accompanying drawings. It is understood that these drawings depict only typical embodiments of the invention and are therefore not intended to limit its scope. In the drawings, identical or corresponding parts will be indicated by the same or similar reference numerals for clarity.

[0022] Figure 1 This diagram illustrates the software development and maintenance lifecycle of a satellite-ground collaborative dual-V model in one embodiment of the present invention.

[0023] Figure 2 A schematic diagram of the design of a space software fault-tolerant architecture module is shown in one embodiment of the present invention.

[0024] Figure 3 This diagram illustrates a closed-loop process for on-orbit software health status monitoring and evidence collection in one embodiment of the present invention.

[0025] List of reference numerals 100 Ground Development V-Model 101 Top-level requirements definition phase 102 System Design and Software Requirements Analysis Phase 103 High-rise design and detailed design phase 104 Coding and Unit Testing Phase 105 Software Integration and Integration Testing Phase 106 System Testing and Acceptance Testing Phase 200 On-orbit Maintenance V-Model 201 On-orbit Demand Change Analysis and Impact Assessment Phase 202 Differential Package Design and Generation Phase 203 Secure Uploading and Transmission Phase 204 On-orbit loading and pre-activation verification phase 205 On-orbit Testing and Functional Validation Phase 206 Status Monitoring and Feedback Phase Detailed Implementation It should be noted that the components in the various figures may be shown exaggeratedly for illustrative purposes and are not necessarily to scale. In each figure, the same reference numerals are used for components that are identical or have the same function.

[0026] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.

[0027] In this invention, unless otherwise specified, the quantifiers “a” and “one” do not exclude scenarios involving multiple elements.

[0028] It should also be noted that, for clarity and simplicity, only a portion of the components may be shown in the embodiments of the present invention. However, those skilled in the art will understand that, under the teachings of the present invention, the required components can be added according to specific needs. Furthermore, unless otherwise stated, features in different embodiments of the present invention can be combined with each other. For example, a feature in the second embodiment can replace a corresponding or functionally identical or similar feature in the first embodiment, and the resulting embodiment will also fall within the scope of disclosure or description of this application.

[0029] It should also be noted that within the scope of this invention, the terms "same", "equal", and "equal to" do not mean that the two values ​​are absolutely equal, but allow for a certain reasonable error. In other words, the terms also cover "substantially the same", "substantially equal", and "substantially equal to".

[0030] Furthermore, the numbering of the steps in the methods of the present invention does not limit the execution order of the method steps. Unless otherwise specified, the method steps may be executed in different orders.

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

[0032] In one embodiment of the present invention, a design method for ensuring the software integrity of a satellite system based on DO-278A is proposed, the method comprising: Step S1: Define the satellite software security integrity level SSIL, which is configured to map to the software integrity level SWIL defined in the DO-278A standard; Step S2: Construct a satellite-ground collaborative dual V model module, which includes a ground development V model 100 and an on-orbit maintenance V model 200. Based on the satellite software security integrity level (SSIL) defined in step S1, the objectives and outputs in the DO-278A standard are mapped and adaptively tailored and applied to the satellite-ground collaborative dual V model. Step S3: Construct a space software fault-tolerant architecture module, which is configured to perform specific fault-tolerant design based on the systematically identified satellite-specific risks, and to add special tests and fault injection tests to verify the effectiveness of the above-mentioned fault-tolerant mechanism during the verification activities; Step S4: Construct a closed-loop process module for on-orbit software health status monitoring and evidence collection. This module is configured to continuously monitor and collect key data during satellite software operation and form closed-loop feedback to guide possible on-orbit maintenance activities.

[0033] In one embodiment of the present invention, the SSIL level is divided into 5 levels (SSIL-0 to SSIL-4) based on the severity of the consequences of satellite functional failure, while the SWIL level in the DO-278A standard, "Guidelines for Software Integrity Assurance of Communication, Navigation, Surveillance and Air Traffic Management (CNS / ATM) Systems", is classified based on the impact of software failure on system safety (for example, SWIL levels are divided into SWIL-1 to SWIL-4, with SWIL-4 being the highest level).

[0034] In one embodiment of the present invention, the classification of SSIL levels and its mapping to SWIL levels are as follows: SSIL-0 (No impact from functional failure): Mapped to SWIL-1 (No safety impact) or does not require the application of strict DO-278A targets. Since SSIL-0 has no impact, a full integrity assurance process may not be required, but the minimum requirements of SWIL-1 can be referenced.

[0035] SSIL-1 (Function failure leading to task degradation or minor loss): Mapped to SWIL-2 (Minor security impact), SSIL-1 is configured to apply the corresponding goals and outputs of SWIL-2, but with adaptive pruning, such as reducing the rigor of certain documents or tests.

[0036] SSIL-2 (Functional failure leading to major mission failure or significant asset loss): Mapped to SWIL-3 (Major security impact), SSIL-2 is configured to apply the corresponding objectives and outputs of SWIL-3, and adds fault-tolerant design verification for satellite risks.

[0037] SSIL-3 (Failure of Functionality Leading to Severe Damage to Satellite Platform or Permanent Loss of Mission): Maps to all the objective requirements of SWIL-3 and SWIL-4 (Catastrophic Safety Impact). This means that SSIL-3 must meet all the objectives and outputs of SWIL-3 and SWIL-4, including highly rigorous development processes and / or fault injection testing.

[0038] SSIL-4 (Functional failure resulting in casualties, damage to other spacecraft, or catastrophic ground hazard): Mapped to all the target requirements of SWIL-4 with added enhancements (such as additional fault tolerance mechanisms or more stringent on-orbit monitoring). Due to the catastrophic consequences of functional failure, the target requirements of SSIL-4 may exceed those of standard SWIL-4.

[0039] Figure 1 This diagram illustrates the software development and maintenance lifecycle of a satellite-ground collaborative dual-V model according to one embodiment of the present invention. Figure 1 As shown, the satellite-ground collaborative dual V-model includes a ground development V-model 100 on the ground and an on-orbit maintenance V-model 200 on the satellite.

[0040] Specifically, the development and maintenance cycle of the ground development V-model 100 includes the following stages: Phase 101, Top-Level Requirements Definition: This phase clarifies the core mission objectives and security constraints of the satellite software. Combining the criticality of the satellite mission with its Security Integrity Level (SSIL) of the satellite software, it defines the top-level requirements and security requirements.

[0041] System Design and Software Requirements Analysis Phase 102: This phase breaks down the top-level requirements defined in the top-level requirements definition phase 101 into feasible system design solutions and / or software requirements.

[0042] Phase 103 of the high-level design and detailed design: This phase divides the software functional modules, confirms the fault-tolerant architecture, outputs design solutions for each module, and ensures that the design solutions can directly guide coding.

[0043] In the coding and unit testing phase 104, the design scheme output in the high-level design and detailed design phase 103 is strictly followed, and code unit modules are coded. At the same time, testing and / or functional verification are carried out for each code unit (such as functions and / or submodules) to verify the correctness of the unit's functionality.

[0044] Software integration and integration testing phase 105: In this phase, multiple unit modules are assembled into a complete software system and integration testing is performed to verify the functional coherence of the system, the system compatibility between modules, and the cross-module collaborative effect of the fault tolerance mechanism.

[0045] System testing and acceptance testing phase 106 involves functional and risk verification in a ground-based hardware-in-the-loop (HIL) simulation environment. This includes functional testing, performance testing, and fault injection testing to confirm whether the software meets delivery standards. If the software meets delivery standards, the software version is frozen, and the final firmware and all development documentation are stored in the configuration management database to provide baseline data for subsequent on-orbit maintenance procedures.

[0046] The development and maintenance phases of the V-Model 200 in-orbit maintenance include the following stages: In the On-orbit Requirements Change Analysis and Impact Assessment Phase 201, when on-orbit software malfunctions, mission objectives are adjusted, or hardware ages, i.e. when on-orbit requirements change, the software baseline from the ground development phase is retrieved from the configuration management database. Combined with on-orbit telemetry data, the impact range of the requirement change is assessed, and the necessity and feasibility of the change are ultimately confirmed.

[0047] Differential Package Design and Generation Phase 202: In this phase, to avoid the problems of large data transmission volume and long time consumption caused by full software upload, differential packages are designed and generated to update the software.

[0048] In the secure uploading and transmission phase 203, differential packets are transmitted via the satellite-to-ground secure uploading link.

[0049] In the on-orbit loading and activation pre-verification phase 204, the differential packets transmitted in the security uploading and transmission phase 203 are not directly activated on the satellite. Instead, they are first loaded on-orbit and tested for version compatibility, core functions, and / or fault tolerance mechanisms to avoid affecting on-orbit services.

[0050] In the on-orbit testing and functional verification phase 205, if the differential packet transmitted in the security loading and transmission phase 203 passes the pre-activation verification in the on-orbit loading and pre-activation verification phase 204, then the version is activated and on-orbit testing is conducted to verify whether the changes in requirements have been implemented and whether the unchanged functions have been affected.

[0051] Phase 206: Status Monitoring and Feedback. In this phase, after the software is officially running, a closed-loop process for monitoring the health status of the software in orbit and collecting evidence is initiated. Key indicator data (such as mission execution cycle timeout count, memory ECC error correction count, and / or safe mode entry count) are collected in real time through on-board software monitoring points and periodically transmitted back to the ground via telemetry links. The ground end performs trend analysis on the transmitted data, and if an anomaly is detected, an early warning mechanism is triggered.

[0052] In one embodiment of the present invention, the ground development V-model 100 and the on-orbit maintenance V-model 200 are connected through a configuration management database and a security upload link to ensure that the entire lifecycle process of software from development to on-orbit maintenance is controllable and traceable.

[0053] Specifically, in one embodiment of the present invention, all outputs during the ground development phase are stored in a configuration management database to form baseline data. Each operation during the on-orbit maintenance phase, including requirement changes, differential package generation, upload records, and / or data monitoring, must be associated with the baseline data in the configuration management database. For example, differential package design requires retrieving the code structure from the baseline data, and on-orbit testing requires comparing the performance baseline of the baseline data. Through this approach, it can be ensured that all changes in the on-orbit maintenance process are traceable, and all problems are locatable. Simultaneously, abnormal data from on-orbit monitoring is stored in the configuration management database, providing data reference for subsequent iterative development of satellite software.

[0054] In one embodiment of the present invention, the final output version of the software in the ground-based development V-model 100 is transmitted to the satellite via a secure uplink, becoming the initial running version of the software in the on-orbit maintenance V-model 200, thus completing the development-interaction process. Simultaneously, the design of differential packages and / or test schemes after changes in on-orbit requirements must be based on the technical specifications of the ground development phase, and the generation and / or verification of the differential packages must be completed in the ground environment before being transmitted to the satellite via the secure uplink.

[0055] In summary, the ground development V-model 100 and the on-orbit maintenance V-model 200 achieve a fully closed-loop process and data traceability through configuration management databases and secure uploading links, providing software integrity assurance for the operation of long-cycle satellite missions.

[0056] Figure 2 A flowchart illustrating a space software fault-tolerant architecture module in one embodiment of the present invention is shown. Specifically, the space software fault-tolerant architecture module mainly includes the following modules: The Watchdog Timer module is configured to set a maximum execution cycle threshold for critical tasks, monitor the task execution cycle, and trigger a system reset or safe mode switch if the task times out due to deadlock, runaway, or other reasons.

[0057] The Process Health Monitor module is configured to monitor the status, CPU utilization, and stack usage of critical processes in real time, and issue warnings for minor anomalies (such as short-term CPU spikes), and trigger restarts or report to the safe mode module for serious anomalies (such as process crashes).

[0058] The memory scrubbing module is configured to periodically detect and correct soft errors in memory, supporting ECC (Error Correction Code) and TMR (Triple Modular Redundancy) memory structures.

[0059] The Redundant Execution Unit (REDU) module is configured to use either a dual-core lockstep (two cores execute the same instruction synchronously, compare the results in real time, and trigger a retry if they are inconsistent) or an instruction repetition mechanism (the same core executes the instruction repeatedly in different time slices and compares the results twice) for critical control flows.

[0060] The Configuration Protection module is configured to write-protect critical registers and non-volatile memory (by locking hardware registers to prevent unauthorized modifications) and refresh periodically.

[0061] Safe Mode Manager module: When a serious anomaly is detected, it automatically switches to the minimum functional safety mode to disable unnecessary functions, reduce system load, and increase the running priority of fault-tolerant modules.

[0062] like Figure 2 As shown, in one embodiment of the present invention, the operation flow of the space software fault-tolerant architecture module is as follows: After system health monitoring is started, it checks whether the task execution has timed out.

[0063] If the watchdog timer module detects a task execution timeout, it triggers a system reset and / or switches to safe mode. Otherwise, proceed to the next step.

[0064] Furthermore, if the process health monitoring module detects an abnormal state in a critical process, it will issue an alert. Otherwise, proceed to the next step.

[0065] Furthermore, if the memory wiping module detects a soft memory error, it corrects the error. Otherwise, it proceeds to the next step.

[0066] Furthermore, if critical control flows require redundant execution, the instruction redundancy execution module intervenes, employing a dual-core lockstep or instruction repetition mechanism. Otherwise, the configuration parameter protection module performs write protection and / or refresh of configuration parameters.

[0067] In summary, each module in the fault-tolerant architecture of space software independently undertakes fault-tolerant tasks in specific dimensions, and forms cross-validation through information exchange to ensure the high reliability of space software in harsh environments such as radiation and single-event effects.

[0068] Figure 3 This diagram illustrates a closed-loop process for on-orbit software health status monitoring and evidence collection in one embodiment of the present invention. Figure 3 As shown, in one embodiment of the present invention, the closed-loop process of on-orbit software health status monitoring and evidence collection is as follows: Step S41, Data Acquisition: Real-time acquisition of on-orbit software operation index data, such as watchdog reset count, memory ECC count, and / or task execution time, through on-board software monitoring points.

[0069] Step S42, Telemetry Downlink: The collected operational index data is transmitted to the ground station via the telemetry link.

[0070] Step S43, Ground Processing and Analysis: After receiving the data, the ground system parses, stores, and performs trend analysis to generate a health assessment report.

[0071] Step S44, Anomaly Detection and Early Warning: Identify abnormal patterns based on preset thresholds or machine learning algorithms. If an anomaly is detected, an early warning mechanism is triggered.

[0072] Step S45, Decision Support and Feedback: Based on the analysis results, decide whether to initiate on-orbit maintenance procedures, such as software updates or mode switching.

[0073] Step S46, Command Upload and Execution: If it is necessary to start the on-orbit maintenance process, a safety command or differential packet is generated, encrypted and verified, and then uploaded to the satellite for execution.

[0074] Step S47, Effect Verification and Closed Loop: After performing on-orbit maintenance, collect on-orbit software operation index data again to verify the effectiveness of the maintenance measures, thereby forming a closed loop control.

[0075] In summary, the above steps enable closed-loop control of on-orbit software health status monitoring and evidence collection, ensuring accurate maintenance and long-term optimization of satellite software during mission execution.

[0076] In one embodiment of the present invention, a satellite system software integrity assurance system based on DO-278A is also proposed, the system comprising: The SSIL standard module is configured to classify satellite-specific satellite software security integrity levels (SSIL) and map them to the software integrity levels (SWIL) defined in DO-278A, clarifying the software requirements corresponding to different levels. The satellite-ground collaborative dual V model module is configured to establish a lifecycle management mechanism for satellite software ground development and on-orbit maintenance; The space fault-tolerant architecture module is configured to ensure the stable operation of satellite software in the face of various risks; and The on-orbit software health status monitoring and evidence collection module is configured to continuously collect key data during software operation to achieve real-time monitoring and timely maintenance of the satellite software's on-orbit status.

[0077] The application of the system described in this invention in the development, testing, and execution of satellite software is illustrated in detail below through a specific embodiment of this invention.

[0078] In one embodiment of the present invention, taking the attitude control (ACS) software of a certain type of remote sensing satellite as an example, the following steps are performed: 1. SSIL Level Definition and Standard Mapping Since the ACS software is the core module of satellite attitude control, if it fails, it may cause the satellite to roll, lose its Earth pointing direction, or even collide with other space objects, ultimately leading to complete mission failure and significant asset loss. Therefore, the SSIL level of the ACS software is set at Level 3 (SSIL-3).

[0079] Based on this level, the integrity level is mapped according to the DO-278A standard. The ACS software must meet all the target requirements of software integrity levels SWIL3 (SWIL-3) and SWIL4 (SWIL-4). In addition, some enhancement measures (such as strengthening memory fault tolerance) are added to take into account the special characteristics of the satellite scenario.

[0080] 2. Lifecycle Process Design In this embodiment, a dual V-model of space-ground collaboration is adopted to cover the entire software lifecycle, corresponding to the ground development stage and the on-orbit maintenance stage respectively, to ensure that each stage meets the reliability requirements of SSIL-3.

[0081] At different stages of ground development of the V-model: During the requirements phase, identify all core requirements related to fault tolerance and create verifiable requirements documents.

[0082] During the design phase, a modular design architecture is adopted, while introducing time isolation (different tasks are scheduled according to fixed periods) and space isolation (core functions and non-core functions belong to independent memory partitions) to avoid the spread of a single failure affecting the whole system.

[0083] During the coding phase, code is written using safe coding subsets such as MISRA-C to reduce the risk of code defects from the source.

[0084] During the testing phase, coverage is ensured through multiple rounds of testing. Specifically, requirement coverage must reach 100% to ensure that all requirements have corresponding test cases. Modification condition / decision coverage (MC / DC) must also reach 100% to fully verify the integrity of logical decisions.

[0085] For on-orbit maintenance of the V-model, an "On-orbit Software Update Management Specification" should be formulated in advance. When it is necessary to fix software bugs discovered during on-orbit operation, the following procedures must be strictly followed: First, the fault is reproduced in a ground simulation environment to analyze and locate the root cause of the problem.

[0086] Subsequently, a fix patch was developed based on the root cause of the problem, followed by a complete regression test (covering all core functions). The test included a fault injection step to verify that the patch had no negative impact on the original functions and fault tolerance.

[0087] After passing regression testing, the patch is packaged into a differential injection package, and the data packet is encrypted and its integrity is verified to prevent it from being tampered with or damaged during transmission.

[0088] When placing bets, select a window period when the satellite is in safe mode to perform the betting operation, reducing the risk of update failure.

[0089] After the patch is completed, first load the patch to the backup partition, and then run a series of diagnostic tests, such as functional correctness tests and / or fault tolerance logic effectiveness tests, to verify whether the patch is working properly.

[0090] After the diagnostic test is passed, the software running partition will be switched to the new partition with the patch loaded, and continuous monitoring will be started to track the software running status in real time.

[0091] 3. Risk mitigation design and validation To address the core risks of ACS software operation in orbit, a closed-loop process of "risk identification - solution design - testing and verification" is employed to ensure that risks are controllable. Specifically, the process is as follows: Based on space environment analysis and fault mode derivation, the attitude calculation data (such as satellite attitude angle, angular velocity, and quaternions) stored in SRAM (Static Random Access Memory) may be damaged by space single-event upset (SEU, where high-energy particle impact causes storage bit 0 / 1 to flip), which may lead to errors in attitude control command calculation and affect satellite attitude stability.

[0092] Furthermore, for critical attitude data such as quaternions, a triple modular redundancy (TMR) storage architecture is adopted to create replicas. A low-priority background "memory wipe" task is designed to periodically read three copies of the data, vote on them, and write the correct values ​​back to the positions where errors may occur, thereby ensuring the correctness of the data.

[0093] Furthermore, in the hardware-in-the-loop (HIL) test platform, a spatial SEU failure was simulated. A single-bit flip error was randomly injected into a piece of data stored in the TMR through the debug interface to verify whether the memory wipe task could detect and correct the error in the next cycle, and whether the upper-level control function was unaffected.

[0094] 4. On-orbit evidence collection and risk warning Lightweight monitoring points are embedded in the ACS software to collect and periodically transmit three types of key data: The number of cleaning and correction cycles reflects the degree to which the SRAM is affected by radiation; Control the jitter time of the cycle; if it exceeds the threshold, it indicates an abnormal task scheduling. The watchdog reset flag, when triggered, indicates a task timeout failure.

[0095] After receiving telemetry data, the ground station automatically enters it into the database and performs trend analysis. For example, if the number of scrubbing corrections increases sharply in a short period of time, it may indicate that the satellite is passing through a high-radiation region (such as the South Atlantic Anomaly). In this case, the on-orbit software can issue an early warning and prepare to enter a temporary safety mode.

[0096] In summary, in a specific embodiment of the present invention, a complete integrity assurance system is constructed for the satellite ACS software, which greatly enhances its resistance to risks and fault tolerance. Its reliability far exceeds that of traditional design methods, ensuring that the software can operate with high reliability continuously throughout the long life cycle of the satellite.

[0097] Although various embodiments of the invention have been described above, it should be understood that they are presented by way of example only and not as limitations. It will be apparent to those skilled in the art that various combinations, modifications, and alterations can be made without departing from the spirit and scope of the invention. Therefore, the breadth and scope of the invention disclosed herein should not be limited by the exemplary embodiments disclosed above, but should be defined solely by the appended claims and their equivalents.

Claims

1. A DO-278A based satellite system software integrity assurance design method, characterized in that, The method comprises: Step S1, defining a satellite software safety integrity level SSIL which is configured to be mapped with a software integrity level SWIL defined in the DO-278A standard; Step S2, constructing a satellite-ground collaborative double V model module, the satellite-ground collaborative double V model module comprising a ground development V model and an on-orbit maintenance V model, the target and output in the DO-278A standard being mapped and adaptively cut according to the satellite software safety integrity level SSIL defined in step S1, and being applied to the satellite-ground collaborative double V model; Step S3, constructing a space software fault-tolerant architecture module which is configured to design a specific fault-tolerant mechanism according to a systemically identified satellite-specific risk, and to increase special testing and fault injection testing on the effectiveness of the fault-tolerant mechanism in a verification activity; and Step S4, constructing an on-orbit software health state monitoring and evidence collection closed-loop process module which is configured to continuously monitor and collect key data of satellite software runtime, and to form a closed-loop feedback for guiding possible on-orbit maintenance activities. In step S1, the satellite software safety integrity level SSIL is divided into five levels:

2. The method of claim 1, wherein, SSIL-0: functional failure has no impact, the SSIL-0 is mapped to SWIL-1, and is configured to not apply complete targets or to apply partial targets corresponding to SWIL-1; SSIL-1: functional failure causes task degradation or slight loss, the SSIL-1 is mapped to SWIL-2, and is configured to apply targets and outputs corresponding to SWIL-2 and to adaptively cut; SSIL-2: functional failure causes main task failure or significant asset loss, the SSIL-2 is mapped to SWIL-3, and is configured to apply targets and outputs corresponding to SWIL-3 and to increase fault-tolerant design verification for satellite risks; SSIL-3: functional failure causes satellite platform serious damage or permanent task loss, the SSIL-3 is mapped to SWIL-3 and SWIL-4, and is configured to apply all target requirements of SWIL-3 and SWIL-4; and SSIL-4: functional failure causes personnel injury, damage to other spacecraft or catastrophic ground hazards, the SSIL-4 is mapped to SWIL-4, and is configured to apply all target requirements of SWIL-4 and to increase enhanced fault-tolerant measures and / or on-orbit monitoring requirements. In step S2, the ground development V model comprises the following stages:

3. The method of claim 1, wherein, A top-level requirement definition stage which is configured to define top-level requirements and safety requirements in combination with criticality of a satellite task and a satellite software safety integrity level SSIL thereof; A system design and software requirement analysis stage which is configured to decompose the top-level requirements into a feasible system design scheme and / or software requirements; A high-level design and detailed design stage which is configured to divide software function modules, confirm a fault-tolerant architecture, and output a design scheme; A coding and unit testing stage which is configured to code a code unit module, and to carry out testing and / or function verification for each code unit; ​ a software integration and integration testing phase configured to assemble the plurality of unit modules into a complete software system and perform integration testing; and a system testing and acceptance testing phase configured to verify software functions and risk responses.

4. The method of claim 1, wherein, In step S2, the on-orbit maintenance V model includes the following phases: an on-orbit requirement change analysis and impact evaluation phase configured to evaluate the impact range of requirement changes when on-orbit requirements change; a differential package design and generation phase configured to design and generate a differential package to update the software; a secure onloading and transmission phase configured to transmit the differential package through a space-ground secure onloading link; an on-orbit loading and pre-activation verification phase configured to complete on-orbit loading of the differential package and perform pre-activation verification testing; an on-orbit testing and function confirmation phase configured to perform on-orbit testing on the loaded differential package to verify whether the changed requirements are implemented and whether the unchanged functions are affected; and a state monitoring and feedback phase configured to start an on-orbit software health state monitoring and evidence collection closed-loop process, collect key indicator data, and feed back to the ground. The ground end performs trend analysis on the returned data, and if an anomaly is found, a warning mechanism is triggered.

5. The method of claim 1, wherein, In step S3, the space software fault-tolerant architecture module includes: a watchdog timer module configured to monitor the task execution period, and trigger system reset or safety mode switching if the period is exceeded; a process health monitor module configured to detect the state, CPU occupancy, and stack usage of key processes in real time; a memory scrubbing module configured to periodically detect and correct soft errors in the memory; an instruction redundancy execution module configured to use dual-core lockstep or instruction repetition execution mechanism for critical control flow; a configuration parameter protection module configured to write-protect and periodically refresh critical registers and non-volatile memory; and a safety mode management module configured to autonomously switch to a minimum function safety mode when a serious anomaly is detected.

6. The method of claim 1, wherein, In step S3, the fault injection test includes simulating single event upset (SEU) disturbance on memory or register bits in a hardware-in-the-loop (HIL) simulation test environment to verify whether the detection and recovery capabilities and time indicators of the fault-tolerant mechanism meet the design requirements.

7. The method of claim 1, wherein In step S4, the on-orbit software health state monitoring and evidence collection closed-loop process includes: Step S41, data collection, real-time collection of running indicator data through on-board software monitoring points; Step S42, telemetry download, transmission of the collected running indicator data to the ground station; Step S43, ground processing and analysis, ground system analysis, storage, and trend analysis of the received running indicator data; Step S44, anomaly detection and warning, identification of abnormal patterns based on preset thresholds and / or machine learning algorithms, and triggering of a warning mechanism if an anomaly is detected; Step S45, decision support and feedback, based on the identification results of S44, to decide whether to perform intervention; Step S46, instruction uploading and execution. If it is determined to execute the intervention in step S45, a safety instruction and / or a differential package is generated, encrypted and verified, and then uploaded to the satellite for execution. Step S47, effect verification and closed loop formation. After the intervention is executed, the running index data is collected again to verify the effectiveness of the intervention, and a closed loop control is formed.

8. The method of claim 7, wherein, In step S41, the running index data includes: task execution period timeout count, watchdog reset count, memory ECC error correction / detection count, safety mode entry count, abnormal fluctuation of CPU occupancy rate of key processes and / or peak value of stack usage.

9. A DO-278A based satellite system software integrity assurance system, characterized by, The system includes: an SSIL standard module configured to divide a satellite software safety integrity level (SSIL) dedicated to the satellite and map it to a software integrity level (SWIL) defined in DO-278A, and to specify software requirements corresponding to different levels; a satellite-ground collaborative double V model module configured to establish a life cycle management mechanism for satellite software ground development and on-orbit maintenance; a space fault-tolerant architecture module configured to ensure that the satellite software can still run stably when facing various risks; and an on-orbit software health state monitoring and evidence collection module configured to realize real-time monitoring and timely maintenance of the on-orbit state of the satellite software by continuously collecting key data of the software running time.

10. The system of claim 9, wherein, The satellite-ground collaborative double V model module includes: a ground development V model configured to cover the whole process from requirements to integration testing, and to specify corresponding targets, inputs, outputs and activities at each stage; and an on-orbit maintenance V model configured to cover the whole process from on-orbit requirement change, differential package generation, safety uploading, on-orbit verification to activation.

Images