Spacecraft software component requirement analysis and modeling method based on dynamic data flow graph

Abstract

The application discloses a spacecraft software component requirement analysis and modeling method based on a dynamic data flow graph, relates to the technical field of spacecraft integrated electronics, and solves the problem that a traditional data flow graph is difficult to express the data transmission relationship between internal modules of a complex spacecraft system component and components. The method comprises the following steps: a dynamic data flow graph is constructed for data in spacecraft software; component requirement analysis is performed on the dynamic data flow graph to obtain components in the data flow graph; component outline design is performed on the components in the data flow graph; and a component model is established for the components according to the component outline design, which is used for component verification in a subsequent visual assembly process with tool support.

Description

Technical Field

[0001] This invention relates to the field of integrated electronic technology for spacecraft, specifically to a method for spacecraft software component requirements analysis and modeling based on dynamic data flow graphs. Background Technology

[0002] Traditional spacecraft software design typically employs static data flow analysis for requirements analysis, followed by preliminary and detailed design based on the results. This approach has the following shortcomings:

[0003] 1) When new spacecraft apply a large number of advanced international standards, such as the Advisory Committee on Space Data Systems (CCSDS) standard, the system is more complex and there are many data flow paths. Traditional static data flow diagrams are difficult to describe the internal structure of software components or the relationships between software components.

[0004] 2) It is difficult to support the simulation of internal processing of components and information flow between components.

[0005] There is currently no technical solution that can solve the above problems. Summary of the Invention

[0006] In view of this, the present invention provides a method for spacecraft software component requirements analysis and modeling based on dynamic data flow graphs, which solves the problem that traditional data flow graphs are difficult to express the internal modules of complex spacecraft system components and the data transmission relationships between components.

[0007] To achieve the above objectives, the present invention provides a spacecraft software component requirements analysis and modeling method based on dynamic data flow graphs, comprising the following steps:

[0008] For data in spacecraft software, construct dynamic data flow graphs.

[0009] Perform component requirement analysis on the dynamic data flow diagram to obtain the components in the data flow diagram.

[0010] Perform a component overview design for the components in the data flow diagram.

[0011] Based on the component outline design, a component model is created for the component. The component model is used for component verification during the visual assembly process after tools are available.

[0012] Furthermore, for the data in the spacecraft software, a dynamic data flow diagram is constructed, including the following:

[0013] STEP(1) For the data in the spacecraft software, construct an initial data flow diagram based on the conventional data flow diagram construction method, combined with the data processing process, data storage, data flow direction and data representation method;

[0014] STEP(2) Add execution step arrows with step numbers 1, 2, 3... to the initial data flow diagram.

[0015] STEP(3) adds the address identifier of the step execution in the initial data flow diagram with added execution step arrows. S indicates that the step is executed at the source end, and D indicates that the step is executed at the destination end.

[0016] STEP(4) In the textual description of the initial data flow diagram, for each primitive, describe its front-end processing process according to the steps, and describe the software background execution process according to the steps.

[0017] STEP(5) describes each process in the initial data flow graph according to its input, processing, and output to obtain a dynamic data flow graph.

[0018] Furthermore, a component overview design is performed for the components in the data flow diagram, specifically including the following steps:

[0019] Transform the corresponding processing procedures in the dynamic data flow diagram into software modules.

[0020] Transform the data storage in the dynamic data flow graph into the data structure inside the component.

[0021] Transform the primitives provided by components in the dynamic data flow diagram and the primitives that need to be provided by other components into the interfaces provided by the components and the required interfaces.

[0022] Furthermore, based on the component outline design, a component model is established for the component. The established component model includes at least three aspects: the component interface aspect, the path aspect, and the performance aspect.

[0023] Furthermore, the component interface side describes the component's external interfaces and configurable parameters; the component interface side includes three types of interfaces, namely the component configuration and initialization interface, the interface provided by the component to the outside world, and the external interfaces required by the component.

[0024] On the path side, each layer of components generally provides an interface to the upper layer, while requiring the interface of the lower layer to deliver data. After establishing the path side for each component, the component model is driven by data, selects a path based on the input data, and transmits data through different interfaces. After the system is built through the component model, data is input through any interface of the system and simulated to obtain the data flow between various devices in the system and between various components within the devices.

[0025] The performance aspect is used to verify whether the overall data processing time and other performance parameters of the system meet the requirements after the system is assembled from components, as data is transferred between multiple components or even multiple devices.

[0026] Beneficial effects:

