Physical Layer API same as Lab q enq

Physical Layer API (same as Lab) q enq(), deq(), scan() q Periodically Ø if not currently master select non-empty outgoing queue send start condition (capture bus) Function Calls q On Interrupt Ø if bus master and not end of frame send next byte, otherwise send stop condition Ø if bus slave § get byte and process header information, or place into appropriate incoming queue based on previous header information. Ø Deal w/ flow control somehow (control frames for acknowledgement) Ø Deal w/ Security dst port Timer Interrupt and External Interrupt Routines CSE 466 – Fall 2000 - Introduction - 1

A Complete Development Environment Debugging Networking File I/O Kernel Task Scheduling Memory Management Resource Protection Interrupt Handling Task-message Passing Task event management Device I/O Kernel Device I/O Device Drivers File I/O File Creation and Deletion File I/O Directory Structures and Navigation Networking Protocols and device driver support for data communication. Task to Task message passing over a network. Debugging Simulation Monitor based Debugging Hardware Emulator CSE 466 – Fall 2000 - Introduction - 2

Debugging q Simulation Ø you’ve seen the limits of that approach. q In-System Debug (w/ a Monitor) Ø Ability to download code and upload state information (RAM, Regs) Ø Breakpoints § replace instruction w/ SWI or JSR § SWI waits for user commands § On “continue” monitor executes the trapped instruction and returns control to the app Ø Not good for final test unless monitor is part of shipped system Ø Requires system resources: interrupts, RAM, ROM. q HW Emulation Ø A circuit board w/ a socket connector that acts just like real processor. Allows debugging without a monitor Monitor Program R/W code and data space serial interface Debugging Host SW based single stepping Single Stepping in the 8051 ISR for External Interrupt 0 JNB P 3. 2, $ ; Wait Here Till INT 0 Goes High JB P 3. 2, $ ; Now Wait Here Till it Goes Low RETI ; Go Back and Execute One Instruction CSE 466 – Fall 2000 - Introduction - 3

Projects/Reports q Option 1: A final lab assignment … to be negotiated. Ø Some improvement on music player (I think we can do 20 K music at 11 MHz anyway). Maybe Streaming from NT through one player to another player over I 2 C. No upload needed. Ø Chat Ø A PCB for the Music Player w/I 2 C and Serial ports q Option 2: A report/presentation Ø design approaches for some existing system § fuzzy logic controller design § automotive apps and networking (ECU, Airbag, CAN) § Embedded TCP (IP? /I 2 C? ) § Embedded web-servers § Robot architectures § Convergence devices § Object technology for 8 -bit microcontrollers Ø hw that we didn’t cover § motors § watchdog circuits § DAC, ADC. audio codecs § display…vga/lcd § radios § Memory devices and interfaces CSE 466 – Fall 2000 - Introduction - 4

Safety q Examples q Terms and Concepts q Safety Architectures q Safe Design Process q Software Specific Stuff q Sources Ø Hard Time by Bruce Powell Douglass, which references Safeware by Nancy Leveson CSE 466 – Fall 2000 - Introduction - 5

What is a Safe System? Brake w/ local controller Brake Pedal Sensor Processor Bus Engine w/ local controller Is it safe? Add electronic watch dog between brake and bus What does “safe” mean? Add mechanical linkage from separate brake pedal directly to brake Add a third mechanical linkage…. How can we make it safe? CSE 466 – Fall 2000 - Introduction - 6

Terms and Concepts q Reliability of component i can be expressed as the probability that component i is still functioning at some time t. Pi(t) = Probability of being operational at time t burn in period Low failure rate means nearly constant probability 1/(failure rate) = MTBF time q Is system reliability Ps (t) = PPi(t) ? q Assuming that all components have the same component reliability, Is a system w/ fewer components always more reliable ? q Does component failure system failure ? CSE 466 – Fall 2000 - Introduction - 7

