Een parkeergarage die auto’s op de juiste plek zette. Dat was de droom van de gemeente Den Bosch. Het pakte echter verkeerd uit. Auto’s werden op elkaar gestapeld en veel voertuigen kwamen vol beschadigingen terug bij hun rechtmatige eigenaar. Deel 3 in de artikelenreeks ‘Als Oplossingen Problemen Worden’.
| Als oplossingen problemen worden In deze serie worden ict-projecten belicht die bedrijven en/of overheden in een lastig parket hebben gebracht. |
Wie?
De gemeente Den Bosch.
Wanneer?
Ambtenaren die vanaf april 2003 hun auto parkeerden in de kersverse volautomatische parkeergarage in Den Bosch onder het nieuwe stadskantoor keken raar op toen ze hun auto kwamen ophalen. De parkeergarage meldde dat hun auto niet aanwezig was, terwijl ze hem door het traliewerk heen konden zien staan. Anderen kregen hun auto wel terug, maar zonder buitenspiegel of met beschadigingen aan de lak. De automatische parkeergarage parkeerde auto’s waar al auto’s stonden en hield geen rekening met de hoogte van de wagen.
Wat ging er mis?
De gemeente Den Bosch dacht slim te zijn door in april 2001 na een aanbestedingsprocedure voor bijna drie miljoen euro een automatische garage te bestellen bij het bedrijf CVSS (Computerised Vehicle Storage Systems). Op die manier dacht de gemeente optimaal gebruik te kunnen maken van de beschikbare ruimte. In een automatische parkeergarage zijn namelijk geen rijbanen nodig. Via een stelsel van transportbanden, sluizen en liften zou CVSS de auto’s naar de juiste plek transporteren.
Professor Jan Friso Groote van de Technische Universiteit Eindhoven: “Tijdens de bouw van de garage dacht men in eerste instantie dat één computer voldoende was om de garage met twee liften aan te sturen. Dat bleek niet voldoende. Dus werden er op beide liften computers geplaatst die beide een deel van de garage in hun beheer hadden. De computers moesten niet alleen met elkaar, maar ook met alle apparaten in de garage communiceren. Dat is buitengewoon ingewikkeld, omdat ook de software rekening moest houden met alle mogelijke foutsituaties en communicatiestoringen. De leverancier heeft zich nooit gerealiseerd hoe complex software is en richtte zijn aandacht op het installeren van goede hardware, vanuit het idee dat een programma voor de aansturing van de hardware niet al te moeilijk zou zijn. Het bedrijf realiseerde zich niet dat de software niet alleen geschikt moet zijn om een auto op de juiste plek te parkeren, maar dat het ook onder iedere omstandigheid moet werken. Niet alleen in een lege, maar ook in een volle en een halfvolle garage. En de software moet nog steeds adequaat reageren als er louter bestelbussen in de garage worden geparkeerd en tegelijkertijd één van de twee liften stuk gaat. Kortom: het aantal omstandigheden waar de software potentieel mee geconfronteerd kan worden is zeer groot. Groter dan het aantal atomen in het heelal.”
Hoe verholpen?
Nadat de gemeenteraad in 2006 een plan blokkeerde om een andere leverancier de problemen voor 1,9 miljoen euro te laten oplossen, heeft de gemeente in februari 2007 besloten het volautomatische parkeersysteem uit de garage te slopen. In plaats daarvan komt er een traditionele parkeergarage, met half zoveel plaatsen en met traditionele hellingbanen.
Blaren?
Sinds de opening van het nieuwe stadskantoor in maart 2003 hebben ambtenaren hun auto niet normaal kunnen parkeren. Ze liepen het risico hun auto beschadigd of helemaal niet terug te krijgen, waardoor ze met het openbaar vervoer naar huis moesten. CVSS ging failliet, maar maakte een doorstart als Dolphin Parking. Bovenop de kosten die de gemeente Den Bosch maakte voor de volautomatische parkeergarage is nu ook nog eens 2,1 miljoen euro nodig voor een conventionele garage.
Had dat niet anders gekund?
Groote: “Bij het ontwikkelen van nieuwe software slaagt 20 procent van de projecten, 30 procent mislukt volkomen en 50 procent voldoet niet aan de oorspronkelijke eisen. Het toverwoord dat je altijd tegenkomt is onderschatting van de complexiteit. Kleine design flows in softwareontwerp zijn vaak moeilijk te detecteren. Moderne softwaresystemen bevatten zoveel intelligentie, dat de bediening ervan lastig is. Wat er ín die systemen gebeurt, gaat vaak zelfs het voorstellingsvermogen te boven.
“Botenbouwers zijn in staat om boten te bouwen van dimensies die het menselijke voorstellingsvermogen ver te boven gaan. Waarom breken die boten toch niet doormidden? Omdat ingenieurs wiskundige modelleertechnieken gebruiken voor het doorrekenen van krachten die stammen uit de 17e eeuw en nog continu verfijnd worden. Dat is de reden dat ingenieurs zo’n goede naam hebben. Dat geldt niet voor softwareontwerpers.”
“Als je een huis laat bouwen, legt de gemeente je ontwerp voor aan een constructiebureau. Bij software is dat niet zo. Wat er bij elk softwareontwerp zou moeten gebeuren, is dat je het dataverkeer modelleert en daarna op een abstract niveau bewijst dat het correct is. Verder pleit ik voor het oprichten van onafhankelijke overheidscommissies die het ontwerp daarna nog eens controleren op correctheid.”
Is dit nieuws??? Dit artikel stond 15 juni 2007 exact hetzelfde in de computable…
De voornaamste oorzaak voor het mislukken van zoveel softwareprojecten is dat de eisen voor het project vaak op het moment van oplevering zelfs nog niet geheel duidelijk zijn.
De opdrachtgever denkt vaak niet abstract genoeg om eisen te formuleren en de uitvoerder stelt veelal niet de juiste vragen om alle probleemgevallen in kaart te brengen.
Voeg daar aan toe dat er tijdens het implementeren nog nieuwe eisen gesteld worden (of duidelijk worden) en dan kom je al heel snel tot een wan-product wat ofwel niet naar wens werkt, danwel onmogelijk is om te onderhouden.
Het grote voordeel van een keuringsdienst die het product doorlicht is dan dat je wel een stuk gestructureerder moet werken en op voorhand al zaken tegenkomt die kennelijk niet duidelijk zijn voor de gebruiker en dat je dan op een eerder punt al aanpassingen kunt maken.
Een deel van het “niet naar wens functioneren” zit namelijk ook in dat de bediening te complex of omslachtig is.
De Duitsers kunnen dit anders prima, getuige de automatische parkeergarage van Volkswagen in Wolfsburg …
Schijnt op het moment vaker te gebeuren; volgens mij had ik dat verhaal over problemen met de kabelbomen in de vliegtuigindustrie dat recentelijk (weer) in de Computable stond ook al eerder gezien … Vraagje an de redactie: Is het niet een beetje vroeg voor de ‘komkommertijd’?
“Kleine design flows in softwareontwerp zijn vaak moeilijk te detecteren.” Tekenend voor hoe een klein foutje je een hele verkeerde kant op kan sturen. Een ‘design flOw’ (ontwerpstroom of -afloop) is namelijk iets heel anders dan een ‘design flAw’ (ontwerpfout), wat hier ongetwijfeld werd bedoeld …
Wat een onzin … Complex zal het wel zijn, maar gewoon slecht geschreven software en een slecht plan van aanpak zal eerder de oorzaak zijn. Maar ja wie geeft dat toe …
Ik vind dat de schrijver een beetje te makkelijk roept dat iets veel te complex is. Je zou eens in een moderne fabriek moeten kijken wat daar allemaal bestuurd wordt, dan is zo’n parkeergarage peanuts … lijkt mij gewoon een kwestie van onkunde.
Ik moet altijd erg lachen bij de term “intelligente software”. Als iemand dat gaat roepen, berg je dan maar. Hoogmoed komt voor de val.
Wiskundige modelleertechnieken gebruiken? Ook dat hangt af van de kwaliteit van de wiskundige.
Zorg gewoon dat je het juiste team neerzet: een opdrachtgever die weet wat hij vraagt doordat hem door de juiste ontwerper(s) het hemd van het lijf wordt gevraagd. Inzet van constructeurs die verstand hebben van de toegepaste technieken en zeer kritisch meewerken aan het ontwerp. Zorg dat het ontwerp in verschillende modellen behoorlijk aan de tand wordt gevoeld, en zorg voor complete testen die alle gebouwde onderdelen aan de tand voelen na de bouw.
Ik verbaas me elke keer weer over de managers en bestuurders die alleen op basis van tijd en geld dit soort projecten al vooraf geen kans van slagen geven. En andersom over de it-leveranciers die gouden dingen beloven voor een habbekrats.
In dit project spelen de sensorsystemen een sleutelrol. Als dat goed uitgevoerd is krijgt de ambtenaar in ieder geval zijn auto onbeschadigd terug. In het ergste geval krijgt hij hem niet terug.
Echter, dat valt dan te wijten aan bv. weigerende transportsystemen. Natuurlijk, als zo’n lift naar beneden dondert houdt geen sensor dat tegen, er moet ook gewoon goed gebouwd worden.
Uit dit artikel blijkt eerder dat de transportsystemen hun werk wel betrouwbaar uit zouden kunnen voeren, maar dat sensorgegevens niet kloppen of niet goed geinterpreteerd worden.
Niet kloppende gegevens komen voort uit sensorsystemen die niet geschikt zijn voor hun taak, waar dus alternatieven voor gezocht moeten worden; dat lukt of lukt niet. Lukt het niet: einde project.
Lukt dit wel, volgende stap: de interpretatie.
Slechte interpretatie van de gegevens komt alleen door nalatigheid bij het schrijven van de aansturende software, dit is kwalijk, omdat goede software afleveren bij een in theorie werkend systeem slechts een kwestie is van tijd.
In het geval van zo’n parkeergarage gaat die tijd vooral zitten in ontzettend veel meten om die meetgegevens te gebruiken bij het instellen van de software. Het schrijven van de software zelf valt in principe mee; Als een sensor een waarde buiten het toegestane bereik opgeeft, moet de software met een alternatieve oplossing kunnen komen. Meestal komt dit neer op menselijk ingrijpen. Maar dan zit er dus nog steeds geen kras op je Audi A6. De procesbewaker constateert een sensor-defect, repareert, controleert, en het systeem werkt weer. En als reparatie niet direct mogelijk blijkt, kan de betreffende bewaker de sensorfunctie tijdelijk overnemen om de Audi A6 naar buiten te helpen. Pas als zoveel functies uitvallen dat de bewaker zelfs handmatig het systeem niet meer kan besturen, is de ambtenaar zijn auto misschien wel wat langer kwijt. Maar nog steeds zit er geen kras op.
Technisch allemaal zeer wel mogelijk en niet overdonderend complex.