Laadpaal offline: monitoring, verbinding en laden uit elkaar houden

Er verschijnt een alarm in de monitoring: de laadpaal is offline. Moet u een technicus sturen, het netwerk contacteren of wachten? Er ontbreekt nog een essentieel gegeven: wat er ter plaatse echt gebeurt. Een communicatiealarm en een onmogelijkheid om te laden kunnen een gemeenschappelijke oorzaak hebben, maar het zijn niet twee formuleringen van dezelfde vaststelling.

Wat OCPP verbindt

OCPP regelt de uitwisselingen tussen een laadpaal en zijn beheersysteem. Die dialoog moet u onderscheiden van die tussen het voertuig en het toestel. De versie van het protocol en de functies die echt zijn geïmplementeerd, tellen mee: de naam OCPP garandeert op zich niet alle verwachte gedragingen, met name de mogelijkheden om zonder verbinding te werken.

Beschrijf concreet drie afzonderlijke toestanden: de laatst ontvangen communicatie, de status die in de monitoring wordt getoond en het resultaat van een echt gebruik wanneer dat bekend is. Een oude waarde mag niet worden voorgesteld als een waarneming in real time.

Beginnen met de omvang en het uur

• Is het maar één laadpaal of zijn meerdere toestellen van de site getroffen?
• Is het verlies van communicatie op meerdere punten op hetzelfde ogenblik begonnen?
• Wat is het uur van het laatst ontvangen gegeven, en in welke tijdzone?
• Is er een bekende onderbreking op de site, een netwerkingreep of een wijziging van de configuratie?
• Heeft een gebruiker vastgesteld dat laden onmogelijk is, of beschikt u alleen over een alarm op afstand?

Gelijktijdigheid helpt om de controles te prioriteren, maar volstaat niet om de oorzaak vast te stellen. Meerdere laadpalen die offline staan, kunnen een reden zijn om een gemeenschappelijke afhankelijkheid te onderzoeken. Dat bewijst niet dat een router defect is.

Een leesbare chronologie opstellen

1. Bewaar de eerste gebeurtenis van verlies van communicatie en de laatste gekende uitwisseling.
2. Verzamel de relevante berichten rond die periode, met de vereiste toestemming.
3. Voeg de bekende wijzigingen toe: onderhoud, netwerk, software of stroomonderbreking.
4. Breng die elementen in verband met de vaststellingen op de site.
5. Noteer elke actie van de helpdesk met tijdstip en resultaat.

Vermijd opeenvolgende herstarts die niet worden genoteerd: ze maken de chronologie moeilijker te interpreteren en kunnen een sessie onderbreken. Elke actie op afstand moet zijn toegestaan, aangepast aan het model en verenigbaar met de exploitatie. Hebt u niet het nodige mandaat, bezorg uw vaststellingen dan aan het verantwoordelijke team.

De controles verdelen over de juiste actoren

De monitoringhelpdesk kan de ontvangst van de gebeurtenissen en de configuratie die hij beheert onderzoeken. Het netwerkteam controleert zijn perimeter van toegang en connectiviteit. De onderhoudsfirma controleert het toestel als een interventie ter plaatse nodig is. Open geen openbare poort, schakel geen certificaatcontrole uit en deel geen beheerdersaccount om “te proberen”. Die kortere wegen verplaatsen het probleem naar de veiligheid.

Bepalen wat het herstel bewijst

Wacht na de correctie op recente, coherente uitwisselingen met het juiste toestel en controleer dan de functies die binnen de perimeter van de test voorzien zijn. Dat een lampje “verbonden” weer brandt, bewijst op zich niet dat een lading start en dat het verslag ervan correct doorkomt. Als de gebruikersproef niet kon worden uitgevoerd, vermeld dat dan in het dossier.

Bewaar ten slotte de perioden met ontbrekende gegevens als zodanig. Als u ze achteraf omzet in zekere beschikbaarheid of in een zeker defect, vervalst dat de indicatoren van het park. Een goed gevoerd onderzoek aanvaardt een status “onbekend” zolang het bewijs ontbreekt.