Some examples of
Download
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
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 control system

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) control systemHayes/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 control system B

r: S x S  B

g: S x S  B

q: S x S  B


Sluicegatesystem requirements
SluiceGateSystem requirements control system

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 control system

  • 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 control system

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 control system

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 control system

  • 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 system

Control

input top, bot: Bool

output motor: {on, off}

dirn: {up, dn}

rely guar-sensor  guar-motor

guar guar-SGS  rely-motor


Notice
Notice control system

  • 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? control 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 control system

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 control system

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 control system

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” control system

  • widely used challenge example

    • what is the specification?

    • what are the assumptions abut equipment?


Deposit Belt control system

Robot

Crane

Press

Arm 1

Arm 2

Feed Belt

Elevating

Rotary Table


Specifications sans z of operations check with davec
Specifications (sans Z) of operations control systemcheck 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 control system

  • 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 control system

  • 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 control system

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


Joey s list s
Joey’s list(s) control system


Hayes jackson jones deriving specifications1
Hayes/Jackson/Jones control systemDeriving specifications

  • decide bounds of specification

  • expose the assumptions (with rely conditions)

    • not specify universe

specify overall system

derivespec of control system

rely


ad