Ingebouwde telematica versus mobiele apps
Het verzamelen van rijgegevens leunde lange tijd op één enkele hardware-architectuur: een fysiek kastje dat met het voertuig was verbonden. Tegenwoordig moeten wagenparkbeheerders de afweging maken tussen deze traditionele aanpak en oplossingen die puur op software zijn gebaseerd, geïnstalleerd op de smartphones van de bestuurders. Deze keuze gaat inmiddels veel verder dan alleen het installatiegemak. Het vereist fundamentele technische compromissen wat betreft het soort data dat wordt verzameld en de betrouwbaarheid van de gegevensoverdracht. Toch nemen OBD-dongels nog steeds een aanzienlijk deel van de markt voor verzekeringstelematica voor hun rekening.
Van oudsher is telematica voor wagenparken opgebouwd rondom de diagnosepoort in het voertuig. Deze aansluiting biedt een direct toegangspunt tot de voertuigtechniek.
De verschuiving van het wagenpark naar nieuwe aandrijfsystemen en de verbeterde rekenkracht van mobiele apparaten veranderen echter de aard van de discussie. Een technische analyse van deze twee architecturen brengt duidelijke use-cases aan het licht, ingegeven door de natuurkundige wetten van sensoren en het cybersecuritybeleid van de autofabrikanten.
Drie beslissingscriteria
Bij het maken van een technologische keuze voor een zakelijk wagenpark, vallen er drie belangrijke beslissingscriteria te onderscheiden:
- De behoefte aan technische diagnose: Diepgaande analyses en toegang tot foutcodes blijven uitsluitend voorbehouden aan fysieke hardware die verbonden is met de boordelektronica.
- Het aandeel elektrische voertuigen in het wagenpark: Veel elektrische modellen beperken de toegang tot data, wat soms de verzamelcapaciteit van traditionele dongels in de weg staat.
- De noodzaak voor real-time data: De latentie van de datatransmissie is fundamenteel afhankelijk van de netwerkarchitectuur van de gebruikte telecomprovider.
Mobiele algoritmes: hoe compenseert een smartphone zijn eigen bewegingen in de auto?
De softwarematige aanpak is gebaseerd op het 'Bring Your Own Device' (BYOD)-principe, waarbij gebruik wordt gemaakt van de eigen apparatuur van de bestuurder. Smartphone-telematica gebruikt de ingebouwde sensoren van de telefoon om ritten te detecteren en het rijgedrag te meten. Er is hierbij geen specifieke hardware nodig die op de auto wordt aangesloten.
Sensorfusie en kalibratie via Machine Learning
Om de rijdynamiek van een voertuig te analyseren, maakt de app tegelijkertijd gebruik van de versnellingsmeter, de gyroscoop, de GPS-module en de magnetometer van het toestel. In tegenstelling tot een vaste module of een stevig ingeplugde dongel, is een telefoon mobiel: hij kan in de zak van de bestuurder zitten, in een sporttas of in een telefoonhouder.
Sensorfusie-algoritmes gebruiken Machine Learning-modellen om de ruimtelijke positie van de telefoon ten opzichte van de rijrichting van het voertuig te bepalen, en compenseren de eigen bewegingen van het toestel op wiskundige wijze. Hoe nauwkeurig specifieke gebeurtenissen zoals hard remmen of bruusk optrekken worden gedetecteerd, hangt sterk af van het telefoonmodel, de positie in het interieur en de kwaliteit van het algoritme.
De uitdaging van de stroomvoorziening
De impact op de batterijduur van de telefoon is een belangrijk technisch criterium voor zakelijke implementaties. Dankzij code-optimalisatie kan het stroomverbruik tegenwoordig worden beperkt. De energiebehoefte van een telematica-app hangt echter nog steeds sterk af van de ritduur, het telefoonmodel, de batterijcapaciteit en de gebruikte GPS-modus. Deze autonome werking staat in schril contrast met die van een OBD-dongel, die zijn stroom rechtstreeks uit het elektrische systeem van het voertuig haalt. Bij langdurig parkeren loopt men bij laatstgenoemde wel het risico dat de accu van de auto leegloopt als de dongel constant stroom blijft trekken.
Het voordeel van de OBD-dongel: CAN-bus en datacontinuïteit
Ondanks de vooruitgang op het gebied van mobiele algoritmes, behoudt specifieke hardware voordelen die te danken zijn aan de fysieke integratie in het voertuig.
Directe toegang tot het multiplex-netwerk
De zogenaamde 'black box'-telematica (of OBD-II-dongel) wordt aangesloten op de diagnosepoort van het voertuig. Deze fysieke verbinding maakt het mogelijk om data rechtstreeks uit te lezen van de CAN-bus (Controller Area Network), het centrale zenuwstelsel van de auto. Zo krijgt de dongel toegang tot gegevens die direct afkomstig zijn van de motorregeleenheid (ECU): het exacte motortoerental, het door het elektronische systeem berekende brandstofverbruik, en de foutcodes (Diagnostic Trouble Codes, of DTC's).
Door deze foutcodes uit te lezen, kunnen wagenparkbeheerders anticiperen op defecten voordat het voertuig stil komt te staan, door preventief onderhoud in te plannen. Deze specifieke parameters van de interne motorwerking zijn gegevens waar een smartphone, beperkt door zijn traagheids- en externe sensoren, fysiek simpelweg niet bij kan.
Datacontinuïteit zonder GPS-ontvangst
De combinatie van CAN-busdata en een geïntegreerde GPS-module zorgt voor een veel grotere ruimtelijke veerkracht. Bij het doorrijden van tunnels of in straten met veel hoge gebouwen (urban canyons) gaat het satellietsignaal vaak verloren. Op dat moment heeft de OBD-dongel een onmiskenbaar technisch voordeel ten opzichte van de smartphone: hij blijft de exacte rijsnelheid registreren door de snelheidssensor van het voertuig (Vehicle Speed Sensor) direct uit te lezen. Deze temporele continuïteit garandeert een nauwkeurige registratie van de afgelegde route, zonder last te hebben van vertragingen of vreemde positiesprongen die optreden als een mobiele telefoon zijn GPS-verbinding verliest.
OBD-dongel of mobiele app: wat kan er eigenlijk worden uitgelezen in een elektrisch voertuig?
Hardware-beperkingen vanuit de fabrikant
De architectuur van elektrische voertuigen (EV's) verschilt fundamenteel van die van modellen met een verbrandingsmotor. Veel elektrische modellen, met name van fabrikanten als Tesla, beperken de datatoegang via de OBD-II-poort. Deze voertuigen gebruiken afwijkende communicatieprotocollen of stellen slechts een zeer beperkt aantal parameters beschikbaar via de traditionele diagnosepoort.
Hierdoor blijken hardwaredongels die oorspronkelijk zijn ontworpen voor de standaarden van brandstofauto's, vaak onbetrouwbaar of deels onbruikbaar in geëlektrificeerde wagenparken. Deze technische blokkade dwingt beheerders van gemengde wagenparken om op zoek te gaan naar alternatieven die merkonafhankelijk zijn.
Het meten van afleiding achter het stuur
Een tweede beslissende factor is de analyse van het menselijke risico. Een OBD-dongel is uitstekend in het doormeten van de machine, maar is technisch gezien niet in staat om te detecteren of de bestuurder met zijn digitale omgeving bezig is. Daarentegen beschikt uitsluitend de smartphone van de gebruiker over de benodigde systeemrechten om het gebruik van het eigen scherm waar te nemen.
De mobiele app kan fysieke manipulatie van de telefoon registreren via zijn traagheidssensoren. Daarnaast gebeurt het detecteren van het wisselen van de actieve app via de machtigingen van het besturingssysteem, zodra er sprake is van een geregistreerde rit. Deze mogelijkheid om cognitieve en visuele afleiding te kwantificeren, is een absolute prioriteit geworden binnen het arbobeleid en risicopreventie van veel bedrijven.
Connectiviteit en latentie: De rol van het mobiele netwerk
Naast de manier van dataverzameling, is ook de overdracht van die data naar de bedrijfsservers bepalend voor de reactiesnelheid van het systeem. Of het nu gaat om een vastgesoldeerde simkaart in een dongel of de simkaart in de smartphone van de werknemer: de kwaliteit van het communicatiekanaal is doorslaggevend.
De impact van de core-netwerkarchitectuur
Een mobiele netwerkverbinding krijgt over het algemeen de voorkeur, omdat deze een lagere latentie biedt dan andere langeafstandsverbindingen. Toch blijkt uit analyses van gespecialiseerde connectiviteitsleveranciers dat deze latentie niet overal gelijk is: dit is fundamenteel afhankelijk van de core-netwerkarchitectuur (Core Network) van de telecomprovider. De routering van datapakketten van het ene land naar het andere kan vertragingen opleveren die per provider sterk verschillen, ongeacht de kwaliteit van de lokale dekking (de bekende 'streepjes' op het scherm).
De noodzaak van bedrijfskritische real-time data
Deze verschillen in infrastructuur komen pas echt aan het licht bij noodprotocollen. Het opsporen van een gestolen voertuig (Stolen Vehicle Recovery, of SVR) vereist regelmatige locatie-updates — mogelijk zelfs per seconde — afhankelijk van het escalatieprotocol. In een scenario waarbij moet worden samengewerkt met de politie, kan een extra latentie van slechts enkele tientallen seconden al genoeg zijn om een onderschepping te laten mislukken. Bij de keuze voor een telematicasysteem is het dan ook essentieel om de roaming-overeenkomsten en de onderliggende connectiviteitsinfrastructuur te controleren.
Vergelijkende tabel: Welke architectuur past bij welk gebruik?
De keuze voor de juiste uitrusting is afhankelijk van de besproken technologische randvoorwaarden en de operationele doelstellingen van het wagenpark. In deze tabel worden de capaciteiten van beide verzamelmethoden overzichtelijk samengevat.
| Beoordelingscriterium | Enkel mobiele app | OBD-II-dongel | Hybride aanpak |
|---|---|---|---|
| Foutcodes uitlezen (DTC) | Nee | Ja | Ja |
| Snelheidsmeting zonder GPS | Nee | Ja | Ja |
| Universele dekking (inclusief EV's) | Ja | Beperkt | Universeel |
| Detectie van telefoongebruik | Ja | Nee | Ja |
| Stroomvoorziening | Via batterij smartphone | Via accu voertuig | Via accu voertuig |
De hybride aanpak, waarbij een compacte fysieke dongel via Bluetooth communiceert met de mobiele app van de bestuurder, komt naar voren als een sterk technisch compromis. Deze oplossing biedt universele dekking dankzij de smartphone-component, aangevuld met gerichte OBD-data. Daar staat tegenover dat bij deze methode de kosten zich opstapelen. Volgens gegevens van Damoov ligt de aanschafprijs van een OBD-dongel tussen de 45 en 185 euro per stuk, exclusief eventuele installatiekosten. De totale kosten per uitgerust voertuig kunnen hierdoor aanzienlijk variëren, afhankelijk van de leverancier en de specifieke implementatie.
Veelgestelde vragen (FAQ) over telematicatechnologieën
Wat gebeurt er als een bestuurder zijn smartphone vergeet of de batterij leeg is?
Dit is direct de operationele grens van het softwaremodel. Bij telematica die uitsluitend op de smartphone draait, wordt er geen enkele rit geregistreerd of geanalyseerd als de telefoon niet fysiek in het voertuig aanwezig is, als deze is uitgeschakeld, of als de gebruiker zijn locatievoorzieningen in het besturingssysteem heeft uitgezet.
Dit is het grootste functionele nadeel ten opzichte van een specifieke OBD-II-hardwaremodule. De dongel schakelt automatisch in zodra de auto op contact wordt gezet, wat een continue registratie garandeert, onafhankelijk van wat de werknemer doet.
Kan het exacte brandstofverbruik gemeten worden zonder OBD-dongel?
Nee, het door de boordcomputer (ECU) berekende brandstofverbruik is uitsluitend uit te lezen via een directe verbinding met de CAN-bus. Een smartphone moet het doen met traagheidssensoren en een GPS-chip. Hierdoor kan het verbruik slechts indirect worden geschat, wat nooit de nauwkeurigheid van het eigen motormanagement evenaart.
Wat is de financiële impact van hardware-installatie vergeleken met een app?
Dat verschil is aanzienlijk. De hardwarekosten voor een OBD-dongel bedragen tussen de 45 en 185 euro per stuk, nog los van eventuele installatiekosten. Een mobiele app wordt simpelweg gedownload en brengt per gebruiker geen hardwarekosten met zich mee. De totale kosten per uitgerust voertuig met een dongel zijn afhankelijk van de gekozen hardware, de installatievoorwaarden en de leverancier.
Conclusie
De harde vergelijking tussen de fysieke dongel en de mobiele app illustreert de huidige overgangsfase binnen de vlootbeheerindustrie. Autofabrikanten (OEM's) bouwen tegenwoordig steeds vaker mobiele modems in, waardoor de voertuigdata direct beschikbaar wordt gesteld via native API's.
