2. STANDARD ISO 15693.
2.1 INTRODUZIONE.
Nel capitolo precedente sono state descritte molte delle numerose applicazioni dei sistemi di identificazione a radio frequenza, in cui rientrano sistemi con caratteristiche molto diverse fra loro.
L’International Organization for Standardization (ISO) e l’International Electrotechnical Commission (IEC) hanno collaborato alla stesura e allo sviluppo degli standard internazionali.
In questo capitolo è descritto lo standard ISO 15693 cioè lo standard che è stato preso come riferimento per regolamentare la progettazione del tag.
In particolare nella prima parte dello standard sono descritte le caratteristiche elettriche e il campo a radio frequenza che permette la comunicazione bidirezionale fra tag e lettore, mentre nella seconda parte dello standard sono descritte le procedure di anticollisione ed il protocollo di trasmissione.
La progettazione del tag, nel rispetto dello standard, non preclude la possibilità di utilizzo di altre tecnologie.
2.2
DIALOGO.
Si consideri un sistema RFID, costituito quindi da un lettore e da uno o più tag che si scambiano delle informazioni.
Il dialogo fra il lettore e uno o più tag presenti nello stesso momento è condotto attraverso operazioni specifiche.
I tag presenti nella zona di interrogazione del lettore, a causa del campo a radio frequenza emesso dal lettore, si attivano, rimanendo però in silenzio in attesa di una nuova trasmissione del lettore.
Solo quando il lettore trasmette la richiesta di un comando al tag, il tag, eseguito il comando, trasmette al lettore la risposta al comando.
Tutte le operazioni considerate avvengono attraverso campi elettromagnetici a radio frequenza, i segnali di comunicazione devono rispettare quanto specificato nello standard.
2.3 TRASFERIMENTO DI ENERGIA.
Il trasferimento di energia dal lettore al tag avviene tramite il campo a radio frequenza generato dal lettore stesso sfruttando l’accoppiamento induttivo fra lettore e tag, entrambi sono infatti dotati di antenna. Per permettere la comunicazione bidirezionale fra lettore e tag il campo a radio frequenze deve essere però modulato.
Scendendo più in dettaglio il lettore genera un campo a radio frequenza la cui frequenza
c
f è pari a 13,56MHz ± 7KHz.
Il lettore opera sempre mantenendo il valore del campo, per ogni possibile posizione occupata dal tag, all’interno di un ben determinato intervallo di valori: il valore minimo è di 150mA/m rms mentre il valore massimo del campo è di 5A/m rms.
2.4 COMUNICAZIONE DAL LETTORE AL TAG.
La scelta dei parametri da utilizzare è definita in base alle applicazioni.
Si può scegliere qualsiasi tipo di modulazione, indipendentemente dalla scelta della codifica dei dati.
2.4.1 Modulazione.
Lettore e tag comunicano fra loro utilizzando i principi della modulazione ASK.
Nel caso specifico si possono utilizzare due indici di modulazione, 10% o 100%; il lettore decide quale indice di modulazione usare, mentre il tag deve riconoscere quale indice di modulazione è stato usato.
La scelta del lettore fra i due tipi di modulazione determina le immagini seguenti.
Figura 2-2: Forma d’onda con modulazione al 10%
Il tag può operare per ogni valore dell’indice di modulazione incluso fra il 10% e il 30%.
Si può notare che nelle due figure compare il tempo 9,44µs, che può espresso in funzione del numero di periodi della portante, cioè 9,44µs=128/ fc.
2.4.2 Codifica dei dati.
I dati sono codificati utilizzando una modulazione PPM (Pulse Position Modulation). Il tag supporta due tipi di codifica dei dati; in particolare il lettore sceglie il tipo di codifica con cui inviare i dati, mentre il tag decifra il tipo di codifica in base allo Start Of Frame (SOF) inviato dal lettore.
2.4.2.1 Codifica: 1 di 256.
Il valore di un singolo byte, nel caso di codifica 1 di 256, è rappresentato dalla posizione di una pausa. La posizione della pausa, che si trova in uno dei 256 periodi di 18,88µs (pari a 256/ fc), determina quindi il valore del byte.
Nella codifica 1 di 256 la trasmissione di un byte ha una durata di 4,833ms (pari a 65536/ fc), cioè 256 periodi di 18,88µs.
Ne risulta pertanto un data rate di 1,65Kbit/s (pari a fc/8192).
Nella figura è rappresentata la tecnica di modulazione PPM (Pulse Position Modulation) appena descritta, quando il lettore manda al tag il dato E1 esadecimale (225 decimale).
Figura 2-3: Codifica 1 di 256
Si può notare inoltre che la pausa è posizionata nella seconda metà del periodo, che ne determina il valore.
2.4.2.2 Codifica: 1 di 4.
La modulazione PPM nel caso della codifica 1 di 4 determina due bit alla volta. Per la trasmissione di un byte si devono quindi trasmettere quattro coppie di bit.
La prima coppia trasmessa è la coppia meno significativa.
Nella figura è rappresentata la tecnica di modulazione PPM nel caso di codifica 1 di 4.
Figura 2-5: Codifica 1 di 4
A differenza del precedente tipo di codifica, per trasmettere un byte si devono trasmettere quattro coppie di bit. Quindi nella codifica 1 di 4 la trasmissione di un byte ha una durata di 302,08µs (pari a 4096/ fc).
Nella figura seguente è rappresentata la tecnica di modulazione appena descritta, quando il lettore manda al tag il dato E1 esadecimale (11100001 binario, 225 decimale).
Figura 2-6: Esempio della codifica 1 di 4
In entrambi i tipi di codifica dei dati la pausa ha una durata di 9,44µs (pari a 128/fc).
2.4.3 Frame inviati dal lettore al tag.
L’invio di un frame dal lettore al tag deve permettere una sincronizzazione fra i due dispositivi, indipendentemente dal protocollo considerato.
Ogni frame è delimitato da uno start of frame (SOF) e da un end of frame (EOF), implementati utilizzando una violazione del protocollo.
Il tag, dopo aver inviato un frame al lettore, è pronto a ricevere un nuovo frame dal lettore solo dopo 300µs.
Il tag è pronto a ricevere un frame dal lettore dopo 1ms dall’attivazione del campo elettromagnetico da parte del lettore.
2.4.3.1 SOF per i due tipi di codifica.
Le sequenze di start of frame (SOF) rappresentate nelle figure seguenti differisce per i due tipi di codifica.
Figura 2-7: Sequenza di SOF nel caso di codifica 1 di 256
Figura 2-8: Sequenza di SOF nel caso di codifica 1 di 4
In entrambi i casi però la sequenza è implementata tramite una violazione del protocollo.
2.4.3.2 EOF per i due tipi di codifica.
La sequenza di end of frame (EOF), rappresentata nella figura seguente, è la stessa per i due tipi di codifica.
Figura 2-9: EOF per i due tipi di codifica
La sequenza di EOF, come le sequenze di SOF, è implementata tramite una violazione del protocollo.
128/ fc . Il tempo 9,44µs=128/ fc può essere quindi considerato come un tempo di riferimento.
Ogni volta che il tag riceve un frame deve fare una operazione di campionamento per riconoscere il segnale.
2.5 COMUNICAZIONE DAL TAG AL LETTORE.
La scelta dei parametri da utilizzare è definita in base alle applicazioni.
2.5.1 Load Modulation.
Il tag deve essere in grado di comunicare con il lettore sfruttando un’area di accoppiamento elettromagnetico in modo che la portante risulti caricata per generare una sottoportante con frequenza fS , descritta in dettaglio nel paragrafo successivo. La sottoportante è generata nel tag tramite un cambiamento di carico.
L’ampiezza della modulazione di carico deve essere di almeno 10mV, quando è misurata come descritto nella sezione dei metodi di test, come definito nell’International Standard ISO/IEC 10373.
2.5.2 Sottoportante.
Il tag comunica con il lettore utilizzando una o due sottoportanti, come richiesto dal lettore selezionando il primo bit presente nel protocollo di trasmissione, come vedremo in dettaglio in seguito.
Nel caso in cui la comunicazione prevede una singola sottoportante, la frequenza fS1
Nel caso in cui la comunicazione prevede due sottoportanti, la frequenza fS1 della sottoportante deve essere fc/32 (423,75KHz), e la frequenza fS2 della sottoportante deve essere fc/28 (484,28KHz).
Nel caso in cui sono presenti le due sottoportanti, deve essere continuamente mantenuta la relazione di fase fra le due sottoportanti stesse.
2.5.3 Data Rate.
Nella comunicazione si può utilizzare un data rate alto o basso. Il data rate è selezionato direttamente dal lettore tramite il secondo bit del protocollo di comunicazione, come vedremo in dettaglio in seguito. Il tag deve quindi supportare i data rate secondo quanto descrittonella tabella che segue.
Data Rate Singola sottoportante Doppia sottoportante
Basso 6,62Kbits/s( fc/2048) 6,67Kbits/s( fc/2032)
Alto 26,48Kbits/s( fc/512) 26,69Kbits/s( fc/508)
Tabella 1: Data Rate
2.5.4 Rappresentazione e codifica dei bit.
Tutte le temporizzazioni che seguiranno faranno riferimento alla comunicazione dal tag al lettore che utilizza il data rate alto. Nel caso in cui si utilizza il data rate basso, con le stesse frequenze delle sottoportanti, il numero di impulsi deve essere moltiplicato per quattro, quindi tutti i tempi saranno incrementati dello stesso fattore.
2.5.4.1 Codifica dei bit quando si usa un’unica sottoportante.
Uno 0 logico è rappresentato da 8 impulsi alla frequenza di fc/32 (~423,75KHz)
seguito da un segnale non modulato per un tempo pari a 256/ fc (~18,88µs), come di seguito mostrato.
Figura 2-10: Rappresentazione di uno 0 logico con un’unica sottoportante
Un 1 logico è rappresentato da un segnale non modulato per un tempo pari a 256/ fc
(~18,88µs) seguito da 8 impulsi alla frequenza di fc/32 (~423,75KHz), come di seguito mostrato.
Figura 2-11: Rappresentazione di un 1 logico con un’unica sottoportante
2.5.4.2 Codifica dei bit quando si usano due sottoportanti.
Uno 0 logico è rappresentato da 8 impulsi alla frequenza di fc/32 (~423,75KHz) seguito da 9 impulsi alla frequenza di fc/28 (~484,28KHz), come di seguito mostrato.
Figura 2-12: Rappresentazione di uno 0 logico con due sottoportanti
Un 1 logico è rappresentato da 9 impulsi alla frequenza di fc/28 (~484,28KHz) seguito da 8 impulsi alla frequenza di fc/32 (~423,75KHz), come di seguito mostrato.
Figura 2-13: Rappresentazione di un 1 logico con due sottoportanti
2.5.5 Frame inviati dal tag al lettore.
I frame inviati dal tag al lettore sono stati scelti in modo da facilitare la sincronizzazione fra i due dispositivi e sono indipendenti dal protocollo considerato.
Ogni frame è delimitato da uno start of frame (SOF) e da un end of frame (EOF), implementati utilizzando una violazione del protocollo.
Tutte le temporizzazioni mostrate in seguito faranno riferimento alla comunicazione dal tag al lettore che utilizza il data rate alto. Nel caso in cui si utilizza il data rate basso, utilizzando le stesse frequenze delle sottoportanti, il numero di impulsi deve essere moltiplicato per quattro, quindi tutti i tempi saranno incrementati dello stesso fattore.
Il lettore deve essere pronto a ricevere un frame proveniente dal tag entro 300µs a partire dall’ultimo frame inviato al tag.
2.5.5.1 SOF quando si usa un’unica sottoportante.
Nel caso in cui si utilizza un’unica sottoportante la sequenza di start of frame (SOF) è composta da tre parti: un segnale non modulato per un tempo pari a 768/ fc (~56,64µs),
seguito da 24 impulsi alla frequenza di fc/32 (~423,75KHz), seguito infine da un 1 logico cioè un segnale non modulato per un tempo pari a 256/ fc (~18,88µs) ed 8 impulsi alla frequenza di fc/32 (~423,75KHz), come mostrato nella figura successiva.
Figura 2-14: SOF quando si usa un’unica sottoportante
2.5.5.2 SOF quando si usano due sottoportanti.
Nel caso in cui si utilizzano due sottoportanti la sequenza di start of frame (SOF) è composta da tre parti: 27 impulsi alla frequenza di fc/28 (~484,28KHz), seguito da 24 impulsi alla frequenza di fc/32 (~423,75KHz), seguito infine da un 1 logico cioè un segnale di 9 impulsi alla frequenza di fc/28 (~484,28KHz) ed 8 impulsi alla frequenza di fc/32
Figura 2-15: SOF quando si usano due sottoportanti
2.5.5.3 EOF quando si usa un’unica sottoportante.
Nel caso in cui si utilizza un’unica sottoportante la sequenza di end of frame (EOF) è composta da tre parti: uno 0 logico cioè 8 impulsi alla frequenza di fc/32 (~423,75KHz) ed un segnale non modulato per un tempo pari a 256/ fc (~18,88µs), seguito da 24 impulsi alla frequenza di fc/32 (~423,75KHz), seguito infine da un segnale non modulato per un tempo
pari a 768/ fc (~56,64µs), come di seguito mostrato in figura.
Figura 2-16: EOF quando si usa un’unica sottoportante
2.5.5.4 EOF quando si usano due sottoportanti.
Nel caso in cui si utilizzano due sottoportanti la sequenza di end of frame (EOF) è composta da tre parti: uno 0 logico cioè 8 impulsi alla frequenza di fc/32 (~423,75KHz) seguito da 9 impulsi alla frequenza di fc/28 (~484,28KHz), seguito da 24 impulsi alla
frequenza di fc/32 (~423,75KHz), seguito infine da 27 impulsi alla frequenza di fc/28 (~484,28KHz), come di seguito mostrato in figura.
Figura 2-17: EOF quando si usano due sottoportanti
2.6 PROTOCOLLO DI COMUNICAZIONE.
2.6.1 Definizioni.
Identificatore unico (UID)
Il tag è identificato unicamente tramite l’identificatore unico (UID) su 64 bit. L’identificatore è usato per indirizzare univocamente ogni singolo tag, durante il ciclo di anticollisione e per uno scambio di informazione fra il lettore e il singolo tag selezionato.
Il UID comprende, come schematizzato nella tabella: gli 8 bit più significativi corrispondenti ad ‘E0’, un codice, su 8 bit, della IC manifacturer in accordo con ISO/IEC 7816-6/AM1, ed infine un numero seriale unico, sui 48 bit meno significativi, assegnato dalla IC manifacturer permanentemente.
MSB LSB
64 57 56 49 48 1
‘E0' Codice IC Numero seriale IC
Identificatore della famiglia di applicazioni (AFI)
L’identificatore della famiglia di applicazioni (AFI) rappresenta il tipo di applicazioni individuato dal lettore e serve per selezionare, fra tutti i tag presenti, solo i tag che rispondono ai requisiti richiesti.
Il AFI può essere programmato e chiuso dai rispettivi comandi, una volta chiuso però non può più essere modificato.
Il AFI è codificato su un byte, costituito da due gruppi di quattro bit. Il gruppo più significativo è usato per selezionare una specifica fra tutte le famiglie di applicazioni. Il gruppo meno significativo è usato per selezionare una specifica fra tutte le sotto-famiglie di applicazioni. AFI gruppo più significativo AFI gruppo meno significativo Significato Esempi
‘0’ ‘0’ Tutte le famiglie e sottofamiglie No applicative preselection X '0' Tutte le sottofamiglie della famiglia X Wide applicative preselection X Y Solo la sottofamiglia Y della famiglia X
‘0’ Y Solo la sottofamiglia Y
‘1' ‘0’, Y Trasporto Autobus, linee aeree
'2' ‘0’, Y Finanziario IEP, Banking, Retail
'3' ‘0’, Y Identificazione Controllo accessi
'4' ‘0’, Y Telecomunicazione Telefoni pubblici, GSM
‘5’ ‘0’, Y Medico
'6' ‘0’, Y Multimediale Servizi internet
'7' ‘0’, Y Gaming
'8' ‘0’, Y Immagazzinamento dei dati File
'9' ‘0’, Y Item managment
'A' ‘0’, Y Express parcel
'B' ‘0’, Y Servizi postali
'C' ‘0’, Y Bagagli aerei
'D' ‘0’, Y RFU
'E' ‘0’, Y RFU
‘F’ ‘0’, Y RFU
Tabella 3: Codifica del AFI
Dove X ed Y rappresentano un valore qualsiasi esadecimale incluso fra ‘1’ e ‘F’. Il AFI può essere o meno supportato dal tag.
In seguito alla richiesta da parte del lettore di un comando inventario il tag risponde in base al valore del AFI qualora sia supportato.
Nel caso in cui il tag non supporta il AFI ed è selezionato il flag AFI, il tag non deve rispondere, qualunque sia il valore del AFI presente nella richiesta.
Nel caso in cui il tag supporta il AFI, il tag deve rispondere se il valore del AFI presente nella richiesta ha valore nullo o coincide con il valore del AFI proprio del tag, in accordo con
Figura 2-18: Diagramma ad albero per AFI
Identificatore del formato dei dati immagazzinati (DSFID)
L’identificatore del formato dei dati immagazzinati (DSFID) indica in che modo sono strutturati i dati nella memoria del tag.
Il DSFID può essere programmato e chiuso con i rispettivi comandi, una volta chiuso però non può più essere modificato.
Ricevuta la richiesta di Inventory Si No No Si Risposta Si No Si No Risposta Nessuna Risposta Risposta Nessuna Risposta
AFI supportato dal Tag
AFI di valore 0 AFI Flag 1
Valore dell’AFI = AFI del Tag
Il DSFID è codificato su un byte e permette di conoscere l’organizzazione logica dei dati. Nel caso in cui il tag non supporta il DSFID, il tag risponde con un valore nullo (‘00’).
Cyclic Redundancy Check (CRC)
Il CRC è utilizzato per aggiungere una protezione ulteriore riguardo agli eventuali errori di trasmissione dell’informazione ed è calcolato come da definizione in ISO/IEC 13239.
Il cyclic redundancy check (CRC) è codificato su due byte, il cui valore iniziale contiene tutti i bit pari a 1, quindi ‘FFFF’. I due byte di CRC sono attaccati ad ogni richiesta e ad ogni risposta, con ogni frame, prima del EOF. Il CRC è calcolato su tutti i byte contenuti nel frame, dopo il campo SOF senza includere il campo CRC. Nel caso in cui si include anche il campo CRC si ottiene un residuo fisso e pari a ‘F0B8’. Il polinomio generatore è
1 5 12 16 + + +x x x = ‘8408’.
Una volta ricevuta una richiesta da parte del lettore, il tag deve verificare che il valore del CRC sia corretto, nel caso in cui non è corretto il tag deve scartare il frame e non deve rispondere.
Una volta ricevuta la risposta da parte del tag, anche il lettore dovrebbe verificare che il valore del CRC sia corretto, nel caso in cui non è corretto il lettore non deve considerare l’ultima azione eseguita.
Il CRC è trasmesso a partire dal byte meno significativo, ognuno dei quali è trasmesso a partire dal bit meno significativo.
Organizzazione della memoria del tag
La memoria fisica è organizzata in 256 blocchi (o pagine) di 256 bit. La memoria ha quindi una capacità di 8Kbyte (64Kbit).
I comandi permettono un accesso (in lettura e in scrittura) per blocchi, ciò non costituisce però una restrizione implicita o esplicita ad altri metodi di accesso.
Stato di sicurezza di un blocco
Lo stato di sicurezza di un blocco è codificato su un byte e costituisce un elemento del protocollo. Non costituisce però un’assunzione implicita o esplicita che gli 8 bit siano implementati nella struttura che costituisce la memoria fisica del tag.
In presenza di una richiesta il tag interpreta il bit, mentre lo mette ad uno in caso di risposta seguendo la tabella.
Bit Nome del flag Valore Descrizione
0 Non bloccato.
b1 Lock_flag
1 Bloccato.
b2 to b8 RFU 0
Tabella 4: Stato di sicurezza del blocco
2.6.2 Protocollo.
Il protocollo di trasmissione definisce i meccanismi di scambio delle istruzioni e dei dati fra lettore e tag, in entrambe le direzioni.
Si basa innanzitutto sul concetto che il lettore è il primo a parlare. In questo modo tutti i tag presenti non possono iniziare trasmettere senza avere prima ricevuto e decodificato una istruzione dal lettore.
Il protocollo è basato sullo scambio di una richiesta trasmessa dal lettore al tag ed una risposta trasmessa dai tag presenti al lettore. Ogni richiesta ed ogni risposta sono contenute in un frame, delimitate da SOF e EOF, come già descritto in precedenza.
Ogni frame che costituisce una richiesta contiene, fra SOF e EOF, i campi: flag, codice di un comando, tutti i parametri obbligatori o opzionali che dipendono dal comando stesso, dati e CRC.
Ogni frame che costituisce una risposta contiene, fra SOF e EOF, i campi: flag, tutti i parametri obbligatori o opzionali che dipendono dal comando stesso, dati e CRC.
Il numero di bit trasmessi in un frame, pur essendo diverso per ogni comando, è comunque multiplo di otto, quindi costituito da un numero intero di byte. I byte sono trasmessi a partire dal byte meno significativo, ed ogni byte è trasmesso a partire dal bit meno significativo.
Quando un bit del flag è portato ad 1 indica che il relativo campo è presente, mentre quando è 0 indica che il campo è assente. I bit del flag riservati ad un utilizzo futuro (RFU) hanno normalmente valore nullo.
2.6.3 Modi.
Il termine modo si riferisce al meccanismo specificato nella richiesta a cui il tag deve rispondere.
Nel caso in cui l’address_flag è a 1 (modo indirizzato), la richiesta deve contenere l’identificatore unico (UID). Quando il tag riceve una richiesta con l’address_flag a 1, confronta l’UID presente nella richiesta con l’UID proprio; nel caso in cui coincidono esegue il comando, se possibile, e manda la risposta al lettore, secondo quanto in seguito specificato, nel caso in cui non coincidono rimane invece in silenzio.
Nel caso in cui l’address_flag è a 0 (modo non indirizzato), la richiesta non contiene l’identificatore unico (UID). Ogni tag che riceve la richiesta esegue il comando, se possibile, e manda la risposta al lettore, secondo quanto in seguito specificato.
Nel caso in cui il select_flag è a 1 (modo selezionato) la richiesta non contiene l’UID. Il solo tag nello stato selected che riceve una richiesta con il select_flag a 1 esegue il comando, se possibile, e manda la risposta al lettore, secondo quanto in seguito specificato.
2.6.4 Formato di una richiesta.
Ogni richiesta inviata dal lettore contiene, fra SOF e EOF, i campi: flag, codice di un comando, tutti i parametri obbligatori o opzionali che dipendono dal comando stesso, dati e CRC.
SOF Flags Command code Parameters Data CRC EOF
Figura 2-19: Formato generale di una richiesta
2.6.4.1 Flag presenti nella richiesta.
In una richiesta il campo flag, su 8 bit, specifica le azioni che il tag deve compiere quando i corrispondenti campi sono o meno presenti.
Bit Nome del flag Valore Descrizione
0 Una singola frequenza deve essere usata dal tag. b1 Sub-carrier_flag
1 Due sottoportanti sono usate dal tag. 0 Deve essere usato il data rate basso. b2 Data_rate_flag
1 Deve essere usato il data rate alto. 0 Per I bit da 5 a 8 dei flag vedi la tabella 6. b3 Inventory_flag
1 Per I bit da 5 a 8 dei flag vedi la tabella 7. 0 Non ci sono estensioni del formato del protocollo. b4 Extension_flag Protocol
1 Il protocollo è stato esteso.
Tabella 5: Definizione dei bit da 1 a 4 dei flag della richiesta
Bit Nome del flag Valore Descrizione
0 La richiesta deve essere eseguita da ogni tag in accordo con l’address_flag.
b5 Select_flag 1 La richiesta deve essere eseguita solo dal tag nello stato selected. L’address_flag deve essere 0 e l’UID non deve essere presente nella richiesta.
0 La richiesta non è indirizzata. Il campo UID non è presente. Sarà eseguita da tutti I tag.
b6 Address_flag 1 La richiesta è indirizzata. Il campo UID è presente. Sarà eseguita solo dal tag il cui UID coincide con quello specificato nella richiesta.
0 Il significato è definito nella descrizione dei comandi. È 0 nel caso in cui non è specificato in modo diverso dal comando.
b7 Option_flag
1 Il significato è definito nella descrizione dei comandi.
b8 RFU 0
Tabella 6: Definizione dei bit da 5 a 8 dei flag della richiesta quando l’inventory_flag è 0
Se il select_flag è 1, l’address_flag deve essere 0 e il campo UID non deve essere presente nella richiesta.
Bit Nome del flag Valore Descrizione
0 Il campo AFI non è presente.
b5 AFI_flag
1 Il campo AFI è presente. 0 16 slot.
b6 Nb_slots_flag
1 1 slot.
0 Il significato è definito nella descrizione dei comandi. È 0 nel caso in cui non è specificato in modo diverso dal comando.
b7 Option_flag
1 Il significato è definito nella descrizione dei comandi.
b8 RFU 0
Tabella 7: Definizione dei bit da 5 a 8 dei flag della richiesta quando l’inventory_flag è 1
2.6.5 Formato di una risposta.
La risposta inviata dal tag al lettore contiene, fra SOF e EOF, i campi: flag, uno o più parametri, che dipendono dal comando stesso, dati e CRC.
SOF Flags Parameters Data CRC EOF
Figura 2-20: Formato generale della risposta
2.6.5.1 Flag presenti nella risposta.
In una risposta il campo flag, su 8 bit, indica come la richiesta è stata eseguita dal tag e se i campi sono o meno presenti.
Bit Nome del flag Valore Descrizione
0 Non ci sono errori.
b1 Error_flag
1 Rilevati errori. Il codice dell’errore è nel relativo campo.
b2 RFU 0
b3 RFU 0
0 Non ci sono estensioni nel formato del protocollo. b4 Extension_flag
1 Il formato del protocollo è stato esteso.
b5 RFU 0
b6 RFU 0
b7 RFU 0
b8 RFU 0
Tabella 8: Definizione dei bit da 1 a 8 dei flag della risposta
2.6.5.2 Codice dell’errore nella risposta.
Se l’error_flag è messo ad 1 dal tag nella risposta, è presente il campo codice dell’errore e provvede ad informare sull’errore che si è verificato.
Nella tabella è specificato per ogni codice di errore il relativo significato
Codice dell’errore Significato
'01' Il commando non è supportato, cioè il codice della richiesta non è stato riconosciuto. '02' Il commando non è stato riconosciuto, ad esempio un errore nel formato.
'03' L’opzione del commando non è supportata.
'0F' Errore di cui non si hanno informazioni o non è supportato il codice di errore specifico. '10' Il blocco specifico non è disponibile (non esiste).
'11' Il blocco specificato è chiuso e non può essere chiuso di nuovo. '12' Il blocco specificato è chiuso e il contenuto non può essere cambiato. '13' Il blocco specificato non è stato programmato con successo.
'14' Il blocco specificato non è stato chiuso con successo. 'A0' – 'DF' Codici di errore dei comandi custom.
Tutti gli altri RFU
Tabella 9: Definizione dei codici di errore nella risposta
Se il tag non supporta la lista dei codici di errore presenti nella tabella 9, la risposta in presenza di un errore deve fornire il codice di errore ‘0F’ (errore sconosciuto).
2.6.6 Gli stati del tag.
Il tag può trovarsi in uno dei quattro stati: power-off, ready, quiet e selected.
Il tag deve necessariamente supportare gli stati power-off, ready e quiet, mentre lo stato selected può essere o meno supportato.
Lo stato power-off
Il tag, inizialmente nello stato power-off, vi permane finché non verrà attivato dal lettore.
Lo stato ready
Il tag si porta nello stato ready quando è attivato dal lettore. Il tag deve eseguire ogni richiesta in cui il select_flag è 0.
Lo stato quiet
Quando si trova nello stato quiet, il tag deve eseguire ogni richiesta in cui l’inventory_flag è 0 e l’address_flag è 1.
Lo stato selected
Il solo tag nello stato selected deve eseguire ogni richiesta in cui il select_flag è 1. Si parte dal presupposto che un unico tag alla volta può trovarsi nello stato selected.
La figura mostra le sole transizioni valide fra i vari stati, in tutti gli altri casi il tag rimane nello stato in cui si trovava. Anche nel caso in cui il tag non può eseguire una richiesta da parte del lettore, ad esempio quando si verifica un errore di trasmissione del CRC, il tag rimane nello stato in cui si trovava.
Figura 2-21: Diagramma di transizione degli stati del tag
2.6.7 Anticollisioni.
Lo scopo della sequenza di anticollisione è di realizzare l’inventario dei tag presenti nella zona di interrogazione dell’unico lettore, sfruttando l’identificatore unico (UID) descritto nel paragrafo 2.6.9.1.
Il lettore gestisce la comunicazione con uno o più lettori presenti. La comunicazione dunque inizia con la richiesta, da parte del lettore, di un comando inventory.
Il tag può inviare una risposta oppure può non rispondere, attenendosi però a quanto descritto in seguito.
2.6.7.1 Parametri ed esecuzione della richiesta da parte del tag.
Come si può vedere nella figura successiva, quando il lettore fa la richiesta di un comando inventory, invia in successione: il flag, in cui seleziona il bit Nb_slot_flag, il comando, la lunghezza della maschera ed il valore della maschera stessa.
Nella richiesta deve essere inoltre presente il campo AFI, qualora l’afi_flag ha un valore pari a 1.
SOF Flag Comando Lunghezza della maschera
Valore della
maschera CRC16 EOF
8 bit 8 bit 8 bit Da 0 a 8 byte 16 bit
Figura 2-22: Formato della richiesta inventory
Il valore della maschera è contenuto in un numero intero di byte, la lunghezza della maschera indica il numero di bit significativi che costituiscono il valore della maschera, il cui bit meno significativo deve essere trasmesso per primo.
La lunghezza della maschera non è un multiplo di 8 bit, quindi il valore della maschera deve essere completato con un certo numero di 0 nei bit più significativi in modo da rendere il contenuto pari ad un numero intero di byte.
Nella figura che segue è riportato un esempio, in cui il valore della maschera ha una lunghezza pari a 12 bit. Per ottenere il valore della maschera su un numero intero di byte, in questo caso 2 byte, la maschera stessa deve essere completata con quattro bit pari a 0.
MSB LSB
0000 0100 1100 1111 Pad Valore della maschera
Figura 2-23: Esempio del completamento del valore della maschera
Una volta ricevuta una richiesta valida del comando inventory, il tag deve eseguire il comando.
Fra i parametri presenti nella richiesta, è importante il bit del flag relativo al Nb_slot_flag, descritto nella tabella 7.
Nel caso in cui il bit Nb_slot_flag vale 1 (1 slot), il tag deve confrontare direttamente il valore della maschera, senza i bit utilizzati per il completamento, con i relativi bit dell’identificatore unico (UID) proprio del tag. Qualora i due valori coincidono il tag invia la risposta al lettore.
Nel caso in cui il bit Nb_slot_flag vale 0 (16 slot), il tag deve confrontare con i relativi bit dell’UID proprio il valore della maschera, senza i bit utilizzati per il completamento, concatenato con i quattro bit più significativi, il cui valore è pari al numero dello slot. Qualora i due valori coincidono il tag invia la risposta al lettore.
Il numero dello slot è il valore del contatore dello slot. Una volta ricevuta una richiesta del comando inventory il tag azzera il contatore dello slot e ne incrementa il valore ad ogni successiva sequenza di EOF ricevuta dal lettore.
Il primo slot inizia subito dopo la ricezione dell’end of frame della richiesta. Finché non rileva la risposta da parte di un tag, il lettore invia una nuova sequenza di EOF. Se invece il lettore riceve la risposta di uno o più tag, deve aspettare la completa ricezione dei frame, prima di mandare una nuova sequenza di EOF.
Nella figura che segue è descritto in maniera dettagliata il processo di comparazione fra il valore della maschera e l’UID proprio del tag, tenendo conto del numero dello slot.
Figura 2-24: Principio di comparazione fra la maschera, l’UID e il numero di slot
2.6.7.2 Sequenza di anticollisione.
Nella figura sono rappresentati i possibili casi che si possono verificare durante la sequenza di anticollisione quando il bit del flag Nb_slot_flag vale 0 (16 slot).
Vediamo cosa accade passo dopo passo, si considera il caso 16 slot.
Il lettore fa il primo passo ed invia una richiesta di inventory, che termina con la sequenza di EOF.
Il tag 1 trasmette la risposta quando il numero di slot è 0. Essendo l’unico tag a rispondere non si verificano quindi collisioni, il lettore dunque riceve e registra l’UID del tag.
Il lettore invia una nuova sequenza di EOF, ciò significa che si passa cosi allo slot successivo.
Quando il numero di slot è pari ad 1 sia il tag 2 che il tag 3 trasmettono le loro risposte. Essendoci due risposte si genera quindi una collisione, il lettore quindi rileva e ricorda la collisione.
Il lettore invia una nuova sequenza di EOF, passando cosi allo slot successivo.
Quando il numero di slot è pari a 2 nessun tag risponde, quindi il lettore passa allo slot successivo inviando una nuova sequenza di EOF.
Quando il numero di slot è pari a 3 si verifica una nuova collisione causata dalle risposte dei tag 4 e 5.
Il lettore decide a questo punto di inviare una richiesta di un comando di lettura di un blocco al tag 1, da cui ha ricevuto il valore corretto dell’UID.
Tutti i tag, avendo rilevato la sequenza di start of frame escono dalla sequenza di anticollisione. La richiesta è indirizzata al solo tag 1, che è l’unico a trasmettere la risposta.
Tutti i tag sono pronti a ricevere una nuova richiesta. Nel caso in cui il nuovo comando è di nuovo il comando inventory la sequenza di anticollisione ricomincia da capo azzerando quindi il numero di slot.
La decisione di interrompere la sequenza di anticollisione spetta comunque al lettore, che potrebbe continuare la sequenza di anticollisione finché il numero di slot diventa 15, per poi inviare la richiesta al tag 1.
Slot 0
Lettore SOF Richiesta inventory EOF EOF
Tag
Risposta 1
Timing t1 t2 t1
Tempi
Continua…
Slot 1 Slot 2 Slot 3
Lettore EOF EOF
Tag Risposta 2 Risposta 4
Risposta 3 Risposta 5
Timing t2 t3 t1
Commenti Collisione No risposta Collisione
Tempi
Continua…
Lettore SOF Richiesta al Tag 1 EOF
Tag Risposta al lettore
dal Tag 1
Timing t2 t1
Commenti
Tempi
Figura 2-25: Descrizione di una possibile sequenza di anticollisione
2.6.8 Definizione dei tempi.
Dopo la ricezione dell’EOF, il tag deve aspettare un tempo pari a 128/ fC (9,44µs) + t1 prima di iniziare la trasmissione della risposta alla richiesta da parte del lettore oppure passare al nuovo slot, nel caso di una richiesta di inventory.
La sincronizzazione con l’impulso di EOF è necessaria per assicurare la sincronizzazione delle risposte del tag.
Il tempo t2 è il tempo usato dal lettore per inviare un EOF, per passare al successivo slot, una volta ricevuta la risposta da parte del tag, a partire dall’EOF ricevuto dal tag.
Il tempo t3 è il tempo usato dal lettore per inviare un EOF, per passare al successivo slot, quando non riceve risposta dai tag presenti.
Minimo Nominale Massimo
t1 4192/ fC (309,2µs) 4224/ fC (311,5µs) 4256/ fC (313,9µs)
t2 4192/ fC (309,2µs) - -
t3 t1 massimo +tsof - -
Tabella 10: Valori dei tempi
2.6.9 Comandi.
I comandi si dividono in quattro gruppi:
Obbligatori
Sono codificati da ‘01’ a ‘1F’, devono essere supportati da tutti i tag.
Opzionali
Sono codificati da ‘20’ a ‘9F’, possono essere o meno supportati dai tag. Nel caso in cui il tag supporta i comandi opzionali il formato di richiesta e risposta devono rispettare le definizioni che vedremo in seguito.
Nel caso in cui il tag non supporta i comandi opzionali e o l’address_flag o il select_flag sono 1, il tag può rimanere in silenzio o mandare il codice di errore (‘comando non supportato’), se sia l’address_flag che il select_flag sono 0, il tag deve rimanere in silenzio.
Custom
I comandi custom sono codificati da ‘A0’ a ‘DF’. Questi comandi sono usati per funzioni specifiche. Le funzioni dei flag (inclusi i bit riservati) non possono essere modificate, a parte il custom_flag; possono essere modificati invece i campi parametri e dati.
Nel caso in cui il tag non supporta i comandi custom, il tag può rimanere in silenzio o mandare il codice di errore (‘comando non supportato’).
Proprietary
I comandi sono codificati da ‘E0’ a ‘FF’. Questi comandi sono usati per test, programmazione di sistemi di informazione, ecc.. I formati di questo tipo di comandi però non sono specificati.
2.6.10 Codici dei comandi.
Codice del comando Tipo Funzione
'01' Obbligatorio Inventory
'02' Obbligatorio Stay quiet
'03' – '1F' Obbligatorio RFU
'20' Opzionale Read single block
'21' Opzionale Write single block
'22' Opzionale Lock block
'23' Opzionale Read multiple blocks
'24' Opzionale Write multiple blocks
'25' Opzionale Select
'26' Opzionale Reset to ready
'27' Opzionale Write AFI
'28' Opzionale Lock AFI
'29' Opzionale Write DSFID
'2A' Opzionale Lock DSFID
'2B' Opzionale Get system information
'2C' Opzionale Get multiple block security status
'2D' – '9F' Opzionale RFU
'A0' – 'DF' Custom IC Mfg dependent
'E0' – 'FF' Proprietary IC Mfg dependent
2.6.11 Comandi obbligatori.
2.6.11.1 Inventory.
Il codice del comando inventory è ‘01’.
Quando il tag riceve la richiesta di inventory, il tag deve eseguire la sequenza di anticollisione.
La richiesta del lettore contiene: il flag, il codice del comando inventory, l’AFI se l’afi_flag è 1, la lunghezza della maschera e il valore della maschera, il CRC.
L’inventory_flag deve essere sempre 1 ed i bit del flag, da 5 a 8 hanno il significato descritto nella tabella 5.
SOF Flag Inventory AFI (opzionale) Lunghezza
della maschera Valore della maschera CRC16 EOF
8 bit 8 bit 8 bit 8 bit 0 – 64 bit 16 bit
Figura 2-26: Formato della richiesta del comando inventory
La risposta del tag deve contenere il DSFID e l’identificatore unico (UID).
SOF Flag DSFID UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
Figura 2-27: Formato della risposta al comando inventory
2.6.11.2 Stay quiet.
Il codice del comando stay quiet è ‘02’.
Quando il tag riceve la richiesta di stay quiet, il tag entra nello stato quiet e non deve inviare la risposta al lettore. Non è prevista infatti una risposta al comando stay quiet.
Quando si trova nello stato quiet, il tag esegue le sole richieste indirizzate, cioè le richieste in cui l’address_flag è 1, e non esegue il comando inventory, quindi l’inventory_flag deve essere 0.
Il tag esce dallo stato quiet nel caso di reset del dispositivo, in tal caso il tag passa nello stato di power-off, nel caso in cui riceve un comando reset to ready, in tal caso il tag passa nello stato di ready, nel caso in cui riceve una richiesta di select il tag va nello stato selected, se è supportato dal dispositivo, o segnala un errore, se il comando non è supportato dal dispositivo.
Il comando stay quiet deve essere eseguito in modalità indirizzata, cioè con l’address_flag 1 e il select_flag 0.
La richiesta del lettore del comando stay quiet deve contenere necessariamente l’UID.
SOF Flag quiet Stay UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
Figura 2-28: Formato della richiesta del comando stay quiet
2.6.12 Comandi opzionali.
2.6.12.1 Read single block.
Il codice del comando read single block è ‘20’.
Quando riceve la richiesta di read single block, il tag deve leggere il blocco richiesto e inviare al lettore la risposta contenente i valori letti.
Nel caso in cui nella richiesta l’option_flag è 1, il tag deve inviare lo stato di sicurezza del blocco, seguito dai valori letti nel blocco richiesto; se invece l’option_flag è 0 il tag deve inviare al lettore i soli valori letti nel blocco richiesto.
La richiesta del lettore del comando read single block, può contenere o meno l’UID, ma deve contenere necessariamente il numero del blocco da leggere.
SOF Flag single Read
block UID
Numero
del blocco CRC16 EOF
8 bit 8 bit 64 bit 8 bit 16 bit
Figura 2-29: Formato della richiesta del comando read single block
La risposta del tag al comando read single block nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errrore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-30: Formato della risposta al comando read single block quando l’error_flag è 1
La risposta del tag al comando read single block nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene lo stato di sicurezza del blocco, se l’option_flag è 1, e i valori del blocco di dati letto.
SOF Flag sicurezza Stato di
del blocco Dati CRC16 EOF
8 bit 8 bit Lunghezza
del blocco 16 bit
Figura 2-31: Formato della risposta al comando read single block quando l’error_flag è 0
2.6.12.2 Write single block.
Il codice del comando write single block è ‘21’.
Quando riceve la richiesta di write single block, il tag deve scrivere nel blocco richiesto con i dati contenuti nella richiesta e riportare il successo dell’operazione nella risposta.
Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
Se l’option_flag è 1, il tag deve aspettare di ricevere l’EOF modulato al 100% del lettore e, solo dopo averlo ricevuto, deve mandare la risposta.
La richiesta del lettore del comando write single block, può contenere o meno l’UID, ma deve contenere necessariamente il numero del blocco e i dati da scrivere.
SOF Flag single Write
block UID
Numero
del blocco Dati CRC16 EOF
8 bit 8 bit 64 bit 8 bit Lunghezza del blocco 16bit
Figura 2-32: Formato della richiesta del comando write single block
La risposta del tag al comando write single block nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-33: Formato della risposta al comando write single block quando l’error_flag è 1
La risposta del tag al comando write single block nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-34: Formato della risposta al comando write single block quando l’error_flag è 0
2.6.12.3 Lock block.
Il codice del comando lock block è ‘22’.
Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
± e termina dopo 20ms.
Se l’option_flag è 1, il tag deve aspettare di ricevere l’EOF modulato al 100% del lettore e, solo dopo averlo ricevuto, deve mandare la risposta.
La richiesta del lettore del comando lock block, può contenere o meno l’UID, ma deve contenere necessariamente il numero del blocco da chiudere.
SOF Flag block Lock UID del blocco Numero CRC16 EOF
8 bit 8 bit 64 bit 8 bit 16 bit
Figura 2-35: Formato della richiesta del comando lock block
La risposta del tag al comando lock block nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag Codice
dell’errore CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-36: Formato della risposta al comando lock block quando l’error_flag è 1
La risposta del tag al comando lock block nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-37: Formato della risposta al comando lock block quando l’error_flag è 0
2.6.12.4 Read multiple block.
Quando riceve la richiesta di read multiple block, il tag deve leggere i blocchi richiesti e inviare al lettore la risposta contenente i valori letti.
Nel caso in cui nella richiesta l’option_flag è 1, il tag deve inviare lo stato di sicurezza del blocco, seguito dai valori letti nel blocco in maniera sequenziale blocco per blocco; se invece l’option_flag è 0 il tag deve inviare al lettore i soli valori letti nei blocchi.
I blocchi sono numerati da ‘00’ a ‘FF’, cioè da 0 a 255. Il numero del blocco presente nella richiesta è uno in meno rispetto al numero di blocchi che il tag deve leggere. Il valore ‘00’ richiede la lettura di un singolo blocco, se nel campo numero di blocchi è presente il valore ‘06’ si devono dunque leggere 7 blocchi.
La richiesta del lettore del comando read multiple block, può contenere o meno l’UID, ma deve contenere necessariamente il numero del primo blocco e il numero di blocchi da leggere.
SOF Flag multiple Read
block UID Numero del primo blocco Numero di blocchi CRC16 EOF
8 bit 8 bit 64 bit 8 bit 8 bit 16 bit
Figura 2-38: Formato della richiesta del comando read multiple block
La risposta del tag al comando read multiple block nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-39: Formato della risposta al comando read multiple block quando l’error_flag è 1
La risposta del tag al comando read multiple block nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene lo stato di sicurezza del blocco, se l’option_flag è 1, e i valori del blocco di dati letto ripetuto per il numero di blocchi richiesto.
SOF Flag sicurezza Stato di
del blocco Data CRC16 EOF
8 bit 8 bit Lunghezza del blocco 16 bit
Ripetuto quanto necessario
Figura 2-40: Formato della risposta al comando read multiple block quando l’error_flag è 0
Nella risposta deve essere rispettato l’ordine, se N è il primo blocco richiesto, N deve essere il primo blocco nella risposta.
Se nella richiesta l’option_flag è 1, la risposta deve contenere nell’ordine: lo stato di sicurezza del primo blocco N e a seguire i valori contenuti nel primo blocco N , lo stato di sicurezza del secondo blocco N +1 e a seguire i valori contenuti nel secondo blocco N +1 e cosi via per il numero di blocchi richiesto.
2.6.12.5 Write multiple block.
Il codice del comando write multiple block è ‘24’.
Quando riceve la richiesta di write multiple block, il tag deve scrivere nei blocchi richiesti con i dati contenuti nella richiesta e riportare il successo dell’operazione nella risposta.
Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
± e termina dopo 20ms.
I blocchi sono numerati da ‘00’ a ‘FF’, cioè da 0 a 255. Il numero del blocco presente nella richiesta è uno in meno rispetto al numero di blocchi che il tag deve scrivere. Il valore ‘00’ richiede la scrittura di un singolo blocco e il campo dati contiene un blocco, se nel campo numero di blocchi è presente il valore ‘06’ si devono dunque scrivere 7 blocchi e il campo dati contiene sette blocchi.
La richiesta del lettore del comando write multiple block, può contenere o meno l’UID, ma deve contenere necessariamente il numero del primo blocco, il numero di blocchi da scrivere e i valori del blocco di dati da scrivere ripetuto per il numero di blocchi richiesto.
SOF Flag multiple Write block UID Numero del primo blocco Numero dei
blocchi Dati CRC16 EOF
8 bit 8 bit 64 bit 8 bit 8 bit Lunghezza del blocco 16 bit Ripetuto quanto
necessario
Figura 2-41: Formato della richiesta del comando write multiple block
La risposta del tag al comando write multiple block nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-42: Formato della risposta al comando write multiple block quando l’error_flag è 1
La risposta del tag al comando write multiple block nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-43: Formato della risposta al comando write multiple block quando l’error_flag è 0
2.6.12.6 Select.
Il codice del comando select è ‘25’.
Quando riceve il comando select, se l’UID presente nella richiesta coincide con l’UID proprio del tag, il tag deve portarsi nello stato selected e inviare la risposta; se gli UID sono differenti il tag deve portarsi nello stato ready e non deve inviare alcuna risposta.
Il comando select deve essere eseguito in modalità indirizzata, cioè con l’address_flag 1 e il select_flag 0.
SOF Flag Select UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
Figura 2-44: Formato della richiesta del comando select
La risposta del tag al comando select nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-45: Formato della risposta al comando select quando l’error_flag è 1
La risposta del tag al comando select nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-46:Formato della risposta al comando select quando l’error_flag è 0
2.6.12.7 Reset to ready.
Il codice del comando reset to ready è ‘26’.
Quando riceve il comando reset to ready, il tag deve portarsi nello stato ready e inviare la risposta.
La richiesta del lettore del comando reset to ready non deve contenere necessariamente l’UID.
SOF Flag Reset to ready UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
La risposta del tag al comando reset to ready nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-48: Formato della risposta al comando reset to ready quando l’error_flag è 1
La risposta del tag al comando reset to ready nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-49:Formato della risposta al comando reset to ready quando l’error_flag è 0
2.6.12.8 Write AFI.
Il codice del comando write AFI è ‘27’.
Quando riceve il comando write AFI, il tag deve memorizzare il valore dell’AFI.
Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
± e termina dopo 20ms.
Se l’option_flag è 1, il tag deve aspettare di ricevere l’EOF del lettore e, solo dopo averlo ricevuto, deve mandare la risposta.
La richiesta del lettore del comando write AFI, può contenere o meno l’UID, ma deve contenere necessariamente il valore dell’AFI da memorizzare.
SOF Flag Write AFI UID AFI CRC16 EOF
8 bit 8 bit 64 bit 8 bit 16 bit
La risposta del tag al comando write AFI nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-51: Formato della risposta al comando write AFI quando l’error_flag è 1
La risposta del tag al comando write AFI nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-52:Formato della risposta al comando write AFI quando l’error_flag è 0
2.6.12.9 Lock AFI.
Il codice del comando lock AFI è ‘28’.
Quando riceve il comando lock AFI, il tag deve bloccare permanentemente il valore dell’AFI precedentemente memorizzato.
Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
± e termina dopo 20ms.
Se l’option_flag è 1, il tag deve aspettare di ricevere l’EOF del lettore e, solo dopo averlo ricevuto, deve mandare la risposta.
La richiesta del lettore del comando lock AFI non deve contenere necessariamente il valore dell’UID.
SOF Flag Lock AFI UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
Figura 2-53: Formato della richiesta del comando lock AFI
La risposta del tag al comando lock AFI nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-54: Formato della risposta al comando lock AFI quando l’error_flag è 1
La risposta del tag al comando lock AFI nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-55:Formato della risposta al comando lock AFI quando l’error_flag è 0
2.6.12.10 Write DSFID.
Il codice del comando write DSFID è ‘29’.
Quando riceve il comando write DSFID, il tag deve memorizzare il valore del DSFID. Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
± e termina dopo 20ms.
Se l’option_flag è 1, il tag deve aspettare di ricevere l’EOF del lettore e, solo dopo averlo ricevuto, deve mandare la risposta.
La richiesta del lettore del comando write DSFID, può contenere o meno l’UID, ma deve contenere necessariamente il valore del DSFID da memorizzare.
SOF Flag DSFID Write UID DSFID CRC16 EOF
8 bit 8 bit 64 bit 8 bit 16 bit
Figura 2-56: Formato della richiesta del comando write DSFID
La risposta del tag al comando write DSFID nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-57: Formato della risposta al comando write DSFID quando l’error_flag è 1
La risposta del tag al comando write DSFID nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-58:Formato della risposta al comando write DSFID quando l’error_flag è 0
2.6.12.11 Lock DSFID.
Il codice del comando lock DSFID è ‘2A’.
Quando riceve il comando lock DSFID, il tag deve bloccare permanentemente il valore del DSFID precedentemente memorizzato.
Se l’option_flag è 0, il tag invia la risposta una volta completata l’operazione di scrittura, che inizia dopo un tempo t1 nominale (vedi la tabella 8) con una tolleranza di
C f
/ 32
± e termina dopo 20ms.
Se l’option_flag è 1, il tag deve aspettare di ricevere l’EOF del lettore e, solo dopo averlo ricevuto, deve mandare la risposta.
La richiesta del lettore del comando lock DSFID non deve contenere necessariamente il valore dell’UID.
SOF Flag DSFID Lock UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
Figura 2-59: Formato della richiesta del comando lock DSFID
La risposta del tag al comando lock DSFID nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-60: Formato della risposta al comando lock DSFID quando l’error_flag è 1
La risposta del tag al comando lock DSFID nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il solo flag.
SOF Flag CRC16 EOF
8 bit 16 bit
Figura 2-61:Formato della risposta al comando lock DSFID quando l’error_flag è 0
2.6.12.12 Get system information.
Il codice del comando get system information è ‘2B’.
Il comando get system information serve al lettore per ottenere i valori di informazione sul sistema.
La richiesta del lettore del comando get system information può contenere o meno il valore dell’UID.
SOF Flag system Get
info UID CRC16 EOF
8 bit 8 bit 64 bit 16 bit
Figura 2-62: Formato della richiesta del comando get system information
La risposta del tag al comando get system information nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-63: Formato della risposta al comando get system information quando l’error_flag è 1
La risposta del tag al comando get system information nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene necessariamente il flag, il flag di informazioni e il valore dell’UID, a seguire i campi DSFID e AFI, se i rispettivi flag valgono 1, e cosi per i successivi campi, se previsti dai rispettivi flag.
SOF Flag Info flag UID DSFID AFI campi Altri CRC16 EOF
8 bit 8 bit 64 bit 8 bit 8 bit sotto Vedi 16 bit
Figura 2-64: Formato della risposta al comando get system information quando l’error_flag è 0
Bit Nome del Flag Valore Descrizione
0 Il DSFID non è supportato. Il campo DSFID non è presente.
b1 DSFID
1 Il DSFID è supportato. Il campo DSFID è presente. 0 L’AFI non è supportato. Il campo AFI non è presente.
b2 AFI
1 L’AFI è supportato. Il campo AFI è presente. 0 L’informazione sulla capacità di memoria del tag non è supportata. Il campo capacità di
memoria non è presente. b3 RF Tag memory size
1 L’informazione sulla capacità di memoria del tag è supportata. Il campo capacità di memoria è presente.
0 L’informazione sull’IC reference non è supportata. Il campo IC reference non è presente.
b4 IC reference
1 L’informazione sull’IC reference è supportata. Il campo IC reference è presente.
b5 RFU 0
b6 RFU 0
b7 RFU 0
b8 RFU 0
Tabella 12: Definizione del flag di informazioni
L’IC reference è su 8 bit e il suo significato è definito dall’IC manifacturer. La capacità di memoria è espressa su 16 bit, come schematizzato.
MSB LSB
16 14 13 9 8 1
RFU Capacità del blocco in byte Numero di blocchi
Tabella 13: Informazioni sulla capacità di memoria
La capacità di memoria, espressa in numeri di byte, è su 5 bit, che serve per specificare fino a 32 byte, cioè 256 bit. Si ricorda che il numero di byte è uno in meno rispetto al numero di byte attuale, cioè il valore ‘00’ indica 1 byte e il valore ‘1F’ indica 32 byte.
Il numero di blocchi è su 8 bit e serve per specificare fino a 256 blocchi. Anche in questo caso il numero di blocchi è uno in meno rispetto al numero di blocchi attuale, cioè il valore ‘00’ indica 1 blocco e il valore ‘FF’ indica 256 blocchi.
I tre bit più significativi sono invece riservati per gli sviluppi futuri (RFU) e devono essere zero.
2.6.12.13 Get multiple block security status.
Il codice del comando get multiple block security status è ‘2C’.
Quando riceve la richiesta di get multiple block security status, il tag deve inviare al lettore la risposta contenente lo stato di sicurezza dei blocchi.
I blocchi sono numerati da ‘00’ a ‘FF’, cioè da 0 a 255. Il numero del blocco presente nella richiesta è uno in meno rispetto al numero di blocchi di cui il lettore vuole conoscere lo stato di sicurezza. Il valore ‘00’ richiede lo stato di sicurezza di un singolo blocco, se nel campo numero di blocchi è presente il valore ‘06’ si richiede dunque lo stato di sicurezza di 7 blocchi.
La richiesta del lettore del comando get multiple block security status, può contenere o meno l’UID, ma deve contenere necessariamente il numero del primo blocco e il numero di blocchi di cui il lettore vuole conoscere lo stato di sicurezza.
SOF Flag Get multiple block security status
UID del primo Numero blocco
Numero di
blocchi CRC16 EOF
8 bit 8 bit 64 bit 8 bit 8 bit 16 bit
Figura 2-65: Formato della richiesta del comando get multiple block security status
La risposta del tag al comando get multiple block security status nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
La risposta del tag al comando get multiple block security status nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il flag e lo stato di sicurezza del blocco ripetuto in numero pari al numero di blocchi.
SOF Flag Block security status CRC16 EOF
8 bit 8 bit 16 bit
Ripetuto quanto necessario
Figura 2-67: Formato della risposta al comando get system information quando l’error_flag è 0
2.6.13 Comandi custom.
Il formato dei comandi custom è descritto in modo generico attribuendo in maniera non ambigua i codici dei comandi custom per ogni tag realizzato.
Il codice del comando custom è infatti la combinazione di un comando custom e di un codice di fabbricazione del tag.
La definizione della richiesta dei parametri dei comandi custom è sotto la responsabilità di colui che realizza il tag.
La richiesta del lettore di un comando custom, deve contenere necessariamente il codice di fabbricazione del tag in accordo alla ISO/IEC 7816-6/AM1.
SOF Flag Custom IC Mfg codice Parametri custom CRC16 EOF
8 bit 8 bit 8 bit Definiti custom 16 bit
Figura 2-68: Formato della richiesta di un comando custom
La risposta del tag ad un comando custom nel caso in cui si sono verificati degli errori, cioè quando l’error_flag è 1, contiene il flag e il codice dell’errore.
SOF Flag dell’errore Codice CRC16 EOF
8 bit 8 bit 16 bit
Figura 2-69: Formato della risposta ad un comando custom quando l’error_flag è 1
La risposta del tag ad un comando custom nel caso in cui non si sono verificati errori, cioè quando l’error_flag è 0, contiene il flag ed i parametri di risposta al comando custom.
SOF Flag Parametri custom di risposta CRC16 EOF
8 bit Definiti custom 16 bit
Figura 2-70: Formato della risposta ad un comando custom quando l’error_flag è 0
2.6.14 Comandi proprietary.
