Скачать презентацию Alan Wassyng A Safety Critical Software Approach to Скачать презентацию Alan Wassyng A Safety Critical Software Approach to

efd395cb1e5712b98a60bfaece93ba50.ppt

  • Количество слайдов: 121

Alan Wassyng A Safety. Critical Software Approach to Hard Real-Time Applications Alan Wassyng A Safety. Critical Software Approach to Hard Real-Time Applications

Safety-Critical Software n n n Software required for a safety system Action initiated (or Safety-Critical Software n n n Software required for a safety system Action initiated (or not initiated) by the software that can lead directly to loss of life In the Canadian Nuclear Industry, software that has a safety role is kept separate from control software 2

Safety-Critical Software n The methodology we are going to talk about is applicable to Safety-Critical Software n The methodology we are going to talk about is applicable to a wide variety of applications: u Nuclear Generating Station shutdown systems (the example we will discuss) u Embedded applications in auto and avionics industries u Embedded applications in software controlled electric motors u Weapons systems. . . 3

Safety-Critical Software n NGS Shutdown System T/C = Trip Computer D/T = Display/Test Computer Safety-Critical Software n NGS Shutdown System T/C = Trip Computer D/T = Display/Test Computer Mon. Comp = Monitor Computer 4

Safety-Critical Software n Target System - SDS 1 5 Safety-Critical Software n Target System - SDS 1 5

Safety-Critical Software n An SDS 1 Trip Computer 6 Safety-Critical Software n An SDS 1 Trip Computer 6

Safety-Critical Software n SDS 1 & SDS 2: Real-Time Monitoring & Shutdown u These Safety-Critical Software n SDS 1 & SDS 2: Real-Time Monitoring & Shutdown u These computer systems have hard deadlines in which they have to detect potential accident scenarios. u They also have hard deadlines in which they have to initiate alarms, and, if necessary, initiate shutdown of the reactor. 7

Safety-Critical Software n Methodology - SDS 1 8 Safety-Critical Software n Methodology - SDS 1 8

Safety-Critical Software n SDS 1 u Trip Computer Design Requirements u Trip Computer Design Safety-Critical Software n SDS 1 u Trip Computer Design Requirements u Trip Computer Design Description u Software Design Review - (nd) u Software Design Verification u FORTRAN Code u Testing - not going to discuss (nd) u Code Review - (nd) u Code Verification 9

DR C Safety-Critical Software T n Mills, H. D. : Stepwise refinement and verification DR C Safety-Critical Software T n Mills, H. D. : Stepwise refinement and verification in boxstructured systems. Computer 21 (1988) 23 - Trip Computer Design Requirements (Mills’ Black-Box) R = f ( S, Sh ) S is the set of stimuli, Sh the set of stimulus history, R the set of responses 10

DR C Safety-Critical Software T n TCDR u Context diagrams u Stimuli & Responses DR C Safety-Critical Software T n TCDR u Context diagrams u Stimuli & Responses u Constants u Main function tables u Natural language expressions u Tolerances, PTRs and TRs u Anticipated changes u Changes from previous freezes 11

DR C Safety-Critical Software T n n n We expect that all responses are DR C Safety-Critical Software T n n n We expect that all responses are described in terms of stimuli and stimuli history only. It is sometimes advantageous to allow response history to appear in functional descriptions. In deterministic systems, response history is always a representation of stimuli history. 12

DR C Safety-Critical Software T n n n We refer to stimuli as monitored DR C Safety-Critical Software T n n n We refer to stimuli as monitored variables, and responses as controlled variables. We prefix identifiers by a suitable character followed by _ to help identify the role of the identifier. m_ name is a monitored variable, c_name is a controlled variable, k_name is a constant, etc. 13

DR C Safety-Critical Software T n n m_name represents value of the current instance DR C Safety-Critical Software T n n m_name represents value of the current instance of m_name-1 represents value of the previous 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. 14

DR C Safety-Critical Software T n n If m_name is time-discrete, time between m_name DR C Safety-Critical Software T n n If m_name is time-discrete, time between m_name and m_name-1 is t(m_name) - t(m_name-1). In general, t(var) returns time stamp of the instance of var. In a real system it will not be possible to represent R = f(S, Sh) by a single function or function table. 15

DR C Safety-Critical Software T 16 DR C Safety-Critical Software T 16

Safety. Critical Software DR C T tm(cond) is most recent time cond changed from Safety. Critical Software DR C T tm(cond) is most recent time cond changed from False to True 17

DR C Safety-Critical Software T n Examine one “path” as example 18 DR C Safety-Critical Software T n Examine one “path” as example 18

DR C Safety-Critical Software T n The following table evaluates the current value of DR C Safety-Critical Software T n The following table evaluates the current value of the Neutron Overpower (NOP) setpoint. It relies heavily on a number of “natural language expressions”. 19

T DR C Safety-Critical Software u Neutron Overpower Setpoint 20 T DR C Safety-Critical Software u Neutron Overpower Setpoint 20

DR C Safety-Critical Software T n Example: NOP Abnormal 1 setpoint is requested or DR C Safety-Critical Software T n Example: NOP Abnormal 1 setpoint is requested or cancelled 21

DR C Safety-Critical Software T n Already saw NOP setpoint, now NOP sensor trips DR C Safety-Critical Software T n Already saw NOP setpoint, now NOP sensor trips 22

DR C Safety-Critical Software T n And NOP parameter trip 23 DR C Safety-Critical Software T n And NOP parameter trip 23

DR C Safety-Critical Software T n Tolerances & Timing Requirements u Black-box describes behaviour DR C Safety-Critical Software T n Tolerances & Timing Requirements u Black-box describes behaviour of an idealised system - impossible to meet. u Need tolerances in general. u Need timing tolerances in particular. F Timing Resolutions (TRs) F Performance Timing Requirements (PTRs) 24

DR C Safety-Critical Software TR T An event that lasts for TR or longer DR C Safety-Critical Software TR T An event that lasts for TR or longer must be detected TR setpoint m_signal Timing resolution for time continuous stimuli TR Two events at least TR apart must both be detected M_signal time TR M_signal Timing resolution for time discrete stimuli time 25

DR C Safety-Critical Software T n PTRs u The PTR for a stimulus/response pair DR C Safety-Critical Software T n PTRs u The PTR for a stimulus/response pair specifies an allowable processing delay. u Each response must have a PTR specified for it. The PTR applies to the response and the particular stimuli on which the response behaviour depends. The PTR is measured from the time that the stimulus on which the response behaviour depends crosses the system boundary until the time that the associated response crosses the system boundary. 26

DR C Safety-Critical Software T 27 DR C Safety-Critical Software T 27

DR C Safety-Critical Software T n PTRs u The PTR for the pair c-m DR C Safety-Critical Software T n PTRs u The PTR for the pair c-m is meaningless if c does not change its value in response to a change in the value of m. u The time sequence of responses of a controlled variable, c, cannot be altered by consideration of the PTRs for each c-mi pair. 28

DR C Safety-Critical Software T If m does not cause a change in c, DR C Safety-Critical Software T If m does not cause a change in c, PTR has no black-box meaning 29

DR C Safety-Critical Software T Cannot allow this! 30 DR C Safety-Critical Software T Cannot allow this! 30

DR C Safety-Critical Software T Example for c_NOPparmtrip 31 DR C Safety-Critical Software T Example for c_NOPparmtrip 31

DR C Safety-Critical Software T n Anticipated Changes u Information Parnas, D. : On DR C Safety-Critical Software T n Anticipated Changes u Information Parnas, D. : On the criteria to be used in decomposing systems into modules. Communications of the ACM December (1972) 1053 -1058 Hiding is a software design paradigm that was introduced by Parnas in a famous paper in the early 1970 s. u The original version of Information Hiding used anticipated design changes to drive the software decomposition. u It turns out that requirement changes are an even greater source of “secrets”. 32

DR C Safety-Critical Software T 33 DR C Safety-Critical Software T 33

DD C Safety-Critical Software T n Trip Computer Design Description u Uses TCDR as DD C Safety-Critical Software T n Trip Computer Design Description u Uses TCDR as a basis u Adds design information, e. g. pushbutton debouncing u Model changes to a Finite State Machine with an arbitrarily small clock -tick u SRS contained within TCDD 34

DD C Safety-Critical Software T n Finite State Machine (FSM) Model u C(t) - DD C Safety-Critical Software T n Finite State Machine (FSM) Model u C(t) - set of controlled vars at time t u M(t) - set of monitored vars at time t u S(t) - set of state vars at time t u t 0 - time of initialisation u S(t 0) must be known C(tk) = REQ(M(tk), S(tk)) S(tk+1) = NS(M(tk), S(tk)), k=0, 1, 2, 3, . . . 35

DD C Safety-Critical Software T n FSM Model We have very simple states in DD C Safety-Critical Software T n FSM Model We have very simple states in the TCDD. If f_name is a function, f_name-1 is the value of f_name at the previous clock tick. It is a state variable. 36

T DD C Safety-Critical Software n TCDD u Context diagrams u Monitored & Controlled T DD C Safety-Critical Software n TCDD u Context diagrams u Monitored & Controlled Variables u Constants u Main function tables u Natural language expressions u M-I mappings, transfer events u C-O mappings, transfer events u Tolerances, PTRs and TRs u Anticipated changes u Changes from previous freezes 37

DD C Safety-Critical Software T n n We can see how debouncing pushbuttons affects DD C Safety-Critical Software T n n We can see how debouncing pushbuttons affects the behaviour specified in the TCDR. In particular, “NOP Abnormal 1 setpoint is requested or cancelled” is respecified as follows. 38

DD C Safety-Critical Software T n Debounce a pushbutton u Can specify more than DD C Safety-Critical Software T n Debounce a pushbutton u Can specify more than 1 output 39

DD C Safety-Critical Software T n So, NOP Abnormal 1 setpoint is requested or DD C Safety-Critical Software T n So, NOP Abnormal 1 setpoint is requested or cancelled is now defined in terms of f_NOPsp. Abn 1 ON/OFF 40

Safety-Critical Software DD C T TCDR Version TCDD Version 41 Safety-Critical Software DD C T TCDR Version TCDD Version 41

DD C Safety-Critical Software T Modified version of TCDR specification 42 DD C Safety-Critical Software T Modified version of TCDR specification 42

Safety. Critical Software TCDR DD TC version TCDD version 43 Safety. Critical Software TCDR DD TC version TCDD version 43

DD C Safety-Critical Software T n n We need to examine functional timing requirements DD C Safety-Critical Software T n n We need to examine functional timing requirements in more detail. As an example, consider a sensor trip that depends on a sensor (signal) being in a trip state for a sustained period of time. 44

Safety-Critical Software n Since k_HTLFdelay has a tolerance, how do we cope with the Safety-Critical Software n Since k_HTLFdelay has a tolerance, how do we cope with the fact that, from clock-tick to clock-tick, k_HTLFdelay may have different values at different times? 45

Safety-Critical Software Allowing tolerances on timing constants can cause significant problems 46 Safety-Critical Software Allowing tolerances on timing constants can cause significant problems 46

DD C Safety-Critical Software T 47 DD C Safety-Critical Software T 47

Safety-Critical Software 48 Safety-Critical Software 48

DD C Safety-Critical Software T n TCDD REQ M IN I SOF C O DD C Safety-Critical Software T n TCDD REQ M IN I SOF C O Parnas’ 4 variable model. Software Design Parnas, D. L. , Madey, J. : Functional C = REQ(M*), and related to the documents for computer systems. I = IN(M) and C = OUT(O) Science of Computer OUT software through 49

DD C Safety-Critical Software T n n The TCDD specifies “transfer events” (what the DD C Safety-Critical Software T n n The TCDD specifies “transfer events” (what the software must do to trigger getting a software input, I, or emitting a software output, O). The TCDD also specifies the “M-I mappings”, and “C-O mappings” (what the hardware does). 50

DD C Safety-Critical Software T n n The TCDD specifies a modified list of DD C Safety-Critical Software T n n The TCDD specifies a modified list of timing requirements that takes into account the design aspects added in the TCDD. The TCDD also lists a (potentially modified) list of anticipated changes. 51

DD C Safety-Critical Software T Example for c_NOPparmtrip 52 DD C Safety-Critical Software T Example for c_NOPparmtrip 52

Safety. Critical Software DD TC Example function definition in TCDD 53 Safety. Critical Software DD TC Example function definition in TCDD 53

DD S Safety-Critical Software n Software Design Description u Augmented anticipated changes u Module DD S Safety-Critical Software n Software Design Description u Augmented anticipated changes u Module guide u Alternate views u Module designs u Derived timing requirements u Design notes u Supplementary function tables / mappings to TCDD 54

Safety-Critical Software DD S n SDD M REQ OUT IN I SOFin Mp C Safety-Critical Software DD S n SDD M REQ OUT IN I SOFin Mp C O SOFout SOFreq Cp Software Design 55

DD S Safety-Critical Software n Some crucial definitions u Software module u Access program DD S Safety-Critical Software n Some crucial definitions u Software module u Access program u Processing unit 56

DD S Safety-Critical Software n Software module u. A module is a conceptual design DD S Safety-Critical Software n Software module u. A module is a conceptual design unit in the decomposition of software functionality. Modules can be developed in a hierarchical structure where one module can “contain” other modules. This leads to a tree structure of modules. u The top-level modules divide the system into a few broadly defined areas. 57

DD S Safety-Critical Software n Software module - continued u Each top-level module should DD S Safety-Critical Software n Software module - continued u Each top-level module should have a general responsibility (role and purpose) related to encapsulating (hiding) a design decision (a secret). u The functionality enclosed within such a module should contribute to that overall responsibility. u Each of the top-level modules can be further decomposed into smaller modules. 58

DD S Safety-Critical Software n Software module - continued u Each of these smaller DD S Safety-Critical Software n Software module - continued u Each of these smaller modules has its own responsibility and secret, but the responsibilities are more focused. u Modules that require no further refinement are termed “leaf modules” (in keeping with the tree structure). The leaf modules represent the final decomposition of the software system. 59

DD S Safety-Critical Software system Top level modules Class modules Leaf modules 60 DD S Safety-Critical Software system Top level modules Class modules Leaf modules 60

DD S Safety-Critical Software n Access programs u Leaf modules communicate with each other DD S Safety-Critical Software n Access programs u Leaf modules communicate with each other through the use of externally visible access programs. The access programs belonging to a particular leaf module (A) allow other leaf modules to deliver data that the module (A) needs, and to examine the values of data items contained within the module (A). This is the only approved method for one leaf module to access the contents of another leaf module. 61

Safety-Critical Software DD S Module A A. Spro g 1 s_one, s_two Module C Safety-Critical Software DD S Module A A. Spro g 1 s_one, s_two Module C s_other Sets values for s_one, s_two A. Gprog 2 Returns value of s_one Returns value of s_two A. Gprog 3 Module B C. Sprog s_alpha B. Sprog 1 Sets value of s_alpha B. Gprog 2 Returns value of s_alpha a = A. Gprog 3+k_deltat b = B. Gprog 2 -4*k_up. . . Sprog = a + b + A. Gprog 2 62

DD S Safety-Critical Software n Processing unit u. A processing unit is a group DD S Safety-Critical Software n Processing unit u. A processing unit is a group of access programs that is considered to be a single executable unit. The required behaviour of the application is achieved by executing all the processing units defined for the application according to the control structure defined in the scheduler 63

DD S Safety-Critical Software n We use design attributes to drive the software design DD S Safety-Critical Software n We use design attributes to drive the software design process u General design attributes u System structure attributes u Decomposition attributes u Module interface design attributes u Module detailed design attributes 64

DD S Safety-Critical Software n Decomposition attributes u Group 1 - (during and after DD S Safety-Critical Software n Decomposition attributes u Group 1 - (during and after decomposition) F Coverage, Information hiding, Responsibility, Locatability, Hardware isolation u Group 2 - (after interfaces) F Module cohesion, Focus, Maintainability, Localization of data u Group 3 - (after detailed design) F Independence, Uniqueness of data 65

DD S Safety-Critical Software n Information hiding attribute u For any change that has DD S Safety-Critical Software n Information hiding attribute u For any change that has been identified as likely, the functional behaviour directly affected by that change should be isolated in a single module. 66

DD S Safety-Critical Software n Top-level decomposition 67 DD S Safety-Critical Software n Top-level decomposition 67

Safety-Critical Software DD S n Repeated decomposition u Each top-level module can be examined Safety-Critical Software DD S n Repeated decomposition u Each top-level module can be examined to see how it can be further decomposed. The decomposed modules represent classes of modules and should share some distinguishing characteristics in terms of their responsibilities and the secrets they hide from the rest of the system. Typical classes at this level contain sets of: Function drivers; and Device interface modules. 68

DD S Safety-Critical Software n Function drivers u Modules whose sole purpose is to DD S Safety-Critical Software n Function drivers u Modules whose sole purpose is to produce system outputs. n Device interface modules u Modules that provide virtual interfaces to the hardware, completely hiding the characteristics of a peripheral device from the software application. 69

DD S Safety-Critical Software n n Each class module can be further decomposed until DD S Safety-Critical Software n n Each class module can be further decomposed until the leaf modules represent the final decomposition of the system. To implement this process requires heuristics to aid in further decomposing a module, and criteria for stopping any further decomposition. 70

Safety-Critical Software DD S n Decomposing modules u Isolate components likely to change u Safety-Critical Software DD S n Decomposing modules u Isolate components likely to change u Protect data from unintentional/ unwarranted modification by encapsulating it u Look for groups of history dependent entities for possible encapsulation. u Encapsulate interrupt and timer processing. u Encapsulate algorithms specified in the TCDD. u Encapsulate scheduling policies. 71

DD S Safety-Critical Software n Stopping further decomposition of a module u If the DD S Safety-Critical Software n Stopping further decomposition of a module u If the module were to be further decomposed, the secret encapsulated within a newly created module would not be worth hiding. u Further decomposition would require excessive communication between the new modules. u The module is already simple enough to be implemented easily in code. 72

DD S Safety-Critical Software Module Guide extract 73 DD S Safety-Critical Software Module Guide extract 73

DD S Safety-Critical Software Module Dependencies u Need to know what data is required DD S Safety-Critical Software Module Dependencies u Need to know what data is required by which module and which module owns the data u How do we know this? F We have complete functional descriptions of behaviour in the TCDD F A module’s responsibility is represented by functional behaviour as described in the TCDD 74

Safety-Critical Software DD S n Create and refine access programs u Default set of Safety-Critical Software DD S n Create and refine access programs u Default set of access program always exists F Perform processing (update state data, produce a system output) F Initialization program F Programs that provide information about the module’s state data to other modules u Can refine these access programs in a (sort of) systematic way 75

Safety-Critical Software DD S n Criteria while refining access programs Access programs must not Safety-Critical Software DD S n Criteria while refining access programs Access programs must not reveal secret of the module u Each program’s interface is as simple as possible u Each program services its users in a way convenient to the users u Each parameter required by every user u Make choices based on simplifying timing u Parameters of a single access program should all move data in a single direction (does not apply to control variables) u 76

DD S Safety-Critical Software n Once all the modules and module interfaces are decided DD S Safety-Critical Software n Once all the modules and module interfaces are decided we can continue with the detailed design of each module. 77

DD S Safety-Critical Software Module documentation 78 DD S Safety-Critical Software Module documentation 78

DD S Safety-Critical Software Cover page for module Watchdog 79 DD S Safety-Critical Software Cover page for module Watchdog 79

DD S Safety-Critical Software Module-wide internal declarations 80 DD S Safety-Critical Software Module-wide internal declarations 80

DD S Safety-Critical Software Detailed module design for an example access program 81 DD S Safety-Critical Software Detailed module design for an example access program 81

DD S Safety-Critical Software n n Since the decomposition of behaviour in the SDD DD S Safety-Critical Software n n Since the decomposition of behaviour in the SDD is almost guaranteed to be different from the decomposition in the TCDD, it is likely that just a portion of a TCDD function may be implemented in an access program, or that a composition of TCDD functions may be implemented in an access program. This presents a couple of important problems. 82

DD S Safety-Critical Software n n We use the TCDD functions to specify the DD S Safety-Critical Software n n We use the TCDD functions to specify the black-box behaviour of an access program, and so if the access program does not implement a single, complete TCDD function, this black-box behaviour is difficult to specify. It is difficult to verify the SDD behaviour against the TCDD behaviour when the function topologies of the two are different. 83

DD S Safety-Critical Software n The way we overcome these difficulties is by use DD S Safety-Critical Software n The way we overcome these difficulties is by use of “supplementary function tables” (SFTs). The idea here is that we imagine a pseudo requirements specification in which the function topology will exactly match that in the SDD. If such a pseudo requirements specification were to exist, then verifying the SDD against the TCDD could be performed in two steps. 84

DD S Safety-Critical Software n n Verify the SDD against the pseudo requirements specification. DD S Safety-Critical Software n n Verify the SDD against the pseudo requirements specification. Verify the pseudo requirement specification against the TCDD. 85

DD S Safety-Critical Software n n The SFTs are developed during the forward going DD S Safety-Critical Software n n The SFTs are developed during the forward going process, by the software designers themselves, but are not considered “proved”. They are available during the software verification to aid the verification team in the mathematical verification of the software. 86

DD S Safety-Critical Software n The following data flow diagrams illustrate the concept of DD S Safety-Critical Software n The following data flow diagrams illustrate the concept of STFs. 87

DD S Safety-Critical Software n We can use the SFTs, f_x, f_c’, f_y, f_d’, DD S Safety-Critical Software n We can use the SFTs, f_x, f_c’, f_y, f_d’, f_z and f_e’ as references on module cover pages (and in the MG). 88

Safety-Critical Software DD S n Safety-net (a couple of examples) u Safe state (if Safety-Critical Software DD S n Safety-net (a couple of examples) u Safe state (if there is one) is always placed in the right-most column of a function table. This convention can be used to produce code that puts the software into a safe state even in the face of hardware malfunctions. u Sequence checks - uses a baton passing mechanism to check that programs are invoked in the correct sequence, and no program has been “skipped”. 89

DD S Safety-Critical Software n Scheduler u Optimal: a simple infinite loop that just DD S Safety-Critical Software n Scheduler u Optimal: a simple infinite loop that just invokes each processing unit in the required sequence. u Reality: if the hardware cannot support the optimal strategy, we have to try alternative strategies - e. g. F Loop frames - LF 1, LF 2, LF 3, LF 4 F Each LF invokes programs in a way that will satisfy PTRs, and takes advantage of more relaxed PTRs to schedule those programs less frequently. 90

DD S Safety-Critical Software n Processing Unit (PU) Example u PU 16 ECALNP() ESPNP() DD S Safety-Critical Software n Processing Unit (PU) Example u PU 16 ECALNP() ESPNP() ESTNP() EPTNP() {NOP trip fns} Calibrated NOP sensors NOP setpoint NOP sensor trips NOP parm trip 91

DD S Safety-Critical Software n Example of use of loop frames u Straight 136 DD S Safety-Critical Software n Example of use of loop frames u Straight 136 ms PU 5 PU 2 PU 16 PU 13. . . PU 19 PU 11 PU 7 PU 1 PU 3 line version: {read A/Is} (read D/Is} {NOP trip fns} {HTLF trip fns}. . . {LN trip fns} {HTHP trip fns} {HTLP trip fns} {Chan trip} {write A/Os} {write D/Os} 160 350 160 250 pt 92

DD S n Safety-Critical Software Example of use of loop frames u Loop frame DD S n Safety-Critical Software Example of use of loop frames u Loop frame version: PU 5 PU 2 PU 16 PU 19 PU 11 PU 7 PU 1 PU 3 {read A/Is} (read D/Is} {NOP trip fns} {LN trip fns} {HTHP trip fns} {HTLP trip fns} {Chan trip} {write A/Os} {write D/Os} 46 ms LF 1 160 250 pt 46 ms. . . PU 5 {read A/Is} PU 2 {read D/Is} PU 16 {NOP trip fns} PU 19 {LN trip fns} PU 13 {HTLF trip fns} PU 7 {Chan trip} PU 1 {write A/Os} PU 3 {write D/Os} LF 3 160 350 pt . . . 93

DV S Safety-Critical Software n SDD Verification u Verify SDD against pseudo-TCDD have same DV S Safety-Critical Software n SDD Verification u Verify SDD against pseudo-TCDD have same data flow topology. u Verify pseudo-TCDD against TCDD only need to verify those blocks that are different. u Concentrate for now on verifying SDD against pseudo-TCDD. 94

DV S Safety-Critical Software n Proof obligation Result via path 1 must equal result DV S Safety-Critical Software n Proof obligation Result via path 1 must equal result via path 2. REQp(M) = Abstc-1(SOFreq(Abstm(M))) Abstm(M) = SOFin(IN(M)) C = OUT(SOFout(Abstc(C))) 95

DV S Safety-Critical Software n Proof obligation for SDD vs pseudo-TCDD u REQp(M) = DV S Safety-Critical Software n Proof obligation for SDD vs pseudo-TCDD u REQp(M) = Abstc-1(SOFreq(Abstm(M))) u Can prove that we can do the proof piece-wise in blocks. Each block is identified as having equivalent inputs and outputs in the SDD and pseudo. TCDD. (Can make use of SFTs) 96

DV S Safety-Critical Software vs SDD u Example: TCDD 97 DV S Safety-Critical Software vs SDD u Example: TCDD 97

DV S Safety-Critical Software u Proof obligation for example Abstc 1 -1(g 4(g 2(g DV S Safety-Critical Software u Proof obligation for example Abstc 1 -1(g 4(g 2(g 1(Abstm 1(m 1), Abstm 2(m 2))), g 3(g 1(Abstm 1(m 1), Abstm 2(m 2)))) = f 4(f 2(f 1(m 1, m 2)), f 3(f 1(m 1, m 2)) Abstc 2 -1(g 3(g 1(Abstm 1(m 1), Abstm 2(m 2))) = f 3(f 1(m 1, m 2) . . . (1). . . (2) 98

DV S Safety-Critical Software u Piece-wise verification F Possible block boundaries exist on each DV S Safety-Critical Software u Piece-wise verification F Possible block boundaries exist on each set of matching inputs and outputs (matching in pseudo-TCDD and SDD) 99

DV S Safety-Critical Software Block 1 Block 2 Block 3 Block 4 100 DV S Safety-Critical Software Block 1 Block 2 Block 3 Block 4 100

DV S Safety-Critical Software Block 1 u A 1(f 1(m 1, m 2) = DV S Safety-Critical Software Block 1 u A 1(f 1(m 1, m 2) = g 1(Abstm 1(m 1), Abstm 2(m 2)) Block 2 u A 2(f 1*)) = g 2(A 1(f 1*) Block 3 u Abstc 1(f 4(f 2*, f 3*)) = g 4(A 2(f 2*), Abstc 2(f 3*)) Block 4 u Abstc 2(f 3(f 1*, m 2)) = g 3(A 1(f 1*), Abstm 2(m 2)) n n . . . (3). . . (4). . . (5). . . (6) If we now assume that (3) through (6) are verified to be true, then we can proceed by: Substituting for A 2(f 1*)) from (4) into (5) - gives (1), and substituting for A 1(f 1(m 1, m 2) from (3) into (6) - gives (2) So, example demonstrates piece-wise success - if topology is the same. 101

DV S Safety-Critical Software n Lawford, M. , Mc. Dougall, J. , Froebel, P. DV S Safety-Critical Software n Lawford, M. , Mc. Dougall, J. , Froebel, P. , Moum, G. : Practical application of functional and n relational methods for the specification and verification of safety critical software. In Rus, T. , ed. : Proc. of AMAST 2000, Iowa City, Iowa, USA, May 2000. Volume 1816 of LNCS. , Springer (2000) 73 -88. Typically, in a specific block, we compose the SDD tables and manipulate them until we can show that they are equal to the composed pseudo-TCDD tables. There has also been considerable working done in automating these proofs using theorem provers like PVS. 102

Safety-Critical Software DV S n n n Design heuristic helps verification: Get-Process-Set. There are Safety-Critical Software DV S n n n Design heuristic helps verification: Get-Process-Set. There are often cases where timing considerations considerably complicate the verification process. There also some cases where software design decisions complicate the verification. 103

DV S Safety-Critical Software n TCDD SDD Verification 104 DV S Safety-Critical Software n TCDD SDD Verification 104

DV S Safety-Critical Software n Currently, without more advanced automated verification tools, my estimate DV S Safety-Critical Software n Currently, without more advanced automated verification tools, my estimate is that SDD verification accounts for about 30% of the total effort. 105

e od C Safety-Critical Software n Coding u Coding performed from detailed design in e od C Safety-Critical Software n Coding u Coding performed from detailed design in the SDD. u Traceable to the SDD. u Safe even in the face of hardware malfunctions. u Coding from function tables produces well structured, easily verified, code. 106

Safety-Critical Software e od C n FORTRAN 66 Code u Use labelled common to Safety-Critical Software e od C n FORTRAN 66 Code u Use labelled common to construct modules. COMMON /NAMEX/ list of module exported contants F COMMON /NAMEV/ list of module state variables F COMMON /NAMEK/ list of module internal constants F Any program can include any number of ___X common statements, but only three common statements with the NAME of the module F u Challenge to describe safe and readable control structures. u Comments refer to the SDD. 107

Safety-Critical Software e od C Example extract for EWDOG Part 1 108 Safety-Critical Software e od C Example extract for EWDOG Part 1 108

Safety-Critical Software e od C Example extract for EWDOG Part 2 109 Safety-Critical Software e od C Example extract for EWDOG Part 2 109

Safety-Critical Software e od C n Safety-net (again) u Use full word for logical/boolean Safety-Critical Software e od C n Safety-net (again) u Use full word for logical/boolean values, not bits F 16 -bit word: False = 0, True <> 0 F 65, 535 ways to be True, 1 to be False F Make sure True represents safe state, then even if there is a RAM error (even some other hardware errors), there is a 65000 to 1 chance that the software will set the safe state 110

VR C Safety-Critical Software n Code Verification u Typically straight forward and relatively easy. VR C Safety-Critical Software n Code Verification u Typically straight forward and relatively easy. u If code comment indicates VCT (Vertical Condition Table) then analyse code to produce VCT. Afterwards compare with SDD. u If code comment indicates Algorithm (pseudo-code) then analyse code to compare with pseudo-code. 111

Ti ing m Safety-Critical Software n Relationship between TR and PTR u Usually the Ti ing m Safety-Critical Software n Relationship between TR and PTR u Usually the TR for a given m-c pair is dictated by physical characteristics of m. However, nuclear safety analyses make few asumptions about the TR. u TR < PTR is sometimes all we can assume [ts is the sample interval, tp the processing time, then ts+tp PTR. Since tp > 0 and TR is an upper bound for ts, TR < PTR] 112

Safety-Critical Software g in m Ti TRs and PTRs - Basics real world times Safety-Critical Software g in m Ti TRs and PTRs - Basics real world times at which inputs are sampled 113

Ti ing m Safety-Critical Software n Relationship between TR and functional timing requirements u Ti ing m Safety-Critical Software n Relationship between TR and functional timing requirements u What if we have a sustained event? Example: To filter out the effect of a noisy signal we may specify that a sensor trip should be sustained for 400 50 ms before it can cause a parameter trip. This means that the implementation must guarantee that if the sensor trip is sustained for less than 350 ms, the parameter trip must not occur. Similarly, if the sensor trip is sustained for 450 ms, the parameter trip must be recorded. (It can be issued some time later, as long as it is within the PTR for that c -m pair. ) 114

Ti ing m Safety-Critical Software 115 Ti ing m Safety-Critical Software 115

Ti ing m Safety-Critical Software 116 Ti ing m Safety-Critical Software 116

Ti ing m Safety-Critical Software 117 Ti ing m Safety-Critical Software 117

Ti ing m Safety-Critical Software n Why do we need two samples in the Ti ing m Safety-Critical Software n Why do we need two samples in the range? u If we have only one, and it is not on a boundary, then: F Assume ts is constant F Let that sample be the nth sample, including the detection of the event F We know that at least (n-1)ts has elapsed since the actual event F But, actually, nts may have elapsed F However, nts will be greater than d+ R, since only one sample in range 118

ing m Ti Safety-Critical Software n n k_HTLFdelay = 400 50 ms = [d- ing m Ti Safety-Critical Software n n k_HTLFdelay = 400 50 ms = [d- L, d+ R] TR ( L+ R)/2 will suffice but is overly restrictive If ½( L+ R) < ts < ( L+ R), there has to be a sample point in the interval [d- L, d+ R] at which we make the decision concerning the parameter trip, and this point must be such that the previous sample point also lies within [d- L, d+ R]. Mathematically what we are looking 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. 119

ing m Ti Safety-Critical Software PTRs for sustained events 120 ing m Ti Safety-Critical Software PTRs for sustained events 120

Ti ing m Safety-Critical Software n “Seal-in” presents similar but different difficulties. u u Ti ing m Safety-Critical Software n “Seal-in” presents similar but different difficulties. u u n Seal-in is measured from the time a controlled variable changed from e_Not. Trip to e_Trip (if the channel D/O is opened for 125 -200 ms then the channel trip D/O is not allowed to close until a manual reset is perfomed) Turns out to be slightly easier because it is measured from a known time, so only one sample in the range is required Would be very useful to find a more general analysis 121