M. Jackson: Problem Frames Two Sluice Gate Control Examples

Transcript

Egon Börger (Pisa)
M. Jackson: Problem Frames
Two Sluice Gate Control Examples
Illustrating
a required behaviour frame (Sluice Gate Control)
a commanded behaviour frame (Operated Sluice Gate Control)
Università di Pisa, Dipartimento di Informatica, I-56127 Pisa, Italy
[email protected]
c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy.
Copyright 1
Sluice Gate Control Problem Description (p.49)
A small sluice, with a rising and falling gate, is used in a simple
irrigation system. A computer system is needed to control the sluice
gate: the requirement is that the gate should be held in the fully
open position for ten minutes in every three hours and otherwise kept
in the fully closed position.
The gate is opened and closed by rotating vertical screws. The
screws are driven by a small motor , which can be controlled by
clockwise, anticlockwise, on and off pulses.
There are sensors at the top and bottom of the gate travel; at the
top it’s fully open, at the bottom it’s fully shut.
The connection to the computer consists of four pulse lines for
motor control and two status lines for the gate sensors.
NB. No initialization requirements are formulated.
Copyright 2
Two-Phase Ground Model to capture user requirements
Ground model, displayed in FSM-style graphical notation, abstracts from
screws, motor, sensors, pulses, reducing the device to switching from
phase fullyClosed to fullyOpen when time closedPeriod has passed,
and back when openPeriod has elapsed
timing model, using monitored boolean-valued locations
Passed (openPeriod ), Passed (closedPeriod ) with appropriate
interpretation
motor actions Open = Shut = skip (placeholder for refinement)
Copyright 3
‘Showing’ the ground model to be ‘correct’
The above stated requirement is “that the gate should be held in the
fully open position for ten minutes in every three hours and otherwise
kept in the fully closed position”.
The SluiceGateGround model and its runs are mathematical
objects for which one can prove the following :
Let S0, S1, . . . be any run of SluiceGateGround, started in an
initial state S0 where ctl state = fullyClosed and
– period =3 h, closedPeriod =170 min, openPeriod =10 min.
Then for each number n the following holds:
– state S2n is reached by step 2n, satisfies ctl state = fullyClosed
and lasts closedPeriod (until step 2n + 1 is executed),
– state S2n+1 is reached by step 2n + 1, satisfies
ctl state = fullyOpen and lasts openPeriod (until step 2n + 2 is
executed).
Proof: Induction on n.
Copyright 4
SluiceGateGround Domain Knowledge
Open, Shut in the env work using a screws driving motor that
can be set on and off
has two move dir ection values: clockwise (say to raise the gate) and
anticlockwise (say to lower the gate)
obtains gate status information from two sensors informing about the
(in SluiceGateGround monitored) Event(Top)/Event(Bottom)
of the gate travel reaching its top (fully open)/bottom (fully closed).
The connection bw motor, sensors and control program consists of
four pulse lines to Emit(Pulse(...)) (output) for motor control
two status lines to monitor Event(...)s (input) from the gate sensors
This knowledge guides two refinements of SluiceGateGround:
introducing the motor and the sensors in SluiceGateMotorCtl
detailing the connection bw the controller and the physical equipment
in the status line driven and pulse driving SluiceGateCtl
Copyright 5
Refinement SluiceGateMotorCtl defining motor actions
controlled locs motor : {on, off }, dir : {clockwise, anticlockwise}
Boolean-valued monitored locations Event(Top), Event(Bottom)
with appropriate Input Locations Assumption (for correctness proof)
StartToRaise = (dir := clockwise, motor := on)
StartToLower = (dir := anticlockwise, motor := on)
StopMotor = (motor := off )
closedPeriod = period
−(StartToRaiseTime + OpeningTime + StopMotorTime)
−(StartToLowerTime + ClosingTime + StopMotorTime)
Copyright 6
Refinement SluiceGate defining status lines and pulses
Environment machine describing equipment actions when pulses appear
Pulses = upon Event(Clockwise) do dir := clockwise
upon Event(AntiClockwise) do dir := anticlockwise
upon Event(MotorOn) do motor := on
upon Event(MotorOff ) do motor := off
SluiceGateMotorCtl with Emit(Pulse(. . .)) submachines
StartToRaise = Emit(Pulse(Clockwise))
Emit(Pulse(MotorOn))
StartToLower = Emit(Pulse(AntiClockwise))
Emit(Pulse(MotorOn))
StopMotor = Emit(Pulse(MotorOff ))
Copyright 7
Proving correctness of the refinement
Correctness proof, relating abstract and refined runs, relies upon:
Pulse Output Assumption: each Emit(Pulse(p)) in
SluiceGateCtl yields Event(p) to happen in the env machine
Input Locations Assumption reinterpreted, reflecting that the
information detected by the sensors arrives at SluiceGateCtl as
input Event(Top), Event(Bottom) via two status lines
Usual convention that events are consumed by triggering the rule
guarded by them
NB. Refinement type is (1,2), meaning that:
every segment consisting of one step of SluiceGateMotorCtl is
refined by
a segment of two corresponding steps of SluiceGate consisting of
– one step of software machine SluiceGateCtl
– followed by one step of environment machine Pulses
Copyright 8
Further Constraints on SluiceGateCtl Runs
Typically domain knowledge and/or the requirements impose further
constraints on SluiceGateCtl runs to restrict the operator’s
freedom to issue commands, since not each cmd sequence may be
possible, reasonable and desirable.
Exl:
on cmds are ignored when the machine is already moving, off cmds
when the gate is fully closed
clockwise/anticlockwise cmds are ignored when the machine is already
moving in the respective direction
These matters are discussed below for the variant
OperatedSluiceGate (called occasional sluice gate control in
op.cit.). This will also illustrate reusing ASMs.
Copyright 9
Specifying an Operated Sluice Gate Control
An Illustration of Reusing ASMs
We will reuse
the ASMs developed for the Sluice Gate Control
– the ground model SluiceGateGround
– the refinement steps introducing
• the equipment (motor and sensors in SluiceGateMotorCtl)
• its connection to the machine (pulse and sensor status lines in
SluiceGateCtl)
the formulation of the domain knowledge (assumptions) needed for an
argument to establish the correctness of failure free normal behavior
– of the ground model wrt the user requirements
– of the refinements wrt the ground model
Copyright 10
Operated Sluice Gate Control Problem Description (p.90/91)
A small sluice, with a rising and falling gate, is used in a simple
irrigation system. A computer system is needed to raise and lower
the sluice gate in response to the commands of an operator .
The gate is opened and closed by rotating vertical screws. The
screws are driven by a small motor, which can be controlled by
clockwise, anticlockwise, on and off pulses.
There are sensors at the top and bottom of the gate travel; at the
top it’s fully open, at the bottom it’s fully shut.
The connection to the computer consists of four pulse lines for motor
control, two status lines for the gate sensors, and a status line for
each class of operator command.
...the operator can position the gate as desired by issuing Raise,
Lower and Stop commands: the machine should respond to a Raise
by putting the gate & motor into a Rising state, and so on...The
Rising and Falling states are mutually exclusive...
Copyright 11
Reusing SluiceGateGround for OperatedSluiceGtGd
OperatedSluiceGtGd & its refinements can be defined reusing
SluiceGateGround
components of SluiceGateMotorCtl and SluiceGateCtl
Pulses
& extending description technique for monitored sensor values to the
new kind of to-be-monitored input coming through cmd status lines.
OperatedSluiceGtGd is a variation of SluiceGateGround
obtained through
replacing the time events Passed (...Period ) by command and sensor
events
renaming the target entering abstract (read: skip) actions Open,
Shut to Raise, Lower
adding the target entering abstract (read: skip) action Stop
The Assumption on Monitored Locations is carried over without change
Copyright 12
Capturing User Requirements by OPERATEDSLUICEGTGD
Rising
RAISE
Event(Stop)
Or
Event(Top)
Event
(Raise)
STOP
Stopped
Event(Stop)
Or
Event(Bottom)
Event
(Lower)
Falling
Copyright LOWER
13
Refining OperatedSluiceGtGd by Motor Actions & Pulses
Reuse SluiceGateMotorCtl components to address mot acts
OperatedSluiceGtMotCtl =
OperatedSluiceGtGd where
Raise = StartToRaise
Lower = StartToLower
Stop = StopMotor
Reuse
– the pulse refinement of StartToRaise, StartToLower,
StopMotor to refine OperatedSluiceGtMotCtl to
OperatedSluiceGtCtl
– reuse Pulses to combine it with OperatedSluiceGtCtl to
OperatedSluiceGt
Assumption on cmd values: command status line value cmd makes
Event(cmd ) true in OperatedSluiceGtMotCtl and
OperatedSluiceGtCtl for each command cmd .
Copyright 14
How to Discipline Operator Commands
Fact: Some cmd sequences may be impossible to realize, or not be
reasonable or not be desired.
Problem: How to discipline cmd issuing and prevent the machine to
obey to some in a given context undesired but issued cmd.
In a math model one can always constrain runs to exclude certain cmd
sequences. In real-life, one can issue operating instructions, but one
cannot rely upon such instructions being followed always perfectly.
Event classification (‘Reasons for disobedience’ p.112)
– not sensible cmd: ‘makes no sense in the context of preceding cmds’
– not viable cmd: ‘inappropriate or impermissible in the current state’
– not overrunnable cmd: the response to the cmd has to be finished
before other cmds come in (Ch.9.2 on ‘overrun concern’ due to
mismatch of speeds bw triggering an action and its exec)
• to be resolved by inhibition, ignoring or buffering events that occur
when the machine is not ready to participate in them
Copyright 15
Illustrating Cmd Sequence Constraints
Define all not sensible or not viable cmd sequences, e.g. by a table or a
finite state machine graph (here complementing the control state
diagram used to define OperatedSluiceGtCtl):
no two or more cmds are issued simultaneously
say only sequences of pairs Raise, Stop or Lower , Stop are sensible.
Then in any cmd sequence where one of the following pairs occurs, the
second cmd has to be rejected as insensible:
– Raise, Lower (possibly not viable for physical reasons)
– Raise, Raise (includes no Raise when at top: not viable)
– Lower, Raise (possibly not viable for physical reasons)
– Lower, Lower (includes no Lower when at bottom: not viable)
– Stop, Stop (no Stop when Stopped: NB that both the operator and
the machine can trigger Stop)
Copyright 16
How to Realize Cmd Constraints in the Machine Spec
Detect issued cmds and
ignore sensible cmds that are not viable (possibly notify their
occurence).
For example the following rule have the effect to simply consume a
Stop cmd occurring in the top position without changing the state
(except for the notification):
if phase = Stopped and At(Top) and Event(Stop) then
skip
Notify(Stop at Top)
ignore cmds that are not sensible (possibly notify their occurence)
Exl:
if phase = Rising and Event(Raise) then
skip
Notify(Raise when Rising)
Copyright 17
References
M. Jackson: Problem Frames. Addison-Wesley 2001
C. A. Gunter, E. L. Gunter, M. Jackson, P. Zave: A Reference Model
For Requirements and Specifications. IEEE Software, May/June 2000
Copyright 18

M. Jackson: Problem Frames Two Sluice Gate Control Examples

Transcript

Documenti analoghi

Elementary Affine Logic and the Call by Value Lambda Calculus

Of Tongues, Trunks and Tentacles, Muscular Hydrostats and Soft

Where we are

Michele Lanzo

Scuola di Ingegneria UNIBAS - Università degli Studi della Basilicata

Summer School - Researchitaly

A reinterpretation of the definition of slice

Microsoft PowerPoint - DP-L03-DesignPrinciples2015.ppt

The Bulb in partnership with Gestionali in Opera

2013-03-21 CV Donato Mazzeo Ita