Software Betrouwbaarheid

Theorie en praktijk

J.vanEkris@Delta-Pi.nl http://www.slideshare.net/Jaap_van_Ekris/

Mijn achtergrond

Agenda

• Wat is software?

• Wat is softwarefalen?

• Zijn al die systemen wel “well designed”?

• Voorwaardescheppende aanpak

– DO 178B

– IEC 61508 familie

• Kwantificerende aanpakken

– Reliability Growth Modelling

– TOPAAS

Mijn persoonlijke frustratie…

Software faalt

Constructief/

Electromech.

falen

Systeem faalt

in missie

Software sluipt binnen…

• Mechanical control

• Electrisch Relais (±1860)

• PLC (±1968)

Software is de trend

• Soms technisch noodzakelijk

• Klanten willen het:

– Flexibeler

– Lichter

– Kleiner

– Enabler voor proces verandering

Is dit de essentie van software?

Of is dit de essentie van software?

Een RAMS-blik

• Software is een manier om functies te realiseren

• Software zonder functie kan niet falen!

Bugs zijn van alle tijden

Software is fragiel…

• USS Yorktown (CG-48)

• Testomgeving “Smart Ship” program

• Invoer van een “0” leidt tot totale uitval

– voortstuwing

– wapensystemen

Falen is weigeren te werken

• “Het systeem hangt”

• Meest genoemde faalvorm in risico analyses

• Komt in de praktijk minder voor dan men vermoed

• Is vaak de minst desastreuze faalvorm

Onjuist/onterecht handelen is ook falen!

• Vaak wordt vergeten dat software zich actief tegen je kan keren

• Is daardoor ook het meest destructief

• Deze fout komt vrij veel voor

Systematisch falen?

Software is deterministisch en

gedraagt zich identiek, ongeacht de machine

Alan Turing (1936)

Determinisme heeft gevolgen

• Redundante Software met zelfde inputs zal op dezelfde manier de fout ingaan, dus β=1

• Alleen multiprogramming leidt tot onafhankelijk falen

Een wake-up call

• 10.000 uur full-time getest

– verschillende teams

– verschillende hardware

– Niets gezien

• Ruim 42.000 maal exact dezelfde test herhaald

– 42.000 keer goed

– Maar zeer significant aantal niet!

The impact of a mandelbug

1,E-05

1,E-04

1,E-03

1,E-02

1,E-01

1,E+00

4.35 4.36 4.37

Ch

ance

of

Failu

re (

Loga

rith

mic

Sca

le)

Platform Version

Known unreliability Function M versus Version

Foutsoorten

• Bohrbug: iets gaat op een eenvoudige (deterministische) manier niet of verkeerd

• Mandelbug: een fout waarvan de condities zo complex zijn dat hij zich op een chaotische of niet-deterministische manier manifesteert

Een broedplaats voor Mandelbugs

De onderliggende oorzaak

Omgevingstemperatuur > 20°C

CPU neemt gas terug om

oververhitting te voorkomen

Buffer loopt regelmatig vol en wordt

leeggegooid om permanent achterlopen

te voorkomen

Meer dan 300ms metingen weg

Kritieke noodsituatie gemist

En is dit softwarefalen?

• Altimeter gaf verkeerde hoogte aan

• Autothrottle ging automatisch op “retard” modus

• Softwarefout of bedieningsfout?

Gelijke software, gelijke kansen?

• Weigeren te sluiten tgv softwarefalen?

• Onterecht sluiten tgv softwarefalen?

Één stuk software kent vele faalkansen

Functie Weigeren Onterecht

Prim. Beveiliging Q=10-4 λ=10-7/uur

Sec. Beveiliging Q=5*10-3 λ=10-8/uur

Tert. Beveiliging Q=10-3 λ=10-8/uur

Faalkans

Is eigenlijk een Restkans, gegeven een systeem dat:

• “Fit for purpose” is

• goed ontworpen is

• Goed onderhouden wordt

Simplicity is prerequisite for reliability

Edsger W. Dijkstra (1975)

Is het überhaupt maakbaar?

• Baggageafhandeling – 9 KM transportband

