Timing Tolerances in Safety-Critical

Software

Alan Wassyng, Mark Lawford, Xiayong Hu

FM 2005

Software Quality Research LaboratoryMcMaster University

2

Introduction

Built on definitions and analysis developed at Ontario Power Generation for safety-critical software applications in the nuclear power industry.

Need to describe timing behaviour that includes tolerances in time durations.

Need to describe timing tolerances that allow deviations from ideal behaviour specified by typical requirements models.

3

Example To filter noisy signals we may specify that a sensor signal

above its setpoint (the event) sustained for 300 ms causes a “trip”.

If the event is sustained for less than 300 ms, the trip must not occur.

Similarly, if the event is sustained for 300 ms or longer, the trip must be generated.

Without tolerances on the time duration, these requirements would be impossible to meet, so the duration may be specified as 300±50 ms for instance.

Introduction

4

Implementations of example specification.

Informal spec:

Trip if m_signal is above setpoint for 300±50 ms.

Introduction

5

Model & Notation

Model: Finite State Machine, discrete time with arbitrarily

small clock-tick. Stimuli monitored variables. Responses controlled variables. C(t) - vector of values of controlled variables at time t. M(t) - vector of values of monitored variables at time t. S(t) - vector of values of state variables at time t. C(tk) R(M(tk), S(tk))

S(tk+1) NST(M(tk), S(tk))

where t0 is time of initialisation, t = tk+1 - tk

k = 0,1,2,…

6

Notation: tnow represents current time.

variable-n is value of variable n clock-ticks ago. We use tabular expressions wherever possible:

Model &

Notation

=

f_name

Condition1 result1 Condition2 result2

. . . . . . Conditionn resultn

if Condition1 then f_name = result1 else if Condition2 then f_name = result2 else if . . . then . . . else if Conditionn then f_name = resultn

7

Definitions

(Condition) Held for (d, L, R) (Infix operator)duration defined by constant d (>0), with tolerances -L, +R (0 ≤ L < d, 0 ≤ R)

8

Formal definition of “Held for”

Definitions

(Condition: bool) Held for (d: RR >0, L, R: RR ≥0): bool durat (ion Condit :ion bool): [d- , +L d R]

_Eventstart_time(Condit :ion ):bool RR ≥0 Initially: duration = any va lue in [d- , +L d R]; Event_star _t time-1 = 0; Condition-1 = False

duration Event_start_time

(Condition = Tru )e & (Condition-1 = False) Any value in [d- , L d+ ]R tnow

(Condition = False) or (Condition-1 = Tru )e No Change No Change

Held for

tnow – Ev _entstar _t time ≥ duration True = Condition True tnow – Ev _entstar _t time < duration False

= Condition False False

9

Periodic(Condition, d, L, R)

Definitions

10

Formal definition of “Periodic”

Definitions

Periodic(Condition: bool, d: RR >0, L, R: RR ≥0): bool period(Periodic-1: bool): [d- , +L d R] previou _s puls _e tim (e Condi :tion bool): RR ≥0 Initially: =period any value in [0, ]; R prev _ious puls _e time-1 = 0; Periodic-1 = False

period

Periodic-1 = True Any value i n [d- , +L d R] Periodic-1 = False No Change

Periodic _ _previous pulse time

Condition-1 = False True tnow tnow ≥ previou _s pu _lse time-1

+ period True tnow Condition

= True Condition-1 = True tnow < previous_pu _lse time-1

+ period False No Change

Condition = False False No Change

11

SyncPeriodic(d, L, R)

Definitions

12

Formal definition of “SyncPeriodic”

Definitions

SyncPeriodic (d: RR >0, L, R: RR ≥0): bool n: NN : RR

Initially: n = 0 = any value in [0, ]R SyncPeriodic-1 = False

n

SyncPeriodic-1 = True Any value i n [- L, ]R n+1 SyncPeriodic-1 = False No Change No Change

SyncPeriodic

tnow ≥ n ï d + True tnow < n ï d + False

13

Functional Timing Requirements

Functional timing requirements are timing requirements that are directly related to the required behaviour of the application. So, “Held for”, “Periodic” and “SyncPeriodic” are

examples of templates describing functional timing requirements.

