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