260 likes | 347 Views
Some examples of Determining the Specification of a Control Systems from that of its Environment Joey Coleman Cliff Jones. Hayes/Jackson/Jones Deriving specifications. decide bounds of specification expose the assumptions (with rely conditions) not specify universe. specify overall system.
E N D
Some examples of Determining the Specification of a Control Systems from that of its EnvironmentJoey ColemanCliff Jones
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
Quick intro: Sluice Gate example[FM-03 paper];currently writing journal version top: Bool pos: Height bot: Bool dir: up | down motor: on | off
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!
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}
(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
p: S B r: S x S B g: S x S B q: S x S B …
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?
Process • have “wider” specification; • next we • make assumptions on (ideal) sensors • guar-Sensor • make assumptions on (ideal) motor • guar-Motor
Ideal sensor assumptions Sensor input pos: Height output top, bot: Bool guar (pos = open top) over Time (pos = closed bot) over Time
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) ...
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 Control input top, bot: Bool output motor: {on, off} dirn: {up, dn} rely guar-sensor guar-motor guar 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? + probabilities!
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”
Simple example rather 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 actual rely 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 Robot Crane Press Arm 1 Arm 2 Feed Belt 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)
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
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