Connexxion: 'Handelingsfout oorzaak botsing ParkShuttles'

Het onderzoek dat busmaatschappij Connexxion heeft ingesteld na de botsing van twee onbemande ParkShuttle-bussen vorige week in Rotterdam, heeft aangetoond dat een handelingsfout in combinatie met een ongelukkige samenloop van omstandigheden de oorzaak van het ongeluk was. Het incident begon met een communicatieprobleem tussen een van de bussen en de centrale computer. Daarom stopte de bus totdat er weer contact mogelijk was. Het voertuig blokkeerde toen de brug, zodat twee andere bussen er ook niet langs konden en aan weerszijden van de brug bleven wachten.

Het voertuig met de storing werd toen naar de eerstvolgende halte gestuurd om de brug weer vrij te maken. Hierna werd het baanvak echter per ongeluk tweemaal vrijgegegeven, waardoor beide ParkShuttles tegelijk de brug op reden. Het obstakeldetectiesysteem probeerde de voertuigen nog te stoppen, maar de remweg van de bus was te lang. Het systeem is namelijk bedoeld voor stilstaande voorwerpen, terwijl hier twee bussen elkaar tegemoet reden, zodat het toch tot een botsing kwam. De kreukelzones vingen de klap op en het passagierscompartiment bleef intact.

Connexxion zal in samenwerking met 2getthere, fabrikant van de ParkShuttles, maatregelen nemen om een herhaling van het ongeluk te voorkomen. De dekking van het communicatienetwerk zal worden verbeterd, de software zal worden aangepast, evenals de procedures die het bedienend personeel moet volgen. De aanpassingen zullen naar verwachting nog voor het eind van dit jaar gereed zijn. Daarna volgt een testfase met de overgebleven vier onbeschadigde bussen. Wanneer de twee bij het ongeluk betrokken voertuigen weer gerepareerd zullen zijn is nog niet bekend. Connexxion kan dan ook nog niet zeggen wanneer het systeem weer volledig in gebruik zal worden genomen.

Reacties (91)

[JeanJeremy]

ik vind dat eigenlijk best verontrustend:

Het systeem is namelijk bedoeld voor stilstaande voorwerpen, terwijl hier twee bussen elkaar tegemoet reden, zodat het toch tot een botsing kwam

[psyBSD]

Heb je wel gelijk in, staat waarschijnlijkop de TODO lijst van 1.1

[Robinski]

en dan te bedenken dat dit eigelijk 2.0 al was

[Oceria]

Deze situatie had nooit voor mogen komen: doordat een mens het baanvak twee keer vrij gaf (een keer voor elke bus die voor de brug stond te wachten) is het ongeluk gebeurd. Met de software en hardware is dus niks mis.

Sterker nog: het laat zien dat de software zelfs in situaties buiten het kenveld nog de schade weet te beperken: door te remmen werd de gecombineerde snelheid dusdanig verlaagd dat de passieve veiligheids systemen (de kreukelzones) niet overvraagd werden.
Als er passagiers aan boord waren geweest was de kans groot dat dezen hoogstens met kleine verwondingen de bus hadden kunnen verlaten, terwijl een persoon het systeem buiten de operationele parameters had gebracht!

[denkster]

En waarom geeft die operator twee keer vrij? Omdat er niets begon te bewegen. En waarom begon er niets te bewegen?
Omdat beide bussen elkaar zien staan, op gelijke afstand van de brug, dus met dezelfde prioriteit. Deadlock!

[SunnieNL]

waar haalt iedereen dat deadlock toch vandaan?
Er wordt nergens aangegeven dat dit het geval was..

De bussen stonden stil op gelijke afstand van de brug (als dat al zo was.. ze zouden dan dus precies op het midden van de brug botsen).

Mogelijk is het centrale systeem wel zo ontwikkeld dat het op zo'n moment 1 bus vrijgeeft en de andere laat staan.. Dan krijg je dus ook geen deadlock

[Jaco69]

Als je twee bussen tegen elkaar aan kan laten rijden door welke handeling dan ook dan lijkt me dat toch een systeem fout die in de software opgelost moet worden.

[Anoniem: 120782]

dan lijkt me dat toch een systeem fout die in de software opgelost moet worden.

van het remote bedieningspaneel ja : \

[Anoniem: 55657]

