Semi-automatic simulation method and system for complex embedded system software requirements based on VHDL (Very High Definition Language)

Abstract

The invention discloses a semi-automatic simulation method and system for complex embedded system software requirements based on VHDL, and relates to the field of requirement engineering.The method comprises the steps that an equipment model of a specific field is predefined; generating an atomic controller VHDL model and a data storage VHDL model according to an atomic controller demand in the software demand specification; generating a combined controller VHDL model according to a combined controller demand in the software demand specification; in the system combination stage, the atomic controller VHDL model, the equipment VHDL model, the data storage VHDL model and the combination controller VHDL model are combined, and a complete system model is obtained; and in a property verification execution stage, a VHDL verification tool Vivado is used for carrying out property verification on the complete system model. According to the method, the VHDL models meeting requirements can be generated and combined to obtain a complete system model, and requirement simulation and property verification are achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of demand engineering, and more particularly to a VHDL-based semi-automatic simulation method and system for complex embedded system software demand. Background Art

[0002] With the development of embedded systems, the scale and complexity of the systems are growing exponentially. These systems involve complex features such as multiple components, network communications, parallel processing, and real-time response. Traditional requirements verification methods cannot effectively cope with this complexity, so simulation methods are needed to provide more comprehensive and accurate verification.

[0003] In the development process of complex embedded systems, requirements errors or omissions may lead to serious consequences, such as system failures, incomplete functions, performance issues, etc., and the cost of repairing these problems is often very high. Through simulation verification in the requirements stage, problems can be discovered and solved early, reducing the risks and costs in the development process. At the same time, the development of complex embedded systems is also a process of continuous iteration and improvement. There may be vague or imperfect parts in the requirements specification, which need to be verified and improved through simulation methods. Through continuous simulation verification and improvement, the quality of the requirements specification and the reliability of the system can be gradually improved.

[0004] Therefore, how to provide a demand simulation method for complex embedded systems is a technical problem that those skilled in the art urgently need to solve. Summary of the invention

[0005] In view of this, the present invention provides a VHDL-based semi-automatic simulation method and system for complex embedded system software requirements, which solves the problems existing in the background technology.

[0006] In order to achieve the above object, the present invention provides the following technical solutions:

[0007] A semi-automatic simulation method for complex embedded system software requirements based on VHDL, comprising the following steps:

[0008] Predefine a device model for a specific field, where the device model is an artificially constructed device VHDL model;

[0009] According to the atomic controller requirements in the software requirements specification, the atomic controller VHDL model is generated and the computing components therein are supplemented and improved manually;

[0010] Generate a data storage VHDL model based on the atomic controller requirements in the software requirements specification;

[0011] Generate a VHDL model of the combined controller according to the combined controller requirements in the software requirements specification;

[0012] In the combined system stage, the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combined controller VHDL model are combined to obtain a complete system model;

[0013] In the performance verification phase, the VHDL verification tool Vivado is used to perform property verification on the complete system model.

[0014] Optionally, an atomic controller VHDL model is generated and the computing components are supplemented and improved manually, specifically including the following steps:

[0015] Traverse the atomic controller requirements in the software requirement specification to obtain the atomic controllers, computing components, device names, and data storage names involved in the atomic controller requirements;

[0016] Generate a model structure of an atomic controller VHDL model according to the atomic controller name and computing component name required by the atomic controller;

[0017] Generate entity port declarations of the atomic controller VHDL model according to the device names and the calling signals to the devices, the data storage names and the calling signals to the data storage, and the computing component names and the calling signals to the computing components involved in the atomic controller requirements;

[0018] Based on the relationship between the atomic controller requirements and the combined controller requirements, the initial state and end state of the atomic controller VHDL model are generated. Combined with the call signal sequence of the atomic controller requirements for the device, data storage and computing components, the atomic controller state machine process is generated.

[0019] Generate signals and variables used in the atomic controller VHDL model according to the shared phenomenon description in the atomic controller requirements;

[0020] The computational components in the generated atomic controller VHDL model are supplemented and improved manually.

[0021] Optionally, generate a data storage VHDL model, specifically:

[0022] Generate entity port declarations of the data storage VHDL model according to the data storage name and the calling signal of the data storage required by the atomic controller.

[0023] Optionally, generating a VHDL model of the combined controller includes the following steps:

[0024] Generate entity port declarations of the combined controller VHDL model according to the combined controller name required by the combined controller;

[0025] Generate the state of the combined controller VHDL model according to the combined controller name and its relationship required by the combined controller;

[0026] According to the time constraints on the combined controller in the combined controller requirements, the transition conditions between corresponding states are generated.

[0027] Optionally, a complete system model is obtained, specifically including the following steps:

[0028] Generate a system structure tree according to the name of the combined controller and its relationship required by the combined controller, and traverse the structure tree from bottom to top to combine the combined controller VHDL model and the atomic controller VHDL model;

