Semi-automatic simulation method and system for software requirements of complex embedded systems based on VHDL

Abstract

The present invention discloses a semi-automatic simulation method and system for software requirements of a complex embedded system based on VHDL, which relates to the field of requirements engineering and includes: predefining device models for specific domains; generating an atomic controller VHDL model and a data storage VHDL model according to the atomic controller requirements in the software requirements specification; generating a combined controller VHDL model according to the combined controller requirements in the software requirements specification; in the combined system stage, combining the atomic controller VHDL model, the device VHDL model, the data storage VHDL model and the combined controller VHDL model to obtain a complete system model; in the execution verification property stage, using the VHDL verification tool Vivado to perform property verification on the complete system model. The present invention can generate VHDL models that meet the requirements and combine them to obtain a complete system model, realizing requirements simulation and property verification.

Description

Technical Field

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

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

[0003] During the development of complex embedded systems, requirements errors or omissions may lead to serious consequences, such as system failures, incomplete functions, performance issues, etc. The cost of fixing these problems is often very high. By performing simulation verification in the requirements phase, problems can be detected and solved early, reducing the risks and costs during the development process. At the same time, the development of complex embedded systems is also a continuous iterative and improvement process. There may be ambiguous or imperfect parts in the requirements specification, which need to be verified and improved through simulation methods. By 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 requirements 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 semi-automatic simulation method and system for software requirements of complex embedded systems based on VHDL, which solves the problems existing in the background art.

[0006] To achieve the above object, the present invention provides the following technical solutions:

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

[0008] Pre-define device models for specific domains, where the device models are artificially constructed device VHDL models;

[0009] Generate an atomic controller VHDL model according to the atomic controller requirements in the software requirements specification and supplement and improve the computing components therein manually;

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

[0011] Generate a combined controller VHDL model 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 execution verification property stage, the VHDL verification tool Vivado is used to verify the properties of the complete system model.

[0014] Optionally, generate the atomic controller VHDL model and supplement and improve the computing components manually, which specifically includes the following steps:

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

[0016] Generate the model structure of the atomic controller VHDL model according to the atomic controller name and computing component name in the atomic controller requirements;

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

[0018] Based on the relationship between the atomic controller requirements and the combined controller requirements, generate the initial state and end state of the atomic controller VHDL model, and combine the call signal order of the devices, data storage, and computing components in the atomic controller requirements to generate the atomic controller state machine process;

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

[0020] Manually supplement and improve the computing components in the generated atomic controller VHDL model.

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

[0022] Generate the entity port declaration of the data storage VHDL model according to the data storage names involved in the atomic controller requirements and the call signals to the data storage.

[0023] Optionally, generate the combined controller VHDL model, which specifically includes the following steps:

[0024] Generate the entity port declaration of the combined controller VHDL model according to the combined controller name in the combined controller requirements;

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

[0026] Generate the transition conditions between corresponding states according to the time constraints on the combined controller in the combined controller requirements.

[0027] Optionally, obtain the complete system model, which specifically includes the following steps:

[0028] Generate a system structure tree according to the name and relationship of the combined controller 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] Combine the model obtained in the previous step and the data storage VHDL model according to the data storage name involved in the atomic controller requirements and the call signals for the data storage;

[0030] Combine the model obtained in the previous step and the device VHDL model according to the device name involved in the atomic controller requirements and the call signals for the device to obtain the complete system model.

[0031] Optionally, in the execution verification property stage, the types of properties to be verified and the properties verifiable by Vivado 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 whether the system operates according to the functions of 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, the verification of time constraint satisfiability includes the following three main types:

[0036] 1) Detect that 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. Detect whether it meets the period: A<>T.init imply t == p; where, T.init represents being at the init state node of the T-time automaton model;

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

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

[0040] The device predefinition module is used to predefine device models in a specific domain, and the device models are manually constructed device VHDL models;

