Satellite-borne electronic hardware design guarantee method and system

Abstract

The invention relates to a satellite-borne electronic hardware design guarantee method and system. The method comprises the following steps: determining a satellite-borne hardware guarantee level (SHL) of satellite-borne electronic hardware; integrating a fault mode injection FM I into a design process of satellite-borne electronic hardware, and adjusting the execution depth of the FM I based on the SHL level; and providing a process cutting engine, and realizing adaptive process cutting based on a DO-254 standard according to the SHL level and in combination with the execution depth of the FM I. The system comprises an SHL evaluation module; an FM I management module; a space environment effect knowledge base; and a process cutting engine. According to the method, the problem that the DO-254 standard is insufficient in adaptability in the aerospace field is solved, the reliability design and verification efficiency of satellite-borne electronic hardware is remarkably improved, and the method is suitable for aerospace tasks such as various satellites and deep space probes.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of aerospace electronics, and relates to a satellite-borne electronic hardware design guarantee method and system, in particular to a self-adaptive design guarantee method and system based on the DO-254 standard (DO-254 Airborne Electronic Device Hardware Design Guarantee Guide) and deeply adapted to the characteristics of satellite-borne electronic hardware. BACKGROUND

[0002] With the development of commercial aerospace and deep space exploration, satellites are becoming increasingly complex, and the reliability of their core satellite-borne electronic hardware (such as anti-radiation FPGA, ASIC, processor module, power controller, etc.) is crucial. Once a satellite is launched into orbit, satellite-borne electronic hardware failures are almost impossible to repair, which can lead to the failure of the entire mission and cause huge economic losses. Currently, the field of aerospace satellite-borne electronic hardware widely follows the DO-254 standard, which provides strict guidelines for the design guarantee of custom chips (ASIC / FPGA) and complex circuit boards for airborne devices (such as flight control computers for passenger aircraft). The DO-254 standard classifies satellite-borne electronic hardware into five levels (A, B, C, D, and E) based on the potential impact of functional failure on aircraft safety, with level A being the most stringent (e.g., potentially leading to aircraft crashes). However, directly applying the DO-254 standard to satellite-borne electronic hardware faces many challenges: 1) Environmental differences: Satellites face unique space environments such as single event effects (SEE), total ionizing dose (TID), displacement damage (DD), extreme temperature cycles, and high vacuum, which are less considered in the aviation field; 2) Task profile differences: The mission cycle of a satellite often lasts for several years or even decades, and it is almost impossible to maintain and repair hardware failures during the long on-orbit operation, while aircraft can be promptly inspected and repaired during regular maintenance; 3) Limitations of verification and testing: Ground simulation testing of space radiation effects is extremely costly and time-consuming, and it is difficult to 100% replicate the real environment; 4) Balance between cost and cycle: Space projects are extremely sensitive to cost and development cycle, and require more efficient allocation of reliability guarantee resources than aviation.

[0003] Currently, there is a lack of a systematic electronic hardware design guarantee method in the aerospace field that is as widely recognized and mature as the DO-254 standard in the aviation field. Some existing design methods are mostly based on the DO-254 standard, but lack systematization and comprehensiveness, making it difficult to fully address the complex space of satellite-borne electronic hardware. SUMMARY

[0004] The application provides a spaceborne electronic hardware design guarantee method and system, and specifically provides a self-adaptive design guarantee method and system based on a DO-254 standard and deeply adapted to characteristics of spaceborne electronic hardware. The application creatively adapts and extends the DO-254 standard, and forms a systematic and tailorable design guarantee guideline system specially used for spaceborne electronic hardware with high reliability, long service life and on-orbit maintenance through the spaceborne electronic hardware design guarantee method. The design guarantee guideline system is used for guiding the whole life cycle reliability guarantee activities of the spaceborne electronic hardware from requirement analysis, design, verification to on-orbit support, has the characteristics of configurability, tailorability and traceability, solves the problem of insufficient adaptability of the DO-254 standard in the field of spaceflight, significantly improves the reliability design and verification efficiency of the spaceborne electronic hardware, and is suitable for various spaceflight tasks such as satellites and deep space probes.

[0005] The first aspect of the application provides a spaceborne electronic hardware design guarantee method, including the following steps:

[0006] determining a spaceborne hardware guarantee level SHL (Space Hardware Level, SHL) level of the spaceborne electronic hardware, wherein the SHL level directly determines the depth and breadth of the subsequent spaceborne electronic hardware design guarantee method;

[0007] integrating a fault mode injection FMI (Fault Mode Injection, FMI) into a design flow of the spaceborne electronic hardware, and adjusting the execution depth of the FMI based on the SHL level; and

[0008] providing a flow tailoring engine, and realizing adaptive flow tailoring based on the DO-254 standard, the SHL level and the execution depth of the FMI.

[0009] Further, the DO-254 standard is compiled by the RTCA Special Committee-180 (SC-180), and is approved by the RTCA Program Management Committee on April 19, 2000.

[0010] Further, the design flow includes requirement definition, architecture design and detailed design stages of the spaceborne electronic hardware.

[0011] Further, the SHL level of the spaceborne electronic hardware includes the following steps:

[0012] collecting spaceborne electronic hardware evaluation parameters;

[0013] constructing a multi-dimensional satellite-borne electronic hardware criticality evaluation model, calculating a SHL score based on a satellite mission requirement (satellite mission, orbit type, mission life, functional performance index, etc.) based on the satellite-borne electronic hardware criticality evaluation model and the satellite-borne electronic hardware evaluation parameters; and

[0014] mapping the SHL score to the SHL level according to a mapping rule.

[0015] Further, the satellite-borne electronic hardware evaluation parameters include a functional definition of the satellite-borne electronic hardware, a task background, a component list (such as whether it is a radiation-resistant device), and an orbit environment parameter (such as radiation intensity) of satellite operation, providing basic data for subsequent scoring.

[0016] Further, in the multi-dimensional satellite-borne electronic hardware criticality evaluation model, the multi-dimensions include:

[0017] functional criticality (the functional criticality refers to the influence degree of the functional failure of the satellite-borne electronic hardware on the satellite mission (such as platform safety, core load function, and task benefit)), which includes:

[0018] mission criticality: if the satellite-borne electronic hardware affects the satellite survival or core task function, it is evaluated as mission critical, corresponding to a score of 3 points;

