Security verification method of spacecraft digital-real fusion test system and computer device

Abstract

The invention relates to a security verification method of a spacecraft digital-real fusion test system and a computer device, and belongs to the technical field of security argumentation. According to the safety process and the system development process of the spacecraft digital-real fusion test system, the spacecraft digital-real fusion test system is divided into a plurality of parts, the GSN safety cases are created for all the parts of the digital-real fusion test system, and when the safety cases of all the parts are created, the safety targets to be achieved of the parts are determined firstly, and then the safety targets to be achieved of the parts are determined; and determining a corresponding claim and each sub-target according to the security target, decomposing the sub-targets again until the sub-targets cannot be decomposed, and performing evidence collection on the sub-targets which cannot be decomposed again so as to establish security cases of all parts. Safety analysis can be performed on the spacecraft digital-real fusion test system through a graphic representation method according to the constructed safety cases of all the parts, the whole verification process can be visually displayed, and full-cycle safe and reliable operation of the spacecraft digital-real fusion test system is ensured.

Description

Technical Field

[0001] The invention relates to a safety verification method and a computer device for a spacecraft digital-real fusion test system, belonging to the technical field of safety demonstration. Background Art

[0002] The spacecraft test system refers to a real-time, accurate, efficient and safe spacecraft integrated test and control system that is established by effectively and comprehensively applying advanced information technology, spacecraft test technology, computer technology, network technology, automatic control technology, and communication technology to the entire spacecraft test. Through testing, functional defects and design defects of the spacecraft system can be discovered, and through the analysis of test data, the spacecraft system can be analyzed and verified.

[0003] Like any engineering project, a large amount of testing is required throughout the development of a spacecraft model. Testing is required to confirm whether the performance and functions of the spacecraft meet the design requirements, and to obtain qualitative and quantitative parameters in the test and process and evaluate them. Therefore, testing is an important part of the development process of a spacecraft model, and it forms a complete whole with the design and manufacture of modern spacecraft systems. The successful testing and finalization of any scientific theory and modern equipment in the aerospace field requires the support of advanced testing technology. The qualitative or quantitative data obtained from the test is the basis for research, design improvement and experimental analysis.

[0004] With the development of science and technology, simulation technology plays a key role in the field of modern technology research and development. The testing of spacecraft test systems is oriented towards new testing requirements. The mass production network parallel testing of the tested digital-real fusion test system has put forward higher testing requirements and safer and more reliable requirements. Digital-real fusion testing refers to the combination of digital technology and physical equipment, and the testing and verification are carried out through the collaborative work of artificial and intelligent systems. Virtual simulation testing allows digital technology to enter various industries on a larger scale, in a wider field, and at a deeper level, changing the business processes of traditional industries, constantly nurturing more new technologies, and building a new technology system. Through digital-real fusion simulation testing, system functional defects and design defects can be discovered, and through the analysis of test data, the system can be analyzed and verified, providing a basis for intelligent prediction, optimization, and adaptation.

[0005] Therefore, the credibility of digital-physical fusion test systems has received increasing attention, and a method is needed to verify the security and reliability of these systems under specific conditions. Current security demonstrations are mainly carried out through formal verification, model checking, etc. Although the security verification of the system can also be achieved, the implementation process of this method is relatively complicated and not intuitive enough. Summary of the invention

[0006] The purpose of the present invention is to provide a safety verification method and computer device for a spacecraft digital-real fusion test system, so as to solve the problems that the safety verification process of the current test system is complicated and not intuitive enough.

[0007] In order to solve the above technical problems, the present invention provides a safety verification method for a spacecraft digital-real fusion test system, which comprises the following steps:

[0008] Divide the spacecraft digital-physical fusion test system into multiple parts according to its safety process and system development process, and establish GSN safety cases for each part for verification. When the verification results of some parts are relatively unsafe, the results will be fed back to the design stage of the spacecraft digital-physical fusion test system.

[0009] When establishing the GSN security case for each part, first determine the security goal to be achieved by the part, then determine the corresponding claims and sub-goals based on the security goal, and decompose the sub-goals again until they cannot be decomposed. For the sub-goals that cannot be decomposed any further, collect evidence to establish the security case for each part.