[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 supplement and perfect the computing components manually;

[0042] The data storage generation module is used to generate a data storage VHDL model according to the atomic controller requirements in the software requirements 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 combined 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 solutions that, compared with the prior art, the present invention provides a semi-automatic simulation method and system for software requirements of complex embedded systems based on VHDL. By combining the generated atomic controller VHDL model, device VHDL model, data storage VHDL model, and combined controller VHDL model, a complete system model can be obtained, and the process of semi-automatically generating a simulation model can be realized. Then, by calling the Vivado software for property verification, the semi-automated generation and property verification of the requirements simulation model can be realized. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0048] Figure 1Flowchart of the semi-automatic simulation method for software requirements of complex embedded systems based on VHDL provided by the present invention;

[0049] Figure 2 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) Schematic diagrams of the gyroscope device model, sun sensor device model, and thruster device model provided by the present invention respectively;

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

[0052] Figure 5 Integrated combination controller model of the generated sun search system provided by the present invention;

[0053] Figure 6 Data acquisition combination controller model of the generated sun search system provided by the present invention;

[0054] Figure 7 Gyro data acquisition atomic controller model of the generated sun search system provided by the present invention;

[0055] Figure 8 System structure tree of the generated sun search system provided by the present invention;

[0056] Figure 9 Simulation waveform diagram of the gyro data acquisition atomic problem of the sun search system using the Vivado platform in the present invention;

[0057] Figure 10 Results of data flow consistency verification, control flow correctness verification, and time constraint satisfiability verification of the software requirements specification of the sun search system provided by the present invention. Detailed implementation manners

[0058] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0059] An embodiment of the present invention discloses a semi-automatic simulation method for software requirements of complex embedded systems based on VHDL, as Figure 1 shown, including the following steps:

[0060] 1. Generate a domain - specific device VHDL model according to the atomic controller requirements in the software requirements specification.

[0061] Specifically, device models are generally divided into two types: sensors and actuators. They play different roles and functions in the system. A sensor is a device used to sense the external environment. It can detect various physical quantities or parameters in the environment, perform detections regularly or triggered by external events, and transmit the detected data to the system. An actuator is a device that executes corresponding behaviors according to system instructions. It can perform specific operations or actions according to the received control signals. In the VHDL model, the various states of the device and the transitions between states are implemented through state - machine processes, including basic on and off states, etc., and external events are simulated through ports.

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

[0063] Traverse the atomic controller requirements in the software requirements 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 name and computing component name in the atomic controller requirements; generate the entity port declarations of the atomic controller VHDL model according to the device names involved in the atomic controller requirements, the call signals to the devices, the data storage names, the call signals to the data storage, and the computing component names and the call signals to the computing components; generate the initial state and end state of the atomic controller VHDL model to respond to the call of the combined controller based on the relationship between the atomic controller requirements and the combined controller requirements, and generate the atomic controller state - machine process in combination with the call signal order of the atomic controller requirements to the devices, data storage, and computing components; generate the signals and variables used in the atomic controller VHDL model according to the shared phenomenon description in the atomic controller requirements; 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 requirements specification. The atomic controller is called by the combined controller or runs in parallel with other controllers without being called.

[0065] In the problem domain related to the atomic controller requirements, the controller, computing components, and data storage are within the embedded software. In the design of the atomic controller VHDL simulation model, we map the controller, computing components, and data storage to a VHDL design entity. However, since the data storage is an embodiment of the correlation between sub-requirements and the same data storage may appear in multiple atomic controller requirements, the data storage is not included in the atomic controller VHDL model. Due to this unique requirement pattern of data conversion, all atomic problems are divided into three categories: one is the atomic problem without computation, one is the atomic problem used to define the custom component for data conversion, and one is the other atomic problems that interact with the custom component. Therefore, the atomic controller VHDL model only contains the controller and computing components, where the computing components are not necessary. Generate the model structure of the atomic controller VHDL model according to the atomic controller name and computing component name in the atomic controller requirements.

[0066] A VHDL design entity consists of two parts: an entity and an architecture. The entity defines the interface of the VHDL design entity, including the names, data types, and directions of input and output signals, etc. The architecture defines the specific implementation method of the VHDL design entity, such as describing the logical relationship between components, signal assignment, and timing relationship, etc. Among them, the behavioral interaction between the controller in the problem diagram and each problem domain is mapped to the ports in the entity. Convert the behavioral interaction part of the atomic controller requirements into the entity port declaration in the atomic controller VHDL model. Convert the behavioral interaction type in the behavioral interaction of the atomic controller into the data type of the entity port declaration in the model according to Table 1.

