Hayes/Jackson/Jones Deriving specifications
description
Transcript of Hayes/Jackson/Jones Deriving specifications
REFT Workshop 2005-07-19 1
Some examples of Determining the Specification of a Control
Systems from that of its Environment
Joey ColemanCliff Jones
REFT Workshop 2005-07-19 2
Hayes/Jackson/JonesDeriving specifications
• decide bounds of specification• expose the assumptions (with rely conditions)
– not specify universespecify overall system
derive spec of control system
rely
REFT Workshop 2005-07-19 3
Quick intro: Sluice Gate example[FM-03 paper]; currently writing journal version
bot: Bool
top: Bool
dir: up | downmotor: on | off
pos: Height
REFT Workshop 2005-07-19 4
Contrast with: guessing a “specification” for the control system
Do we want (yet) a specification of control like:wait 49min;set dir = up;motor = on;until top do …motor = offwait 9min;...
REFT Workshop 2005-07-19 5
control GSM requirementb a
GSM = Gate/Sensors/Motor
a: {pos: Height}
b: control ! {dir: up | down, motor: on | off} GSM ! {top: Bool, bot: Bool}
Bringing together 3 ideas (i):Jackson’s problem frame diagrams
REFT Workshop 2005-07-19 6
(ii) Hayes/Mahony notation
I: Interval #I 10hr I (pos = open) / I (pos = closed) {x | 1/7 x 1/5}
pos is modelled by its trace over time
REFT Workshop 2005-07-19 7
g: S x S B
q: S
x S
B
r: S x S B
p: S B
…
REFT Workshop 2005-07-19 8
SluiceGateSystem requirementsSGSoutput pos: Heightguar I: Interval
#I 10hr I (pos = open) / I (pos = closed) {x | 1/7 x 1/5}
could add: “no period longer than an hour without 5 mins open” “open and close no more than twice per hour”
but above will serve to illustrate most points
Question: is this satisfiable? is it flexible enough?
REFT Workshop 2005-07-19 9
Process
• have “wider” specification;• next we
– make assumptions on (ideal) sensors• guar-Sensor
– make assumptions on (ideal) motor• guar-Motor
REFT Workshop 2005-07-19 10
Ideal sensor assumptions
Sensorinput pos: Heightoutput top, bot: Boolguar (pos = open top) over Time
(pos = closed bot) over Time
REFT Workshop 2005-07-19 11
Ideal motor assumptions
Motorinput motor: on | off, dir: up | downoutput pos: Heightguar I, J: Interval
#I 1min (motor = on dir = up) over I
(motor = off) over J ((pos = open ) over J)
...
REFT Workshop 2005-07-19 12
So, we
• make assumptions on ideal sensors– guar-sensor
• make assumptions on ideal motor– guar-motor
• check the manual!– need to make sure not reversed whilst driving
• gives assm-motor
REFT Workshop 2005-07-19 13
Specifying control with ideal components
Controlinput top, bot: Booloutput motor: {on, off} dirn: {up, dn}rely guar-sensor guar-motorguar guar-SGS rely-motor
REFT Workshop 2005-07-19 14
Notice
• we have not – (yet) had to model details of the equipment– control might be linked to Alberich/Nibelungs– or a simulator
• we have – a proper decomposition– left clear assumptions
• for the person who decides whether to deploy the control system in a given environment
• insulation weaker for fault tolerance
REFT Workshop 2005-07-19 15
Question: scope of system?
• position of the gate• flow of water
– rely on level• growth of crops
– rely on weather• profit
– rely on CAP• contentment
– Tao?
REFT Workshop 2005-07-19 16
Faults as “interference”
• some examples of mechanical faults– Sluice Gate– Jackson’s traffic lights– Ravn’s “Gas Burner”– Karlsruhe “Production Cell”
specify overall
derive spec ofcontrol system
rely
REFT Workshop 2005-07-19 17
Simple examplerather than
(reading (max error)) corrective action
write(actual max) corrective action
rely: | reading actual | error
“make it yell at you!”
REFT Workshop 2005-07-19 18
example: TMR
instead of saying control system takes majority of readingi
specify system in terms of actualrely
readingi = readingj i j
| readingi actual | error
REFT Workshop 2005-07-19 19
Karlsruhe “Production Cell”
• widely used challenge example– what is the specification?– what are the assumptions abut equipment?
REFT Workshop 2005-07-19 20
Deposit Belt
Feed Belt
PressCrane
Arm 1 Arm 2
Robot
Elevating Rotary Table
REFT Workshop 2005-07-19 21
Specifications (sans Z) of operationscheck with DaveC
• “initially both arms are retracted and unloaded”• “robot must not rotate if arm extended”• “robot’s rotation does not change extension
status”• “to extend, robot must be at location …”• “arm 1 operations do not affect arm 2”• …• concern: pre-/post-condition merge
REFT Workshop 2005-07-19 22
Failures as interference
• question: separation of logical/stochastic• problem (cf. ISAT)
– difference in levels of abstraction• specification• knowledge of devices to be used
– but• assumptions (pre, rely) pinpoint messy interfaces• layers are necessary to design tractable systems
REFT Workshop 2005-07-19 23
Jackson’s traffic lights
• specification of computer system (“machine”)– send (red) signal
• Jackson addresses wider system (“environment”)– wiring– initial state
• inv: ¬ (lighta = green lightb = green)rely: signali(red) lighti = red
• or even wider– requirement: probability of accident (never zero)– rely: probability that drivers cross red lights (over time)
REFT Workshop 2005-07-19 24
Gas burner
• Ravn’s specification– time gas on without flame
• widen to say– no explosion– rely on no explosion with
• gas less than n%• gas rate
• not specifying universe• are clarifying risk
specify overall
derive spec of control system
rely
REFT Workshop 2005-07-19 25
Joey’s list(s)
REFT Workshop 2005-07-19 26
Hayes/Jackson/JonesDeriving specifications
• decide bounds of specification• expose the assumptions (with rely conditions)
– not specify universespecify overall system
derive spec of control system
rely