Hayes/Jackson/Jones Deriving specifications

1. Some examples of Determining the Specification of a Control Systems from that of its EnvironmentJoey ColemanCliff Jones

2. Hayes/Jackson/JonesDeriving specifications • decide bounds of specification • expose the assumptions (with rely conditions) • not specify universe specify overall system derivespec of control system rely

3. Quick intro: Sluice Gate example[FM-03 paper];currently writing journal version top: Bool pos: Height bot: Bool dir: up | down motor: on | off

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 = off wait 9min; ... No!

5. requirement Bringing together 3 ideas (i):Jackson’s problem frame diagrams b a control GSM GSM = Gate/Sensors/Motor a: {pos: Height} b: control ! {dir: up | down, motor: on | off} GSM ! {top: Bool, bot: Bool}

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

7. p: S  B r: S x S  B g: S x S  B q: S x S  B …

8. SluiceGateSystem requirements SGS output pos: Height guar  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?

9. Process • have “wider” specification; • next we • make assumptions on (ideal) sensors • guar-Sensor • make assumptions on (ideal) motor • guar-Motor

10. Ideal sensor assumptions Sensor input pos: Height output top, bot: Bool guar (pos = open  top) over Time  (pos = closed  bot) over Time

11. Ideal motor assumptions Motor input motor: on | off, dir: up | down output pos: Height guar  I, J: Interval  #I  1min  (motor = on  dir = up) over I   (motor = off) over J ((pos = open ) over J)  ...

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

13. Specifying control with ideal components Control input top, bot: Bool output motor: {on, off} dirn: {up, dn} rely guar-sensor  guar-motor guar guar-SGS  rely-motor

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

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? + probabilities!

16. specify overall derive spec of control system rely Faults as “interference” • some examples of mechanical faults • Sluice Gate • Jackson’s traffic lights • Ravn’s “Gas Burner” • Karlsruhe “Production Cell”

17. Simple example rather than (reading ³ (max - error)) Þ corrective action write (actual ³ max) Þcorrective action rely: | reading - actual | £ error • “make it yell at you!”

18. example: TMR instead of saying control system takes majority of readingi specify system in terms of actual rely readingi = readingjÙ i ¹ j Þ | readingi- actual | £ error

19. Karlsruhe “Production Cell” • widely used challenge example • what is the specification? • what are the assumptions abut equipment?

20. Deposit Belt Robot Crane Press Arm 1 Arm 2 Feed Belt Elevating Rotary Table

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

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

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)

24. specify overall derive spec of control system rely 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

25. Joey’s list(s)

26. Hayes/Jackson/JonesDeriving specifications • decide bounds of specification • expose the assumptions (with rely conditions) • not specify universe specify overall system derivespec of control system rely