Digital model of a single-unit spaceborne computer in space

Abstract

This invention discloses a digital model of a single-unit spaceborne computer for aerospace applications. The model includes: a prototype-oriented requirements model: establishing a requirements model that evolves from prototype to final product through requirements import and dynamic updates; an object-oriented structural model: establishing four hierarchical models from top to bottom: single-unit layer, module layer, unit layer, and component layer, each corresponding one-to-one with the single-unit physical layer; realizing structural modeling of the interaction between CPU hardware and CPU application software under different conditions; a semi-physical hybrid behavior model: simulating the ability of the single-unit physical layer to process binary code streams; functional performance requirements verification: proposing a classification and verification scheme for nearly one hundred complex requirements of the single-unit; and a single-unit model testing environment: constructing a UI-based spaceborne computer testing system. This invention's single-unit digital model, based on the SysML language, can be applied to the overall digital design and simulation of satellites. This invention's UI-based single-unit testing system can be used for multi-scenario, fully closed-loop verification of the single-unit model.

Description

Technical Field

[0001] This invention belongs to the field of modeling and simulation of aerospace single-machine systems, and specifically relates to a digital model of a spaceborne computer for aerospace single-machine systems. Background Technology

[0002] Faced with the higher demands for high quality, short cycle time, and low cost from major aerospace missions, the construction of digital aerospace has become an inevitable path. Model-driven and data-driven R&D models have become important means to improve productivity, reduce production costs, and enhance innovation. Model-based systems engineering (MBSE) has been repeatedly applied in the functional closed-loop verification of complex system-level and system-level engineering projects such as lunar exploration, space stations, launch vehicles, and satellites, effectively promoting high-quality and high-efficiency missions. However, considering the scale and complexity of system models, MBSE modeling and research at the subsystem, sub-system, and single-machine levels in the aerospace field have not yet been deepened.

[0003] The onboard computer is a crucial component of the satellite's integrated electronic subsystem. It provides the operating environment and hardware platform for satellite administration and attitude / orbit control software, undertaking tasks such as telemetry and remote control processing, data management, data acquisition, data distribution, and program control for the entire satellite and its various subsystems. It also provides overall satellite timing and synchronization. It can be likened to the "brain" of the satellite platform and is of paramount importance. Only by achieving high-fidelity, high-precision modeling of the onboard computer can a truly meaningful digital prototype system for the satellite platform be established. However, due to the numerous and varied interface types of onboard computers, including multiple FPGAs and processors, the information and control flows are complex, making modeling extremely difficult. Currently, research on the digital modeling of this type of single-machine system in China is still in its infancy.

[0004] The MBSE modeling methodology and SysML system modeling language provide a complete guidance scheme and effective modeling tools for the digital modeling of complex products. Therefore, based on the MBSE modeling methodology and SysML system modeling language, a digital modeling method for spaceborne computers is proposed. Summary of the Invention

[0005] To achieve digital modeling of spaceborne computers, a digital model of a single-machine spaceborne computer for aerospace applications is proposed.

[0006] The technical solution adopted in this invention is:

[0007] The onboard computer digital model is divided into five parts: a prototype-oriented requirements model, an object-oriented structural model, a semi-physical hybrid behavior model, functional and performance requirements verification, and a single-machine model testing environment.

[0008] The modeling of the single-unit requirements model for the spaceborne computer initially focuses on the physical prototype of the unit and continues throughout the entire model development process. Modeling is primarily conducted using requirement modeling elements in the SysML language through a requirements import method. The single-unit system requirements are extracted from the single-unit task specification and stored as formatted text in an Excel requirement table. The requirement table is then bound to SysML language modeling software, automatically importing and generating the "Requirement Table". As the prototype development progresses from basic to final prototype, the Excel requirement table and the SysML language model elements in the "Requirement Table" are dynamically updated synchronously.

[0009] The object-oriented structural modeling of a single-machine spaceborne computer is divided into three levels from top to bottom: single-machine structural modeling, module structural modeling, and unit structural modeling. These correspond to the entire spaceborne computer, the circuit boards of each functional module of the spaceborne computer, and the relatively independent constituent units within each module circuit board, respectively. The hierarchical composition relationship is used to describe the single-machine structure, and this relationship is visualized through a block definition diagram (BDD diagram).

[0010] Preferably, for model elements containing "parts", multiple IBD diagrams describing the internal structure of the same model are created to express different perspectives of the model's internal composition. Taking a single spaceborne computer as an example, an IBD diagram of the energy flow of the internal modules of the spaceborne computer and an IBD diagram of the information flow inside and outside the constituent modules of the spaceborne computer are created.