[0029] According to the data storage name and the calling signal of the data storage required by the atomic controller, the model obtained in the previous step and the data storage VHDL model are combined;

[0030] According to the device names involved in the atomic controller requirements and the calling signals for the devices, the model obtained in the previous step and the device VHDL model are combined to obtain a complete system model.

[0031] Optionally, during the property verification phase, the property types to be verified and the properties that Vivado can verify specifically include:

[0032] Data flow correctness: Verify whether the system meets the data correctness requirements defined in the software requirements specification when processing data;

[0033] Control flow correctness: Verify that the system operates according to the functions specified in the software requirements specification;

[0034] Time constraint satisfiability: For complex embedded systems with time constraints, verify whether the corresponding actions are completed within the specified time.

[0035] Optionally, verification of the satisfiability of timing constraints includes the following three main types:

[0036] 1) Detection at a specific time t0, entering state X: A<>X imply t==t0;

[0037] 2) Task T is a periodic task with a period of p. Assume that clock t specifically records the task execution time and check whether it meets the period: A<>T.init imply t==p; where T.init represents the node in the init state of the T-time automaton model;

[0038] 3) Check whether the time interval during which state X is maintained is [t1, t2]: A<>X implies t>=t1&&t<=t2.

[0039] A semi-automatic simulation system for complex embedded system software requirements based on VHDL, comprising: a device pre-definition module, an atomic controller generation module, a data storage generation module, a combination controller generation module, a system combination module and a property verification module;

[0040] The device pre-definition module is used to pre-define a device model in a specific field, and the device model is an artificially constructed device VHDL model;

[0041] The atomic controller generation module is used to generate an atomic controller VHDL model according to the atomic controller requirements in the software requirements specification and manually supplement and improve the calculation components;

[0042] The data storage generation module is used to generate a data storage VHDL model according to the atomic controller requirements in the software requirement specification;

[0043] The combined controller generation module is used to generate a combined controller VHDL model according to the combined controller requirements in the software requirements specification;

[0044] The system combination module is used to combine the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combination controller VHDL model to obtain a complete system model;

[0045] The property verification module verifies the properties of the complete system model by using the VHDL verification tool Vivado.

[0046] It can be seen from the above technical solution that compared with the prior art, the present invention provides a VHDL-based semi-automatic simulation method and system for complex embedded system software requirements. By combining the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combined controller VHDL model, a complete system model is obtained, which can realize the semi-automatic generation process of the simulation model, and then the property verification is performed by calling the Vivado software, thereby realizing the semi-automatic generation and property verification of the demand simulation model. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0048] Figure 1A flow chart of a VHDL-based semi-automatic simulation method for complex embedded system software requirements provided by the present invention;

[0049] Figure 2 A VHDL model structure corresponding to the basic structure in the atomic controller requirements provided by the present invention;

[0050] Figure 3(a)-Figure 3(c) They are schematic diagrams of a gyro device model, a sun sensor device model, and a thruster device model provided by the present invention respectively;

[0051] Figure 4(a)-Figure 4(d) Schematic diagrams of the device declaration, comprehensive combination controller requirements, data acquisition combination controller requirements and gyro data acquisition atomic controller requirements of the software requirement specification of the solar search system provided by the present invention;

[0052] Figure 5 A comprehensive combined controller model of a solar search system provided by the present invention;

[0053] Figure 6 A data acquisition combined controller model for a solar search system provided by the present invention;

[0054] Figure 7 A gyro data acquisition atomic controller model for a generated solar search system provided by the present invention;

[0055] Figure 8 A system structure tree of a solar search system generated by the present invention;

[0056] Fig. 9 This is a simulation waveform diagram of the atomic problem of gyro data collection for the solar search system using the Vivado platform of the present invention;

[0057] Fig.10 The software requirement specification data flow consistency verification results, control flow correctness verification results, and time constraint satisfiability verification results of the solar search system provided by the present invention. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0059] The embodiment of the present invention discloses a semi-automatic simulation method for complex embedded system software requirements based on VHDL, such as Figure 1 As shown, the following steps are included:

[0060] 1. Generate domain-specific device VHDL models based on the atomic controller requirements in the software requirements specification.

[0061] Specifically, device models are generally divided into two types: sensors and actuators, which play different roles and functions in the system. Sensors are devices used to sense the external environment. They can detect various physical quantities or parameters in the environment, perform detection regularly or based on external event triggers, and transmit the detected data to the system. Actuators are devices that perform corresponding actions according to system instructions. They can perform specific operations or actions based on the received control signals. In the VHDL model, the state machine process is used to realize the switching between various states of the device, including basic open and closed states, etc., and external events are simulated through ports.

[0062] 2. Generate the atomic controller VHDL model according to the atomic controller requirements in the software requirement specification.