[0019] system criticality: if the satellite-borne electronic hardware affects part of the function but can be degraded, it is evaluated as system critical, corresponding to a score of 2 points; and

[0020] non-criticality: if the satellite-borne electronic hardware only affects auxiliary functions, it is evaluated as non-critical, corresponding to a score of 1 point;

[0021] on-orbit recoverability (the on-orbit recoverability refers to whether the function of the satellite-borne electronic hardware can be recovered through on-board backup, software fault tolerance, or ground instruction), which includes:

[0022] complete recoverability: if the satellite-borne electronic hardware has redundancy or software fault tolerance capability,

[0023] it is evaluated as complete recoverability, corresponding to a score of 1 point;

[0024] partial recoverability: if only part of the function of the satellite-borne electronic hardware can be recovered and needs to be degraded, it is evaluated as partial recoverability, corresponding to a score of 2 points; and

[0025] non-recoverability: if the satellite-borne electronic hardware has no recovery mechanism, it is evaluated as non-recoverable, corresponding to a score of 3 points; and

[0026] Space environment sensitivity (the space environment sensitivity refers to the inherent sensitivity of onboard electronic hardware to SEE, TID, etc., based on factors such as component manufacturing process, packaging type, and orbital environment (based on manufacturing process, structure, etc.)), which includes:

[0027] Highly sensitive: If the onboard electronic hardware is an unhardened commercial device, or is known to be sensitive to SEE or TID, it is assessed as highly sensitive, with a corresponding score of 3.

[0028] Medium Sensitive: If the onboard electronic hardware has been hardened with some radiation-resistant components or has protective measures, it is assessed as medium sensitive, corresponding to a score of 2 points; and

[0029] Low sensitivity: If the onboard electronic hardware is a radiation-resistant device certified by NASA (National Aeronautics and Space Administration) or ESA (European Space Agency), it is assessed as low sensitivity, with a corresponding score of 1 point; the weights of functional criticality, on-orbit recoverability, and space environment sensitivity are 0.4-0.5, 0.2-0.3, and 0.1-0.2, respectively, and the total weight of functional criticality, on-orbit recoverability, and space environment sensitivity is 1.

[0030] More preferably, the weights corresponding to functional criticality, on-orbit recoverability, and space environment sensitivity are 0.5, 0.3, and 0.2, respectively.

[0031] Furthermore, the criticality assessment model for the spaceborne electronic hardware is a weighted scoring model.

[0032] Furthermore, in the context of the onboard electronic hardware affecting satellite survival or core mission functions, core missions refer to critical tasks that the satellite must complete. Failure of these functions could lead to mission failure or satellite loss. For example, these functions affecting satellite survival or core mission functions include satellite platform safety functions (such as attitude control (ADCS), orbit control, power management, and thermal control systems), core payload functions (such as image acquisition and processing for remote sensing satellites, signal forwarding and routing for communication satellites, positioning signal generation for navigation satellites, and data acquisition and storage for scientific exploration satellites), and mission-critical data links (such as core communication links with ground stations and payload data downlinks).

[0033] Furthermore, the onboard electronic hardware only affects auxiliary functions, which refer to functions that have a minor impact on the overall satellite mission. Their failure will not lead to mission failure, but may affect performance or convenience. For example, the auxiliary functions include internal diagnostics and health monitoring (such as temperature sensor readings and voltage monitoring logs), non-critical communication (such as debugging interfaces and auxiliary data reporting (non-real-time mission data)), auxiliary payload control (such as switching control of non-core instruments (such as background radiation monitors)), and user interface functions (such as auxiliary parsing of ground commands and configuration of non-critical parameters).

[0034] Furthermore, the onboard electronic hardware consists of unhardened commercial devices, including: STM32F429 (MCU), TM4C1231 H6PZ (CPU), MAX3490EESA (422 transceiver), MAX823SEUK (watchdog), AD7606BSTZ (A / D converter), TL082HIDR (operational amplifier), REG1117-3.3 (voltage regulator), and DAC80504 (D / A converter).

[0035] Furthermore, the onboard electronic hardware has been hardened with some radiation-resistant components, or has protective measures in place. Some of these radiation-resistant components include the D26LV31 (485 level converter) and RSW1201. URH3V3 (current voltage regulator), RCS7469T1 (MOSFET), 2N2222AUB (transistor), HT850M10G4T4R-80mm-A (optical transceiver), ATmegaS64M!-MA-HP (MCU), and XHOA4T4R-001-50mm (optical module). Protective measures refer to measures taken to reduce the impact of radiation through design or external means, including hardware and system-level strategies. For example, the protective measures include design-level and system-level protective measures; design-level protective measures include redundant design (such as triple modular redundancy (TMR), dual redundant power supplies), error handling (such as EDAC (error detection and correction), watchdog timers, state machine protection), and filtering and debouncing (such as RC filter circuits, signal debouncing logic); system-level protective measures include radiation shielding (such as aluminum or tungsten shielding layers, local shielding covers), fault recovery mechanisms (such as automatic switching of redundant units, safe mode triggering), and periodic refresh (such as periodic memory read / write to prevent accumulated errors).

[0036] Furthermore, in calculating the SHL score based on the aforementioned onboard electronic hardware criticality assessment model, the SHL score is calculated using a weighted scoring method. The formula for calculating the SHL score is as follows:

[0037] SHL_Score=0.5×F+0.3×R+0.2×S

[0038] Where SHL_Score is the SHL score; F, R, and S are the SHL scores for functional criticality, on-orbit recoverability, and space environment sensitivity, respectively; and / or

[0039] The SHL levels include SHL-0, SHL-1, SHL-2, and SHL-3, and the mapping rule is as follows:

[0040] When the SHL score is ≤1.5, the SHL level is SHL-0;

[0041] When 1.5 < SHL score ≤ 2.2, the SHL level is SHL-1;

[0042] When 2.2 < SHL score ≤ 2.7, the SHL level is SHL-2; and

[0043] When the SHL score is greater than 2.7, the SHL level is SHL-3.