[0011] Specifically, in the IBD diagram describing the internal energy flow of the onboard computer, the legend model is used to define different styles of connectors between power supply interfaces, modeling the cold and hot backup of each module of the onboard computer. The power supply energy flow of modules under different operating states is graphically represented: that is, the channel gateway and JJM modules A and B, navigation receiver modules A and B, can respectively realize the capabilities of "A on B", "A off B", and "B off A"; processor modules A and B, time base & serial I / O modules type I 1 and 2, integrated interface modules type I 1 and 2, and power drive modules 1 and 2, each form an independent group, with each group having the capability of "A on B", "A off B", and "B off A". By using legend model elements to set different state attributes of different groups of connectors, the power supply energy flow modeling and grouped power supply of each module inside the onboard computer can be described in a multi-level and dynamically updated manner.

[0012] Specifically, in the internal and external information flow IBD diagram of the onboard computer, the external interfaces of the stand-alone machine are assigned to the external interfaces of the modules, the interface interconnection relationship between modules is visualized and modeled, and the input and output information flow of the interface is clarified through the flow item model elements.

[0013] The physical layer structure modeling of the spaceborne computer is extended to the component layer, establishing a mapping relationship between the unit structure model and the components. Depending on the specific situation, the unit structure model can correspond to a functional circuit composed of several discrete components, the minimum functional circuit of an integrated chip, or an independent functional module of a control chip, etc.

[0014] Specifically, a single-machine component model library is established, with block model elements used to model components. The value attributes of a block can be used to define important performance indicators and parameters of the component, such as weight, operating voltage, power consumption, quality grade, accuracy grade, temperature range, and radiation resistance grade. Boolean operations (AND, OR) and simple algebraic operations on the component performance indicators form the performance indicators of the unit structure model.

[0015] Specifically, the modeling of similar components is achieved through the "Generalization" relationship. The general characteristics of a certain type of component are abstracted, and a parent class model block is defined, such as resistors, crystal oscillators, antifuse FPGAs, etc.; the characteristics of subclasses or specific components or chips are defined through redefinition of specific attribute values.

[0016] In particular, in object-oriented structural modeling, the modeling of onboard computer processor module hardware and CPU application software (such as space management software) has the following two modes:

[0017] (1) The CPU of the processor module does not have an operating system installed. To achieve structural modeling for the interaction between the processor module hardware and CPU application software (such as the space management software), the modeling elements of the port's "behavioral features" are primarily used. The space management software processes the information and control flow of the entire onboard computer by directly accessing the processor's specific physical address space. Therefore, the following modeling method is adopted:

[0018] a) The processor module block provides a "prov operation" that can access its memory address, and also provides several "behavior ports" defined by the "interface".

[0019] b) The interface contains several operations attributes, which are implemented by the provoperation provided by the processor module block, converting the interface into a provided interface for use by the space management software.

[0020] c) The star management software block has corresponding ports defined by several required interfaces. By connecting with the ports defined by the provided interfaces in the processor module block, it calls the provided operations provided by the processor module block to access specific address spaces in the hardware.

[0021] (2) Operating System Installation on the CPU of the Processor Module. To achieve structural modeling for the interaction between the processor module hardware and CPU application software (such as space management software), the SysML language's "reference property" element is primarily used. At this point, the hardware API functions provided by the operating system can directly access modules of the onboard computer (such as the time base & serial I / O module 1 block). Hardware API function blocks and CPU application software (such as space management software) blocks are defined as components of the CPU software block. The hardware API function block contains several operation attributes, with the operation implementation methods provided by the blocks of each functional module of the onboard computer. Other functional modules of the onboard computer are used as "reference properties" of the CPU software module and connected using a bond connector, thereby enabling structural modeling for application software access to hardware modules and hardware-software interaction.

[0022] In the semi-physical hybrid behavior modeling of spaceborne computers, state machine behavior serves as the classifier behavior of a single spaceborne computer, defining its behavioral patterns throughout its entire on-orbit lifecycle (including: initial operating mode, normal flight mode, emergency operating mode, and long-term autonomous operation mode). By setting the entry, exit, and do activities for each state in the state machine, the modeling of a specific behavioral activity within a particular operating mode is achieved.

[0023] Specifically, in the remote control behavior modeling of the spaceborne computer, a hybrid modeling approach combining physical and logical methods is adopted, using activity diagrams. The outermost activities in the activity diagrams are call behavior actions, defined using verb-object phrases to describe the logical behavior. For each call behavior action, a sub-activity diagram is created. Inside each activity diagram, opaque actions are used, and lightweight JavaScript code is written to implement the logical behavior, simulating the physical behavior implemented by the corresponding underlying hardware modules.

[0024] Specifically, the opaque action can, but is not limited to, the parsing and distribution of binary remote control PCM codes input from transponders by the onboard computer; processing and framing PCM codes formed from digital telemetry information from individual units and analog telemetry information collected by the onboard computer, and sending them to the telemetry and control subsystem, thereby providing behavioral-level descriptions of hardware units. The code running the opaque action can be reverse-engineered from the Verilog language of the FPGA or the C language code of the lower-level machine.

