Software zonder gevaar

Informatietechnologie rukt op in de
veiligheidsindustrie. Denk hierbij aan met IT
doorspekte veiligheidsborgende systemen voor
de procesindustrie, energiecentrales, transport
van fossiele brandstoffen, mobiliteit op weg en
spoor, transport door de lucht, gezondheidszorg
voor diagnostiek en behandeling, en ga zo maar
door. Daarbij moet de veiligheid geborgd worden.
Veiligheid is een helm opzetten in de auto,
functionele veiligheid is een airbag die afgaat
bij een aanrijding om ernstig hoofdletsel te
voorkomen.  Ongelukken kun je nooit helemaal
voorkomen. Dit wordt wel eens geroepen door
betrokkenen als vrijbrief om helemaal niets te
doen om de veiligheid te garanderen. Maar als je
toch al het mogelijke wilt doen, op welke manier
ga je dan te werk? En wanneer is het goed genoeg?

In sommige landen is dit bij wet verankerd. Daar
ben je verplicht om een zogenaamde hiërarchie
van controls in volgorde langs te gaan om de
veiligheid te borgen. Die hiërarchie ziet er
als volgt uit:

	1. Probeer het gevaar te elimineren,
	pas als dat niet lukt mag je door naar 2.

	2. Probeer het gevaar weg te engineeren
	bijvoorbeeld door een slim ontwerp,
	pas als dat niet lukt mag je door naar 3.

	3. Probeer het gevaar via procedures te
	voorkomen, pas als dat niet lukt mag je
	door naar 4.

	4. Probeer het gevaar als het zich
	voordoet effectief en efficiënt aan
	te pakken middels opleiding, training
	en oefening.

Een alledaags voorbeeld: door een kruising
ongelijkvloers te maken elimineer je het gevaar
van botsingen. Op snelwegen is dat de slimste
aanpak. In de stad is het niet zomaar mogelijk
om alles ongelijkvloers aan te leggen, daar
lost men dat met een IT-intensief systeem op:
verkeerslichten. Op plekken waar dat normaliter
niet nodig is hebben we de normale verkeersregels
van rechts heeft voorrang, kortom daarmee probeer
je met procedures het gevaar te weren. Mocht
zich toch een ongeluk voordoen, dan zijn er
de hulpdiensten die door hun opleiding, hun
training en oefening, en de praktijk adequate
hulp verlenen om de impact zo klein mogelijk
te houden.

Een minder alledaags voorbeeld: industriële
mengmachines. Het onderhoud daaraan kan riskante
situaties opleveren. De ene monteur staat
op de lopende band om die na te lopen. Die
ziet dat de andere onderhoudsmonteur bij de
schakelkast staat. Hij roept voor de zekerheid:
de lopende band niet aanzetten, waarop de
ander de lopende band juist aanzet omdat hij
dat verstaat, met dodelijke afloop. Onderdeel
van functionele veiligheid is bijvoorbeeld
het aanbrengen van sensoren die personen
op de lopende band detecteren waardoor deze
onbeschikbaar en onbedienbaar gemaakt wordt,
wat men in de schakelkast of control room van
de fabriek ook doet. Maar ja die sensor moet
natuurlijk niet het productieproces verstoren
door vals-positieven tijdens normaal bedrijf
van de machine. Dat kun je vermijden door voor
de machine een onderhoudsbedrijf te definiëren
waarin het gedrag ervan afwijkt van dat tijdens
normaalbedrijf.

Bij elimineren of weg-engineeren komt
creativiteit en out of the box denken te
kijken. Door je het onmogelijke voor te stellen
kom je op ontwerpen die doeltreffend zijn. Maar
daar kom je niet op als je niet bewust bezig bent
met het mogelijk falen van het systeem. Mensen
die elkaar misverstaan is aan de orde van de dag,
dus daarop anticiperend moet je gevaren door
communicatie weg-engineeren. Een bungeejumpharnas
ontwerpen dat het onmogelijk maakt om te springen
voordat alles goed vastzit.

Voor het weg engineeren van gevaren middels
slimme ontwerpen om de veiligheid ervan
maximaal te borgen bestaan goede hulpmiddelen,
zoals faalanalyses, faalbomen om faalkansen
af te schatten, een internationale norm voor
functionele veiligheid (de IEC 61508) en meer. De
faalkans van hardware, bijvoorbeeld een camera,
ventiel of noodaggregaat, is nog wel te meten,
op te zoeken of te berekenen.

Bij software zit het anders: hoe schat je
de betrouwbaarheid van net geschreven code
in? Met het nauwkeurig administreren van het
defectenverloop tijdens de ontwikkeling, het goed
meten van tussenfaaltijden tijdens het testen,
vergelijkingen maken via benchmarks plus een
flinke dosis geavanceerde wiskunde kom je een
heel eind. Het Handbook of Software Reliability
Engineering is een perfect startpunt om zicht
te krijgen op deze complexe materie.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in de AG.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.