Nou nee, ligt er volgens mij maar net aan wat de opzet is geweest. Als van meet af aan bedoelt is dat een persoon de baanvakken vrij geeft na problemen en de rest van het systeem daarop ontwikkeld is dan is het geen systeemfout, maar een menselijke fout. Valt alleen nog een compliment aan de software te maken dat het ook ingreep buiten haar specificaties.

[Gé Brander]

Inderdaad. Je zou toch verwachten dat zo een systeem alle mogelijke variabelen in ogenschouw neemt. Dus stilstaande, achteroprijdend en tegemoetkomend verkeer.

Ik zal niet snel instappen....

[To_Tall]

heb er een keer ingezeten is best grappig....

[denkster]

Het is van de gekke ALS ze geen rekening zouden houden met bewegende obstakels.
Dit lijkt me een gevolg van een verouderd concept: een systeem met baanvakken.
In Mumbay (Bombay, India) werken ze met GPS in elke trein. Alle treinen broadcasten voortdurend hun positie en snelheid. Als een trein een voertuig te dicht nadert stopt hij automatisch. Daardoor kunnen de treinen met tussenruimte van 3 à 4 minuten rijden, wat onmogelijk veilig is te doen met baanvakken.
Je moet rondkijken in de wereld, niet telkens het wiel opnieuw willen uitvinden.

[Anoniem: 25693]

je vergeet alleen 1 ding......op een treinspoor rijden alleen treinen....wat nou als er hier niet alleen deze voertuigen rijden maar ook andere voertuigen die geen GSM signaal uitsturen? Dan is jouw oplossing opeens totaal nutteloos.

Dat hele GPS gebeuren wordt overigens hard aan gewerkt....zoiets implementeer je alleen niet in 2 dagen ofzo. De treinen zelf moeten aangepast worden en ook heel de treininfrastructuur door het hele land (denk dat je het met me eens bent dat 2 verschillende botsbeveiligingen een beetje link is).

[Brons]

Op zo'n moment zou je toch willen dat er een mens achter de knuppel zat die zelf dingen kan beslissen. De software werkt altijd perfect, maar als het niet weet wat het moet doen houdt het gewoon op.

@webfreakz.nl, als je het artikel had gelezen kon je zien dat het wagentje dat wel zag, maar omdat de remweg te kort was ging het toch fout.

[Qwerty-273]

Hierna werd het baanvak echter per ongeluk tweemaal vrijgegegeven, waardoor beide ParkShuttles tegelijk de brug op reden.

Blijkbaar zat er een knuppel in de centrale die de baan twee keer heeft vrijgegeven. Of was het een fout in de software? dat wordt niet echt duifelijk verteld.

[Anoniem: 125773]

Hierna werd het baanvak echter per ongeluk tweemaal vrijgegegeven, waardoor beide ParkShuttles tegelijk de brug op reden.

Blijkbaar zat er een knuppel in de centrale die de baan twee keer heeft vrijgegeven. Of was het een fout in de software? dat wordt niet echt duifelijk verteld.

Het is juist heel logisch om beide banen weer vrij te geven. Het is de bedoeling dat alle bussen weer gaan rijden.

De software had moeten weten dat er aan beide kanten een bus stond en ze na elkaar laten vertrekken.

[Milt]

Ik dacht ook eerst aan een eventuele programmeerfout maar waarschijnlijk is het als volgt gegaan. De operator heeft na het verplaatsen van de defecte shuttle het baanvak vrij gegeven. Toen heeft het systeem 1 van de twee wachtende shuttles de brug opgestuurd. De operator zag dat de andere wachtende shuttle ook nog stil stond en heeft het baanvak toen nogmaals vrijgegeven.

Op zich zou het verplaatsen van de defecte shuttle het baanvak al vrij moeten geven en had er dus geen handmatige vrijgave nodig hoeven zijn.
Maar men had ook het systeem zo kunnen maken dat een operator nooit een baanvak kan vrij geven terwijl er een shuttle op rijdt die geen storing meldt. Dat zou bijvoorbeeld alleen mogelijk moeten zijn als er fysiek iemand bij de shuttle aanwezig is en bijvoorbeeld een sleutel of pasje in de shuttle plaatst. Die persoon garandeert dan het systeem middels de sleutel/pas dat een overrule mogelijk en veilig is.

[Anoniem: 61096]

Maar men had ook het systeem zo kunnen maken dat een operator nooit een baanvak kan vrij geven terwijl er een shuttle op rijdt die geen storing meldt.

