Configuratiesleutels zijn de minst besproken en meest voorkomende bron van integratiefouten tussen een lader en een platform. Ze zijn de manier waarop een backend het gedrag van een oplader inspecteert en aanpast, en de specificatie laat veel ruimte voor interpretatie over wat er moet bestaan.
In die ruimte leven interoperabiliteitsproblemen, en daarom garandeert versie-compliance aan beide kanten heel weinig.
Wat configuratiesleutels doen
Een platform kan aan een lader vragen wat de huidige instellingen zijn en proberen deze te wijzigen. Heartbeat-interval, meterwaardebemonstering, connectortime-outs, autorisatiegedrag en vele andere parameters worden op deze manier zichtbaar.
Dit is hoe een backend een nieuw aangesloten oplader in een consistente bedrijfsstatus brengt zonder dat iemand de locatie bezoekt, wat het van fundamenteel belang maakt voor het exploiteren van een wagenpark op elke schaal.
Vereist, optioneel en leverancierspecifiek
Een platform geschreven tegen het wagenpark van één fabrikant gaat er vaak van uit dat optionele sleutels aanwezig zijn, omdat ze dat altijd waren. Introduceer een oplader die deze weglaat en het platform kan deze niet configureren, zonder dat een van beide partijen niet-conform is.
- Sommige sleutels vereisen volgens de specificatie dat elke oplader wordt ondersteund.
- Sommige zijn optioneel en een compatibele oplader heeft deze mogelijk eenvoudigweg niet.
- Sommige zijn leverancierspecifiek en hebben alleen betrekking op de eenheden van één fabrikant.
- Sommige zijn alleen-lezen en een poging om deze te wijzigen zal worden geweigerd in plaats van toegepast.
Geweigerde wijzigingen en stille niet-toepassing
Wanneer een platform probeert een sleutel in te stellen, kan de oplader deze accepteren, afwijzen, accepteren maar opnieuw opstarten voordat deze van kracht wordt, of acceptatie melden terwijl deze niet wordt toegepast.
Het derde geval is legitiem en gespecificeerd. De vierde is een defect en is moeilijk te detecteren zonder de waarde terug te lezen nadat deze is ingesteld. Geverifieerde terugmelding is de enige betrouwbare manier om te weten of er een configuratiewijziging heeft plaatsgevonden.
Waar drift zich ophoopt in een vloot
Opladers die op verschillende tijdstippen in bedrijf zijn gesteld, op verschillende firmware werken of door veldtechnici zijn gereset, krijgen uiteindelijk verschillende configuraties, terwijl ze op het platform identiek lijken. Foutpatronen worden dan onleesbaar, omdat hetzelfde symptoom verschillende oorzaken heeft, afhankelijk van hoe een bepaalde eenheid is ingesteld.
Het periodiek teruglezen van de configuratie door de hele vloot, in plaats van aan te nemen dat deze overeenkomt met wat werd gepusht, is de praktijk die dit voorkomt. Er zijn maar weinig operators die dit doen tot na een incident dat ze niet konden verklaren.
Hoofdlettergevoeligheid en naamgeving
Sleutelnamen zijn tekenreeksen, en implementaties variëren in hoe strikt ze daarmee overeenkomen. Een platform dat een sleutel aanvraagt met een ander hoofdlettergebruik dan de oplader gebruikt, ontvangt mogelijk niets en concludeert dat de sleutel niet wordt ondersteund wanneer deze aanwezig is.
Dit is een klein detail met een groot gevolg, en het is de moeite waard om dit uit te sluiten voordat we concluderen dat een oplader geen mogelijkheden heeft.
Wat u moet regelen tijdens de integratie
- Lees de volledige sleutellijst van de oplader in plaats van uit te gaan van een standaardset.
- Identificeer van welke sleutels het platform afhankelijk is en bevestig dat ze bestaan.
- Test of de wijzigingen van toepassing zijn, door terug te lezen in plaats van het antwoord te vertrouwen.
- Bepaal welke toetsen opnieuw moeten worden opgestart om van kracht te worden.
- Leg de configuratiebasislijn vast, zodat drift later kan worden gedetecteerd.
Waarom dit een interoperabiliteitsvraag is, en geen compliancevraagstuk?
Niets hierboven houdt in dat een van beide partijen de specificatie overtreedt. Beide kunnen volledig compliant zijn en toch niet kunnen samenwerken, omdat compliance een minimum definieert in plaats van een contract tussen twee specifieke implementaties.
Dit is de praktische reden dat de integratie wordt geverifieerd aan de hand van het platform en de firmwareversie die u wilt gebruiken, in plaats van te worden afgeleid uit een versienummer op een gegevensblad.