1 / 32

Using Domain Models to Specify Systems

This work explores the use of domain models to specify control systems, particularly in a sluice gate scenario. Models must represent the controlled domain and its interface, ensuring clarity on overall behavior, assumptions on normal functionality, and constraints on control mechanisms. By addressing how to handle hazardous and misbehaving systems, as well as coping with errors and specifying responses to faults, we demonstrate approaches to derive effective specifications. Key principles and examples illustrate the necessary rigor and completeness for successful system design and safety.

eze
Download Presentation

Using Domain Models to Specify Systems

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  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. specify overall system derive spec of control system rely Approach

  4. 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

  5. Sluice gate equipment top: Bool pos: Height bot: Bool dir: up | down motor: on | off

  6. 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}

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

  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)  ...

  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 E K motor = off #K ≥switch_time

  18. 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

  19. 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

  20. 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)

  21. 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

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

  23. 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

  24. 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?

  25. 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 • . . .

  26. 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

  27. 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

  28. 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

  29. 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

  30. Conclusion (2) In specification decouple • required behaviour of overall system • assumptions about equipment • constraints on how equipment is controlled

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

  32. Thanks for listening

More Related