CN112733323B - Robosim model real-time system-oriented model detection method - Google Patents

Abstract

The invention discloses a model detection method facing a Robosim model real-time system, which is characterized in that a conversion rule is predefined, the Robosim model is converted into a time automaton network model which can be identified by UPPAAL, corresponding TCTL properties are automatically generated, and a model detection tool UPPAAL is used for simulating, verifying and analyzing a robot simulation model. Compared with the prior art, the method has high verification efficiency, is suitable for modeling and verifying the physical platform and environment of the robot, supports the conversion of the Robosim model into the time automaton network model, and provides an effective method for formally verifying the Robosim robot simulation model.

Description

Robosim model real-time system-oriented model detection method

Technical Field

The invention relates to the technical field of detection of robot simulation models, in particular to a model detection method for a Robosim model real-time system.

Background

At present, the application of the robot system is increasingly wide, and a plurality of potential safety hazards faced by the robot system are gradually valued by people. The robot System is a typical Cyber-Physical System (CPS), and combines a robot platform with a Physical environment to realize the interaction between a computer and the real world. Because the development of the robot system is complex and the cost for inputting the real environment for simulation is high, the simulation modeling of the system is usually needed in the initial development stage of the system, so that the system can be simulated and operated on simulation software, and the development cost is reduced.

Robosilm is a simulation modeling language for a robot system, and is a graphical language independent of tools like UML, and mainly performs simulation modeling on control logic of the robot system. The robosi model introduces the concept of execution cycles to simulate the cycle-consuming time of register read-write and intermediate operations in a robotic system. In addition, RoboSim defines its formalized semantics using a temporal version of the Communication Sequential Process (CSP), the dock-CSP.

UPPAAL is a model detection tool for modeling and verifying a real-time system, and models a system model needing verification by using a time Automata Network (NTA), and describes a property specification required to be met by the system model by using Time Computing Tree Logic (TCTL).

However, the rock-CSP semantics of robosi is inefficient at validating time-dependent properties and is not suitable for modeling and validating the physical platform and environment of a robotic system.

Disclosure of Invention

The invention aims to provide a Robosim model-oriented real-time system model detection method, which adopts a model conversion technology based on a template and a conversion rule to convert a Robosim model into a time automaton network model and automatically generate basic TCTL properties so as to use a model detection tool UPPAAL to simulate, verify and analyze a robot simulation model, and provides a feasible and effective solution for verifying the simulation model Robosim of a robot by using a verification tool UPPAAL of a real-time system.

The specific technical scheme for realizing the invention is as follows: a model detection method for a Robosim model real-time system is characterized in that a model conversion technology is adopted, a Robosim model is converted into a time automaton network model, basic TCTL properties are automatically generated, and a robot simulation model is simulated, verified and analyzed by using a model detection tool UPPAAL, and the method specifically comprises the following steps:

s1: a RoboSim robot simulation model was designed using a RoboSim model editor.

S2: and extracting the execution period and context content of the module, the controller and the state machine in the Robosim model, filling the execution period and the context content into a model template of the time automaton, and generating the time automaton model.

S3: and extracting the migration relation of the state machine diagram from the Robosim model, adding a conversion rule, and generating a time automaton model.

S4: TCTL properties were generated automatically according to the robosi model.

S5: combining all the temporal automata models generated in step S2 and step S3 into a temporal automata network model, and generating an XML result file that can be recognized by uppal in combination with the TCTL properties generated in step S4.

S6: and opening the result file by using a UPPAAL tool, and performing simulation, verification and analysis.

The template of the time automaton model specifically comprises:

s2-1: aiming at a time automaton model template of a module in a Robosim model;

s2-2: aiming at a time automaton model template of a controller in a Robosim model;

s2-3: a time automaton model template for a state machine in a RoboSim model.

The conversion rule specifically includes:

s3-1: converting a Node in a Robosim state machine into a modeling element in a time automaton model, wherein the Node comprises a connection junction, an initial connection junction, a simple state, a termination state, a state with internal actions and a composite state;

s3-2: the transformation from migrating transitions in a RoboSim state machine to modeling elements in a time automaton model includes: normal migration and migration with exec triggers;

s3-3: the conversion of the context in the robosi state machine to the modeling element in the temporal automaton includes: local variables (including constants), operations, events, and global interfaces, wherein the global interfaces include: global variables (including constants), operations, and events;

