Het pizza protocol

Enige tijd geleden hoorde ik van collega's dat ze de
software architectuur van een zogeheten C3I systeem
moesten onderzoeken.  C3I is een defensie afkorting die
staat voor Command, Control, Communications, & Intelligence.
Het ging om een systeem waar je een aantal gedistribueerde
dingen hebt, met daar tussen communicatie, een commando
structuur, etc.  Denk hierbij aan een squadron helikopters,
vliegtuigen, of tanks.

Het gaat hierbij om complexe systemen die tegen een
stootje moeten kunnen, waarbij de integrated video bij
min 50 graden gewoon moet blijven werken, en ook bij plus
50 graden.  Gisteren zag ik via CNN beelden van wellicht
dat C3I systeem: live video beelden meteen opgestraald
via een videofoon terwijl de tanks door de woestijn
raasden.

Dat ziet er allemaal indrukwekkend uit.  Maar nu even
over de software.  Uiteraard is alles volledig vercijferd,
zodat anderen wel kunnen luisteren maar niets horen, za'k
maar zeggen.  Toch zat er een foutje in deze gedachtengang,
en dat noemen we wel het pizza protocol.

Wat is nu het pizza protocol?  Het verhaal gaat, dat
journalisten bij het Pentagon het aantal pizza's dat per
dag afgeleverd wordt bijhouden.  Als er een crisis dreigt
uit te breken, dan blijven mensen langer werken, en worden
er meer pizza's besteld.  Met andere woorden:  aan de
hoeveelheid verkeer kun je ook dingen afmeten.  Dat bleek
ook het geval te wezen met het C3I systeem: je kon aan
de hoeveelheid verkeer tussen de verschillende sites zien
wie de commander moest wezen.  Die ontving en verzond
namelijk significant meer informatie dan de anderen.  Om
dit op te lossen komen de pizza's nu in grote witte
vrachtwagens, zodat men dit niet meer kan waarnemen,
aldus dit mooie verhaal.

Je snapt het al, om dan een eenheid uit te schakelen, ga
je eerst mikken op degene met het meeste verkeer, want
dat zal de aanvoerder wel wezen.  Ik dacht dat de
systeemeigenaren niet wakker lagen van het pizza protocol,
en ik geloof dat er niets aan het systeem veranderd is.

Meestal moet er dan ook iets foutgaan, zoals vorige keer
in de Golf oorlog.  De Amerikaanse rekenkamer (The General
Accounting Office) heeft dat onderzocht in een rapport
met de illustere titel: "Patriot Missile Defense: Software
Problem Led to System Failure at Dhahran, Saudi Arabia."
Waarbij System Failure 28 doden betekende.

Wat was er nu aan de hand?  De Patriot batterij kon een
Scud niet meer tracken en daardoor ging de interceptie
helemaal mis.  Dit vanwege een software probleem in het
wapencontrole systeem, een C3I systeem dus.  Als de
Patriot radar een Scud waarneemt, gaat een algorithme
uitrekenen waar je je volgende radar pulse naar toe moet
sturen, om de Scud te tracken en tracen, en uiteindelijk
te onderscheppen.  Het algorithme heeft een onnauwkeurigheid
die bleek af te hangen van de tijd dat de Patriot batterij's
uptime langer was.  Om een idee te geven: na 1 uur uptime
bleek je er al 7 meter naast te zitten, niet zo heel erg,
want het blijft raak schieten, maar na 20 uur uptime zit
je op 137 meter, en is het doel dan al uit zicht.  Toen
het systeem honderd uur up was en er ineens een Scud
aankwam, was de afwijking 687 meter, wat ertoe leidde
dat het systeem de verkeerde kant opkeek, en de Scud
gewoon kon landen op zijn bestemming.

We hebben kunnen horen dat ze het tracen tegenwoordig
aardig onder controle hebben; nu alleen de identificatie
module nog.

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.  Hij schrijft      
maandelijks een column in AG II.  Deze tekst is 
copyright SDU.  Niets van deze uitgave mag zonder
schriftelijke toestemming van de uitgever worden
overgenomen of worden gepubliceerd.