A Safety-Critical Software Approach to Hard Real-Time ...

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


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


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


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


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


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


TCDRContext diagramsStimuli & ResponsesConstantsMain function tablesNatural language expressionsTolerances, PTRs and TRsAnticipated changesChanges from previous freezes

TCDR

12


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


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


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


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


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


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


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


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


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


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


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


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


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


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


time

c_SomeTripe_Trip

e_NotTrip

Cond(m_signal)F

T

m_signalIf m does notcause achange in c,PTR has noblack-boxmeaning

30


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


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


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


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


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


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


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


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


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


Result

Condition


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


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


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


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


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


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


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


TRUE

FALSE

Condition

Held for

period periodperiod

d - L

R+ d

TRUE

FALSE

d - L d - L

R+ d R+ d

48


(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


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


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


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


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


Software Design DescriptionAugmented anticipated changesModule guideAlternate viewsModule designsDerived timing requirementsDesign notesSupplementary function tables /mappings to TCDD

SDD

2003-04-03

28

55


SDDM CREQ

IN

SOF

OUT

I O

SOFin

SOFreq

SOFout

Mp Cp

Software Design

SDD

56


Some crucial definitionsSoftware moduleAccess programProcessing unit

SDD

2003-04-03

29

57


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


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


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


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


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


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


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


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


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


Top-level decompositionSDD

Hardware Hiding Behaviour Hiding Software Decisions

Application

68


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


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


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


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


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


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


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


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


Once all the modules and moduleinterfaces are decided we cancontinue with the detailed designof each module.

SDD

78


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


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


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-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


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


Processing Unit (PU) ExamplePU16 {NOP trip fns}

ECALNP() Calibrated NOP sensorsESPNP() NOP setpointESTNP() NOP sensor tripsEPTNP() NOP parm trip

SDD

92


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


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


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


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


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


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


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


Currently, without moreadvanced automated verificationtools, my estimate is that SDDverification accounts for about30% of the total effort.

SDV

106


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


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


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


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-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


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


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


TRs and PTRs - BasicsTim

ing

real world

times atwhichinputs aresampled

114


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


ingFirst sample

after initial eventSecond sampleafter initial event

Event

δd - L δd + R


Must tripby the

time weget here


Is thissampling

rate okay?NO

Event could haveoccurred

immediately afterlast sample

2003-04-03

59

117


ing

Event

δd - L δd + R


Must tripby the

time weget here


Must have at least two samples inthe range of the sustained event

118


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


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

A Safety-Critical Software Approach to Hard Real-Time ...

Documents

Transcript of A Safety-Critical Software Approach to Hard Real-Time ...