Het hele punt van het handmatig vrijgeven van een baanvak zal waarschijnlijk te maken hebben met mogelijke fouten in het computersysteem. Als het computer systeem een baanvak wat vrij is niet meer vrijgeeft is het handig dat een operator dit handmatig kan doen. Zeker in testfases (maar ook daarna) wil je de mogelijkheid hebben fouten in het systeem te corrigeren.

Wat trouwens ook gebeurd kan zijn is dat het systeem nadat de 3e shuttle van de weg gehaald was (te) traag was met het vrijgeven waarna de Operator besloot handmatig de baan vrij te geven. Daarna gaf het automatische systeem dan alsnog de baan vrij met alle gevolgen van dien.

[denkster]

Fout gedacht, m.i.
De operator geeft de baan vrij, maar de shuttle gaat niet rijden, want er staat er nog een aan de andere kant: deadlock!

[Anoniem: 79837]

@denkster

nee, dat zal niet zo zijn aangezien het systeem overal een heen en een terugweg heeft (2 banen dus) behalve op de brug. alleen de brug is maar 1 baan. als er dus een bus staat te wachten aan kant A kan de bus die vanaf kant B komt gewoon de bus aan kant A passeren zonder dat ze elkaar gaan zoenen.

[denkster]

Twee bussen, aan weerszijde van de brug een, mogen tegelijk gaan rijden. Wie begint? Deadlock!
Allereerst is het aardig te zien dat er inderdaad een deadlock was, zoals ik bij het vorige artikel veronderstelde.
Overal dezelfde software betekent altijd dat je extra software nodig hebt om deadlocks op te lossen.
Verder: een systeem met baanvakken is natuurlijk idioot en hopeloos verouderd. In Mumbay (Bombay, India) werken ze met GPS in elke trein. Alle treinen broadcasten voortdurend hun positie en snelheid. Als een trein een voertuig te dicht nadert stopt hij automatisch. Daardoor kunnen de treinen met tussenruimte van 3 à 4 minuten rijden, wat onmogelijk veilig is te doen met baanvakken.
Je moet rondkijken in de wereld, niet telkens het wiel opnieuw willen uitvinden.

[Anoniem: 140475]

Blijkbaar zat er een knuppel in de centrale die de baan twee keer heeft vrijgegeven.

De baan werd vrijgegeven, of je nu 1, 2, 3 of 100 keer de baan vrijgeeft zou niet uit mogen maken, een vrije baan is een vrije baan.

[BoekaBart]

Nee, denk ik niet. Ik denk dit:

====----====
(weg - brug - weg)
De kapotte bus stond op de brug stil. Aan weerszijden stond een bus te wachten. Ze hebben die kapotte 'handmatig' weggestuurd/weggereden, maar die kon dus dat stuk baanvak niet vrij-melden bij de centrale computer.
Dus wachtten die 2 bussen nog steeds voor een lege brug. Dus deed de operator ' OVERRIDE VRIJ' op de brug, op z'n schermpje werd de brug dus even 'groen'=vrij, en meteen besloot 1 van de 2 bussen dan maar weer te gaan rijden, so far so good. Hij meldde dus METEEN de brug weer 'bezet', omdat hij erop zou gaan. Dus de andere bus moest nog gewoon wachten. Echter de operator die de brug op GROEN zetten, zag meteen de brug weer 'rood worden' (=bezet) na zijn Klik, en dacht, ik heb het niet goed gedaan! Dus heeftie nog eens 'override free' gedaan en op dat moment besloot de 2e bus dat hij dan wel kon gaan.
Fout 1: De operator was fout (domdomdom)
Fout 2: De software die 'override' toekent moet eigenlijk aan de 'last known' 'eigenaar' van dat stuk weg vragen of het wel echt vrij is. In geval van die stukke bus had hij geen antwoord gekregen en dus had de operator kunnen aangeven: dat klopt, weten we, echt, het vak is leeg.
In het TWEEDE geval had de software het aan die bus gevraagd die net weer was gaan rijden, en die bus had gezegd, nee, flikker op, ik ben hier echt en ik ben ook nog op snelheid, dus handjes thuis. Dat had aan de operator gepresenteerd kunnen worden. Die had dan ongetwijfeld WEL nagedacht en vervolgens niet de 'override' doorgezet.
Maar ja, connexion heeft _mij_ niks gevraagd

