Programmeermal en provisioning van EV-lader
Het handmatig programmeren en inrichten van een oplader is niet schaalbaar en is de stap waarbij eenheden de lijn ongeconfigureerd verlaten. We bouwen mallen die automatisch testen, programmeren en inrichten, en elk resultaat loggen in het productlevenscyclussysteem, zodat er voor elke eenheid een record bestaat, lang nadat deze is verzonden.
Dit maakt deel uit van het productief maken van een EV-laderproduct op volume. De mal test en evalueert de eenheid, programmeert deze, bepaalt de identiteit ervan en schrijft de resultaten ergens waar ze kunnen worden opgehaald als een eenheid twee jaar later terugkomt van het veld.
Definieer uw inrichtingsstroomVoor Productie-ingenieur, eigenaar van de firmware, lokale OEM
Waar het station van toepassing is
Veeg om te vergelijken
| Toegepast | Waarom het wordt gecontroleerd |
|---|---|
| Firmware-build | Bepaalt het veldgedrag en moet overeenkomen met de gecertificeerde configuratie |
| Configuratie ingesteld | Vermogensniveau, connector, marktparameters, backend-eindpunt |
| Seriële identiteit | De sleutel waartegen elk productie- en veldrecord wordt gearchiveerd |
| Backend-referenties | Authenticeert het apparaat bij een laadbeheersysteem |
| Kalibratiewaarden | Waar de dosering aanpassing per eenheid vereist |
Het toepassen van een waarde en het bevestigen ervan zijn verschillende handelingen. Alleen het tweede is bewijs, en daarom wordt elk item hierboven teruggelezen en vergeleken in plaats van dat wordt aangenomen dat het met succes is geschreven.
Identiteit is geen seriële sticker
Een serienummer identificeert het apparaat voor u. Met backend-referenties kan de eenheid die identiteit laten gelden bij een systeem dat deze vertrouwt. Dat zijn verschillende problemen met verschillende faalwijzen.
- Inloggegevens moeten uniek zijn per eenheid en mogen niet door een batch worden gedeeld
- De referentiebron heeft toegangscontrole nodig, omdat het station vertrouwde identiteiten kan creëren
- Bij mislukte of gesloopte eenheden moeten de inloggegevens worden ingetrokken en niet alleen worden weggegooid
- Herwerkte eenheden mogen geen tweede identiteit verwerven terwijl ze de eerste behouden
Het geval van de gesloopte eenheid wordt het vaakst gemist. Een bord dat na de inrichting de laatste test niet doorstaat, beschikt nog steeds over een geldige inloggegevens, en als de verwijderingsroute deze niet intrekt, verlaat die inloggegevens de fabriek.
Armatuur ontwerp
Het armatuur presenteert de programmeerinterface betrouwbaar over duizenden invoegingen, houdt de eenheid in een herhaalbare positie en faalt in een veilige toestand als de cyclus wordt onderbroken. Contactslijtage is het belangrijkste onderhoudsitem, en een verslechterend contact veroorzaakt periodieke programmeerfouten die op firmwarefouten lijken.
Compatibiliteit van versies
Programmeersoftware is aangepast aan productrevisies. Een armatuur mag geen build kunnen laden die bedoeld is voor een andere variant, omdat de resulterende eenheid de onmiddellijke controles doorstaat en zich tijdens gebruik onjuist gedraagt.
Dit wordt op het station afgedwongen en niet via een procedure. Een bediening die afhankelijk is van een operator die het juiste menu-item selecteert, zal uiteindelijk mislukken tijdens een drukke dienst.
Opnames
Elke cyclus registreert het serienummer, de firmwareversie en hash, de toegepaste configuratie, het station, de operator en de tijdstempel. Met dat record kun je een firmwareprobleem beperken tot een datumbereik en een station, in plaats van tot een volledige productierun.
Waar dit zich bevindt ten opzichte van de end-of-line-test
Programmering en end-of-line-test zijn afzonderlijke stations met verschillende doeleinden. Programmering maakt het apparaat tot wat het bedoeld is. De end-of-line-test bewijst dat dit het geval is. Door ze in één stap te combineren, wordt vloerruimte bespaard en wordt de onafhankelijke controle weggenomen, wat bij elk volume een slechte zaak is.
Hoe wij hierin met u samenwerken
Programmering en provisioning hebben invloed op uw beveiligingshouding, dus dit wordt samen met uw team opgebouwd en niet terzijde geschoven. Sleutelafhandeling, certificaatvoorziening en wie wat in handen heeft, zijn beslissingen die u moet nemen en begrijpen, en geen beslissingen die een leverancier stilletjes voor u moet nemen.
Onze engineers zetten het ter plaatse op en blijven bij de eerste productieruns. Daarna valt het onder dezelfde maandelijkse ondersteuningsregeling als de rest van de lijn.
Wat een geautomatiseerde mal doet
- 1
Test en evalueert
De eenheid wordt geoefend in plaats van geïnspecteerd, zodat een storing op de lijn wordt opgemerkt in plaats van op de locatie van de klant.
- 2
Programma's
Firmware geladen en geverifieerd, bij takt, zonder een ingenieur met een kabel.
- 3
Voorzieningen
Identiteit, sleutels en configuratie geschreven als een gecontroleerde productiestap in plaats van als iets dat achteraf wordt gedaan.
- 4
Logboeken
Elk resultaat wordt geregistreerd op basis van het serienummer van het apparaat, in het productlevenscyclussysteem.
De besparing op mankracht is het voor de hand liggende voordeel. Het record is het record dat zich later terugbetaalt.
Waarom het logboek belangrijker is dan de test
Een test die slaagt en niet wordt vastgelegd, bewijst drie jaar later niets, en dat is precies het moment waarop iemand erom vraagt.
De resultaten worden geschreven in het productlevenscyclusbeheersysteem, dat in ons eigen bedrijf de S3-suite is. Wanneer een apparaat uit het veld terugkeert, is het volledige productierecord opvraagbaar: wat er is getest, wat de meetwaarden waren, welke firmware het heeft achtergelaten, welke componenten zijn gemonteerd. Dat verandert een veldfout van een gok in een analyse, en het is ook wat een klant die uw lijn controleert, zal vragen om deze te zien.
Hoe wij het voor u bouwen
De mallen zijn ontworpen voor uw product en uw lijn en worden niet uit een catalogus geleverd. De functieset komt voort uit wat u moet testen en wat uw proces vereist, en het werk maakt deel uit van een breder productieprogramma en staat niet op zichzelf.
Onze ingenieurs bouwen het samen met uw productie- en kwaliteitsteams en blijven bij de eerste runs, omdat testlimieten worden herzien zodra een lijn echte gegevens begint te genereren.
Toegepast op uw eigen locatie?
Definieer uw inrichtingsstroomGerelateerde inhoud
Technisch beoordeeld door Deepu Joy, Director of Products and Delivery. Laatst beoordeeld 2026-08-29.
Veelgestelde vragen
Kunnen programmering en end-of-line-test een station delen?
Dat kan fysiek, maar het moeten afzonderlijke activiteiten blijven met afzonderlijke records. Programmering stelt de unit in en de end-of-line-test verifieert deze onafhankelijk. Als u ze samenvoegt, wordt de vink verwijderd.
Levert u het programmeerapparaat?
Het armatuurontwerp, de programmeersoftware, de provisioningmethode en het recordformaat kunnen allemaal deel uitmaken van de overdracht. Bevestig de opgegeven omvang voor uw programma.
Hoe worden backend-referenties beschermd?
Inloggegevens zijn uniek per eenheid en de inloggegevensbron wordt gecontroleerd op toegang, omdat een programmeerstation identiteiten kan creëren die een backend zal vertrouwen.
Wat gebeurt er met de inloggegevens op een afgedankt apparaat?
Ze worden ingetrokken in plaats van weggegooid. Een ingerichte eenheid die de laatste test niet doorstaat, heeft nog steeds een geldige referentie totdat iets deze verwijdert.
Hoe voorkom je dat de verkeerde firmware wordt geladen?
Programmeersoftware wordt aangepast aan productrevisies en het station dwingt de match af. Een controle die erop vertrouwt dat de operator de juiste keuze maakt, zal uiteindelijk mislukken.
Wat wordt er opgenomen op het programmeerstation?
Serieel, firmwareversie en hash, toegepaste configuratie, station, operator en tijdstempel.
Definieer uw inrichtingsstroom
Vertel ons uw varianten, lijntarief en backend, en wij definiëren wat het programmeerstation toepast, verifieert en vastlegt.
Definieer uw inrichtingsstroom