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

▶
static analysis of embedded systems
SMART_READER_LITE
LIVE PREVIEW

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

Apr 02, 2023 692 likes •828 views

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

slide-1
SLIDE 1

Static Analysis

  • f Embedded Systems

Xavier RIVAL

rival@di.ens.fr

slide-2
SLIDE 2

Outline

√ Case study

· Certification of embedded softwares · Demo

Static Analysisof Embedded Systems – p.2/12

slide-3
SLIDE 3

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

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

Outline

· Case study

√ Certification of embedded softwares

· Demo

Static Analysisof Embedded Systems – p.8/12

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

slide-12
SLIDE 12

Outline

· Case study · Certification of embedded softwares

√ Demo

Static Analysisof Embedded Systems – p.12/12