Lab vs. field: waarom een werkend prototype nog geen robuust industrieel product is

Een prototype dat in het labo werkt, bewijst dat het concept klopt. Een product dat jarenlang betrouwbaar moet blijven werken in een machine, een voertuig of op een schip vraagt een andere manier van denken. In het veld heb je geen gecontroleerde omstandigheden meer. De voeding valt weg, netwerken zijn onbetrouwbaar, de temperatuur schommelt, kabels trillen, en problemen duiken op wanneer er geen engineer naast het toestel staat.

Of het concept werkt, weet je dus na het labo. Of je een product hebt, merk je pas in het veld.

In het labo heb je alles onder controle

Tijdens de ontwikkeling zijn de omstandigheden meestal ideaal. Je hebt een stabiele labvoeding, korte kabels, een betrouwbare Ethernetverbinding, kamertemperatuur en rechtstreekse toegang tot logs, een debugger, een oscilloscoop of JTAG. Loopt er iets fout, dan herstart je het toestel, en de ontwikkelaar zit ernaast.

In het veld heeft een toestel die luxe niet. Het moet zelf fouten herkennen, veilig reageren en genoeg informatie bewaren zodat je achteraf kunt begrijpen wat er gebeurd is.

Ons maritieme project: het veld in zijn puurste vorm

Een goed voorbeeld is een project dat we voor vissersvaartuigen uitvoeren. Aan boord plaatsen we een edge computer die gegevens uit verschillende systemen verzamelt, onder meer de vangstgegevens uit de weegschaal, het brandstofverbruik, de trekkracht, de GPS-positie en het tijdstip. Die informatie wordt lokaal verwerkt en opgeslagen, en later naar een centrale server gesynchroniseerd voor analyse, rapportering en de opvolging van Europese regelgeving.

Op een ontwikkeltafel lijkt zo’n architectuur vrij eenvoudig. Aan boord is de context helemaal anders. Het systeem staat in een omgeving met trillingen, vocht en zout, en er is niet altijd netwerkverbinding. Toch moet de datacollectie gewoon doorgaan, want het schip wacht niet tot het internet terug is.

Op zee is connectiviteit iets wat er soms is. De kernfunctie van het toestel mag daar niet van afhangen.

Het systeem moet dus lokaal zelfstandig kunnen werken, data veilig bufferen en later synchroniseren. Dat verschil tussen een nette demo en een robuust edge-product is waar dit artikel over gaat.

Voeding is nooit zomaar voeding

Een prototype krijgt bijvoorbeeld 24 V uit een nette labvoeding. In een machine of voertuig betekent “24 V” niet dat er altijd exact en stabiel 24 V op staat. Spanningsdips, transients, een slechte massa, inductieve lasten, onverwachte power cycles en brown-outs horen bij de realiteit.

Daardoor wordt ook software een hardwarevraagstuk. Wat gebeurt er als de voeding wegvalt terwijl Linux naar flash schrijft? Kan de applicatie haar toestand herstellen? Kan de Linux-computer eerst gecontroleerd afsluiten?

In onze eigen X Series gebruiken we daarvoor een aparte microcontroller voor power sequencing en ignition-detectie. Zo start en stopt een eenvoudige, deterministische controller de complexere Linux-computer op een gecontroleerde manier.

Netwerken vallen uit

LABDevice -> Ethernet -> Server OKFIELDDevice ->? Switch ->? Router ->? Internet ->? Cloud

Netwerksoftware ontwerp je vanuit de veronderstelling dat verbindingen wegvallen. Dat betekent onder meer reconnect-logica, time-outs, buffering, store-and-forward, retries met backoff, en een duidelijke scheiding tussen functies die lokaal moeten blijven werken en functies die de cloud nodig hebben.

Op de vissersvaartuigen is dat essentieel. De datacollectie en de lokale opslag moeten doorgaan wanneer het schip geen betrouwbare verbinding heeft, en de synchronisatie volgt zodra de verbinding terug is.

Temperatuur, trillingen en de mechanische realiteit

Een embedded computer die probleemloos op een bureau draait, kan zich anders gedragen in een gesloten behuizing, in volle zon of naast elektronica die warmte afgeeft. Het thermisch ontwerp bepaalt niet alleen de CPU-temperatuur, maar ook of de processor gaat throttlen, hoe lang de componenten meegaan, hoe het display en de backlight zich houden en hoe betrouwbaar de opslag is. Daarnaast krijgt een toestel in het veld te maken met:

• temperatuurcycli en cold boots;
• trillingen en schokken;
• vocht, condensatie, stof en zout;
• connectoren, kabeltrek en langdurige mechanische belasting;
• UV en veroudering van materialen bij gebruik buiten.

Een IP-rating vertelt daarbij maar een deel van het verhaal. Met een IP65-front is een product nog niet vanzelf geschikt voor elke industriële of maritieme omgeving.

EMC, de onzichtbare grens tussen prototype en product

Een PCB kan perfect werken op de werkbank en toch problemen geven naast motoren, frequentieregelaars, contactoren, lange communicatiekabels of radiozenders. Grounding, shielding, filtering, bescherming tegen ESD en surges en uiteindelijk de EMC-verificatie horen daarom bij de productontwikkeling zelf. Je kunt ze niet achteraf als afwerking toevoegen.