A Safety System q A system is safe if it’s deployment involves assuming an acceptable amount of risk…acceptable to whom? q Risk factors Ø Probability of something bad happing Ø Consequences of something bad happening (Severity) q Example Ø Airplane Travel – high severity, low probability Ø Electric shock from battery powered devices – hi probability, low severity safe zone danger zone (we don’t all have the same risk tolerance!) probability PC airplane autopilot mp 3 player severity CSE 466 – Fall 2000 - Introduction - 8

More Precise Terminology q Accident or Mishap: (unintended) Damage to property or harm to persons. Economic impact of failure to meet warranted performance is outside of the scope of safety. q Hazard: A state of the system that will inevitably lead to an accident or mishap Ø Release of Energy Ø Release of Toxins Ø Interference with life support functions Ø Supplying misleading information to safety personnel or control systems. This is the desktop PC nightmare scenario. Bad information Ø Failure to alarm when hazardous conditions exist CSE 466 – Fall 2000 - Introduction - 9

Faults q A fault is an “unsatisfactory system condition or state”. A fault is not necessarily a hazard. In fact, assessments of safety are based on the notion of fault tolerance. q Systemic faults Ø Design Errors (includes process errors such as failure to test or failure to apply a safety design process) Ø Faults due to software bugs are systemic Ø Security breech q Random Faults Ø Random events that can cause permanent or temporary damage to the system. Includes EMI and radiation, component failure, power supply problems, wear and tear. CSE 466 – Fall 2000 - Introduction - 10

Component v. System q Reliability is a component issue q Safety and Availability are system issues q A system can be safe even if it is unreliable! q If a system has lots of redundancy the likelihood of a component failure (a fault) increases, but so may increase the safety and availability of that system. q Safety and Availability are different and sometimes at odds. Safety may require the shutdown of a system that may still be able to perform its function. Ø A backup system that can fully operate a nuclear power plant might always shut it down in the event of failure of the primary system. Ø The plant could remain available, but it is unsafe to continue operation CSE 466 – Fall 2000 - Introduction - 11

Single Fault Tolerance (for safety) q The existence of any single fault does not result in a hazard q Single fault tolerant systems are generally considered to be safe, but more stringent requirements may apply to high risk cases…airplanes, power plants, etc. Backup H 2 Valve Control watchdog protocol Main H 2 Valve Control CSE 466 – Fall 2000 - Introduction - 12 If the handshake fails, then either one or both can shut off the gas supply. Is this a single fault tolerant system?

Is This? Backup H 2 Valve Control common mode failures watchdog handshake Main H 2 Valve Control CSE 466 – Fall 2000 - Introduction - 13

Now Safe? Backup H 2 Valve Control watchdog handshake Main H 2 Valve Control CSE 466 – Fall 2000 - Introduction - 14 • Separate Clock Source • Power Fail-Safe (non-latching) Valves What about power spike that confuses both processors at the same time? Maybe the watchdog can’t be software based. Does it ever end?

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

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

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

Safety Architectures q Self Checking (Single Channel Protected Design) q Redundancy q Diversity or Heterogeneity watchdog protocol Brake Pedal Sensor Computer Brake Computer Bus parity/crc Periodic internal CRC/Checksum computation (code/data corruption) CSE 466 – Fall 2000 - Introduction - 18 Engine Control

Single Channel Protection q Self Checking Ø perform periodic checksums on code and data Ø How long does this take? Ø Is T 0<T 1? parity/crc on the bus Computer (code corruption) Brake Computer Bus q Feasibility of Self Checking Ø Fault Tolerance Time Ø Speed of the processor Ø Amount of ROM/RAM Ø Redundant Memory Subsystems: special hw Ø Recurring cost v. Development cost tradeoff CSE 466 – Fall 2000 - Introduction - 19 Engine Control

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

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

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

