1. CSE 466 – Spring 2000 - Introduction - 1 The Final  Hardware: probably something on memory mapped I/O (HW and SW)  OS: Probably a task diagram of some kind, related to Tiny  Something related to how the I2C bus works  Something about frames, protocols, and layers…closely related to the physical and transport layers that we discussed in class (not the master/slave one)  A safety question

2. CSE 466 – Spring 2000 - Introduction - 2 Time is a Factor  The TUV Fault Assessment Flow Chart  T0: Fault tolerance time of the first failure  T1: Time after which a second fault is likely  Captures time, and the notion of “latent faults”  T0 – tolerance time for first fault  T1 – Time after which a second fault is likely  Based on MTBF data  Safety requires that  T test <T 0 <T 1 1 st Fault hazard after T 0 ? System Unsafe yes no 2 nd Fault System Safe Fault Detected before T 1 ? yes no yes no hazard?

3. CSE 466 – Spring 2000 - Introduction - 3 Latent Faults  Any fault this is not detectable by the system during operation has a probability of 1 – doesn’t count in single fault tolerance assessment  Detection might not mean diagnosis. If system can detect secondary affect of device failure before a hazard arises, then this could be considered safe Backup H2 Valve Control Main H2 Valve Control watchdog handshake stuck valves could be latent if the controllers cannot check their state. May as well assume that they are stuck!

4. CSE 466 – Spring 2000 - Introduction - 4 Fail-Safe Design (just an example)  On reset processor checks status. If bad, enter “safe mode”  power off  reduced/altered functionality  alarm  restart  Safe mode is application dependent Processor Watchdog protocol failure reset status

5. CSE 466 – Spring 2000 - Introduction - 5 Safety Architectures  Self Checking (Single Channel Protected Design)  Redundancy  Diversity or Heterogeneity Brake Pedal Sensor Computer Bus Brake Engine Control watchdog protocol parity/crc Periodic internal CRC/Checksum computation (code/data corruption) Beef up each link in the chain

6. CSE 466 – Spring 2000 - Introduction - 6 Single Channel Protection  Self Checking  perform periodic checksums on code and data  How long does this take?  Is Ttest < T0?  Feasibility of Self Checking  Fault Tolerance Time  Speed of the processors  Amount of ROM/RAM  Recurring cost v. Development cost tradeoff Computer (code corruption) Computer Bus Brake Engine Control parity/crc on the bus

7. CSE 466 – Spring 2000 - Introduction - 7 Redundancy  Homogeneous Redundancy  Low development cost…just duplicate  High recurring cost  No protection against systemic faults Computer (code corruption) Brake Engine Control Computer Voting Bus could be implemented similar to collision detection

8. CSE 466 – Spring 2000 - Introduction - 8 Multi-Channel Protection  Heterogeneous Redundancy (Diversity)  Protects against random and some systemic faults.  Best if implementation teams are kept separated  Space shuttle: five computers, 4 same 1 different Proc/SW 1 Brake Engine Control Proc/SW 2 Voting Bus

9. CSE 466 – Spring 2000 - Introduction - 9 Design for Safety 1.Hazard Identification and Fault Analysis 2.Risk Assessment 3.Define Safety Measures 4.Create Safe Requirements 5.Implement Safety 6.Assure Safety Process 7.Test,Test,Test,Test,Test

10. CSE 466 – Spring 2000 - Introduction - 10 1. Hazard Identification – Ventilator Example HazardSeverityTolerance Time Fault Example LikelihoodDetection Time MechanismExposure Time Hypo- ventilation Severe5 min.Vent FailsRare30secIndep. pressure sensor w/ alarm 40sec Esophageal intubation Medium30secC02 sensor alarm 40sec User mis- attaches breathing hoses neverN/ADifferent mechanic al fittings for intake and exhaust N/A Over- pressuriza tion Sever0.05secRelease valve failure Rare0.01secSecondary valve opens 0.01sec Human in Loop

11. CSE 466 – Spring 2000 - Introduction - 11 FMEA – Working Forward  Failure Mode: how a device can fail  Battery: never voltage spike, only low voltage  Valve: Stuck open? Stuck Closed? Leaky?  Motor Controller: Stuck fast, stuck slow?  Hydrogen sensor: Will it be latent or mimic the presence of hydrogen?  Thermistor: Looks hot or looks cold?  FMEA  For each failure mode of each device perform hazard analysis as in the previous flow chart  Huge search space

12. CSE 466 – Spring 2000 - Introduction - 12 2. Risk Assessment  Determine how risky your system is S: Extent of Damage Slight injury Single Death Several Deaths Catastrophe E: Exposure Time infrquent continuous G: Prevenability Possible Impossible W: Probability low medium high 1 2 3 4 5 6 7 8 3 4 5 7 6 - 1 2 2 3 4 6 5 - - 1 W3 W2W1 S1 S3 S2 G2 G1 G2 G1 S4 E2 E1 E2 E1

13. CSE 466 – Spring 2000 - Introduction - 13 Example Risk Assessment DeviceHazardExtent of Damage Exposure Time Hazard Prevention Probabil ity TUV Risk Level Microwave Oven IrradiationS2E2G2W35 PacemakerPacing too slowly Pacing too fast S2E2G2W35 Power station burner control ExplosionS3E1--W36 AirlinerCrashS4E2G2W28