[0025] In particular, all kinds of behaviors and operations generated in behavior modeling are associated with the corresponding block elements, enjoy the behavior execution context provided by the block, and can access the value attributes and interface attributes of the block.

[0026] In confirming the functional and performance requirements of onboard computers, the confirmation methods are divided into three categories: confirmation of functional requirements, confirmation of derived performance indicators (such as quality, power consumption, reliability indicators, etc.), and confirmation of attribute-based performance indicators (such as processor clock speed, SRAM storage space, etc.).

[0027] Specifically, the functional requirements of the onboard computer are confirmed through the tracing of the "satisfy matrix". The performance indicators of the onboard computer attribute class are confirmed through the "satisfy" of the component-related attributes associated with the unit model; the confirmation of the derived class performance indicators requires bottom-up calculation and synthesis.

[0028] In the test environment of a standalone model of the spaceborne computer, a closed-loop test system for multi-task scenarios of the spaceborne computer, based on a UI interface, is constructed. The test system establishes a test context block, which includes the standalone spaceborne computer, a simulated transponder, and a spaceborne computer test module. The simulated transponder can generate uplink remote control commands and forward downlink telemetry data; the spaceborne computer test module simulates other standalone units on the satellite, can be used to respond to remote control commands issued by the spaceborne computer, and return standalone telemetry information.

[0029] Specifically, remote control commands for the simulated transponder are set via a UI interface, generating a remote control binary stream. The onboard computer can simulate the entire process of parsing, processing, and distributing the binary remote control stream, and send remote control commands or remote control signals to specific units or ports within the onboard computer's test module. The results are then visualized through the UI interface associated with the onboard computer's test module.

[0030] Specifically, the UI interface allows for the configuration of RS422-based telemetry information from other subsystems or individual units associated with the onboard computer, generating digital telemetry binary streams. The UI interface also allows for the configuration of analog quantities, temperature measurements, and other telemetry information directly acquired by the onboard computer. The onboard computer can simulate the entire process of acquiring telemetry data from specific units or ports, performing packetization and framing processing of the telemetry information to form a downlink telemetry information stream, which is then sent to the simulated transponder. The UI interface associated with the test context module provides a visual representation of this information.

[0031] Specifically, state machines or activities respond to specific signals to enable communication between modules within the test context. Signals are sent from ports in the model that correspond to the interfaces of actual standalone machines, simulating the processing of external information and control flows by a real onboard computer.

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] (1) This invention uses the system modeling language Sysml to establish a digital model of the onboard computer, which can be easily embedded into the digital satellite for the overall digital design and simulation of the satellite.

[0034] (2) This invention proposes a user interface-based stand-alone model testing system that can realize system-level simulation of functions in multiple scenarios of a stand-alone machine. Through human-computer interaction and stand-alone semi-logic and semi-physical hybrid modeling and simulation, functional simulation and full closed-loop verification of the stand-alone machine design stage are realized.

[0035] (3) This invention defines a digital prototype of a spaceborne computer based on the Sysml language. The requirements, functions, performance, parameters, etc. of the single machine are all unambiguous. The model can be visualized and simulated for information flow, which improves the communication efficiency between the single machine designers of the professional institute and the subsystem designers of the overall unit.

[0036] (4) The digital modeling method of the single machine of the present invention can not only be applied to the design and development of similar single machines in the aerospace field, but can also be further extended to the digital modeling of electronic products with microprocessors in other fields, thereby reducing the product design and development cycle and reducing the product design and development cost. Attached Figure Description

[0037] Figure 1 This is an overview diagram of a spaceborne computer digital modeling method according to an embodiment of the present invention;

[0038] Figure 2 This is a schematic diagram of an object-oriented spaceborne computer structure according to an embodiment of the present invention;

[0039] Figure 3 This is a partial IBD diagram of the internal information flow of a spaceborne computer according to an embodiment of the present invention;

[0040] Figure 4 This is a partial IBD diagram of the internal energy flow of a spaceborne computer according to an embodiment of the present invention;

[0041] Figure 5 An IBD diagram representation of the internal energy flow of a spaceborne computer according to an embodiment of the present invention is shown in group A.

[0042] Figure 6 This is a partial view of a spaceborne computer component model library according to an embodiment of the present invention.

[0043] Figure 7 This invention provides an interface implementation model for the hardware and software interaction structure of a spaceborne computer.

[0044] Figure 8 This is a partial diagram of the definition of a spaceborne computer interface according to an embodiment of the present invention.

[0045] Figure 9 This invention provides a reference for implementing hardware and software interaction modeling of a spaceborne computer in one embodiment.

[0046] Figure 10 This is a partial diagram illustrating the main behavior modeling of a spaceborne computer using a state machine diagram, as described in an embodiment of the present invention.

[0047] Figure 11 An embodiment of the present invention provides an activity graph for modeling the remote control behavior of a spaceborne computer.

