using domain models to specify systems
DESCRIPTION
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. Using Domain Models to Specify Systems. Overview. In order to specify a control system one needs - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/1.jpg)
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
![Page 2: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/2.jpg)
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
![Page 3: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/3.jpg)
REFT 2005-07-19 3
Approach
specify overall system
derive spec of control system
rely
![Page 4: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/4.jpg)
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
![Page 5: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/5.jpg)
REFT 2005-07-19 5
Sluice gate equipment
bot: Bool
top: Bool
dir: up | downmotor: on | off
pos: Height
![Page 6: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/6.jpg)
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)
![Page 7: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/7.jpg)
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
![Page 8: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/8.jpg)
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?
![Page 9: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/9.jpg)
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!
![Page 10: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/10.jpg)
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))
![Page 11: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/11.jpg)
REFT 2005-07-19 11
Ideal motor assumptions
motor = on dir = up motor = off
pos = open
≥ 1min
I J
![Page 12: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/12.jpg)
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)
...
![Page 13: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/13.jpg)
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
![Page 14: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/14.jpg)
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
![Page 15: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/15.jpg)
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)
...
![Page 16: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/16.jpg)
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
![Page 17: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/17.jpg)
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
![Page 18: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/18.jpg)
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
![Page 19: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/19.jpg)
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
![Page 20: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/20.jpg)
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)
![Page 21: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/21.jpg)
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”
![Page 22: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/22.jpg)
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)
![Page 23: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/23.jpg)
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
![Page 24: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/24.jpg)
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?
![Page 25: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/25.jpg)
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• . . .
![Page 26: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/26.jpg)
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
![Page 27: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/27.jpg)
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
![Page 28: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/28.jpg)
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
![Page 29: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/29.jpg)
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
![Page 30: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/30.jpg)
REFT 2005-07-19 31
Conclusion (2)
In specification decouple
• required behaviour of overall system
• assumptions about equipment
• constraints on how equipment is controlled
![Page 31: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/31.jpg)
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?
![Page 32: Using Domain Models to Specify Systems](https://reader036.vdocument.in/reader036/viewer/2022062309/56814e54550346895dbbe6eb/html5/thumbnails/32.jpg)
REFT 2005-07-19 33
Thanks for listening