s3-4: the conversion of statements and expressions in robosi to modeling elements in a temporal automaton, wherein the statements include: clock reset, call (operations and events) and variable assignment; the expression includes: arithmetic expressions, relational expressions, logical expressions, data expressions, and keywords.

The TCTL properties specifically include:

s4-1: no dead lock A [ ] not dead lock;

s4-2: no output conflict nature;

s4-3: reachability of all states.

The XML result file that can be recognized by UPPAAL is generated by merging multiple time automata models and TCTL properties and adding other necessary tags.

The simulation, verification and analysis specifically comprises:

s6-1: opening the XML file generated in step S5 in the uppal tool;

s6-2: simulating the converted time automaton network model corresponding to the Robosim model by using a simulator in a UPPAAL tool;

s6-3: validating the automatically generated TCTL property in a uppal tool using a validator;

s6-4: adding other TCTL properties to be verified by using a verifier in a UPPAAL tool for verification;

s6-5: the verification model is analyzed in the UPPAAL tool using a verifier, and if the property is not satisfied, a counter-example path can be found in the simulator through the get trace button.

Compared with the prior art, the method has high verification efficiency, is suitable for modeling and verifying the physical platform and environment of the robot, supports the conversion of the Robosim model into the time automaton network model, and provides an effective method for formally verifying the Robosim robot simulation model.

Drawings

FIG. 1 is a block diagram of the architecture of the present invention;

FIG. 2 is a template diagram of a temporal automaton model for a module in a Robosim model and a corresponding template diagram of a local declaration;

FIG. 3 is a template diagram of a temporal automaton model for a controller in the Robosim model and a corresponding template diagram of a local declaration;

FIG. 4 is a template diagram of a time robot model for a state machine in the Robosim model and a corresponding template diagram of a local declaration;

FIG. 5 is a schematic diagram of a part of nodes Node in the Robosim meta-model and a conversion rule from a migration Transition to a modeling element of a time automaton;

FIG. 6 is a schematic diagram of the rules for converting simple states with internal actions to time automata modeling elements in a Robosim meta-model;

FIG. 7 is a diagram of a model of a temporal automaton for During actions;

FIG. 8 is a diagram illustrating the rules for the transformation of Context to a modeling element of a temporal automaton in a Robosim meta-model;

FIG. 9 is a schematic diagram of a conversion rule from a Statement State to a modeling element of a temporal automaton in a Robosim meta model;

FIG. 10 is a schematic diagram of a conversion rule from Expression to a time automaton modeling element in a Robosim meta model;

FIG. 11 is a FootBot model diagram of the Robosim robot simulation model of example 1;

FIG. 12 is a diagram of a CFoot _ cycle of the temporal automaton model in example 1 and a local declaration;

FIG. 13 is a view of a temporal automaton model move _ cycle and a partial declaration in embodiment 1;

FIG. 14 is a diagram of a time automaton model SimsMovement _ cycle and a local declaration in example 1;

FIG. 15 is a diagram of a time automaton model SimsMovement and a partial declaration in example 1.

Detailed Description

Referring to fig. 1, the invention adopts a model conversion technology based on a template and a conversion rule to convert a robosil model into a time automaton network model, automatically generates basic TCTL properties for stipulating property constraints that the robosil model needs to satisfy, and uses a model detection tool uppal to simulate, verify and analyze a robot simulation model, and the specific implementation steps are as follows:

s1: a robot simulation model of RoboSim was created using a RoboSim model editor.

S2: and extracting a periodic mechanism (the periodic mechanism specifically comprises an execution period and context contents) of three types of components (modules, controllers and state machines) from the Robosim model, adding the periodic mechanism into a model template of the time automaton, and generating the time automaton model.

S3: and obtaining a time automaton model corresponding to the state machine in the Robosim model according to the migration relation of the state machine in the Robosim model, the meta model of the Robosim and a predefined conversion rule.

S4: according to the RoboSim model, the corresponding TCTL properties are automatically generated.

S5: and combining all the generated time automata network models into a time automata network model, and generating an XML result file which can be identified by UPPAAL by combining the generated TCTL property.

S6: and opening the result file by using a UPPAAL tool, and performing simulation, verification and analysis.

The step S2 specifically includes:

s2-1: referring to fig. 2, for a time automata template of a robosilm module execution period and a corresponding local declaration template, generating time automata corresponding to all robosilm module execution periods, where the time automata template of the module execution period and the corresponding local declaration template specifically include the following steps:

s2-1-1: the output counter is reset using the Update tag Init () and then data read from the external device is recorded using the Update tag TakeInput ().

S2-1-2: these inputs are immediately passed to all controller execution cycles under the module via the Sync tag register read _ mName _ C (mName is the name of the module, the same below). At the same time, it resets the input from its parent node through Update tag reset ().

S2-1-3: wait for output from the controller execution cycle (passed through the Sync tag register write _ C _ mName), or wait for Sync tag end. When the End signal is received, it will determine the number of terminated state machines, and if all the state machines are terminated, enter the End position to terminate the whole system.

S2-1-4: after receiving the Output from the controller execution cycle, judging whether an Output Conflict exists through a guard tag ifConflict (), if so, deadlock at a position Output _ Conflict, otherwise, transmitting the values to an external device through a Sync tag register write and an Update tag GiveOutput ().

S2-1-5: the time automaton uses a clock variable cycle to enter a new cycle after waiting for period time units. At the same time, the Sync tag wait _ p will signal the end of the cycle to ensure that the time automata of all execution cycles remain synchronized.

S2-1-6: the local declaration template declares a local clock variable cycle and a constant period for representing the number of cycles, as well as Update tag Init (), TakeInput (), reset (), GiveOutput () and Guard tag ifConflict () function functions. The remaining synchronization signals, i.e., the Sync tag described above, are asserted in the global assertion.

S2-2: referring to fig. 3, for the temporal automata template of the RoboSim controller execution period and the corresponding local declaration template, generating the temporal automata corresponding to all RoboSim controller execution periods, where the temporal automata template of the controller execution period and the corresponding local declaration template specifically include the following steps:

s2-2-1: the current cycle begins upon receipt of a register read signal (i.e., Sync tag register read _ mName _ C) sent by a module execution cycle.

S2-2-2: the Update tag TakeInput () is used to record data read from the module execution cycle, the rest of this step is the same as step 2-1-1.

S2-2-3: the input is passed to the time automaton of all state machine execution cycles under the controller via the Sync tag register read _ cName _ S (cName is the name of the controller, the same below), the rest of this step is the same as step 2-1-2.

S2-2-4: waiting for the output from the state machine execution cycle (passed through the Sync tag register write _ cName _ S) or waiting for Sync tag end, the remainder of this step is the same as steps 2-1-3.

S2-2-5: after receiving the Output from the state machine execution cycle, judging whether Output Conflict exists through a guard tag ifConflict (), if so, deadlock at a position Output _ Conflict, otherwise, transmitting the values to the module execution cycle through a Sync tag register write _ C _ mName and an Update tag GiveOutput ().

S2-2-6: the current cycle ends after receiving the signal wait _ p from the module execution cycle.

S2-2-7: the local declaration template declares the function of Update tag Init (), TakeInput (), reset (), GiveOutput (), and Guard tag ifConflict (). The remaining synchronization signals, i.e., the Sync tag described above, are asserted in the global assertion.

S2-3: referring to fig. 4, for the time automata template of the robosilm state machine execution period and the corresponding local declaration template, generating time automata corresponding to all robosilm state machine execution periods, where the time automata template of the state machine execution period and the corresponding local declaration template specifically include the following steps:

s2-3-1: the current cycle starts upon receipt of a register read signal, Sync tag register read _ cName _ S, issued by the controller execution cycle.

S2-3-2: the Update tag TakeInput () is used to record data read from the controller execution cycle, the remainder of this step being the same as step 2-1-1.

S2-3-3: the state machine execution cycle immediately starts the current cycle of the state machine sName with the Sync tag startexec _ sName (sName is the name of the state machine). At the same time, it resets the input from its parent node through Update tag reset ().

S2-3-4: waiting for the output from the state machine (passed through the Sync tag collection _ sName), or waiting for the Sync tag endexec _ sName, which is used to end the current cycle of the state machine sName.

S2-3-5: after receiving the Output from the state machine, judging whether Output Conflict exists through a guard tag ifConflict (), if so, deadlock at a position Output _ Conflict, otherwise, transmitting the values to a controller execution cycle through a Sync tag register write _ S _ cName and an Update tag GiveOutput ().

S2-3-6: wait for the wait _ p signal from the module execution cycle to end the current cycle, or wait for the end signal from the state machine, i.e., the Sync tag end. When the End signal is received, it will determine the number of terminated state machines, and if all the state machines are terminated, enter the End position to terminate the whole system.