[Skinkie]

wat dacht je van een race conditie?

busje een rijdt op het baantje, zegt: hoi ik rijd hier. baanvak wordt vrij gegeven omdat er een stilstaand busje stond
busje twee een stilstaand busje wordt naar de halte gestuurd en rijdt niets vermoedend naar de halte terwijl busje een op het zojuist vrijgeven stukje aan komt tuffen.

De fout is dus race conditie, dat het obstakel detectie systeem niet beter werkt en niet minimaal twee keer zijn remweg kan afzoeken is een veiligheids probleem.

[Roa]

De fout is hier, zoals praktisch altijd, menselijk. De software wist prima wat te doen, maar iemand heeft tegen beide bussen gezegt: Jullie mogen gaan rijden.

Overigens ben ik het wel eens rooicity, die sensoren moeten toch ook bewegende voorwerpen op tijd kunnen detecteren. Sowieso zou je denken dat het centrale systeem de positie van de busjes weet, en deze zou moeten kunnen aanpassen als het de verkeerde kant op lijkt te gaan...

[arjankoole]

De fout is hier, zoals praktisch altijd, menselijk. De software wist prima wat te doen, maar iemand heeft tegen beide bussen gezegt: Jullie mogen gaan rijden.

die 'iemand' was hier het centrale computersysteem. Die software gaf per ongeluk het baanvak vrij aan beide bussen, met als gevolg een crash. Eigelijk best komisch, maar uitsluitend omdat er niemand in de bussen zat.

[Anoniem: 76345]

Op zo'n moment zou je toch willen dat er een mens achter de knuppel zat die zelf dingen kan beslissen. De software werkt altijd perfect, maar als het niet weet wat het moet doen houdt het gewoon op.

Maar de mens maakt weer fouten op momenten dat een computer dat nooit zou doen, dus ja... Pech is natuurlijk dat dit het vertrouwen in dit soort systemen direct een enorme deuk geeft, en om dat vertrouwen terug te kunnen winnen moet het systeem echt wel enkele jaren ongeluk-vrij functioneren.

[kamerplant]

De software werkt altijd perfect

Software werkt altijd perfect? Dude...?

[Brons]

Het is echt niet de fout van de software. Het is altijd de fout van de ontwikkelaar, die in dit geval vergeten is dat voorwerpen op de straat ook kunnen bewegen.

[mashell]

>Het is altijd de fout van de ontwikkelaar, die in dit geval vergeten is dat voorwerpen
Om nou de schuld bij de ontwikkelaar te leggen. Even goed kan connexxion expliciet gevraagd hebben om een systeem dat alleen stilstaande obstakels kan ontwijken.

Hoewel ik in dit geval wel vreemd vind dat het detectie systeem niet kan omgaan met bewegende voertuigen, dat lijkt me als buitenstaande nou niet echte een gekke eis. Voor als er eens 1 "op hol" slaat of zo.

[Anoniem: 35832]

What about een ingebouwde self-destruct functie, in geval van nood

[Calamor]

Nee die gaat er naar toe rennen. Tuurlijk.

[DannyXP1600]

als dat voortaan de enige manier wordt om zelfmoord te plegen...

[PanMan]

Ja, uiteindelijk is iets natuurlijk altijd de fout van de ontwikkelaar, en nooit van de software zelf: Die heeft geen wil ofzo, maar doet alleen wat hem is opgedragen door de softwareontwikkelaar (samen met de compiler). Inclusief eventuele fouten daarin.

[Anoniem: 156329]

Ook handig als er een kind de straat over komt rennen.
Denk maar niet dat dat kind denkt 'he als ik stil ga staan dan stop die bus vast wel'.

[Anoniem: 105463]

software doet precies wat de mens verteld hem te doen. hij zal zelf geen andere dingen gaan doen. vandaar dat software perfect werkt. of de mens het perfect maakt is iets anders

[SED]

dat doen kinderen ook... denken veel ouders tenminste. Die hebben dezelfde naieve instelling als jij en dar kom je vanzelf achter vrees ik

[Anoniem: 141229]

(+/-) 90% van de ongelukken op de weg vinden plaats door toedoen van autobestuurders (bron: Gevaar op de weg, vorige aflevering), zodra dit systeem getest is en het goed geimplementeerd kan worden tot een 100% dekking op bijvoorbeeld snelwegen dan neem ik aan dat het aantal ongelukken enorm zullen afnemen.

