This report documents the development of the model of a single robot in a swarm acting under the Alpha Algorithm. Chapter 1 presents our model of the Alpha Algorithm implemented in a single robot, and presents the results of the verification of the requirements described below. Chapter 2 presents results of the verification using the timed RoboChart model of the Alpha Algorithm, considering both the requirements described below as well as requirements regarding timed properties.
As a basis for verification, we define below a few requirements for the alpha algorithm restricted to a single robot. The basic requirements are core properties. The model requirements are specific of the application. We encode them as CSP processes, which refer to elements of the semantics of the RoboChart model we present below. Only those interested in understanding the formal description of the semantics need to read these process definitions.
In particular, if the robot broadcasts its identifier through broadcast
, zero or more occurrences of receive
, whose first
element of the parameter is that identifier, occur; these are the responses from the neighbours. While the robot receives
responses from neighbours, it also can receive a broadcast from another robot, which is followed by a receive
event,
whose parameter contains the parameter of the broadcast
as first element, and the identifier of the robot as the second element.
Spec1 = let
Responds = (|~|x:ID @ receive.(Communication_id,x) -> Responds) |~| SKIP
Run = broadcast?x:diff(ID,{Communication_id}) -> receive!(x,Communication_id) -> Run |~| SKIP
Main = broadcast.Communication_id -> (Responds|||Run); Main
within
Main
assert Spec1 [F= AggregationSoftware_O\diff(Events,{|receive,broadcast|})
Spec2 = let
Moves = moveCall -> moveRet -> (Moves |~| SKIP)
Run = |~|x:Position @ obstacle.x -> Moves; Run
within
Moves; Run
assert Spec2 [F= AggregationSoftware_O\diff(Events,{|moveCall,moveRet,obstacle|})
The model for the Alpha Algorithm shown below is very simple as is common in swarm algorithms. The Alpha-Algorithm
state machines have timed cyclic behaviours defined using clocks. The robot is required to: turn after every MB
time units,
and probe for information from its neighbours after every RC
time units. The value of these constants is left undefined in
the RoboChart model, and so for a particular system they need to be instantiated. In particular, because of the interaction
between the state machines their values need to be chosen so that overall the system can satisfy both cyclic periods.
These cyclic behaviours are specified in the state machines Movement
and Communication
through the use of clocks and
appropriate timed conditions. For example, in the case of the state machine Movement
, the state Turning
is entered
after MB
time units (specified by the condition since(MBC)>=MB
on the transition from MovementAndAvoidance
to
Turning
). Similarly, in the state machine Communication
, the state Receive
is entered after every RC
time units
(specified by the condition since(RCC)>=RC
between the states Receive
and Broadcast
).
Most of the requirements are established easily by FDR, except A.1 which states that the communication behaviour is deterministic. This fails because in
the state Receive
, the transition guarded by [since(RCC) >= RC]
(once it becomes enabled) introduces a nondeterminism.
Since this transition does not have a trigger, if any of the events that trigger another transition from Receive
occur,
then either that transition of the one guarded by [since(RCC) >= RC]
can take place.
The model can be altered to satisfy this requirement by conditioning all competing transitions with [since(RCC)<RC]
.
While the requirement still cannot be verified in the untimed model, in the timed model we are able to prove it. This is
discussed in the next chapter, where we present an alternative model with the extra guards.
Absence of timed guards on transitions are also why requirements A.5 and A.7 are verified successfully. However, further review of the
model and its semantics uncovers that the random()
function does not introduce nondeterminism. This is due to the fact that
the CSP semantics of RoboChart does not support the definition of nondeterministic functions such as random()
.
This limitation can be overcome by modifying the CSP model directly, and extracting the nondeterminism from the function
call and distributing it over the statement. For instance, the statement x = random()
can be defined as |~|i:real @ x = i
,
provided that the output type of random
is real
and that in the model real
is instantiated as a finite set. We do not
pursue this option here.
In this particular model, nondeterminism should only arise from the use of random()
as a parameter to wait
.
This can be addressed using the timed semantics of RoboChat, which is the object of the next chapter.
This model was created and analysed using the following version of the RoboTool plugins:
Plugin | Version |
---|---|
RoboChart Metamodel | 2.0.0.202206211010 |
RoboChart Textual Editor | 3.0.0.202206290948 |
RoboChart Graphical Editor | 2.0.0.202208141127 |
RoboChart CSP Generator | 3.0.0.202206212138 |
Requirement | Result |
---|---|
A.1 CommunicationC is deterministic |
false |
A.2 CommunicationC is divergence free |
true |
A.3 CommunicationC is deadlock free |
true |
A.4 MovementC is nondeterministic |
true |
A.5 MovementC is divergence free |
true |
A.6 MovementC is deadlock free |
true |
A.7 AggregationSoftware_O is nondeterministic |
true |
A.8 AggregationSoftware_O is divergence free |
true |
A.9 AggregationSoftware_O is deadlock free |
true |
B.1 AggregationSoftware_O refines Spec1 |
true |
B.2 AggregationSoftware_O refines Spec2 |
true |
In this chapter we address the limitations of the analysis discussed in the previous chapter by analysing the
Alpha-Algorithm specification using the tock-CSP
model derived from the RoboChart specification. In addition, we consider some additional requirements related to time.
To cater for the extra requirements, we define tock-CSP
processes. Like the processes above, they refer to elements
of the semantics of the RoboChart model. Only those interested in understanding the formal description of the timed
semantics need to read these process definitions.
In the semantics, we have a process T_Movement_VS
, where the internal events Movement_enteredV
,
Movement_enterV
, and Movement_exitV
are visible. These events record when a state of the Movement
state
machine is beginning to enter, has entered, and is being exited, respectively. The semantics also defines a
corresponding process T_Communication_VS
for the state machineCommunication
, where the events
Communication_enterV
andCommunication_exitV
are made visible. Similarly,AggregationSoftware_VS
makes
those events visible for the whole robotic system. Untimed versions of these processes are similarly defined
without the prefix T_
. The tock-CSP
processes without the internal events visible are defined as: T_Movement
, T_Communication
and T_AggregationSoftware
, respectively.
To check this property we define the following auxiliary sets of events visible for the state machines and the whole robot.
TA_ExternalEvents_Movement = {|Movement_obstacle,Movement_neighbours|}
TA_ExternalEvents_Communication = {|Communication_receive,Communication_robots|}
TA_ExternalEvents_AggregationSoftware = {|obstacle,receive|}
Absence of timelocks corresponds to not refusing tock
events at any point, whereas other externally visible events can be
performed or refused arbitrarily. For example, for the overall Alpha Algorithm module, we check this property by considering
the refinement between: the parallel composition in interleaving of RUN({tock})
, which offers tock
forever, and CHAOS(TA_ExternalEvents_AggregationSoftware)
,
which may or may not refuse events in the set TA_ExternalEvents_AggregationSoftware
forever, and the process T_AggregationSoftware |\ union(TA_ExternalEvents_AggregationSoftware,{tock})
where every event other than tock
and those in the set TA_ExternalEvents_AggregationSoftware
are hidden using |\
.
-- Requirement TA.1
assert RUN({tock}) ||| CHAOS(TA_ExternalEvents_Movement) [F= T_Movement |\ union(TA_ExternalEvents_Movement,{tock})
assert RUN({tock}) ||| CHAOS(TA_ExternalEvents_Communication) [F= T_Communication |\ union(TA_ExternalEvents_Communication,{tock})
assert RUN({tock}) ||| CHAOS(TA_ExternalEvents_AggregationSoftware) [F= T_AggregationSoftware |\ union(TA_ExternalEvents_AggregationSoftware,{tock})
-- Requirement TA.2
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning_Turn180"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning_RandomTurn"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning_f1"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_MovementAndAvoidance"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_MovementAndAvoidance_Move"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_MovementAndAvoidance_Avoid"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Communication_enteredV."Communication_Broadcast"|}
assert not STOP [T= T_AggregationSoftware_VS |\ {|Communication_enteredV."Communication_Receive"|}
In the following assertions we check that every state can be entered forever. For example, in the case of the state
Turn180
we check that when considering the process T_AggregationSoftware_VS
modelling the overall module with the
Movement_enteredV."Movement_Turning_Turn180"
event visible and no other, then it is refined by
RUN({|Movement_enteredV."Movement_Turning_Turn180"|})
, which continuously offers the event
Movement_enteredV."Movement_Turning_Turn180"
.
-- Requirement TA.3
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning_Turn180"|}
[T= RUN({|Movement_enteredV."Movement_Turning_Turn180"|})
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning_RandomTurn"|}
[T= RUN({|Movement_enteredV."Movement_Turning_RandomTurn"|})
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning_f1"|}
[T= RUN({|Movement_enteredV."Movement_Turning_f1"|})
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_Turning"|}
[T= RUN({|Movement_enteredV."Movement_Turning"|})
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_MovementAndAvoidance"|}
[T= RUN({|Movement_enteredV."Movement_MovementAndAvoidance"|})
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_MovementAndAvoidance_Move"|}
[T= RUN({|Movement_enteredV."Movement_MovementAndAvoidance_Move"|})
assert T_AggregationSoftware_VS |\ {|Movement_enteredV."Movement_MovementAndAvoidance_Avoid"|}
[T= RUN({|Movement_enteredV."Movement_MovementAndAvoidance_Avoid"|})
assert T_AggregationSoftware_VS |\ {|Communication_enteredV."Communication_Broadcast"|}
[T= RUN({|Communication_enteredV."Communication_Broadcast"|})
assert T_AggregationSoftware_VS |\ {|Communication_enteredV."Communication_Receive"|}
[T= RUN({|Communication_enteredV."Communication_Receive"|})
-- Requirement TA.4
assert T_AggregationSoftware |\ union(ExternalEvents_AggregationSoftware,{tock}) :[divergence free]
RC
continuous time units are spent in the state Receive
of the state-machine Communication
.Since the cyclic behaviour of the state machine Communication
is specified by the period RC
, we capture the maximum time allowed in the state Receive
by defining the following tock-CSP
process CommunicationStateSpent(t,x)
, where t
is a parameter that we can vary to analyse the system, and x
is the unique name of the state being considered.
CommunicationStateSpent(t,x) =
let
Main = AnyOther({|Communication_enterV.x|}) ; ADeadline({|Communication_exitV.x|},t) ; Main
within
timed_priority(Main)
This process first accepts any event nondeterministically using AnyOther(E) = CHAOS(Events) [|E|> SKIP
, but once the event
Communication_enterV.x
occurs, then it requires that the event Communication_exitV.x
must take place within t
time units.
This deadline is encoded using the process ADeadline(E,d) = (CHAOS(Events) [| {tock} |] WAIT(d)) [|E|> SKIP
, which allows
any event to happen nondeterministically within d
time units, but after that an event in the set E
must take place before
time can pass. On the other hand, as soon as some event in E
takes place, ADeadline(E,d)
terminates. Finally there is a recursion. The overall process is defined by applying timed\_priority
to Main
, which ensures that maximal progress, that is, every internal event is performed before time can pass, is achieved in the tock-CSP
encoding.
In our case, since the timed condition between Receive
and Broadcast
is since(RCC)>=RC
, we specify through the following
assertion that no more than Communication_RC
time units are spent in state "Communication_Receive"
. We observe that in
the CSP
model of RoboChart, variables and constants are uniquely identified together with the name of the state machine where they are declared, hence constant RC
is actually uniquely defined as Communication_RC
.
-- Requirement TB.1
assert CommunicationStateSpent(Communication_RC,"Communication_Receive")
[FD=
T_AggregationSoftware_VS
Communication
starts to enter the state Receive
exactly every RC
units.EnterExactly(t) =
let
Initial = ADeadline({|Communication_enterV."Communication_Receive"|},0)
EveryT = ADeadline({|Communication_enterV."Communication_Receive"|},t) ; EveryT
within
timed_priority(Initial ; EveryT)
-- Requirement TB.2
assert EnterExactly(Communication_RC)
[FD=
T_AggregationSoftware_VS
Broadcast
of state machine Communication
.In order to be able to receive
or broadcast
every time unit, except for when the robot does its own broadcast
every RC
units, we check that no time is spent in state Broadcast
via the following assertion.
-- Requirement TB.3
assert CommunicationStateSpent(0,"Communication_Broadcast")
[FD=
T_AggregationSoftware_VS
RC
time units, when a broadcast.Communication_id
happens, then the events broadcast
and receive
are offered before RC
time units elapse.We define the following process NoEvent
, where we first allow any event nondeterministically in AnyOther({|broadcast.Communication_id|})
, and following a broadcast.Communication_id
, it then behaves as BroadcastHappened(0)
, which offers receive
and broadcast
before RC
units elapse. If receive
or broadcast
happen, then any event is offered until RC
units elapse. After the elapsing of RC
units, the process behaves as NoEvent
once more.
NoEvent = AnyOther({|broadcast.Communication_id|}) ; BroadcastHappened(0)
BroadcastHappened(t) = (t < Communication_RC & (broadcast ?x-> SomeHappened(t)
[]
receive?x:{x|x <- {(Communication_id,x0) | x0 <- ID}} -> SomeHappened(t)
[]
tock -> BroadcastHappened(t+1)))
[]
t == Communication_RC & NoEvent
SomeHappened(t) = t < Communication_RC & (AnyOther({tock}) ; SomeHappened(t+1))
[]
t == Communication_RC & NoEvent
We then check that NoEvent
in interleaving with the process that offers moveCall
, moveRet
, obstacle
and tock
nondeterministically, is refined by T_AggregationSoftware
. The events moveCall
, moveRet
and obstacle
are kept visible in T_AggregationSoftware
as hiding them would introduce unwanted divergences for this check.
-- Requirement TB.4
assert CHAOS({|moveCall,moveRet,obstacle,tock|}) [| {tock} |] NoEvent [FD= T_AggregationSoftware
MB
time units, the state Turning
in the state machine Movement
is entered.The cyclic period MB
of the state machine Movement
can be captured by requiring that the state Turning
is entered every MB
units.
EveryMBEnterTurning =
let
Main = ADeadline({|Movement_enterV."Movement_Turning"|},Movement_MB) ; Main
within
timed_priority(Main)
-- Requirement TB.5
assert EveryMBEnterTurning [FD= T_AggregationSoftware_VS
MovementAndAvoidance
is entered, up to MB
time units are spent in this state.To capture the maximum allowed time spent in a certain state of state machine Movement
, we define the following CSP process MovementStateSpent(t,x)
.
MovementStateSpent(t,x) =
let
Main = AnyOther({|Movement_enterV.x|}) ; ADeadline({|Movement_exitV.x|},t) ; Main
within
timed_priority(Main)
For example, the following assertion encodes the requirement that state MovementAndAvoidance
does not take more than MB
time units, which could disrupt the cyclic behaviour of state Turning
.
-- Requirement TB.6
assert MovementStateSpent(Movement_MB,"Movement_MovementAndAvoidance") [FD= T_AggregationSoftware_VS
360/av
time units are spent in the state Avoid
of the state-machine Movement
.Given that random()
ranges over the real interval 0..1
, and that the transition from Avoid
to Move
should be taken immediately once the entry action of the state Avoid
is completed, the state Avoid
should be left in no more than 360/av time units. This is a derived property taking into account the definition of the behaviour in the state Avoid
in terms of random()
.
-- Requirement TB.7
assert MovementStateSpent(360/Movement_av,"Movement_MovementAndAvoidance_Avoid")
[FD=
T_AggregationSoftware_VS
360/av
time units are spent in the state Turning
of state-machine Movement
.Similarly to the previous requirement, we require that once the state Turning
has been entered, no more than 360/av
time units are spent in that state.
-- Requirement TB.8
assert MovementStateSpent(360/Movement_av,"Movement_Turning") [FD= T_AggregationSoftware_VS
Here we analyse the initial version of the Alpha Algorithm model as presented in the introduction. Not surprisingly, the issues already raised there show up here again.
To make the conditions using random()
analysable, we make random range over the interval from 0
to 1
. This is
a limitation of the encoding of reals as a finite set, and the fact that FDR
does not handle fixed or floating point types. An alternative that could be considered would include an encoding of rational numbers.
We consider RC = 1
and MB = 1
.
Requirement | Result | Notes |
---|---|---|
A.1 | fail | |
A.2 | pass | |
A.3 | - | [2] |
A.4 | pass | |
A.5 | pass | |
A.6 | - | [2] |
A.7 | pass | [1] |
A.8 | pass | [1] |
A.9 | - | [1,2] |
[1]: These results are only tractable due to the selective application of FDR’s wbisim
compression
function.
[2]: In the timed model we can ascertain the absense of time locks, but not the absence, in general, of deadlocks.
[A.1]: Fails just like in the untimed model because, once since(RCC) >= RC
is true, the transition from
Receive
to Broadcast
competes nondeterministically with the self-transitions on state Receive
. To make Communication
deterministic the self-transitions need to be disabled once since(RCC) >= RC
is true.
Requirement | Result | Notes |
---|---|---|
B.1 | pass | |
B.2 | pass |
Requirement | Result | Notes |
---|---|---|
TA.1 | pass | [2] |
TA.2 | pass | |
TA.3 | pass | |
TA.4 | pass |
Requirement | Result | Notes |
---|---|---|
TB.1 | fail | |
TB.2 | fail | |
TB.3 | fail | |
TB.4 | fail | |
TB.5 | fail | |
TB.6 | fail | |
TB.7 | pass | |
TB.8 | fail |
[TB.1]: Fails because there is no guarantee that once in state Receive
the event receive
takes place immediately, and so more than RC
time units can be spent in state Receive
violating requirement TB.1.
[TB.2]: Similarly to TB.1, TB.2 fails because there is no requirement on broadcast
to take place immediately in state Broadcast
, so it is not necessarily the case that state Receive
is entered every RC
time units.
[TB.3]: Similarly to TB.2, TB.3 fails because it is not possible to guarantee that no time is spent in state Broadcast
as there is no deadline on the event broadcast
.
[TB.4]: Fails because exactly after RC
units have passed, there is a nondeterminism between transitioning to state Broadcast
or allowing another self-transition on state Receive
, such as broadcast
with a different ID other than Communication_ID
, to take place.
[TB.5]: Fails because there is no guarantee that the transition from state MovementAndAvoid
is taken exactly after since(MBC) >= MB
is true. Namely, if the robot detects an object
then the avoidance takes some time, which is always allowed to happen. Therefore, an appropriate condition on the transition from Move
to Avoid
would be since(MBC) < MB - 360/av
, with the caveat that MB
itself must satisfy MB - 360/av >= 0
, so MB >= 360/av
. And in order to at least offer the possibility to treat the object
event for at least one time unit, MB > 360/av
.
Even if we fix the condition on the assertion from Move
to Avoid
, there is still a problem with the lack of clock resets on the transitions between states MovementAndAvoid
and Turning
. The appropriate change, incorporating the suggestion described here, is to have a clock reset on the transition from state MovementAndAvoid
to state Turning
. In this way the clock MBC
also reflects the time since entering state Turning
and together with the condition since(MBC) <= MB - 360/av
guarantees that the transition on obstacle
does not compete with the timed trigger.
To fully satisfy the requirement, however, it is necessary to make sure that MB < EE
, where EE
is the worst-case time taken by state Turning
, which, overall depends on RCC
as well.
[TB.6]: Fails because once an obstacle
is detected, it is no longer the case that the transition from MovementAndAvoid
to state Turning
is triggered after MB
units. Similarly to requirement TB.5
this property cannot be satisfied unless the transition on obstacle
is guarded by since(MBC) < MB -360/av
so that no more than MB
units are ever spent in state MovementAndAvoidance
.
[TB.8]: Fails because the state-machine Movement
may not be able to receive a value through the event neighbours
immediately, and so it could spend an unbounded amount of time in state Turning
.
This model was created and analysed using the following version of the RoboTool plugins:
Plugin | Version |
---|---|
RoboChart Metamodel | 2.0.0.202206211010 |
RoboChart Textual Editor | 3.0.0.202206290948 |
RoboChart Graphical Editor | 2.0.0.202208141127 |
RoboChart CSP Generator | 3.0.0.202206212138 |
To cater for requirement A.1
we change the transitions out of state Receive
, on state machine Communication
, to be guarded with a conjunction on since(RCC)<RC
so that they do not compete with the guarded transition from Receive
to Broadcast
. We adopt the following changes to state-machine Communication
:
broadcast!id
is annotated with deadline 0
.Receive
with trigger broadcast
is guarded by [since(RCC)<RC]
.Receive
with trigger receive
is guarded with a conjunction with sinceRCC<RC
.To cater for the other requirements, we adjust the transitions in the state machine Communication
as follows:
Receive
with trigger broadcast
is annotated with deadline 0
.We also adjust the transitions in state machine Movement
as follows:
Move
to Avoid
is guarded with the condition since(MBC) < MB-360/av
, so that obstacle
is offered before MB
time units have passed since the last reset of clock MBC
and any time that could be taken by state Avoid
(which in the worst case is 360/av
).MovementAndAvoidance
to state Turning
has a reset on clock MBC
added, so that the time spent by state Turning
can be taken into account for the purpose of the cyclic execution.We also note that
MB
must be greater than 360/av
.The changed diagrams are reproduced below.
For the purpose of our analysis we consider consider RC = 360/av+1
and MB = 360/av+1
.
Requirement | Result | Notes |
---|---|---|
A.1 | pass | |
A.2 | pass | |
A.3 | - | |
A.4 | pass | |
A.5 | pass | |
A.6 | - | |
A.7 | pass | |
A.8 | pass | |
A.9 | - |
Requirement | Result | Notes |
---|---|---|
B.1 | ? | [3] |
B.2 | ? | [3] |
[3]: Unable to verify due to abortion in FDR’s execution.
Requirement | Result | Notes |
---|---|---|
TA.1 | pass | [4] |
TA.2 | pass | |
TA.3 | pass | |
TA.4 | pass |
[4]: Result is conditional on hiding the events Communication_receive
, Communication_robots
and receive
in the checks, as these events now have deadlines imposed on them and thus result in visible timelocks. The updated assertions are listed below.
-- Requirement TA.1 [modified to cater for known timelocks caused by deadlines]
TA_ExternalEvents_Communication_WithoutDeadlines = {|Communication_robots|}
TA_ExternalEvents_AggregationSoftware_WithoutDeadlines = {|obstacle|}
assert RUN({tock}) ||| CHAOS(TA_ExternalEvents_Communication_WithoutDeadlines) [F= T_Communication |\ union(TA_ExternalEvents_Communication_WithoutDeadlines,{tock})
assert RUN({tock}) ||| CHAOS(TA_ExternalEvents_AggregationSoftware_WithoutDeadlines) [F= T_AggregationSoftware |\ union(TA_ExternalEvents_AggregationSoftware_WithoutDeadlines,{tock})
Requirement | Result | Notes |
---|---|---|
TB.1 | pass | |
TB.2 | pass | |
TB.3 | pass | |
TB.4 | pass | |
TB.5 | pass | |
TB.6 | pass | |
TB.7 | pass | |
TB.8 | pass |
This model was created and analysed using the following version of the RoboTool plugins:
Plugin | Version |
---|---|
RoboChart Metamodel | 2.0.0.202206211010 |
RoboChart Textual Editor | 3.0.0.202206290948 |
RoboChart Graphical Editor | 2.0.0.202208141127 |
RoboChart CSP Generator | 3.0.0.202206212138 |
The project file contains a manually generated semantics of the simulation for the Alpha Algorithm example, focusing on the Movement machine, as well as its correctness verification.
The simulation was verified against the RoboChart model with assumptions TA1
, TA2
and TA3
.
The file with the CSP models and verification assertions is:
src-gen/timed/AlphaAlgorithm_assertionsVerification.csp
The interested reader can load this file in the FDR4 tool and check the assertions. The relevant assertions are:
assert PMConstrainedSpecA3 \ ExternalEvents_System [FD= SimSpec
assert SimSpec [FD= PMConstrainedSpecA3 \ ExternalEvents_System
They assert that the manually generated simulation model for the Movement machine
(SimSpec
) has the same behaviour (in the Failures-Divergences model of CSP) as the
RoboChart model with the assumptions.
Department of Computer Science
Deramore Lane, University of York, Heslington, York, YO10 5GH, UK
Tel: 01904 325500
University of York legal statements