[0048] Figure 12 This is a code layer implementation of the opaque action logic behavior according to an embodiment of the present invention.

[0049] Figure 13 This is a partial diagram of the binary PCM bitstream processing implementation in an embodiment of the present invention.

[0050] Figure 14 This is a partial diagram of a spaceborne computer closed-loop test system defined by an IBD diagram according to an embodiment of the present invention.

[0051] Figure 15 This is a partial diagram of the UI and remote control processing implementation of a spaceborne computer closed-loop test system according to an embodiment of the present invention. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0053] Taking a certain type of spaceborne computer as an example, explain the specific components of the digital model of a spaceborne computer. For example... Figure 1As shown, the digital model of the spaceborne computer is divided into five parts: a prototype-oriented requirements model, an object-oriented structural model, a semi-physical hybrid behavior model, functional and performance requirements verification, and a single-machine model testing environment.

[0054] In the requirements modeling of a single spaceborne computer, the initial focus is on the physical prototype, which continues throughout the entire model development process. Requirements modeling for the prototype primarily utilizes a requirements import method. Specifically, the system requirements are extracted from the single-machine task specification and stored as a formatted text file in an Excel requirements table. The MBSE modeling software binds to the requirements table, automatically importing and generating the "Requirement Table." As prototype development progresses from basic to preliminary and final prototypes, the Excel requirements table and the SysML language model element "Requirement Table" are dynamically updated synchronously.

[0055] like Figure 1 As shown, the object-oriented structural model of a single-machine spaceborne computer is divided into three levels from top to bottom: a single-machine structural model, a modular structural model, and a unit structural model; these correspond to the single-machine spaceborne computer, the circuit boards of various functional modules of the spaceborne computer, and the relatively independent constituent units within the circuit boards of each module of the spaceborne computer, respectively. For example... Figure 2 As shown, a hierarchical composition relationship is used to describe the single-machine structure, and this relationship is visualized through a block definition diagram (BDD diagram). The diagram includes: a single-machine structure model (i.e., a single-machine model of an onboard computer), a module model (i.e., a functional module circuit board model), and a unit structure model (i.e., a circuit functional unit model).

[0056] Taking a single onboard computer as an example, multiple IBD diagrams describing the same model element are created to express different perspectives of the model's internal composition. For example... Figure 3 , Figure 4 As shown, energy flow IBD diagrams of the internal modules of the onboard computer and information flow IBD diagrams of the internal and external modules of the onboard computer are established respectively.

[0057] like Figure 3As shown, in the IBD diagram describing the internal energy flow of the onboard computer, the legend model is used to define different styles of connectors between power supply interfaces, modeling the cold and hot backup of each module of the onboard computer. The legend model uses different legends to graphically represent the power supply energy flow of modules under different operating states: namely, the channel gateway and JJM modules A and B, navigation receiver modules A and B, which can respectively realize the capabilities of opening A and opening B, opening A and closing B, and opening B and closing A; processor modules A and B, time base & serial I / O modules A and B, integrated interface modules type I 1 and 2, and power drive modules 1 and 2, each forming an independent group, with each group having the capability of opening A and opening B, opening A and closing B, and opening B and closing A (using II_5VA and II_5V B power supplies respectively). Using legend model elements, a multi-level, dynamically updated description of the power supply energy flow of each module inside the onboard computer and visualization of grouped power supply are achieved. Figure 5 As shown, connectors defined in the same legend model can be highlighted, thereby enabling a hierarchical visualization of power flow.

[0058] like Figure 4 As shown in the IBD diagram of the internal and external information flow of the spaceborne computer, the external interfaces of the stand-alone machine are assigned to the external interfaces of the modules, the interconnection relationship between the interfaces of the modules is visualized and modeled, and the input and output information flow of the interface is clarified through the flow item model elements.

[0059] The physical layer structure modeling of the spaceborne computer is extended to the component layer, establishing a mapping relationship between the unit structure model and the components. Depending on the specific situation, the unit structure model can correspond to a functional circuit composed of several discrete components, the minimum functional circuit of an integrated chip, or an independent functional module of a control chip, etc. For example... Figure 2 As shown, a mapping relationship is established between the crystal block and the device ZA715JCB3-11M05920 (main frequency 11.0592MHz).

[0060] like Figure 6 As shown, block model elements can be used to model components and establish a component model library for a single machine. The value attributes of a block can be used to define important performance indicators and parameters of the components, such as weight, operating voltage, power consumption, quality grade, accuracy grade, temperature range, and radiation resistance grade. Boolean operations (AND, OR) and simple algebraic operations on the component performance indicators yield the performance indicators of the unit structure model.

