Deze presentatie beschrijft de basis van TOPAAS 2.0, inclusief de aanpak om software bouwstenen te identificeren.

1. TOPAAS, een model in de
praktijk
Een pragmatische aanvliegroute voor
de inschatting van betrouwbaarheid
van ICT oplossingen

3. Compiler libraries...

4. OS afhankelijkheden…

5. Testen is extreem beperkt…
• Een simpele 64 bits functie
doortesten kost al 200 jaar
• Efficiëntere aanpakken zijn
in ontwikkeling
• Maar in praktijk is software
niet deterministisch!

6. Resultaten uit het verleden…
• De faalkans van software is
zeer afhankelijk van het
soort gebruik
• Een trackrecord is maar een
zeer beperkte indicatie voor
de faalkans

7. Probleem met de Maeslantkering
• “Bewijs” uit het ongerijmde,
vol met inhoudelijke fouten
• Toonde wel aan dat de
cijfers van TDT niet voor
publieke verdediging
geschikt waren

8. TOPAAS
• Task Oriented Probability of Abnormalities Analysis for
Software
• Ontwikkeld in 2005 tot 2010
• Ontwikkelteam: DNV, Movares, LogicaCMG, Refis,
Intermedion, TU/e
• Reviewteam: Delta Pi, NRG, UvA, Rijkswaterstaat

9. TOPAAS
• Centraal staat
taakuitvoering
• Gebruikt de Bayesiaanse
kansopvatting als basis
• Gebruikt vragenlijst om
deze herhaalbaar te maken

10. Physical View
Development ViewProcess View
Logical View
4+1 Modelling
Scenarios

11. Taakuitvoering

12. Decompositie van taakuitvoering
• Moet onderscheidbaar zijn en zichtbaar gedrag vertonen
• Zo abstract mogelijk
• Alleen splitsen als belangrijke parameters anders worden:
– Ontwikkelteam
– Gebruiksintensiteit

13. Software Bouwstenen

14. Waar op te letten...
• Gaat om direct bij de missie betrokken code
• “Onterecht sluiten” kent een andere faalkans
dan “Niet sluiten”
• Afhandelen van falende hardware is andere
taakuitvoering (en minimaal 2e
orde object)

15. Dingen die geen bouwstenen zijn
• Operating systeem
• Firmware
• Objecten die geen output kennen

16. TOPAAS en tunnels
• Het ontwerp en de functiedefinities zijn in
hoge mate gestandaardiseerd door LTS:
– Afsluiting
– Hoogtedetectie
– Ventilatie
– Nooddeuren
– Incidentdetectie
• Alleen RAMS-eisen liggen nog niet vast

17. Scoring van TOPAAS
• “ONBEKEND” scoren
– gewoon doen als het onbekend is
– scoren als strategische keuze is echt fout
• Er wordt soms veel bijgesleept
– Een competentie management organisatie eisen
– Er moet kwaliteitsmanagement zijn
– De architectuur moet specifieke views hebben
– Traceerbaarheid moet met logisch bewijs zijn
• Soms zijn draaiuren gewoon makkelijker

18. 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

19. Wat praktische cijfers
• Met redelijke cijfers via TOPAAS: “niet sluiten
slagboom” levert 10-3
on demand
• Op basis van ervaringsgegevens: “onterecht
sluiten” ongeveer eens in de 12 jaar

20. Wat gaat er binnenkort gebeuren?
• Publicatie eerste wetenschappelijke TOPAAS
artikel in QREI
• Onderhoud op TOPAAS (versie 2.0) met
onderwerpen:
– Sterkere focus op goed modelleren taakuitvoering
– Meetvoorschrift voor veel parameters