[0044] Furthermore, the SHL level serves as the basis for tailoring the design assurance process, determining the depth and breadth of design assurance activities required for different levels of onboard electronic hardware: when the SHL level is SHL-0, it indicates that the onboard electronic hardware is non-critical, simplifying the design assurance process and requiring only basic verification; when the SHL level is SHL-1, it indicates that the onboard electronic hardware is moderately critical, requiring the execution of some DO-254 objectives, which can simplify formal verification; when the SHL level is SHL-2, it indicates that the onboard electronic hardware is highly critical, requiring the execution of most DO-254 objectives, including fault injection testing; when the SHL level is SHL-3, it indicates that the onboard electronic hardware is the most critical, requiring compliance with DO-254 Level A requirements.

[0045] Furthermore, the basic verification applies to non-critical hardware at SHL-0 level, aiming to ensure that the hardware performs basic functions under normal conditions without requiring complex space environment testing. For example, the object of basic verification is non-critical hardware (such as auxiliary temperature sensors, non-core data interfaces); the verification methods include: functional correctness verification: confirming that the hardware logic is error-free through simulation or a simple test bench; and basic reliability testing: such as continuous operation testing at normal temperature and pressure; the degree of basic verification is to only cover the core functional path, without requiring high code coverage; and no fault injection or radiation simulation testing is performed (example: verifying that the temperature sensor can correctly read data, but not testing its behavior under radiation).

[0046] Furthermore, the simplified formal verification is applicable to medium-critical hardware at SHL-1 level. It is more rigorous than basic verification but less complete than high-level verification, focusing on the formal analysis of key attributes. For example, the simplified formal verification targets medium-critical hardware (such as data bus controllers and medium-importance state machines); the verification methods include: selective formal verification: performing formal analysis only on safety-critical attributes (such as deadlock avoidance and state consistency); and simplified toolchain: using lightweight formal verification tools instead of full-process formal verification; the degree of simplification is that it does not require full-chip formal verification, but only for some modules or interfaces (example: verifying whether the data bus controller will not experience arbitration deadlock, but not verifying all data transmission scenarios).

[0047] Furthermore, the design process for integrating FMI into onboard electronic hardware includes the following steps:

[0048] In the requirements phase: Construct a knowledge base on space environment effects, analyze the potential failure modes of the spaceborne electronic hardware based on the knowledge base, and transform the failure modes into reliability requirements;

[0049] During the design phase: Mitigation measures are written into the mitigation measures document as part of the design requirements, and the mitigation measures are clearly defined in the design process;

[0050] During the verification phase: the effectiveness of mitigation measures is verified through fault injection testing; and

[0051] Integrating with EDA (Electronic Design Automation) tools via APIs (Application Programming Interfaces) or plugins enables automated prompts and checks, ensuring design robustness; and / or

[0052] The space environment effects knowledge base contains various failure modes of different spaceborne electronic hardware (such as memory, processors, and power chips) under space radiation, heat, and vacuum environments. These failure modes include Single Event Upset (SEU), Single Event Latchup (SEL), and gate lock (a functional deadlock caused by circuit logic design defects or external interference). This invention integrates FMI as a mandatory process node into the requirements definition, architecture design, and detailed design phases of hardware design. Designers must systematically analyze potential space environment failures their designs may encounter based on the space environment effects knowledge base and incorporate mitigation measures (such as triple modular redundancy (TMR), EDAC, watchdog timers, and radiation-hardened selection) as part of the design requirements into the documentation.

[0053] Furthermore, the document explicitly records the design measures (such as redundancy, error correction, filtering, etc.) taken to address space environment failures, as part of the design output, for subsequent verification and traceability.

[0054] Furthermore, the test object of the fault injection test is an FPGA prototype or simulation model; the test process is: injecting fault → running test cases → monitoring response → recording results; the test result is: generating a test report, including error correction rate and recovery time, etc.

[0055] Furthermore, the EDA tools include Vivado and Questasim; Vivado is an FPGA (Field Programmable Gate Array) integrated design environment (IDE) launched by Xilinx; Questasim is a high-performance digital circuit simulation and verification tool launched by Siemens.

[0056] Furthermore, during the verification phase, the effectiveness of the mitigation measures is verified through fault injection testing. If the mitigation measures are effective, it indicates that the fault protection design meets the requirements and can be smoothly integrated with the traditional V model (referring to the waterfall development model from requirements → design → implementation → verification, emphasizing phase correspondence and traceability), and proceed to the subsequent development or delivery stage. If the mitigation measures are ineffective (e.g., the EDAC error correction rate does not meet the standard), the mitigation measures need to be adjusted, and the fault mitigation scheme needs to be optimized again in the design phase before re-entering the verification phase.

[0057] Furthermore, based on the aforementioned space environment effects knowledge base, the potential failure modes of the spaceborne electronic hardware are analyzed using FMEA (Failure Mode and Effects Analysis) or FMECA (Failure Mode, Effects, and Criticality Analysis) methods; and / or

[0058] The mitigation measures include Triple Modular Redundancy (TMR), EDAC, filtering circuits, watchdog timers, and radiation-hardened selection. Radiation-hardened selection refers to prioritizing radiation-hardened devices (such as radiation-hardened FPGAs, AS ICs, and memory) that are insensitive to space radiation like SEE and TID, based on a knowledge base of space environment effects, during the component selection phase.

[0059] Furthermore, after analyzing the potential failure modes of the onboard electronic hardware using FMEA or FMECA methods, mitigation measures are formulated and recorded, forming a "Reliability Design Analysis Report".

[0060] Furthermore, a process pruning engine is provided, based on the DO-254 standard, to achieve adaptive process pruning according to the SHL level and in combination with the execution depth of the FMI, including the following steps:

[0061] SHL rating and project constraints are used as the process trimming inputs for the process trimming engine;

[0062] The applicability of each design assurance objective (requirements traceability, code coverage, formal verification, etc.) in the DO-254 standard is assessed using decision trees or questionnaires; and

[0063] Based on the SHL rating, dynamically select the execution strategy of the DO-254 standard to generate a Hardware Design Assurance Plan (HDAP) to clarify the tailoring rules and execution standards, thereby achieving adaptive process tailoring; and / or

[0064] The process pruning engine is a software module or a decision support system; and / or

[0065] The project constraints include cost budget, development cycle, and technology maturity.