S2-3-7: the local declaration template declares the function of Update tag Init (), TakeInput (), reset () and GiveOutput (), and Guard tag ifConflict (). The remaining synchronization signals, i.e., the Sync tag described above, are asserted in the global assertion.

The step S3 specifically includes the following steps:

s3-1: the conversion of a Node in a Robosim state machine to a modeling element in a time automaton, wherein the Node comprises: connection, initial connection, simple state, termination state, state with internal actions (including Entry action, During action, and Exit action), and composite state.

Referring to FIG. 5, some nodes Node in the Robosim meta model and Transition rules for migrating transitions to the modeling elements of the temporal automaton. In which the conversion rules of connection, initial connection, termination state, and simple state without internal actions are shown in fig. 5.

Referring to fig. 6-7, the robosi meta model has time automata modeling elements corresponding to simple states with internal actions. Time automata model for During action. The transition rule for a simple state (assumed name s) with internal actions is shown in fig. 6. Wherein the Entry action is realized by adding a position Entry _ s and an edge; the Exit action is realized by newly adding a position Exit _ s and an edge; the During action is implemented by creating a time automaton During _ s, as shown in fig. 7, which is synchronized by a synchronization signal start _ During _ s! To start the reducing _ s and indefinitely by the synchronisation signal end _ reducing _ s! To interrupt the reducing actions in the reducing _ s.

For the combination status, regardless of the situation with During action, the transformation algorithm is shown in table 1 below:

TABLE 1 conversion Algorithm

The input of the conversion is a combined state in a Robosim state machine model, an internal state machine and an in-out edge contained in the combined state are output as a migration sequence in a time automaton, wherein:

lines 1-4, process all immigration edges, if there is an Entry action in the combined state, then process it;

in lines 5 to 9, if the internal state machine has a termination state, the termination state is connected to all the migrated edges; if the combination state has an Exit action, processing the Exit action;

lines 10-21, if the internal state machine has no termination state, then the algorithm is recursively called for all its states, if it is a combined state; if it is a simple state only, it is connected to all the migrated edges, and if the combined state has an Exit action, it is processed;

on line 22, other nodes and transitions in the internal state machine are transformed according to the original transformation rules.

S3-2: in the Robosim state machine, the conversion rules of the migration Transition to the modeling element in the time automaton, including the normal migration and the migration with exec trigger, are shown in FIG. 5. Wherein, the ordinary migration directly converts the edge in the time automaton, and the source and the target can be directly mapped to the label source and the target on the edge of the time automaton; the action is a statement, and according to the subsequent step S3-4, the action can be mapped to an Update tag on the time automaton edge; the condition is an expression, and according to the subsequent step S3-4, the condition can be mapped to a tag guard on the time automaton edge. Migration with exec trigger when mapped to a modeling element in a temporal automaton expands the migration into two edges, one with the Sync tag exec _ sName!according to the Robosim semantics! Another startexec _ sName with Sync tag? .

S3-3: referring to fig. 8, the conversion rule of the Context in the robosil meta-model to the modeling element of the time automaton, and the conversion of the Context in the robosil state machine to the modeling element in the time automaton include local variables (including constants), operations, events, and global interfaces, wherein the global interfaces include global variables (including constants), operations, and events, and the conversion rule is as shown in fig. 8.

S3-4: referring to fig. 9, rules for conversion of statements in RoboSim meta-model to modeling elements of temporal automata, and conversion of statements and expressions in RoboSim to modeling elements of temporal automata. Where the statements include clock resets, calls (operations and events) and variable assignments, as shown in figure 9.

Referring to fig. 10, rules for the conversion of expressions to time automaton modeling elements in the robosi meta model. The expressions include arithmetic expressions, relational expressions, logical expressions, data expressions, and keywords, as shown in fig. 10.

S3-5: and combining the steps to obtain the converted time automaton model.

The step S4 specifically includes the following steps:

s4-1: generating the deadlock free A [ ] not deadlock.

S4-2: and generating a non-Output Conflict property for the time automata corresponding to the execution cycles of all the components (modules, controllers and state machines), namely, generating the non-Output Conflict property that the position Output _ Conflict cannot be reached.

S4-3: and for the time automata corresponding to all the state machines, generating the reachability E < > sName.

The step S5 specifically includes the following steps:

s5-1: according to the DTD (document definition type) defined by UPPAAL (legal XML document building block), creating XML format document which is recognizable by UPPAAL.

