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


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


Quick intro: Sluice Gate example[FM-03 paper]; currently writing journal version

bot: Bool

top: Bool

dir: up | downmotor: on | off

pos: Height


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;...


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


(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


g: S x S B

q: S

x S

B

r: S x S B

p: S B

…


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?


Process

• have “wider” specification;• next we

– make assumptions on (ideal) sensors• guar-Sensor

– make assumptions on (ideal) motor• guar-Motor


Ideal sensor assumptions

Sensorinput pos: Heightoutput top, bot: Boolguar (pos = open top) over Time

(pos = closed bot) over Time


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)

...


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


Specifying control with ideal components

Controlinput top, bot: Booloutput motor: {on, off} dirn: {up, dn}rely guar-sensor guar-motorguar guar-SGS rely-motor


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


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?


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


Simple examplerather than

(reading (max error)) corrective action

write(actual max) corrective action

rely: | reading actual | error

“make it yell at you!”


example: TMR

instead of saying control system takes majority of readingi

specify system in terms of actualrely

readingi = readingj i j

| readingi actual | error


Karlsruhe “Production Cell”

• widely used challenge example– what is the specification?– what are the assumptions abut equipment?


Deposit Belt

Feed Belt

PressCrane

Arm 1 Arm 2

Robot

Elevating Rotary Table


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


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


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)


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


rely


Joey’s list(s)


Hayes/Jackson/JonesDeriving specifications

• decide bounds of specification• expose the assumptions (with rely conditions)

– not specify universespecify overall system


rely

hayes/jackson/jones deriving specifications

Documents