Static Analysis of Embedded Systems Xavier R IVAL rival@di.ens.fr - PowerPoint PPT Presentation

Static Analysis of Embedded Systems Xavier R IVAL 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