[0010] Furthermore, the method also includes verifying the evidence used in the security cases of each part, by establishing a security case for each piece of evidence, and when any evidence fails the verification, re-establishing the security case for the corresponding part.

[0011] Furthermore, the divisions include the operating environment, dangerous scenarios, safe operation concepts, and functions at various levels of the digital-physical fusion test system.

[0012] Furthermore, the process of establishing the GSN safety case in the operating environment is as follows:

[0013] The completeness and correctness of the operation domain model of the digital-physical fusion test system is the safety test scope of the test system and is used as the security goal. The determined security goals are decomposed into operation domain model sub-goals and operation scenario sub-goals in the operation domain model. The operation domain model sub-goals are verified through the operation domain model definition and the definition of operation safety. The verification evidence is that the operation domain model includes information about all elements of the operation domain and the operation domain model includes specifications for various operations. The operation scenario sub-goals are verified through the operation scenario definition. The verification evidence is the operation scenario verification report.

[0014] Furthermore, the process of establishing a GSN safety case for dangerous scenarios is as follows:

[0015] The safety goal is to confirm that all dangerous scenarios related to the operation of the digital-physical fusion test system have been determined; the determined safety goals are decomposed into sub-goals of dangerous scenarios have been identified and sub-goals of dangerous scenarios can be handled; the sub-goals of dangerous scenarios have been identified are further decomposed into sub-goals of obtaining correct analysis through test decisions and sub-goals of interaction between the system and its operating environment; the sub-goals of obtaining correct analysis through test decisions are verified through the definition of operation scenarios, and the verification evidence is the decision analysis report; the sub-goals of interaction between the system and its operating environment are verified through the definition of operation domain models, and the verification evidence is the decision analysis report; the verification evidence adopted by the sub-goal of dangerous scenarios can be handled is the dangerous scenario verification report.

[0016] Furthermore, the process of establishing the GSN safety case in the safety operation concept is as follows:

[0017] The safety goal is to formulate a safe operation concept that can solve all identified dangerous scenarios; decompose the determined safety goals into system-level safety requirements defined in the safe operation concept that can solve dangerous scenario sub-goals and the operation domain model, including the constraint sub-goals required to solve dangerous scenarios; the system-level safety requirements defined in the safe operation concept can solve dangerous scenario sub-goals, and the verification evidence adopted is the safe operation concept proof report; the operation domain model includes the constraint sub-goals required to solve dangerous scenarios, which are further decomposed into solving dangerous scenario sub-goals by defining corresponding operation sub-goals according to the needs of specific conditions and solving dangerous scenario sub-goals through prescribed operations; by defining corresponding operation sub-goals according to the needs of specific conditions, the definition of the operation is verified, and the verification evidence is the safe operation concept proof report, and solving dangerous scenario sub-goals through prescribed operations is verified by solving the definition of the dangerous scenario, and the verification evidence is the safe operation concept proof report.

[0018] Furthermore, the functions of each layer include a presentation layer, a communication layer, a service layer and a data layer, and a corresponding GSN security case is established for each layer.

[0019] Further, the method includes establishing a safety case for each level of design, where the safety case is proposed for each level and the objectives are verified through a discussion of the design decisions taken, the design process followed, and checking for dangerous errors that may be introduced into the design.

[0020] Furthermore, when verifying the evidence used in each part of the safety case, create a safety goal for each part to prove that the verification evidence provided for the part is sufficient to show that the safety requirements defined in the part are met; support the safety goal by demonstrating the selected verification method and provide reasons for selecting the specified verification method, which involves testing, formal verification, or a combination of these methods. If testing is used, the evidence in the test table must meet the sub-goals of the part. If formal verification is used, formal verification must be satisfied to prove that the evidence in the part meets the sub-goals of the part.

[0021] The present invention also provides a computer device, including a processor, wherein the processor is used to execute computer program instructions to implement the above-mentioned safety verification method of the spacecraft digital-real fusion test system.

[0022] The beneficial effects of the present invention are as follows: the present invention divides the spacecraft digital-real fusion test system into multiple parts according to its security process and system development process, creates GSN security cases for each part of the digital-real fusion test system, and when creating each security case, first determines the security goal to be achieved by the part, then determines the corresponding claims and each sub-goal according to the security goal, and decomposes the sub-goal again until it cannot be decomposed, collects evidence for the sub-goal that cannot be decomposed any further, and thereby establishes security cases for each part. The security cases for each part constructed by the present invention can perform security analysis on the spacecraft digital-real fusion test system by means of graphical representation, can intuitively display the entire verification process, and ensure the full-cycle safety and reliable operation of the spacecraft digital-real fusion test system. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the relationship between target argument evidence in GSN security argument;

