CS 2125 Introduction to Medical Computing Stephen M. Watt
Embedded Software Embedded software is computer software that makes a device perform its function without presenting it as a general purpose computer.
Examples o MP3 player o Digital camera o The braking system in a car o GPS navigation device o Flight control o Cable box o DVD player o Printer o Mobile phone o Video game console o Microwave oven o CT imaging device o Blood pressure monitor o Defibrillator o Pacemaker
What is in Common Don t think of it as a computer No screen/keyboard/mouse Take input signals from sensors/buttons/etc Gives output signals/actuators/switches/etc Often controls something Real-time response needed Need to be able to turn on/off/reset Reliability is essential
Some Resources http://en.wikipedia.org/wiki/embedded_system http://en.wikipedia.org/wiki/medical_software http://ptolemy.eecs.berkeley.edu/publications/papers/02/embsoft/ embsoftwre.pdf
Key Ideas Concurrency Real time response Correctness
Concurrency Processors, Processes, Threads. Process state. Context switching. Pre-emptive vs non-pre-emptive scheduling.
Real-Time Response Real-time response does not just mean fast response. It means the response is predictable and guaranteed to be within certain limits. This means that the worst-case execution time can be proven to always be within the required limit. E.g. anti-lock braking system must control the brakes before the car slides off the road.
Consequences of R-T constraints All libraries used in a software system have to have real-time guarantees. Concurrency must be r-t aware, or controllable. Memory management usually done statically.
Hard RT vs Soft RT Property Hart RT Soft RT Response time Required Desired Peak-load performance Predictable Degraded Control of pace Environment Computer Safety Often critical Non-critical Size of data Small/medium Any Redunancy type Active Checkpoint-recovery Data integrity Short term Long term Error detection Autonomous User Assisted *Adapted from Real-Time Systems, Kanaka Juvva
Real-Time Scheduling *Adapted from Real-Time Systems, Kanaka Juvva http://www.ece.cmu.edu/~koopman/des_s99/real_time/
Correctness Want correct software No, really.
Correctness Really want correct software. Cannot have if (! isasexpected(v1)) { } fprintf(stderr, Error: unexpected value %d\n, v1); exit(exit_failure);
How to Achieve Correctness Correctness proofs. Prove: The program computes the right thing. Prove: No variables overflow, no division by zero, etc.
Proving Programs Correct Not just a convincing argument. Mathematical proof of some precise statement about the execution and computed quantities. Typically annotate program with assertions Prove that if the input conditions are met, then the assertions are true. Assertions may be pre-conditions, post-conditions or invariants.
Proving Programs Correct A change-making algorithm Pre-condition Post-condition * From Essays on Algorithm Analysis, F. D. Lewis http://cs.engr.uky.edu/~lewis/essays/analysis.pdf
Proving Programs Correct Pre-condition: what is true before a block Invariant: what is always true at this point (usually a loop invariant) Post-condition: what is true after a block Some programming langauges (e.g. Eiffel) have native support for these.
Inductive Assertions Flow Chart: diagramatic representation of program execution. Basic blocks have predecessors and successors. Assertions can be attached to the arrows. Start with validity of starting precondition as true and all assertions as unknown. Prove assertions based on validity of predecessor assertions.
Proving Programs Correct Break program into sequential parts with assertions inserted between. For loops, write a loop invariant that expresses the purpose of the loop. Write it so Inv(n) is true after n iterations of the loop. Show the pre-condition guarantees Inv(0) is true. (Basis step) Show that if Inv(k) is true and the loop test L is true, then Inv(k+1) is true. (Inductive step) Show that after the loop iterates the required number of times, the post-condition of the loop is guaranteed.
Proving Programs Correct An Introduction to Proving the Correctness of Programs, Sidney L. Hantler and James C. King, Computing Surveys, Vol 9, No 3, Sept 1976. Program correctness: on inductive assertion methods, J.C. King, IEEE Transactions on Software Engineering, Vol SE-6, Issue 5, pp 465-479.