[0061] Furthermore, such as Figure 6As shown, the modeling of similar components is achieved through the "Generalization" relationship. The general characteristics of a certain type of component are abstracted to create a parent class model block, such as resistors, crystal oscillators, antifuse, FPGAs, etc. The characteristics of subclasses or specific components or chips are defined by redefining specific attribute values ​​of block elements. Specifically, as shown... Figure 6 In the diagram, the parent chip models, such as crystal oscillator chips and DC-DC chips, represented by yellow modules, define the relevant attributes of chip ZA715JCB3-25M00000 by redefining the parent class attributes such as frequency, operating voltage, quality grade, radiation resistance, and unit characteristics. This establishes the relationships between chip models of the same type, facilitating modeling and management.

[0062] In object-oriented structural modeling, to realize the modeling of the hardware of the onboard computer processor module and the CPU running software (such as space management software), the following two modes are proposed:

[0063] (1) The CPU of the processor module does not have an operating system installed. To realize the structural modeling of the interaction between the processor module hardware and the CPU running software (such as the space management software), the modeling elements of port's "behavioral features" are mainly used. At this time, for the actual system, the CPU software, such as the space management software, mainly processes the information flow and control flow of the entire onboard computer by directly accessing the specific physical address space of the processor hardware.

[0064] like Figure 7 As shown, the processor CPU hardware module block provides ports defined by the provided interface, such as port p142 defined by the provided interface "Timebase & Serial I / O Module Type II Module Access I / F". The space management software block has a corresponding port defined by the required interface, such as port p142 defined by the required interface "Timebase & Serial I / O Module Type II Module Access I / F". These ports are interconnected by a connector, allowing the space management software block to access the hardware by calling the operations provided by the processor module block.

[0065] like Figure 8 As shown, the part elements of a processor CPU hardware module model (such as a processor module FPGA) provide access to their memory addresses via "operations". Figure 8The FPGA model of the processor module defines and implements the operation "Time Base & Serial I / O Module Type II Cache Address Read Function (addr:String,out; Return_Data:String)". It also defines several operation attributes within the interface of the processor CPU hardware module's port. For example... Figure 8 The interface named "Timebase & Serial I / O Module Type II Module Access I / F" defines the operation "Timebase & Serial I / O Module Type II Cache Address Read Function (addr:String,out; Return_Data:String)". The processor CPU hardware modules and their constituent "operations" attributes implement the corresponding "operations" attributes in the interface, providing them for external model elements (such as CPU running software) to call. For example... Figure 8 In the interface named "Timebase & Serial I / O Module Type II Module Access I / F", the operation "Timebase & Serial I / O Module Type II Cache Address Read Function" is specifically implemented by the operation of the same name "Timebase & Serial I / O Module Type II Cache Address Read Function" defined in the processor module FPGA model.

[0066] Accordingly, the space management software model can access the processor module FPGA model through the required interface "Timebase & Serial I / O Module Type II Module Access I / F" on page 142 of the "port" to access operations such as "Timebase & Serial I / O Module Type II Cache Address Read Function (addr:String,out Return_Data:String)" and "Timebase & Serial I / O Module Type II Cache Address Write Function (addr:String,Set_Data:String)", thereby simulating access to the processor memory address and realizing access to hardware modules and control of individual machines.

[0067] (2) The CPU of the processor module is equipped with an operating system. To achieve structural modeling for the interaction between the processor module hardware and CPU software (such as space management software), the Sysml language's "reference property" element is primarily used. At this point, for the actual system, the hardware API functions provided by the operating system can directly access the components of the onboard computer (such as time base & serial I / O modules A and B, and integrated interface modules I-type 1 and 2).

[0068] Therefore, such as Figure 9As shown, the hardware device driver API, space service software, and loading monitoring software are defined as components of the integrated management unit application software module. The hardware driver API module contains several "operations" attributes (e.g., provsoiii_sub_recvfrom(*buffer:Integer,channel:Integer,len:Integer), soiii_sub_sendto(*buffer:Integer,channel:Integer,len:Integer) etc.). Each operation serves as a mapping model of the hardware driver interface function in the actual system. The operation is implemented by various functional modules of the onboard computer (e.g., the operation named "prov soiii_sub_recvfrom(*buffer:Integer,channel:Integer,len:Integer)" is implemented by the time base & serial I / O module). Other functional modules of the onboard computer, such as the time base & serial I / O module, channel gateway, and JJM module, are all used as reference properties of the CPU software module and are connected to the corresponding block model using a bond connector, thereby enabling software access to hardware modules and structural modeling of software-hardware interaction.

[0069] like Figure 10 As shown, in the semi-physical hybrid behavior model of the spaceborne computer, the state machine behavior serves as the classifier behavior of the individual spaceborne computer, defining the behavioral patterns of the single machine throughout its entire on-orbit lifecycle (including: initial operating mode, normal flight mode, emergency flight mode, long-term autonomous operation mode, etc.). By setting the entry, exit, and do activities of each state in the state machine, the behavioral activities of a certain state under a specific operating mode are modeled.