[0024] Figure 2 It is a schematic diagram of the GSN case module;

[0025] Figure 3 1. It is a schematic diagram of a GSN security assurance case framework adopted by a digital-real fusion test system in an embodiment of the present invention;

[0026] Figure 4 It is a schematic diagram of a GSN safety case of a part of the operation environment of a digital-real fusion test system in an embodiment of the present invention;

[0027] Figure 5 It is a schematic diagram of some GSN safety cases in dangerous scenarios of the digital-real fusion test system in an embodiment of the present invention;

[0028] Figure 6 It is a schematic diagram of a GSN safety case of the safety operation concept of the digital-real fusion test system in an embodiment of the present invention;

[0029] Figure 7 Schematic diagram of the hierarchical structure of the digital-real fusion test system in an embodiment of the present invention;

[0030] Figure 8 Schematic diagram of a GSN security case of the presentation layer of the digital-real fusion test system in an embodiment of the present invention;

[0031] Fig. 9 Schematic diagram of a GSN security case of the communication layer of the digital-real fusion test system in an embodiment of the present invention;

[0032] Fig.10 Schematic diagram of a GSN security case of a service layer of a digital-real fusion test system in an embodiment of the present invention;

[0033] Fig.11 Schematic diagram of a GSN security case of a data layer in a digital-real fusion test system according to an embodiment of the present invention;

[0034] Fig.12 It is a schematic diagram of GSN security cases designed at various levels of the digital-real fusion test system in an embodiment of the present invention;

[0035] Fig.13 It is a schematic diagram of the GSN security case of evidence of various parts of the digital-real fusion test system in an embodiment of the present invention. DETAILED DESCRIPTION

[0036] The specific implementation of the present invention will be further described below in conjunction with the accompanying drawings.

[0037] The present invention divides a spacecraft digital-physical fusion test system into multiple parts according to its security process and system development process, establishes a GSN security case for each part for verification, and when a part has a relatively unsafe verification result, feeds the result back to the design stage of the spacecraft digital-physical fusion test system; when establishing a GSN security case for each part, first determine the security goal to be achieved by the part, then determine the corresponding claims and sub-goals based on the security goal, and decompose the sub-goals again until they cannot be decomposed, collect evidence for the sub-goals that cannot be decomposed any further, so as to establish a security case for each part.

[0038] Method Embodiment

[0039] Goal Structure Notation (GSN) is a graphical argument notation used to formally depict the content and structure of any argument, as well as the relationship between arguments and evidence. Figure 1As shown in , the core components of a GSN include: (1) assurance goals or claims, that is, the security objectives that the system strives to achieve; (2) evidence to support the satisfaction of the goals, that is, data or facts that can prove the rationality of the security goals; and (3) arguments that connect the evidence to the goals, which constitute the logical basis for people to believe that the evidence is sufficient to support the legitimacy of the goals. When these GSN elements are interconnected in a network, they together form what is called a "goal structure." This basic framework is applied recursively to create a hierarchical structure for the system, in which the top level of the system is its overall goal. Other graphical elements that can be used in a GSN include strategies, assumptions, reasons, and contexts, such as Figure 2 shown.

[0040] The digital-physical fusion test system can realize the design method of a universal simulation management platform for simulation model resource management, simulation project management, visual simulation test assumptions, distributed real-time information-physical simulation and debugging functions. Users can efficiently manage the simulation digital models, protocol models, hardware model resources and simulation test projects required for testing through the platform, and create, edit and delete digital models, protocol models and hardware models in the system. The digital model adopts the FMU model that conforms to the FMI standard, so that users can integrate modeling in the system through a variety of modeling tools. The protocol model allows users to configure most application layer protocols and decouple them from specific communication hardware. In the test task, the available communication hardware interface can be used for verification and then quickly replaced. A standardized interface is designed for the hardware model. In addition to the various hardware communication interfaces supported by the system itself, it also supports users to import custom models written by themselves that conform to the hardware model interface standards, greatly improving the system's universal information-physical simulation capabilities. Through the visual simulation assumption method, the required models are quickly integrated for the test task, and the distributed real-time information-physical simulation test is realized after the simulation parameters are set, and debugging is carried out during the test process.

