Welke backend moet je als OEM meeleveren met je laders

De productbeslissingen van een laderfabrikant stoppen niet bij de hardware. Zodra een lader de fabriek verlaat, moet iemand drie vragen beantwoorden: hoe configureert en monitort een installateur hem, hoe start de gebruiker een sessie en ziet wat die heeft gekost, en hoe praat hij met al het andere, een energiemanagementsysteem, een fleettool, een facturatieplatform. Kies de verkeerde backend en alle drie de antwoorden betekenen ofwel software bouwen die het bedrijf niet kan onderhouden, ofwel een platform kiezen dat het merk vastzet aan de roadmap van één leverancier.

De drie dingen die kopers echt vragen

In de praktijk heeft een OEM die een lader levert een CSMS nodig om hem te beheren, een app of portaal zodat gebruikers niet met een handleiding zitten, en een manier voor andere software om verbinding te maken. Plugchoice's OEM-programma bundelt dat: een CSMS dat het merk van de OEM kan dragen, een app voor rijder en installateur die op OCPP draait in plaats van een eigen protocol, en een publieke REST API eronder. De white-labelonderdelen lopen via een aparte overeenkomst.

Het white-label deel is geen laagje verf. Het webportaal, de gebrande e-mails en de mobiele app kunnen het logo, de kleuren en het domein van de OEM dragen. White-labeling, de gebrande e-mails, een eigen domein en een gebrande app regel je in een aparte overeenkomst.

Waarom "draait op OCPP" het deel is dat telt

Het verschil dat een OEM echt beschermt, is niet dat de app gebrand oogt, het is welk protocol eronder zit. Een app die tegen de eigen API van één backend is gebouwd, stopt met werken zodra die backend verandert, of dat nu is omdat de OEM van platform wisselt, een klant een andere backoffice wil draaien, of een reseller de lader op infrastructuur wil zetten die de OEM niet beheert. Een app die op OCPP is gebouwd, blijft de lader aansturen ongeacht welke backoffice erachter zit, want de OCPP-proxy van Plugchoice kan de berichten van een lader naar een bestaande backoffice routeren zonder die te vervangen. De bestaande opstelling van een klant blijft werken terwijl de eigen app en het portaal van de OEM ernaast draaien.

Wat er onder de motorkap meekomt

Voorbij de app en het portaal kan Plugchoice in een aparte overeenkomst een OEM-kant inrichten om een vloot over productlijnen heen te beheren: feature flags om functies per ladermodel aan of uit te zetten, virtuele producten zodat een nieuw ladermodel automatisch de juiste standaardconfiguratie overneemt, en tools voor de firmwarelevenscyclus, versiebeheer over de hele vloot, gefaseerde uitrol naar een testgroep voordat een bredere push volgt, en updates op afstand zonder locatiebezoek. Firmwarebeheer en configuratie op afstand horen nu al bij het platform. Niets daarvan vereist dat het eigen engineeringteam van de OEM een device-managementbackend vanaf nul bouwt of onderhoudt.

Twee commerciële modellen

Het OEM-programma van Plugchoice kan op twee commerciële modellen draaien, vastgelegd in een getekende overeenkomst, en de keuze bepaalt wie de klantrelatie bezit. Onder het gratis model biedt de OEM Plugchoice zonder voorafgaande kosten aan zijn klanten aan, en betalen klanten voor de betaalde functies die ze activeren, zoals Smart Charging. Onder het OEM-managed model houdt de OEM de volledige klantrelatie en prijscontrole zelf, en betaalt in plaats daarvan een terugkerend platformtarief per lader aan Plugchoice. White-labeling is beschikbaar onder beide modellen, in die overeenkomst. Geen van beide modellen vereist exclusiviteit: de OCPP-proxy zorgt ervoor dat een lader door de gebrande laag van de OEM kan draaien terwijl hij nog steeds verbonden is met welke backoffice de eindklant ook al gebruikt.

Erbovenop bouwen

Voor OEM's of hun integratiepartners die hun eigen tools willen aansluiten in plaats van te vertrouwen op alleen het portaal en de app, biedt hetzelfde systeem een publieke REST API: persoonlijke toegangstokens voor snelle integraties en interne tools, OAuth 2.0 voor productieapplicaties die afgebakende, gedelegeerde toegang nodig hebben. De API geeft data in hetzelfde formaat terug over ladermerken heen, voor zover elke lader ze meldt: laders, sessies, meterstanden, configuratie, zodat de eigen dashboards van een OEM of het energiemanagementsysteem van een klant geen aparte logica nodig hebben voor elke hardwarevariant in de vloot.

Welk model een OEM moet kiezen hangt af van hoeveel van de klantrelatie hij zelf wil bezitten en hoeveel platformrisico hij zelf wil dragen. Wat niet verandert over die keuze heen, is het protocol eronder: een app en backend gebouwd op OCPP is de ene keuze die niet steeds opnieuw hoeft te worden bekeken zodra een klant, een markt, of een backendeis verandert.