[0063] Traverse the atomic controller requirements in the software requirement specification to obtain the atomic controllers, computing components, device names and data storage names involved in the atomic controller requirements; generate the model structure of the atomic controller VHDL model according to the atomic controller names and computing component names in the atomic controller requirements; generate the entity port declaration of the atomic controller VHDL model according to the device names and the calling signals to the devices, the data storage names and the calling signals to the data storages, and the computing component names and the calling signals to the computing components involved in the atomic controller requirements; based on the relationship between the atomic controller requirements and the combined controller requirements, generate the initial state and the end state of the atomic controller VHDL model to cope with the call of the combined controller, and generate the atomic controller state machine process in combination with the calling signal sequence of the atomic controller requirements for the devices, data storage and computing components; generate the signals and variables used in the atomic controller VHDL model according to the description of the shared phenomenon in the atomic controller requirements; and manually supplement and improve the computing components in the generated atomic controller VHDL model.

[0064] Specifically, the atomic controller model is generated according to the atomic controller requirements in the software requirement specification. The atomic controller is called by the composite controller or is not called and runs in parallel with other controllers.

[0065] In the problem domain involved in the atomic controller requirement, the controller, computing component and data storage belong to the embedded software. In the design of the atomic controller VHDL simulation model, we map the controller, computing component and data storage into a VHDL design entity. However, since data storage is a manifestation of the association between sub-requirements, the same data storage may appear in multiple atomic controller requirements, so the atomic controller VHDL model does not include data storage. Due to the unique requirement pattern of data conversion, all atomic problems are divided into three categories: one is the atomic problem without calculation, one is the atomic problem used to define the custom component of data conversion, and the other is other atomic problems that interact with custom components. Therefore, the atomic controller VHDL model only contains the controller and computing component, among which the computing component is not necessary. According to the atomic controller name and computing component name of the atomic controller requirement, the model structure of the atomic controller VHDL model is generated.

[0066] The VHDL design entity consists of two parts: entity and architecture. The entity defines the interface of the VHDL design entity, including the name, data type and direction of the input and output signals. The structure defines the specific implementation of the VHDL design entity, such as describing the logical relationship between the components, the assignment and timing relationship of the signal, etc. The behavioral interaction between the controller and each problem domain in the problem diagram is mapped to the port in the entity. The behavioral interaction part according to the requirements of the atomic controller is converted into the entity port declaration in the atomic controller VHDL model. According to Table 1, the behavioral interaction type in the behavioral interaction of the atomic controller is converted into the entity port declaration data type in the model.

[0067] Table 1 Atomic controller behavior interaction converted into entity port declaration relationship table

[0068]

[0069] Based on the relationship between the atomic controller requirements and the combined controller requirements, the initial state and end state of the atomic controller VHDL model are generated to cope with the call of the combined controller. In the initial state, the working state signal is done = '0', indicating that the atomic controller VHDL model is not working. When the working signal start = '1' is started, the state is transferred to the working state, and the atomic controller VHDL model starts to work. In the end state, the working state signal is done = '1', indicating that the atomic controller VHDL model has completed the work and the state is transferred to the initial state. According to the call signal sequence of the atomic controller requirements for the device, data storage and computing components, the working state of the atomic controller VHDL model is generated.

[0070] According to the behavioral interactions in the atomic controller requirements, a memory (RAM) and a storage process (Process) are declared for each input port.

[0071] 3. Generate a data storage VHDL model based on the atomic controller requirements in the software requirements specification.

[0072] According to the data storage name and the calling signal of the data storage involved in the atomic controller requirements, the entity port declaration of the data storage VHDL model is generated; the architecture declaration in the generated data storage VHDL model is supplemented and improved manually.

[0073] 4. Generate a VHDL model of the combined controller based on the combined controller requirements in the software requirement specification.

[0074] According to the name of the combination controller required by the combination controller, the entity port declaration of the combination controller VHDL model is generated; according to the name of the combination controller required by the combination controller and its relationship, the state of the combination controller VHDL model is generated to cope with the call of other combination controllers to it; according to the time constraints on the combination controller in the combination controller requirements, the migration conditions between corresponding states are generated; the architecture declaration in the generated combination controller VHDL model is manually supplemented and improved.

[0075] Specifically, about the format of software requirement specification. Software requirement specification is a structured representation, and its components mainly include problem domain declaration, combined controller software requirements and atomic controller software requirements. The problem domain declaration is a description of different problem domain types. For example, Figure 4(a) is a declaration of the problem domain of the solar search system. The problem domain is divided into lexical domain and causal domain. The lexical domain is used to store data. For example, after completing the data collection function, the collected data is sent to the lexical domain for storage. The causal domain indicates that there is a causal relationship between interactions. For example, if a gyro device receives a start command, the gyro is in the on state.

