Development

Software-ontwikkeling
Gestintel met onze veiligheid

Gestintel met onze veiligheid

Steeds meer apparaten worden bestuurd door software. De vraag is of dit in keuringen wordt meegenomen. 

© CCO/Pixabay Ben_Kerckx
21 november 2018

De Stint is na een fataal ongeluk voorlopig van de weg gehaald. Maar de RDW had hem goedgekeurd?! Is helemaal niet gek: de RDW is niet ingesteld op het keuren van smartphones op wielen.

Dit is direct aan het testrapport te zien. De test is gebaseerd op een bijzondere bromfiets, dus dat past voor geen meter. En interpretatieruimte in regels die er wel is, wordt niet benut. Dat laatste komt omdat de toetsers vooral veel weten van bromfietsen opvoeren en niets van programmeren.

Die regels zitten op het niveau dat een frame met voor- en achtervork geen breuken of scheuren mag vertonen, niet zijn doorgeroest en niet zodanig zijn vervormd dat de stijfheid en sterkte ervan in gevaar worden. Ja "worden", het staat er echt.

Zolang de chip niet is doorgeroest en deugdelijk bevestigd is, krijg je een OK van de RDW!

Zolang de chip niet is doorgeroest en deugdelijk bevestigd is, krijg je een OK van de RDW! Allemaal eisen aan benzinetanks, lpg-installaties, cng-installaties, verbrandingsmotor, wiellagerspeling, enzovoort, die niet van toepassing of die irrelevant zijn. Dan komt er een haakje: de stuurinrichting danwel het besturingssysteem moet deugdelijk zijn.

Een besturingssysteem is ook software. Dan kan, sterker, moet de RDW die software binnen de kaders onderzoeken. En als het ding op hol slaat of plots gaat stilstaan, is het besturingssysteem ondeugdelijk. Ergo: afkeuren.

De fabrikant verweert zich met een onduidelijk verhaal over wat de bestuurder moet doen om het ding te doen stoppen, maar een deugdelijk besturingssysteem stopt zélf het systeem en voorkomt actief dit soort rare fratsen.

Steeds meer veiligheidskritische apparatuur wordt overgenomen door IT-intensieve systemen met niet alleen heel gevoelige elektronica maar ook shaky software

Juist de RDW zou gewaarschuwd moeten zijn voor dit soort pieremachochels. SUA, ofwel sudden unintended accelaration, is al sinds jaar en dag een bekend fenomeen. Een toets op SUA's zou zo langzamerhand wel in de gereedschapskist van de RDW-toetser moeten zitten. De beroemde case Bookout/Schwarz versus Toyota uit 2007 getuigt daarvan: heel veel gesteggel of het nu wel of geen softwarefalen was. Toyota schikte snel voor 3 miljoen dollar toen experts allerlei problemen in de software blootlegden. SUA's zijn zo algemeen dat er zelfs dashcamcompilaties van zijn. CBS News kopte in 2010 al: Toyota "Unintended Acceleration" Has Killed 89.

Naast de Stint is er ook de Tsinova Ion. Dat is een e-bike van Chinese makelij van zo'n 2.000 euro. Tijdens een review begon het ding uit zichzelf te rijden. Het apparaat was niet meer in de hand te houden. De YouTube van deze review is de moeite waard. De reviewer zegt op een gegeven moment: "zo kapot als dit ding heb ik ze nog nooit gezien".

Toezichthouders en regelgevers realiseren zich nog te weinig dat steeds meer veiligheidskritische apparatuur wordt overgenomen door IT-intensieve systemen met niet alleen heel gevoelige elektronica maar ook shaky software.

Reageer met veel stringenter toezicht en andersoortige toetsers die scherp zijn op hardware- en softwarefalen en hun combinatie. Anders staan we erbij en kijken ernaar terwijl de fietsenmaker al programmerend geheid meer doden zal veroorzaken.

Reactie toevoegen
2
Reacties
Frans Leijse 23 november 2018 08:05

Geheel eens !
Ik zou willen pleiten voor good governance beginselen op soft/hardware ontwikkeling.
Dat begint bij brede en diepe (her)educatie voor producent en toezichthouders. Dat is m.i. de premisse voor het werken vanuit een kwaliteitsparadigma dat kan leiden tot een werkelijk veilig product.

Peter Steenmeijer 22 november 2018 19:59

Ik houd mijn hart vast als steeds meer functionaliteit wordt overgenomen door software. Software ontwerpen is nog redelijk eenvoudig, je hoeft alleen maar op te schrijven wat er van verwacht wordt. Maar goed coderen van software is veel moeilijker dan wordt gedacht. Bovendien lijkt coderen niet sexy te zijn, dus doe je dat zo kort mogelijk in je automatiseringscarrière. Jarenlang is gedacht dat coderen zou worden overgenomen door computers, maar dat is nog steeds niet het geval. Daarnaast wordt teveel uitgegaan van de kwaliteit van de onderliggende hardware. Van techniek is één eigenschap bekend, het gaat een keer kapot en dus moet je elke handeling controleren op het goed functioneren. Software coderen is maar voor 10% het uitvoeren van de gewenste handelingen in het ontwerp en 90% het controleren of de handeling goed is verlopen en de beslissingen bedenken als een handeling niet goed is verlopen. De kosten zitten dus in de foutafhandeling en als dat door de goede onderliggende hardware maar weinig voor komt, dan is de verleiding groot om de foutafhandeling (dus 90%) maar te laten zitten. Veel gehoord : Als dat voorkomt lossen we het wel op. In een administratief programma kan dat nog wel, maar aangezien steeds meer software steeds meer vitale functies uitvoert is een dergelijke houding levensbedreigend. Het controleren of software voldoet aan de hierboven geschetste zekerheid is echter bijna ondoenlijk. Het moet dus in het coderen meteen worden meegenomen, anders kun je het wel vergeten.