– 35 KM rails

– 4000 karretjes

– 4000 KM netwerkkabel

– 92 PLC’s

– 300 servers

• Na 10 jaar “verbeteren” volledig afgeschreven

Het tart alle wetenschap…

• High-level besturing is in principe NP-compleet

– “Reliable Delivery”requirement

– Zeer dynamische omgeving

• Wachtrijtheorie op een ongekende schaal

• Proces bevat veel 2e orde (en hoger!) regellussen

2e orde regellussen komen meer voor

• Overdrukinstallaties voor het MTK

• Verwarmingsinstallaties

• Schutfunctie bij watermanagement

Goed ontworpen systemen?

• Trackrecord van de industrie is niet zo goed

• Industrie staat stijf van de autodidacten

• Onderschatting complexiteit is aan de orde van de dag

Bepaalde kennis schaalt niet

Software-ontwerp is een opeenstapeling

• Applicatie

• Platform / Blocks

• Operating System

• Firmware

En het gaat zeker niet altijd goed…

• Complexiteit wordt routinematig onderschat

• Men heeft geen begrip van het systeemgedrag

• Systeemintegratie wordt niet serieus opgepakt

• Men is te makkelijk met wijzigen in productie

Ook bij serieuze projecten…

Hergebruik is riskant!

Zelfs een bewezen ontwerp

• Ariane 5

• Hergebruik groot deel van flight management

• Ander vermogen had impact op niet vastgelegde aannames

Systeem ontwerp is een vak!

• Grotere systemen vereist veel ervaring en inzicht

• Veel traditionele partijen hebben dit niet in huis!

Er is altijd een restrisico

Restrisico…

• Capers-Jones:

– minimaal 1 fout per 10 KLoc

– Gemiddeld 4 fouten per KLoc

• Industrie concensus is dat software nooit beter zal zijn dan

– 10-5 on demand

– 10-9 per uur

10KLoc in perspectief…

61.000 KLoC

39.300 KLoC

24.700 KLoC

20.200 KLoC

15.000 KLoC = 6000 manjaar

11.800 KLoC

9.900 KLoC

4.500 KLoC

2.400 KLoC

2.300 KLoC

400 KLoC

40 KLoC

10 KLoC

M 10 M 20 M 30 M 40 M 50 M 60 M

Facebook

Windows 7

F-35 Control Systems

Linux Kernel 4.2

Linux Kernel 3.6

Android OS

Firefox Browser

DVD Player

Linux kernel 2.4.2

Windows 3.1

Space Shuttle

Average iPhone app

Unix V1.0

Een paradox

Het effect van proces-verbetering

CMM Level Defect Removal Efficiency

1 85%

2 89%

3 91%

4 93%

5 95%

DO-178B/C en DO-278

• Gebruikt in Avionics (DO-178 B/C) en Air Traffic Control (DO-278)

• Geen brede industrieconcensus bij opzet

• Wel geaccepteerd door Amerikaanse en Europeese toezichthouders

DO-178B, nivo’s

Level Impact Target Reliability (INDICATIEF)

A Catestrofaal 10-9/vlieguur

B Gevaarlijk 10-7/vlieguur

C Majeur probleem 10-5/vlieguur

D Klein 10-3/vlieguur

E Geen effect

DO-178B, maatregelen

Level # Maatregelen Waarvan Verificatie

D 28 8

C 57 32

B 65 39

A 66 40

Waar wordt fouten geintroduceerd?

Falen ≠ Fouten

• Je hebt een keten nodig om van een fout naar falen te komen

• Niet elke fout leidt tot falen

• Niet elke fout is veiligheidskritisch

• In Fail-To-Safe omgeving helpen fouten vaak met het halen van de safety case

Er is natuurlijk vaak wel een correlatie…

Oordeel over DO-178B

• Statistiek: 1,4 veiligheidskritische fout/KLoC, wat gevoelsmatig niet spectaculair goed is

• In praktijk erg gericht op aantoonbaarheid naar toezichthouder (FAA of EASA)

• Erg test/verificatiegedreven, met name gericht op systematisch falen

