RFID et mobile apps: iOS vs Android

Récemment, chez Liip, nous avons eu l’opportunité de travailler avec Bobst SA. Cette société, qui vend des machines demandant une authentification, souhaitait optimiser ses processus actuels. Auparavant, les client·e·s devaient utiliser un outil pour scanner la machine et saisir manuellement une référence dans le portail web de Bobst SA. Leur nouveau processus utilise désormais des tags RFID. Notre but était de créer une application mobile capable de scanner ces tags et de se connecter automatiquement au compte de l’utilisateur·rice sur les serveurs de Bobst afin de lui octroyer le certificat correct. L’application permettrait ensuite la reprise du certificat sur la machine.

Technologies

Tout comme pour la plupart des applications que nous créons chez Liip, nous avons choisi de travailler avec des technologies natives pour les deux plateformes. Nous avons créé l’application Android en utilisant Kotlin (Kotlin version 1.4.10, cible Android 11 – API 30) et l’application iOS en utilisant Swift (Swift 5, cible iOS 14).
Nous préférons en général ces technologies aux options multi-plateformes pour diverses raisons, y compris la performance, l’expérience UI pour les utilisateur·rice·s des deux plateformes et la maintenabilité. Dans ce cas, le choix était d’autant plus évident que les capacités NFC font partie des bibliothèques numériques intégrées de ces systèmes. Une application de multi-plateforme aurait dans tous les cas requis des modules de passerelle pour les deux plateformes.

Standards RFID

Le sigle RFID vient de l’abréviation anglaise pour radio frequency identification. Les tags RFID les plus simples fonctionnent même sans apport d’énergie. Les appareils RFID peuvent être implémentés selon différents standards, et notamment selon la norme ISO 15693-3, utilisée par les tags Bobst.
La technologie NFC, ou Near field communication, est une sous-catégorie plus précise des appareils de radio-identification. Les appareils NFC peuvent être à la fois tags et lecteurs, et sont en mesure de communiquer activement ensemble. Presque tous les téléphones mobiles modernes sont munis des capacités NFC. De manière générale, les appareils NFC communiquent entre eux par NDEF (NFC Data Exchange Format). Cependant, lors de la communication selon les normes ISO en RFID, il faut utiliser d’autres formats: les NFC type 2 (= type A) et type 4 (= type B) sont utilisés pour communiquer avec la norme ISO 14443 en RFID.
Dans notre cas, nous utiliserons le NFC type 5 (= type V) pour communiquer avec notre tag ISO 15693.

Support NFC pour Android, état en mai 2021

Support NFC pour iOS, état en mai 2021

Implémentation sur les deux plateformes

Considérant les deux tableaux ci-dessus, nous constatons qu’Android et iOS supportent tous deux les puces RFID de Bobst. Nous avons utilisé le type Android NfcV et le type iOS NFCISO15693Tag.

De plus, les deux systèmes requièrent l’autorisation adéquate pour accéder aux capacités NFC. Les documents Android et iOS abordent ce sujet en détail.

En bref, notre implémentation devait supporter trois opérations :

• Identifier un tag à proximité
• Lire le contenu du tag
• Écrire un nouveau contenu sur le tag

Nous avons utilisé ces opérations de la manière suivante :

1. Identifier et lire : attendre l’identification d’un tag (le système reçoit son identifiant unique), puis utiliser cet identifiant unique pour demander une opération de lecture.
2. Envoyer le résultat de l’opération de lecture au serveur Bobst pour recevoir un certificat (pas d’opération RFID dans ce cas).
3. Identifier et écrire : identifier une nouvelle fois un tag proche et s’assurer que l’identifiant est le même que celui lu au préalable (il s’agit du même tag). Écrire ensuite le certificat.

Étape 1 : identifier un tag

Les deux systèmes offrent une façon simple, mais quelque peu différente, de recevoir l’identification d’un tag proche :

Pour iOS, nous devons demander au système de commencer l’identification de tags RFID. À ce stade, l’utilisateur·rice a une vue modale, et le système attend de trouver un tag. En principe, les lignes suivantes suffisent.