[0070] In the remote control behavior model of the spaceborne computer, a hybrid modeling approach combining physical and logical methods is adopted, utilizing activity diagrams for modeling. For example... Figure 11As shown in the activity diagram of remote control behavior, the outer activities use call behavior actions. Verb-object phrases define the logical behavior represented by the activity, allowing for an intuitive understanding of the behavior and input / output flow modeled by the activity diagram. For each call behavior action, further activity diagrams can be created. Within these activity diagrams, opaque actions are used, and lightweight JavaScript executable code is written to implement the logical behavior described by the call behavior action, accurately specifying its concrete implementation details and simulating the physical-level behavior of the underlying hardware modules. Figure 11 In this context, the "remote control command processing and distribution" activity is assigned to the time-based serial port I / O module; to accurately specify the details of executing the "remote control command processing and distribution" activity, Figure 12 In this process, the opaque action parses the input remote control frame data and extracts the "APID". By judging the value of APID, the remote control frame is distributed to the corresponding output port.

[0071] Figure 13 As shown, the activity diagram is simulated. By employing opaque action for semi-physical modeling, the remote control behavior model can simulate the remote control function of an onboard computer, parsing and distributing the input binary remote control PCM code.

[0072] By employing a pattern of nested call behavior actions (descriptions of logical actions) and opaqueaction sub-activities (descriptions of executable script code), it is possible to further visualize, model, and simulate other behaviors of the onboard computer, providing a physical behavior-level description of hardware functions under different scenarios, including but not limited to telemetry behavior. In telemetry behavior, the onboard computer collects digital telemetry data from each individual unit via a time-based serial port I / O module, and analog telemetry data via a comprehensive interface board module. The satellite control software processes and assembles various telemetry information into packets and frames, forming downlink telemetry information that is sent to the telemetry and control subsystem.

[0073] The code for the opaque action can be reverse-engineered from the Verilog language of the FPGA or the C language code of the lower-level machine.

[0074] like Figure 10 , 11 As shown in Figure 12, all kinds of behaviors and operations in the behavior model are associated with the block elements of the behavior and enjoy the behavior execution context provided by the block.

[0075] In confirming the functional and performance requirements of onboard computers, the confirmation methods are divided into three categories: confirmation of functional requirements, confirmation of derived performance indicators (such as quality, power consumption, reliability indicators, etc.), and confirmation of attribute-based performance indicators (such as processor clock speed, SRAM storage space, etc.).

[0076] The functional requirements of the onboard computer were confirmed through the tracing of the "satisfy matrix". Performance indicators of the onboard computer's attributes were confirmed through the "satisfy" of the component-related attributes associated with the unit model. For example, using the BM3823 processor, the value attribute "clock frequency: 200MHz" in the BM3823 model satisfies the requirement of "computing performance: clock frequency not less than 200MHz" for the onboard computer. Confirmation of derived performance indicators requires bottom-up calculation and synthesis. In this model, to meet the requirement of "storage resources NOR FLASH not less than 64MB (32M×16bit, with ECC)" for the onboard computer, calculations were performed using the value attribute "storage size: 16M*16bit" of the component SM29LV256MC model and the value attribute "NOR FLASH number: 3" of the processor module model, thus confirming that the requirement was met.

[0077] In the test environment of a standalone spaceborne computer model, a closed-loop test system for multi-task scenarios of the spaceborne computer, based on a UI interface, is constructed. For example... Figure 14 As shown, a test context model block is established, containing an onboard computer model, a simulated transponder model, and an onboard computer test module model. The simulated transponder can generate uplink remote control commands and acquire downlink telemetry data; the onboard computer test module can simulate other onboard units, respond to remote control commands issued by the onboard computer, and simulate other units generating telemetry information.

[0078] like Figure 15As shown, remote control commands are configured through the module associated with the simulated transponder in the UI interface, generating an uplink remote control binary code stream. As shown in the figure, in the "OC Command Settings" row, the text edit boxes named "Channel Settings (0-64)" and "Command Pulse Width (ms)" allow you to set the channel and negative pulse width of the OC command. After setting, clicking the "Set Remote Control Frame Complete" button generates the corresponding binary code stream based on the settings; the generated binary remote control code stream is then displayed in the text edit box corresponding to "PCM Code Display". Clicking the "Send Remote Control Command" button sends the binary remote control code stream to the onboard computer module. The onboard computer module can simulate the entire process of parsing, processing, and distributing the binary remote control code stream, and send remote control commands or remote control signals to specific ports in the onboard computer test module according to the physical implementation. In the UI interface corresponding to the onboard computer test module, clicking "Start Remote Control Test" accepts the remote control command, which is then visually displayed by the labels or text boxes associated with the onboard computer test module. Figure 15 In the simulation, after the transponder sends an OC command and the onboard computer processes it, the onboard computer interface test module receives the OC command. At this time, the labels for "OC Command Output" and "Binary Code Stream Output" under the "Onboard Computer Interface Test Module Remote Control Test" combo box display the processed text output and binary code output of the OC command, respectively.