[0067] Table 1 Relationship table for converting the behavioral interaction of the atomic controller into entity port declarations

[0068]

[0069] Based on the relationship between the atomic controller requirements and the combined controller requirements, generate the initial state and end state of the atomic controller VHDL model to respond to 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 start working signal start = '1', the state migrates 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 its work and the state migrates to the initial state. Generate the working state of the atomic controller VHDL model according to the call signal sequence of the atomic controller requirements for devices, data storage, and computing components.

[0070] Declare a memory (RAM) and a storage process for each input port according to the behavioral interactions in the atomic controller requirements.

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

[0072] Generate the entity port declarations of the data storage VHDL model according to the data storage names involved in the atomic controller requirements and the call signals for the data storage; manually supplement and improve the architecture declarations in the generated data storage VHDL model.

[0073] 4. Generate a combined controller VHDL model according to the combined controller requirements in the software requirements specification.

[0074] Generate the entity port declarations of the combined controller VHDL model according to the combined controller names in the combined controller requirements; generate the states of the combined controller VHDL model according to the combined controller names and their relationships in the combined controller requirements to handle calls from other combined controllers; generate the transition conditions between corresponding states according to the time constraints on the combined controller in the combined controller requirements; manually supplement and improve the architecture declarations in the generated combined controller VHDL model.

[0075] Specifically, regarding the format of the software requirements specification. The software requirements specification is a structured representation, and its components mainly include problem domain declarations, combined controller software requirements, and atomic controller software requirements. Among them, the problem domain declaration is an explanation of different problem domain types. For example, Figure 4(a) is a declaration of the problem domain of the sun search system. The problem domain is divided into the lexical domain and the causal domain. The lexical domain is used to store data. For example, after the data acquisition function is completed, the acquired data is sent to the lexical domain for storage. The causal domain indicates that there is a causal relationship between interactions. For example, for a gyro device, if an enable instruction is received, then the gyro is in the enabled state.

[0076] Combined controllers are divided into combined controllers without call requirements (as shown in Figure 4(b)) and combined controllers with call requirements (as shown in Figure 4(c)). The combined controller describes the combined relationships with atomic controllers or certain combined controllers, mainly including sequential structures, loop structures, branch structures, and parallel structures; at the same time, it also defines the syntax specifications for time constraints.

[0077] In the atomic controller, various structures of software behavioral interactions are defined, such as sequential structures, loop structures, branch structures, and parallel structures; at the same time, the syntax specifications for time constraints are also defined, such as Figure 2As shown below. The sequential structure is separated by ";". b represents a behavioral interaction, and its format is generally "Controlname sends / receives instruction / data to another Controlname / Device[event / value / state]". The sequential structure sequentially executes each behavioral interaction. The branch structure is embodied as "if(b1constraint){…}else if(b2constraint){…}…", where b1constraint and b2constraint are the constraint conditions for the branch to execute relevant interactions respectively. At the same time, the branch structure may have multiple branches, and the missing branches will be automatically generated according to the constraint conditions when generating the model. The loop structure is embodied as "while(brelated){…}", where b related is the constraint condition for loop execution, usually the constraint condition for the clock of a certain behavioral interaction b. For the parallel structure, it is represented by the symbol "||". Since each model is parallel in the timed automata model, no additional processing is required for the parallel structure. There are two structures for the time constraint structure, where: "b1; after(T); b2" represents a time delay, and after the behavioral interaction b1 is executed, it stays for T time and then the behavioral interaction b2 is executed; "at(T){b}" represents triggering the behavioral interaction b at time T.

[0078] Next, it will be described how to generate the combined controller VHDL model. The combined controller realizes its functions by calling other combined controllers or atomic controllers. In order to obtain the call relationship between the combined controller and the atomic controller, 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 the non-leaf nodes are the atomic controllers and combined controllers called by the combined controller.

[0079] Then, it is studied how to obtain its states and transitions from the software requirements specification based on the call relationship. Before that, for each combined controller VHDL model, an initial state and an end state are established to handle the calls from 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 start working signal start = '1', the state migrates to the working state, and the combined controller VHDL model starts to work. In the end state, the working state signal is done = '1', indicating that the combined controller VHDL model has completed its work, and the state migrates to the initial state. The working state of the combined controller VHDL model is generated according to the call relationship between the combined controller and other controllers.

