Download
1 / 29
290 likes | 437 Views
Alan Wassyng, Mark Lawford, Xiayong Hu. Software Quality Research Laboratory McMaster University. Timing Tolerances in Safety-Critical Software. FM 2005. Introduction.
E N D
Alan Wassyng, Mark Lawford, Xiayong Hu Software Quality Research Laboratory McMaster University Timing Tolerances in Safety-Critical Software FM 2005
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.
Introduction 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 Implementations of example specification. Informal spec: Trip if m_signal is above setpoint for 300±50 ms.
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,…
Model & Notation • Notation: • tnow represents current time. • variable-n is value of variable n clock-ticks ago. • We use tabular expressions wherever possible: =
Definitions • (Condition) Held for (d, L, R)(Infix operator) duration defined by constant d (>0), with tolerances -L, +R (0 ≤ L < d, 0 ≤ R)
Definitions • Formal definition of “Held for”
Definitions • Periodic(Condition, d, L, R)
Definitions • Formal definition of “Periodic”
Definitions • SyncPeriodic(d, L, R)
Definitions • Formal definition of “SyncPeriodic”
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.
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
PTRs • Timing Resolution
PTRs • 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 NO!
Interaction Between FTRs & PTRs • Timing resolution & sustained events ( j: tsj TR )
Interaction ts_min tsj ts_max for each j {0..n} Need at least 2 samples in this interval to ensure decision based on value in this interval
Interaction 0 < ts_max (L + R) / 2 implementable (L + R) < ts_max not implementable Need at least 2 samples in this interval to ensure decision based on value in this interval
Interaction 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. (L + R) / 2 < ts_max (L + R): k j=1 k j=1 and k+1 j=1
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.
Interaction Analysis applied to examples. The tolerances on the sample intervals are shown in paren-theses. Longer durations are more difficult to implement.
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.
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.
Conclusion • 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 • 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.
