Het bouwen van een oplaadbackend is niet in de eerste plaats een protocoloefening. Het protocol is gedocumenteerd en eindig. De moeilijkheid is het nauwkeurig bijhouden van duizenden langlevende verbindingen waarvan de tegenpartijen onbetrouwbaar en inconsistent zijn.
Ieder lastig probleem bij een laadplatform is daar een variant van.
Langdurige verbindingen veranderen de architectuur
Opladers houden wekenlang persistente verbindingen vast. Dat is anders dan request-response-webverkeer en beperkt de manier waarop het platform kan worden ingezet: een routinematige herstart verbreekt elke verbinding, en een vloot die opnieuw verbinding maakt, arriveert tegelijkertijd als een donderhoed.
Om dit te kunnen afhandelen is een verbindingsstatus nodig die het opnieuw opstarten van processen overleeft, of een implementatiemodel dat verbindingen netjes leegmaakt in plaats van ze te laten vallen.
Transactie-integriteit ondanks onderbrekingen
Een sessie kan beginnen, de verbinding kan wegvallen, de oplader kan opnieuw opstarten en de stop kan uren later of nooit plaatsvinden. Het platform moet al deze problemen omzetten in een verdedigbaar factuuroverzicht.
Dat betekent dat transacties niet in het geheugen kunnen worden bewaard als ze aan een verbinding zijn gekoppeld. Ze zijn duurzaam en hebben een levenscyclus die onafhankelijk is van de vraag of de lader momenteel bereikbaar is.
Duplicaten zijn gegarandeerd
Een oplader die geen bevestiging ontvangt, zal opnieuw verzenden. Vroeg of laat komt elk berichttype twee keer binnen, en de backend moet het herkennen in plaats van het als nieuw te behandelen.
Idempotentie is daarom een ontwerpvereiste, geen verfijning. Zonder dit netwerk zal een netwerk chauffeurs dubbel factureren, wat meer kost in vertrouwen dan de energie waard was.
Tolereer afwijkend gedrag van de oplader
Opladers verschillen qua ondersteunde configuratiesleutels, foutcodetoewijzing, statusovergangen en hoe strikt ze de specificatie volgen. Een backend die geschreven is tegen het gedrag van de ene leverancier, zal bij de tweede kapot gaan.
Het patroon dat overleeft is een kern die de specificatie afhandelt en een aanpassingslaag per leverancier die de verschillen normaliseert, waarbij de ruwe uitwisseling behouden blijft zodat onverwacht gedrag kan worden onderzocht in plaats van te raden.
Bewaar de uitwisseling
Het meest waardevolle operationele kenmerk is de mogelijkheid om uit te lezen wat er daadwerkelijk op een bepaald moment met een specifieke lader is uitgewisseld. Het beslecht geschillen met leveranciers, diagnosticeert periodieke fouten en beantwoordt factureringsvragen.
Platformen die alleen uitkomsten opslaan, maken van elk incident een kwestie van mening. Opslag kost geld; Het niet hebben van het spoor kost meer.
Het ondersteunen van twee protocolversies is permanent
Vloten migreren niet atomair, dus een backend die een echt netwerk bedient, ondersteunt voor onbepaalde tijd meer dan één versie. Door dat als een overgangstoestand te behandelen, ontstaat een architectuur die de realiteit bestrijdt.
De versies verschillen voldoende qua apparaat en transactiemodel, zodat dit bijna twee protocollen ondersteunt, en het vanaf het begin plannen ervan is veel goedkoper dan achteraf inbouwen.
Tijd is moeilijker dan het lijkt
Opladers dwalen af, rapporteren in hun eigen tijdzone en leveren transacties met terugwerkende kracht na storingen. Tarieven zijn tijdsafhankelijk, dus het verwerken van tijdstempels is eerder een probleem met de correctheid van de facturering dan een probleem met de opmaak.
Door alles in één absolute referentie op te slaan en de gerapporteerde tijd van de lader naast de ontvangen tijd te houden, is latere afstemming mogelijk.