[0066] Furthermore, the HDAP explicitly indicates mandatory, simplified, or omitted steps in the process. It clarifies the design assurance activities required for the project, avoiding resource waste. All subsequent design assurance activities follow the HDAP guidelines, replacing the "one-size-fits-all" requirements of the general DO-254 standard. Specifically, the HDAP clearly indicates which DO-254 standard "objectives" are mandatory, optional, and can be simplified for a specific SHL-level project (a spaceborne electronic hardware development task, such as image processing FPGAs, spaceborne computers, etc.), avoiding "over-assurance." The HDAP includes process execution strategies, verification plans, documentation requirements, review milestones, etc.

[0067] Furthermore, it also includes:

[0068] Perform enhanced verification and validation (V&V), which includes:

[0069] Forced fault injection testing is performed on all fault tolerance and fault recovery mechanisms to ensure they respond correctly in the event of a real-world failure. These mechanisms include redundancy switching, safe mode triggering, and / or

[0070] Simulation testing of RTL (Register Transfer Level Code) code is performed to verify functional correctness and ensure the reliability and robustness of the design; and / or

[0071] Radiation experiments were conducted in a simulated space radiation environment on the ground to verify the radiation resistance of the onboard electronic hardware. Addressing the unmaintainable nature of on-orbit systems, this invention strengthens the requirements for reliability growth testing and fault handling process verification. In addition to traditional simulation and FPGA prototyping verification, fault injection testing is mandatory for all fault tolerance and fault recovery mechanisms to ensure they respond correctly in the event of actual failures.

[0072] Furthermore, it also includes:

[0073] Delivery and on-orbit support include outputting design documents, verification reports, and on-orbit diagnostic guidelines. The design documents include HDL code, schematics, and placement and routing files. The verification reports include simulation reports, test coverage reports, and fault injection test reports. The on-orbit diagnostic guidelines include anomaly handling manuals and telemetry interpretation guidelines. The on-orbit diagnostic guidelines are one of the final outputs of the design assurance process. They are based on the FMI analysis and verification results from the design phase. The content of the on-orbit diagnostic guidelines includes anomaly telemetry characteristics, possible failure modes, ground command response strategies, restart / switchover procedures, etc. The purpose of the on-orbit diagnostic guidelines is to provide ground control personnel with a basis for on-orbit fault diagnosis and handling.

[0074] A second aspect of the present invention provides a system for implementing the above-described method, the system comprising:

[0075] The SHL assessment module is configured to provide an SHL assessment interface and calculate the SHL rating.

[0076] The FMI management module is configured to manage fault mode injection and analyze potential fault modes of the onboard electronic hardware. The FMI management module is integrated into the design flow of the onboard electronic hardware and adjusts the execution depth of FMI based on the SHL level.

[0077] A space environment effects knowledge base, configured to provide underlying data support for the SHL assessment module and FMI management module, stores failure modes and mitigation measures; and

[0078] The process tailoring engine is configured to use the SUL level output by the SHL evaluation module as the decision variable, and combine project constraints and FMI execution depth to generate HDAP based on the DO-254 standard. The HDAP specifies the execution depth for the FMI management module to achieve adaptive process tailoring.

[0079] Furthermore, these modules together constitute an integrated design assurance platform, with the following data flow: SHL assessment → process tailoring → FMI integration → verification reinforcement → output delivery.

[0080] Furthermore, the HDAP specifies the execution depth for the FMI management module, including: determining the scope of fault injection testing; and specifying the types and number of fault modes.

[0081] This method constructs a critical assessment model for spaceborne electronic hardware, injects space environment failure modes into the FMI process and integrates it into the design phase, and dynamically tailors the design assurance process based on SHL levels. It can establish a set of spaceborne electronic hardware design assurance guidelines that cover the entire design lifecycle, can dynamically adjust the severity level, and deeply integrate space environment adaptability. The design assurance guidelines system refers to a set of structured methods, processes, tools, and document templates used to guide the reliability assurance activities of spaceborne electronic hardware throughout its entire lifecycle, from requirements analysis, design, verification to on-orbit support. It is characterized by being configurable, customizable, and traceable.

[0082] This invention has at least the following beneficial effects: 1) This invention proposes for the first time a systematic electronic hardware design assurance method that is deeply adapted to the characteristics of aerospace. Through the critical evaluation model of spaceborne electronic hardware and adaptive process tailoring, it significantly improves the efficiency of reliability engineering and avoids resource waste; 2) This invention, through the embedded space environment effect library and FMI process, advances reliability design and greatly reduces the risk of on-orbit failure; 3) This invention solves the problem of insufficient adaptability of the DO-254 standard in the aerospace field, significantly improves the reliability design and verification efficiency of spaceborne electronic hardware, and is applicable to various satellites, deep space probes and other aerospace missions. Attached Figure Description

[0083] To further illustrate the above and other advantages and features of the various embodiments of the present invention, a more specific description of the embodiments of the invention will be presented with reference to the accompanying drawings. It is to be 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 identical or similar reference numerals for clarity.

[0084] Figure 1 The overall flow of the design assurance method for spaceborne electronic hardware in some embodiments of the present invention is shown;

[0085] Figure 2 The evaluation dimensions and decision-making flowchart of the critical evaluation model for spaceborne electronic hardware in some embodiments of the present invention are shown.

[0086] Figure 3 This diagram illustrates the integration of the fault mode injection process with the traditional hardware design process in some embodiments of the present invention.

[0087] Figure 4The working mechanism of the process trimming engine in some embodiments of the present invention is shown (left sub-process: input and applicability judgment; right sub-process: dynamic trimming and HDAP generation). Detailed Implementation

[0088] It should be noted that the components in the accompanying drawings may be shown exaggerated for illustrative purposes and may not be to scale.

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

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

[0091] It should also be noted that, in the embodiments of the present invention, only a portion of the parts or components may be shown for clarity and simplicity. However, those skilled in the art will understand that, under the teachings of the present invention, the required parts or components can be added as needed for specific scenarios.

[0092] 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".

