320 likes | 419 Views
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
E N D
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 • a model of the domain being controlled • including its interface to the controlling machine
specify overall system derive spec of control system rely Approach
Domain Model* The model should be adequate to specify: • The overall system’s required behaviour • The assumptions the machine can rely on about the equipment’s (normal) behaviour • The constraints on the way the equipment may be controlled via its interface. * Not quite the same as used by Dines
Sluice gate equipment top: Bool pos: Height bot: Bool dir: up | down motor: on | off
requirement 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}
Getting the overall requirements Height = open | closed | neither var pos: Height pos is modelled by its trace (a function) over time (cf. Brendan Mahony)
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?
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!
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))
Ideal motor assumptions ≥1min motor = on dir = up motor = off I J pos = open
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) ...
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
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
“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) ...
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
Ideal motor assumptionsOff while switching motor = on dir = up motor = on dir = down I J E K motor = off #K ≥switch_time
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
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
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)
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
Responses to Faults One needs to be able to specify allowable responses to faults • typically as alternative behaviours • this weakens the required behaviour (1)
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
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?
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 • . . .
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 havereacted to shut down the motor and raise the alarm already • hard fault occurred fault reported
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
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
specify overall system derive spec of control system rely Conclusion (1) • message • decide bounds of specification • expose the assumptions (with rely conditions) • not specify universe
Conclusion (2) In specification decouple • required behaviour of overall system • assumptions about equipment • constraints on how equipment is controlled
Conclusion (3) For fault tolerance decouple specification of • equipment faults (transient/hard) • perceivable? • allowed response • healthiness checks Can we decouple in implementation?