func startScan() {
    guard  NFCTagReaderSession.readingAvailable else {
        delegate?.onScanningNotSupported()
        return
    }
    nfcSession = NFCTagReaderSession(pollingOption: NFCTagReaderSession.PollingOption.iso15693, delegate: self, queue: **nil**)
    nfcSession?.alertMessage = ... // whatever alert message such as "hold the phone near the tag"
    nfcSession?.begin()
}

func stopScan() {
    nfcSession?.invalidate()
}

Pour Android, le système fonctionne grâce au mécanisme d'Intent d'Android. Cela signifie que nous devons enregistrer l’application pour accepter les scan intents du type NFC adéquat. Après exécution, l’application reçoit une notification. Par conséquent, il n’y a pas besoin de cliquer sur un bouton pour démarrer. Même lorsque l’application est fermée, si un tag est proche, l’application s’ouvre et reçoit immédiatement une notification !

Enregistrement de la capacité NFC dans le manifeste, dans l’activité qui reçoit l’information :

<intent-filter>
    <action android:name="android.nfc.action.TECH_DISCOVERED" />
</intent-filter>
<meta-data
    android:name="android.nfc.action.TECH_DISCOVERED"
    android:resource="@xml/filter_nfc"
/>

Ajouter la liste de filtres dans le fichier de ressources que nous avons référencé dans le manifeste, tel que xml/filter_nfc/xml (dans notre cas, nous saisissons simplement NfcV, comme dans le tableau ci-dessus) :

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
    <tech-list>
        <tech>android.nfc.tech.NfcV</tech>
    </tech-list>
</resources>

Notre activité sera notifiée via onNewIntent:

override fun onNewIntent(intent: Intent) {
  super.onNewIntent(intent)

  if (NfcAdapter.ACTION_TECH_DISCOVERED == intent.action) {
    val tag = intent.getParcelableExtra<Tag>(NfcAdapter.EXTRA_TAG)
    viewModel.scanned(tag)  // Or whatever else
  }
}

Les deux plateformes offrent clairement une expérience différente aux utilisateur·rice·s, mais fonctionnent toutes deux de la façon suivante : les précédentes étapes résultent en un objet de tag contenant l’identifiant du tag détecté. Maintenant, nous devons l’utiliser pour lire ou écrire ce dont nous avons besoin.

Étape 2 : lire un tag

Pour iOS, le système contient déjà une implémentation basique de la norme ISO 15693, ce qui nous simplifie les choses.

L’implémentation exacte va dépendre des besoins spécifiques. L’idée de base est de convertir l’identifiant générique du tag en une implémentation ISO correcte intégrée dans la bibliothèque de base NFC :

if case let NFCTag.iso15693(tagType5) = tag {
}

Puis, nous utilisons des fonctions intégrées telles que tag.readMultipleBlocks(). Cette fonction accepte un certain nombre d’arguments, y compris les drapeaux de demande pratiques.

tag.readMultipleBlocks(requestFlags: [.highDataRate], blockRange: NSRange(location: 0, length: NfcService.MAXREADBLOCK)) { data, error in
... // check for error and get data using the variables above
}

À ce stade, l’unique difficulté est de déterminer dans quel ordre les octets ont été organisés. La société Bobst nous a fourni une documentation précise afin de nous permettre de lire leurs tags correctement. Dans notre cas, ils étaient organisés en blocs de quatre devant être inversés individuellement après lecture.

Pour Android, le système ne fournit pas d’implémentation intégrée de la norme ISO, hormis la fonction d’envoi de blocs bruts d’octets. Ces blocs bruts contiennent une demande de commande pour le tag, organisée selon la norme ISO 15693 https://www.iso.org/standard/73602.html

La première étape est très similaire à celle d’iOS : obtenir le type de système correspondant à notre tag.

val nfcVTag = NfcV.get(tag) ?: return

L’étape suivante est plus délicate. Le document de 70 pages décrivant la norme ISO 15693 nous indique, entre autres commandes, que la fonction readMultipleBlocks intégrée dans la version iOS est en réalité déclenchée par l’envoi du code de commande 0x23.

Il nous précise également que pour envoyer une commande, nous devons envoyer les informations suivantes :
— drapeaux
— code de commande
— champs de paramétrage obligatoires et facultatifs, selon la commande