S5-2: and filling the XML document with the global statement, the time automata aiming at the component execution period, the execution period of the state machine and the TCTL property, and adding other necessary tags to generate the XML file capable of being identified by UPPAAL.

The step S6 specifically includes the following steps:

s6-1: the XML file generated in step S5 is opened in the uppal tool.

S6-2: and simulating the converted time automaton network model corresponding to the Robosim model by using a simulator in the UPPAAL tool.

S6-3: the automatically generated TCTL properties are validated in a validator for use in a uppal tool.

S6-4: the validator is used in the UPPAAL tool to add other TCTL properties that are desired to be validated.

S6-5: and (3) analyzing a verification result by using a verifier in the UPPAAL tool, wherein the verification result shows whether the model meets the property, and if not, a counterexample path can be found in the simulator through a get trace button.

The following describes the present invention in detail by taking the FootBot model as an example, which simulates the movements, detecting obstacles, stopping and turning behavior of a robot system.

Example 1

The invention adopts a model conversion technology to convert a Robosim model into a time automaton network model and automatically generate basic TCTL properties so as to use a model detection tool UPPAAL to simulate, verify and analyze a robot simulation model, and specifically comprises the following steps:

1. and modeling a robot simulation model FootBot of the Robosim robot.

Referring to fig. 11, the model mainly comprises:

a. the robot comprises global interfaces ObstacleI and MovementI, wherein the ObstacleI declares an event obsacle and is used for indicating that the robot meets an obstacle; MovementI states the operations move (ls, as) and stop (), and ls and as are parameters of move operation and represent linear velocity of linear motion and angular velocity of a turn, respectively.

b. The module CFootBOt, with a cycle period of 1 time unit, contains a robot platform FootBot and a reference to a controller move. FootBot passes the event obstage to move and receives the outputs from move, i.e., move operation and stop operation.

c. The controller move, with a cycle of 1 time unit, contains a reference to a state machine simshift. Move passes the event obstage to SimMovement and receives outputs from SimMovement, i.e., move and stop operations.

d. The state machine simmovement has a cycle period of 1 time unit, and comprises an input obsaclei, an output MovementI, constants lv, PI, av and a clock variable MBC. In the state machine, the execution process of the control flow is as follows: when the state machine starts running, an initial migration (a migration from an initial connection) is triggered; when the control flow reaches the SMoving state, an entry action $ move (lv,0) is performed, which means that the robot is made to advance at a linear speed lv; then, the control flow directly enters a DMoving state from the SMoving state and then goes to the next junction from the DMoving state, wherein the special trigger exec marks the end of the first period; there are two migration paths from this junction, which one is chosen depending on whether a $ obstacle event occurs or not: if no obstacle is detected, the method returns to DMoving, otherwise, the method shifts to a Waiting state and carries out clock reset # MBC, and the robot stops moving by calling $ stop (); next, the control flow enters a stunning state through exec, and an entry action $ move (0, av) is executed, so that the robot rotates at an angular velocity av; after rotating a proper angle, the robot enters the SMoving state again to start moving.

2. Extracting the execution cycles and context contents of all modules, controllers and state machines from the FootBot model, filling the execution cycles and context contents into a time automaton model template, and generating a corresponding time automaton model, wherein the method specifically comprises the following steps:

a. and generating a time automaton CFoot _ cycle and a local statement corresponding to the execution cycle of the module CFoot in the FootBot model.

Referring to fig. 12, the operation flow of the time automaton is as follows:

firstly, starting from an initial position, resetting an output counter by using action Init (), simulating the random occurrence of an obsacle event by using a select statement i: int [0,1], and then storing data read from the outside into a local variable by using an action takeinput (i); the time automaton then immediately passes through the channel registerRead _ CFoot _ C! Passing the data to the move _ cycle while resetting the input using Reset (); then, the temporal automaton passes the registerWrite _ C _ CFootBot? Wait for output from move _ cycle and pass through channel register write! And the action GiveOutput () passes these values to the outside; if Output Conflict occurs, the time automaton is deadlocked at the Output _ Conflict position; finally, a new cycle is entered after waiting for period (value 1) time units and using the channel wait _ p! To ensure synchronization with move _ cycle and simmove _ cycle; if an end is received? Signaled, and simmove terminates, the time automaton moves to the End position and terminates.

b. And generating a time automaton move _ cycle and a local statement corresponding to the execution cycle of the controller move in the FootBot model.