Other common functional timing requirements can be modeled in similar fashion.

These requirements are interpreted within the constraints of the governing model, in our case the discrete time FSM with arbitrarily small clock-tick. This describes idealised behaviour with the capability of including tolerances on all timing durations.

14

Performance Timing Requirements

Idealised behaviour totally ignores the fact that an implementation cannot continuously monitor sensor values and requires a finite, non-zero amount of time to process its results.

To complete the description of the required behaviour, a requirements document must also specify the performance tolerances that are allowed in meeting functional timing requirements.

We identify two different performance timing requirements. Timing Resolution Response Allowance

15

Timing Resolution

PTRs

16

Response Allowance The Response Allowance (RA) for a controlled-monitored

variable pair specifies an allowable processing delay. Each controlled variable must have an RA specified for it. The

RA applies to the controlled variable and the particular monitored variable on which the controlled variable’s behaviour depends.

The RA is measured from the time the event actually occurred in the physical domain, until the time the value of the controlled variable is generated and crosses the application boundary into the physical domain.

The RA for the pair c-m is meaningless if c does not change its value in response to a change in the value of m (the effect must be visible externally).

The time sequence of externally generated values of a controlled variable c cannot be altered by consideration of the RAs for each c-m pair.

PTRs

17

PTRs

18

PTRs

NO!

19

Interaction Between FTRs & PTRs

Timing resolution & sustained events( j: tsj TR )

20

Interaction

ts_min tsj ts_max for each j {0..n}

Need at least 2 samples inthis intervalto ensure decision basedon value inthis interval

21

Interaction

0 < ts_max (L + R) / 2 implementable(L + R) < ts_max not implementable

Need at least 2 samples inthis intervalto ensure decision basedon value inthis interval

22

Interaction

(L + R) / 2 < ts_max (L + R):

kmin = int((d - L) / ts_max); kmax = int((d - L) / ts_min)

kmin kmax kmax ts_min d - L & kmax ts_max > d - L

k | tsj = d - L - ( arbitrarily small > 0)

not implementable.

k = kmin = kmax tsj d - L

tsj > d - L

So, if (k + 2) ts_max d + R

then it is implementable.

k

j=1

j=1

k

j=1

k+1and

23

Interaction

Analysis applied to examples.

The tolerances on the sample intervals are shown in paren-theses.

As we would expect, jitter in the sample interval makes it more difficult to implement the requirement.

24

Interaction

Analysis applied to examples.

The tolerances on the sample intervals are shown in paren-theses.

Longer durations are more difficult to implement.

25

Interaction

Response allowance with sustained events Two cases to consider:

Event ends before it is sustained.• Easy to deal with. The usual ra is applied.

Event is successfully sustained.• Not so easy. Apply ra for the unsuccessful case in addition to

the maximum duration of the sustained event, i.e. d + R.

Example: ra is 250 ms, event must be sustained for k_delay ms, k_delay in [400-40, 400+25] ms.

Response allowance is 675 ms if sustained, 250 ms if not.

We write it as

675 ms Held for (k_delay) / 250 ms.

26

Conclusion

We have separated functional and performance timing requirements.

We have provided example definitions for specific functional timing requirements, and the definitions include the effects of tolerances.

We have also analysed specific interactions between functional and performance timing requirements.

27

So - why do we think this is useful? The definitions are precise and practical. They allow behaviours

that agree with our intuitive concepts but can be used to adjudicate objectively in cases where we have a “discussion” between verifiers and developers.

The advantage of having formal definitions and analyses that deal with tolerances is that we can now develop tools that will help automate scheduling and verification of timing requirements.

The analysis is simple yet effective. We do not have to force TRs to be less than (L + R) /2. We can find implementable sampling intervals in the range ( (L + R) /2, (L + R) ), and we have shown that minimising jitter in the sampling intervals is really worth while. Even small jitter can result in not being able to implement a requirement unless we have the maximum sampling interval less than (L + R) /2.

Conclusion

28

Future work Complete formalisation of timing requirements and their

implementation using PVS. Currently partially completed, including confirmation of the analysis presented earlier.

Analysis of effect of TRs and RAs on intermediate functions in the requirements decomposition.

Conclusion

29

Thanks - see you at FM’06 at McMaster University, Canada