[0027] 1) The spacecraft software component requirements analysis and modeling method based on dynamic data flow diagrams provided by this invention supports dynamic data flow analysis of software components, facilitating developers' intuitive understanding of the information flow paths of software components under different input conditions, as well as the interface and information flow relationships between different components of a complex system. Based on this data flow diagram, the correctness of the data flow diagram can be verified through the design of test cases during the requirements phase. It can represent not only the static processing relationships described in conventional data flow diagrams, but also the dynamic execution and interaction processes of the software at the source and destination ends.

[0028] 2) The spacecraft software component requirements analysis and modeling method based on dynamic data flow graphs provided by this invention establishes component models. Subsequently, based on software visualization assembly and simulation verification tools, the correctness and adaptability of components can be verified after selecting components from the component library, solving the component verification problem mentioned above and making visualization assembly based on software components possible.

[0029] 3) This invention provides a method for spacecraft software component requirements analysis and modeling based on dynamic data flow graphs, which supports component-based software design and improves software reusability. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the dynamic data flow of the transport layer components;

[0031] Figure 2 It is a software component interface design diagram. Detailed Implementation

[0032] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0033] This invention provides a spacecraft software component design method based on dynamic data flow analysis. This method is used to design spacecraft software components. Taking the design of an onboard space packet protocol component as an example, the method includes the following steps:

[0034] Step 1: Component Requirements Analysis

[0035] Component requirements analysis is performed using dynamic data flow diagrams (a general method). The main rules of these data flow diagrams are as follows:

[0036] (1) Data processing procedures, data storage, data flow direction, data representation methods and conventional data flow Figure 1 To;

[0037] (2) Add thick arrows with step numbers 1, 2, 3... to the diagram to indicate the steps to be performed;

[0038] (3) Add address identifiers for the execution of steps in the diagram. S indicates that the step is executed at the source end, and D indicates that the step is executed at the destination end.

[0039] (4) In the textual description of the data flow diagram, for each primitive, describe its front-end processing process according to the steps, and describe the software background execution process according to the steps when necessary.

[0040] (5) For each process in the data flow diagram, describe it separately according to input, processing and output.

[0041] Taking the transport layer spatial packet protocol component in the software architecture as an example, its data flow diagram is as follows: Figure 1 As shown.

[0042] In the diagram, (1S), (2S), and (3S) represent the steps a user takes to send a space packet to the underlying layer using the PACKET.Request primitive. The description is as follows (details of the algorithm, parameters, and processing are omitted here for brevity):

[0043] Source-side foreground execution process:

[0044] (1S) The space packet sending interface accepts calls from upper-layer users and passes in space packet routing output processing.

[0045] (2S) Spatial packet routing output processing queries the routing table to obtain routing information and passes the spatial packet along with the routing information to the packet output. If the packet output fails and the number of failures does not exceed the maximum number of failures, the data is put into the output packet queue.

[0046] (3S) Packet output calls the lower-level subnet packet service primitive to send data.

[0047] Source-side background execution process:

[0048] (4S) The background task of spatial packet routing periodically retrieves the selected data units from the output packet queue and submits them to the spatial packet routing output.

[0049] PACKET.Indication represents the processing procedure at the destination, and can also be described using a similar method.

[0050] Execution process of the destination front end:

[0051] (5D) The space packet receiving interface obtains the space packet from the subnet packet service data delivery interface.

[0052] (6D) The space packet receiving interface delivers the space packet to the space packet routing output.

[0053] (7D) The spatial packet routing output interface processing is the same as (2S).

[0054] (8D) Packet output delivers data to the upper layer via PACKET.Indication.

[0055] By performing the dynamic data flow diagram analysis and iteration on each primitive or interface as described above, a complete data flow diagram of the entire component can be formed. Then, based on the processing procedure for each piece of data in the text description, test cases are constructed, and test case deduction is performed according to the execution steps of the data flow diagram to verify whether the interfaces between each process match and whether there are any omissions.

[0056] The above process not only provides input for subsequent preliminary design, but also makes component-based system data flow simulation and component verification possible.

[0057] Step 2, Component Overview Design

[0058] Based on the results of component requirements analysis, the main steps in the component preliminary design process include:

[0059] (1) Transform the corresponding processing procedures in the component dynamic data flow diagram into software modules;

[0060] (2) Transform the data storage in the component dynamic data flow diagram into the data structure inside the component;

[0061] (3) Transform the primitives provided by the component and the primitives that need to be provided by other components in the component dynamic data flow into the interface provided by the component and the required interface.

[0062] After completing the above steps, the basic design of the component is essentially finished. However, the issues of component correctness and adaptability within the system, mentioned earlier, need to be addressed. Therefore, a model of the component can be created to facilitate component verification during the visual assembly process once tools are available. The component model should contain at least three aspects.

[0063] (1) Component interface side

