CN117313369A - Demand simulation method and system for complex embedded system based on time automaton - Google Patents
Demand simulation method and system for complex embedded system based on time automaton Download PDFInfo
- Publication number
- CN117313369A CN117313369A CN202311259417.5A CN202311259417A CN117313369A CN 117313369 A CN117313369 A CN 117313369A CN 202311259417 A CN202311259417 A CN 202311259417A CN 117313369 A CN117313369 A CN 117313369A
- Authority
- CN
- China
- Prior art keywords
- controller
- model
- time
- atomic
- combined
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004088 simulation Methods 0.000 title claims abstract description 44
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000012795 verification Methods 0.000 claims abstract description 47
- 238000013508 migration Methods 0.000 claims description 54
- 230000005012 migration Effects 0.000 claims description 53
- 230000007704 transition Effects 0.000 claims description 21
- 238000013500 data storage Methods 0.000 claims description 17
- 230000002123 temporal effect Effects 0.000 claims description 15
- 230000001360 synchronised effect Effects 0.000 claims description 9
- 108010076504 Protein Sorting Signals Proteins 0.000 claims description 3
- 230000000737 periodic effect Effects 0.000 claims description 3
- 230000003993 interaction Effects 0.000 description 36
- 230000000875 corresponding effect Effects 0.000 description 34
- 238000012545 processing Methods 0.000 description 11
- 230000003542 behavioural effect Effects 0.000 description 10
- 230000008569 process Effects 0.000 description 8
- 230000009471 action Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 5
- 125000004122 cyclic group Chemical group 0.000 description 5
- 230000002452 interceptive effect Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000013480 data collection Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000011282 treatment Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/20—Design optimisation, verification or simulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2115/00—Details relating to the type of the circuit
- G06F2115/02—System on chip [SoC] design
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses a demand simulation method and a demand simulation system of a complex embedded system based on a time automaton, which relate to the technical field of demand engineering and comprise the following steps: predefining a domain-specific device model; generating a combined controller time automaton model based on the combined controller requirements in the software requirement protocol; generating an atomic controller time automaton model based on the atomic controller requirements and the equipment model in the software requirement protocol; generating a simulation system statement, and setting a system variable initial value according to simulation requirements; and executing a property verification stage, writing the property to be verified, and performing property verification by using a time automaton verification tool UPPAAL. The invention combines the generated combined controller time automaton model, the atomic controller time automaton model and the equipment model to obtain a complete system model, and then writes properties to carry out property verification by calling UPPAAL software, thereby realizing automatic generation and property verification of the demand simulation model.
Description
Technical Field
The invention relates to the technical field of demand engineering, in particular to a demand simulation method and system of a complex embedded system based on a time automaton.
Background
Along with the development of embedded technology, embedded systems have been developed from single-chip microcomputers, microcontrollers and systems on chip to networking, and the application of the embedded systems relates to the fields of intelligent home, industrial control, traffic management, aerospace, automobile electronics, rail transit and the like, and has good development prospects. However, its networking, intelligent development has led to a dramatic increase in system complexity and day time.
Simulation is required before such complex embedded system software can be implemented. However, because of the complexity, the simulation model is established by using a lot of manpower and time, and the period is relatively long. Meanwhile, the existing simulation technology generally performs simulation verification in the design stage of the whole system, and if the verification result finds that some places needing to be perfected exist, the required design needs to be changed again, so that more time and cost are required. If the demand simulation verification is carried out in the early demand stage, the defects can be found through the simulation verification in the demand stage, the quality of the demand protocol is ensured, the development period is shortened, and a large amount of cost is saved.
Therefore, how to provide a method for simulating the requirements of a complex embedded system is a technical problem that needs to be solved by those skilled in the art.
Disclosure of Invention
In view of the above, the invention provides a method and a system for simulating the demand of a complex embedded system based on a time automaton, which can automatically generate a time automaton model meeting the demand according to a software demand protocol and combine the time automaton model to obtain a complete system model, thereby realizing automatic generation and property verification of the demand simulation model.
In order to achieve the above object, the present invention provides the following technical solutions:
a demand simulation method of a complex embedded system based on a time automaton comprises the following steps:
predefining an equipment model in a specific field, wherein the equipment model is a time automaton model constructed manually;
generating a combined controller time automaton model based on the combined controller requirements in the software requirement protocol;
generating an atomic controller time automaton model based on the atomic controller requirements and the equipment model in the software requirement protocol;
generating a simulation system statement, and setting a system variable initial value according to simulation requirements;
and executing a property verification stage, writing the property to be verified, and performing property verification by using a time automaton verification tool UPPAAL.
Optionally, generating a time automaton model of the combined controller specifically includes the following steps:
traversing the combined controller requirement of the software requirement protocol to generate an initial state of a combined controller time automaton model;
based on the name of the combined controller required by the combined controller and the relation thereof, generating the state and migration of the combined controller time automaton model;
generating corresponding synchronous signals in migration based on the combined controller names required by the combined controllers;
generating invariance in a corresponding migration starting node and guard conditions in migration based on time constraint on the combined controller in the combined controller demand;
based on the call relationship between the combined controller demand and other demands, states and transitions and their synchronization signals are established to handle the calls made by other combined controllers.
Optionally, generating an atomic controller time automaton model specifically includes the following steps:
traversing the atomic controller requirement of the software requirement protocol to generate an initial state of an atomic controller time automaton model;
establishing a state based on the equipment name related to the atomic controller requirement and the calling signal of the equipment, and establishing migration and synchronization signals according to the calling signal sequence;
establishing a shared variable based on data storage related to the atomic controller demand and operation on equipment;
generating invariance in a corresponding migration starting node and guard conditions in migration based on time constraint on an atomic controller in the atomic controller demand;
based on the relationship of atomic controller requirements and combined controller requirements, states and transitions and their synchronization signals are established to handle the invocation of the combined controller.
Optionally, generating the simulation system statement specifically includes the following steps:
generating a model statement, wherein the model statement comprises a combined controller, an atomic controller and a device model;
generating a variable declaration, wherein the variable declaration comprises a combination controller, an atomic controller, equipment and a data storage variable;
initial values are set for the various variables declared.
Optionally, the property types to be verified and the verifiable properties of upaal specifically include:
system behavior consistency: the software behavior and the device behavior are combined without deadlock, and the specific properties are described as follows: e </SUB > non-deadlock;
system demand satisfaction: under the current software behavior, whether the system requirement is met or not, wherein the system requirement is expressed as whether the observable device state is a specific state Y or not after the event e occurs, and the state X after the event e occurs and the expected device state Y are described, namely X < - > Y, when specific use property is verified;
time constraint satisfaction: for complex embedded systems with time constraints, it is verified whether the corresponding operation is completed within a specified time.
Optionally, the verification of the satisfaction of the time constraint specifically includes the following three main types:
1) Detecting at a specific time t 0 Enter state X: a is that<>X imply t＝＝t 0 ；
2) The task T is a periodic task, the period is p, the clock T is assumed to specially record the task execution time, and whether the task T meets the period is detected: a </SUB > T.init real t= p; wherein t.init represents a node in the state of T-time automaton model init;
3) Detecting whether the time interval maintained in the state X is in [ t ] 1 ,t 2 ]：A<>X imply t>＝t 1 &&t<＝t 2 。
A demand simulation system for a complex embedded system based on a temporal automaton, comprising: the system comprises a device predefined module, a combined controller generation module, an atomic controller generation module, a system statement generation module and a writing property verification module;
the device predefining module is used for establishing a time automaton model for the devices in the specific field by the user;
the combined controller generation module is used for establishing a corresponding combined controller time automaton model based on combined controller requirements in a software requirement protocol;
the atomic controller generation module is used for establishing a corresponding atomic controller time automaton model based on the atomic controller demands and the equipment model in the software demand protocol;
a system declaration generation module for generating model declarations for the generated combination controller and atomic controller and generating various related channel and data variable declarations, and setting initial values for the variables at the same time;
and the writing property verification module is used for writing three types of properties according to defined writing property rules and verifying through the UPPAAL platform.
Compared with the prior art, the invention provides the demand simulation method and the demand simulation system for the complex embedded system based on the time automaton, which are characterized in that the generated combined controller time automaton model, the atomic controller time automaton model and the equipment model are combined to obtain a complete system model, the process of automatically generating the simulation model can be realized, and then the property verification is realized by calling UPPAAL software to verify the property of the demand simulation model.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present invention, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of a demand simulation method of a complex embedded system based on a time automaton provided by the invention;
FIG. 2 is a schematic diagram of a model structure of a time automaton corresponding to a basic structure of atomic controller requirements;
fig. 3 (a) -3 (c) are schematic diagrams of a gyro device model, a sun sensor device model and a thruster device model provided by the invention respectively;
fig. 4 (a) -4 (d) are schematic diagrams of an equipment statement, an integrated combination controller requirement, a data acquisition combination controller requirement and a gyro data acquisition atomic controller requirement of a software requirement specification of the solar search system provided by the present invention;
FIG. 5 is a diagram of an integrated combined controller model of a generated solar search system provided by the present invention;
FIG. 6 is a data acquisition combination controller model of the generated solar search system provided by the present invention;
FIG. 7 is a top data collection atomic controller model of the generated solar search system provided by the invention;
8 (a) and 8 (b) are respectively screenshot of variable declaration and model declaration of the solar search system provided by the invention;
fig. 9 is a screenshot of a solar search system case using a UPPAAL platform provided by the present invention for property verification;
fig. 10 (a) -10 (c) are respectively a software requirement protocol consistency verification result, a system requirement satisfiability verification result and a time constraint satisfiability verification result of the solar search system provided by the invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The embodiment of the invention discloses a demand simulation method of a complex embedded system based on a time automaton, which is shown in fig. 1 and comprises the following steps:
1. and predefining a device model in a specific field, wherein the device model is a manually constructed time automaton model.
Specifically, the device model is generally classified into two types, a sensor and an actuator.
The sensor is generally used to periodically detect the property of an external environment variable, and is driven by an event, and is generally represented by that the sensor receives a certain signal and then detects the property value of some variable in the external environment to update, and the sensor is generally in an on-off working state. When the time automaton is built for the sensor type device, the switch state of the sensor is considered, the initial state is named as Off, one state is named as On, migration from Off to On and from On to Off is built, and a synchronous signal is added in the corresponding migration constraint. For the need to detect external environment variables, then self-migration is established On the On state and corresponding synchronization signals are added in the migration constraints. In the process of modeling the time automaton, the environment variable is set as a global shared variable, so that the sensor only represents the process of detecting the external environment variable without actually transmitting data when receiving a signal to detect the external environment variable, and the data transmission is realized through the shared variable.
The actuator is also event driven, and performs a corresponding action by receiving a control signal. The actuator usually has definite working states such as on and off, when the device time automaton model of the actuator type is built, the working states are directly mapped to the state of the time automaton model, corresponding state migration is built, and a synchronous signal is added in migration constraint to receive a control signal. Meanwhile, the response time of the actuator may exist in the process of receiving the control signal and converting the control signal into other working states, a state can be added between different working states, the state is entered after the control signal is received, time delay is represented by adding time invariance to the state, and then corresponding guard conditions are added on the transition from the state to the expected state, so that the response time of the actuator is realized.
2. Based on the combined controller demand in the software demand protocol, generating a combined controller time automaton model, which specifically comprises the following steps:
traversing the combined controller requirement of the software requirement protocol to generate an initial state of a combined controller time automaton model; based on the name of the combined controller required by the combined controller and the relation thereof, generating the state and migration of the combined controller time automaton model; generating corresponding synchronous signals in migration based on the combined controller names required by the combined controllers; generating invariance in a corresponding migration starting node and guard conditions in migration based on time constraint on the combined controller in the combined controller demand; based on the call relationship between the combined controller demand and other demands, states and transitions and their synchronization signals are established to handle the calls made by other combined controllers.
In particular, regarding the format of the software requirements specification. The software requirement specification is a structured representation whose components mainly include problem domain declarations, combined controller requirements, and atomic controller requirements. The problem domain declaration is a description of shared devices and data storage, and fig. 4 (a) is a declaration of the problem domain of the sun search system.
The combined controllers are classified into a combined controller having no called demand (e.g., fig. 4 (b)) and a combined controller having a called demand (e.g., fig. 4 (c)), which is also called an integrated combined controller. The combination controller describes the combination relation of atomic controllers or some combination controllers and mainly comprises a sequence structure, a circulation structure, a branch structure and a parallel structure; at the same time, a grammar specification for the time constraint is also defined.
Various structures of software behavior interaction, such as a sequential structure, a cyclic structure, a branch structure and a parallel structure, are defined in the atomic controller; at the same time, a time constrained grammar specification is defined, as shown in fig. 2. Sequential structure pass "; "split, b represents a behavioral interaction, which is typically in the format of" Controlname sends/receives instruction/data to anotherControlname/Device "and the sequential structure is that the behavioral interactions are performed sequentially. The branch structure is embodied as 'if (b 1 constraint) { … } else if (b 2 constraint) { … } …', and b1constraint and b2 constraint are constraint conditions of the branch execution related interaction respectively, and meanwhile, the branch structure may have a plurality of branches, and a missing branch is automatically generated according to the constraint conditions when a model is generated. The loop structure is embodied as "while (b related) { … }, b related being a constraint on loop execution, typically a constraint on the clock of a certain behavioral interaction b. For the parallel structure, the symbol "||" indicates that no additional processing is required for the parallel structure because the models are parallel in the automaton model. There are two structures of time constraint structure, wherein: "b1; after (T); b2 "represents a time delay, and the behavior interaction b2 is executed again after the execution of the behavior interaction b1 is stopped for a time T; "at (T) { b }" means that the behavioral interaction b is triggered at time T.
Next, how to generate the combined controller temporal automaton model is explained. The combined controller implements the function by invoking other combined controllers or atomic controllers. Thus, it is investigated from the call relations how to get its state and migration from the software requirements specification. Before this, an initial state, named "Init", was added for each combined controller temporal automaton model.
Next, the calling relationship is converted into a state and migration of the temporal automaton. In order to obtain the calling relation between the combined controller and the atomic controller, firstly, traversing the software requirement protocol in breadth first to obtain the calling relation of a tree structure. Then determine if the combined controller is called by other combined controllers, if so, add a new state "received", establish a migration from "Init" to "received", add a synchronization signal "controlnamins" named for the combined controller in migration constraints? ". And at the end of generating the combined controller a transition back to "Init" needs to be added, adding the synchronization signal "controlnamins-! "means that the combination controller issues a completion signal.
The relation expression between other controllers called by the combined controller is different, and the method for converting the combined controller into the time automaton model is also different, which is specifically as follows:
for parallel structures, no additional processing is done since the model itself is in parallel state.
For sequential structure, a new state is added first, named the state "Controlname" with the combined controller name to be invoked, then the migration from the previous state to that state is added, as well as the synchronization signal "Controlname in the migration constraint-! ". Then a new state "ControlnameF" is added, migration from "Controlname" to "ControlnameF" is established, and the synchronization signal on the migration constraint is "ControlnameFIns? ".
For a branch structure, the branch start state is marked first, then for each branch a migration is established from that state, and guard conditions generated from the branch conditions are added to the migration. And generating a corresponding model structure for the interactive content in the branch according to the structure type. After all branches are processed, whether all branches cover all possible situations needs to be judged, and if not, a new branch needs to be generated for processing other conditions. Finally, a new state end is added to represent the end state of the branch structure, and the transition from the last state of each branch to the state end is established.
For the loop structure, marking the loop starting state, then generating a corresponding model structure for the interactive content in the loop structure according to the structure, and finally adding the migration returning to the loop starting state, and adding the guard condition generated according to the loop condition on the migration constraint.
For the after (T) time constraint, add invariance "T < =t" at the current state, add update constraint "t=0" at the transition into the current state, add guard constraint "T > =t" at the transition out of the current state, T is the clock variable of the current model.
For the at (T) { b } time constraint, when processing the interactive content b, a guard condition "t= =t" is added to the transition into this state, and T is the clock variable of the current model.
3. Based on the atomic controller demand and the equipment model in the software demand protocol, generating an atomic controller time automaton model, which specifically comprises the following steps:
traversing the atomic controller requirement of the software requirement protocol to generate an initial state of an atomic controller time automaton model; establishing a state based on the equipment name related to the atomic controller requirement and the calling signal of the equipment, and establishing migration and synchronization signals according to the calling signal sequence; establishing a shared variable based on data storage related to the atomic controller demand and operation on equipment; generating invariance in a corresponding migration starting node and guard conditions in migration based on time constraint on an atomic controller in the atomic controller demand; based on the relationship of atomic controller requirements and combined controller requirements, states and transitions and their synchronization signals are established to handle the invocation of the combined controller.
Specifically, an atomic controller model is generated based on atomic controller requirements in a software requirements specification. The atomic controller is invoked or not invoked by the combined controller to run in parallel with other controllers.
Generating an atomic controller, firstly adding an initial state 'Init', then judging whether the atomic controller is called, adding a new state 'received' if the atomic controller is called, establishing migration from the state 'Init' to the state 'received', and adding a synchronous signal 'atoControl namins' named by the name of the atomic controller on the migration? ". Also, at the end of generating an atomic controller, it is necessary to establish a transition back to state "Init" and add a synchronization signal "AtoControlnameFIns-! ", indicates the atomic controller complete signal.
The behavioral interaction component based on atomic controller requirements is then converted to states and transitions in the atomic controller temporal automaton model. According to fig. 2, various structures in the behavioral interactions of the atomic controller are converted into states and transitions in the temporal automaton model, similar to the method of converting into model states and transitions according to call relations in generating the combined controller model, except that for the processing of interactions, the call relations of the combined controller are only implemented by synchronization signals, the behavioral interactions of the atomic controller include interactions with device models of various domain types, and there are different processes for different domain types.
For the data storage field, which is designed to store various data, in the temporal automaton model, data communication is achieved by sharing variables, so that the processing in the temporal automaton model in the data storage field represents data storage or data acquisition by setting values of some variables, for example, setting the variable "pulsecountStoIns=1", that is, representing that the variable "Pulsecount" is stored in the gyro data storage field.
For the device domain, there are different treatments according to the interaction category, if the interaction category is event, a synchronization signal needs to be added on migration, and the synchronization signal is added as content Ins according to the interaction is "send" or "receive" -! "or" content (b) Ins? ". If the interaction category is "value" or "state", an update constraint "content (b) =1" is added to the migration.
The atomic controller behavior cross-conversion relationships are shown in table 1.
TABLE 1 atomic controller behavior interaction transformation relationship table
4. Generating simulation system declarations, traversing a temporal automaton network combined by the generated combined controller and atomic controller model, generating variable declarations of various types, and adding model declarations.
Generating a system statement includes the steps of:
(1) A variable declaration is generated.
Various migration constraints involved in generating the combined controller and atomic controller model, as well as data variables involved in various behavioral interactions, all need to be declared.
As shown in table 2, the variable types corresponding to the various types in the system declaration are given.
Table 2 generation of system declaration corresponding variable types
For data storage, the numerical value of a variable is used to mark whether data is stored or loaded, so that the declared data is of the "int" type.
For the device, the type of the declaration variable is determined according to the behavior interaction type. For the "event" type, communication is performed by a synchronization signal, and thus it is necessary to assert a communication channel, i.e., to be of the "chan" type. For the "value" and "status" types, there are actual values, and therefore are declared as "int" types.
(2) Model declarations of the respective time automata in the whole system are generated.
In order for the models to function properly, each model needs to be declared in the system model, so the name of each model is added to the model declaration in the system declaration.
(3) And setting an initial value of a system variable.
In order for the model to operate properly to obtain simulation results, it is often necessary to set initial values for variables in the system. The initial value of the system variable is set, and the initial value of the system variable is required to be set to 0 mainly aiming at the data variable of the type "int", for example, the variable which is used for interactively marking the data storage and loading with the data storage field, and for some data needing to be calculated, some initial values are required to be set so as to make the simulation result meaningful.
5. And executing a property verification stage, writing the property to be verified according to writing methods of different types of properties, and performing property verification by using a time automaton verification tool UPPAAL.
Verifying the property after generating the demand simulation model, and classifying the property into three types for verification:
(1) And (3) verifying system behavior consistency: e </non-deadlock, verifying whether the system has a simulation path which will not cause deadlock.
(2) System demand satisfiability verification: the requirements of the high layers of the system are verified whether the requirements are met, and the general property writing method is X < - > Y, namely whether the writing is completed or is in the corresponding state Y when the writing is in the X state.
(3) Time constraint satisfaction verification: for some complex embedded systems with time constraint, it can be verified whether the corresponding operation is completed within a specified time, and the main types are also classified into three types:
1) Detecting at a specific time t 0 Enter state X: a is that<>X imply t＝＝t 0 ；
2) The task T is a periodic task, the period is p, the clock T is assumed to specially record the task execution time, and whether the task T meets the period is detected: a </SUB > T.init real t= p, wherein T.init refers to a node in the state of T-time automaton model init;
3) Whether the time interval maintained in state X is at [ t ] 1 ,t 2 ]：A<>X imply t>＝t 1 &&t<＝t 2 。
These expressions are placed into the UPPAAL verifier for verification.
To describe this technical solution in further detail, a description is given below with respect to a specific example of a solar search system.
1. A domain-specific device model is predefined.
For solar search systems, the devices involved include gyroscopes, sun sensors, and thrusters. Modeling these devices makes it clear first of all whether the device is a sensor or an actuator. The gyroscope and the sun sensor are sensors, and the thruster is an actuator. FIG. 3 (a) shows a time automaton model of a gyroscopic device, where the gyroscopes interact with the controller via channels "Gyropower on signal" and "Gyropower off signal" to switch the operating states of the switches; the detected external environment attributes "Pulsecount" and "Gyropowerstate" are updated through channels "PulsecountacqIns" and "gyropowerstateins". FIG. 3 (b) shows a time automaton model of a sun sensor interacting with a controller via channels "Sunsensiorpowersignal" and "Sunsensiorpowofignal" to switch the operating state of the switch; the detected external environment variables "provisiblesig n", "provimeasurementangle" and "provinsorpowerstate" are updated through channels "provisos busgesamaccqins", "provimeasurementangqins" and "provinsorpowerstate". Fig. 3 (c) shows a time automaton model of the thruster, which communicates with the controller via channels "poweronsignal" and "poweroffignal", switching the operating state of the switch; the detected external environment variables 'JetInterval' and 'Thresputerpowerstate' are updated through channels 'JetInterval acqIns' and 'ThresputerpowerstateIns'; the satellite attitude is adjusted by receiving the thruster control signal through the channel 'triaxialcontrol signal'.
2. Based on the combined controller requirements in the software requirements specification, a combined controller model is generated.
And generating a time automaton model of the combined controller according to the software requirement specification of the combined controller. There are 7 combined controllers in total in the sun search control system. Fig. 4 (b) and 4 (c) show the integrated combined controller requirements and the data acquisition combined controller requirements, respectively, in the solar search system software requirements specification.
The integrated combined controller software requirements specification in the solar search system presented in fig. 4 (b) is not invoked by other combined controllers. The resulting combined controller temporal automaton model is shown in fig. 5. No state is added to receive the scheduling synchronization signal since it is not invoked by other controllers. Then, the interactive content of the calling controller is processed, firstly, the Initialization is called, the new state Initialization is added to establish the migration from the initial state to the state and the called synchronization signal Initialization Ins-! "a loop structure" while (160 ms) "follows according to the requirement specifications, and the initialization is called only once, so the migration and synchronization signal" initialization FINs "is added back to the initial state? "receive initialization complete signal". For the cyclic structure, according to the temporal automaton model structure corresponding to the cyclic structure shown in fig. 2, a cyclic start state start, that is, an initial state "MasterController", is recorded first, then interaction behavior in the cyclic structure is processed, and as a sequential structure, according to the temporal automaton model structure corresponding to the sequential structure in fig. 2, states and migration are added according to the name of the called controller. First, "Telecontrol Instruction Processing 2", then add the state named it, and add the transition from the loop start state "MasterController" to this state, and add the synchronization signal "Telecontrol InstructionProcessIns-! "then add a state" Telecontrol InstructionProcessF "for receiving a call to the controller done signal, then establish a transition to that state and a synchronization signal" Telecontrol InstructionProcessFIns? ", the same is done for the subsequent call controller requirements. The last called controller in the processed loop structure, i.e. the end state is reached, adds a migration back to the initial state, and adds the related constraint "b related" on the migration, where the guard condition "t= 160" needs to be added. And according to the comprehensive combined controller requirement in the solar search system, the generated combined controller model is finally obtained if no interaction part exists.
The data acquisition combination controller given in fig. 4 (c) is invoked by the controller. First an initial state is added, a new state "Receive" is added as invoked by the other combined controllers, a transition from the initial state to the state is established, and a synchronization signal "dataacquisition ins? "means receiving a scheduling signal. The corresponding temporal automaton model structure is then built according to the processing of the sequential structure shown in fig. 2. Finally, the transition back to the initial state is added, and the synchronization signal DataAcquisitionFIns is added-! "indicates that data acquisition is completed and transmission is completed, and the generated combined controller model is shown in fig. 6.
3. An atomic controller model is generated based on the atomic controller requirements and the device model in the software requirements specification.
There are 19 atomic controller models in the solar search system. Taking a gyro data acquisition atomic controller as an example, the software requirement protocol is shown in fig. 4 (d). First add an initial state, the atomic controller is called by the data acquisition combination controller, add a new state "Receive", establish a transition from the initial state to the state, and add a synchronization signal "gyrodataacrobations? "receive call signal". The interactive section is then processed according to the sequential structure shown in fig. 2. And for the interaction part, carrying out corresponding processing on different interaction field types. According to the software requirement protocol, firstly, interacting with a gyroscopic device model (G), wherein the action interaction type is event, then according to the processing of the action interaction about the device event type in the table 1, firstly adding a state, and establishing migration, wherein the interaction information is 'send', then adding a synchronous signal 'pulsecount acquisition structure' on migration! ". Next, a behavioral interaction with the gyroscopic data store (GD) is performed, and the interaction type is event, then according to the behavioral interaction process about the event type of the data store in table 1, a new state is added and migration is established, and an update constraint "angular dynamics database transaction=1" is added on the migration. And sequentially processing all behavior interactions, finally establishing migration back to the initial state, and adding a synchronous signal of Gyro DataAcquisitionFIns-! "indicates that the gyro data collection is completed and the transmission is completed. The finally generated gyro data acquisition atomic controller model is shown in fig. 7.
4. Generating a simulation system statement and setting a variable initial value.
The system declarations include various variable declarations and model declarations. Variable declarations include various synchronization signal declarations as "chan" types, data variable declarations as "int", "double" types, etc., and clock signal declarations as "clock" types. For the variable declaration, the variable declaration is generated according to the action interaction type and interaction field in the process of generating the combined controller and the atomic controller, and according to the table 2, whether the data is stored or loaded is marked by using the numerical value of the variable for the data storage field, so the variable declaration is declared as 'int' type, the variable declaration is generated according to the action interaction type, if the communication channel is required to be declared for the event type, the variable declaration is declared as 'chan' type, if the communication channel is required to be declared as the value/state type, the variable declaration is declared as 'int' type, for example, the variable declaration is declared as 'chan Pulsecountacquisitioninstruction' in the gyroscopic data collection atomic controller, the action interaction with gyroscopic data storage GD is required, and the interaction type is event, the variable declaration is declared as 'int Angularvelocityanalogstorageinstruction'. Other similar, the final generated variable declaration is shown in FIG. 8 (a).
For the model declaration section, a corresponding model declaration needs to be added for all the temporal automaton models, in which a declaration needs to be made for the combined controller and the atomic controller, the model declarations are named by controller names, as shown in fig. 8 (b) in particular.
The initial value of the system variable is set, and the initial value is not set for the synchronous signal type variable, but some data variables need to be initialized, so that the simulation result is meaningful. For variables having practical significance such as pulse count (pulse), angular velocity analog (angular velocity analog), etc., initial values need to be given so that the simulation result is significant, and these initial values can be set according to the experience of the field expert. For a variable in the model for marking whether data is stored or loaded, its initial value needs to be set to 0 for initializing the simulation, for example, a variable "angular velocity analog data storage" for marking angular velocity analog data storage needs to be assigned its initial value to 0. The variable initial value portion is set as shown in fig. 8 (a).
5. And executing a property verification stage, writing the property to be verified according to writing methods of different types of properties, and performing property verification by using a time automaton verification tool UPPAAL.
1) And (3) consistency verification: e </non-deadlock, verify whether the system has the emulation route that will not happen to deadlock, verify the result is shown in figure 10 (a).
2) And (3) verifying system requirements: and verifying whether the requirements of a high layer of the system are met, wherein the property writing method is X < - > Y, namely, whether the corresponding operation is finished to verify through the verification variable value when the time automaton is in an X state or whether the corresponding operated time automaton is in a corresponding state. Taking mastercontroller.dataacq— pulsecountstorage= 1 as an example, it means that the corresponding data acquisition is completed and stored when the combination controller is in the data acquisition state, and the verification result about the system requirement is shown in fig. 10 (b).
3) And (3) time constraint verification: for some complex embedded systems with time constraints, it may be verified whether the corresponding operation is completed within a specified time, taking the example that the thruster needs to output at 128ms, the property a </threshold.
The property is written, verified by using the UPPAAL platform, as shown in figure 9, the property is verified by clicking the 'Add' button, then inputting the written property in the 'property to be verified' input box, and then clicking the 'begin verification' button. The properties to be verified can be added and deleted by "add" and "delete" buttons. Each property is followed by a gray dot, gray representing that no verification has been performed, green representing that the property is verified, and red representing that the property is not verified.
According to three types of property writing methods, properties are written, and then a UPPAAL platform verifier is used to verify the properties of the whole system, and the results are shown in FIG. 10 (a) -FIG. 10 (c).
Corresponding to the method shown in fig. 1, the embodiment of the present invention further provides a demand simulation system of a complex embedded system based on a time automaton, which is used for implementing the method in fig. 1, where the demand simulation system of the complex embedded system based on the time automaton provided by the embodiment of the present invention may be applied to a computer terminal or various mobile devices, and specifically includes: the system comprises a device predefined module, a combined controller generation module, an atomic controller generation module, a system statement generation module and a writing property verification module;
the device predefining module is used for establishing a time automaton model for the devices in the specific field by the user;
the combined controller generation module is used for establishing a corresponding combined controller time automaton model based on combined controller requirements in a software requirement protocol;
the atomic controller generation module is used for establishing a corresponding atomic controller time automaton model based on the atomic controller demands and the equipment model in the software demand protocol;
a system declaration generation module for generating model declarations for the generated combination controller and atomic controller and generating various related channel and data variable declarations, and setting initial values for the variables at the same time;
and the writing property verification module is used for writing three types of properties according to defined writing property rules and verifying through the UPPAAL platform.
According to the embodiment, the generated combined controller time automaton model, the atomic controller time automaton model and the equipment model are combined to obtain a complete system model, the process of automatically generating the simulation model can be realized, and then the property verification is carried out by calling UPPAAL software by writing properties, so that the property verification of the demand simulation model is realized.
In the present specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, and identical and similar parts between the embodiments are all enough to refer 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 points refer to the description of the method section.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (7)
1. A demand simulation method of a complex embedded system based on a time automaton is characterized by comprising the following steps:
predefining an equipment model in a specific field, wherein the equipment model is a time automaton model constructed manually;
generating a combined controller time automaton model based on the combined controller requirements in the software requirement protocol;
generating an atomic controller time automaton model based on the atomic controller requirements and the equipment model in the software requirement protocol;
generating a simulation system statement, and setting a system variable initial value according to simulation requirements;
and executing a property verification stage, writing the property to be verified, and performing property verification by using a time automaton verification tool UPPAAL.
2. The method for simulating the demand of a complex embedded system based on a time automaton according to claim 1, wherein the method for generating the time automaton model of the combined controller specifically comprises the following steps:
traversing the combined controller requirement of the software requirement protocol to generate an initial state of a combined controller time automaton model;
based on the name of the combined controller required by the combined controller and the relation thereof, generating the state and migration of the combined controller time automaton model;
generating corresponding synchronous signals in migration based on the combined controller names required by the combined controllers;
generating invariance in a corresponding migration starting node and guard conditions in migration based on time constraint on the combined controller in the combined controller demand;
based on the call relationship between the combined controller demand and other demands, states and transitions and their synchronization signals are established to handle the calls made by other combined controllers.
3. The method for simulating the demand of a complex embedded system based on a time automaton according to claim 1, wherein the method for generating the atomic controller time automaton model specifically comprises the following steps:
traversing the atomic controller requirement of the software requirement protocol to generate an initial state of an atomic controller time automaton model;
establishing a state based on the equipment name related to the atomic controller requirement and the calling signal of the equipment, and establishing migration and synchronization signals according to the calling signal sequence;
establishing a shared variable based on data storage related to the atomic controller demand and operation on equipment;
generating invariance in a corresponding migration starting node and guard conditions in migration based on time constraint on an atomic controller in the atomic controller demand;
based on the relationship of atomic controller requirements and combined controller requirements, states and transitions and their synchronization signals are established to handle the invocation of the combined controller.
4. The method for simulating the demand of a complex embedded system based on a time automaton according to claim 1, wherein the generation of the simulation system statement comprises the following steps:
generating a model statement, wherein the model statement comprises a combined controller, an atomic controller and a device model;
generating a variable declaration, wherein the variable declaration comprises a combination controller, an atomic controller, equipment and a data storage variable;
initial values are set for the various variables declared.
5. The method for simulating the demand of a complex embedded system based on a time automaton according to claim 1, wherein the property types to be verified and the verifiable properties of upaal specifically include:
system behavior consistency: the software behavior and the device behavior are combined without deadlock, and the specific properties are described as follows: e </SUB > non-deadlock;
system demand satisfaction: under the current software behavior, whether the system requirement is met or not, wherein the system requirement is expressed as whether the observable device state is a specific state Y or not after the event e occurs, and the state X after the event e occurs and the expected device state Y are described, namely X < - > Y, when specific use property is verified;
time constraint satisfaction: for complex embedded systems with time constraints, it is verified whether the corresponding operation is completed within a specified time.
6. The method for simulating the demand of a complex embedded system based on a time automaton according to claim 5, wherein the verification of the satisfaction of the time constraint comprises the following three main types:
1) Detecting at a specific time t 0 Enter state X: a is that<>X imply t＝＝t 0 ；
2) The task T is a periodic task, the period is p, the clock T is assumed to specially record the task execution time, and whether the task T meets the period is detected: a </SUB > T.init real t= p; wherein t.init represents a node in the state of T-time automaton model init;
3) Detecting whether the time interval maintained in the state X is in [ t ] 1 ,t 2 ]：A<>X imply t>＝t 1 &&t<＝t 2 。
7. A demand simulation system for a complex embedded system based on a temporal automaton, comprising: the system comprises a device predefined module, a combined controller generation module, an atomic controller generation module, a system statement generation module and a writing property verification module;
the device predefining module is used for establishing a time automaton model for the devices in the specific field by a user;
the combined controller generating module is used for establishing a corresponding combined controller time automaton model based on the combined controller requirements in the software requirement protocol;
the atomic controller generating module is used for establishing a corresponding atomic controller time automaton model based on the atomic controller demands and the equipment model in the software demand protocol;
the system statement generating module is used for generating model statement and various related channel and data variable statement for the generated combined controller and atomic controller, and setting initial value for the variable at the same time;
the writing property verification module is used for writing three types of properties according to defined writing property rules and verifying the three types of properties through the UPPAAL platform.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311259417.5A CN117313369A (en) | 2023-09-27 | 2023-09-27 | Demand simulation method and system for complex embedded system based on time automaton |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311259417.5A CN117313369A (en) | 2023-09-27 | 2023-09-27 | Demand simulation method and system for complex embedded system based on time automaton |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117313369A true CN117313369A (en) | 2023-12-29 |
Family
ID=89242052
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311259417.5A Pending CN117313369A (en) | 2023-09-27 | 2023-09-27 | Demand simulation method and system for complex embedded system based on time automaton |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117313369A (en) |
-
2023
- 2023-09-27 CN CN202311259417.5A patent/CN117313369A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Hemingway et al. | Rapid synthesis of high-level architecture-based heterogeneous simulation: a model-based integration approach | |
| US7979248B2 (en) | Model independent simulation | |
| CN103513992A (en) | Universal development platform for education and entertainment robot application software | |
| CN106021816B (en) | A kind of implementation method of the distributed system behavior simulation analysis tool of Behavior-based control tree | |
| CN112130534B (en) | Processing method and controller for constructing workshop digital twin body | |
| CN113836754A (en) | Multi-agent simulation modeling oriented simulation method, device, equipment and medium | |
| Komma et al. | An approach for agent modeling in manufacturing on JADE™ reactive architecture | |
| CN108460199A (en) | CNI modelings | |
| CN109739740A (en) | A kind of AADL model combination formalization verification method | |
| Hussain et al. | UML-based development process for IEC 61499 with automatic test-case generation | |
| CN111274142A (en) | Software communication system architecture conformance test modeling method based on extended finite-state machine | |
| Abdoul et al. | AADL execution semantics transformation for formal verification | |
| CN111399829B (en) | Waveform modeling method and terminal based on model driving | |
| CN114911715B (en) | Formalized test model modeling method, system, computer and storage medium | |
| CN117313369A (en) | Demand simulation method and system for complex embedded system based on time automaton | |
| CN111694637B (en) | Online full-automatic multi-agent control simulation compiling system | |
| CN114357672A (en) | Simulation verification method of model-based avionics system | |
| CN104660697B (en) | Based on Kepler scientific workflow Sensor Network service combining methods | |
| Hamri et al. | On using design patterns for DEVS modeling and simulation tools | |
| Santa et al. | Relations of UML and OETPN Models | |
| CN112817571B (en) | Man-machine object fusion application modeling method based on scene storyboard | |
| Mariño et al. | Using LOTOS in the specification of industrial bus communication protocols | |
| CN115687167B (en) | Formal verification method and device for group intelligent operating system | |
| CN117055869B (en) | Discrete event simulation graphical modeling method based on abacus | |
| Aybek et al. | From the Synchronous Data Flow Model of Computation to an Automotive Component Model |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |