CN115454381A - Spacecraft software component demand analysis and modeling method based on dynamic data flow graph - Google Patents

Spacecraft software component demand analysis and modeling method based on dynamic data flow graph Download PDF

Info

Publication number
CN115454381A
CN115454381A CN202210947740.0A CN202210947740A CN115454381A CN 115454381 A CN115454381 A CN 115454381A CN 202210947740 A CN202210947740 A CN 202210947740A CN 115454381 A CN115454381 A CN 115454381A
Authority
CN
China
Prior art keywords
component
data flow
data
flow graph
components
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210947740.0A
Other languages
Chinese (zh)
Inventor
何熊文
徐明伟
周志成
詹盼盼
阎冬
顾明
程博文
齐征
杨丽君
李佳津
李文娟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Institute of Spacecraft System Engineering
Original Assignee
Beijing Institute of Spacecraft System Engineering
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Institute of Spacecraft System Engineering filed Critical Beijing Institute of Spacecraft System Engineering
Priority to CN202210947740.0A priority Critical patent/CN115454381A/en
Publication of CN115454381A publication Critical patent/CN115454381A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Geometry (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Computational Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention discloses a spacecraft software component demand analysis and modeling method based on a dynamic data flow graph, relates to the technical field of spacecraft integrated electronics, and solves the problems that the traditional data flow graph is difficult to express the data transfer relationship between internal modules and components of a complex spacecraft system component. The method comprises the following steps: and constructing a dynamic data flow diagram aiming at data in spacecraft software. And analyzing the component requirement of the dynamic data flow graph to obtain the components in the data flow graph. And carrying out component outline design on components in the data flow graph. And establishing a component model for the component according to the general design of the component, wherein the component model is used for verifying the component in the visual assembly process after being supported by a tool subsequently.

Description

Spacecraft software component demand analysis and modeling method based on dynamic data flow graph
Technical Field
The invention relates to the technical field of spacecraft integrated electronics, in particular to a spacecraft software component demand analysis and modeling method based on a dynamic data flow graph.
Background
When a traditional spacecraft is used for designing spacecraft software, a static data flow analysis method is generally adopted for demand analysis, and then summary design and detailed design are carried out according to a demand analysis result. The above method has the following disadvantages:
1) The novel spacecraft applies a large number of international advanced standards such as the Consultative Committee for Space Data Systems (CCSDS) standard, the system is complex, the data flow path is large, and the traditional static data flow diagram is difficult to describe and clearly show the relationship inside or between software components.
2) It is difficult to support the simulation of component internal processes and information flow between components.
At present, no technical scheme can solve the problems.
Disclosure of Invention
In view of the above, the invention provides a method for analyzing and modeling spacecraft software component requirements based on a dynamic data flow diagram, which solves the problem that the traditional data flow diagram is difficult to express the data transfer relationship between the internal modules and components of a complex spacecraft system component.
In order to achieve the purpose, the spacecraft software component requirement analysis and modeling method based on the dynamic data flow graph comprises the following steps:
and constructing a dynamic data flow diagram aiming at data in spacecraft software.
And analyzing the component requirement of the dynamic data flow graph to obtain the components in the data flow graph.
And carrying out component outline design on components in the data flow graph.
And establishing a component model for the component according to the general design of the component, wherein the component model is used for verifying the component in the visual assembly process after being supported by a tool subsequently.
Further, a dynamic data flow diagram is constructed for data in the spacecraft software, and the dynamic data flow diagram comprises the following contents:
the method comprises the STEPs that STEP (1) for data in spacecraft software, an initial data flow diagram is constructed according to a construction method of a conventional data flow diagram and by combining a data processing process, data storage, a data flow direction and a data representation method of the data;
STEP (2) adds an execution STEP arrow with STEP number 1,2,3 \8230inthe initial dataflow graph.
STEP (3) adds the address identifier of STEP execution in the initial data flow graph added with the STEP execution arrow, S represents that the STEP is executed at the source end, and D represents that the STEP is executed at the target end.
STEP (4) in the character description of the initial data flow graph, for each primitive, respectively describing the foreground processing process according to the STEPs, and describing the software background execution process according to the STEPs;
and the STEP (5) describes each processing procedure in the initial data flow graph according to input, processing and output respectively to obtain a dynamic data flow graph.
Further, the method for designing the summary of the components in the dataflow graph specifically includes the following steps:
and converting the corresponding processing process in the dynamic data flow diagram into a software module.
And converting the data storage in the dynamic data flow graph into a data structure inside the component.
Converting the primitives provided by the components and needed by other components in the dynamic data flow graph into the interfaces provided by the components and needed interfaces.
Further, according to the general design of the component, a component model is built for the component, and the built component model at least comprises three sides: a component interface side, a path side, and a performance side.
Further, the component interface side is used for describing an external interface and configurable parameters of the component; the interface side of the component comprises three types of interfaces which are respectively an interface for component configuration and initialization, an interface for component external supply and an external interface required by the component;
the method comprises the steps that path side surfaces are arranged, components of each layer generally provide interfaces for an upper layer, meanwhile, data delivery is carried out on the interfaces of a lower layer, after the path side surfaces are established for the components, component models take the data as driving, path selection is carried out according to input data, and the data are transmitted through different interfaces; after the system is built through a component model, data are input through any one interface of the system and are subjected to simulation operation, and data streams of the data among all equipment of the system and among all components in the equipment are obtained.
And the performance side is used for verifying whether the performance of the data in the system, such as the whole processing time, meets the requirements or not because the data is transmitted in a plurality of components or even a plurality of devices after the system is assembled by adopting the components.
Has the advantages that:
1) The spacecraft software component requirement analysis and modeling method based on the dynamic data flow graph supports dynamic data flow analysis of software components, and is convenient for developers to visually know information flow paths of the software components under different input conditions and interfaces and information flow relations between different components of a complex system. Based on the data flow graph, the correctness of the data flow graph can be verified through the design of a test case in a demand stage. Not only can represent the static processing relationship described in the conventional data flow diagram, but also can represent the dynamic execution and interaction process of the source end software and the destination end software.
2) According to the spacecraft software component requirement analysis and modeling method based on the dynamic data flow graph, through establishment of the side face of a component model and subsequent visual assembly and simulation verification tools based on software, the correctness and adaptability of the component can be verified after the component is selected from a component library, the component verification problem is solved, and visual assembly based on the software component is possible.
3) The invention provides a spacecraft software component requirement analysis and modeling method based on a dynamic data flow graph, which supports component design of software and improves reusability of the software.
Drawings
FIG. 1 is a schematic diagram of the component dynamic data flow of the transport layer;
FIG. 2 is a software component interface layout.
Detailed Description
The invention is described in detail below by way of example with reference to the accompanying drawings.
The invention provides a spacecraft software component design method based on dynamic data flow analysis, which is used for designing spacecraft software components. Taking the design of a satellite-borne space packet protocol component as an example, the method comprises the following steps:
step 1, component requirement analysis
Component requirement analysis is performed through a dynamic data flow diagram (general method), and the main rules of the data flow diagram are as follows:
(1) The data processing process, the data storage, the data flow direction and the data representation method are consistent with those of a conventional data flow graph;
(2) The thick arrow with step number 1,2,3 \8230isadded in the figure to represent the execution steps;
(3) Adding the address identification of the step execution in the figure, wherein S represents that the step is executed at the source end, and D represents that the step is executed at the destination end;
(4) In the text description of the data flow graph, for each primitive, the foreground processing process is respectively described according to the steps, and the software background execution process is described according to the steps if necessary;
(5) For each processing procedure in the data flow graph, the description is respectively performed according to input, processing and output.
Taking the transport layer space packet protocol component in the software architecture as an example, the data flow diagram is shown in fig. 1.
In the drawings, (1S), (2S) and (3S) are steps of sending a spatial packet to the bottom layer for a user through a packet request primitive of the spatial packet, which are described as follows (for the sake of brevity, details of some algorithms, parameters and processing procedures are omitted here):
the source foreground executing process:
and (1S) the space packet sending interface receives the call of an upper layer user and transmits the space packet to the routing output processing.
And (2S) the spatial packet routing output processing inquires a routing table to obtain routing information, transmits the spatial packet and the routing information to packet output, and puts data into an output packet queue if the packet output fails and the times do not exceed the maximum times.
And (3S) the packet output calls a service primitive of a subnet packet of a lower layer to send data.
The source end background execution process:
and (4S) periodically taking out the selected data unit from the output packet queue by the space packet routing background task, and submitting the data unit to the space packet routing output.
Packet is a process of the destination, and a similar method can be used for description.
The foreground execution process of the destination end:
(5D) And the space packet receiving interface acquires the space packet from the subnet packet service data delivery interface.
(6D) The spatial packet receiving interface delivers the spatial packet to the spatial packet routing output.
(7D) The spatial packet routing output interface processing is the same as (2S).
(8D) Packet output delivers data to the upper layer through packet.
After the above dynamic dataflow graph analysis and iteration are performed on each primitive or interface, a complete dataflow graph of the whole component can be formed. And then constructing a test case according to the processing process of each data in the text description, performing test case deduction according to the execution steps of the data flow graph, and verifying whether interfaces between the processes are matched or not and whether the interfaces are omitted or not.
The above process provides both input for subsequent summary design and enables component-based system data flow simulation and component verification.
Step 2, outline design of components
Based on the results of the component requirement analysis, the main steps in the component summary design process include:
(1) Converting the corresponding processing process in the component dynamic data flow diagram into a software module;
(2) Converting data storage in the dynamic data flow diagram of the component into a data structure inside the component;
(3) Converting the primitives provided by the component to the outside and the primitives required to be provided by other components in the dynamic data flow of the component into the interfaces provided by the component to the outside and the required interfaces.
After the above steps are completed, the outline design of the component is basically completed. But the aforementioned problems of correctness of components and adaptability in the system need to be solved. Therefore, the component can be modeled, and component verification in the visual assembly process is facilitated after subsequent tool support. The component model at least comprises three sides;
(1) Side of component interface
For describing the external interfaces of the components and configurable parameters. The interface side of the component mainly includes three types of interfaces, which are respectively a component configuration and initialization interface, an externally provided interface for the component, and an external interface required by the component, as shown in fig. 2:
the component development adopts many object-oriented ideas such as class, object, encapsulation, information hiding and the like, but because spacecraft software is mostly developed by adopting a non-object-oriented C language at present, a special design of a component interface needs to be carried out aiming at the C language. The method adopted here is to encapsulate data and interfaces with a structure, each component of a service or protocol has a main structure, similar to a class of object-oriented language C + +, and one or more variables of the type are created for instantiation in actual use. The interface is put into the structure body in the form of a function pointer, and is hooked with a specific function when the component is initialized.
(2) Side of the path
The component of each layer generally provides an interface for the upper layer, and simultaneously needs the interface of the lower layer to deliver data, after a path side is established for each component, the component model can take data as a drive, performs path selection according to input data, and transmits the data through different interfaces. After the system is built through the component model, data can be input through any interface of the system and can be operated in a simulation mode, and data streams of the data among all devices of the system and among all components in the devices are obtained.
The model of the component path profile can be represented in a variety of forms, one simplified form being selected according to an algorithm based on the input parameters of the component. For example, a certain input parameter X is a link id, and the selection algorithm expressed by a pseudo code is as follows.
switch(X)
case 1：
Output through output interface 1
case 2：
Output via output interface 2
default：
Output via input interface 3
(3) Performance side
The side surface is mainly used for verifying whether the performance of the data in the system, such as the whole processing time, meets the requirements or not because the data is transmitted in a plurality of components or even a plurality of devices after the system is assembled by adopting the components.
The specific model of the side face can be based on the previous path model, a mode of designing a delay parameter for each path is adopted, and the delay parameter can be represented by a default constant or a certain algorithm. When the algorithm representation is adopted, more accurate representation can be performed according to different input conditions. When the system operates in a simulation mode, the sum of the delay of all paths through which the data passes is the processing and forwarding delay of the data. Through the design of the performance side face, the time performance of the system under various different input conditions and different component assembly structures can be tested through various test cases.
Step 3, detailed design of components
In the detailed component design stage, algorithm and flow design is mainly performed on modules formed in the component outline design process. The design is performed in a pseudo code mode, which is a common practice and is not described in detail.
In summary, the above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (5)