[0093] It should also be noted that in the description of this invention, the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not explicitly or implicitly suggest that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0094] In this invention, the modules of the system according to the invention can be implemented using software, hardware, firmware, or a combination thereof. When a module is implemented using software, its function can be implemented through computer program flow. For example, the module can be implemented using code segments (such as code segments in languages ​​like C and C++) stored in a storage device (such as a hard disk, memory, etc.), wherein the corresponding function of the module can be implemented when the code segment is executed by a processor. When a module is implemented using hardware, its function can be implemented by setting a corresponding hardware structure. For example, the module's function can be implemented by hardware programming a programmable device such as a field-programmable gate array (FPGA), or by designing an application-specific integrated circuit (ASIC) that includes multiple transistors, resistors, capacitors, and other electronic devices. When a module is implemented using firmware, the module's function can be written into a read-only memory such as an EPROM or EEPROM in the form of program code, and the corresponding function of the module can be implemented when the program code is executed by a processor. In addition, some functions of the module may need to be implemented by separate hardware or by working in cooperation with the hardware. For example, the detection function is implemented by the corresponding sensor (such as a proximity sensor, accelerometer, gyroscope, etc.), the signal transmission function is implemented by the corresponding communication device (such as a Bluetooth device, infrared communication device, baseband communication device, Wi-Fi communication device, etc.), the output function is implemented by the corresponding output device (such as a display, speaker, etc.), and so on.

[0095] Furthermore, the embodiments of the present invention describe the process steps in a specific order. However, this is only for the convenience of distinguishing each step, and is not a limitation on the order of each step. In different embodiments of the present invention, the order of each step can be adjusted according to the process.

[0096] The following embodiments provide a method for ensuring the design of spaceborne electronic hardware. Figure 1 This paper illustrates the overall flow of a design assurance method for spaceborne electronic hardware, which includes the following steps:

[0097] Determine the onboard hardware assurance level (SHL) for the onboard electronic hardware;

[0098] Integrate Fault Mode and Effects Injection (FMI) into the design flow of onboard electronic hardware, and adjust the execution depth of FMI based on the SHL level;

[0099] Provides a process trimming engine based on the DO-254 standard, which enables adaptive process trimming based on SHL level and the execution depth of FM I;

[0100] Perform enhanced verification and confirmation; and

[0101] Delivery and on-orbit support.

[0102] The SHL rating for determining the onboard electronic hardware includes:

[0103] Collect evaluation parameters for onboard electronic hardware, including the functional definition of the onboard electronic hardware, the mission background, the component list (such as whether it is a radiation-resistant device), and the orbital environment parameters of the satellite (such as radiation intensity), to provide basic data for subsequent scoring.

