2003-04-03
1
A Safety-CriticalSoftware Approachto Hard Real-TimeApplications
Alan Wassyng
2
Safety-Critical Software
Software required for a safetysystemAction initiated (or not initiated)by the software that can leaddirectly to loss of lifeIn the Canadian NuclearIndustry, software that has asafety role is kept separate fromcontrol software
2003-04-03
2
3
Safety-Critical Software
The methodology we are going totalk about is applicable to a widevariety of applications:
Nuclear Generating Station shutdownsystems (the example we will discuss)Embedded applications in auto andavionics industriesEmbedded applications in softwarecontrolled electric motorsWeapons systems ...
4
Safety-Critical SoftwareNGS Shutdown System
Operator'sConsolePlant
T/C"D"
SDS1
SDS2
T/C"E"
T/C"F"
T/C"G"
T/C"H"
T/C"J"
D/T"D"
D/T"E"
D/T"F"
D/T"G"
D/T"H"
D/T"J"
Mon.Comp
Mon.Comp
T/C = Trip Computer
D/T = Display/TestComputer
Mon. Comp = MonitorComputer
2003-04-03
3
5
Safety-Critical SoftwareTarget System - SDS1
6
Safety-CriticalSoftware
An SDS1TripComputer
2003-04-03
4
7
Safety-Critical Software
SDS1 & SDS2: Real-TimeMonitoring & Shutdown
These computer systems have harddeadlines in which they have to detectpotential accident scenarios.They also have hard deadlines inwhich they have to initiate alarms,and, if necessary, initiate shutdown ofthe reactor.
8
Safety-Critical Software
Methodology - SDS1
DID = Design Input DocumentationDIDR = DID Review ReportSRS = Software Requirements
SpecificationSDD = Software Design DescriptionHAR = Hazards Analysis ReportDRR = Design Review ReportDVR = Design Verification ReportCRR = Code Review ReportCVR = Code Verification ReportUTR = Unit Test ReportSWITR = Software Integration Test ReportVTR = Validation Test ReportRQR = Reliability Qualification Report
HAR
HAR
HAR
DID(+SRS)
SDD
CODE
DRR & DVR
CRR & CVR
UTR
SWITR
VTR & RQRDIDR
2003-04-03
5
9
Safety-Critical Software
SDS1Trip Computer Design RequirementsTrip Computer Design DescriptionSoftware Design DescriptionSoftware Design Review - (nd)Software Design VerificationFORTRAN CodeTesting - not going to discuss (nd)Code Review - (nd)Code Verification
10
Safety-Critical Software
Trip Computer DesignRequirements (Mills’ Black-Box)
R = f ( S, Sh )S is the set of stimuli, Sh the set ofstimulus history, R the set of responses
R1
R2
R1-1
R2-1
S1
S2S2-1
S1-1
S3
S2-1
S3-1
System
TCDR
Mills, H.D.: Stepwiserefinement and verificationin box-structured systems.Computer 21 (1988) 23-36
2003-04-03
6
11
Safety-Critical Software
TCDRContext diagramsStimuli & ResponsesConstantsMain function tablesNatural language expressionsTolerances, PTRs and TRsAnticipated changesChanges from previous freezes
TCDR
12
Safety-Critical Software
We expect that all responses aredescribed in terms of stimuli andstimuli history only.It is sometimes advantageous toallow response history to appearin functional descriptions.In deterministic systems,response history is always arepresentation of stimuli history.
TCDR
2003-04-03
7
13
Safety-Critical Software
We refer to stimuli as monitoredvariables, and responses ascontrolled variables.We prefix identifiers by a suitablecharacter followed by _ to helpidentify the role of the identifier.m_ name is a monitored variable,c_name is a controlled variable,k_name is a constant, etc.
TCDR
14
Safety-Critical Software
m_name represents value of thecurrent instance of m_name.m_name-1 represents value of theprevious instance of m_name.If m_name is time-continuous,there’s an arbitrarily small time, δt,between m_name and m_name-1.tnow represents current time.
TCDR
2003-04-03
8
15
Safety-Critical Software
If m_name is time-discrete, timebetween m_name and m_name-1is t(m_name) - t(m_name-1). Ingeneral, t(var) returns time stampof the instance of var.In a real system it will not bepossible to represent R = f(S,Sh)by a single function or functiontable.
TCDR
16
Safety-Critical Software
f_sensortripi, i=1,..,4{For each i = 1,..,4} Result
Condition f_sensortripi
k_setpoint ≤ m_signali
{ith signal is now in the trip region} e_Trip
k_setpoint - k_hysteresis < m_signali < k_setpoint{ith signal is now in the deadband region} No Change
m_signali ≤ k_setpoint - k_hysteresis{ith signal is now in the non-trip region} e_NotTrip
m_signal3
k_setpoint
k_hysteresis
Non-trip region Trip region Non-trip
regionTCDR
2003-04-03
9
17
Safety-CriticalSoftware
TCDR
tm(cond) ismost recenttime condchanged fromFalse to True
time
c_ChanTripe_Trip
e_NotTrip
tk
Manual reset
tm(Manual reset)f_ChanTripTime(tnow) tnow
F
T
Result
Condition f_ChanTripTime[ Manual reset ] NT
[ There is a time tk, tmanualreset < tk ≤ tnow wherec_ChanTrip(tk) = e_Trip ] &
NOT [ There is a time tj, tmanualreset < tj < tk wherec_ChanTrip(tj) = e_Trip ]
{tk is the earliest time at which the channel was trippedafter the most recent manual reset}
tk
NOT [ Manualreset ]
[ NOT (c_ChanTrip(t) = e_Trip) for all t,tmanualreset < t ≤ tnow ]
{No channel trip has occurred since the most recentmanual reset}
NT
where tmanualreset = tm( [ Manual reset ] ), and NT is some representation (in ms) toindicate that there was no channel trip in the interval concerned.
18
Safety-Critical Software
Examine one “path” as exampleTCDR
M_RxNOPGaini
c_NOPparmtrip
NOP Tripm_NOPspAbn1OFF
m_NOPspAbn1ON
m_NOPspAbn2OFF
m_NOPspAbn2ON
m_NOPspLPOFF
m_NOPspLPON
m_NOPaii
m_CalibrateEnable
M_RxFnType
f_NOPsentripif_NOPsp
M_RxCPPF
2003-04-03
10
19
Safety-Critical SoftwareThe following table evaluates thecurrent value of the NeutronOverpower (NOP) setpoint. It reliesheavily on a number of “naturallanguage expressions”.
TCDR
20
Safety-Critical SoftwareNeutron Overpower Setpoint
TCDR
Result
Condition f_NOPspNOP Low Power setpoint is requested k_NOPLPspNOP Low Power setpoint is cancelled
&NOP Abnormal 2 setpoint is requested
k_NOPAbn2sp
NOP Low Power setpoint is cancelled&
NOP Abnormal 2 setpoint is cancelled&
NOP Abnormal 1 setpoint is requested
k_NOPAbn1sp
NOP Low Power setpoint is cancelled&
NOP Abnormal 2 setpoint is cancelled&
NOP Abnormal 1 setpoint is cancelled
k_NOPnormsp
2003-04-03
11
21
Safety-Critical Software
Example: NOP Abnormal 1setpoint is requested orcancelled
TCDR
Result
Condition
NOP Abnormal 1setpoint is requested
or cancelled(m_NOPspAbn1ON = e_NotPressed) &(m_NOPspAbn1OFF = e_NotPressed)
No Change
(m_NOPspAbn1ON = e_NotPressed) &(m_NOPspAbn1OFF = e_Pressed)
cancelled
(m_NOPspAbn1ON = e_Pressed) &(m_NOPspAbn1OFF = e_NotPressed)
requested
(m_NOPspAbn1ON = e_Pressed) &(m_NOPspAbn1OFF = e_Pressed)
requested
22
Safety-Critical Software
Already saw NOP setpoint, nowNOP sensor trips
TCDR
{For each i = 1,..,18} Result
Condition f_NOPsentripi
f_NOPsp ≤ Calibrated ith NOP signal{Calibrated NOP signali is now in the trip region}
e_Trip
f_NOPsp - k_NOPhys < Calibrated ith NOP signal < f_NOPsp{Calibrated NOP signali is now in the deadband region}
(f_NOPsentripi)-1
Calibrated ith NOP signal ≤ f_NOPsp - k_NOPhys{Calibrated NOP signali is now in the non-trip region}
e_NotTrip
2003-04-03
12
23
Safety-Critical Software
And NOP parameter tripTCDR
Result
Condition c_NOPparmtripAny (i ∈ 1,..,18) (f_NOPsentripi = e_Trip)
{Any NOP sensor is tripped}e_Trip
All (i = 1,..,18) (f_NOPsentripi = e_NotTrip){All NOP sensors are not tripped}
e_NotTrip
24
Safety-Critical Software
Tolerances & TimingRequirements
Black-box describes behaviour of anidealised system - impossible to meet.Need tolerances in general.Need timing tolerances in particular.
Timing Resolutions (TRs)Performance Timing Requirements(PTRs)
TCDR
2003-04-03
13
25
Safety-Critical Software
TR
TR TRsetpoint
m_signal
timeTiming resolution for time continuous stimuli
Timing resolution for time discrete stimuli time
TR
M_signalM_signal
M_signal
M_signal
TCDR
An event thatlasts for TR orlonger mustbe detected
Two events atleast TR apartmust both bedetected
26
Safety-Critical Software
PTRsThe PTR for a stimulus/response pairspecifies an allowable processing delay.
Each response must have a PTR specifiedfor it. The PTR applies to the responseand the particular stimuli on which theresponse behaviour depends. The PTR ismeasured from the time that the stimuluson which the response behaviour dependscrosses the system boundary until the timethat the associated response crosses thesystem boundary.
TCDR
2003-04-03
14
27
Safety-Critical SoftwareTCDR
time
c_SomeTripe_Trip
e_NotTrip
Cond(m_signal)F
T
m_signal
k_setpoint
PTR
28
Safety-Critical Software
PTRsThe PTR for the pair c-m is meaninglessif c does not change its value in responseto a change in the value of m.
The time sequence of responses of acontrolled variable, c, cannot be altered byconsideration of the PTRs for each c-mi
pair.
TCDR
2003-04-03
15
29
Safety-Critical SoftwareTCDR
time
c_SomeTripe_Trip
e_NotTrip
Cond(m_signal)F
T
m_signalIf m does notcause achange in c,PTR has noblack-boxmeaning
30
Safety-Critical SoftwareTCDR
21
time
c_SomeTripe_Trip
e_NotTrip
Cond(m_signal)F
T
PTR for e_NotTrip
PTR for e_Trip
12
NotTrip detected
Trip detected
Cannot allowthis!
2003-04-03
16
31
Safety-Critical SoftwareTCDR
Table 2.4.1 - Timing Requirements
ControlledVariable
GoverningVariables
PTR TR Reference
c_NOPparmtrip m_NOPaii, i=1,..,18 160 ms Default
(Already morerestrictive than
required to meetseal-in)
[38], Table 1
m_NOPspAbn1OFFm_NOPspAbn1ONm_NOPspAbn2OFFm_NOPspAbn2ONm_NOPspLPOFFm_NOPspLPON
850 ms 350 ms [14], 1
m_CalibrateEnable N/A 1000 ms No directeffect
M_RxFnType 2000 ms Default -3
M_RxNOPGaini,i=1,..,18
N/A 2000 ms No directeffect
Example forc_NOPparmtrip
32
Safety-Critical SoftwareAnticipated Changes
Information Hiding is a software designparadigm that was introduced by Parnasin a famous paper in the early 1970s.
The original version of InformationHiding used anticipated design changes todrive the software decomposition.
It turns out that requirement changes arean even greater source of “secrets”.
TCDR
Parnas, D.: On thecriteria to be used indecomposing systemsinto modules.Communications of theACM December (1972)1053-1058
2003-04-03
17
33
Safety-Critical SoftwareTCDR
Table 9.1-1 - Anticipated Changes
Id Anticipated ChangeAC-1 Provisions shall be made in the software coding to give all
power dependent setpoints the ability to handle arbitrarysetpoint functions (instead of the current step functions). Asa minimum requirement, facilities to accommodate asetpoint value for each 1% power change shall be providedup to an upper limit of 110% Full Power (FP).
AC-2 Ranges as specified in the table that defines values ofconstants, see [27], shall be pre-verified so that theapplication can use any trip setpoint in the relevant range.
AC-3 New parameter trips may be added.
AC-4 The algorithm and number of detectors used for theestimated power calculation may change from the currentspecification.
AC-5 Individual deadbands may be revised, HTLF in particular.
AC-6 The processing time for the HTLF analog inputs may bereduced by 100 ms to make provisions to reallocate delayexternal to the trip computer, see [47], 2.2.2.
34
Safety-Critical Software
Trip Computer DesignDescription
Uses TCDR as a basisAdds design information, e.g.pushbutton debouncingModel changes to a Finite StateMachine with an arbitrarily smallclock-tickSRS contained within TCDD
TCDD
2003-04-03
18
35
Safety-Critical Software
Finite State Machine (FSM)Model
C(t) - set of controlled vars at time tM(t) - set of monitored vars at time tS(t) - set of state vars at time tt0 - time of initialisationS(t0) must be known
C(tk) = REQ(M(tk), S(tk))S(tk+1) = NS(M(tk), S(tk)), k=0,1,2,3,...
TCDD
36
Safety-Critical Software
FSM ModelTCDD
M(tk) C(tk)
S(tk+1)
NS(M(tk),S(tk))
REQ(M(tk),S(tk))
We have verysimple states inthe TCDD. Iff_name is afunction,f_name-1 is thevalue off_name at theprevious clocktick. It is astate variable.
2003-04-03
19
37
Safety-Critical SoftwareTCDD
Context diagramsMonitored & Controlled VariablesConstantsMain function tablesNatural language expressionsM-I mappings, transfer eventsC-O mappings, transfer eventsTolerances, PTRs and TRsAnticipated changesChanges from previous freezes
TCDD
38
Safety-Critical Software
We can see how debouncingpushbuttons affects thebehaviour specified in the TCDR.In particular, “NOP Abnormal 1setpoint is requested orcancelled” is respecified asfollows.
TCDD
2003-04-03
20
39
Safety-Critical Software
Debounce a pushbuttonCan specify more than 1 output
TCDD
Result
Condition f_NOPspAbn1OFF f_StuckNOPspAbn1OFFm_NOPspAbn1OFF = e_NotPressed e_pbNotDebounced False[ m_NOPspAbn1OFF = e_Pressed ]
&NOT [ (m_NOPspAbn1OFF =
e_Pressed) Held for k_Debounce ]
e_pbNotDebounced False
[ (m_NOPspAbn1OFF = e_Pressed)Held for k_Debounce ] &
NOT [ (m_NOPspAbn1OFF =e_Pressed) Held for k_pbStuck ]
e_pbDebounced False
(m_NOPspAbn1OFF = e_Pressed)Held for k_pbStuck e_pbStuck True
40
Safety-Critical SoftwareSo, NOP Abnormal 1 setpoint isrequested or cancelled is now definedin terms of f_NOPspAbn1ON/OFF
TCDD
Result
Condition
NOP Abnormal 1setpoint is requested
or cancelledf_NOPspAbn1ON = e_pbStuck OR
f_NOPspAbn1OFF = e_pbStuckrequested
f_NOPspAbn1ON = e_pbNotDebounced &f_NOPspAbn1OFF = e_pbNotDebounced
No Change
f_NOPspAbn1ON = e_pbNotDebounced &f_NOPspAbn1OFF = e_pbDebounced
cancelled
f_NOPspAbn1ON = e_pbDebounced &f_NOPspAbn1OFF = e_pbNotDebounced
requested
f_NOPspAbn1ON = e_pbDebounced &f_NOPspAbn1OFF = e_pbDebounced
requested
2003-04-03
21
41
Safety-Critical SoftwareTCDD
Result
Condition
NOP Abnormal 1setpoint is requested
or cancelledf_NOPspAbn1ON = e_pbStuck OR
f_NOPspAbn1OFF = e_pbStuckrequested
f_NOPspAbn1ON = e_pbNotDebounced &f_NOPspAbn1OFF = e_pbNotDebounced
No Change
f_NOPspAbn1ON = e_pbNotDebounced &f_NOPspAbn1OFF = e_pbDebounced
cancelled
f_NOPspAbn1ON = e_pbDebounced &f_NOPspAbn1OFF = e_pbNotDebounced
requested
f_NOPspAbn1ON = e_pbDebounced &f_NOPspAbn1OFF = e_pbDebounced
requested
Result
Condition
NOP Abnormal 1setpoint is requested
or cancelled(m_NOPspAbn1ON = e_NotPressed) &(m_NOPspAbn1OFF = e_NotPressed)
No Change
(m_NOPspAbn1ON = e_NotPressed) &(m_NOPspAbn1OFF = e_Pressed)
cancelled
(m_NOPspAbn1ON = e_Pressed) &(m_NOPspAbn1OFF = e_NotPressed)
requested
(m_NOPspAbn1ON = e_Pressed) &(m_NOPspAbn1OFF = e_Pressed)
requested
TCDDVersion
TCDRVersion
42
Safety-Critical SoftwareTCDD
Result
Condition f_ChanTripTime FirstTrip[ Manual reset ] NT True
[ c_ChanTrip = e_Trip ]&
[ FirstTrip-1 ]{There is currently a channel
trip and this is the firstchannel trip since a manual
reset}
tnow False
NOT [ Manualreset ]
NOT [ c_ChanTrip =e_Trip ]
ORNOT [ FirstTrip-1 ]
{There is not currently achannel trip or this is not the
first channel trip since amanual reset}
f_ChanTripTime-1 FirstTrip-1
where NT is chosen to be zero.Notes:1) The storage capacity required for this item is one word (16 bits). The value contained in
this item may "wraparound" if required, i.e. if the value exceeds the storage capacity by avalue n, then the new value becomes n-1.
2) Since NT is chosen to be zero, a channel trip at the time of initialization, or atwraparound, cannot be differentiated from the case where there is no channel trip.
Modifiedversion ofTCDRspecification
2003-04-03
22
43
Safety-CriticalSoftware
TCDD
Result
Condition f_ChanTripTime FirstTrip[ Manual reset ] NT True
[ c_ChanTrip = e_Trip ]&
[ FirstTrip-1 ]{There is currently a channel
trip and this is the firstchannel trip since a manual
reset}
tnow False
NOT [ Manualreset ]
NOT [ c_ChanTrip =e_Trip ]
ORNOT [ FirstTrip-1 ]
{There is not currently achannel trip or this is not the
first channel trip since amanual reset}
f_ChanTripTime-1 FirstTrip-1
where NT is chosen to be zero.
Result
Condition f_ChanTripTime[ Manual reset ] NT
[ There is a time tk, tmanualreset < tk ≤ tnow wherec_ChanTrip(tk) = e_Trip ] &
NOT [ There is a time tj, tmanualreset < tj < tk wherec_ChanTrip(tj) = e_Trip ]
{tk is the earliest time at which the channel was trippedafter the most recent manual reset}
tk
NOT [ Manualreset ]
[ NOT (c_ChanTrip(t) = e_Trip) for all t,tmanualreset < t ≤ tnow ]
{No channel trip has occurred since the most recentmanual reset}
NT
where tmanualreset = tm( [ Manual reset ] ), and NT is some representation (in ms) toindicate that there was no channel trip in the interval concerned.
TCDDversion
TCDRversion
44
Safety-Critical Software
We need to examine functionaltiming requirements in moredetail.As an example, consider asensor trip that depends on asensor (signal) being in a tripstate for a sustained period oftime.
TCDD
2003-04-03
23
45
Safety-Critical Software
f_HTLFsentripi, i=1,..,4{For each i = 1,..,4} Result
Condition f_HTLFsentripi
(f_HTLFimmsentripi = e_Trip) Held for (k_HTLFdelay){Immediate sensor trip active for at least past k_HTLFdelay time period}
e_Trip tnow ≥k_HTLFdelay
NOT [ (f_HTLFimmsentripi = e_Trip) Held for (k_HTLFdelay) ]{Immediate sensor trip not active for at least one instant in past k_HTLFdelay
time period}
e_NotTrip
(f_HTLFimmsentripi = e_Trip) Held for (tnow){Immediate sensor trip active since initialization}
e_Triptnow <k_HTLFdelay
NOT [ (f_HTLFimmsentripi = e_Trip) Held for (tnow) ]{Immediate sensor trip not active for at least one instant since initialization}
e_NotTrip
Since k_HTLFdelay has a tolerance, how do we copewith the fact that, from clock-tick to clock-tick,k_HTLFdelay may have different values at differenttimes?
46
Safety-Critical Software
0 t1 t2 t3 t4
Range for k_HTLFdelay
k_HTLFdelay at t1
k_HTLFdelay at t2
k_HTLFdelay at t3
Held for
Condition
T
T
F
FAllowingtolerances ontiming constantscan causesignificantproblems
2003-04-03
24
47
Safety-Critical SoftwareTCDD
TRUE
FALSE
Condition
Held for
period periodperiod
d - L
R+ d
TRUE
FALSE
d - L d - L
R+ d R+ d
48
Safety-Critical Software
(Condition) Held for (d) This function (Held for) checks to see whether “Condition” is true and hasbeen held true continuously for the immediate past “d” time period.
Let period be given by the duration, d, and tolerances -δL, +δR, 0 ≤ δL < d, 0 ≤ δR. Then period must berestricted as follows:
Result
Condition period Event_start_time
(Condition = True) & (Condition-1 = False) Any value in [d-δL, d+δR] tnow
(Condition = False) OR (Condition-1 = True) No Change No Change
where at time of initialization, period is any value in [d-δL, d+δR], and Event_start_time-1 = 0.
Result
Condition (Condition) Held for (d)tnow – Event_start_time ≥ period TrueCondition = True
tnow – Event_start_time < period False
Condition = False False
2003-04-03
25
49
Safety-Critical Software
TCDD
M CREQ
IN SOF OUTI O
Software Design
C = REQ(M*), and related to the software throughI = IN(M) and C = OUT(O)
TCDD
Parnas’ 4 variable model.Parnas, D.L., Madey, J.:Functional documents forcomputer systems.Science ofComputer Programming25 (1995) 41-61
50
Safety-Critical Software
The TCDD specifies “transferevents” (what the software mustdo to trigger getting a softwareinput, I, or emitting a softwareoutput, O).The TCDD also specifies the “M-Imappings”, and “C-O mappings”(what the hardware does).
TCDD
2003-04-03
26
51
Safety-Critical Software
The TCDD specifies a modifiedlist of timing requirements thattakes into account the designaspects added in the TCDD.The TCDD also lists a (potentiallymodified) list of anticipatedchanges.
TCDD
52
Safety-Critical SoftwareTCDD Table 2.2.2 - Timing Requirements
ControlledVariable
GoverningVariables PTR TR Reference
c_NOPparmtrip m_NOPaii, i=1,..,18 160 ms Default
(Alreadymore
restrictivethan requiredto meet seal-
in)
TCDR
m_NOPspAbn1OFF
m_NOPspAbn1ON
m_NOPspAbn2OFF
m_NOPspAbn2ON
m_NOPspLPOFF
m_NOPspLPON
850 ms (Heldfor
k_Debounce)/ 500 ms
350 ms TCDR and[13], #1 and
[23]
m_CalibrateEnable N/A 1000 ms TCDR
M_RxFnType 2000 ms Default TCDR
M_RxNOPGaini,i=1,..,18
N/A 2000 ms TCDR
Example forc_NOPparmtrip
2003-04-03
27
53
Safety-CriticalSoftware
TCDD
2.3.1 Steam Generator Low Level Sensor Trip
Determines whether there is a Steam Generator low level sensor trip, which is used todetermine whether there is an associated parameter trip.
2.3.1.1 Inputs/Natural Language Expressions
Input NL Expression Referencef_SGLLsp - 2.3.3.4m_SGLeveli, i=1,..,4 - Table 2.6.1-1
2.3.1.2 Initial Value
Name InitialValue
Reference
(f_SGLLsentripi)-1, i=1,..,4 e_Trip TCDR
2.3.1.3 Output Units/Type
Output Typef_SGLLsentripi, i=1,..,4 y_trip
2.3.1.4 f_SGLLsentripi, i=1,..,4{For each i = 1,..,4} Result
Condition f_SGLLsentripi
f_SGLLsp ≥ m_SGLeveli
{SG leveli signal is now in the trip region} e_Trip
f_SGLLsp + k_SGLLhys > m_SGLeveli > f_SGLLsp{SG leveli signal is now in the deadband region} (f_SGLLsentripi)-1
m_SGLeveli ≥ f_SGLLsp + k_SGLLhys{SG leveli signal is now in the non-trip region} e_NotTrip
Example functiondefinition inTCDD
54
Safety-Critical Software
Software Design DescriptionAugmented anticipated changesModule guideAlternate viewsModule designsDerived timing requirementsDesign notesSupplementary function tables /mappings to TCDD
SDD
2003-04-03
28
55
Safety-Critical Software
SDDM CREQ
IN
SOF
OUT
I O
SOFin
SOFreq
SOFout
Mp Cp
Software Design
SDD
56
Safety-Critical Software
Some crucial definitionsSoftware moduleAccess programProcessing unit
SDD
2003-04-03
29
57
Safety-Critical Software
Software moduleA module is a conceptual design unitin the decomposition of softwarefunctionality. Modules can bedeveloped in a hierarchical structurewhere one module can “contain” othermodules. This leads to a treestructure of modules.The top-level modules divide thesystem into a few broadly definedareas.
SDD
58
Safety-Critical Software
Software module - continuedEach top-level module should have ageneral responsibility (role andpurpose) related to encapsulating(hiding) a design decision (a secret).The functionality enclosed within sucha module should contribute to thatoverall responsibility.Each of the top-level modules can befurther decomposed into smallermodules.
SDD
2003-04-03
30
59
Safety-Critical Software
Software module - continuedEach of these smaller modules has itsown responsibility and secret, but theresponsibilities are more focused.Modules that require no furtherrefinement are termed “leaf modules”(in keeping with the tree structure).The leaf modules represent the finaldecomposition of the software system.
SDD
60
Safety-Critical SoftwareSDD
Top levelmodules
Softwaresystem
Leaf modules
Classmodules
2003-04-03
31
61
Safety-Critical Software
Access programsLeaf modules communicate with eachother through the use of externallyvisible access programs. The accessprograms belonging to a particular leafmodule (A) allow other leaf modules todeliver data that the module (A) needs,and to examine the values of data itemscontained within the module (A). Thisis the only approved method for oneleaf module to access the contents ofanother leaf module.
SDD
62
Safety-Critical SoftwareSDD
Module AModule C
Module B
s_one, s_two
A.Sprog1A.Gprog2
A.Gprog3
s_alpha
B.Sprog1
B.Gprog2
s_other
C.Sprog
a = A.Gprog3+k_deltatb = B.Gprog2-4*k_up...Sprog = a + b + A.Gprog2...
Sets values for s_one, s_two
Returns value of s_oneReturns value of s_two
Sets value of s_alpha
Returns value of s_alpha
2003-04-03
32
63
Safety-Critical Software
Processing unitA processing unit is a group ofaccess programs that is consideredto be a single executable unit. Therequired behaviour of the applicationis achieved by executing all theprocessing units defined for theapplication according to the controlstructure defined in the scheduler
SDD
64
Safety-Critical Software
We use design attributes to drivethe software design process
General design attributesSystem structure attributesDecomposition attributesModule interface design attributesModule detailed design attributes
SDD
2003-04-03
33
65
Safety-Critical Software
Decomposition attributesGroup 1 - (during and afterdecomposition)
Coverage, Information hiding,Responsibility, Locatability, Hardwareisolation
Group 2 - (after interfaces)Module cohesion, Focus,Maintainability, Localization of data
Group 3 - (after detailed design)Independence, Uniqueness of data
SDD
66
Safety-Critical Software
Information hiding attributeFor any change that has beenidentified as likely, the functionalbehaviour directly affected by thatchange should be isolated in a singlemodule.
SDD
2003-04-03
34
67
Safety-Critical Software
Top-level decompositionSDD
Hardware Hiding Behaviour Hiding Software Decisions
Application
68
Safety-Critical Software
Repeated decompositionEach top-level module can be examined tosee how it can be further decomposed.The decomposed modules representclasses of modules and should sharesome distinguishing characteristics interms of their responsibilities and thesecrets they hide from the rest of thesystem. Typical classes at this levelcontain sets of: Function drivers; andDevice interface modules.
SDD
2003-04-03
35
69
Safety-Critical Software
Function driversModules whose sole purpose is toproduce system outputs.
Device interface modulesModules that provide virtual interfacesto the hardware, completely hiding thecharacteristics of a peripheral devicefrom the software application.
SDD
70
Safety-Critical Software
Each class module can be furtherdecomposed until the leafmodules represent the finaldecomposition of the system.To implement this processrequires heuristics to aid in furtherdecomposing a module, andcriteria for stopping any furtherdecomposition.
SDD
2003-04-03
36
71
Safety-Critical Software
Decomposing modulesIsolate components likely to changeProtect data from unintentional/unwarranted modification by encapsulatingitLook for groups of history dependententities for possible encapsulation.Encapsulate interrupt and timer processing.Encapsulate algorithms specified in theTCDD.Encapsulate scheduling policies.
SDD
72
Safety-Critical Software
Stopping further decomposition ofa module
If the module were to be furtherdecomposed, the secret encapsulatedwithin a newly created module wouldnot be worth hiding.Further decomposition would requireexcessive communication between thenew modules.The module is already simple enoughto be implemented easily in code.
SDD
2003-04-03
37
73
Safety-Critical SoftwareSDD Table 5-4 - Module Reference Table (Behaviour Hiding)
ID Name Module Secrets Module Responsibility TCDD Ref1 BehaviourHiding All aspects of behaviour of the system that
1) are externally visible,2) can be implemented independently ofchanges in hardware (which do not affectthe capability of the hardware).
Implements the rules that produce therequired external behaviour of the SDS1Trip Computer.
-
1.1 ChannelTrip The rules for determining the channel tripsystem outputs, the channel trip time sincethe last manual reset, the manual resetrequest status, and the validity of thechannel trip sealed-in status word.(C21)
Determines all the channel trip relatedstatuses. Provides current channel tripstatus to drive the channel trip output,channel trip time since the last manualreset, status of the manual reset requestand validity of the channel trip sealed-instatus word.
‘Any parameter tripped’,‘Channel trip sealed-in’,‘Consistency check fatal error’,‘Manual reset request’,c_ChanTrip, f_ChanTripTime,sw_SealinWord, Initial Value,Initialization Requirements.
1.2 ParamTrip (P) The rules for determining parameter tripsystem outputs.(C3, C7)
A parameterized module whichimplements parameter trip detection logicfor trip parameters. Provides the currentparameter trip status to drive theparameter trip output.
N/A
1.2.1 NPParTrip The rules for determining the NeutronOverpower parameter trip system output.
Instantiation of ParamTrip module forNeutron Overpower trip.
c_NOPparmtrip, Initial Value,Initialization Requirements.
… … … … …1.3 SensorTrip (P) The rules for determining sensor trips for
each trip parameter.(C5, C6)
A parameterized module whichimplements the sensor trip determinationrules. Provides the current sensor tripstatus. Provides facilities to track/reset thestatus of sensor trip occurrence indication.
N/A
1.3.1 NPSnrTrip The rules for determining NeutronOverpower sensor trips.
Instantiation of SensorTrip module forNeutron Overpower trip.
f_NOPsentripi, i=1,..,18, InitialValue, InitializationRequirements,f_NOPsentripsti, i=1,..,18*.
… … … … …
ModuleGuideextract
74
Safety-Critical Software
Module DependenciesNeed to know what data is required bywhich module and which module ownsthe dataHow do we know this?
We have complete functionaldescriptions of behaviour in the TCDDA module’s responsibility is representedby functional behaviour as described inthe TCDD
SDD
2003-04-03
38
75
Safety-Critical Software
Create and refine access programsDefault set of access program alwaysexists
Perform processing (update state data,produce a system output)Initialization programPrograms that provide information aboutthe module’s state data to other modules
Can refine these access programs in a(sort of) systematic way
SDD
76
Safety-Critical Software
Criteria while refining accessprograms
Access programs must not reveal secret of themoduleEach program’s interface is as simple as possibleEach program services its users in a wayconvenient to the usersEach parameter required by every userMake choices based on simplifying timingParameters of a single access program should allmove data in a single direction (does not apply tocontrol variables)
SDD
2003-04-03
39
77
Safety-Critical Software
Once all the modules and moduleinterfaces are decided we cancontinue with the detailed designof each module.
SDD
78
Safety-Critical Software
Module Cover Page
Module Name & NumberResponsibility
Export ConstantsExport Types
Access Program 1 NameParametersDescriptionReferences
...Access Program n Name
ParametersDescriptionReferences
Module Internal Declarations
Internal ConstantsInternal Types
State Data
System InputsSystem Outputs
Local Program 1 NameParametersDescriptionReferences
...Local Program m Name
ParametersDescriptionReferences
Program 1 Name
Program 2 Name
Program n+m Name
...Interface design team
Available to all designersDefines design tasks for
module designers
Module design teamAvailable to module designers
Individual designers
SDD
Moduledocumentation
2003-04-03
40
79
Safety-Critical SoftwareSDD n.m MODULE Watchdog(1.10)
Determines the watchdog system output.
Name Value Type
Constants: (None)
Name Definition
Types: (None)
Access Programs:
EWDOGUpdates the state of the watchdog timer DO.References: c_Watchdog, ‘Watchdog test active’*.
IWDOGInitializes all the Watchdog module internal states and sets the initial watchdog output.References: Initial Value, Initialization Requirements.
SWDOGNCPARM: t_boolean - inSignals to Watchdog module that a valid watchdog test request is received if NCPARM =$TRUE. Note that NCPARM is a “Conditional Output Call Argument”; calling theprogram with NCPARM = $FALSE has no effects on the module.
References: ‘Watchdog test active’*.
Cover pagefor moduleWatchdog
80
Safety-Critical SoftwareSDD
n.m.1 MODULE WatchdogInternal Declaration
Name Value/Origin TypeConstants: KWDDLY 1000 t_integer
Name Definition/OriginTypes: t_boolean Global
t_integer Globalt_MsecTimerID Timert_PBId DigitalInputt_PBStat DigitalInputt_PosInt Globalt_TimerOp Timert_WDogStat DigitalOutput
Name TypeState Data: WDGST t_boolean
WDGTST t_boolean
Module-wideinternaldeclarations
2003-04-03
41
81
Safety-Critical SoftwareSDD n.m.1.1 ACCESS PROGRAM EWDOG
Name Ext_value Type OriginInputs: l_CalEn GPBKS($PBCAL) t_PBStat DigitalInput
l_TREQD GCMSEC($CWDG) t_PosInt Timer
Name Ext_value Type OriginUpdates: WDGST - t_boolean State
WDGTST - t_boolean State
Name Ext_value Type OriginOutputs: l_WdgClk SCMSEC($CWDG, l_WdgClk) t_TimerOp Timer
l_WdgDO SDOWDG(l_WdgDO) t_WDogStat DigitalOutput
Range check assertion 1: (l_CalEn = $DBNC) OR (l_CalEn = $NDBNC)
Modes:l_InTest 0 < l_TREQD < KWDDLYl_NoTest l_TREQD = 0l_TstEnd l_TREQD >= KWDDLY
VCT: EWDOGWDGTST = $FALSE NOT (WDGTST = $FALSE)
NOT (l_CalEn = $NDBNC)WDGST =$FALSE
NOT(WDGST = $FALSE)
l_CalEn =$NDBNC l_NoTest l_InTest l_TstEnd
l_WdgClk $CRSET $CRSET $CRSET $CSTRT $CNC $CRSETl_WdgDO $WDON $WDOFF $WDNC $WDNC $WDNC $WDNCWDGST $TRUE $FALSE No Change No Change No Change No Change
WDGTST No Change No Change $FALSE No Change No Change $FALSE
Detailedmoduledesign foran exampleaccessprogram
82
Safety-Critical SoftwareSince the decomposition of behaviourin the SDD is almost guaranteed to bedifferent from the decomposition in theTCDD, it is likely that just a portion of aTCDD function may be implemented inan access program, or that acomposition of TCDD functions may beimplemented in an access program.This presents a couple of importantproblems.
SDD
2003-04-03
42
83
Safety-Critical SoftwareWe use the TCDD functions to specifythe black-box behaviour of an accessprogram, and so if the access programdoes not implement a single, completeTCDD function, this black-boxbehaviour is difficult to specify.It is difficult to verify the SDD behaviouragainst the TCDD behaviour when thefunction topologies of the two aredifferent.
SDD
84
Safety-Critical SoftwareThe way we overcome these difficultiesis by use of “supplementary functiontables” (SFTs). The idea here is thatwe imagine a pseudo requirementsspecification in which the functiontopology will exactly match that in theSDD. If such a pseudo requirementsspecification were to exist, thenverifying the SDD against the TCDDcould be performed in two steps.
SDD
2003-04-03
43
85
Safety-Critical SoftwareVerify the SDD against the pseudorequirements specification.Verify the pseudo requirementspecification against the TCDD.
SDD
86
Safety-Critical SoftwareThe SFTs are developed during theforward going process, by the softwaredesigners themselves, but are notconsidered “proved”.They are available during the softwareverification to aid the verification teamin the mathematical verification of thesoftware.
SDD
2003-04-03
44
87
Safety-Critical SoftwareThe following data flow diagramsillustrate the concept of STFs.
SDD
f_b
f_d
f_c
f_e
f_d-1
f_c-1
a e
TCDDTopology
f_B
f_Y
f_X
f_Es_Za f_Z e
s_Z is state datarelated to f_Z
SDDTopology
88
Safety-Critical SoftwareSDD
f_b
f_d'
f_c'
f_e'
f_d'-1
f_c'-1
a
f_y
f_x
f_z
split f_c
split f_d
e
split f_eSFT
TopologySplit TCDDFunctions
f_b
f_d'
f_c'
f_e'
f_d'-1
f_c'-1
a
f_y
f_x
f_z e
should matchf_Z
SFTTopology
RegroupedFunctions
We can use the SFTs, f_x, f_c’, f_y,f_d’, f_z and f_e’ as references onmodule cover pages (and in the MG).
2003-04-03
45
89
Safety-Critical Software
Safety-net (a couple of examples)Safe state (if there is one) is alwaysplaced in the right-most column of afunction table. This convention can beused to produce code that puts thesoftware into a safe state even in the faceof hardware malfunctions.Sequence checks - uses a baton passingmechanism to check that programs areinvoked in the correct sequence, and noprogram has been “skipped”.
SDD
90
Safety-Critical Software
SchedulerOptimal: a simple infinite loop that justinvokes each processing unit in therequired sequence.Reality: if the hardware cannot supportthe optimal strategy, we have to tryalternative strategies - e.g.
Loop frames - LF1, LF2, LF3, LF4Each LF invokes programs in a way thatwill satisfy PTRs, and takes advantageof more relaxed PTRs to schedule thoseprograms less frequently.
SDD
2003-04-03
46
91
Safety-Critical Software
Processing Unit (PU) ExamplePU16 {NOP trip fns}
ECALNP() Calibrated NOP sensorsESPNP() NOP setpointESTNP() NOP sensor tripsEPTNP() NOP parm trip
SDD
92
Safety-Critical Software
Example of use of loop framesStraight line version:
PU5 {read A/Is}PU2 (read D/Is}PU16 {NOP trip fns} 160PU13 {HTLF trip fns} 350. . . . . .PU19 {LN trip fns} 160PU9 {HTHP trip fns} 250PU11 {HTLP trip fns} 250PU7 {Chan trip} ptPU1 {write A/Os}PU3 {write D/Os}
SDD
136 ms
2003-04-03
47
93
Safety-Critical SoftwareExample of use of loop frames
Loop frame version:
PU5 {read A/Is}PU2 (read D/Is}PU16 {NOP trip fns} 160PU19 {LN trip fns} 160PU9 {HTHP trip fns} 250PU11 {HTLP trip fns} 250PU7 {Chan trip} ptPU1 {write A/Os}PU3 {write D/Os}
SDD
PU5 {read A/Is}PU2 {read D/Is}PU16 {NOP trip fns} 160PU19 {LN trip fns} 160PU13 {HTLF trip fns} 350PU7 {Chan trip} ptPU1 {write A/Os}PU3 {write D/Os}
46 ms 46 ms
LF1 LF3 . . .. . .
94
Safety-Critical Software
SDD VerificationVerify SDD against pseudo-TCDD -have same data flow topology.Verify pseudo-TCDD against TCDD -only need to verify those blocks thatare different.
Concentrate for now on verifying SDDagainst pseudo-TCDD.
SDV
2003-04-03
48
95
Safety-Critical Software
Proof obligationSDV
pseudo - TCDD
SDD
REQpM
IN
I
SOFin
Mp
C
O
Cp
OUT
SOFout
SOFreq
Abst m Abst c
Path 1
Path 2
Result via path 1 mustequal result via path 2.
REQp(M) = Abstc
-1(SOFreq(Abstm(M)))
Abstm(M) = SOFin(IN(M))
C = OUT(SOFout(Abstc(C)))
96
Safety-Critical Software
Proof obligation for SDD vspseudo-TCDD
REQp(M) = Abstc-1(SOFreq(Abstm(M)))
Can prove that we can do the proofpiece-wise in blocks. Each block isidentified as having equivalent inputsand outputs in the SDD and pseudo-TCDD. (Can make use of SFTs)
SDV
2003-04-03
49
97
Safety-Critical SoftwareExample: TCDD vs SDDSDV
98
Safety-Critical SoftwareProof obligation for example
SDV
Abstc 1-1(g4(g2(g1(Abstm 1(m1), Abstm 2(m2))), g3(g1(Abstm 1(m1), Abstm 2(m2)),
Abstm 2(m2)))) = f4(f2(f1(m1, m2)), f3(f1(m1, m2), m2)) ... (1)Abstc 2
-1(g3(g1(Abstm 1(m1), Abstm 2(m2)), Abstm 2(m2))) = f3(f1(m1, m2), m2) ... (2)
2003-04-03
50
99
Safety-Critical SoftwarePiece-wise verification
Possible block boundaries exist oneach set of matching inputs andoutputs (matching in pseudo-TCDDand SDD)
SDV
100
Safety-Critical SoftwareSDV
Block 1Block 2 Block 3
Block 4
2003-04-03
51
101
Safety-Critical SoftwareBlock 1
A1(f1(m1, m2) = g1(Abstm 1(m1), Abstm 2(m2)) ... (3)Block 2
A2(f2(f1*)) = g2(A1(f1*) ... (4)Block 3
Abstc 1(f4(f2*, f3*)) = g4(A2(f2*), Abstc 2(f3*)) ... (5)Block 4
Abstc 2(f3(f1*, m2)) = g3(A1(f1*),Abstm 2(m2)) ... (6)
If we now assume that (3) through (6) are verified to be true, then wecan proceed by:Substituting for A2(f2(f1*)) from (4) into (5) - gives (1), andsubstituting for A1(f1(m1, m2) from (3) into (6) - gives (2)
So, example demonstrates piece-wise success - if topology is thesame.
SDV
102
Safety-Critical Software
Typically, in a specific block, wecompose the SDD tables andmanipulate them until we canshow that they are equal to thecomposed pseudo-TCDD tables.There has also beenconsiderable working done inautomating these proofs usingtheorem provers like PVS.
SDV
Lawford, M., McDougall,J., Froebel, P., Moum, G.:Practical application offunctional and relationalmethods for thespecification andverification of safetycritical software. In Rus,T., ed.: Proc. of AMAST2000, Iowa City, Iowa,USA, May 2000.Volume 1816 of LNCS.,Springer (2000) 73-88.
2003-04-03
52
103
Safety-Critical Software
Design heuristic helps verification:Get-Process-Set.There are often cases wheretiming considerations considerablycomplicate the verificationprocess.There are also some cases wheresoftware design decisionscomplicate the verification.
SDV
104
Safety-Critical Software
SDD Verification
ChkLink
RxRdy
WDTest
NOPData
HTFData
HTFGains
P1 ChkRx
P2
E2E3
E4E5
E6
E1
E37
S1S2 S3
S5
S6
S10
S12
S16
S4
S18RxInit
Process Message
LnkOff
PartMsg
NoMsg
LnkInit
RestrtHPX
InvPt Ms Hdr
Bad
S19S21
S22
S20 S24
S25 S26
E7
E20E21
E22
E23
E24E25
E27
E28
E31
E32E33
E34
E35
E36
NOPGains
NOHTF
S17
NoNOP
S11
TentNOP
S7
NOPRng
S8
NOPInv
S9
TentHTF
S13
HTFRng
S14
HTFInv
S15
E8E9
E10
E11
E13
E14
E12
E15E16
E17
E18E19
AnyNewGns
S23
E26E29
E30
RxIdle
Waiting for Msg
Waiting forrest of Msg
Process Msg
Receive Idle
SDV
TCDD
SDD
2003-04-03
53
105
Safety-Critical Software
Currently, without moreadvanced automated verificationtools, my estimate is that SDDverification accounts for about30% of the total effort.
SDV
106
Safety-Critical Software
CodingCoding performed from detaileddesign in the SDD.Traceable to the SDD.Safe even in the face of hardwaremalfunctions.
Coding from function tables produceswell structured, easily verified, code.
Code
2003-04-03
54
107
Safety-Critical Software
FORTRAN 66 CodeUse labelled common to construct modules.
COMMON /NAMEX/ list of module exported contantsCOMMON /NAMEV/ list of module state variablesCOMMON /NAMEK/ list of module internal constantsAny program can include any number of ___Xcommon statements, but only three commonstatements with the NAME of the module
Challenge to describe safe and readablecontrol structures.Comments refer to the SDD.
Code
108
Safety-CriticalSoftware
Code
Example extractfor EWDOG
Part 1
C < SDD Input: l_CalEn = DigitalInput.GPBKS($PBCAL) > LLCALE = GPBKS($PBCAL)C < SDD Input: l_TREQD = Timer.GCMSEC($CWDG) > LLTREQ = GCMSEC($CWDG)CC Range check on <l_CalEn> and <l_TREQD>. IF (((LLCALE .NE. $DBNC) .AND. (LLCALE .NE. $NDBNC)) .OR. + (LLTREQ .LT. 0))C ErrorHdler.SFAT($FERNG, KPLN) + CALL SFAT($FERNG, KPLN)CC --- < VCT EWDOG > --------------------------------------------------- IF (WDGTST .NE. $FALSE) GO TO 20000 IF (WDGST .NE. $FALSE) GO TO 12000 WDGST = $TRUEC < SDD Output call: Timer.SCMSEC($CWDG, l_WdgClk) > CALL SCMSEC($CWDG, $CRSET)C < SDD Output call: DigitalOutput.SDOWDG(l_WdgDO) > CALL SDOWDG($WDON) GO TO 2999912000 CONTINUEC < NOT(WDGST = $FALSE) > WDGST = $FALSEC < SDD Output call: Timer.SCMSEC($CWDG, l_WdgClk) > CALL SCMSEC($CWDG, $CRSET)C < SDD Output call: DigitalOutput.SDOWDG(l_WdgDO) > CALL SDOWDG($WDOFF) GO TO 2999920000 CONTINUEC < NOT(WDGTST = $FALSE) > IF (LLCALE .NE. $NDBNC) GO TO 22000 WDGTST = $FALSEC < SDD Output call: Timer.SCMSEC($CWDG, l_WdgClk) > CALL SCMSEC($CWDG, $CRSET)C < SDD Conditional Output Call: C DigitalOutput.SDOWDG(l_WdgDO) >C CALL SDOWDG($WDNC) GO TO 29999
2003-04-03
55
109
Safety-CriticalSoftware
Code
Example extractfor EWDOG
Part 2
22000 CONTINUEC < NOT(LLCALE = $NDBNC) > IF (LLTREQ .NE. 0) GO TO 22200C < l_NoTest >C < SDD Output call: Timer.SCMSEC($CWDG, l_WdgClk) > CALL SCMSEC($CWDG, $CSTRT)C < SDD Conditional Output Call: C DigitalOutput.SDOWDG(l_WdgDO) >C CALL SDOWDG($WDNC) GO TO 2999922200 CONTINUEC Redundant test of 0 < l_TREQD is not included forC performance reasons. IF (LLTREQ .GE. KWDDLY) GO TO 22300C < l_InTest >C < SDD Conditional Output Call: C Timer.SCMSEC($CWDG, l_WdgClk) >C CALL SCMSEC($CWDG, $CNC)C < SDD Conditional Output Call: C DigitalOutput.SDOWDG(l_WdgDO) >C CALL SDOWDG($WDNC) GO TO 2999922300 CONTINUEC < l_TstEnd > WDGTST = $FALSEC < SDD Output call: Timer.SCMSEC($CWDG, l_WdgClk) > CALL SCMSEC($CWDG, $CRSET)C < SDD Conditional Output Call: C DigitalOutput.SDOWDG(l_WdgDO) >C CALL SDOWDG($WDNC)29999 CONTINUEC --- < END VCT EWDOG > -----------------------------------------------
110
Safety-Critical Software
Safety-net (again)Use full word for logical/boolean values,not bits
16-bit word: False = 0, True <> 065,535 ways to be True, 1 to be FalseMake sure True represents safe state, theneven if there is a RAM error (even someother hardware errors), there is a 65000 to1 chance that the software will set the safestate
Code
2003-04-03
56
111
Safety-Critical Software
Code VerificationTypically straight forward andrelatively easy.If code comment indicates VCT(Vertical Condition Table) thenanalyse code to produce VCT.Afterwards compare with SDD.If code comment indicates Algorithm(pseudo-code) then analyse code tocompare with pseudo-code.
CVR
112
Safety-Critical Software
Relationship between TR andPTR
Usually the TR for a given m-c pair isdictated by physical characteristics ofm. However, nuclear safety analysesmake few asumptions about the TR.TR < PTR is sometimes all we canassume [ts is the sample interval, tpthe processing time, then ts+tp ≤ PTR.Since tp > 0 and TR is an upper boundfor ts, TR < PTR]
Timing
2003-04-03
57
113
Safety-CriticalSoftware
TRs and PTRs - BasicsTim
ing
real world
times atwhichinputs aresampled
114
Safety-Critical Software
Relationship between TR andfunctional timing requirements
What if we have a sustained event?Example: To filter out the effect of a noisy signalwe may specify that a sensor trip should besustained for 400 ± 50 ms before it can cause aparameter trip. This means that theimplementation must guarantee that if the sensortrip is sustained for less than 350 ms, theparameter trip must not occur. Similarly, if thesensor trip is sustained for 450 ms, the parametertrip must be recorded. (It can be issued sometime later, as long as it is within the PTR for thatc-m pair.)
Timing
2003-04-03
58
115
Safety-Critical SoftwareTim
ingFirst sample
after initial eventSecond sampleafter initial event
Event
δd - L δd + R
No trip inthis timeinterval
Must tripby the
time weget here
Can trip in thistime interval
Is thissampling
rate okay?
116
Safety-Critical SoftwareTim
ingFirst sample
after initial eventSecond sampleafter initial event
Event
δd - L δd + R
No trip inthis timeinterval
Must tripby the
time weget here
Can trip in thistime interval
Is thissampling
rate okay?NO
Event could haveoccurred
immediately afterlast sample
2003-04-03
59
117
Safety-Critical SoftwareTim
ing
Event
δd - L δd + R
No trip inthis timeinterval
Must tripby the
time weget here
Can trip in thistime interval
Must have at least two samples inthe range of the sustained event
118
Safety-Critical SoftwareTim
ing
Why do we need two samples inthe range?
If we have only one, and it is not on aboundary, then:
Assume ts is constantLet that sample be the nth sample,including the detection of the eventWe know that at least (n-1)ts haselapsed since the actual eventBut, actually, nts may have elapsedHowever, nts will be greater thand+δR, since only one sample in range
2003-04-03
60
119
Safety-Critical SoftwareTR ≤ (δL+δR)/2 will suffice but is overlyrestrictiveIf ½(δL+δR) < ts < (δL+δR), there has to be asample point in the interval [d-δL, d+δR] atwhich we make the decision concerning theparameter trip, and this point must be suchthat the previous sample point also lies within[d-δL, d+δR]. Mathematically what we arelooking for is described by:Choose ts such that
d-δL ≤ (n-1)ts (left most sample in the interval)nts ≤ d+δR (right most sample in the interval)
where n is an integer.
k_HTLFdelay= 400 ± 50 ms= [d-δL, d+δR]
Timing
120
Safety-Critical SoftwareTim
ing
PTRs forsustainedevents
2003-04-03
61
121
Safety-Critical Software“Seal-in” presents similar but differentdifficulties.
Seal-in is measured from the time a controlledvariable changed from e_NotTrip to e_Trip (if thechannel D/O is opened for 125-200 ms then thechannel trip D/O is not allowed to close until amanual reset is perfomed)Turns out to be slightly easier because it ismeasured from a known time, so only one sample inthe range is required
Would be very useful to find a more generalanalysis
Timing