Referring to fig. 13, the operation flow of the time automaton is as follows:

first, from the initial position, is there the signal regiosterread _ CFootBot _ C received? Starting the current period later, resetting an output counter by using action Init (), and storing data read from the CFoot _ cycle into a local variable by using action TakeInput (); the time automaton then immediately passes through the channel registered _ Movement _ S! Passing the data to the simmove _ cycle while resetting the input using Reset (); subsequently, the temporal automaton passes register write _ S _ move? Wait for the output from the SimMovement _ cycle and pass through the channel registerWrite _ C _ CFootBOT! And the action GiveOutput () passes these values to the outside; if Output Conflict occurs, the time automaton is deadlocked at the Output _ Conflict position; finally, after wait _ p is received? Ending the current period after the signal; if an end is received? Signaled, and simmovement terminates, then the time automaton moves to the End location and terminates.

c. And generating a time automaton SimMovement _ cycle and a local statement corresponding to the execution cycle of the state machine SimMovement in the FootBot model.

Referring to fig. 14, the operation flow of the time automaton is as follows:

first, from the initial position, is there the signal registered _ Movement _ S received? Starting the current period later, resetting an output counter by using action Init (), and storing the data read from move into a local variable by using action TakeInput (); next, the time automaton immediately passes through the channel startexec _ SimsMovement! Starting the current cycle of the state machine simshift while resetting the input using Reset (); then, the time automaton passes the collection _ simshift? Wait for the output from the SimsMovement and pass through the channel register write _ S _ Movement! And action GiveOutput () passes these values to the move _ cycle; if Output Conflict occurs, the time automaton is deadlocked at the Output _ Conflict position; after receiving the endexec _ simmsovement? Then marks that the SimMovement ends the execution of the current cycle; finally, after wait _ p is received? Ending the current period after the signal; if an end is received? Signaled, and simmove terminates, the time automaton moves to the End position and terminates.

3. And obtaining a time automaton model and a local statement corresponding to the SimMovement according to the migration relation in the state machine SimMovement in the RoboSim model, the meta model of the RoboSim and a predefined conversion rule.

Referring to FIG. 15, the conversion in SimMovement is as follows:

a. the initial node transitions to location i0 with a synchronization signal startexec _ simmsovement on the outgoing edge? .

b. The state smoling is converted into an emergency position entry _ smoling and an emergency position smoling, and a transition edge between them, where there are a series of assignment operations and a transmission signal collection _ simshift! The purpose is to output the value of the operation move to the simmove _ cycle and record the number of outputs.

c. The state DMoving switches to the emergency position DMoving, whose outgoing edge should switch to a position exec1 since it contains the trigger event exec, and whose incoming edge contains the send signal endexec _ simmsovement |. The emigration edge contains the received signal startexec _ simmsovement? .

d. The node transitions to commit position j0, contains a guard condition not on the edge from the node to DMoving (object _ simmove.b ═ true), contains a guard condition on the edge from the node to waiving (object _ simmove.b ═ true), sends a signal collection _ simmove! And a series of assignment operations whose purpose is to clock reset MBC to 0 and output the value of operation stop to simshift _ cycle and record the number of outputs.

e. State Waiting is converted into Emergency position Waiting, the outgoing edge of which, as it contains the trigger event exec, should be converted into a position exec2, the incoming edge of which contains the send signal exec _ SimsMovement! The extra edge contains the received signal startexec _ simsvovement? .

f. The status mapping is converted into the emergency location entry _ mapping and the emergency location mapping, and a transition edge therebetween, where the transition edge has a series of assignment operations and a transmission signal collection _ simshift! The purpose is to output the value of the operation move to the simmove _ cycle and record the number of outputs.

g. The state DTurning is converted into the emergency position DTurning, the outgoing edge of which, due to the inclusion of the trigger event exec, should be converted into a position exec3, the incoming edge of which contains the send signal exec _ simmsovement |. The emigration edge contains the received signal startexec _ simmsovement? .

h. The node is converted to commit position j1, and the edge from the node to DTurning contains the guard condition (MBC < (PI/av)), and the edge from the node to entry _ SMoving contains the guard condition (MBC > ═ PI/av).

4. According to the Robosim model, automatically generating corresponding TCTL properties, mainly comprising:

a. generating the deadlock-free property: a [ ] not decode lock;