[0104] Construct a multi-dimensional critical evaluation model for spaceborne electronic hardware. Figure 2 The diagram illustrates the evaluation dimensions and decision-making flowchart of the onboard electronic hardware criticality assessment model. Based on satellite mission requirements (satellite mission, orbit type, mission lifespan, functional performance indicators, etc.), the SHL score is calculated using the onboard electronic hardware criticality assessment model and onboard electronic hardware evaluation parameters. The multi-dimensional onboard electronic hardware criticality assessment model includes functional criticality, on-orbit recoverability, and space environment sensitivity. Functional criticality refers to the degree of impact of onboard electronic hardware failure on the satellite mission (such as platform safety, core payload functions, and mission benefits). Functional criticality includes mission... Critical (if the onboard electronic hardware affects the satellite's survival or core mission functions, it is assessed as mission critical, corresponding to a score of 3 points), system critical (if the onboard electronic hardware affects some functions but can be degraded, it is assessed as system critical, corresponding to a score of 2 points), and non-critical (if the onboard electronic hardware only affects auxiliary functions, it is assessed as non-critical, corresponding to a score of 1 point); Orbit recoverability refers to whether the functions of the onboard electronic hardware can be restored through onboard backup, software fault tolerance, or ground commands. Orbit recoverability includes full recovery (if the onboard electronic hardware has redundancy or software fault tolerance capabilities). The assessment criteria are as follows: fully recoverable (1 point), partially recoverable (if only some functions of the onboard electronic hardware are recoverable and degraded operation is required, then it is assessed as partially recoverable, with a score of 2 points), and unrecoverable (if the onboard electronic hardware has no recovery mechanism, then it is assessed as unrecoverable, with a score of 3 points); Space environment sensitivity refers to the assessment of the inherent sensitivity of onboard electronic hardware to SEE, TID, etc., based on factors such as component technology, packaging type, and orbital environment. Space environment sensitivity includes high sensitivity (if the onboard electronic hardware is an unhardened commercial device, or is known to be sensitive to SEE or TID). Sensitive (D) is assessed as highly sensitive, corresponding to a score of 3 points; moderately sensitive (if the onboard electronic hardware has been hardened with some radiation-resistant components or has protective measures, it is assessed as moderately sensitive, corresponding to a score of 2 points); and low sensitive (if the onboard electronic hardware is a radiation-resistant component certified by NASA or ESA, it is assessed as low sensitive, corresponding to a score of 1 point). The weights for functional criticality, on-orbit recoverability, and space environment sensitivity are 0.5, 0.3, and 0.2 respectively (specific values ​​can be adjusted according to the project). The SHL score is calculated using a weighted scoring method. The formula for calculating the SHL score is:

[0105] SHL_Score=0.5×F+0.3×R+0.2×S

[0106] Where SHL_Score is the SHL score; F, R, and S are the SHL scores for functional criticality, on-orbit recoverability, and space environment sensitivity, respectively; SHL levels include SHL-0, SHL-1, SHL-2, and SHL-3, with the mapping rule being: when the SHL score ≤ 1.5, the SHL level is...

[0107] SHL-0; when 1.5 < SHL score ≤ 2.2, the SHL level is SHL-1; when 2.2 < SHL score ≤ 2.7, the SHL level is SHL-2; when the SHL score > 2.7, the SHL level is...

[0108] SHL-3; When the SHL level is SHL-0, it indicates that the onboard electronic hardware is non-critical, simplifying the design assurance process and requiring only basic verification; when the SHL level is SHL-1, it indicates that the onboard electronic hardware is medium-critical, requiring the execution of some DO-254 objectives, but formal verification can be simplified; when the SHL level is SHL-2, it indicates that the onboard electronic hardware is high-critical, requiring the execution of most DO-254 objectives, including fault injection testing; when the SHL level is SHL-3, it indicates that the onboard electronic hardware is the highest-critical, requiring compliance with DO-254 Level A requirements;

[0109] Figure 3 This diagram illustrates the integration of the Fault Mode Injection (FMI) process with the traditional hardware design flow. Integrating FMI into the design flow of onboard electronic hardware includes the following steps:

[0110] During the requirements phase: A knowledge base on space environment effects is constructed. Based on this knowledge base, potential failure modes of onboard electronic hardware are analyzed using FMEA or FMECA methods. Mitigation measures are formulated and recorded, resulting in a "Reliability Design Analysis Report." Mitigation measures include triple-modular redundancy (TMR), EDAC, filtering circuits, watchdog timers, and radiation protection selection. Failure modes are transformed into reliability requirements. The knowledge base on space environment effects contains various failure modes of different onboard electronic hardware (such as memory, processors, and power chips) affected by space radiation, heat, and vacuum environments. Failure modes include Single Event Upset (SEU), Single Event Latchup (SEL), and door locks.

[0111] During the design phase: Mitigation measures should be included as part of the design requirements in the mitigation measures document, and the mitigation measures should be clearly defined in the design process;

[0112] During the verification phase: The effectiveness of mitigation measures is verified through fault injection testing. The test object for fault injection testing is an FPGA prototype or simulation model. The testing process is: injecting faults → running test cases → monitoring responses → recording results. The test results include generating a test report, including error correction rate and recovery time. If the mitigation measures are effective, it indicates that the fault protection design meets the requirements and can be smoothly integrated with the traditional V model (referring to the waterfall development model from requirements → design → implementation → verification, emphasizing phase correspondence and traceability), entering subsequent development or delivery stages to form a closed-loop reliability design mechanism. If the mitigation measures are ineffective (e.g., the EDAC error correction rate is not up to standard), the mitigation measures need to be adjusted, returning to the design phase to optimize the fault mitigation scheme, and re-entering the verification phase.

[0113] By integrating with EDA tools (Vivado, Questasim) through APIs or plugins, automated suggestions and checks can be achieved to ensure design robustness.

[0114] Figure 4 The working mechanism of the process trimming engine is shown. Figure 4 In this context, "DO" stands for "Design Objective," referring to the design assurance objectives defined in the DO-254 standard, such as requirements traceability, code coverage analysis, formal verification, and fault injection testing. "C" stands for "Compliance" or "Condition."

[0115] (Condition) is an abbreviation for the judgment condition or compliance status of each design goal, such as whether it is mandatory, whether it can be simplified, or whether it can be omitted. Figure 4 This demonstrates how the process tailoring engine dynamically generates a Hardware Design Assurance Plan (HDAP) based on SHL levels and project constraints, by determining the "C" (Compliance / Condition) of each "DO" (Document), thus achieving adaptive process tailoring. Specifically, Figure 4 It comprises two parts (left and right sub-processes). The left sub-process performs logical judgments, while the right sub-process executes the generation process, describing the complete decision-making process from input conditions to the generation of the final plan. A process pruning engine is provided, based on the DO-254 standard, to achieve adaptive process pruning according to SHL levels and combined with FM I execution depth, including the following steps:

[0116] The SHL rating and project constraints (cost budget, development cycle and technology maturity) are used as inputs for the process tailoring engine.

[0117] The applicability of each design assurance objective (requirements traceability, code coverage, formal verification, etc.) in the DO-254 standard is assessed using decision trees or questionnaires; and

[0118] A Hardware Design Assurance Plan (HDAP) is generated to clarify tailoring rules and execution standards, enabling adaptive process tailoring. The HDAP explicitly indicates mandatory, simplified, or omitted steps in the process, clarifying the design assurance activities required for the project and avoiding resource waste. All subsequent design assurance activities are based on the HDAP, replacing the "one-size-fits-all" requirements of the general DO-254 standard. Specifically, the HDAP clearly indicates which DO-254 standard "objectives" are mandatory, optional, and can be simplified for a specific SHL-level project (a spaceborne electronic hardware development task, such as image processing FPGA, spaceborne computers, etc.), avoiding "over-assurance." The HDAP includes process execution strategies, verification plans, documentation requirements, review nodes, etc.; the process tailoring engine is a software module or decision support system; and / or

[0119] Perform enhanced verification and validation, including:

[0120] Mandate fault injection testing of all fault tolerance and fault recovery mechanisms to ensure they respond correctly in the event of a real-world failure. These mechanisms include redundancy switching, safe mode triggering, and / or...

[0121] Simulation testing of RTL (Register Transfer Level Code) code is performed to verify functional correctness and ensure the reliability and robustness of the design; and / or

[0122] Radiation experiments were conducted in a simulated space radiation environment on the ground to verify the radiation resistance of the onboard electronic hardware. Addressing the unmaintainable nature of on-orbit systems, this invention strengthens the requirements for reliability growth testing and fault handling process verification. In addition to traditional simulation and FPGA prototyping verification, fault injection testing is mandatory for all fault tolerance and fault recovery mechanisms to ensure they respond correctly in the event of actual failures.

[0123] Delivery and on-orbit support include output design documents, verification reports, and on-orbit diagnostic guidelines. Design documents include HDL code, schematics, and place-and-route files. Verification reports include simulation reports, test coverage reports, and fault injection test reports. On-orbit diagnostic guidelines include anomaly handling manuals and telemetry interpretation guidelines. The on-orbit diagnostic guidelines are one of the final outputs of the design assurance process. Based on the FMI analysis and verification results from the design phase, the guidelines include anomaly telemetry characteristics, possible failure modes, ground command response strategies, restart / switchover procedures, etc. The purpose of the on-orbit diagnostic guidelines is to provide ground control personnel with a basis for on-orbit fault diagnosis and handling.

[0124] Taking an FPGA used for image data processing from a low Earth orbit (LEO) remote sensing satellite as an example, this design assurance method includes the following steps:

[0125] The onboard hardware assurance level (SHL) of the image data processing FPGA is determined as follows: The image data processing FPGA is functionally critical (affecting core scientific data), can be partially restored in orbit by switching back the image data processing FPGA, is sensitive to SEU, and is comprehensively rated as SHL-2.

[0126] Fault Mode and Effects Injection (FM I) is integrated into the design flow of onboard electronic hardware, and the execution depth of FM I is adjusted based on the SHL level: Based on the knowledge base of space environment effects, it is known that SRAM-type FPGAs are prone to SEUs (Search Engine Unlocking). Therefore, the requirements explicitly state that: TMR (Triple Modular Redundancy) is used for critical state machines and control registers; SEC-DED EDAC (Single Error Correction, Double Error Detection, Error Detection and Correction) protection is used for the frame buffer (the internal storage area of ​​onboard electronic hardware used to temporarily store critical information such as image data) to address potential data errors caused by the space environment and ensure the integrity and correctness of data within the frame buffer.

[0127] Provides a process trimming engine based on the DO-254 standard, which achieves adaptive process trimming according to the SHL level and combined with the execution depth of FMI: Because it is SHL-2, the process trimming engine requires code coverage analysis, but can simplify some formal verification; it requires accelerated life testing, but the total dose test conditions can be accurately calculated based on LEO orbital parameters instead of using the highest standard.

[0128] Perform enhanced verification and validation: Conduct fault injection testing. During testing (dynamic testing in an FPGA prototype or simulation environment, simulating faults caused by space radiation to verify the design's fault tolerance), specifically inject SEU faults to verify whether the TMR and EDAC functions correctly correct errors, and verify the effectiveness of the backup switching process (injecting single / multi-bit flip faults; checking whether the TMR can correct errors by voting; checking whether the EDAC can detect and correct errors; recording the error correction success rate and system recovery time); and

[0129] Delivery and On-Orbit Support: Output verified FPGA bitstreams and an on-orbit image processing FPGA anomaly handling manual.

[0130] In the design assurance methods described above for FPGAs used in image data processing, the choice to use TMR for critical state machines and control registers (and other similar critical logic) is a comprehensive decision based on the FMEA process, primarily based on:

[0131] Highly critical: their failure directly leads to mission failure;

[0132] High sensitivity: Composed of SRAM, susceptible to SEU influence;

[0133] Low detectability / recoverability: Prone to "silent errors" that cannot be recovered from with simple operations;

[0134] Resource acceptability: Although the cost is high, it is necessary and acceptable to protect core functionality.

[0135] In contrast, large data storage units such as frame buffers are protected using the more resource-efficient EDAC scheme because errors in them are localized and easily detected and corrected.

[0136] Specifically, while the requirements document explicitly lists "critical state machines" and "control registers" as application targets for TMR in the context of critical state machines and control registers, this is only a minimum requirement based on their extreme criticality. In actual design, engineers, based on FMEA analysis, include all logic units that, if malfunctioning, could lead to mission failure or threaten satellite safety within the protection scope of TMR. That is, in practical engineering design, beyond critical state machines and control registers, based on the same evaluation principles, the following types of logic or memory units are typically also considered for inclusion in TMR or similar high-level protection:

[0137] Configuration registers: These registers are used to set the operating parameters of various IP cores within the FPGA (such as memory controllers, high-speed interfaces, etc.). If tampered with by a single-event upset (SEU), it may cause the entire interface or functional module to malfunction.

[0138] Command decoder: Responsible for parsing the logic of instructions from the starship master computer. If an error occurs, it may execute incorrect instructions, leading to catastrophic consequences.

[0139] Critical counters and timers: For example, counters responsible for generating image sensor exposure timing and data packet frame header synchronization signals. Errors in these counters can directly lead to data acquisition failure or data stream corruption.

[0140] Watchdog timer: A critical safety logic used to monitor whether the system has malfunctioned. It must be highly reliable; otherwise, the reset and recovery functions cannot be executed correctly.

[0141] In this embodiment, the design assurance method for onboard electronic hardware can be implemented through a combination of software toolchain and manual review. The specific steps are as follows:

[0142] 1. Construct a knowledge base for space environmental effects:

[0143] 1) The knowledge base on space environmental effects adopts a relational database structure. The table structure includes: component type, process node, failure mode (such as SEU, SEL, TID failure threshold), mitigation measures, and test data source, etc.

[0144] 2) Supports user-defined extensions and can be integrated with EDA tools (such as Vivado and Quartus) to achieve real-time fault mode prompts during the design phase.

