Goede tijden, slechte tijden

5 december 2011

Maak je software voor een technisch ingewikkeld apparaat? Dan heb je vast wel eens meegemaakt dat de serviceorganisatie hulp vraagt omdat de software bij een klant niet goed werkt. Een eerste navraag leert dat de klant geen of moeilijk samples kan insluizen in zijn machine omdat de software dan vreemd reageert. Je probeert de serviceafdeling te overtuigen dat het echt niet aan de software kan liggen omdat het probleem immers niet optreedt bij andere klanten met de dezelfde configuratie. Nee nee, het is echt de software volgens de servicemannen want alle hardware is nagekeken en getest en ze kunnen geen problemen vinden. Helaas is het probleem niet op de lokale apparaten te reproduceren. Je tast in het duister. Wat kan er aan de hand zijn? De logfiles worden opgestuurd en na het bestuderen ervan is het nog steeds niet duidelijk. Na lang soebatten met de mechanicus die het insluismechanisme heeft gebouwd, ben je er eindelijk uit: er komt geen signaal, dus het is de eindschakelaar die los moet zitten. Zie je wel, het was toch een hardwareprobleem.

Is deze situatie herkenbaar, lees dan door.

Ik ben het me pas een tijdje geleden gaan realiseren, maar ik moet toegeven dat problemen van de bovenstaande categorie toch in de eerste plaats softwareproblemen zijn. Traditioneel concentreren we ons voornamelijk op het goedweergedrag van de software. We denken wel na over wat er mis kan gaan, maar dat is in veel gevallen alleen wat de softwareman kan bedenken. Om het slechtweergedrag van het apparaat goed af te handelen, moeten we als softwareontwerpers vroeger tijdens het ontwerpproces aan de slag. Samen met de andere disciplines moeten we structureel een failure-mode effect analysis (FMEA) doorlopen voor alle modules van het apparaat, maar dan speciaal gericht op software. Dit komt in feite neer op een tijdje brainstormen over de faalmogelijkheden. Component voor component bekijk en bedenk je welke scenario’s kunnen leiden tot falen. Met deze informatie bedenk je vervolgens hoe elk falen kan worden opgemerkt. Typisch zal dit leiden tot redelijk wat code om alles te detecteren, en tot het inzicht dat sommige problemen niet direct te zien zijn en pas veel later ergens in het systeem de kop opsteken.

Nu heb je de mogelijkheid om afhankelijk van de risico-inschatting en de kans van optreden wat aan mogelijke problemen te doen. Extra sensoren toevoegen of het ontwerp in zijn geheel aanpassen behoort nog tot de mogelijkheden. Je moet ook bedenken hoe het apparaat hoort te reageren op een fout. Veelal moet het in een veilige toestand worden gebracht, de gebruiker moet correct worden ingelicht en heel soms is er een herstelprocedure mogelijk nadat het probleem is verhopen. FMEA is een techniek die dus gaat helpen bij graceful degradation van je apparaat.

Het kan lonen deze aanpak te integreren met een servicestrategie. In plaats van op componentniveau service te verlenen, kan het veel goedkoper zijn hele modules te vervangen, want dat betekent kortere servicetijden en het personeel hoeft minder specialistisch te zijn dan voorheen. Voor de software betekent het dat je minder ver hoeft te gaan met de foutdiagnose; je hoeft alleen aan te geven welke module het betreft.

Dan is er alleen nog de verantwoordelijkheid om al die slechtweercode te testen. Dat kan knap lastig zijn, want je kunt het apparaat niet kapotmaken om alles uit te proberen. Een goede simulator zal hier uitkomst moeten bieden. Heb je gelijk een goede reden om te investeren in simulatie.

Robert Hendriksen

Terug naar overzicht