Pourquoi un simulateur ?

Nous développons très souvent des applications mobiles qui doivent communiquer avec des appareils électroniques divers et variés en Bluetooth Low Energy.

La plupart du temps, l’appareil en question n’existe pas encore et doit être conçu physiquement (la carte électronique avec tous ses composants) et son logiciel interne (son firmware) devra ensuite être écrit, testé, validé.

Toute cette procédure prend du temps et généralement, pour ne pas trop en perdre, nous commençons le développement de l’application mobile bien avant que la carte électronique soit en mesure d’échanger la moindre information.

C’est un véritable problème et garder « pour la fin » la partie communication BLE n’est pas une bonne idée. En effet, pour une intégration idéale et pour que Madame Michu soit en mesure d’utiliser les yeux fermés l’application (communication incluse) il faut intégrer la dimension BLE dès le début.

Alors chez GUYZMO nous nous sommes développés un outil qui permet de simuler le fonctionnement d’un appareil communiquant en BLE avant même qu’il existe. Cela permet de valider bien en amont les échanges à mettre en place et cela permet aussi de se rendre compte très tôt de toutes les petites choses qui n’avaient pas été correctement prévues. C’est donc un outil très important pour obtenir une application mobile robuste en terme de communication BLE. De plus, cela permet à la partie électronique de se voir valider très tôt des choix cruciaux en matière de communication via le Bluetooth Low Energy.

Windows 10 IoT

Notre simulateur fonctionne sous Windows, il est développé en C# en utilisant la technologie UWP (Universal Windows Plateform). Du coup il fonctionne nativement sur les PC, les tablettes Windows, les téléphones Windows (paix à leur âme) et aussi sur des machines moins classiques (on va voir après quel genre de machines).

Il est important de comprendre que dans une communication BLE entre une app mobile et un appareil électronique, l’application mobile est cliente alors que l’appareil électronique est serveur. Dans le vocabulaire Bluettoth Low Energy, le client est généralement appelé le central alors que le serveur est appelé le périphérique.

Comme notre simulateur émule un périphérique BLE il faut que la machine sur laquelle il va fonctionner soit doté d’une puce Bluetooth capable de prendre ce rôle là. Beaucoup de machines ne peuvent en fait prendre QUE le rôle de client et sont incapables matériellement parlant de devenir un serveur BLE.

Il existe une machine qui est capable de prendre les deux rôles, c’est le Raspberry PI 3. Vous allez me dire que cette machine ne tourne pas sous Windows et donc qu’elle ne peut faire tourner le simulateur. En fait c’est faux, il existe une version Windows IoT qui tourne sur ce type de machines (un Windows 10 pour processeur ARM avec une structure très légère en termes de besoins processeur et mémoire). Comme notre simulateur est développé pour UWP, il fonctionne sans problème sous Windows IoT sur Raspberry PI 3 (elle est pas belle la vie ?).

Le simulateur

Le simulateur doit pouvoir exécuter des instructions très variées. Il doit être en mesure de générer la structure du périphérique BLE à simuler, et aussi effectuer des tâches qui vont le faire réagir comme si c’était le vrai périphérique. Pour cela il faut idéalement pouvoir « programmer » le simulateur. Nous utilisons pour ça un langage « maison » que nous avons affectueusement baptisé « MOGWAI ».

MOGWAI permet de programmer le simulateur et de lui faire faire tout ce qui est nécessaire pour faire croire à un client connecté en BLE qu’il est en train de dialoguer avec le véritable périphérique.

MOGWAI est développé sous la forme d’une bibliothèque .NET Standard. Le moteur d’exécution interprète les instructions et communique avec l’hôte qui l’utilise (ici le simulateur) pour étendre ses fonctions. MOGWAI est très proche au niveau de la syntaxe du Forth et encore plus du RPL (Revers Polish Lisp), le langage utilisé par HP dans ses calculatrices (HP 48 par exemple). Le langage utilise une pile et la notation polonaise inversée, par exemple pour effectuer l’opération 2+2 on notera 2 2 + et le résultat sera placé sur la pile.

MOGWAI étant en .NET Standard, il peut être utilisé sur beaucoup de plateformes (autres que Windows). Il est par exemple possible de l’utiliser dans les projets XAMARIN pour iOS et Android. Nous avons aussi développé une version native iOS (en SWIFT) de MOGWAI. Nous entrerons plus en détails sur le langage MOGWAI dans un prochain billet en vous montrant d’autres outils programmables développés avec lui.

Exemple de simulation d’un périphérique BLE

Nous allons prendre un exemple simple. Nous allons créer un périphérique BLE qui expose le service de gestion de la batterie. Ce service est normalisé, son UUID est 0x180F. D’après la documentation officielle il expose une valeur (en BLE on dit une characteristic) « BatteryLevel » (UUID 0x2A19) qui fournit aux clients le niveau actuel de la batterie en % (la valeur 23 par exemple signifie 23%). Cette valeur peut être lue et aussi notifiée (quand elle change le client est automatiquement prévenu du changement, ce qui évite de faire du pooling et donc de consommer de l’énergie pour rien).

Donc il faut créer le service avec sa characteristic :

[
name: 'BatteryService'
uuid: "0000180F-0000-1000-8000-00805F9B34FB"
characteristics:
(
[name: 'BatteryLevel' uuid: "00002A19-0000-1000-8000-00805F9B34FB" type: "RN" size: 1]
)
]

addService

Ensuite il faut être en mesure de répondre à une demande de lecture. Quand une telle demande arrive (c’est un événement), on crée une valeur aléatoire comprise entre 0 et 100 en réponse :

onEvent 'BatteryLevel_READ' do
«
rand 100 * ->int 1 ->list ->bytes 'BatteryLevel.VALUE' sto
»

Pour être en mesure de tester la notification, il faut ajouter un bouton à l’interface qui permettra de lancer une notification de valeur modifiée. Pour cela on crée un bouton et on répond à son événement click :

'BatteryLevelNotifyButton' "Notify battery level" addButton

onEvent 'BatteryLevelNotifyButton_CLICK' do 
«
rand 100 * ->int 1 ->list ->bytes 'BatteryLevel.VALUE' sto
'BatteryLevel' notify
»

Voilà, il ne reste plus qu’à activer le service dans le périphérique avec l’instruction « StartService » et à s’y connecter depuis un client générique ou depuis l’application que vous êtes en train de développer.

Si on clique sur le bouton « Notify batterie level » une nouvelle valeur est calculée et les clients abonnés en sont automatiquement informés.

Voilà ce que ça donne en utilisant l’application Blue Gecko de Silicon Labs sous iOS (existe aussi pour Android) :

Voici le code complet de cet exemple :

Conclusion

Grâce à notre simulateur, nous sommes en mesure de réaliser des développements bien avant que le matériel en cours de création soit opérationnel. Cet outil nous fait gagner du temps, et nous permet d’effectuer en avance des opérations souvent complexes liées à la communication BLE.

La création de MOGWAI nous permet de « motoriser » des applications, de leur donner la faculté de s’adapter à de très nombreuses situations.

Et pour ne rien vous cacher, développer un langage comme MOGWAI est une tâche très instructive et fort intéressante.

Si notre simulateur de périphérique BLE et/ou MOGWAI vous intéressent, n’hésitez pas à me contacter en laissant un commentaire, nous pourrons échanger sur ces sujets avec plaisir.

Dans un prochain billet je prendrai plus de temps pour vous montrer tout ce que MOGWAI sait faire de base, et comment on peut étendre ses capacités.