[0064] This describes the external interfaces and configurable parameters of a component. The component's interface side mainly includes three types of interfaces: component configuration and initialization interfaces, external interfaces provided by the component, and external interfaces required by the component, such as... Figure 2 As shown:

[0065] Component development employs many object-oriented concepts, such as classes, objects, encapsulation, and information hiding. However, since most spacecraft software is currently developed using the non-object-oriented C language, special design for component interfaces is required for C. The approach used here is to encapsulate data and interfaces using structures. Each business or protocol component has a main structure, similar to a class in the object-oriented language C++. During actual use, one or more variables of this type are instantiated. Interfaces are placed in the structure in the form of function pointers and are linked to specific functions during component initialization.

[0066] (2) Path side

[0067] Each layer of components typically provides interfaces to the upper layer and requires interfaces from the lower layer to transmit data. After establishing path profiles for each component, the component model can be data-driven, selecting paths based on input data and transmitting data through different interfaces. Once the system is built using the component model, data can be input through any interface of the system and simulation can be performed to obtain the data flow between various devices in the system and between components within each device.

[0068] The model of the component path side can be represented in various forms. A simplified form is to select based on the component's input parameters according to a certain algorithm. For example, if a certain input parameter X is a link identifier, the selection algorithm represented by pseudocode is as follows.

[0069] switch(X)

[0070] case 1:

[0071] Output via output interface 1

[0072] case 2:

[0073] Output via output interface 2

[0074] default:

[0075] Output via input interface 3

[0076] (3) Performance aspect

[0077] This aspect is mainly to verify whether the overall data processing time and other performance aspects of the system meet the requirements after the system is assembled from components, since data is transmitted between multiple components or even multiple devices.

[0078] The specific model for this aspect can be based on the preceding path model, employing a method of designing delay parameters for each path. These delay parameters can be represented by default constants or by a specific algorithm. When using an algorithm, a more precise representation can be achieved based on different input conditions. During system simulation, the sum of the delays of all paths traversed by the data represents the data processing and forwarding delay. Through the design of the performance aspect, various test cases can be used to test the system's time performance under different input conditions and with different component assembly structures.

[0079] Step 3: Detailed Design of Components

[0080] In the detailed design phase of a component, the algorithm and process design are mainly carried out for the modules formed during the component's preliminary design. Pseudocode is used for the design, which is a common practice and will not be elaborated further.

[0081] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for spacecraft software component requirements analysis and modeling based on dynamic data flow graphs, characterized in that, Includes the following steps: For data in spacecraft software, construct dynamic data flow graphs; Perform component requirement analysis on the dynamic data flow diagram to obtain the components in the data flow diagram; Perform component overview design for the components in the data flow diagram; Based on the component outline design, a component model is established for the component. The component model is used for component verification during the visual assembly process after tool support is available. The construction of a dynamic data flow graph for data in spacecraft software includes the following: STEP (1) For the data in the spacecraft software, construct an initial data flow diagram based on the data flow diagram construction method, combined with the data processing process, data storage, data flow direction and data representation method; STEP (2) Add execution step arrows with step numbers 1, 2, 3... to the initial data flow diagram; STEP (3) In the initial data flow diagram with added execution step arrows, add the address identifier of the step execution, S indicates that the step is executed at the source end, and D indicates that the step is executed at the destination end; STEP (4) In the textual description of the initial data flow diagram, for each primitive, describe its foreground processing process according to the steps, and describe the software background execution process according to the steps; STEP (5) For each process in the initial data flow diagram, describe it according to input, processing, and output to obtain a dynamic data flow diagram; The component outline design for the components in the data flow diagram specifically includes the following steps: Transform the processing procedures corresponding to the dynamic data flow diagram into software modules; Transform the data storage in the dynamic data flow graph into the data structure inside the component; Transform the primitives provided by components in the dynamic data flow diagram and the primitives that need to be provided by other components into the interfaces provided by the components and the required interfaces. Based on the component outline design, a component model is established for the component. The established component model includes at least three aspects: the component interface aspect, the path aspect, and the performance aspect. The component interface side is used to describe the component's external interfaces and configurable parameters; the component interface side includes three types of interfaces, namely the component configuration and initialization interface, the component's external interface, and the external interfaces required by the component. In the path side, each layer of components provides an interface to the upper layer, and at the same time requires the interface of the lower layer to deliver data. After the path side is established for each component, the component model is driven by data, selects a path according to the input data, and transmits data through different interfaces. After the system is built through the component model, data is input through any interface of the system and simulated to obtain the data flow between various devices in the system and between various components within the device. The performance aspect is used to verify whether the overall data processing time in the system meets the requirements after the system is assembled from components, since data is transmitted between multiple components or even multiple devices.

Images