1. The spacecraft software component demand analysis and modeling method based on the dynamic data flow graph is characterized by comprising the following steps:
aiming at data in spacecraft software, a dynamic data flow diagram is constructed;
analyzing the component requirement of the dynamic data flow graph to obtain components in the data flow graph;
designing a component outline aiming at the components in the data flow graph;
and establishing a component model for the component according to the component outline design, wherein the component model is used for verifying the component in the visual assembly process after being supported by a tool subsequently.
2. The method for spacecraft software component requirement analysis and modeling based on dynamic dataflow graph of claim 1, wherein the dynamic dataflow graph is constructed for data in spacecraft software, and includes the following contents:
the method comprises the STEPs that STEP (1) for data in spacecraft software, an initial data flow diagram is constructed according to a construction method of a conventional data flow diagram and by combining a data processing process, data storage, a data flow direction and a data representation method of the data;
STEP (2) adds an execution STEP arrow with STEP sequence numbers 1,2,3 \8230inthe initial data flow graph;
STEP (3) adds the address identifier of the STEP execution in the initial data flow graph added with the STEP execution arrow, S represents that the STEP is executed at the source end, D represents that the STEP is executed at the destination end;
STEP (4) in the character description of the initial data flow diagram, for each primitive, respectively describing the foreground processing process according to the STEPs, and describing the software background execution process according to the STEPs;
and the STEP (5) describes each processing procedure in the initial data flow graph according to input, processing and output respectively to obtain a dynamic data flow graph.
3. The method for spacecraft software component requirement analysis and modeling based on a dynamic data flow graph according to claim 1 or 2, wherein the component summary design for the components in the data flow graph specifically includes the steps of:
converting the corresponding processing process in the dynamic data flow diagram into a software module;
converting data storage in the dynamic data flow graph into a data structure inside the component;
converting the primitives provided by the components and needed by other components in the dynamic data flow graph into the interfaces provided by the components and needed interfaces.
4. The dynamic dataflow graph-based spacecraft software component requirement analysis and modeling method of claim 1, wherein a component model is built for a component according to a component summary design, the built component model including at least three sides: a component interface side, a path side, and a performance side.
5. The dynamic dataflow graph-based spacecraft software component requirement analysis and modeling method of claim 4, wherein the component interface side is used for describing an external interface of a component and configurable parameters; the interface side of the component comprises three types of interfaces which are respectively an interface for component configuration and initialization, an interface for component external supply and an external interface required by the component;
on the side surface of the path, the component of each layer generally provides an interface for the upper layer, meanwhile, the interface of the lower layer is required to deliver data, after the side surface of the path is established for each component, the component model takes the data as a drive, performs path selection according to input data, and transmits the data through different interfaces; after the system is built through a component model, data are input through any one interface of the system and are subjected to simulation operation, and data streams of the data among all equipment of the system and among all components in the equipment are obtained;
the performance side is used for verifying whether the performance of the system, such as the whole processing time and the like, meets the requirements or not because data are transmitted in a plurality of components or even a plurality of devices after the system is assembled by adopting the components.
CN202210947740.0A 2022-08-05 2022-08-05 Spacecraft software component demand analysis and modeling method based on dynamic data flow graph Pending CN115454381A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210947740.0A CN115454381A (en) 2022-08-05 2022-08-05 Spacecraft software component demand analysis and modeling method based on dynamic data flow graph

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210947740.0A CN115454381A (en) 2022-08-05 2022-08-05 Spacecraft software component demand analysis and modeling method based on dynamic data flow graph