14. CSE 466 – Spring 2000 - Introduction - 14 3. Define the Safety Measures  Obviation: Make it physically impossible (mechanical hookups, etc).  Education: Educate users to prevent misuse or dangerous use.  Alarming: Inform the users/operators or higher level automatic monitors of hazardous conditions  Interlocks: Take steps to eliminate the hazard when conditions exist (shut off power, fuel supply, explode, etc.)  Restrict Access. High voltage sources should be in compartments that require tools to access, w/ proper labels.  Labeling  Consider  Tolerance time  Supervision of the system: constant, occasional, unattended. Airport People movers have to be design to a much higher level of safety than attended trains even if they both have fully automated control

15. CSE 466 – Spring 2000 - Introduction - 15 4. Create Safe Requirements: Specifications  Document the safety functionality  eg. The system shall NOT pass more than 10mA through the ECG lead.  Typically the use of NOT implies a much more general requirement about functionality…in ALL CASES  Create Safe Designs  Start w/ a safe architecture  Keep hazard/risk analysis up to date.  Search for common mode failures  Assign responsibility for safe design… hire a safety engineer.  Design systems that check for latent faults  Use safe design practices…this is very domain specific, we will talk about software

16. CSE 466 – Spring 2000 - Introduction - 16 5. Implement Safety – Safe Software Language Features Type and Range Safe Systems Exception Handling Re-use, Encapsulation Objects Operating Systems Protocols Testing Regression Testing Exception Testing (Fault Seeding) Nuts and Bolts

17. CSE 466 – Spring 2000 - Introduction - 17 Language Features  Type and Range Safe Systems: Pascal, Ada….Java? Program WontCompile1; type MySubRange = 10.. 20; Day = {Mo, Tu, We, Th, Fr, Sa, Su}; var MyVar: MySubRange; MyDate: Day; begin MyVar := 9; {will not compile – range error} MyDate := 0; {will not compile – wrong type)  True type safety also requires runtime checking. a[j] := b; what must be checked here to guarantee type safety? range of j, range of b – this takes a lot of time!  Over head in time and code size. But safety may require this.  Does type-safe = safe?  If no, then what good is a type safe system?

18. CSE 466 – Spring 2000 - Introduction - 18 Guidelines  Make it right before you make it fast  Verify during program execution  Pre-condition invariants  Things that must be true before you attempt to perform and operation.  Post-condition invariants  Things that must be true after and operation is performed  eg while (item!=tail) { process(item); if (item->next == null) { throw new CorruptListException(“Item” + item.id()); } else item = item->next; }  Exception handling What should happen in the event of an exception? who should be responsible for this check?

19. CSE 466 – Spring 2000 - Introduction - 19 Exception Handling  Its NOT okay to just let the system crash if some operation fails! You must, at least, get into safe mode.  it is up to the designer to perform error checking on the value returned by f1 and f2. Easily put off, or ignored. Can’t distinguish error handling from not, no guarantee that all errors are handled gracefully.  a = f1(&b,&c) if (a) switch (a) { case 1: handle exception 1 case 2: handle exception 2 … } b = f2(&e,&f) if (a) switch (a) { case 1: handle exception 1 case 2: handle exception 2 … }

20. CSE 466 – Spring 2000 - Introduction - 20 Exception Handling in Java void myMethod() throws FatalException { try { a = x.f1(&b,&c) b = x.f2(&e,&f) } catch (IOException e) { recover and continue } catch (ArrayOutOfBoundsException e) { not recoverable, throw new FatalException(“I’m Dead”); } finally { finish up and exit } Exceptions that are not handled will terminate the current procedure and raise the exception to the caller, and so on. Exceptions are subclassed so that you can have very general or very specific exception handlers. Separates throwing exceptions functional code exception handling

21. CSE 466 – Spring 2000 - Introduction - 21 Safety of Object Oriented SW  Strongly typed at compile time  Run time checking is not native, but can be built into class libraries for extensive modularization and re-use. The class author can force the app to deal with exceptions by throwing them! class embeddedList extends embeddedObject() { public add(embeddedObject item) throws tooBigException { if (this.len() > this.max()) throw new tooBigException(“List size too big”); else addItem2List(); }  If you call embeddedList.add() you have three choices:  Catch the exception and handle it.  Catch the exception and map it into one of your exceptions by throwing an exception of a type declared in your own throws clause.  Declare the exception in your throws clause and let the exception pass through your method (although you might have a finally clause that cleans up first). Compiler will make you aware of any exceptions you forgot to consider!  When to use exceptions and when to use status codes or other means?

22. CSE 466 – Spring 2000 - Introduction - 22 More Language Features  Garbage collection  What is this for  Is it good or bad for embedded systems  Inheritance  Means that type safe systems can still have functions that operate on generic objects.  Means that we can re-use commonalities between objects.  Encapsulation  Means the the creator of the data structure also gets to define how the data structure is accessed and used  Means that the data structure can change without changing the users of the data structure (is the queue an array or a linked list…who cares!)  Re-use  Use trusted systems that have been thoroughly tested  OS  Networking  etc.  next Friday … how would Java be mapped to an embedded processor…say C++ to C51. What restrictions would you need to support that?

23. CSE 466 – Spring 2000 - Introduction - 23 Testing  Regression Test  Fault Seeding

24. CSE 466 – Spring 2000 - Introduction - 24 Safe Design Process  Mainly, the hazard/risk/FMEA analysis is a process not an event!  How you do things is as important as what you do.  Standards for specification, documentation, design, review, and test  ISO9000 defines quality process…one quality level is stable and predictable.

25. CSE 466 – Spring 2000 - Introduction - 25 Next Week  No Monday  Wednesday: PCB Layout Contest  maybe something on UML/java?  Friday  Embedded Java  UML Example for Engine Controller  Demo: Air Trombone  Demo: Talk Application  Demo: Hi Fidelity  Outcome of the PCB contest