Softwaretesten is ineffectief

• Het volledig testen van een stateless 64-bit systeem kost 2 eeuwen

• Hoe ga je vaststellen of het gedrag ook correct is?

• Complexere fouten vindt je er niet mee…

De waarde van testen

Testing can be used to show the presence of bugs, but never to

show their absence! Edsger W. Dijkstra (1969)

Mijn persoonlijke gevoel bij een testgedreven aanpak

ISO/IEC-61508

• Beantwoord de vraag “Wat is de industrie baseline?” voor veiligheidskritische functies

• Beantwoord defacto de vraag “wanneer ben je verwijtbaar nalatig?”

Afstammelingen ISO/IEC-61508

• IEC-61511 (Proces Industrie)

• IEC-61513 (Nucleair)

• IEC-62061 en ISO-13849 (Machines)

• IEC-62279 / CENELEC (Rail)

• ISO-26262 (Automotive)

Basisgedachte

• Beschrijft een basisproces

– Oa. Risico-analyse

• Beschrijft de SIL-levels

• Beschrijft de (aanvullende) maatregelen die je moet nemen

IEC 61508: SIL levels

Aantal maatregelen per level

SIL Level Verplicht Afgeraden

SIL-1 16

SIL-2 27 2

SIL-3 57 2

SIL-4 61* 3

* Waaronder: “Gij zult een formeel wiskundig correctheidsbewijs leveren”

Formele methoden...

• Op wiskunde gebaseerde ontwerpmethodiek

• Specificaties moeten in formele taal

• Het ontwerp is tevens wiskundig bewijs dat de applicatie specificatie invult

IEC 61508: A process for safety critical functions

Code Generation

Veel voorkomend misverstanden

• We gebruiken SIL-3 PLC’s dus…

• We gebruiken SIL-3 bouwstenen dus…

• We gebruiken een Sil-3 oplossing dus…

maar SIL-3 stelt ook eisen aan

specificeren, integreren en testen!

De waarde van de IEC61508

• Het is een (intuitief) zinnige aanpak

• De maatregelen, zeker op de hogere SIL-nivo’s, voegen echt waarde toe maar zijn soms ook echt pittig

• De mensen die op dit nivo kunnen werken zijn zeer hoogwaardig maar ook zeer schaars

• Aantal partijen in Nederland dat SIL-4 serieus kan aanbieden is op een hand te tellen

Omkeren relatie SIL en target reliability?

Het kookboek alleen is dus niet voldoende

Een echt voorbeeld

Hoe kan zoiets nu misgaan?

Commitment en diepgang mensen

• Romeinen zetten architecten onder de boog bij weghalen steigers

• Boeing en Airbus laten lead-engineers meevliegen bij de eerste testvluchten

• Dijkstra zette zijn “rekenmeisjes” aan de overzijde van tewaterlatingen

Gebrek aan wederkerigheid is een issue

• Hoe overtuig je stakeholders van kwaliteit een systeem?

• Waar richt je als eerste je pijlen op in je (RAMS-) verbetercyclus?

Monte Carlo Testing

• Test het systeem op basis van “Random” input

• Verifieren of het antwoord klopt is uitdagend, analyse waarom het fout gaat nog meer

• Kan bij complexere systemen erg lang duren

Reliability Growth Modelling

• Gebruikt historische data over fouten om toekomstige betrouwbaarheid te voorspellen

• Er zijn meerdere modellen, maar allemaal asymptotisch

2 primaire smaken

Time

Concave Model

Rel

iab

lity

Time

S - Model

Rel

iab

ility

Voorwaarden voor gebruik

• Testen moet met toekomstig gebruik te relateren zijn

• Vereist een minimum aantal fouten om toe te kunnen passen

• Registratie van fouten moet zeer nauwkeurig plaatsvinden

Methodische problemen met RGM

• Fouten, MTBF en failure on demand worden door vele modellen als gerelateerd gezien

• Meeste modellen maken geen onderscheid tussen verschillende functies van software

• Aanname van gestage “afname van fouten” matcht niet met praktijk