Gebruikers volgen de testprocedure niet

Tijdens de ontwikkeling volgen engineers vanzelf de bedoelde volgorde. In het veld worden kabels uitgetrokken, schakelaars snel na elkaar bediend, USB-sticks verwijderd en toestellen maandenlang niet herstart. Een robuust systeem test je daarom niet alleen op het happy path, maar ook op onverwacht en soms hardhandig gebruik.

Ontwerp een product voor wat hoort te gebeuren, en ook voor wat vroeg of laat toch gebeurt.

Een test van tien minuten, een product van tien jaar

24 uur/dag x 365 dagen x 10 jaar = 87.600 bedrijfsuren

Bij langdurig gebruik komt een andere soort fouten naar boven: memory- en file-descriptor leaks, logbestanden die blijven groeien, flash wear, databases die blijven aangroeien, reconnect bugs, race conditions, problemen met de klok, en certificaten die jaren later verlopen.

Soak tests, resource monitoring en nadenken over de volledige levensduur zijn daarom minstens zo belangrijk als een geslaagde demonstratie.

Debuggen als je het toestel niet kunt aanraken

In het labo heb je SSH, GDB, een logic analyzer en een oscilloscoop bij de hand. Uit het veld krijg je eerder een melding als “het toestel is vannacht ergens gestopt”. Of je dat probleem dan kunt onderzoeken, hangt af van de observability die je vooraf hebt ingebouwd:

• structured logging met betrouwbare timestamps;
• de software- en hardwareversies in de diagnostiek;
• crash dumps en reboot reasons;
• de watchdog-historiek en persistente foutcounters;
• health metrics en de status van de opslag;
• veilige remote diagnostics, waar de toepassing dat toelaat.

Als je het probleem niet kunt reproduceren, moet het toestel je helpen begrijpen wat er gebeurd is.

Updates zijn eenvoudig, tot er eentje mislukt

In het labo kopieert een developer een binary en herstart een service. Bij tientallen of honderden toestellen in het veld moet het updateproces rekening houden met onderbroken downloads, stroomuitval, incompatibele configuraties en software die na de uitrol toch problemen blijkt te geven.

Signed updates, A/B-partities, rollback en gefaseerde roll-outs zijn daarom geen luxe. Ontwerp je updatearchitectuur vooral voor de update die halverwege mislukt.

Met Otaryx bouwen we op die lifecycle verder. Met softwaredistributie, remote toegang, gefaseerde uitrol en monitoring houd je embedded systemen ook na de levering beheersbaar.

Security stopt niet bij de release

Een toestel dat tijdens de ontwikkeling achter de bedrijfsfirewall stond, komt later in een klantennetwerk terecht, op een voertuig of op een plek waar iemand er fysiek aan kan. Ondertussen worden er tijdens de levensduur nieuwe kwetsbaarheden ontdekt.

Security gaat dus over meer dan secure boot of signed software bij de productie. Ook het beheer van de SBOM, CVE-monitoring, credentials, certificaten en een betrouwbaar updatepad horen bij het ontwerp van de volledige levenscyclus van het product. Hoe dat er voor een Yocto-image uitziet, lees je in SBOM en CVE-monitoring met Yocto.

Design for failure

Je vraagt je dan niet meer af of iets kan gebeuren, maar wat het product moet doen als het gebeurt.

Testen voor de werkelijkheid

Het verschil tussen labo en veld verdwijnt nooit helemaal, maar je kunt het wel bewust kleiner maken. Naast functionele tests zijn failure injection en langdurige tests bijzonder waardevol. Denk aan:

• de voeding onderbreken tijdens de boot en tijdens een software-update;
• Ethernet uittrekken, of packet loss en hoge latency introduceren;
• de server of cloudservice tijdelijk onbereikbaar maken;
• het filesystem of de logpartitie gecontroleerd laten vollopen;
• sensoren en peripherals loskoppelen terwijl het systeem draait;
• applicaties killen en nagaan of de watchdog ze herstelt;
• honderden of duizenden bootcycli uitvoeren;
• langdurige soak tests onder een realistische belasting;
• waar nodig environmental-, EMC- en compliance-tests.

Van proof of concept naar lifecycle

Proof of concept      |Functional prototype      |Engineering prototype      |Verification & validation      |Production      |Field operation      |Updates & maintenance

De productontwikkeling stopt dus niet wanneer de eerste toestellen van de band rollen. De fase in het veld hoort bij het ontwerp: hoe het systeem zichzelf herstelt, hoe je problemen onderzoekt, hoe je de software veilig updatet en hoe je het product jarenlang onderhoudt.

Tot slot

Bij Invisto ontwerpen we systemen niet alleen om te werken op de werkbank, maar ook voor alles wat daarna komt. Dat vraagt een combinatie van disciplines, want hardware, firmware, embedded Linux, HMI, connectiviteit, cloud en lifecyclebeheer beïnvloeden elkaar zodra een product het labo verlaat.

Het project op de vissersvaartuigen maakt dat heel concreet. De lokale datacollectie, de edge processing en de opslag moeten betrouwbaar blijven werken in een harde maritieme omgeving en met een verbinding die komt en gaat. Daar zie je het verschil tussen een technologiedemo en een industrieel systeem dat voor de werkelijkheid ontworpen is.