[0145] 2. SHL rating calculation:

[0146] 1) Provide a graphical or form-based evaluation interface where users input scores for each dimension;

[0147] 2) Weighted Algorithm Example: Functional Criticality (weight 0.5), Recoverability (weight 0.3), Environmental Sensitivity (weight 0.2). Total Score = ∑(Dimension Score × Weight), and SHL levels are determined based on thresholds.

[0148] 3. Fault injection test:

[0149] 1) Use a hardware simulation platform (such as Veloce, Palladium) or FPGA prototyping system to inject faults (such as bit flips, power supply disturbances) through JTAG or a dedicated interface.

[0150] 2) Monitor system response, record indicators such as recovery time and error correction rate, and generate test reports.

[0151] 4. Process trimming tool:

[0152] 1) Develop a web or local application that provides a questionnaire-style interactive interface.

[0153] 2) Dynamically generate HDAP document templates that conform to DO-254 objectives based on the SHL and project attributes input by the user.

[0154] 5. Integration with existing development processes:

[0155] 1) Supports exporting requirements to requirements management tools such as DOORS and Jama.

[0156] 2) Verification results can be automatically traced back to requirements, supporting compliance audits.

[0157] While some embodiments of the present invention have been described in this application, those skilled in the art will understand that these embodiments are merely illustrative. Numerous variations, alternatives, and improvements will arise in those skilled in the art under the teachings of this invention without departing from its scope. The appended claims are intended to define the scope of the invention and thereby cover methods and structures within the scope of the claims themselves and their equivalents.

Claims

1. A method for ensuring the design of spaceborne electronic hardware, characterized in that, Includes the following steps: Determine the onboard hardware assurance level (SHL) for the onboard electronic hardware; The design flow for integrating Fault Mode and Effects Injection (FM I) into onboard electronic hardware is modified by adjusting the execution depth of FM I based on the SHL level; and Provides a process pruning engine based on the DO-254 standard, which enables adaptive process pruning according to the SHL level and the execution depth of the FM I.

2. The method for ensuring the design of spaceborne electronic hardware according to claim 1, characterized in that, Determining the SHL rating of onboard electronic hardware involves the following steps: Collect evaluation parameters for onboard electronic hardware; A multi-dimensional criticality assessment model for spaceborne electronic hardware is constructed, and the SHL score is calculated based on the assessment model and the assessment parameters. The SHL score is mapped to the SHL level according to the mapping rules.

