I have a simple kripke structure, where I have 3 states, with the following transitions:
s1 --> s2
s2 --> s1
s1 --> s3
s3 --> s3
s1 is the only initial state. I do not want the loop s1 to s2 be repeated more than a certain amount (say twice). In other transition systems, I could add a guard on the transition.
Q1: Can Kripke structures have guards on transitions?
Q2: If yes, how can I model it in NuSmv?
Thanks
You are comparing apples and oranges here. The model with guards (e.g. in NuSMV) defines a state space which again can be seen as a Kripke structure (let's ignore issues like deadlocks here).
Guards are an element of a modelling approach, whereas the Kripke structure is the underlying theoretical concept that is used to describe the state space.
Let's take an example: We have a model with a variable v that can take two values 1 and 2 with 1 as the initial value, and two transitions with guards:
a == WHEN v=1 THEN v:=2
b == WHEN v=2 THEN v:=1
The resulting state space would be:
[v=1] --> [v=2]
[v=2] --> [v=1]
That is actually a Kripke structure (with [v=1] as the only initial state and without any labels defined on the nodes) that does not contain any guards.
Update:
An example for set of labels for each node would be all Boolean expressions that evaluate to true there.
To summarize this for your two questions:
No, Kripke structures itself do not have guards.
Nevertheless (as explained, no guards in Kripke structures do not mean that there must not be guards in the model), I think you can regard the conditions in the case statement as a guard for the action right of the colon. Or with TRANS you have the guards implicit in the expression.
Related
Is it possible to have a state in NuSMV that does not have transitions to any other states? For example is it valid that in my code l3 does not have any transitions? When I run this NuSMV gives me the error that "case conditions are not exhaustive". Thanks!
MODULE main
VAR
location: {l1,l2,l3};
ASSIGN
init(location):=l1;
next(location):= case
(location = l1): l2;
(location = l2): l1;
(location = l2): l3;
esac;
By construction, in the so-called assignment-style [used in your model]:
there is always at least one initial state
all states have at least one next state
non-determinism is apparent
Alternatively, one can use the so-called constraint-style, which allows for:
inconsistent INIT constraints, which result in no initial state
inconsistent TRANS constraints, which result in deadlock states (i.e. a state without any outgoing transition to some next state)
non-determinism is hidden
For more info, see the second part of this course, which applies also to NuSMV for the most part.
An example of a FSM wherein some state has no future state is:
MODULE main
VAR b : boolean;
TRANS b -> FALSE;
The state in which b is true has no future state.
Conversely, the state in which b is false can loop in itself or go to the state in which b = true.
You can use the command check_fsm to detect deadlock states.
Please note that the presence of deadlock states can hinder the correctness of model checking in some situations. For instance:
FAQ #007: CTL specification with top level existential path quantifier
is wrongly reported as being violated. For example, for the model
below both specifications are reported to be false though one is just
the negation of the other! I know such problems can arise with
deadlock states, but running it with -ctt says that everything is
fine.
MODULE main
VAR b : boolean;
TRANS next(b) = b;
CTLSPEC EF b
CTLSPEC !(EF b)
For other critical consequences of deadlock states in the transition relation, see this page.
Usually, when NuSMV says that "the case conditions are not exhaustive" one adds a default action with a TRUE condition at the end of the case construct, which is triggered when none of the previous conditions applies. The most common choice for the default action is a self-loop, which is encoded as follows:
MODULE main
VAR
location: {l1,l2,l3};
ASSIGN
init(location):= l1;
next(location):=
case
(location = l1): l2;
(location = l2): {l1, l3};
TRUE : location;
esac;
NOTE: please notice that if there are multiple conditions with the same guard, only the first of these conditions is ever used. For this reason, when in your model location = l2 then the next value of location can only be l1 and never l3. To fix this, and have some non-deterministic choice among l1 and l3, one must list all possible future values under the same condition as a set of values (i.e. {l1, l3}).
I have to model a "seven-body-mechanism" in Modelica:
The initial angles are given:
Starting with the left side (K5 and K7):
The Modelica Model:
Is it possible to model for example K5 as one body-shape and just specify the center of mass?
Where can I set the initial angles for K5 and K7? In the model "revolute2" it is possible to set one "phi_start"
Which models should I use for the "fixed" B and O? There is this parameter: Position vector from world frame to frame_b, resolved in world frame.
edit: I think i can fix the problem with 2 different angles - I just added another revolute:
The next problem I have: how to model the revolute where K5 and K4 meet? I am not sure if i should also use 2 revolutes? How to model the fixes B and O? A is fixed to the origin, but I am not sure which position vector for B and O.
I always get an error "all forces connot be uniquely calculated"
Thank you very much for your help
Have a look at the Modelica.Mechanics.MultiBody.Examples.Loops.PlanarLoops_analytic example, this contains an example of the K4, K5, K6 and K7 mechanism. In this mechanism set the start value of the Revolute.
Well the crucial part in the mechanism is the connection between O and B (planar four link) which can be solved using e.g. Modelica.Mechanics.MultiBody.Joints.Assemblies.JointRRR as demonstrated in Modelica.Mechanics.MultiBody.Examples.Loops.PlanarLoops_analytic.
The binary members K5-K4 and K7-K6 are principally the same and they don't change the degrees of freedom of the abovementioned planar four link. So they have to be modelled in the same way (which means the revolute2 and revolute6 must be instantiated twice in your model) and be connected similarly to the planar four link once it is properly parameterized and initiated.
Optionally, you can model the mechanism using the PlanarMechanics library.
Say I have a fluid model, with initial pressures, temperatures, valve settings, etc.
Is there a way to run a State Graph simulation where each of the states contains new component parameter settings for the model, i.e. some parameters of some selected components are changed during one state, and are changed again during the next state?
For example, during State1 let's set the values for the following component parameters:
source.pressure = 1
source.temperature = 1
valve1.opening = 1
Until State1 switches to State2 where the parameters are:
source.pressure = 0.5
source.temperature = 0.5
valve1.opening = 0.5
Thanks for your time :-)
Short answer: No. For that use-case you should use discrete variables (and change them using a when-clause).
Long answer: As of version 3.3, Modelica has a new feature, called State Machines (see chapter 17 of the specification). In theory, it should do what you require, but it might still be buggy since it is quite new.
What you are attempting to do is called "variable structure modeling" (although only changing parameters is hardly "variable structure" and can be implemented using discrete variables instead, as my short answer suggests). Long before StateMachines where introduced to Modelica, this was (and remains) an active area of research. You could also use an external tool to achieve your goal, e.g. DysMo
If you were to write an API that is called from Lua (which is 1-based, e.g. table indices start at 1), would you apply the same rule to your API?
For example, say your API had a function called GetFoo(x, y) which returned a Foo at the coordinate (x,y). Would you start your coordinate axes at (0,0) or (1,1) for the API, assuming that in the system itself (say written in C or C++ which are 0-based) these things start at (0,0) (so if you used the Lua convention you would always have to subtract 1 when retrieving numbers for these kinds of operations from the lua stack).
I haven't used Lua, but I would say for a coordinate system specifically (0,0) would be preferred.
For everything else, as long as you state it clearly in the documentation, by all means start indices at 1.
You could also just use the 0 index in your table/arrays. The only inconvenience is the standard libraries use the 1-based convention. So things like table.sort, string operations, etc ... will ignore the table[0] element.
I am really stuck with some state based testing concepts...
I am trying to calculate some checking sequences that will cover all transitions from each state and i have the answers but i dont understand them:
alt text http://www.gam3r.co.uk/1m.jpg
Now the answers i have are :
alt text http://www.gam3r.co.uk/2m.jpg
I dont understand it at all. For example say we want to check transition a/x from s1, wouldnt we do ab only? As we are already in s1, we do a/x to test the transition to s2, then b to check we are in the previous right state(s1)? I cant understand why it is aba or even bb for s1...
Can anyone talk me through it?
Thanks
There are 2 events available in each of 4 states, giving 8 transitions, which the author has decided to test in 8 separate test sequences. Each sequence (except the S1 sequences - apparently the machine's initial state is S1) needs to drive the machine to the target state and then perform either event a or event b.
The sequences he has chosen are sufficient, in that each transition is covered. However, they are not unique, and - as you have observed - not minimal.
A more obvious choice would be:
a b
ab aa
aaa aab
ba bb
I don't understand the author's purpose in adding superfluous transitions at the end of each sequence. The system is a Mealy machine - the behaviour of the machine is uniquely determined by the current state and event. There is no memory of the path leading to the current state; therefore the author's extra transitions give no additional coverage and serve only to confuse.
You are also correct that you could cover the all transitions with a shorter set of paths through the graph. However, I would be disinclined to do that. Clarity is more important than optimization for test code.