Hayes/Jackson/Jones Deriving specifications

1 / 26

Hayes/Jackson/Jones Deriving specifications - PowerPoint PPT Presentation

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

PowerPoint Slideshow about ' Hayes/Jackson/Jones Deriving specifications' - nevina

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

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

control system takes majority of readingi

specify system in terms of actual

rely

| 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