3. The method for ensuring the design of spaceborne electronic hardware according to claim 2, characterized in that, The multi-dimensional critical evaluation model for spaceborne electronic hardware includes the following dimensions: Functional criticality, including: Mission critical: If the onboard electronic hardware affects the satellite's survival or core mission functions, it is assessed as mission critical and the corresponding score is 3 points. System Critical: If the onboard electronic hardware affects some functions but can be degraded during operation, it is assessed as system critical, corresponding to a score of 2 points; and Non-critical: If the onboard electronic hardware only affects auxiliary functions, it is assessed as non-critical and the corresponding score is 1 point; On-orbit recoverability includes: Fully recoverable: If the onboard electronic hardware has redundancy or software fault tolerance, it is assessed as fully recoverable, with a corresponding score of 1 point; Partially recoverable: If only some functions of the onboard electronic hardware are recoverable and degraded operation is required, it is assessed as partially recoverable, corresponding to a score of 2 points; and Unrecoverable: If the onboard electronic hardware lacks a recovery mechanism, it is assessed as unrecoverable, corresponding to a score of 3. Space environment sensitivity, which includes: Highly sensitive: If the onboard electronic hardware is an unhardened commercial device, or is known to be sensitive to SEE or TID, it is assessed as highly sensitive, with a corresponding score of 3. Medium Sensitive: If the onboard electronic hardware has been hardened with some radiation-resistant components or has protective measures, it is assessed as medium sensitive, corresponding to a score of 2 points; and Low sensitivity: If the onboard electronic hardware is a radiation-resistant device that has been certified by NASA or ESA, it is assessed as low sensitivity and the corresponding score is 1 point; the weights of functional criticality, on-orbit recoverability and space environment sensitivity are 0.4-0.5, 0.2-0.3 and 0.1-0.2 respectively, and the total weight of functional criticality, on-orbit recoverability and space environment sensitivity is 1.

4. The method for ensuring the design of spaceborne electronic hardware according to claim 3, characterized in that, In calculating the SHL score based on the aforementioned onboard electronic hardware criticality assessment model, the SHL score is calculated using a weighted scoring method. The formula for calculating the SHL score is as follows: SHL_Score=0.5×F+0.3×R+0.2×S Where SHL_Score is the SHL score; F, R, and S are the SHL scores for functional criticality, on-orbit recoverability, and space environment sensitivity, respectively; and / or The SHL levels include SHL-0, SHL-1, SHL-2, and SHL-3, and the mapping rule is as follows: When the SHL score is ≤1.5, the SHL level is SHL-0; When 1.5 < SHL score ≤ 2.2, the SHL level is SHL-1; When 2.2 < SHL score ≤ 2.7, the SHL level is SHL-2; and When the SHL score is greater than 2.7, the SHL level is SHL-3.

5. The method for ensuring the design of spaceborne electronic hardware according to claim 1, characterized in that, The design process for integrating FMI into onboard electronic hardware includes the following steps: In the requirements phase: Construct a knowledge base on space environment effects, analyze the potential failure modes of the spaceborne electronic hardware based on the knowledge base, and transform the failure modes into reliability requirements; During the design phase: Mitigation measures are written into the mitigation measures document as part of the design requirements, and the mitigation measures are clearly defined in the design process; During the verification phase: the effectiveness of mitigation measures is verified through fault injection testing; and Integrate with EDA tools via API or plugin; and / or The knowledge base on space environment effects contains various failure modes of different spaceborne electronic hardware caused by space radiation, heat, and vacuum environments. These failure modes include single-event upset (SEU), single-event latch-up (SEL), and door lock.

6. The method for ensuring the design of spaceborne electronic hardware according to claim 5, characterized in that, Based on the aforementioned space environment effects knowledge base, potential failure modes of the onboard electronic hardware are analyzed using FMEA or FMECA methods; and / or The mitigation measures include triple-redundant TMR, EDAC, filter circuits, watchdog timer, and radiation protection selection.

7. The method for ensuring the design of spaceborne electronic hardware according to claim 1, characterized in that, A process pruning engine is provided, based on the DO-254 standard, to achieve adaptive process pruning according to the SHL level and the execution depth of the FMI, including the following steps: SHL rating and project constraints are used as the process trimming inputs for the process trimming engine; The applicability of each design assurance objective in the DO-254 standard can be determined using rule engines and decision trees, or through questionnaires; and Generate a Hardware Design Assurance Plan (HDAP) to clarify pruning rules and execution standards, enabling adaptive process pruning; and / or The process pruning engine is a software module or a decision support system; and / or The project constraints include cost budget, development cycle, and technology maturity.

8. The method for ensuring the design of spaceborne electronic hardware according to claim 1, characterized in that, Also includes: Perform enhanced verification and confirmation, which includes: Forced fault injection testing is performed on all fault tolerance and fault recovery mechanisms to ensure that they can respond correctly when a fault actually occurs. The fault tolerance and fault recovery mechanisms include redundancy switching and safe mode triggering. and / or Simulation tests were performed on the RTL code to verify functional correctness; and / or Radiation tests were conducted on the ground to simulate the space radiation environment in order to verify the radiation resistance of the spaceborne electronic hardware.

9. The method for ensuring the design of spaceborne electronic hardware according to claim 1, characterized in that, Also includes: Delivery and on-orbit support include output design documents, verification reports, and on-orbit diagnostic guidelines. The design documents include HDL code, schematics, and place-and-route files. The verification reports include simulation reports, test coverage reports, and fault injection test reports. The on-orbit diagnostic guidelines include anomaly handling manuals and telemetry interpretation guidelines.

10. A system for implementing the method according to any one of claims 1-9, characterized in that, The system includes: The SHL assessment module is configured to provide an SHL assessment interface and calculate the SHL rating. The FMI management module is configured to manage fault mode injection and analyze potential fault modes of the onboard electronic hardware. The FMI management module is integrated into the design flow of the onboard electronic hardware and adjusts the execution depth of FMI based on the SHL level. A space environment effects knowledge base, configured to provide underlying data support for the SHL assessment module and FMI management module, stores failure modes and mitigation measures; and The process tailoring engine is configured to use the SUL level output by the SHL evaluation module as the decision variable, and combine project constraints and FMI execution depth to generate HDAP based on the DO-254 standard. The HDAP specifies the execution depth for the FMI management module to achieve adaptive process tailoring.

Images