Di ChargeRFID
Metodo di verifica: Abbiamo verificato questa guida sulla base delle fonti primarie relative alla normativa e ai protocolli e di quelle dei produttori elencate di seguito. Le raccomandazioni sui prodotti riflettono il punto di vista di ChargeRFID in quanto produttore e dovrebbero essere validate con il vostro lettore, la vostra stazione di ricarica e il vostro backend.

Per configurare l’accesso RFID alle stazioni di ricarica aziendali, verifichi che il lettore sia compatibile con il supporto di identificazione scelto, acquisisca l’identificatore effettivamente trasmesso dalla stazione, registri quel valore nella piattaforma di ricarica, assegni i diritti di accesso necessari e collaudi l’intera sessione di ricarica. Verifichi poi cosa accade quando la connessione si interrompe e quando una tessera viene revocata.
Ordini il lotto di produzione dopo che un campione rappresentativo ha superato questa procedura. Una lettura riuscita conferma soltanto una parte del risultato. Il verbale di accettazione deve attestare anche il punto di ricarica corretto, l’account, la registrazione dell’energia e il comportamento all’arresto.
Questa guida riguarda la gestione degli accessi dopo che un installatore qualificato ha installato e messo in servizio l’apparecchiatura di ricarica. È rivolta al team che collega i supporti fisici di identificazione a un sistema di gestione della ricarica.
Comprendere quale sistema prende ciascuna decisione
In un flusso di autorizzazione online, il lettore RFID acquisisce un identificatore, la stazione di ricarica lo inoltra a un sistema di gestione delle stazioni di ricarica, o CSMS, e la piattaforma restituisce l’esito dell’autorizzazione. OCPP disciplina la comunicazione tra la stazione e tale sistema di gestione. L’interfaccia radio tra tessera e lettore è una parte distinta dell’integrazione. Si veda la panoramica del protocollo di Open Charge Alliance.
| Livello | Cosa occorre accertare |
|---|---|
| Supporto fisico di identificazione e lettore | Il lettore può acquisire l’identificatore previsto o autenticare l’applicazione prevista sulla tessera. |
| Stazione e CSMS | L’identificatore trasmesso raggiunge il backend corretto tramite il protocollo e nella rappresentazione concordati. |
| Account e politica di accesso | Il supporto è assegnato all’account corretto e ai luoghi di ricarica consentiti. |
| Transazione e fatturazione | La sessione risultante viene attribuita e tariffata secondo l’accordo commerciale previsto. |
| Collegamento roaming facoltativo | Il gestore della ricarica e il fornitore di servizi di mobilità possono scambiare e autorizzare il token in base al loro accordo. |
Assegni a una persona la responsabilità di ciascun livello. Il fornitore delle tessere può consegnare il supporto fisico e il file degli identificatori concordati; l’integratore delle stazioni conferma il comportamento del lettore; il gestore della piattaforma controlla la registrazione degli account e i permessi. Documenti chi deve risolvere eventuali discrepanze prima dell’avvio della messa in servizio.
1. Confermare le capacità del lettore e di autorizzazione
Richieda le specifiche del lettore per l’esatto modello di stazione, la revisione hardware e il firmware installato. Annoti gli standard contactless supportati, la modalità di utilizzo del supporto e le eventuali conversioni configurabili dell’identificatore. Una descrizione come «abilitato RFID» lascia aperte queste domande.
NFC opera a 13,56 MHz e comprende diverse tecnologie contactless, tra cui ISO/IEC 14443 Type A, Type B e ISO/IEC 15693. La sola corrispondenza della frequenza è quindi una specifica d’acquisto incompleta. Verifichi la compatibilità tra la tecnologia effettiva della tessera e l’implementazione del lettore. La panoramica tecnica di NFC Forum illustra questi protocolli di base.
Accerti poi cosa implementano effettivamente la stazione e il backend:
La certificazione OCPP va letta a livello delle singole funzionalità. L’aggiornamento OCA di dicembre 2025 colloca Local List Management tra le funzionalità facoltative del profilo OCPP 2.0.1 Core. Il programma di certificazione aggiornato non garantisce quindi che ogni stazione certificata supporti gli elenchi locali. Anche la nota applicativa OCPP 2.Lite, sezione C di OCA spiega che la cache di autorizzazione può essere omessa e che le implementazioni possono supportare metodi di autorizzazione diversi.
Richieda l’ambito del certificato e il Protocol Implementation Conformance Statement, ove disponibili, e li confronti con il software installato. Conservi queste evidenze insieme alla configurazione del sito.
OCA pubblica attualmente pacchetti OCPP 1.6, 2.0.1 e 2.1. Gli esempi seguenti riguardano specificamente 1.6 e 2.0.1; per un’installazione 2.1 utilizzi la specifica corrispondente. Consulti i download ufficiali e gli errata durante la messa in servizio o gli aggiornamenti.
2. Acquisire l’identificatore dalla stazione effettiva

