slide1
Download
Skip this Video
Download Presentation
Hayes/Jackson/Jones Deriving specifications

Loading in 2 Seconds...

play fullscreen
1 / 26

Hayes/Jackson/Jones Deriving specifications - PowerPoint PPT Presentation


  • 61 Views
  • Uploaded on

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.

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

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


An Image/Link below is provided (as is) to download presentation

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
slide1
Some examples of Determining the Specification of a Control Systems from that of its EnvironmentJoey ColemanCliff Jones
hayes jackson jones deriving specifications
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
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
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!

bringing together 3 ideas i jackson s problem frame diagrams

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
(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

slide7

p: S  B

r: S x S  B

g: S x S  B

q: S x S  B

sluicegatesystem requirements
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
Process
  • have “wider” specification;
  • next we
    • make assumptions on (ideal) sensors
      • guar-Sensor
    • make assumptions on (ideal) motor
      • guar-Motor
ideal sensor assumptions
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
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
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
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
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
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!

faults as interference

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
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
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
Karlsruhe “Production Cell”
  • widely used challenge example
    • what is the specification?
    • what are the assumptions abut equipment?
slide20

Deposit Belt

Robot

Crane

Press

Arm 1

Arm 2

Feed Belt

Elevating

Rotary Table

specifications sans z of operations check with davec
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
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
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

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 jones deriving specifications1
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

ad