[0041] The operational environment assurance of the digital-physical fusion test system usually includes defining the functions of the test system, defining and verifying the operational domain model of the test system, defining and verifying the operational scenarios in the defined operational domain model, and creating assurance parameters for the operational context. Among them, the operational domain model is crucial to understanding how the system operates. The operational domain model is a model used in system engineering to describe the system and its operating environment. It covers entities that may interact with the system, external objects, and environmental factors that affect the system, and is an important starting point for system design. The operational domain model of the digital-physical fusion test system defines the environment in which the test is conducted, including real scenarios and virtual scenarios; defines external objects that interact directly or indirectly with the system, such as users, administrators, or other test systems; defines the components within the system, each of which has different functions and works together to operate the entire test system; the operational domain model also describes the interaction between external entities and subsystems.

[0042] Based on the description of the spacecraft digital-real fusion test system and the GSN security assurance case, the present invention provides a security verification method for the spacecraft digital-real fusion test system, such as Figure 3 As shown. This method sorts out the process of building a security case, ensures that the operating scenario, data specification and functional hierarchy design conform to the security concept of the digital-real fusion test system, and analyzes and verifies the security evidence. Through the feedback and iteration of each step in the system development process, a digital-real fusion security case is finally built. The present invention divides the verification of the digital-real fusion test system into the following multiple parts, including the operating environment part of the digital-real fusion test system, the dangerous scenario part, the safe operation concept part, the function implementation part at each level, the function design part at each level and the evidence verification part. The establishment of each part of the security case is described in detail below.

[0043] 1. Establishment of partial safety cases for the operating environment.

[0044] In the process of establishing the safety case, the most important goal is that the defined operation domain model completely and correctly defines the safety test scope of the test system. The present invention takes it as the safety goal G1.1; decompose the determined safety goal G1.1 into the operation domain model sub-goal G1.2 and the operation scenario sub-goal G1.4 in the operation domain model; regarding the operation domain model sub-goal G1.2, it must be proved that the operation behavior in the operation domain model is safe and can meet the test operation requirements. It needs to rely on the operation domain model C1.1 and the definition of operation safety C1.2 for verification. The verification goal is that the operation domain model includes information G1.5 about all elements of the operation domain and the operation domain model includes specifications for various operations; the operation scenario sub-goal G1.4 must prove that the relevant operation scenarios in the operation domain model are completely and correctly identified. It is necessary to understand the definition of the operation scenario and use the operation scenario verification report Sn1.3 as evidence. The established operation environment part of the safety case is as follows: Figure 4 shown.

[0045] 2. Establish some GSN safety cases for dangerous scenarios.

[0046] Dangerous scenarios are scenarios that a digital-real fusion test system may encounter during operation, which may lead to erroneous results under certain conditions. For digital-real fusion test systems, special attention should be paid to the interactions between the various test components in the system and the decisions made based on the test results of the test system. The identification of dangerous scenarios is particularly important in system engineering and risk management, as these scenarios may lead to system failures, data leakage, system hijacking or other potential security issues.

[0047] Confirming that all dangerous scenarios related to the operation of the digital-physical fusion test system have been determined as the safety goal G2.1, the determined safety goal G2.1 is decomposed into the dangerous scenario identified sub-goal G2.2 and the dangerous scenario can be processed sub-goal G2.3; the identification of dangerous scenarios is determined by the decisions made through the test in the test system and the interaction between the test system and its operating environment. The dangerous scenario identified sub-goal G2.2 can be further decomposed into the correct analysis sub-goal G2.4 through the test decision and the interaction sub-goal G2.5 between the system and its operating environment. The correct analysis sub-goal G2.4 through the test decision is verified through the definition of the operation scenario, and the verification evidence is the decision analysis report Sn2.1. The interaction sub-goal G2.5 between the system and its operating environment is verified through the definition of the operation domain model, and the verification evidence is the decision analysis report Sn2.2; the verification evidence used by the dangerous scenario can be processed sub-goal G2.3 is the dangerous scenario verification report Sn2.3. The partial safety case for dangerous scenarios established is as follows: Figure 5 shown.

