2016 11-15 - nvrb - software betrouwbaarheid
Post on 12-Jan-2017
72 Views
Preview:
TRANSCRIPT
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
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?
top related