[0076] Combination controllers are divided into combination controllers without call requirements (as shown in Figure 4(b)) and combination controllers with call requirements (as shown in Figure 4(c)). Combination controllers describe the combination relationship of atomic controllers or some combination controllers, mainly including sequential structure, loop structure, branch structure and parallel structure; at the same time, they also define the syntax specifications of time constraints.

[0077] The atomic controller defines various structures of software behavior interaction, such as sequential structure, loop structure, branch structure and parallel structure; at the same time, it also defines the syntax specifications of time constraints, such as Figure 2As shown. The sequential structure is divided by ";", b represents a behavior interaction, and its format is generally "Controlname sends / receives instruction / data to anotherControlname / Device[event / value / state]". The sequential structure is to execute each behavior interaction sequentially. The branch structure is reflected as "if(b1constraint){…}else if(b2constraint){…}…", b1constraint and b2constraint are the constraints for branch execution related interactions respectively. At the same time, the branch structure may have multiple branches. When generating the model, the missing branches will be automatically generated according to the constraints. The loop structure is reflected as "while(brelated){…}", b related is the constraint for loop execution, usually the constraint on the clock of a behavior interaction b. For parallel structures, the symbol "||" is used to represent them. Since each model in the timed automaton model is parallel, no additional processing is required for the parallel structure. There are two structures of time constraint structure, among which: "b1; after(T); b2" indicates time delay, which means that after the behavior interaction b1 is executed, it stays for T time and then executes the behavior interaction b2; "at(T){b}" means triggering the behavior interaction b at time T.

[0078] Next, we will describe how to generate a combined controller VHDL model. A combined controller implements its functions by calling other combined controllers or atomic controllers. In order to obtain the calling relationship between combined controllers and atomic controllers, a system structure tree is constructed according to the combined controller requirements in the software requirements specification. All non-leaf nodes in the structure tree are combined controllers, and the child nodes of non-leaf nodes are the atomic controllers and combined controllers called by the combined controller.

[0079] Then, we study how to obtain its state and migration from the software requirement specification from the calling relationship. Prior to this, for each combined controller VHDL model, establish the initial state and the end state to cope with the call of other combined controllers. In the initial state, the working state signal is done = '0', indicating that the combined controller VHDL model is not working. When the working signal start = '1' is started, the state migrates to the working state, and the combined controller VHDL model starts working. In the end state, the working state signal is done = '1', indicating that the combined controller VHDL model has completed the work and the state has migrated to the initial state. The working state of the combined controller VHDL model is generated according to the calling relationship between the combined controller and other controllers.

[0080] The relationship structure between other controllers called by the combined controller is different, and the method of converting it into a VHDL model is also different, as follows:

[0081] For a parallel structure, first create a new working state. Determine the number of call signals contained in the working state according to the number of controllers contained in the parallel structure. The call signal is named with the name of the combined controller to be called plus the "_start" field, such as "Controlname_start". Then add the transition from this state to the next state and the synchronization signal in the transition constraint, such as "Controlname_done".

[0082] For a sequential structure, first create a new working state, which contains a call signal. Name the call signal "Controlname_start" with the name of the combined controller to be called plus the "_start" field. Then add a transition from this state to the next state and a synchronization signal "Controlname_done" in the transition constraint.

[0083] For branch structures, first mark the starting state of the branch, then for each branch, establish a migration from this state, and add guard conditions generated according to the branch conditions to the migration. For the relationship structure within the branch, generate the corresponding model structure according to its structure type. After processing all branches, it is necessary to determine whether all branches cover all possibilities. If not, a new branch needs to be generated to handle other conditions. Finally, add a new working state "end" to represent the end state of the branch structure, and establish a migration from the last state of each branch to the state "end".

[0084] For loop structures, first mark the loop start state, then generate the corresponding model structure for the interactive content within the loop structure according to its structure, and finally add a transition back to the loop start state, and add guard conditions generated according to the loop conditions to the transition constraints.

[0085] For the after(T) time constraint, add the invariant “t<=T” to the current state, add the update constraint “t=0” to the transition into the current state, and add the guard constraint “t>=T” to the transition out of the current state, where t is the clock variable of the current model.

[0086] For the at(T){b} time constraint, two new working states are created. The first working state is entered when the previous working state meets the transition condition. A transition is added from this state to the next new working state and a guard condition "t==T" is added to the transition. t is the clock variable of the current model.

[0087] 5. In the combined system stage, the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combined controller VHDL model are combined to obtain a complete system model.

[0088] According to the names of the combined controllers required by the combined controller and their relationships, a system structure tree is generated, and the structure tree is traversed from bottom to top to combine the combined controller VHDL model and the atomic controller VHDL model; according to the data storage names involved in the atomic controller requirements and the calling signals for the data storage, the model obtained in the previous step is combined with the data storage VHDL model; according to the device names involved in the atomic controller requirements and the calling signals for the devices, the model obtained in the previous step is combined with the device VHDL model to obtain a complete system model.