[0048] 3. Some GSN safety cases for safe operation concepts are established.

[0049] The safety operation concept of the digital-physical fusion test system includes the operation process and operation precautions of the test system. The specified test process and operation method can effectively avoid the occurrence of dangerous scenarios to ensure the credibility of the test process and test tasks. The GSN safety case establishment process of this part is as follows: Figure 6 shown.

[0050] The present invention takes the formulated safe operation concept that can solve all identified dangerous scenarios as the safety goal G3.1. In this goal, the most important thing is that the formulated safe operation concept defines sufficient mitigation measures for all identified dangerous scenarios and can serve as an argument support. This is verified by considering each identified dangerous scenario and based on the sub-goal G3.2 of the adequacy of the safe operation concept in solving each dangerous scenario; for each identified dangerous scenario, it must be proved that the dangerous scenario will not occur under the premise that the operation of the test system during operation meets the requirements of the safe operation concept. Therefore, it is necessary to process the operation of the dangerous scenario from the safety requirements defined in the safe operation concept and the operation domain model for verification, that is, decomposing the sub-goal G3.2 into the system-level safety requirements defined in the safe operation concept that can solve the dangerous scenario sub-goal G3.3 and the operation domain model including solving Sub-goal G3.4: Constraints required for dangerous scenarios; Sub-goal G3.3: It is considered that the defined safety requirements are sufficient for handling dangerous scenarios, and needs to be supported by the safety operation concept proof report Sn3.2. The safety operation concept proof report should consider each identified dangerous scenario and provide clear arguments for each scenario; Sub-goal G3.4 should give corresponding safety operation concepts to constrain the handling of dangerous scenarios, and further decompose into sub-goals G3.5: Define corresponding operations according to the needs of specific conditions and sub-goals G3.6: Solve dangerous scenarios through prescribed operations. Sub-goal G3.5 is verified by solving the definition of operations C3.3, and the verification evidence is the safety operation concept proof report Sn3.2. Sub-goal G3.6 is verified by solving the definition of dangerous scenarios C3.4, and the verification evidence is the safety operation concept proof report Sn3.3.

[0051] 4. Establishment of GSN security cases for functional parts at each level.

[0052] The spacecraft digital-real fusion test system of the present invention includes a presentation layer, a communication layer, a service layer and a data layer. Figure 7 As shown, a corresponding GSN security case is established for each level.

[0053] 1) Establishment of GSN security case at presentation layer

[0054] The presentation layer provides users with a visual operation interface to operate the digital-physical fusion test system, including logging into the system, managing test models, managing simulation projects, designing projects, debugging tests, etc. Through visual tools for drag-and-drop operations and module usage, users can more conveniently manage models and projects, reduce learning costs, and improve test efficiency. The design of the presentation layer will help users better use the test system and achieve high-quality engineering design and management.

[0055] Security solutions for the presentation layer Figure 8As shown, the security goal G4.1 is that the presentation layer is acceptably safe. By discussing the function and structural design of the presentation layer, the security goal G4.1 is decomposed into the functional sub-goal G4.2 of the presentation layer and the design structure sub-goal G4.3 of the presentation layer. The sub-goal G4.2 is verified by the presentation layer operation interface definition C4.2, and the verification evidence is the software test package Sn4.1. The verification evidence used by the sub-goal G4.3 is the software design package Sn4.2.

[0056] 2) Establishment of GSN security case at communication layer

[0057] The communication layer of the digital-physical fusion test system mainly includes three modules, the WebSocket module, the HTTP module and the RPC module, as well as the communication methods and standardized interfaces between the modules. The WebSocket module is responsible for establishing a WebSocket connection with the front end to realize real-time data interaction and communication. Through the WebSocket module, the simulation data subscription server can exchange data with the front end in real time, supporting two-way communication and data transmission; the HTTP module is used to interact with the back-end server and terminal devices, and provides an HTTP interface for data transmission and control operations. This module processes data requests from the back end and the terminal, realizes data transmission and processing, and ensures data security and integrity; the RPC module is responsible for establishing an RPC channel to realize data interaction and remote calls with terminal devices. Through the RPC management module, the simulation data subscription server can establish a reliable channel with the terminal device to realize data transmission and remote operation, and improve the flexibility and scalability of the system.