1. Hazard Identification – Ventilator Example Human in Loop Hazard Severity Tolerance Time Fault Example Likelihood Detection Time Mechanism Exposure Time Hypoventilation Severe 5 min. Vent Fails Rare 30 sec Indep. pressure sensor w/ alarm 40 sec Esophageal intubation Medium 30 sec C 02 sensor alarm 40 sec User misattaches breathing hoses never N/A Different mechanic al fittings for intake and exhaust N/A Release valve failure Rare 0. 01 sec Secondary valve opens 0. 01 sec Overpressuriza tion Sever 0. 05 sec CSE 466 – Fall 2000 - Introduction - 23

FMEA Example – notably missing time factor! CSE 466 – Fall 2000 - Introduction - 24

Fault Tree Analysis – working backwards q Pacemaker Example single fault hazard CSE 466 – Fall 2000 - Introduction - 25

FMEA – Working Forward q Failure Mode: how a device can fail Ø Battery: never voltage spike, only low voltage Ø Valve: Stuck open? Stuck Closed? Ø Motor Controller: Stuck fast, stuck slow? Ø Hydrogen sensor: Will it be latent or mimic the presence of hydrogen? q FMEA Ø For each mode of each device perform hazard analysis as in the previous flow chart Ø Huge search space CSE 466 – Fall 2000 - Introduction - 26

2. Risk Assessment q Determine how risky your system is W 3 W 2 W 1 1 - - 2 1 - 3 2 1 4 3 2 5 4 3 E 1 6 5 4 E 2 7 6 5 8 7 6 S 1 G 1 E 1 G 2 S 2 G 1 E 2 G 2 S 3 S 4 CSE 466 – Fall 2000 - Introduction - 27 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

Example Risk Assessment Device Hazard Extent of Damage Exposure Time Hazard Prevention Probabil ity TUV Risk Level Microwave Oven Irradiation S 2 E 2 G 2 W 3 5 Pacemaker Pacing too slowly S 2 E 2 G 2 W 3 5 Pacing too fast Power station burner control Explosion S 3 E 1 -- W 3 6 Airliner Crash S 4 E 2 G 2 W 2 8 CSE 466 – Fall 2000 - Introduction - 28

3. Define the Safety Measures q Obviation: Make it physically impossible (mechanical hookups, etc). q Education: Educate users to prevent misuse or dangerous use. q Alarming: Inform the users/operators or higher level automatic monitors of hazardous conditions q Interlocks: Take steps to eliminate the hazard when conditions exist (shut off power, fuel supply, explode, etc. q Restrict Access. High voltage sources should be in compartments that require tools to access, w/ proper labels. q Labeling q 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 CSE 466 – Fall 2000 - Introduction - 29

4. Create Safe Requirements: Specifications q Document the safety functionality Ø eg. The system shall NOT pass more than 10 m. A through the ECG lead. Ø Typically the use of NOT implies a much more general requirement about functionality…in ALL CASES q 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 q Use safe design practices…this is very domain specific, we will talk about software CSE 466 – Fall 2000 - Introduction - 30

5. Implement Safety – Safe Software Language Features Compile Time Checking Run Time Checking Exception Handling Re-use Objects Operating Systems Protocols Testing Regression Testing Exception Testing (Fault Seeding) CSE 466 – Fall 2000 - Introduction - 31

Language Features q Compile Time Checking: Lint like tools Ø No overhead at run time (code size, execution time) Pascal, example of a strongly typed language Program Wont. Compile 1; type My. Sub. Range = 10. . 20; Day = {Mo, Tu, We, Th, Fr, Sa, Su}; var My. Var: My. Sub. Range; My. Date: Day; begin My. Var : = 9; {will not compile – range error} My. Date : = 0; {will not compile – wrong type) Ø But, compile time checking can’t catch range errors CSE 466 – Fall 2000 - Introduction - 32

Error Checking in Software CSE 466 – Fall 2000 - Introduction - 33

Testing CSE 466 – Fall 2000 - Introduction - 34