[0080] The relational structures among other controllers called by the combined controller are different, and the methods for converting them into VHDL models are also different, as follows:

[0081] · For a parallel structure, first create a working state. Determine the number of call signals included in the working state according to the number of controllers included in the parallel structure. The call signals are named by adding the "_start" field to the name of the combined controller to be called, in the form of "Controlname_start". Then add the transition from this state to the next state and the synchronization signal in the transition constraint, in the form of "Controlname_done".

[0082] · For a sequential structure, first create a working state. The working state includes a call signal, which is named "Controlname_start" by adding the "_start" field to the name of the combined controller to be called. Then add the transition from this state to the next state and the synchronization signal "Controlname_done" in the transition constraint.

[0083] · For a branch structure, first mark the starting state of the branch. Then, for each branch, establish a transition starting from this state and add a guard condition generated according to the branch condition to the transition. Generate the corresponding model structure for the relational structure within the branch 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 transition from the last state of each branch to the state "end".

[0084] · For a loop structure, first mark the starting state of the loop. Then, generate the corresponding model structure for the interaction content within the loop structure according to its structure. Finally, add a transition back to the starting state of the loop and add a guard condition generated according to the loop condition to the transition constraint.

[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 entering the current state, and add the guard constraint "t >= T" to the transition leaving the current state, where t is the clock variable of the current model.

[0086] · For the at(T){b} time constraint, create two working states. The first working state is entered when the previous working state satisfies the transition condition. Add a transition from this state to the next newly created working state and add the guard condition "t == T" to the transition, where 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 combined controller name and its relationships required by the combined controller, a system structure tree is generated. 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 involved in the atomic controller requirements and the call signals for the data storage, combine the model obtained from the previous combination with the data storage VHDL model; according to the device name involved in the atomic controller requirements and the call signals for the device, combine the model obtained from the previous combination with the device VHDL model to obtain a complete system model.

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

[0090] After generating the requirement simulation model, perform property verification. 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 is possible to check the correct transfer, conversion, calculation, and storage of data, etc.

[0092] Control flow correctness: Verify whether the system operates according to the functions defined in the software requirements specification. It is possible to check whether the system correctly executes 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 time constraint satisfiability includes the following three main types:

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

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

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

[0098] and Figure 1Corresponding to the method described above, an embodiment of the present invention further provides a semi-automatic simulation system for software requirements of a complex embedded system based on VHDL, which is used to Figure 1 For the specific implementation of the method in

[0099] The device predefined module is used to predefine device models in a specific domain, and the device models are manually constructed device VHDL models;

[0100] 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 perfect the computing components;

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

[0102] 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;

[0103] The system combination module is used to combine the generated atomic controller VHDL model, device VHDL model, data storage VHDL model and combined 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] To further describe this 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 requirements specification.

[0107] There are 19 atomic controller models in the sun search system. Taking the gyro data acquisition atomic controller as an example, the software requirements specification is shown in Figure 4(d). First, add an initial state. This atomic controller is called by the data acquisition combined controller, and a call signal is added in the initial state. Name this call signal "Gyro Data Acquisition2_start" with the name of the combined controller to be called plus the "_start" field. Then add an end state, add the migration from the end state to the initial state, and the synchronization signal "Gyro Data Acquisition 2_done" in the migration constraint. Then according to Figure 2The sequential structure shown processes the interaction part. For the interaction part, corresponding processing is carried out for different interaction domain types. According to the software requirement specification, first interact with the gyro device model (G). If the behavior interaction type is an event, then according to the processing of device event type behavior interaction in Table 1, first add a state and establish a transition. Since the interaction information is "sends", then add a synchronization signal "Pulsecountacquisitioninstruction!" on the transition. Next is the behavior interaction with the gyro data storage (GD). The interaction type is an event, so according to the behavior interaction processing of the data storage event type in Table 1, add a new state and establish a transition, and add an update constraint "Angularvelocityanalogstorageinstryction = 1" on the transition. After sequentially processing all behavior interactions, finally establish a transition back to the initial state and add a 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 Figure 7 shown.

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