[0079] like Figure 15 As shown, the onboard computer test module can simulate the generation of telemetry information by a standalone unit. The telemetry information output by the onboard computer test module can be configured through a UI interface. Digital telemetry information and analog telemetry information such as temperature, current, and voltage values ​​can be set, and the corresponding ports of the onboard computer collect the telemetry information. The onboard computer can simulate the entire process of acquiring telemetry data from a specific standalone unit or port, process and frame the binary telemetry data stream to form a downlink telemetry information stream, and send it to the transponder based on real physical implementation. The acquisition, processing, and transmission of telemetry information are visualized through the UI interface associated with the test context module.

[0080] The communication flow items of the test context are modeled using a "signal," which sets property attributes describing the communication information. The state machines and activities in the onboard computer model, simulated transponder model, and onboard computer test module model achieve communication between different models by generating or responding to specific "signals." The "signal" is sent from the port of the interface corresponding to the actual single machine in the model, used to simulate the external information flow and control flow of the real onboard computer.

[0081] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A digital model of a single-unit spaceborne computer for aerospace applications, characterized in that, include: Requirements model for prototypes, object-oriented structural model, semi-physical hybrid behavior model, functional and performance requirements verification, and test environment for single-machine model; The prototype-oriented requirements model first focuses on the physical prototype of a single machine and continues throughout the product development process. It uses the requirements modeling elements of the SysML language to model the requirements through a requirements import method. The single-machine system requirements are extracted from the single-machine task book and stored in an Excel requirements table as formatted text. The requirements table is bound to the SysML language modeling software, and the requirements are automatically imported to generate the "Requirement Table". As the prototype development progresses from a rough sample to a preliminary sample and then to a final sample, the Excel requirements table and the SysML language model elements "Requirement Table" are dynamically updated synchronously. The object-oriented structural model is divided into four levels from top to bottom: single-machine structural model, module structural model, unit structural model, and component structural model; corresponding to the entire spaceborne computer, the circuit boards of each functional module of the spaceborne computer, and the relatively independent constituent units and electronic components in each module circuit board of the spaceborne computer. This includes establishing multiple IBD diagrams describing the same model element to express different perspectives on the internal composition of the model; and establishing IBD diagrams of energy flow inside the onboard computer and information flow inside and outside the onboard computer. In the IBD diagram describing the internal energy flow of the onboard computer, different styles of connectors between power supply interfaces are defined using legend model elements to model the cold and hot backup structure of each module of the onboard computer. The power supply energy flow of each module under different working states is graphically expressed: that is, the channel gateway and JJM modules A and B, navigation receiver modules A and B, can respectively realize the ability to turn A on B, turn A off B, and turn B off A; processor modules A and B, time base & serial IO modules 1 and 2, integrated interface modules type I 1 and 2, and power drive modules 1 and 2 form independent groups, each with the ability to turn A on B, turn A off B, and turn B off A; using legend model elements, the power supply energy flow of each module inside the onboard computer can be described in a multi-level and dynamically updated manner, and the visualization of grouped power supply can be realized. In the internal and external information flow IBD diagram of a spaceborne computer, the external interfaces of individual machines are assigned to the external interfaces of modules, the interconnection relationships between modules are visualized and modeled, and the input and output information flows of the interfaces are clarified through flow item model elements; In the semi-physical hybrid behavior model, the state machine behavior serves as the classifier behavior of the onboard computer, describing the behavior patterns of the single machine throughout its on-orbit lifecycle, including: initial working mode, normal flight mode, emergency working mode, and long-term autonomous operation mode; by setting the entry, exit, and doactivity of each state in the state machine, the modeling of specific activities is introduced. In the remote control behavior model of the onboard computer, a hybrid modeling approach combining physical and logical methods is adopted, using activity diagrams for modeling. The outer activities in the activity diagrams use call behavior actions, and verb-object phrases are used to define the logical behavior described by the activities. An activity is created for each call behavior action, and opaque actions are used inside the activity activity diagram. Lightweight JavaScript code is written to implement the logical behavior and simulate the physical behavior of the module. Among them, the opaque action can realize, but is not limited to, the parsing and distribution of binary remote control PCM codes input by the transponder by the onboard computer; after the onboard computer collects the digital and analog telemetry data from each unit, it performs packet and frame processing to form binary telemetry PCM codes, thereby providing a behavioral-level description of the hardware unit; the code running in the opaque action can be reverse-engineered from the Verilog language of the FPGA or the C language code of the lower-level machine. In the behavior model, each behavior and operation is associated with the corresponding block element, enjoys the behavior execution context provided by the block, and accesses the value attributes and interface attributes of the block.