• Aanname van “uniforme foutdistributie” klopt in praktijk niet

Praktische problemen met RGM

• Modelselectie is erg uitdagend (er zijn wel hulpmiddelen voor)

• Bijhouden registratie is een serieuze belasting

• High reliable systems zijn vaak te goed om het minimum aantal fouten te halen

• Vraag is of een afnemer een hoog aantal fouten accepteert!

Waarde van RGM

• Het is kwalitatief een van de beste praktische benaderingen

• De grote lijn klopt het vaak wel

• Wetenschap is geinteresseerd

– Verhelpt methodische fouten

– Maakt het praktischer toepasbaar

TOPAAS

Task Oriented Probability of Abnormalities Analysis for Software

• Centraal staat dus de functie-uitvoering door software

• Bepaalt de restkans dat een goed ontworpen systeem zich random misdraagt (Mandelbugs, of goed verstopte Bohrbugs)

• Vereist wat van de foutenboom (moet functie van software ook benoemen)

Bayesiaanse kansopvatting

• Als je geen kans kunt bepalen, dan vraag je een expert

• Het vertrouwen dat de expert in het systeem heeft, is dan de faalkans

Een tweetrapsraket

Werkelijke Faalkans

Expert afschatting

2 TOPAAS

afschatting

• Gebruikt een expertpanel om tot een intersubjectieve afschatting te komen van de faalkans

• Gebruikt vragenlijst om het expertpanel te simuleren

Decompositie van taakuitvoering

• Moet onderscheidbaar zijn en zichtbaar gedrag vertonen

• Zo abstract mogelijk

• Alleen splitsen als belangrijke parameters anders worden:

– Ontwikkelteam

– Gebruiksintensiteit

Basisopzet TOPAAS

• Basisfaalkans is 1

• Bij toevoegen kennis verbeterd deze faalkans

Typische Resultaten

• Voor een normale ontwikkelaar 10-4 is realistisch:

– Systems Engineering aanpak

– JSTD-016 goed ingezet

– Testen grondig doen

• Voor een goede ontwikkelaar is 10-5 realistisch:

– IEC 61508, SIL-4

– Goed testen van primaire taakuitvoering

Hoe betrouwbaar is TOPAAS zelf?

Werkelijke Faalkans

Expert afschatting

2 TOPAAS

afschatting

R² = 0,9363

0

1

2

3

4

5

0 1 2 3 4 5 Expert Opinion (10-x)

Expert Opinion vs. Model Estimate

Mo

del

Ou

tco

me

(10

-y)

Wetenschappelijke studies geven

aan dat in het algemeen experts

conservatief zijn. Maar:

• Waren deze experts dat ook?

• Hoe erg conservatief dan?

Praktische problemen met TOPAAS

• Wordt soms zeer slordig toegepast

• Soms is berekenen op basis van velddata gewoon makkelijker en betrouwbaarder

• Men schiet regelmatig door met de “modules”

• Hoe kom je van Q naar een λ?

Waarde van TOPAAS

• Levert altijd betrouwbaarheidsgetal op

• Wetenschap is geinteresseerd

– Meerdere vergelijkbare modellen

– TOPAAS is de enige die ook wordt toegepast

Conclusies TOPAAS

• Minst slechte alternatief als:

– RGM niets oplevert

– Monte Carlo testen te duur wordt

• Vereist kennis over de opbouw van het systeem en de totstandkoming ervan

Conclusies (1)

• Software is enorm fragiel

• Softwarebetrouwbaarheid is erg moeilijk te maken

– Systemen simpel/bouwbaar houden is essentieel

– Volgen IEC 61xxx is eigenlijk gewoon een vereiste

– Mensen maken het verschil

Conclusies (2)

• Software betrouwbaarheid is moeilijk te kwantificeren

– Vereist echt aandacht voor “goed ontwerp”

– Methodes zijn er wel

• Kwantificeringsmethode moet per geval bekeken worden – Als er genoeg representatieve velddata is, gewoon gebruiken

– Als RGM toepasbaar is, gewoon doen

– Hou rekening met het toe moeten passen van TOPAAS

Vragen?