De set standaard OCPP foutcodes is klein in verhouding tot het aantal dingen dat fout kan gaan in een lader. Fabrikanten brengen daarom veel interne omstandigheden in kaart op elke code, en ze brengen deze niet op dezelfde manier in kaart.
Het gevolg is dat dezelfde code van twee merken twee verschillende dingen betekent, en dat een platform dat codes als een gemeenschappelijke taal in een gemengd wagenpark behandelt, vol vertrouwen verkeerde conclusies zal trekken.
Waarom de standaardset niet voldoende is
De codes beschrijven brede categorieën: een aardfout, een overstroom, een communicatieprobleem, een interne fout. Een lader heeft tientallen te onderscheiden faalcondities en moet deze in dat vocabulaire comprimeren.
Bij compressie gaan de details verloren die een fout actiegericht maken. Wetende dat er een interne fout is opgetreden, vertelt een technicus niets over wat hij naar de locatie moet brengen.
Waar de nuttige informatie leeft
De meeste fabrikanten bieden leverancierspecifieke foutinformatie naast de standaardcode, en dat is meestal waar het bruikbare detail zich bevindt: een subsysteem, een specifieke toestand, soms een gedocumenteerde code die verwijst naar een serviceactie.
Een platform dat alleen de standaardcode opslaat, gooit deze weg. Het behouden van het leveranciersveld, zelfs zonder het te begrijpen, betekent dat de informatie beschikbaar is wanneer iemand deze uiteindelijk nodig heeft.
Het gemengde vlootprobleem
Zodra een netwerk meer dan één merk heeft, wordt de analyse van fouten tussen de vloot onbetrouwbaar. Het tellen van het voorkomen van een code bij verschillende merken levert een getal op dat niets betekent, omdat de onderliggende omstandigheden verschillen.
De werkbare aanpak is om per merk te normaliseren in uw eigen taxonomie, in plaats van de standaardcodes als al genormaliseerd te behandelen. Dat is werk, en het is het werk dat diagnose op wagenparkniveau mogelijk maakt.
Bouw uw eigen taxonomie
- Definieer de categorieën waarop uw bedrijf daadwerkelijk actief is: bezoek ter plaatse vereist, reset op afstand waarschijnlijk opgelost, voertuigzijde, negeren.
- Breng de codes en leveranciersinformatie van elk merk in kaart in die categorieën.
- Bewaar de onbewerkte code en het leveranciersveld altijd naast de toegewezen categorie.
- Bekijk de mapping opnieuw wanneer de firmware verandert, omdat de mapping mee kan veranderen.
Fouten die geen fouten zijn
Voor een aanzienlijk deel van de gemelde fouten is geen actie vereist. Een voertuig dat stopte met tekenen, een sessie die door de bestuurder werd beëindigd, een korte communicatieonderbreking die herstelde. Door deze naast echte fouten aan een operationeel team te presenteren, worden mensen getraind om waarschuwingen te negeren.
Het uitfilteren ervan is waardevoller dan het detecteren van meer fouten, en het is het eerste dat moet worden gebouwd en niet het laatste.
De volgorde is belangrijker dan de individuele code
Eén foutcode is een datapunt. Een patroon, zoals dezelfde code die elke dag op hetzelfde tijdstip op één connector terugkeert, is een diagnose. Het opslaan van de reeks met tijdstempels in plaats van alleen de huidige status maakt dat zichtbaar.
Dit is dezelfde reden waarom statusovergangen belangrijker zijn dan status. De informatie zit in de verandering, niet in de momentopname.
Wat moet u aan een leverancier van opladers vragen?
Een leverancier die deze kan beantwoorden, heeft nagedacht over de manier waarop zijn product wordt bediend. Velen kunnen dat niet, wat op zich de moeite waard is om te weten voordat je er een vloot van koopt.
- Welke interne voorwaarden op elke standaardcode betrekking hebben.
- Of er leverancierspecifieke foutinformatie wordt verstrekt en of deze is gedocumenteerd.
- Of de mapping stabiel is tussen firmwareversies.
- Welke storingen herstellen zichzelf en welke vereisen interventie?