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