Debuggen in embedded systemen is vaak een tijdrovende klus. Je krijgt een melding van een fout in het veld, maar lokaal laat het apparaat zich niet uit de tent lokken. De fout is niet reproduceerbaar, het systeem draait zonder scherm, en op afstand heb je weinig zicht op wat er precies misging. En dan komt het logboek in beeld – als dat er tenminste is.
Slim loggen is één van de goedkoopste en effectiefste manieren om problemen in embedded systemen sneller op te sporen én te voorkomen. Maar dat betekent wel dat je loggen serieus moet nemen als onderdeel van je ontwikkelproces. In dit artikel leggen we uit wat slim loggen is, waarom het werkt en hoe je het toepast in embedded software development.
Logging ≠ printf debugging
Veel engineers beginnen met printf-debugging: even snel een paar statements toevoegen om te zien of een functie wordt aangeroepen of wat een variabele doet. Daar is niks mis mee bij het oplossen van kleine issues in de ontwikkelfase, maar printf lost weinig op als het probleem optreedt in productie, of slechts onder specifieke omstandigheden. Slim loggen betekent dat je systematisch relevante informatie bijhoudt, op een manier die bruikbaar is tijdens en ná het incident.
Waarom logging cruciaal is in embedded
Embedded systemen draaien vaak in omgevingen waar je niet zomaar een debugger kunt aansluiten. Denk aan apparaten in productiehallen, medische instrumenten, of mobiele systemen in voertuigen. Logging geeft je zicht op:
- Wat er gebeurde vlak vóór een crash of vastloper
- Welke inputs of omgevingsfactoren invloed hadden
- In welke staat het systeem verkeerde
- Hoe vaak een fout zich voordoet (en sinds wanneer)
Zonder logdata wordt debuggen een gok. Met goede logs zie je het verschil tussen een incident en een patroon.
Slim loggen: 6 praktische tips
1. Werk met logniveaus
Gebruik minimaal de standaardniveaus: DEBUG, INFO, WARN, ERROR (en eventueel FATAL). Zo houd je controle over hoeveel informatie je logt en kun je het volume aanpassen per fase (ontwikkeling, test, productie).
Voorbeeld:
c
LOG_INFO("Initializing sensor module");
LOG_WARN("Sensor timeout, retrying...");
LOG_ERROR("Failed to initialize sensor after 3 attempts");
Zorg dat je per omgeving kunt configureren welk niveau wordt opgeslagen of getoond.
2. Gebruik timestamps en context
Een log zonder tijd is als een kaart zonder schaal. Zorg dat je elke regel voorziet van een timestamp (liefst in UTC), en indien mogelijk van thread-ID of component-naam. Zo kun je reconstructies maken van gebeurtenissen over tijd.
Voorbeeld:
makefile
2025-07-21T10:35:42Z [SENSOR] [Thread-2] Timeout after 500ms
Zorg dat je klokken gesynchroniseerd zijn (bijv. via NTP of RTC) om correlatie tussen logs mogelijk te maken.
3. Log cyclisch, niet onbeperkt
Opslag is schaars, zeker op embedded devices. Gebruik circular buffers voor logopslag: zodra het maximum bereikt is, worden de oudste regels overschreven. Combineer dit eventueel met het bewaren van logs bij een crash of bepaalde triggers (bijv. via core dump of persistente opslag).
4. Log state changes, niet alleen fouten
Fouten treden vaak pas op na een reeks kleine afwijkingen. Log daarom ook gewone statuswijzigingen en grenswaarden. Bijvoorbeeld:
- Wanneer de temperatuur een drempel overschrijdt
- Wanneer een modus wordt gewijzigd
- Wanneer een verbinding (opnieuw) tot stand komt
Hierdoor kun je trends ontdekken of correlaties zien die voorafgaan aan fouten.
5. Maak logs op afstand uitleesbaar
Zorg dat logbestanden op afstand beschikbaar zijn, via een remote API, seriële interface, of bijv. MQTT. Als dat niet real-time kan, zorg dan dat logs batchgewijs kunnen worden geëxporteerd (bijv. bij onderhoud).
In kritieke systemen loont het zelfs om logs versleuteld en gecomprimeerd door te sturen naar een centraal platform, zodat je problemen kunt analyseren zonder fysieke toegang.
6. Test je logging mee
Vergeet niet: ook logging is code. En net als andere code kan het stuk gaan of onbruikbaar worden.
– Zorg dat je logging test op inhoud en consistentie
– Gebruik unit tests om te controleren of bepaalde foutscenario’s correcte logoutput genereren
– Check na een test-run: zou ik hiermee een fout kunnen terugvinden?
Extra tip: log als je gebruiker het niet kan
Gebruikers melden symptomen, geen oorzaken. “Hij deed het ineens niet meer.” Slimme logs geven context waar de gebruiker die niet kan geven. Denk aan:
- Laatste user input voor crash
- Batterijstatus
- Netwerk- of sensorstatus
- Interne foutcodes van modules
Zorg dat je logs maken wat voor de gebruiker onzichtbaar is, wél zichtbaar wordt voor het ontwikkelteam.
Tot slot: logging is geen bijzaak
In embedded development is logging lang gezien als iets dat je “erbij doet”, als je tijd hebt. Maar wie zijn logging strategisch opzet, bespaart enorm veel tijd bij testen, debuggen en support. Je voorkomt eindeloze trial-and-error in het veld, maakt je systeem betrouwbaarder, en verhoogt het vertrouwen bij klanten en eindgebruikers.
Slim loggen is geen luxe. Het is een structurele versneller voor kwaliteit.
_
Over Ndus3
De consultants van Ndus3 bewegen op het snijvlak van engineering en software. Ze ondersteunen bedrijven in de maakindustrie op projectbasis met oplossingen, advies en begeleiding. Vanuit een drietal vestigingen in Nederland kunnen engineers op een breed scala van vakgebieden ingezet worden bij klanten in de sectoren Manufacturing, Energy, Life-Science en Mobility. Op die manier bedient Ndus3 zijn klanten met lokale aanwezigheid en landelijke slagkracht!
Weten over deze case of wat we als Ndus3 voor jouw organisatie kunnen betekenen? Mail dan Gerben van Manen via gerben@ndus3.com of neem contact op via ons contactformulier.