2. The digital model of a single-unit spaceborne computer for aerospace applications as described in claim 1, characterized in that, In the object-oriented structural model, the physical layer structural model of the spaceborne computer is extended to the component layer, and the unit structural model inside the module structural layer is mapped and associated with the components. Depending on the specific situation, the unit structural model corresponds to a functional circuit composed of several discrete components, the minimum functional circuit of an integrated chip, and an independent functional module of a large-scale integrated circuit. Among them, a single-machine component model library is established using block model elements. The value attributes of the block are used to define the important performance indicators and parameters of the components, including weight, operating voltage, power consumption, quality grade, accuracy grade, temperature range and radiation resistance grade. Boolean operations and simple algebraic operations of the component performance indicators form the performance indicators of the unit structure model. The modeling of similar components is achieved through the "Generalization" relationship; the general characteristics of a certain type of component are abstracted to establish a parent class model block, including: resistors, capacitors, diodes, crystal oscillators, antifuse, FPGAs, integrated chips, GPUs, and microprocessors; the characteristics of subclasses or specific components or chips are defined by inheriting from the parent class block and redefining the inherited specific attribute values.

3. The digital model of a single-unit spaceborne computer for aerospace applications as described in claim 1, characterized in that, In object-oriented structural models, the modeling of CPU hardware and CPU application software in the onboard computer processor module has the following two modes, depending on the different situations: (1) The CPU of the processor module does not have an operating system installed. To realize the structural modeling of the interaction between the CPU hardware and the CPU application software, the modeling element of the port's "behavioral features" is mainly used. The space management software processes the information flow and control flow of the entire spaceborne computer by directly accessing the specific physical address space of the processor hardware. Therefore, the following modeling method is adopted: a) The processor module block provides a "prov operation" that can access its memory address, and also provides several "behavior ports" defined by the "interface"; b) The interface contains several operations attributes, which are implemented by the provoperation provided by the processor module block, and the interface is converted into a provided interface for use by the space management software. c) The space management software block has corresponding ports defined by several required interfaces. By connecting with the ports defined by the provided interfaces in the processor module block, it calls the provided operations provided by the processor module block to access specific address spaces in the hardware. (2) The CPU of the processor module is equipped with an operating system. To realize the structural modeling of the interaction between the CPU hardware and the CPU application software of the processor module, the Sysml language's "reference property" element is mainly used. At this time, the hardware API functions provided by the operating system can directly access the module model of the onboard computer. The hardware API function block and the CPU application software block are defined as the components of the CPU software block. The hardware API function block contains several operation attributes, and the operation implementation method is provided by the block of each functional module of the single machine. Other functional modules of the onboard computer are used as the "reference property" of the CPU software module and are connected by a bond connector, thereby realizing the structural modeling of the application CPU software accessing the hardware module and the interaction between software and hardware.

4. The digital model of a single-unit spaceborne computer for aerospace applications as described in claim 1, characterized in that, In the confirmation of functional and performance requirements, there are three types of confirmation methods: confirmation of functional requirements, confirmation of derived class performance indicators, and confirmation of attribute class performance indicators. Among them, the confirmation of the functional requirements of the onboard computer is achieved through the tracing of the "satisfy matrix"; the confirmation of the performance indicators of the onboard computer attribute class is achieved through the "satisfy" relationship of the component-related attributes associated with the unit model; the confirmation of the derived class performance indicators requires bottom-up calculation and synthesis.

5. The digital model of a single-unit spaceborne computer for aerospace applications as described in claim 1, characterized in that, In the test environment of the single-machine model, a closed-loop test system for multi-task scenarios of the spaceborne computer based on a UI interface is constructed. A test context block is established in the test system, which includes the spaceborne computer, a simulated transponder, and a spaceborne computer test module. The simulated transponder can generate uplink remote control commands and forward downlink telemetry data. The spaceborne computer test module simulates other single machines on the satellite that interact with the spaceborne computer. It can be used to respond to the remote control commands issued by the spaceborne computer and return the telemetry information of the single machine. The process involves setting uplink remote control commands from simulated response inputs via a UI interface to generate a remote control binary PCM code stream; the onboard computer simulates the parsing, processing, and distribution of the binary remote control code stream throughout the entire process, and sends remote control commands or remote control numbers to specific units or ports in the onboard computer test module according to the actual physical implementation; and the UI interface associated with the onboard computer test module provides a visual display. Specifically, the system allows for the configuration of RS422-based telemetry information from other subsystems or individual units associated with the onboard computer via a UI interface, generating digital telemetry binary streams. It also allows for the configuration of analog and temperature telemetry information directly acquired by the onboard computer via the UI interface. The onboard computer can simulate the entire process of acquiring telemetry data from specific individual units or ports, and perform packetization and framing of the telemetry information to form a downlink telemetry information stream, which is then sent to the simulated transponder with reference to real physical implementation. The downlink telemetry information is visualized through the UI interface associated with the test context module. The communication between modules in the test context is achieved by using a state machine or activity to respond to specific signals. The signals are sent by the port of the interface corresponding to the actual single machine in the model, which is used to simulate the external information flow and control flow of the real spaceborne computer.

Images