[0058] The communication digital interface adopts FMI standard unified modeling to realize data interaction between modules and provide a unified access interface to external entities, which also greatly increases the scalability of simulation. For physical entities, an abstract adaptation layer is constructed to unify the management of physical entities and convert different communication methods, so that various entities and communication methods have standard simulation interfaces and data storage methods that can be interactively accessed. The design of the communication layer interface is to ensure the synchronous operation between the digital model and the physical entity, so as to realize real-time data exchange and feedback mechanism.

[0059] The process of establishing a security case for the communication layer is as follows: Fig. 9As shown in the figure, the security goal G5.1 of this layer is to ensure that the communication layer is acceptably secure. Under the definition of the existing communication layer, goal G5.1 can be decomposed into the protocol selection sub-goal G5.2 and interface design sub-goal G5.3 of the communication layer; sub-goal G5.2 needs to consider the protocol for interaction between modules, which needs to be selected according to the specific needs and application scenarios of the simulation. Choosing a suitable communication protocol is crucial to ensuring the efficiency and stability of data transmission. The software test report Sn5.1 is used to prove the rationality of the protocol selection; in sub-goal G5.3, the interface design with specific sensors, actuators or other hardware devices and digital devices is also an important part of the communication layer, which requires good compatibility and stability between the communication interface and the device. Designing an effective error detection and correction mechanism, as well as various possible communication interference and failure situations, are also important aspects of the communication layer interface design.

[0060] 3) Establishment of service layer GSN security case

[0061] The service layer provides users with specific functions of digital-physical fusion testing, including managing test models, managing simulation projects, designing projects, debugging tests, etc. Model management: Users can upload, download, query, and delete simulation models in the model library of the simulation management system, and can modify the model's name, type, and other parameters through the system. Project management: Users can create, query, and delete simulation projects in the project management interface of the simulation management system, and can modify the project's name, picture, and other information through the system. Project design: Users can open a project in the project management interface, enter the project design interface, integrate the model in a visual way, and build the simulation project required for the test task. Debug control: Users can run the simulation project in the simulation project design interface to perform test tasks. During the test process, they can realize real-time parameter modification, fault injection, and other functions through data injection. At the same time, the status and data of the simulation can be viewed in real time through the debugging control in the project.

[0062] In actual engineering projects, different projects often have different requirements for simulation services. For example, some projects require rapid iteration and accelerated simulation to shorten the product development cycle. Some projects require detailed calculations of a large number of details and do not need to use a faster simulation method to ensure the accuracy and reliability of the simulation results. Therefore, the design of each module of the service layer is also crucial to the simulation service. The process of establishing a security case for the service layer is as follows: Fig.10 shown.

[0063] The safety goal G6.1 of this layer is to ensure that the service layer is acceptably safe. Under the definition of the existing service layer, it is decomposed into the simulation management operation sub-goal G6.2 of the service layer and the structural design sub-goal G6.3 of each service module. The simulation management operation in sub-goal G6.2 should be designed in accordance with the functional requirements of the system and meet the test requirements for various test tasks, which needs to be verified through the software test report Sn6.1. Sub-goal G6.3 should also be diversified and meet the needs of different projects through the setting of modules. Such a design makes the simulation test system more suitable for various engineering projects and provides users with a more flexible and convenient simulation control method.

[0064] 4) Data layer GSN security case establishment

[0065] When executing simulation model simulation, the simulation execution engine will generate a large amount of simulation data. In order to effectively manage the massive data, it is necessary to classify and organize the data and store the results to meet the requirements of time and tasks. Based on the massive and high concurrency characteristics of simulation data, in the design of simulation data storage, the simulation result database software needs to design a suitable model to represent persistent data, select a suitable storage engine to improve concurrency capabilities, and set up a suitable control access mechanism to ensure data security. The process of establishing a security case at the data layer is as follows: Fig.11 shown.

[0066] The security goal G7.1 of this layer is to ensure that the data layer is acceptably secure. It needs to be decomposed into the data layer data storage sub-goal G7.2 and the data layer structure design sub-goal G7.3 for discussion under the definition of the existing data layer; the data layer under sub-goal G7.2 should support multiple data types and complex data structures, as well as dynamic field management, and provide powerful query language and indexing functions, support concurrent access control and transaction-level lock management, provide full and incremental backup functions, support data recovery, etc. The storage function of the data layer can be verified through the software test report Sn7.1; the structural design of the data layer under sub-goal G7.3 aims to provide efficient, stable and reliable time series data storage and query services to meet the needs of different application scenarios and ensure the security of data storage.

[0067] 5. Establishment of GSN security cases for each level of design.

[0068] This section is used to provide assurance about the design of the digital-physical fusion test system. This phase is iterative because it considers the assurance of the test system design across multiple design decomposition levels. Because it includes creating a design proposal that meets the safety regulations, verifying the design proposal, and then possibly changing the specified design accordingly, updating the safety requirements, doing more analysis, etc., in order to create a sufficient safety assurance case. Safety assurance cases for each level of design are as follows: Fig.12 shown.

[0069] The safety goals of this section are proposed for each layer of the digital-physical fusion test system development, which shows that the design of each layer is sufficient to ensure that the safety regulations defined at the current level are met; the safety goals can be verified through discussions on the design decision sub-goal G8.2 that has been taken, the design process sub-goal G8.3 that has been followed, and the sub-goal G8.4 that checks for dangerous errors that may be introduced into the design. Sub-goal G8.2 must provide reasonable reasons to prove that the key design decisions taken are appropriate to ensure that the system safety can meet the safety requirements. According to the safety requirements of the general system, the design decisions taken will include measures to achieve robustness, fault tolerance, and runtime monitoring; sub-goal G8.4 must prove that the design of each layer has checked the design that may lead to the generation of dangerous errors, which is verified through the software design review report Sn8.2.

[0070] In order to further improve the reliability of verification, the present invention also verifies the evidence used in each part of the security case. By establishing each piece of evidence security case, when there is evidence verification that fails, the corresponding part of the security case is re-established. The purpose of this step of verification is to generate evidence to prove that the security requirements specified by the security system are met in the specified operating environment. The different levels of system decomposition can be verified. The GSN security case for each part of the evidence established is as follows: Fig.13 If the evidence used in a part of the safety case is inaccurate, it is necessary to collect evidence for that part again and build a new safety case.

[0071] For each part of the test system, create a safety goal G9.1 to demonstrate that the evidence provided is correct to demonstrate that the verification evidence provided for that part is sufficient to show that the safety requirements defined for that layer are met. Support this goal by justifying the selected verification method. The reasons for choosing the selected verification method J8.1 must also be provided; this may involve testing, formal verification, or some combination of these methods. If testing is used, sub-goal G9.2 must be met; if formal verification is used, sub-goal G9.3 must be met.

[0072] Through the above process, the safety verification method of the spacecraft digital-real fusion test system provided by the present invention demonstrates how to use the GSN method to conduct detailed safety assurance analysis on the operating environment, dangerous scenarios, and various levels of functions and designs of the safe operation concept of the digital-real fusion test system, ensuring the full-cycle safety and reliable operation of the spacecraft digital-real fusion test system. The safety cases of each part constructed by the present invention can perform safety analysis on the spacecraft digital-real fusion test system through a graphical representation method to ensure its full-cycle safety and reliability.

[0073] Computer device embodiment

[0074] The computer device of the present invention includes a processor, which is used to execute computer program instructions to implement the above-mentioned safety verification method of the spacecraft digital-real fusion test system. The specific implementation process has been described in detail in the method embodiment and will not be repeated here.

Claims

1. A safety verification method for a spacecraft digital-real fusion test system, characterized in that: The method comprises the following steps: Divide the spacecraft digital-physical fusion test system into multiple parts according to its safety process and system development process, and establish GSN safety cases for each part for verification. When the verification results of some parts are relatively unsafe, the results will be fed back to the design stage of the spacecraft digital-physical fusion test system. When establishing the GSN security case for each part, first determine the security goal to be achieved by the part, then determine the corresponding claims and sub-goals based on the security goal, and decompose the sub-goals again until they cannot be decomposed. For the sub-goals that cannot be decomposed any further, collect evidence to establish the security case for each part.

2. The safety verification method of the spacecraft digital-real fusion test system according to claim 1 is characterized in that: The method also includes verifying the evidence used in the safety cases of each part, by establishing a safety case for each piece of evidence, and when any evidence fails the verification, re-establishing the safety case for the corresponding part.