[0109] First, obtain the names of all devices according to the causal domain, and then traverse the behavior interactions in the atomic controller requirements. If a certain device is involved in the behavior interaction, then add the content of the behavior interaction with the names of the sender and receiver and abbreviate it to get a port name, such as "in_GDA_G_Puls_coun", and then add this 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. When modeling these devices, it is first necessary to clarify whether the device is a sensor or an actuator. 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; it updates the detected external environmental attributes "Pulsecount" and "Gyropowerstate" 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 working state of the switch; it updates the detected external environmental variables "Sunvisiblesign", "Sunmeasurementangle", and "Sunsensorpowerstate" through the channels "SunvisiblesignacqIns", "SunmeasurementangleacqIns", and "SunsensorpowerstateperIns". 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 working state of the switch; it updates the detected external environmental variables "JetInterval" and "Thrusterpowerstate" through the channels "JetintervalacqIns" and "ThrusterpowerstateIns"; it receives the thruster control signal through the channel "Triaxialcontrolsignal" to adjust the satellite attitude by jetting.

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

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

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

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

[0115] The software requirements specification of the comprehensive combined controller in the solar search system shown in Figure 4(b) is not called by other combined controllers. The generated combined controller VHDL model is as Figure 5 shown. Since it is not called by other controllers, there is no need to add initial and end states to receive scheduling synchronization signals. Then process the interaction content of the calling controller. First, for the sequential structure call Initialization, add a new working state "Initialization", and add a call signal in the working state. Name this call signal "Initialization_start" 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 requirements specification, there is a loop structure "while(160ms)" later. For the loop structure, according to Figure 2 shown, the VHDL model structure corresponding to the loop structure first records the start state of the loop, that is, the start state "Telecontrol InstructionProcessing", and then processes the interaction behavior within the loop structure. For the sequential structure, according to Figure 2 the time automaton model structure corresponding to the sequential structure in , add states and transitions according to the name of the called controller. First, for "Telecontrol Instruction Processing", add a working state named after it, and add a call signal in the working state. Name this call signal "Initialization_start" 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. Process the subsequent calling controller requirements 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 start state and add the relevant guard condition "t == 160" on the transition. According to the comprehensive combined controller requirements in the solar search system, there is no self-interaction part, so finally the generated combined controller model is obtained.

[0116] The data acquisition combination controller given in Figure 4(c) is called by the controller. First, the initial state and the end state are established to respond to the calls of other combination controllers. In the initial state, the working state signal is Data Acquisition_done = '0', indicating that the VHDL model of this combination controller does not work. When the start working signal DataAcquisition_start = '1', the state migrates to the working state, and the VHDL model of this combination controller starts to work. In the end state, the working state signal is Data Acquisition_done = '1', indicating that the VHDL model of this combination controller has completed its work, and the state migrates to the initial state. Then, the interaction content of the calling controller is processed. First, the sequential structure calls Gyro Data Acquisition 2, adds a new working state "Gyro DataAcquisition 2", and adds a calling signal in the working state. The calling signal is named "Gyro Data Acquisition 2_start" with the name of the combination controller to be called plus the "_start" field. Then, the migration from this state to the next state and the synchronization signal "Gyro DataAcquisition 2_done" in the migration constraint are added. The same processing is done for the subsequent calling controller requirements. The generated combination controller model is as Figure 6 shown.

[0117] 5. In the system combination stage, the generated combination 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 combination controller name and its relationship required by the combination controller, a system structure tree is generated. Each subtree in the structure tree is a subsystem, each non-leaf node is a combination controller, and each leaf node is an atomic controller. The system structure tree of the sun search control software is as Figure 8 shown. Traverse the structure tree from bottom to top. When a non-leaf node is encountered, the VHDL model of the combination controller of the non-leaf node and the VHDL models of other controllers of its child nodes are combined to obtain a preliminary system VHDL model.

[0119] Then, according to the data storage name involved in the atomic controller requirements and the calling signal for the data storage, the preliminary system VHDL model obtained from the previous combination and the data storage VHDL model are combined by connecting the same-named ports to obtain the system software VHDL model.

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

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