Daarnaast hoop ik dat het dan ook mogelijk zal zijn vanwege de voorberekeningen van het computernet, dat men sneller gaat rijden (150km of hoger) dus dat men sneller er is. Of door efficiente koersbepalingen men met een langzamere snelheid toch eerder op locatie is. Dit zou best de toekomst kunnen hebben (denk aan film waar Tom Cruise in speelde.

[Anoniem: 120782]

Die film heette 'Minority Report' denk ik? En reken maar niet dat deze busjes binnen de komende 50 jaar op snelwegen worden losgelaten . Ze zijn bedoeld voor simpel, relatief traag vervoer (denk aan +/- 30km per uur)

[basb]

Statistieken zijn erg mooi, wat de statistieken niet vertellen:
Hoeveel ongelukken zijn er voorkomen door menselijk ingrijpen?
offtopic: Gevaar op de weg is toch gesponserd door Koos Spee/ openbaar-ministerie? Riekt naar overheids propaganda zoals dat in dictaturen gebruikelijk is.

Bij de meest eenvoudige conflict situatie rijden twee bussen al op elkaar in. Iets waar elke simpele ziel kan bedenken dat je moet testen, wat gebeurd er als we er twee recht op elkaar af laten rijden?
Dat werkt dus al niet, daarmee is ook zeker dat kleinere objecten(voetgangers, fietsers enz) hun leven niet meer zeker zijn, immers als er zo kreng aan komt moeten ze onmiddelijk stil gaan staan.

Het argument dat het systeem alleen uit gaat van stilstaande objecten is helemaal volslagen belachelijk. wat gaat dat ding doen bij een wegopbreking waarbij zo bus even op de andere rijstrook moet en dus geen rekening kan houden met tegemoet komende auto' s

Computers kunnen functioneren maar in 1 situatie goed: Voorspelbare situaties. Zodra er ook maar iets onverwachts gebeurd is maar 1 ding veilig, dat zo' n ding zich zover mogelijk meteen uitschakeld en alles wat door die computer bestuurd wordt meteen tot stilstand gebracht wordt. Maar ja, zelfs dat blijkt in praktijk niet eens altijd te werken

[Anoniem: 65259]

Ik ben 7 jaar geleden ooit proefpersoon geweest van de Parkshuttle. Ook toen was het verhaal dat ie automatisch zou stoppen bij een obstakel, maar dat werkte destijds ook al niet.

Ik zat namelijk een keer in het busje en 20 meter verder stond de 'baanbeheerder' in z'n golfkarretje op de weg. Hij kon niet verder want er stak verderop een vrachtwagen over. Je voelt 'm al aankomen. Het busje waarin ik zat ging rijden, stopte niet en crashte met volle vaart tegen de golfkar met beheerder.
Gelukkig zag ik het aankomen en hield ik me dus goed vast.

Je zou toch denken dat 7 jaar later de kinderziektes er wel uit zijn gehaald.....

[Anoniem: 49546]

Dat laat alleen maar zien hoe ontzettend moeilijk het is om zoiets goed te maken.

De clue is echter dat wanneer iemand het voor elkaar heeft gekregen het ook niet meer mis kan gaan.

Ter vergelijking, een mens kan een rijbewijs halen, maar das geen garantie dat ie geen klappen maakt. Een stuk software kan ook fouten maken, maar wanneer een fout is opgelost komt deze als het goed is niet meer terug.

Daarnaast moet het natuurlijk ook allemaal niet te duur worden. Als een stuk software minder fouten maakt als de gemiddelde chauffeur gaan ze er echt geen geld in stoppen om em nog beter te maken.

Het is al duur genoeg om zoiets te ontwikkelen en het plan was juist geld te besparen op de chauffeur.

[martijnvanegdom]

Jep.. En een computer maakt geen fouten.. Nee inderdaad nooit! .. Er zijn zoveel dingen die fout konden gaan.. Computer zijn niet perfect, software is niet perfect, compilers zijn niet perfect..

De pentium pro bug, ooit van gehoord? Ga maar eens kijken wat een rare dingen er allemaal kunnen gebeuren in hardware

[Frank-L]

Mensen leren makkelijker van hun (bijna-)fouten dan computers.

[Taeke]

Maar de remweg is alleen lang genoeg voor stilstaande voorwerpen, zoals het artikel vermeldt.

[BRAINLESS01]

ze reden op elkaar af... welke achterste?

[psyBSD]

Het obstakeldetectiesysteem probeerde de voertuigen nog te stoppen, maar de remweg was te lang. Het systeem is namelijk bedoeld voor stilstaande voorwerpen, terwijl hier twee bussen elkaar tegemoet reden, zodat het toch tot een botsing kwam.

Idd.
[edit]
te laat

[Shinji]

Dat gebeurde dus ook, echter zoals in het artikel staat vermeld is dit bedoeld voor stilstaande objecten. Beide wagentjes maakten waarschijnlijk een noodstop voor een stilstaand opject maar doordat ze allebei nog een aantal meters ofzo reden botsten ze op elkaar.

Zeg de remweg is 7 meter, systeem detecteerd op 10 meter objecten, als het ene voorwerp niet beweegt staat het ruimschoots op tijd stil, maar omdat dat andere voertuig dichterbij kwam waren die 3 meter marge niet genoeg.

(getallen uit duim gezogen, is slechts een voorbeeld)

//te laat

[Aikon]

@jqv: Nogal logisch dat sensoren moeten helpen, hoe kan het OS anders ooit weten of er een obstakel is. Een sensor is er om iets te detecteren, programmatuur om daar vervolgens een logische reactie aan te geven.

Wel flauw om 't weer met Windows te vergelijken...

[psyBSD]

Arme busjes , ik heb ook met ze te doen hoor.

[engelbertus]

ik denk dat de busjes beide wel de juiste remweg en remkracht hebben berekend. ze ginger er waarschijnlijk vanuit dat ze de hele remweg konden gebruiken, ( stilstaand obstakel) terwijl dit de helft had moeten zijn, elk van de busjes namelijk de helft.

als dan blijkt dat het obstakel dichterbij komt, is de tijd simpelweg te kort om nog hard genoeg te remmen, om in de halve remweg stil te kunnen staan.

en de kreukelzone heeft gewerkt de rest bleef in tact. hoe hard was de botsing uiteindelijk nog?

wel een enorm stomme fout, dat ze geen rekening hebben gehouden met een frontale botsing...

de busjes moeten dus verder vooruit kijken. en de afstand in de gaten houden ( snelheid van het obstakel) en ondertussen de remkracht aanpassen, dat is een realtime gebeuren. en misschien is dat programma / de sensoren niet echt realtime in staat zoiets op te lossen?

[mashell]

>misschien is dat programma / de sensoren niet echt realtime in staat zoiets op te lossen
Als dat zo is dan is de tijd gewoon nog niet rijp voor onbemande voertuigen in deze vorm.

[killercow]

race conditie foutje anyone?

hier is een mooie uitleg voor de n00bs onder ons:
http://ly.lygo.com/ly/wir...ecial_reports_bugs_2.html

[Mottebelke]

Wat ik vreemd vind is dat er wordt gezegd dat zo'n busje bewegende obstakels niet op tijd kan detecteren en dus te laat remt.

Want dit is niet zo maar een bewegend obstakel (fiets, overstekend wild, etc.), maar zo'n zelfde busje. Oftewel, ze zitten allebei in hetzelfde systeem. Het is toch raar dat het systeem niet meteen kan zien dat er twee busjes op hetzelfde baanvak naar elkaar toe rijden (en ze dus op tijd kan laten stoppen, zonder tussenkomst van de sensors).

Het is duidelijk dat er een menselijke fout is gemaakt door het baanvak twee keer vrij te geven, maar dit moet nog altijd kunnen worden voorkomen door de software.

[Anoniem: 9329]

Dat het niet de schuld is van de software doet er niet toe, een mens had wel op de rem getrapt.

De software is klaarblijkelijk nog in de Beta fase, en hoort dus niet op de weg..

[Anoniem: 61096]

Blijkbaar nog nooit van je leven in een druk gebouw tegen iemand anders opgelopen. Ook de mens reageert wel eens te laat.....

[kodak]

Ik krijg het vermoeden dat als al functies tegen dit soort situaties niet in het systeem hebben zitten er vast nog wel meer 'vergeten' is.

Ik kan het alleen geen vergeten noemen. Vooral bewegende obstakels liggen zo voor de hand dat ze waarschijnlijk gewoon gekozen hebben om daar niets extra's voor te ontwerpen. Als je bij een ontwikkeling hier geen rekening mee houd speel je met levens.