Dans notre cas, nous devons définir les drapeaux à émettre et la commande « Addressed », ce qui signifie que la commande utilise l’identifiant du tag comme un argument et exécute uniquement ce tag spécifique. La documentation indique que ce drapeau équivaut au 6e bit de l’octet du drapeau. Nous allons également activer un drapeau à grand débit (2e bit). L’ensemble total d’octets du drapeau est 00100010, ce qui se traduit par 0x22.

Notre demande Android correspondra donc au tableau d’octets suivant :

val offset = 0 // offset of first block to read
val blocks = 32 // number of blocks to read
val cmd = mutableListOf<Byte>().apply {
  add(0x22.toByte()) // flags: addressed (= UID field present) + high data rate
  add(0x23.toByte()) // command: READ MULTIPLE BLOCKS
  addAll(tag.id.toList()) // tag UID
  add((offset and 0x0ff).toByte()) // first block number. add 0xff to ensure we send two bytes
  add((blocks - 1 and 0x0ff).toByte()) // number of blocks (-1 as 0x00 means one block). add 0xff to ensure we send two bytes
}.toByteArray()

Nous recevons simplement la réponse par la méthode de transceive et contrôlons le premier octet pour nous assurer que cela fonctionne.

nfcVTag.connect()
val responseBytes = nfcVTag.transceive(cmd)
if (responseBytes.first() != 0x00.toByte()) {
  return NfcResponse.Error.Read
}
nfcVTag.close()

Le tableau d’octets de la réponse peut désormais être analysé selon la documentation de Bobst afin de nous permettre d’extraire l’information de tag correcte.

Étape 3 : écrire sur un tag

Pour écrire sur un tag, le processus est presque le même que pour le lire (plus simple pour iOS, plus complexe pour Android).

Pour iOS, nous compilons toutes les informations que nous devrons écrire sur un tableau d’octets. Malheureusement, la fonction d’écriture multiple était désactivée sur les tags de Bobst, raison pour laquelle nous avons dû envoyer les octets individuellement. Nous avons simplement utilisé la fonction de base NFC de transceive en boucle. Là encore, la fonction active tous les drapeaux nécessaires.

tag.writeSingleBlock(requestFlags: [.highDataRate, .address], blockNumber: UInt8(startBlock), dataBlock: dataBlock) { error in
    ... // Simply check for error and react accordingly
}

Pour Android
Comme précédemment, nous devons envoyer la commande d’octet appropriée et utiliser la fonction de transceive. La commande utilise là aussi la valeur 0x22. La documentation de la norme ISO 15693 stipule que la demande writeSingleBlock est émise via 0x21 comme commande d’octet. Nous devons également activer l’identifiant du tag puisque nous effectuons une commande « Addressed ». Nous pouvons ensuite activer les octets identifiants suivis de toutes les données que nous souhaitons écrire.

private fun createCommand(tag: Tag, blockOffset: Int, blockData: List<Byte>) = mutableListOf<Byte>().apply {
  add(0x22.toByte()) // flags: addressed (= UID field present) + high data rate : 00100010
  add(0x21.toByte()) // command: WRITE SINGLE BLOCK (multi read not supported)
  addAll(tag.id.toList()) // tag UID
  add((blockOffset and 0x0ff).toByte()) // first block number. add 0xff to ensure we send two bytes
  addAll(blockData) // The bytes for certificate and reference,
}.toByteArray()

Comme pour iOS, nous aurons besoin d’utiliser cette fonction en boucle en activant le bloc correct en compensation afin d’écrire tous les blocs individuellement.

Conclusion

Tandis que l’expérience utilisateur ne varie que très peu entre Android et iOS, l’implémentation de la lecture et de l’écriture des tags selon la norme ISO 15693 est nettement plus complexe pour la version Android.

Nous constatons souvent ce genre de différence entre les deux plateformes : le framework d’iOS est souvent plus simple d’utilisation pour les développeur·euse·s puisque de nombreuses fonctionnalités sont implémentées par défaut. Le framework d’Android en revanche, en laissant davantage de liberté en termes d’implémentation, nécessite une charge de travail supérieure pour obtenir le même résultat.