Inizi con un piccolo gruppo di tessere di prova identificabili. Tenga separato il riferimento stampato sulla tessera dal valore elettronico: un numero di serie visibile come CRF-TEST-0042 è utile per l’assistenza, ma il suo rapporto con l’identificatore del backend deve essere documentato.
Questi frammenti di payload illustrano una richiesta di autorizzazione OCPP online con un identificatore fittizio:
OCPP 1.6
{"idTag":"04A1B2C3D4E5F7"}OCPP 2.0.1
{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}I frammenti omettono l’incapsulamento dei messaggi WebSocket. Gli schemi ufficiali definiscono un massimo di 20 caratteri per idTag in 1.6 e di 36 per la stringa idToken in 2.0.1; la versione 2.0.1 richiede anche il tipo di token. Esegua la validazione rispetto al pacchetto OCPP 1.6 o al pacchetto OCPP 2.0.1 Edition 4 utilizzato per l’integrazione.
Un avvio autorizzato localmente può seguire una sequenza di messaggi diversa. Chieda all’integratore di indicare dove vengono registrati il supporto e la decisione di autorizzazione per quella modalità.
3. Concordare la rappresentazione degli UID prima di importare le tessere
Per un token ISO14443, OCPP 2.0.1 raccomanda byte UID esadecimali con il byte 0 per primo. Occorre comunque verificare il comportamento dei prodotti esistenti: la guida di attivazione OCPP di Wallbox specifica valori esadecimali little-endian senza separatori per i prodotti trattati. È un’istruzione specifica di quei prodotti, non una regola universale di conversione. Si vedano OCPP 2.0.1, sezione di autorizzazione C.1.1 e la guida di attivazione Wallbox, pagine 14 e 20.
Per questa sequenza fittizia di sette byte, le rappresentazioni sono:
| Rappresentazione | Valore |
|---|---|
| Byte nell’ordine indicato | 04 A1 B2 C3 D4 E5 F7 |
| Esadecimale senza separatori | 04A1B2C3D4E5F7 |
| Ordine dei byte invertito | F7E5D4C3B2A104 |
| Decimale senza segno, interpretando l’ordine indicato con il byte più significativo per primo | 1303689068602871 |
La tabella mostra trasformazioni, non quattro valori intercambiabili nel backend. Importi la rappresentazione richiesta dall’integrazione. Invertire i byte ne cambia l’ordine a coppie di caratteri; invertire i singoli caratteri produce un risultato diverso.
Mantenga una corrispondenza scritta tra i dati del fornitore, il registro della stazione e il campo di importazione del backend. Includa lunghezza in byte, notazione esadecimale o decimale, ordine dei byte, separatori ed eventuali trasformazioni esplicitamente documentate. Conservi il file sorgente grezzo. Eviti troncamenti non documentati o tentativi di indovinare i byte mancanti.
Verifichi le impostazioni del dispositivo che trasformano gli identificatori. Il manuale Wallbox eM4 WebAdmin, per esempio, include un’opzione «Shorten UIDs» e avverte che le impostazioni di autorizzazione possono essere modificate sia dall’interfaccia locale sia dal backend. Si veda il manuale Wallbox WebAdmin, pagina 23. Registri la configurazione effettiva dopo la connessione di entrambi i sistemi.
Importi le colonne degli identificatori nei fogli di calcolo come testo. Excel può eliminare gli zeri iniziali e limita la precisione numerica a 15 cifre significative; il nostro esempio decimale ne contiene 16. Applicare un formato di visualizzazione dopo l’alterazione dei dati non ripristina l’identificatore originale. Segua le indicazioni Microsoft per preservare i dati degli identificatori.
Utilizzi il convertitore UID ChargeRFID per esaminare le rappresentazioni e lo strumento di riconciliazione dei file dei supporti per confrontare i file di produzione e del backend. Confermi la corrispondenza proposta rispetto a un registro reale della stazione prima di applicarla al lotto.
4. Registrare i supporti e assegnare i permessi commerciali