Publications (1)

Publication Number Publication Date
CN115454381A true CN115454381A (en) 2022-12-09

Family

ID=84296652

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210947740.0A Pending CN115454381A (en) 2022-08-05 2022-08-05 Spacecraft software component demand analysis and modeling method based on dynamic data flow graph

Country Status (1)

Country Link
CN (1) CN115454381A (en)

Similar Documents

Publication Publication Date Title
CN103178996B (en) Distributed packet-switching chip model verification system and method
US10089425B2 (en) Resource mapping in a hardware emulation environment
US9043770B2 (en) Program module applicability analyzer for software development and testing for multi-processor environments
US20170003939A1 (en) Code generation
Baldassari et al. PROTOB: An object oriented methodology for developing discrete event dynamic systems
CN102395954A (en) Apparatus & associated methodology of generating a multi-core communications topology
CN100511149C (en) Logic emulation testing system and method
CN114139475A (en) Chip verification method, system, device and storage medium
CN108460199A (en) CNI modelings
CN108062382A (en) Method, apparatus, equipment and the storage medium of information exchange
CN110717268B (en) Portable component unit packaging method based on FACE architecture
CN107844410A (en) The adjustment method and device of a kind of distributed cluster system
CN101458633A (en) Method for accessing host program by script program, and system and apparatus thereof
CN115454381A (en) Spacecraft software component demand analysis and modeling method based on dynamic data flow graph
CN110209565A (en) A kind of metadata schema adjustment method and its device
CN104850015B (en) A kind of software packaging method and a kind of automobile electronic controller
EP1565813B1 (en) Code generation
CN100458800C (en) Automatic construction system and method for electronic circuit design
CN115167985A (en) Virtualized computing power providing method and system
CN113703339A (en) Automatic driving simulation method, device, equipment and storage medium
CN116302901A (en) Method and device for generating universal verification methodology UVM verification platform
CN111274750A (en) FPGA simulation verification system and method based on visual modeling
US20110289469A1 (en) Virtual interconnection method and apparatus
CN114741133B (en) Comprehensive modularized avionics system resource allocation and assessment method based on model
CN108959144A (en) Communication between field programmable gate array

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination