Using Domain Models to Specify Systems
description
Transcript of Using Domain Models to Specify Systems
REFT 2005-07-19 1
Ian HayesSystems and Software Eng. Div.,
School of ITEE &ARC Centre for Complex Systems,
University of Queenslandwork with
Michael Jackson, LondonCliff Jones, University of
Newcastle
Using Domain Models to
Specify Systems
REFT 2005-07-19 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
REFT 2005-07-19 3
Approach
specify overall system
derive spec of control system
rely
REFT 2005-07-19 4
Domain Model*
The model should be adequate to specify:
1. The overall system’s required behaviour
2. The assumptions the machine can rely on
about the equipment’s (normal) behaviour
3. The constraints on the way the equipment
may be controlled via its interface.
* Not quite the same as used by Dines
REFT 2005-07-19 5
Sluice gate equipment
bot: Bool
top: Bool
dir: up | downmotor: on | off
pos: Height
REFT 2005-07-19 6
Control GSM requirementb a
a: {pos: Height}
b: Control ! {dir: up | down, motor: on | off} GSM ! {top: Bool, bot: Bool}
An initial decomposition(Gate/Sensors/Motor)
REFT 2005-07-19 7
Height = open | closed | neither
var pos: Height
pos is modelled by its trace (a function) over time
(cf. Brendan Mahony)
Getting the overall requirements
REFT 2005-07-19 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?
REFT 2005-07-19 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!
REFT 2005-07-19 10
The Environment
Ideal 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))
REFT 2005-07-19 11
Ideal motor assumptions
motor = on dir = up motor = off
pos = open
≥ 1min
I J
REFT 2005-07-19 12
Ideal motor assumptions
Motor
input motor: on | off, dir: up | downoutput 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)
...
REFT 2005-07-19 13
First try at specifying control
Control
input top, bot: Bool
output motor: on | off dir: up | downrely guar-Sensor guar-Motor
guar guar-SGS
REFT 2005-07-19 14
Check equipment manuals
• don’t reverse the motor whilst running
– add to rely-motor
– therefore add to guar-control
• turn the motor off when at top or bottom
REFT 2005-07-19 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
don’t 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)
...
REFT 2005-07-19 16
Ideal motor assumptions
Turn off at openmotor = on dir = up pos = open
#I ≤ motor limit
I
I: Interval
(motor = on dir = up pos = open) over I #I ≤ motor limit
REFT 2005-07-19 17
Ideal motor assumptions
Off while switchingmotor = on dir = up
motor = on dir = down
#K ≥ switch_time
I J
motor = offK
E
REFT 2005-07-19 19
Second try at specifying Control
Control
input top, bot: Bool
output motor: on | off dir: up | downrely guar-sensor guar-motor
guar guar-SGS rely-motor
REFT 2005-07-19 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
REFT 2005-07-19 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)
REFT 2005-07-19 22
Coping with Errors
• 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
“Hazard analysis”
REFT 2005-07-19 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)
REFT 2005-07-19 24
Perceiving errors through sensors
• what if pos doesn’t 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
REFT 2005-07-19 25
Some conclusions
• can’t 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?
REFT 2005-07-19 26
Perceivable Faults
Detectable 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• . . .
REFT 2005-07-19 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
REFT 2005-07-19 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
REFT 2005-07-19 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
REFT 2005-07-19 30
Conclusion (1)
• message
– decide bounds of specification
– expose the assumptions (with rely conditions)
• not specify universe
specify overall system
derive spec of
control system
rely
REFT 2005-07-19 31
Conclusion (2)
In specification decouple
• required behaviour of overall system
• assumptions about equipment
• constraints on how equipment is controlled
REFT 2005-07-19 32
Conclusion (3)
For fault tolerance decouple specification of
• equipment faults (transient/hard)
– perceivable?
• allowed response
• healthiness checks
Can we decouple in implementation?
REFT 2005-07-19 33
Thanks for listening