Crei la registrazione del supporto tramite la procedura di iscrizione o importazione documentata dalla piattaforma. La associ al conducente, al veicolo, al reparto o all’account cliente previsto, in base al modo in cui l’organizzazione attribuisce le ricariche.
Per ciascun supporto del progetto pilota, registri:
Mantenga separati questi criteri di accettazione. Un supporto può comparire nel database senza disporre del permesso previsto per il luogo o dell’assegnazione all’account corretto. Allo stesso modo, un avvio riuscito non dimostra che sia stato applicato il corretto accordo di fatturazione.
Utilizzi un registro di iscrizione con riferimento del lotto, esito dell’importazione, motivo dell’eccezione e revisore. Risolva valori duplicati e assegnazioni in conflitto prima del rilascio. Adatti il modello di consegna degli UID alle effettive specifiche di importazione della piattaforma; la riga di esempio contiene dati di prova.
Per i veicoli condivisi, concordi chi può arrestare una sessione. I casi di test OCPP 1.6 di OCA includono esplicitamente l’arresto con la tessera di avvio e con un’altra tessera collegata tramite un identificatore padre corrispondente. Collaudi il comportamento di gruppo che intende abilitare. Si vedano i casi di test OCTT 2026-02, sezioni 2.3.1 e 2.3.2.
5. Definire una politica esplicita di accesso offline
Decida se la ricarica debba restare disponibile quando la stazione non riesce a raggiungere il sistema di gestione. Per un deposito di flotta ad accesso limitato, una ragionevole politica iniziale è accettare i supporti previsti autorizzati localmente e rifiutare le tessere sconosciute durante un’interruzione. Verifichi che l’apparecchiatura possa attuare questa politica prima di farvi affidamento.
Una cache di autorizzazione conserva le informazioni di autorizzazione apprese negli scambi precedenti. Un elenco locale di autorizzazione viene gestito e sincronizzato dal backend. Sono meccanismi distinti. Svuotare l’uno non dimostra che l’altro sia stato aggiornato. OCPP 1.6 ne descrive il rapporto nella sezione 3.5 della specifica.
I seguenti sono esempi di nomi specifici della versione da discutere con l’integratore, non un file di configurazione da incollare in una stazione:
| Funzione | OCPP 1.6 | OCPP 2.0.1 |
|---|---|---|
| Cache di autorizzazione | AuthorizationCacheEnabled | AuthCacheEnabled |
| Elenco locale di autorizzazione | LocalAuthListEnabled | LocalAuthListEnabled |
| Autorizzazione locale offline | LocalAuthorizeOffline | LocalAuthorizeOffline |
| Preautorizzazione locale | LocalPreAuthorize | LocalPreAuthorize |
| Supporti sconosciuti offline | AllowOfflineTxForUnknownId | OfflineTxForUnknownIdEnabled |
Questi nomi non dichiarano che ogni funzionalità sia implementata, abilitata o modificabile. OCPP 2.0.1 utilizza l’indirizzamento per componenti e variabili; il modello del dispositivo e il caso d’uso applicabile determinano il funzionamento di ogni impostazione. Si vedano le sezioni dell’Edition 4 sull’autorizzazione e sulle variabili richiamate.
Registri la capacità dell’elenco locale, la conferma di aggiornamento, la gestione delle scadenze, la persistenza dopo un riavvio e il comportamento quando la memoria è piena. Collaudi sia un supporto noto ma mai utilizzato sulla stazione, sia uno già autorizzato in precedenza su quella stazione. Questo aiuta a individuare il meccanismo locale su cui l’installazione si basa effettivamente.
Includa la riconnessione nel collaudo. Verifichi come le transazioni offline raggiungono il backend, come vengono riconciliate e cosa accade a una sessione in corso se il backend rifiuta il supporto dopo il ripristino della connessione. Concordi con il proprietario del sito l’esposizione operativa e finanziaria accettabile.
6. Scegliere consapevolmente il modello di sicurezza dei supporti
Chieda se il lettore si limita a leggere un identificatore o esegue un’autenticazione crittografica con il supporto. In un’architettura basata solo sull’UID, l’accettazione di un identificatore corrispondente non dimostra il possesso di un segreto crittografico. Acquistare un chip con funzionalità di sicurezza offre valore solo se il lettore e l’applicazione installati le utilizzano.
Quando è richiesta l’autenticazione crittografica della tessera, documenti l’applicazione supportata, la titolarità delle chiavi, il processo di provisioning, la procedura di sostituzione e le responsabilità di migrazione. Escluda i segreti dai file di consegna degli UID. Le linee guida NIST sulla sicurezza RFID, sezione 5.3.1, descrivono la distinzione tra identificatori e controlli di autenticazione. Sono indicazioni fondamentali pubblicate nel 2007; utilizzi la documentazione attuale dei prodotti per scegliere algoritmi e meccanismi di gestione delle chiavi supportati.
Protegga separatamente la connessione tra stazione e backend. L’attuale Security Operations Guide di OCA, sezioni 4.2 e 4.4, descrive Security Profile 2 come TLS con Basic Authentication e Profile 3 come TLS con certificati lato client, e tratta la conservazione dei dati di autenticazione. Confermi il profilo di trasporto utilizzato, la validazione dei certificati e la gestione dei dati di autenticazione della stazione. Queste impostazioni proteggono una connessione diversa dal collegamento tra tessera e lettore.
7. Aggiungere l’autorizzazione roaming solo se richiesta dal servizio
Un’installazione privata sul luogo di lavoro può richiedere soltanto il registro dei supporti della propria piattaforma. Il roaming aggiunge un ulteriore confine: il gestore dei punti di ricarica, o CPO, deve ottenere l’autorizzazione dal fornitore di servizi di mobilità elettrica interessato, o eMSP, attraverso l’integrazione supportata e l’accordo commerciale previsto.
In OCPI 2.3.0, il record di un token contiene gli identificatori del paese e dell’operatore del fornitore proprietario, un UID del token, il tipo, la validità e la politica di whitelist. La politica ALLOWED_OFFLINE riguarda la comunicazione tra CPO ed eMSP. La perdita della connessione tra stazione e CSMS è un’interruzione distinta. Collaudi entrambi i confini se sono entrambi presenti.
Il modulo Tokens distingue anche un token valido da uno consentito in un luogo specifico. L’invalidazione viene propagata tramite un token aggiornato con valid: false; l’eliminazione dei token tramite quell’interfaccia non è il meccanismo previsto. Verifichi il modulo Tokens ufficiale di OCPI 2.3.0 rispetto alla versione concordata con il partner.
Per il progetto pilota, identifichi l’emittente e la rete partecipante, definisca il percorso di autorizzazione atteso e verifichi la sessione e la registrazione della ricarica risultanti. Riutilizzare la stessa tessera fisica per più servizi richiede comunque le registrazioni, i permessi e gli accordi appropriati.
8. Collaudare l’intero ciclo di vita dell’accesso
Utilizzi una matrice di test con risultati attesi scritti prima del collaudo. La esegua per ogni configurazione distinta di hardware, firmware e backend, quindi verifichi a campione il parco installato rispetto alla configurazione approvata.
| Test | Evidenze di accettazione da conservare |
|---|---|
| Tessera autorizzata online | Identificatore corretto, punto di ricarica consentito e account previsto; la sessione si avvia come atteso. |
| Tessera sconosciuta online | Rifiuto previsto; nessuna sessione di ricarica involontaria. |
| Supporto limitato o scaduto | Decisione prevista nel luogo e nel momento pertinenti. |
| Arresto della sessione | La tessera di avvio e le eventuali tessere di gruppo abilitate deliberatamente si comportano come concordato; le tessere estranee non possono arrestare la sessione. |
| Lettore condiviso o più connettori | L’autorizzazione è associata al punto di ricarica e alla sessione previsti. |
| Connessione della stazione interrotta | Le tessere già utilizzate, precaricate, sconosciute e revocate seguono la politica offline. |
| Connessione ripristinata | Le sessioni offline vengono riconciliate; i conflitti di autorizzazione e le sessioni in corso seguono il comportamento concordato. |
| Riavvio dopo la sincronizzazione | La configurazione prevista e lo stato locale dei supporti persistono o vengono ripristinati come documentato. |
| Fatturazione e allocazione | Identità della sessione, unità di energia, marcature temporali, account e tariffa o centro di costo corrispondono alla registrazione attesa. |
| Tessera persa e sostituzione | Il vecchio supporto viene revocato lungo ogni percorso di autorizzazione rilevante; il sostituto funziona con l’assegnazione prevista. |
Per ogni esecuzione, conservi ora, identificatori della stazione e del connettore, firmware, riferimento della tessera di prova, configurazione effettiva, risultato atteso, risultato reale e registrazione della transazione pertinente. Oscuri i dati personali nelle evidenze condivise al di fuori del team operativo.
Quando una tessera viene persa, registri quando è arrivata la segnalazione e quando ciascun sistema connesso ha confermato la modifica. Una stazione disconnessa non può ricevere immediatamente una nuova revoca. L’esposizione effettiva dipende dallo stato di autorizzazione memorizzato, dalle regole di scadenza e dal comportamento alla riconnessione. Gestisca tale intervallo nella procedura operativa.
Diagnosticare una lettura non riuscita al confine corretto
Raccolga un tentativo fallito con marcatura temporale e riferimento della tessera, quindi esamini le evidenze. Questi controlli restringono l’indagine senza presumere che ogni rifiuto abbia la stessa causa.
| Risultato osservato | Controllo successivo |
|---|---|
| Nessun identificatore nella diagnostica disponibile | Confermare la copertura diagnostica, poi la modalità del lettore, la tecnologia di identificazione supportata e il funzionamento con un campione sicuramente funzionante. |
| Il valore trasmesso differisce dal file di importazione | Confrontare ordine dei byte, notazione, separatori ed eventuali trasformazioni dell’identificatore; conservare i valori originali. |
| Il backend riceve il valore previsto ma lo rifiuta | Esaminare stato restituito, assegnazione all’account, attivazione, scadenza e permessi relativi al luogo. |
| Una tessera funziona online ma non durante un’interruzione | Verificare quale meccanismo locale di autorizzazione è implementato, popolato e abilitato per quel supporto. |
| Una tessera revocata funziona ancora localmente | Esaminare conferma di sincronizzazione, versione dell’elenco locale, stato della cache e regole di scadenza effettive. |
| La sessione è assegnata all’account sbagliato | Verificare le associazioni dei supporti, le assegnazioni duplicate e la registrazione della transazione risultante prima di distribuire altre tessere. |
Esempio di introduzione in un deposito di flotta
Si consideri un deposito fittizio con 60 conducenti, 12 punti di ricarica e due modelli di stazione. Il gestore vuole attribuire l’accesso ai singoli conducenti, limitarlo al deposito e consentire ai conducenti approvati di ricaricare durante un’interruzione del backend.
Inizi con cinque supporti campione. Su ciascun modello di stazione, acquisisca l’identificatore trasmesso e concordi la corrispondenza con il file del fornitore. Registri i campioni in un account pilota, assegni l’accesso al deposito e confermi il centro di costo previsto.
Se l’apparecchiatura supporta un elenco locale gestito, precarichi i supporti pilota e registri la versione confermata. Per questa politica proposta, mantenga disabilitati i supporti sconosciuti offline. Scolleghi la stazione dal CSMS durante un test controllato, poi provi una tessera precaricata, una sconosciuta e una revocata con uno stato locale obsoleto deliberatamente documentato. Ripristini la connessione e verifichi l’aggiornamento e le registrazioni delle transazioni.
Completi i test di rifiuto online, arresto della sessione e fatturazione su entrambi i modelli. Dopo il superamento del pilota, riconcili il file di produzione di 60 tessere con il registro del backend, risolva le eccezioni e distribuisca le tessere con una semplice procedura di segnalazione dello smarrimento. Ripeta i test di accettazione pertinenti dopo modifiche sostanziali a firmware, modalità del lettore o piattaforma.
Domande da risolvere prima dell’ordine
Le tessere RFID di ricarica devono essere programmate?
Per un’architettura che legge l’UID esistente della tessera, la configurazione può consistere nella registrazione di quel valore e nell’assegnazione dell’accesso nella piattaforma. Un’architettura con applicazione protetta può richiedere la personalizzazione della tessera e una configurazione coordinata del lettore. Specifichi l’esatto flusso operativo del lettore prima di ordinare uno dei due servizi.
Un badge aziendale esistente può sbloccare anche una stazione di ricarica?
Può essere possibile quando il lettore supporta la tecnologia del badge, l’identificatore richiesto è disponibile e stabile e la piattaforma consente la registrazione. Ottenga l’approvazione del responsabile del sistema di badge e collaudi campioni reali. Come esempio di registrazione specifica di una piattaforma, la documentazione Easee su account e chiavi locali descrive ambiti di registrazione distinti e segnala i rischi degli identificatori variabili.
Una tessera funzionerà su tutte le reti di ricarica?
Verifichi singolarmente le reti previste. Leggibilità fisica, registrazione del supporto, diritti dell’account ed eventuali accordi di roaming sono tutti parte dei criteri di accettazione. Collaudi la rete partecipante anziché presumere la copertura dall’aspetto della tessera.
Cosa deve ricevere il fornitore delle tessere?
Fornisca i requisiti del lettore, la corrispondenza degli identificatori approvata sul campione, lo schema di numerazione visibile, le specifiche di materiale e stampa, la quantità e il formato concordato di consegna dei dati. Indichi il responsabile dell’importazione nel backend e dell’accettazione dei campioni. Trasferisca i segreti applicativi attraverso un processo sicuro di provisioning concordato separatamente, quando l’architettura lo richiede.
Preparare una specifica dei campioni per il progetto
Riunisca in una sola specifica il modello di stazione e il firmware, il nome del backend e la versione del protocollo, la modalità richiesta per il supporto, la rappresentazione confermata dell’identificatore e la politica offline prevista. Utilizzi il laboratorio dei supporti ChargeRFID per esaminare la consegna dei dati e richieda campioni finiti per il progetto pilota. Approvi insieme il supporto fisico e l’intero flusso di accesso prima di autorizzare l’ordine di produzione.
I nomi di aziende, reti e prodotti citati in questo articolo sono marchi dei rispettivi titolari. Sono usati in modo descrittivo per indicare i sistemi con cui le nostre schede sono compatibili. ChargeRFID è un produttore indipendente e questo articolo non afferma alcuna affiliazione, partnership o approvazione.
Fonti primarie (15)
- Open Charge Alliance protocol overviewOpen Charge Alliance
- NFC Forum technical overviewNFC Forum
- updated certification programOpen Charge Alliance
- OCPP 2.Lite application note, section COpen Charge Alliance
- official downloads and errataOpen Charge Alliance
- OCPP 1.6 packageOpen Charge Alliance
- OCPP 2.0.1 Edition 4 packageOpen Charge Alliance
- Wallbox activation guide, pages 14 and 20Wallbox
- Wallbox WebAdmin manual, page 23Wallbox
- Microsoft's guidance for preserving identifier dataMicrosoft
- OCTT 2026-02 test cases, sections 2.3.1 and 2.3.2Open Charge Alliance
- RFID security guidance, section 5.3.1NIST
- Security Operations Guide, sections 4.2 and 4.4Open Charge Alliance
- official OCPI 2.3.0 Tokens moduleOCPI specification repository
- Easee account and local-key documentationEasee
Passo successivo
Trasformi gli approfondimenti in una specifica per la card.
Condivida il contesto relativo a lettore, chip, dati o implementazione: individueremo le decisioni necessarie per i campioni e la produzione.
Continua a leggere
Articoli correlati

Card RFID per flotte: guida alla gestione operativa dei veicoli elettrici aziendali
Come funzionano le card RFID per flotte nella gestione operativa dei veicoli elettrici aziendali: tracciamento dei kWh per veicolo, integrazione OCPP, reportistica specifica del programma, gestione delle chiavi multi-deposito e cosa specificare quando si emettono card ai conducenti.

Card RFID per la ricarica EV: come funzionano e come sceglierle
Cosa fa realmente una card RFID per la ricarica EV, come si autentica sulle stazioni OCPP e sugli hub di roaming, quali tecnologie chip vengono usate e come scegliere la card giusta per flotte, reti o uso personale.