3. The safety verification method of the spacecraft digital-real fusion test system according to claim 1 is characterized in that: The divided parts include the operating environment, dangerous scenarios, safe operation concepts, and functions at various levels of the digital-physical fusion test system.

4. The safety verification method of the spacecraft digital-real fusion test system according to claim 3 is characterized in that: The process of establishing a GSN safety case in the operating environment is as follows: The completeness and correctness of the operation domain model of the digital-physical fusion test system is the safety test scope of the test system and is used as the security goal. The determined security goals are decomposed into operation domain model sub-goals and operation scenario sub-goals in the operation domain model. The operation domain model sub-goals are verified through the operation domain model definition and the definition of operation safety. The verification evidence is that the operation domain model includes information about all elements of the operation domain and the operation domain model includes specifications for various operations. The operation scenario sub-goals are verified through the operation scenario definition. The verification evidence is the operation scenario verification report.

5. The safety verification method of the spacecraft digital-real fusion test system according to claim 3 is characterized in that: The process of establishing a GSN safety case for dangerous scenarios is as follows: The safety goal is to confirm that all dangerous scenarios related to the operation of the digital-physical fusion test system have been determined; the determined safety goals are decomposed into sub-goals of dangerous scenarios have been identified and sub-goals of dangerous scenarios can be handled; the sub-goals of dangerous scenarios have been identified are further decomposed into sub-goals of obtaining correct analysis through test decisions and sub-goals of interaction between the system and its operating environment; the sub-goals of obtaining correct analysis through test decisions are verified through the definition of operation scenarios, and the verification evidence is the decision analysis report; the sub-goals of interaction between the system and its operating environment are verified through the definition of operation domain models, and the verification evidence is the decision analysis report; the verification evidence adopted by the sub-goal of dangerous scenarios can be handled is the dangerous scenario verification report.

6. The safety verification method of the spacecraft digital-real fusion test system according to claim 3 is characterized in that: The process of establishing a GSN safety case in the safety operation concept is as follows: The safety goal is to solve all identified dangerous scenarios with the developed safe operation concept; decompose the identified safety goal into system-level safety requirements defined in the safe operation concept that can solve dangerous scenario sub-goals and the operation domain model including the constraint sub-goals required to solve dangerous scenarios; The system-level safety requirements defined in the safe operation concept can solve the dangerous scenario sub-goals, and the verification evidence adopted is the safe operation concept proof report; the operation domain model includes the constraint sub-goals required to solve the dangerous scenarios, which are further decomposed into solving the dangerous scenario sub-goals by defining the corresponding operation sub-goals according to the needs of specific conditions and solving the dangerous scenario sub-goals through prescribed operations; by defining the corresponding operation sub-goals according to the needs of specific conditions, the verification is verified by solving the definition of the operation, and the verification evidence is the safe operation concept proof report, and solving the dangerous scenario sub-goals through prescribed operations is verified by solving the definition of the dangerous scenario, and the verification evidence is the safe operation concept proof report.

7. The safety verification method of the spacecraft digital-real fusion test system according to claim 3 is characterized in that: The functions of each layer include presentation layer, communication layer, service layer and data layer, and each layer has a corresponding GSN security case.

8. The safety verification method of the spacecraft digital-real fusion test system according to claim 7 is characterized in that: The methodology also includes building a safety case for each level of design, which is presented for each level and validated through a discussion of the design decisions taken, the design process followed, and a check for dangerous errors that could be introduced into the design.

9. The safety verification method of the spacecraft digital-real fusion test system according to claim 3 is characterized in that: When verifying the evidence used in each part of the safety case, create a safety goal for each part to prove that the verification evidence provided for the part is sufficient to show that the safety requirements defined in the part are met; support the safety goal by demonstrating the selected verification method and provide reasons for selecting the specified verification method, which involves testing, formal verification, or a combination of these methods. If testing is used, the evidence in the test table must meet the sub-goals of the part. If formal verification is used, formal verification must be satisfied to prove that the evidence in the part meets the sub-goals of the part.

10. A computer device comprising a processor, characterized in that: The processor is used to execute computer program instructions to implement the safety verification method of the spacecraft digital-real fusion test system as described in any one of claims 1-9.

Images