b. for the time automata corresponding to the execution cycles of all the components (module cfoot _ cycle, controller move _ cycle, state machine simmomment _ cycle), the output conflict-free property is generated as follows:

A[]not(CFootBot_cycle.Output_Conflict or Movement_cycle.Output_Conflict or SimSMovement_cycle.O；

c. for the time automaton corresponding to the state simshift, the reachability of all the states in the state machine is generated as follows:

E<>SimSMovement.SMoving

E<>SimSMovement.DMoving

E<>SimSMovement.Waiting

E<>SimSMovement.STurning

E<>SimSMovement.DTurning。

5. combining all the generated time automata models into a time automata network model, combining the generated TCTL properties to obtain an XML result file which can be identified by UPPAAL, opening the result file by using a UPPAAL tool, and simulating, verifying and analyzing, wherein the verification result is shown in the following table 2:

TABLE 2 Property List and verification results

All properties are satisfied as shown in the property list of table 2 above.

The embodiments of the present invention have been described in detail, but the embodiments are merely examples, and the present invention is not limited to the embodiments described above. Any equivalent modifications and substitutions to those skilled in the art are also within the scope of the present invention. Accordingly, equivalent changes and modifications made without departing from the spirit and scope of the present invention should be covered by the present invention.

Claims (6)

1. A model detection method for a Robosim model real-time system is characterized in that a model conversion technology is adopted, a Robosim model is converted into a time automaton network model, basic TCTL properties are automatically generated, and a robot simulation model is simulated, verified and analyzed by using a model detection tool UPPAAL, and the method specifically comprises the following steps:

s1: designing a Robosim robot simulation model by using a Robosim model editor;

s2: extracting the execution period and context content of a module, a controller and a state machine in the Robosim model, filling the execution period and context content into a model template of the time automaton, and generating a time automaton model;

s3: extracting the migration relationship of the state machine diagram from the Robosim model, adding a conversion rule, and generating a time automaton model;

s4: automatically generating TCTL properties according to a Robosim model;

s5: combining all the time automata models generated in the steps S2 and S3 into a time automata network model, and generating an XML result file which can be identified by UPPAAL by combining the TCTL properties generated in the step S4;

s6: and opening the result file by using a UPPAAL tool, and performing simulation, verification and analysis.

2. The method for detecting the model of the Robosim model real-time system according to claim 1, wherein the time automaton model template specifically comprises:

s2-1: a time automaton model template aiming at a module in a Robosim model;

s2-2: aiming at a time automaton model template of a controller in a Robosim model;

s2-3: a time automaton model template for a state machine in a RoboSim model.

3. The method for detecting the model of the robosilm model real-time system according to claim 1, wherein the conversion rule specifically includes:

s3-1: converting a Node in a Robosim state machine into a modeling element in a time automaton model, wherein the Node comprises a connection junction, an initial connection junction, a simple state, a termination state, a state with internal actions and a composite state;

s3-2: the conversion of migrating transitions in a robosi state machine to modeling elements in a time automaton model comprises: normal migration and migration with exec triggers;

s3-3: the conversion of the context in the robosi state machine to the modeling element in the temporal automaton includes: local variables, operations, events, and a global interface, wherein the global interface comprises: global variables, operations and events;

s3-4: the conversion of statements and expressions in robosi to modeling elements in a temporal automaton, wherein the statements include: clock reset, call and variable assignment; the expression includes: arithmetic expressions, relational expressions, logical expressions, data expressions, and keywords.

4. The method of claim 1, wherein the TCTL properties specifically include:

s4-1: no dead lock A [ ] not dead lock;

s4-2: no output conflict nature;

s4-3: reachability of all states.

5. The model detection method for the Robosim model real-time system according to claim 1, wherein the XML result file capable of being identified by UPPAAL is generated by combining a plurality of time automaton models and TCTL properties and adding other necessary tags.

6. The method of claim 1, wherein the simulating, verifying and analyzing specifically comprises:

s6-1: opening the XML file generated in step S5 in the uppal tool;

s6-2: simulating the converted time automaton network model corresponding to the Robosim model by using a simulator in a UPPAAL tool;

s6-3: validating the automatically generated TCTL property in a upal tool using a validator;

s6-4: adding other TCTL properties to be verified by using a verifier in a UPPAAL tool for verification;

s6-5: the verification model is analyzed in the UPPAAL tool using a verifier, and if the property is not satisfied, a counter-example path can be found in the simulator through the get trace button.

Images