[0122] After generating the requirement simulation model, verify the properties. The properties are divided 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 is possible to check the correct transfer, conversion, calculation, and storage of data, etc.

[0124] Control flow correctness: Verify whether the system operates according to the functions specified in the software requirements specification. It is possible to check whether the system correctly executes 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] In this embodiment, a complete system model is obtained by combining the generated combined controller VHDL model, atomic controller VHDL model, device VHDL model, and data storage VHDL model, which can realize the process of automatic generation of the simulation model. Then, property verification is performed by calling Vivado software, so as to realize the automatic generation of the requirement simulation model and property verification.

[0127] In terms of simulation effect. The specific details of the atomic problem of the sun-seeking gyro control output are as follows: The machine domain (GCO) sends a read instruction to obtain the gyro power-on instruction from the gyro instruction storage (GI), forwards the power-on instruction to the calculation component (GCOCC), and the calculation component converts it to obtain the gyro power-on signal and forwards it to the machine domain (GCO). The machine domain (GCO) sends the power-on signal to the gyro (G) to complete the gyro power-on. Simulation waveform of the gyro control output atomic controller VHDL model Figure 9As shown, the waveform diagram of the generated code is explained as follows: On the left side of the waveform diagram is the signal name, and on the right side is the signal waveform. From top to bottom in the waveform diagram are 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), which is the waiting-for-start state. The atomic component does not run and there is no output signal. As shown in the figure, the signal waveform is in an unknown state. At the next clock rising edge after the start signal becomes high, it switches to the second state (sta1).

[0129] The second state (sta1), where the gyro power-on read instruction becomes high, and it switches to the third state (sta2) at the next clock rising edge.

[0130] The third state (sta2), where the gyro power-on instruction output to the arithmetic sub-component becomes valid (00000001), and it switches to the fourth state (sta3) at the next clock rising edge.

[0131] The fourth state (sta3), where the gyro power-on signal sent by the arithmetic sub-component becomes valid (00000001), and it switches to the fifth state (sta4) at the next clock rising edge.

[0132] The fifth state (sta4), where the gyro power-on signal output to the gyro becomes valid (00000001) and the completion signal becomes high, and it switches to the first state (sta0) at the next clock rising edge.

[0133] Regarding property verification, the verification results are as Figure 10As shown. For time constraint satisfaction, the timing trigger time constraint verification for the jet control signal output every 128 ms in the sun search control software is successful, and the cycle loop constraint verification for 160 ms in the sun search control software is successful; for data flow correctness, there are 263 interfaces in the sun search control software, among which there is a conflict in the current mode word sharing phenomenon of the remote control atomic problem and the mode switching atomic problem, resulting in the failure of 2 consistency constraint verifications. For control flow correctness, there are 19 atomic problems in the sun search control software, and the control flow constraint verification is successful. There are 7 control dependencies in the sun search control software, among which the while loop time constraint of the main control dependency is not bound to the 32 ms timer, resulting in the failure of the control flow constraint verification.

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

[0135] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein can 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 these 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, an atomic controller VHDL model is generated and the computing components therein are supplemented and improved manually, specifically: the atomic controller requirements in the software requirements specification are traversed to obtain the atomic controller, 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 name and computing component name of the atomic controller requirements; generate the entity port declaration of the atomic controller VHDL model according to the device name and the calling signal to the device, the data storage name and the calling signal to the data storage, and the computing component name and the calling signal to the computing component involved in the atomic controller requirements; generate the initial state and the end state of the atomic controller VHDL model based on the relationship between the atomic controller requirements and the combined controller requirements, and generate the atomic controller state machine process in combination with the calling signal sequence of the atomic controller requirements for the device, data storage and computing component; 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; manually supplement and improve the computing components in the generated atomic controller VHDL model; 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, specifically: according to the combined controller name and its relationship required by the combined controller, 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 name involved in the atomic controller requirement and the call signal to the data storage, the model obtained by the previous step is combined with the data storage VHDL model; according to the device name involved in the atomic controller requirement and the call signal to the device, the model obtained by the previous step is combined with the device VHDL model 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 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.

3. 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.

4. 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.

5. A VHDL-based semi-automatic simulation system for complex embedded system software requirements that implements the method described in any one of claims 1 to 4, 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