[0089] 6. In the property verification stage, use the VHDL verification tool Vivado to perform property verification according to the writing methods of different types of properties.

[0090] After the demand simulation model is generated, the properties are verified and the properties are divided into the following types for verification:

[0091] Data flow correctness: Verify whether the system meets the data correctness requirements defined in the software requirements specification when processing data. It can check the correct transmission, conversion, calculation and storage of data;

[0092] Control flow correctness: Verify whether the system operates according to the functions specified in the software requirements specification. It can check whether the system correctly performs the required calculation, control and communication functions;

[0093] Time constraint satisfiability: For complex embedded systems with time constraints, verify whether the corresponding actions are completed within the specified time.

[0094] Specifically, the verification of the satisfiability of time constraints includes the following three main types:

[0095] 1) Detection at a specific time t0, entering state X: A<>X imply t==t0;

[0096] 2) Task T is a periodic task with a period of p. Assume that clock t specifically records the task execution time and check whether it meets the period: A<>T.init imply t==p; where T.init represents the node in the init state of the T-time automaton model;

[0097] 3) Check whether the time interval during which state X is maintained is [t1, t2]: A<>X implies t>=t1&&t<=t2.

[0098] and Figure 1Corresponding to the method described above, the embodiment of the present invention also provides a VHDL-based semi-automatic simulation system for complex embedded system software requirements. Figure 1 The specific implementation of the method in the embodiment of the present invention is a VHDL-based semi-automatic simulation system for complex embedded system software requirements, which can be applied to computer terminals or various mobile devices, and specifically includes:

[0099] A device pre-definition module is used to pre-define a device model in a specific field, wherein the device model is an artificially constructed device VHDL model;

[0100] The atomic controller generation module is used to generate the atomic controller VHDL model according to the atomic controller requirements in the software requirement specification and manually supplement and improve the calculation components;

[0101] A data storage generation module, used for generating a data storage VHDL model according to the atomic controller requirements in the software requirement specification;

[0102] A combined controller generation module is used to generate a combined controller VHDL model according to the combined controller requirements in the software requirement specification;

[0103] The system combination module is used to combine the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combination controller VHDL model to obtain a complete system model;

[0104] The property verification module verifies the properties of the complete system model by using the VHDL verification tool Vivado.

[0105] In order to further describe the technical solution in detail, a specific example of a sun search system is given below for introduction.

[0106] 1. Generate an atomic controller model based on the atomic controller requirements in the software requirement specification.

[0107] There are 19 atomic controller models in the solar search system. Taking the gyro data acquisition atomic controller as an example, the software requirement specification is shown in Figure 4(d). First, add the initial state. The atomic controller is called by the data acquisition combination controller, and add a call signal in the initial state. The call signal is named "Gyro Data Acquisition2_start" with the name of the combination controller to be called plus the "_start" field. Then add an end state, add a transition from the end state to the initial state, and add the synchronization signal "Gyro Data Acquisition 2_done" in the transition constraint. Then according to Figure 2The sequential structure shown handles the interaction part. For the interaction part, different interaction domain types are processed accordingly. According to the software requirements specification, first interact with the gyro device model (G). The behavior interaction type is an event. According to the processing of the device event type behavior interaction in Table 1, first add the state and establish the migration. Because the interaction information is "sends", add the synchronization signal "PulseCountAcquisitionInstruction!" to the migration. Next is the behavior interaction with the gyro data storage (GD). The interaction type is an event. According to the behavior interaction processing of the event type of the data storage in Table 1, add a new state and establish a migration. Add the update constraint "AngularVelocityAnalogStorageInstryction=1" to the migration. After processing all the behavior interactions in sequence, finally establish a migration back to the initial state, and add the synchronization signal "GyroDataAcquisitionFIns!" to indicate that the gyro data acquisition is completed and the completion signal is sent. The finally generated gyro data acquisition atomic controller model is as follows: Figure 7 shown.

[0108] 2. Based on the atomic controller requirements in the software requirements specification, generate the entity port declaration of the device VHDL model, and manually supplement and improve the model structure.

[0109] First, get the names of all devices according to the causal domain, and then traverse the behavioral interactions in the atomic controller requirements. If a device is involved in the behavioral interaction, add the content of the behavioral interaction to the names of the sender and receiver and abbreviate them to get a port name, such as "in_GDA_G_Puls_coun", and then add the port name to the entity port declaration of the device VHDL model.

[0110] For the solar search system, the devices involved include gyroscopes, sun sensors, and thrusters. To model these devices, we must first understand whether the devices are sensors or actuators. Gyroscopes and sun sensors are sensors, and thrusters are actuators. Figure 3(a) shows the VHDL model of the gyroscope device. The gyroscope interacts with the controller through the channels "Gyropoweronsignal" and "Gyropoweroffsignal" to switch the working state of the switch; the external environment attributes "Pulsecount" and "GyropowerstateperIns" are updated through the channels "PulsecountacqIns" and "GyropowerstateperIns". Figure 3(b) shows the VHDL model of the sun sensor. The sun sensor interacts with the controller through the channels "Sunsensorpoweronsignal" and "Sunsensorpoweroffsignal" to switch the switch working state; the detected external environment variables "Sunvisiblesign", "Sunmeasurementangle" and "SunsensorpowerstateperIns" are updated. Figure 3(c) shows the VHDL model of the thruster. The thruster communicates with the controller through the channels "Thrusterpoweronsignal" and "Thrusterpoweroffsignal" to switch the switch working state; the detected external environment variables "JetInterval" and "Thrusterpowerstate" are updated through the channels "JetintervalacqIns" and "ThrusterpowerstateIns"; and the thruster control signal is received through the channel "Triaxialcontrolsignal" to perform jet output to adjust the satellite attitude.

[0111] 3. Based on the atomic controller requirements in the software requirements specification, generate the data storage VHDL model entity port declaration, and manually supplement and improve the model structure.

[0112] First, get the names of all data according to the lexical domain, and then traverse the behavioral interactions in the atomic controller requirements. If a device is involved in the behavioral interaction, add the names of the sender and receiver to the content of the behavioral interaction and abbreviate them to get a port name, such as "in_GDA_G_Puls_coun", and then add the port name to the entity port declaration of the data storage VHDL model.

[0113] 4. Generate a combined controller model based on the combined controller requirements in the software requirement specification.

[0114] Generate the VHDL model of the combined controller according to the software requirement specification of the combined controller. There are 7 combined controllers in the solar search control system. Figure 4(b) and Figure 4(c) respectively show the comprehensive combined controller requirements and data acquisition combined controller requirements in the software requirement specification of the solar search system.

[0115] The software requirement specification of the integrated combined controller in the solar search system given in Figure 4(b) is not called by other combined controllers. The generated combined controller VHDL model is shown in Figure 5 As shown. Since it is not called by other controllers, there is no need to add initial state and end state to receive the scheduling synchronization signal. Then process the interaction content of the calling controller. First, the sequence structure calls Initialization, adds a new working state "Initialization", and adds a call signal in the working state. The call signal "Initialization_start" is named with the name of the combined controller to be called plus the "_start" field. Then add the transition from this state to the next state and the synchronization signal "Initialization_done" in the transition constraint. According to the requirement specification, there is a loop structure "while(160ms)" behind it. For the loop structure, according to Figure 2 As shown, the VHDL model structure corresponding to the loop structure must first record the loop start state start, that is, the start state "Telecontrol InstructionProcessing", and then process the interactive behavior within the loop structure. It is a sequential structure, so according to Figure 2 The time automaton model structure corresponding to the sequential structure in the figure is added according to the name of the called controller. First is "Telecontrol Instruction Processing", then add a working state named after it, and add a call signal in the working state. The call signal "Initialization_start" is named with the name of the combined controller to be called plus the "_start" field, and then add the transition from this state to the next state and the synchronization signal "Initialization_done" in the transition constraint. The subsequent calling controller requirements are handled in the same way. After processing the last called controller in the loop structure, that is, reaching the end state, add a transition back to the starting state, and add the relevant guard condition "t==160" to the transition. According to the comprehensive combined controller requirements in the solar search system, there is no interactive part of itself, and finally the generated combined controller model is obtained.

[0116] The data acquisition combination controller shown in Figure 4(c) is called by the controller. First, the initial state and the end state are established to respond to the call of other combination controllers. In the initial state, the working state signal is Data Acquisition_done = '0', indicating that the combination controller VHDL model is not working. When the starting working signal DataAcquisition_start = '1', the state is transferred to the working state, and the combination controller VHDL model starts to work. In the end state, the working state signal is Data Acquisition_done = '1', indicating that the combination controller VHDL model has completed the work and the state is transferred to the initial state. Next, we process the interaction content of calling the controller. First, we call Gyro Data Acquisition 2 in the sequence structure, add a new working state "Gyro DataAcquisition 2", and add a call signal in the working state. We name the call signal "Gyro Data Acquisition 2_start" with the name of the combined controller to be called plus the "_start" field. Then, we add the migration from this state to the next state and the synchronization signal "Gyro DataAcquisition 2_done" in the migration constraint. We also process the subsequent controller calls in the same way. The generated combined controller model is as follows: Figure 6 shown.

[0117] 5. In the system combination stage, the generated combined controller VHDL model, atomic controller VHDL model, data storage VHDL model and device VHDL model are combined to obtain a complete system model.

