Static Analysis of Embedded Systems Xavier RIVAL rival@di.ens.fr
Outline Case study Certification of embedded softwares Demo Static Analysisof Embedded Systems p.2/12
Ariane 5 Flight 501 Ariane 5: sattelite launcher successor of Ariane 5, much more powerful higher payload capability first flight, June, 4th, 1996: failure failure report: http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf History of the flight: take-off parameters nominal, normal flight during 36 seconds T + 36.7s: loss of trajectory T + 39s: desintegration of the launcher What is the cause of this trajectory issue? Consequences: > $370 000 000... loss of satellites launcher out of service (more than a year) Static Analysisof Embedded Systems p.3/12
Navigation system Sensors: gyroscopes, inertial units Computers (hardware + software): IRS (Inertial Reference System: integrates sensor data OBC (On Board Computer): computes the action to keep the trajectory correct Actuators: engines of the launcher Fault tolerant, redundant systems: two IRS units, but same software Static Analysisof Embedded Systems p.4/12
Analysis of the failure Resource problem: registers and memory were expensive... programming practice: reduce number of bits to be used e.g., cast 64 bits floating point numbers into signed 16 bits integers In case of an overflow: no local interruption catch (expensive) thus, computer crash + error code returned! Ariane 501 flight: arithmetic fault interuption in IRS computer illegal error code interpreted as regular flight data by OBC improper actions, thus loss of trajectory Static Analysisof Embedded Systems p.5/12
Other Considerations Redundant hardware: useless here all IRS units crashed in the same time in avionics: separate development chains (and teams) Irrelevant computations: faulty computation was irrelevant after take-off (gyroscopes recalibration; useful in the first few seconds only) shutting down a task was considered potentially dangerous Legacy software: the whole system had been used in Ariane 4 successfully, many times... but Ariane 5 was more powerful thus higher horizontal bias values... thus overflow Wrong assumptions, due to legacy software Static Analysisof Embedded Systems p.6/12
Embedded systems software failures Many cases: www.cs.tau.ac.il/~nachumd/horror.html Families of bugs: runtime errors, and other safety problems functional bugs, e.g.: violation of liveness properties unstable control loop specification issues incorrect specifications, invalid specifications... beyond this lecture: what to do if the spec is wrong? user interface issues again, beyond this lecture... Static Analysisof Embedded Systems p.7/12
Outline Case study Certification of embedded softwares Demo Static Analysisof Embedded Systems p.8/12
Development Requirements Rigorous development requirements defined by norms, such as: DO-178 b for avionics ISO 26262, ARP 4754 for automotive industry High certification cost techniques to validate/certify software typically represent a huge cost: unit testing integration testing software maintenance: imposes more testing... Aeronautics, cost of an airplane: airframe: 1/3 engines: 1/3 softwares, avionics: 1/3...... 80 % of which is testing, integration, validation, certification Static Analysisof Embedded Systems p.9/12
DO-178 B Principle Software levels, depending on level of criticality, e.g.: level A: a failure would cause a crash e.g., fly-by-wire software level C: a failure would cause crew overloading e.g., fly management computer level E: no effect on the safety of the flight e.g., IFE (entertainment software)... Software requirement, depending on level of criticality, e.g.: identification of possible failures, and evidence of correctness traceability absence of dead-code unit testing No technique imposed to meet those criteria... but choice based on efficiency in terms of cost/reliability Static Analysisof Embedded Systems p.10/12
Certifying Safety by Analysis Advantages of static analysis: lower cost, better confidence Safety: the software will not crash / cease to function: absence of runtime errors no crash, no violation of application specific constraints Astrée synchronous requirement, i.e., time constraint critical sections should take a bounded amount of time i.e., the software must be responsive recursion is forbidden Absint WCET analysis (Worst Case Execution Time) resource usage no dynamic memory allocation stack usage Absint stack analyzer Beyond safety, functional correctness: usually only testing... (challenge!) Static Analysisof Embedded Systems p.11/12
Outline Case study Certification of embedded softwares Demo Static Analysisof Embedded Systems p.12/12