2005-09-26 - NGI - Softwarekwaliteit In Context

366 views

Published on

Presentation for experienced Software Engineers about developping highly reliable and safety critical complex embedded systems.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
366
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Werkveld: Kerncentrales Luchtverkeersleiding Stormvloedkeringen Fouten kosten veel mensenlevens
  • Veel test-scenario’s zijn direct te relateren aan risico’s die het systeem loopt of die het systeem introduceert: Functioneel gedrag dat veiligheidskritisch is zoals het sluiten van een kering bij hoog water Bijvoorbeeld het handelen naar aanleiding van Stroomstoringen en Uitval van andere systemen, netwerken etc. Maar ook het onderzoeken of gebruikers de user-interfaces begrijpen
  • Zaken die gebeuren tijdens bouwen/installatie beinvloeden wat je weet van de omgeving . Bij Eurontrol bijvoorbeeld bleek dat een masale herstart van alle stations wel eens een stroomstoring kan veroorzaken. Risico’s komen voort uitgevingen en bedreigen omgevingen. Omgevingen veranderen waardoor je risico’s kunnen wijzigen . Een voorbeeld: modificaties aan installaties kunnen spontaan componenten veiligheidskritisch maken Nieuwe soorten risico’s : Spontaan kunnen zaken veiligheidskritisch blijken. Maar het kan blijken dat de scope van je risico’s wel eens te klein is. Een voorbeeld: tot 11 september 2001 was seperatie van vliegtuigen het enige dat veiligheidskritisch was. Na 11 september was deviatie van de route ineens ook veiligheidskritisch.
  • Let op: Meet/a en Meet/b zijn gesynced: tijd moet hetzelfde zijn !
  • Je hebt nog steeds meetfouten, kabelbreuken en schakelfouten: maar de kans is veel kleiner !!
  • Als we rekening gaan houden met deadlocks en redundantie ziet ons plaatje er zo uit: niet echt simpel meer……
  • Three different types of fail-safe behaviour of DCF-77 clocks can kill all communications!
  • 2005-09-26 - NGI - Softwarekwaliteit In Context

    1. 1. Betrouwbare Software Praktijkervaringen met het maken van betrouwbare software Jaap van Ekris
    2. 2. Agenda <ul><li>Wie zijn CIBIT|SERC en Jaap van Ekris </li></ul><ul><li>Wat is software kwaliteit </li></ul><ul><li>Hoe maken we het/ hoe tonen we het aan, aan de hand van: </li></ul><ul><ul><li>Stormvloedkering Oosterschelde </li></ul></ul><ul><ul><li>Luchtverkeersleidingcentrum Eurocontrol </li></ul></ul><ul><ul><li>Kerncentrale Borssele </li></ul></ul>
    3. 3. CIBIT|SERC <ul><li>Adviseurs, coaches, beoordelaars op het gebied van: </li></ul><ul><ul><li>Systeem architectuur </li></ul></ul><ul><ul><li>Software product kwaliteit </li></ul></ul><ul><ul><li>Software proces kwaliteit </li></ul></ul>
    4. 4. Mijn domein: Safety Critical Systems
    5. 5. Extended ISO 9126 - Quint
    6. 6. Eisen aan een softwareproduct <ul><li>Kwaliteit expliciet maken! </li></ul><ul><li>We hebben Quint (of een ander kwaliteitsmodel), dus waarom niet include Quint.*; </li></ul><ul><ul><li>Quint beschrijft geen eisen </li></ul></ul><ul><ul><li>Het implementeren van kwaliteitseisen kost (ook) tijd en geld </li></ul></ul><ul><ul><li>Kwaliteitseisen kunnen onderling conflicteren </li></ul></ul><ul><li>Dus: </li></ul><ul><ul><li>selectie/prioriteitstelling kwaliteitsaspecten noodzakelijk </li></ul></ul><ul><ul><li>aspecten met hoge prioriteit uitwerken tot concrete kwaliteitseisen </li></ul></ul><ul><ul><li>ten behoeve hiervan activiteiten opnemen in requirementsanalyseproces! </li></ul></ul>
    7. 7. Hulpmiddelen: Quintworkshop Het eisen van productkwaliteit
    8. 8. Air Traffic Controll Systeem Webapplicaties voor luchtvaartmaatschappij <ul><li>Bijna nooit alles even belangrijk </li></ul><ul><li>Veel is afhankelijk van de context </li></ul><ul><li>Bijna altijd herkenbaar beeld voor belanghebbenden </li></ul><ul><li>Discussie over verrassingen: waar is security gebleven? </li></ul>Eisen en context….
    9. 9. Hoe te realiseren…… <ul><li>Kwaliteit is lastig </li></ul><ul><li>de *-abilities zijn niet in te bouwen als een feature </li></ul><ul><li>Laten we eens een voorbeeld bij de kop pakken: </li></ul><ul><ul><li>Een veiligheids-systeem mag maximaal maar éé n fout in de 10.000 jaar maken </li></ul></ul><ul><ul><ul><li>Kerncentrales </li></ul></ul></ul><ul><ul><ul><li>Luchtverkeersleidings-systemen </li></ul></ul></ul><ul><ul><ul><li>Primaire waterkeringen </li></ul></ul></ul><ul><ul><li>Dit is statistisch onmogelijk om aan te tonen </li></ul></ul><ul><ul><li>Dit soort systemen zijn te complex voor simulatie </li></ul></ul><ul><ul><li>Toch moet dit aantoonbaar gehaald zijn </li></ul></ul>
    10. 10. Hoe doen we het dan? <ul><li>ISO9001 </li></ul><ul><ul><li>garandeert op geen enkele wijze produktkwaliteit </li></ul></ul><ul><ul><li>is voor watjes </li></ul></ul><ul><li>CMM, zie ISO9001 </li></ul><ul><li>IEC61508 </li></ul><ul><ul><li>ISO9001 als basis </li></ul></ul><ul><ul><li>German V-model </li></ul></ul><ul><ul><li>Risico-analyse drijft alle ontwerpbeslissingen </li></ul></ul><ul><ul><li>Customized process op basis van SIL-levels </li></ul></ul><ul><ul><li>Een geaccepteerde norm door overheid en industrie </li></ul></ul><ul><ul><li>Sterke correlatie met systeembetrouwbaarheid </li></ul></ul>
    11. 11. Customized process: SIL-Levels On-Demand Continuous Operation SIL-1 10 -1 /incident 10 -6 /uur SIL-2 10 -2 /incident 10 -7 /uur SIL-3 10 -3 /incident 10 -8 /uur SIL-4 10 -4 /incident 10 -9 /uur
    12. 12. Het basisproces Acceptance test Functional requirements Technical Specifications Detailed Design Coding Integration test unit test Systeem test <ul><li>Risico-analyse </li></ul><ul><li>Requirements management </li></ul><ul><li>Traceerbaarheid van eisen </li></ul><ul><li>Beheer van ontwerpdocumenten </li></ul><ul><li>Change-management </li></ul><ul><li>Versiebeheer/Configuratiebeheer </li></ul>
    13. 13. IEC61508: SIL4, het begin Acceptance test Integration test unit test Systeem test Functional requirements Technical Specifications Detailed Design Coding <ul><li>Formal methods </li></ul><ul><li>Risk analysis </li></ul><ul><li>Verification of completeness </li></ul><ul><li>Reviews </li></ul><ul><li>Structured testing </li></ul><ul><li>Risk based testing </li></ul><ul><li>Verification of completeness </li></ul><ul><li>Reviews </li></ul>
    14. 14. Een strategie gedreven door risico’s <ul><li>Risico’s sturen de ontwikkel- en testeffort (beslissen wat veel aandacht krijgt) </li></ul><ul><li>Sommige risico’s zijn expliciet onderwerp van studie waarvan testen het sluitstuk vormen </li></ul>Filedetectie faalt OR Detectie faalt Verwerking faalt Signalering faalt OR AND Lus faalt Detectorstat faalt Onderstation faalt Verwerking via VICNet faalt Verwerking via Partylijn faalt OR Inkomende Partylijn faalt Inkomende FEP faalt TOP faalt Uitgaande FEP faalt Uitgaande Partylijn faalt AND Beeldstand Onderstation 1 faalt Beeldstand Onderstation 2 faalt Beeldstand Onderstation 3 faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt
    15. 15. De risico-analyse
    16. 16. Afbreukrisico’s ≠ uitval van het systeem! <ul><li>Functioneel gedrag </li></ul><ul><li>Response-snelheid </li></ul><ul><li>Tolerantie van (gebruikers) fouten uit de omgeving </li></ul><ul><li>Faalgedrag van componenten </li></ul><ul><li>Begrijpbaarheid van het systeem </li></ul><ul><li>Accuraatheid gegevens </li></ul>
    17. 17. Managen van risico’s <ul><li>Het is van vitaal belang de systeem risico’s actueel te houden: </li></ul><ul><li>Je leert van de omgeving nieuwe risico’s te onderscheiden </li></ul><ul><li>De omgeving kan veranderen, en daardoor nieuwe risico’s introduceren </li></ul><ul><li>Nieuwe risico’s kunnen onderkend worden </li></ul>
    18. 18. Redundantie! Hoogtebepaling Aansturing Hoogtemeting Waterkering Diesels Meet a Meet b Stuur a Stuur b Info
    19. 19. Faalkansen Info Hoogtebepaling Aansturing Hoogtemeting Waterkering Diesels Meet a Meet b Stuur a Stuur b Schakelfouten Kans: (10 -6 ) 2 + (10 -6 ) 2 Meetfouten Kans: (10 -6 ) 3 Meter kapot Kans: (10 -5 ) 3 Kabelbreuk Kans: (10 -8 ) 12 Kabelbreuk Kans: (10 -8 ) 4 Kabelbreuk Kans: 3 * (10 -8 ) 2 Schakelfouten Kans: 10 -2
    20. 20. Een patroon Stuur x WD Stuur X :: Functionaliteit StuurX::Diagnose Info Meet a Meet b Diesels Kering Voortgang Functionaliteit Voortgang Diagnose Controle Functionaliteit
    21. 21. Een patroon Stuur x WD Stuur X :: Functionaliteit StuurX::Diagnose Info Meet a Meet b Diesels Kering Schakelfouten Kans = 10 -16 <ul><li>Softwarefouten </li></ul><ul><li>Alfa-kans maximaal 10 -4 </li></ul><ul><li>Beta-kans op diagnose maximaal 10 -4 </li></ul><ul><li>Softwarefouten </li></ul><ul><li>Alfa-kans maximaal 10 -2 </li></ul><ul><li>Beta-kans op Functionaliteit maximaal 10 -4 (=Alfa-kans Stuur X ::Functionaliteit) </li></ul>
    22. 22. IEC61508, SIL4: Een detaileringsslag Acceptance test Functional requirements Technical Specifications Detailed Design Coding Integration test unit test Systeem test <ul><li>Formal design methods </li></ul><ul><li>Risk analysis </li></ul><ul><li>Design Validation </li></ul><ul><li>Design Verification </li></ul><ul><li>Reviews </li></ul><ul><li>Separate test-team </li></ul><ul><li>Structured testing </li></ul><ul><li>Risk based testing </li></ul><ul><li>Verification of completeness </li></ul><ul><li>Reviews </li></ul>
    23. 23. Ontwerpmaatregelen Stuur x ::Functionaliteit <ul><li>Alfa-kans 10 -4 (=SIL-4) </li></ul><ul><ul><li>Ontwerp volledig in Finite State machine/Promela </li></ul></ul><ul><ul><li>Defensief ontwerpen </li></ul></ul><ul><ul><li>Uitwerking in Z-Schema’s </li></ul></ul><ul><ul><li>Verificatie door Universiteit Twente </li></ul></ul><ul><ul><li>Alle communicatie wordt geverifieerd op deadlock en livelock </li></ul></ul><ul><li>Beta-kans op Functionaliteit 10 -4 (=SIL-4)* </li></ul><ul><ul><li>Reductie Common Mode Failures door Multiprogramming </li></ul></ul><ul><li>* met inachtname controlerende werking WD </li></ul>
    24. 24. Ontwerpmaatregelen Stuur x ::Diagnose <ul><li>Beta-kans op Functionaliteit 10 -4 (=SIL-4)* </li></ul><ul><ul><li>Implementatie door middel van gescheiden proces, louter shared memory </li></ul></ul><ul><ul><li>Reductie Common Mode Failures door Multiprogramming </li></ul></ul><ul><ul><li>Ontwerp mag geen korte cycli bevatten </li></ul></ul><ul><ul><li>Ontwerp mag geen buffering gebruiken (=malloc’s) </li></ul></ul><ul><li>Alfa-kans 10 -2 (vanuit consistentie ontwerp SIL-4 gekozen) </li></ul><ul><ul><li>Finite State machine/Promela </li></ul></ul><ul><ul><li>Uitwerking in Z-Schema’s </li></ul></ul><ul><ul><li>Verificatie door Universiteit Twente </li></ul></ul><ul><li>* met inachtname controlerende werking WD </li></ul>
    25. 25. Stuur x : Zonder redundantie StartD W_O_D Sluit b Wacht Init Not Sluit a EN Not Sluit b Sluit a SluitA SluitB Geen waterstand “ Ready” van Diesels Sluit_? “ Sluitt” naar Kering Finished Failed “ Start” naar Diesels
    26. 26. StartD2 Stuur b “ OK” StartD StartD1 “ Start_D” naar Stuur b W_O_D Stuur b > 1 minuut StartD1’ Stuur b geeft “Start_D” “ OK” naar Stuur b “ Sent” StartD3 “ Sent” naar Stuur b “ Start” naar Diesels Init2 Init1 “ Init” naar Stuur b > 1 minuut “ Wacht” Init “ Stuur b “ StartD” W_O_D1 “ Ready” via Stuur b “ Ready” van Diesels “ Ready” naar Stuur b Sluit2 Stuur b “ OK” Sluit_? Sluit1 “ SluitS” naar Stuur b Stuur b > 1 minuut Sluit1’ Stuur b geeft “Sluit” “ Sent” Sluit3 “ SentS” naar Stuur b “ Sluitt” naar Kering Finished Waterstanda < 3 meter EN Waterstandb < 3 meter Failed “ OKS” naar Stuur b StartD4 > 1 minuut “ Sent” van Stuur b Sluit4 “ Sent” van Stuur b Sluit b Wacht Not Sluit a EN Not Sluit b Sluit a SluitA SluitB Geen waterstand Stuur x : Met redundantie
    27. 27. Verificatie…. <ul><li>Peer reviews door 2e ontwerper </li></ul><ul><li>Review door testmanager systeemtesten </li></ul><ul><li>Review door architect </li></ul><ul><li>Reviews door de programmeurs </li></ul><ul><li>Statische Verificatie/ Dynamische Simulatie door Universiteit Twente </li></ul>
    28. 28. IEC61508, SIL 4: Detaillering Acceptance test Functional requirements Technical Specifications Detailed Design Coding Integration test unit test Systeem test <ul><li>Formal design methods </li></ul><ul><li>Risk analysis </li></ul><ul><li>Design Validation </li></ul><ul><li>Design Verification </li></ul><ul><li>Reviews </li></ul><ul><li>Structured testing </li></ul><ul><li>Risk based testing </li></ul><ul><li>Verification of completeness </li></ul><ul><li>Reviews </li></ul>
    29. 29. Een gedetailleerde specificatie W_O_D IN: Ready_Diesels Ready_StuurB While (NOT Ready_Diesels OR Ready_StuurB){ Wait(1 second) } W_O_D1
    30. 30. IEC61508, SIL4: Coding Acceptance test Functional requirements Technical Specifications Detailed Design Coding Integration test unit test Systeem test <ul><li>Only “Safe subsets” allowed </li></ul><ul><li>Coding standard </li></ul><ul><li>Automated verification </li></ul><ul><li>Peer Reviews </li></ul>
    31. 31. Een codingstandard voor C <ul><li>Gebaseerd op “Safer C” van Les Hutton </li></ul><ul><li>Geverifieerd door Lint en 5 andere tools </li></ul><ul><li>Daarna nog eens door een reviewer beoordeeld </li></ul>
    32. 32. Integratietesten <ul><li>Peer reviews in testteam </li></ul><ul><li>Scripts gereviewed door volledige ontwerpteam </li></ul><ul><li>100% dekkingsgraad ten opzichte van: </li></ul><ul><ul><li>Code </li></ul></ul><ul><ul><li>Inputwaarden </li></ul></ul><ul><li>Geautomatiseerde scripts (24x7) </li></ul><ul><li>100Mb/uur aan logging data </li></ul><ul><li>3 maal fout in functie  Overnieuw bouwen </li></ul><ul><li>Nogmaals fouten  Overnieuw ontwerpen </li></ul>
    33. 33. Systeemtesten <ul><li>Peer reviews in testteam </li></ul><ul><li>Scripts gereviewed door volledige ontwerpteam </li></ul><ul><li>Gesimuleerde omgeving 100% compleet </li></ul><ul><li>100% dekkingsgraad ten opzichte van inputwaarden </li></ul><ul><li>Geautomatiseerde scripts (24x7), lopen op 10x normale snelheid </li></ul><ul><li>250Mb/uur aan logging data </li></ul><ul><li>Fout  Rootcause-analyse </li></ul>
    34. 34. Acceptatietesten <ul><li>Testen door volledige team gereviewed </li></ul><ul><li>1e deel volledig gebaseerd op risico-analyse </li></ul><ul><ul><li>Alle top 25 risico’s afgedekt </li></ul></ul><ul><ul><li>Volledig uitgeschreven in scripts </li></ul></ul><ul><ul><li>Alle mogelijke sluitscenario’s doorgelopen </li></ul></ul><ul><li>2e deel is een jaar schaduwdraaien </li></ul><ul><li>Uitgevoerd in de werkende waterkering </li></ul><ul><li>Fouten  Rootcause-analyse </li></ul>
    35. 35. Wil je ook alles testen? <ul><li>Safety Critical kan ook betekenen: dodelijk voor testers </li></ul><ul><ul><li>Falen van het systeem </li></ul></ul><ul><ul><li>Falen van veiligheids-systemen </li></ul></ul><ul><ul><li>Onverwacht gedrag van het systeem </li></ul></ul><ul><li>Testen kan wel eens meer risico introduceren dan het reduceert: </li></ul><ul><ul><li>Het kan altijd fout gaan, maar dat is wat je wilt voorkomen </li></ul></ul><ul><ul><li>Met testen haal je ook “gekke” dingen uit met een systeem </li></ul></ul><ul><ul><li>Je kunt een test-omgeving niet volledig beheersen </li></ul></ul>
    36. 36. Kun je ook alles testen? <ul><li>Praktisch is niet alles haalbaar </li></ul><ul><li>Complex systeemgedrag is krankzinnig moeilijk te doorgronden en simuleren, laat staan testen </li></ul><ul><li>Omgevingen kennen overdimensionering waardoor overbelasting zijn eigen dimensie begint te vormen </li></ul><ul><li>Redundantie kan ook problemen maskeren </li></ul><ul><li>Fail-safe faalgedrag is mooi, maar het introduceert ook zijn eigen klasse van problemen </li></ul><ul><li>De werkelijkheid is gekker dan je ooit kunt bedenken </li></ul>
    37. 37. Onderhoud <ul><li>24x7 Monitoring </li></ul><ul><ul><li>Via Info signalering discrepantie tussencomponenten </li></ul></ul><ul><ul><li>Actieve signalering door BBS (monitoring Oosterschelde) </li></ul></ul><ul><li>Ontwikkeling menselijke onderhoudsschema’s </li></ul><ul><ul><li>Routinematige testen correcte werking NSTA: een maal per maand </li></ul></ul><ul><ul><li>Controles op UPSen: een maal per twee weken </li></ul></ul><ul><ul><li>Extreme scenarios doorlopen: 4 keer per jaar </li></ul></ul>
    38. 38. Maar je kunt niet alles van te voren weten……. Microsoft server crash nearly causes 800-plane pile-up Failure to restart system after 30 days caused data overload. A major breakdown in Southern California's air traffic control system last week was partly due to a &quot;design anomaly&quot; in the way Microsoft Windows servers were integrated into the system, according to a report in the Los Angeles Times. The radio system shutdown, which lasted more than three hours, left 800 planes in the air without contact to air traffic control, and led to at least five cases where planes came too close to one another, according to comments by the Federal Aviation Administration reported in the LA Times and The New York Times. Air traffic controllers were reduced to using personal mobile phones to pass on warnings to controllers at other facilities, and watched close calls without being able to alert pilots, according to the LA Times report. The failure was ultimately down to a combination of human error and a design glitch in the Windows servers brought in over the past three years to replace the radio system's original Unix servers, according to the FAA. The servers are timed to shut down after 49.7 days of use in order to prevent a data overload, a union official told the LA Times. To avoid this automatic shutdown, technicians are required to restart the system manually every 30 days. An improperly trained employee failed to reset the system, leading it to shut down without warning, the official said. Backup systems failed because of a software failure, according to a report in The New York Times. The contract for designing the system, called Voice Switching and Control System (VSCS), was awarded to Harris Corporation in 1992 and the system was installed in the late 1990s, initially using Unix servers, according to Harris. In 2001, the company completed testing of the VSCS Control Subsystem Upgrade (VCSU), which replaced the original servers with off-the-shelf Dell hardware running Microsoft Windows 2000 Advanced Server. The upgrade was installed in California last year, according to the FAA. Soon after installation, however, the FAA discovered that the system design could lead to a radio system shutdown, and put the maintenance procedure into place as a workaround, the LA Times said. The FAA reportedly said it has been working on a permanent fix but has only eliminated the problem in Seattle. The FAA is now planning to institute a second workaround - an alert that will warn controllers well before the software shuts down. The shutdown is intended to keep the system from becoming overloaded with data and potentially giving controllers wrong information about flights, according to a software analyst cited by the LA Times. Microsoft told Techworld it was aware of the reports but was not immediately able to comment.
    39. 39. <ul><li>Vragen ? </li></ul><ul><li>[email_address] </li></ul>

    ×