[0118] First, according to the combined controller names and their relationships required by the combined controller, a system structure tree is generated. Each subtree in the structure tree is a subsystem, each non-leaf node is a combined controller, and each leaf node is an atomic controller. The system structure tree of the solar search control software is as follows: Figure 8 As shown. Traverse the structure tree from bottom to top, when encountering a non-leaf node, combine the combined controller VHDL model of the non-leaf node with the other controller VHDL models of its child nodes to obtain the preliminary VHDL model of the system.

[0119] Then, according to the data storage name and the calling signal for the data storage involved in the atomic controller requirements, the system software VHDL model is obtained by connecting the system preliminary VHDL model and the data storage VHDL model obtained in the previous step through ports with the same name.

[0120] Finally, according to the device names involved in the atomic controller requirements and the calling signals for the devices, the complete system model is obtained by connecting the system software VHDL model and the device VHDL model obtained in the previous step to the ports with the same name.

[0121] 6. Execute the property verification phase. Write the properties to be verified according to the writing methods of different types of properties, and use Vivado to simulate and perform property verification.

[0122] After generating the demand simulation model, verify the properties and divide the properties into the following types for verification:

[0123] Data flow correctness: Verify whether the system meets the data correctness requirements defined in the software requirements when processing data. It can check the correct transmission, conversion, calculation and storage of data;

[0124] Control flow correctness: Verify whether the system operates according to the functions specified in the software requirements specification. It can check whether the system correctly performs the required calculation, control and communication functions;

[0125] Time constraint satisfiability: For complex embedded systems with time constraints, verify whether the corresponding operations are completed within the specified time.

[0126] This embodiment combines the generated combined controller VHDL model, atomic controller VHDL model, device VHDL model and data storage VHDL model to obtain a complete system model, which can realize the process of automatic generation of simulation models, and then calls Vivado software to perform property verification, thereby realizing automatic generation and property verification of the required simulation model.

[0127] In terms of simulation effect. The specific details of the solar search gyro control output atomic problem are: the machine domain (GCO) sends a read instruction to obtain the gyro power-on instruction from the gyro instruction storage (GI), and forwards the power-on instruction to the computing component (GCOCC). The computing component converts the gyro power-on signal and forwards it to the machine domain (GCO). The machine domain (GCO) sends a power-on signal to the gyro (G) to complete the gyro power-on. Gyro control output atomic controller VHDL model simulation waveform Fig. 9As shown, the waveform of the generated code is explained as follows: the signal name is on the left side of the waveform, and the signal waveform is on the right side. The waveform from top to bottom is the clock signal (clk), start signal (GCO_start), gyro power-on instruction read instruction (out_GCO_GI_Gyro_powe_on_inst_load_inst), gyro power-on instruction (out_GCO_GCOC_Gyro_powe_on_inst), gyro power-on signal memory (RAM_GCO_Gyro_powe_on_puls), gyro power-on signal (out_GCO_G_Gyro_powe_on_puls), completion signal (GCO_done) and status signal (sta).

[0128] The first state (sta0) is the waiting state for startup. The atomic component does not run and has no output signal. As shown in the figure, the signal waveform is an unknown state. At the next clock rising edge after the startup signal becomes high, it switches to the second state (sta1).

[0129] In the second state (sta1), the gyro is powered on and the read command becomes high, and the next clock rising edge switches to the third state (sta2).

[0130] In the third state (sta2), the gyro power-on instruction output to the operator component becomes a valid value (00000001), and the next clock rising edge switches to the fourth state (sta3).

[0131] In the fourth state (sta3), the gyro power-on signal sent by the operation subcomponent becomes a valid value (00000001), and the next clock rising edge switches to the fifth state (sta4).

[0132] In the fifth state (sta4), the gyro power-on signal output to the gyro becomes a valid value (00000001) and the completion signal becomes a high level, and the next clock rising edge switches to the first state (sta0).

[0133] In terms of property verification, the verification results are as follows: Fig.10As shown. Time constraint satisfiability, the timing trigger time constraint of the output jet control signal every 128ms in the solar search control software was successfully verified, and the 160ms periodic loop constraint in the solar search control software was successfully verified; Data flow correctness, there are 263 interfaces in the solar search control software, among which the current mode word sharing phenomenon of the remote control atomic problem and the mode switching atomic problem conflicts, resulting in the failure of 2 consistency constraint verifications. Control flow correctness, there are 19 atomic problems in the solar search control software, and the control flow constraint verification is successful. There are 7 control dependencies in the solar search control software, among which the while loop time constraint of the main control dependency is not bound to the 32ms timer, and the control flow constraint verification fails.

