Ian Hayes

1
Using Domain Models to Specify Systems

• Ian Hayes
• Systems and Software Eng. Div., School of ITEE
• ARC Centre for Complex Systems,
• University of Queensland
• work with
• Michael Jackson, London
• Cliff Jones, University of Newcastle

2
Overview

• In order to specify a control system one needs
• a model of the domain being controlled
• including its interface to the controlling
  machine

3
Approach
4
Domain Model

• The model should be adequate to specify
• The overall systems required behaviour
• The assumptions the machine can rely on about the
  equipments (normal) behaviour
• The constraints on the way the equipment may be
  controlled via its interface.
• Not quite the same as used by Dines

5
Sluice gate equipment
top Bool
pos Height
bot Bool
dir up down motor on off
6
An initial decomposition(Gate/Sensors/Motor)
b
a
Control
GSM
a pos Height b Control ! dir up down,
motor on off GSM ! top Bool, bot Bool
7
Getting the overall requirements
Height open closed neither var pos
Height pos is modelled by its trace (a function)
over time (cf. Brendan Mahony)
8
SluiceGateSystem requirements
SGS output pos Height guar ? I Interval ? I ?
1hr ? ? I (pos open) ? 8min
? ? I (pos closed) ? 48min could add
open and close no more than 3 times per
hour Question is this satisfiable? Is it
flexible enough?
9
Deriving specification of Control

• (Control GSM) satisfies SGS-requirement
• Do we want (yet) a specification of Control
  like
• delay until start 48min
• dir up
• motor on
• until top do
• motor off
• deadline start 50min
• delay until start 58min
• ...
• No!

10
The EnvironmentIdeal sensor assumptions
Sensor input pos Height output top, bot
Bool guar (pos open ? top) over Time ?
(pos closed ? bot) over Time Shorthand
for (?t Time ? (pos(t) open) ? top(t))
11
Ideal motor assumptions
1min
motor on ? dir up
motor off
I
J
pos open
12
Ideal motor assumptions
Motor input motor on off, dir up
down output pos Height guar ? I, J Interval
? I ? 1min ? I adjoins J ? (motor on ?
dir up) over I ? ? (motor off) over
J ((pos open ) over J)
? ...
13
First try at specifying control
Control input top, bot Bool output motor on
off dir up down rely guar-Sensor
? guar-Motor guar guar-SGS
14
Check equipment manuals

• dont reverse the motor whilst running
• add to rely-motor
• therefore add to guar-control
• turn the motor off when at top or bottom

15
Ideal motor (extended)
Motor input motor on off, dir up down
output pos Height rely turn off motor when
gate becomes open or closed and dont
reverse motor while moving guar ? I, J
Interval ? I ? 1min ? I adjoins J ?
(motor on ? dir up) over I ? ?
(motor off) over J ((pos open )
over J) ? ...
16
Ideal motor assumptionsTurn off at open
motor on ? dir up ? pos open
I
I motor limit

• I Interval ?
• (motor on ? dir up ? pos open) over I
  ?
• I motor limit

17
Ideal motor assumptionsOff while switching
motor on ? dir up
motor on ? dir down
I
J
K
E
motor off
K switch_time
18
Motor off while switching

• I,J Interval ? I precedes J ?
• (motor on ? dir up) over I ?
• (motor on ? dir down) over J
• ? ( K Interval ? K switch_time ?
• I precedes K ? K precedes J ?
• (motor off) over K)

E
19
Second try at specifying Control
Control input top, bot Bool output motor on
off dir up down rely guar-sensor ?
guar-motor guar guar-SGS ? rely-motor
20
Hazardous Behaviour

• Specify hazardous behaviour of the system to
  be avoided
• For the sluice gate example
• Gate open too long flood field
• Gate open too little crops starved of water
• Motor over heating new aspect of domain

21
Misbehaviour

• Specify possible misbehaviour of the domain
• faults or failure modes (completeness?)
• this weakens the assumptions (2)
• To express some faults (e.g., a sensor failing)
  one needs to decouple
• the interface (e.g., sensors top and bot) from
• the domain (e.g., gate position)

22
Coping with Errors
Hazard analysis

• a log becomes jammed under the gate
• a sensor develops an open circuit (fails false)
• a sensor develops a short circuit (fails true)
• the screw mechanism becomes rusty and the gate
  jams
• the screw mechanism breaks, allowing the gate to
  slide
• the motor direction cable is cut
• the motor overheats

23
Responses to Faults

• One needs to be able to specify allowable
  responses to faults
• typically as alternative behaviours
• this weakens the required behaviour (1)

24
Perceiving errors through sensors

• what if pos doesnt change (with motor on ...)
• stop motor in case burns out alarm
• how about open circuit sensor
• stop motor in case burns out alarm
• distinguish from motor jam?
• no, because given equipment limited

25
Some conclusions

• cant distinguish log jammed in gate from sensor
  failing
• so, only one alarm
• either failure must result in alarm and motor
  off
• How to present the error-tolerating specification
  without losing clarity?

26
Perceivable FaultsDetectable via sensors

• top (bot) sensor does not become true/false
  when it should
• top (bot) sensor changes while motor is set off
• top and bot are simultaneously true at any time
• motor too hot sensor becomes true
• . . .

27
Allowed and Banned

• If a (transient/brief) fault occurs the system is
  allowed to react and shut down the motor and
  raise the alarm
• fault reported ? fault occurred
• A hard fault must not occur the system must have
  reacted to shut down the motor and raise the
  alarm already
• hard fault occurred ? fault reported

28
Checking Health

• Specify healthy behaviour of the equipment to
  allow checks to be made on its behaviour
• this should imply the assumptions that the
  controller relies on (2)
• may vary depending on the equipment installed
  (eg, different motor speeds)
• need to decouple in implementation

29
Checking Health of Equipment

• the motor efficiency is reduced by deterioration
  of the bearings
• a log becomes jammed under the gate
• a sensor develops an open circuit (fails false)
• a sensor develops a short circuit (fails true)
• the screw mechanism becomes rusty and the gate
  jams
• the screw mechanism breaks, allowing the gate to
  slide freely
• the motor direction cable is cut
• the motor overheats

30
Conclusion (1)

• message
• decide bounds of specification
• expose the assumptions (with rely conditions)
• not specify universe

31
Conclusion (2)

• In specification decouple
• required behaviour of overall system
• assumptions about equipment
• constraints on how equipment is controlled

32
Conclusion (3)

• For fault tolerance decouple specification of
• equipment faults (transient/hard)
• perceivable?
• allowed response
• healthiness checks
• Can we decouple in implementation?

33
Thanks for listening