[0134] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0135] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A semi-automatic simulation method for complex embedded system software requirements based on VHDL, characterized in that: The following steps are involved: Predefine the device model for a specific field. The device model is a manually constructed device VHDL model. According to the atomic controller requirements in the software requirements specification, the atomic controller VHDL model is generated and the computing components therein are supplemented and improved manually; Generate a data storage VHDL model based on the atomic controller requirements in the software requirements specification; Generate a VHDL model of the combined controller according to the combined controller requirements in the software requirements specification; In the combined system stage, the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combined controller VHDL model are combined to obtain a complete system model; In the performance verification phase, the VHDL verification tool Vivado is used to perform property verification on the complete system model.

2. A VHDL-based semi-automatic simulation method for complex embedded system software requirements according to claim 1, characterized in that: Generate the atomic controller VHDL model and manually supplement the computing components, which includes the following steps: Traverse the atomic controller requirements in the software requirement specification to obtain the atomic controllers, computing components, device names, and data storage names involved in the atomic controller requirements; Generate a model structure of an atomic controller VHDL model according to the atomic controller name and computing component name required by the atomic controller; Generate entity port declarations of the atomic controller VHDL model according to the device names and the calling signals to the devices, the data storage names and the calling signals to the data storage, and the computing component names and the calling signals to the computing components involved in the atomic controller requirements; Based on the relationship between the atomic controller requirements and the combined controller requirements, the initial state and end state of the atomic controller VHDL model are generated. Combined with the call signal sequence of the atomic controller requirements for the device, data storage and computing components, the atomic controller state machine process is generated. Generate signals and variables used in the atomic controller VHDL model according to the shared phenomenon description in the atomic controller requirements; The computational components in the generated atomic controller VHDL model are supplemented and improved manually.

3. A VHDL-based semi-automatic simulation method for complex embedded system software requirements according to claim 1, characterized in that: Generate a data storage VHDL model, specifically: Generate entity port declarations of the data storage VHDL model according to the data storage name and the calling signal of the data storage required by the atomic controller.

4. A VHDL-based semi-automatic simulation method for complex embedded system software requirements according to claim 1, characterized in that: Generate a VHDL model of the combined controller, including the following steps: Generate entity port declarations of the combined controller VHDL model according to the combined controller name required by the combined controller; Generate the state of the combined controller VHDL model according to the combined controller name and its relationship required by the combined controller; According to the time constraints on the combined controller in the combined controller requirements, the transition conditions between corresponding states are generated.

5. The VHDL-based semi-automatic simulation method for complex embedded system software requirements according to claim 1, characterized in that: Get the complete system model, which includes the following steps: Generate a system structure tree according to the name of the combined controller and its relationship required by the combined controller, and traverse the structure tree from bottom to top to combine the combined controller VHDL model and the atomic controller VHDL model; According to the data storage name and the calling signal of the data storage required by the atomic controller, the model obtained in the previous step and the data storage VHDL model are combined; According to the device names involved in the atomic controller requirements and the calling signals for the devices, the model obtained in the previous step and the device VHDL model are combined to obtain a complete system model.

6. A VHDL-based semi-automatic simulation method for complex embedded system software requirements according to claim 1, characterized in that: In the stage of executing the verification property, the types of properties to be verified and the properties that Vivado can verify include: Data flow correctness: Verify whether the system meets the data correctness requirements defined in the software requirements specification when processing data; Control flow correctness: Verify that the system operates according to the functions specified in the software requirements specification; Time constraint satisfiability: For complex embedded systems with time constraints, verify whether the corresponding actions are completed within the specified time.

7. A VHDL-based semi-automatic simulation method for complex embedded system software requirements according to claim 6, characterized in that: There are three main types of verification of temporal constraint satisfiability: 1) Detection at a specific time t0, entering state X: A<>X imply t==t0; 2) Task T is a periodic task with a period of p. Assume that clock t specifically records the task execution time and check whether it meets the period: A<>T.init imply t==p; where T.init represents the node in the init state of the T-time automaton model; 3) Check whether the time interval during which state X is maintained is [t1, t2]: A<>X implies t>=t1&&t<=t2.

8. A VHDL-based semi-automatic simulation system for complex embedded system software requirements that implements the method of any one of claims 1 to 7, characterized in that: It includes: equipment pre-definition module, atomic controller generation module, data storage generation module, combination controller generation module, system combination module and property verification module; The device pre-definition module is used to pre-define a device model in a specific field, and the device model is an artificially constructed device VHDL model; The atomic controller generation module is used to generate an atomic controller VHDL model according to the atomic controller requirements in the software requirements specification and manually supplement and improve the calculation components; The data storage generation module is used to generate a data storage VHDL model according to the atomic controller requirements in the software requirement specification; The combined controller generation module is used to generate a combined controller VHDL model according to the combined controller requirements in the software requirements specification; The system combination module is used to combine the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combination controller VHDL model to obtain a complete system model; The property verification module verifies the properties of the complete system model by using the VHDL verification tool Vivado.

Images