Au quotidien nous entendons tous de plus en plus parler de “machine learning”, de “deep learning” ou encore d’intelligence artificielle (alias “IA”). Ces notions sont associées à l’idée d’algorithmes très complexes capables, à partir d’un grand volume de données passées, de détecter des événements ou de prendre des décisions en fonction des données présentes voire d’anticiper les événements ou données futures.

Tout cela implique des puissances de calcul importantes et le stockage de beaucoup de données. C’est pourquoi cela était initialement utilisé uniquement sur des serveurs ultra-puissants.

Mais depuis quelques temps il semblerait qu’il soit possible d’utiliser ces concepts dans de petits objets autonomes limités en puissance de calcul et en capacité de stockage…

C’est ce que nous allons étudier dans cette série d’articles, en présentant tout d’abord plus en détail les limitations de ce type d’objet, en précisant le fonctionnement du machine learning pour finalement voir si il est possible de combiner les deux et quel intérêt cela peut avoir.

C’est cette même démarche que nous avons suivie chez Next4 lors du développement de notre tracker “N402” : nous le prendrons donc comme exemple de “petit objet autonome” tout au long de ces articles.

 

1 – Les limitations des “petits objets autonomes”

1.1 La puissance de calcul et la capacité de stockage

Si l’on devait lister et trier les différents systèmes électroniques et informatiques selon leur puissance de calcul et leur capacité de stockage, l’ordinateur de M. et Mme Tout-le-monde se trouverait au milieu, typiquement avec un processeur 4-coeurs fonctionnant à 3 GHz, un disque dur d’1 To et une mémoire vive (la RAM) de 8 Go.

A l’extrémité haute se trouverait les serveurs : bien trop chers pour les particuliers et même la plupart des entreprises, ils sont le plus souvent proposés à la location par OVH, Amazon ou Google par exemple. Ils embarquent en plus de leur processeur principal (CPU) un co-processeur (GPU) optimisé pour les calculs complexes et pouvant disposer de 100 Go de RAM.

Nous ne parlons même pas ici des “supercalculateurs” que peu d’entre nous auront l’occasion d’utiliser, même dans leur vie professionnelle.

Et à l’opposé on trouverait donc nos petits objets autonomes. Il en existe une multitude avec des fonctionnalités très diverses et donc des puissances de calcul et capacité de stockage bien différentes, mais si nous prenons l’exemple de notre tracker N402 voici ces caractéristiques:

  • microprocesseur double coeur fonctionnant à 64 MHz
  • flash (équivalent du disque dur) de 512 Ko
  • RAM de 256 Ko

Mais pourquoi s’imposer ces limitations? Pourquoi ne pas embarquer l’équivalent d’un PC dans nos objets connectés?

  • pour la taille : même si la miniaturisation des composants électroniques ne semblent plus avoir de limite, la taille d’un processeur de PC, de son disque dur ou encore de ses barrettes de RAM sont souvent trop importantes par rapport à l’encombrement souhaité dans le monde de l’IOT.
  • pour le coût : l’ordinateur de M. et Mme Tout-le-monde coûte plusieurs centaines d’euros, alors que les petits objets autonomes sont généralement vendus moins de 100€.
  • pour l’autonomie : on ne parle pas ici d’un smartphone que vous devez recharger tous les soirs, mais bien d’objets dont l’autonomie est au minimum d’un an. Les processeurs qui consomment assez peu pour tenir cette contrainte doivent “pédaler” lentement.

Au vu de la différence entre un ordinateur lambda et notre tracker N402 (grosso modo un facteur 200 sur la puissance et un facteur 30.000 ou plus sur le stockage), on comprend aisément qu’on ne pourra pas faire tourner les mêmes algorithmes sur les deux machines.

1.2 La nécessité de prédictibilité et de fiabilité du logiciel embarqué

Il y a un 2e facteur encore plus important qui effraie les développeurs de logiciel embarqué quand on leur parle de “machine learning” : la nécessité de prédictibilité du comportement et de fiabilité de l’objet.

En effet lorsqu’un site ou un service web crashe (parce que le serveur est “tombé” par exemple) il ne faut que quelques minutes ou au pire quelques heures pour le remettre en service. Par contre si notre tracker de containers maritimes crashe alors qu’il est sur un container en pleine mer, il faudra plusieurs semaines voire plusieurs mois avant de pouvoir le récupérer pour le remettre en service… et pendant ce temps le service ne sera pas rendu au client qui sera impacté et mécontent.

Il est à noter que cela ne s’applique pas qu’aux “petits objets” : le logiciel embarqué dans votre voiture doit lui aussi être 100% fiable!

Pour garantir cette fiabilité, en dehors bien sûr de toutes les campagnes de tests qui seront effectuées, il est indispensable de maîtriser entièrement le logiciel embarqué et de savoir exactement comment il va se comporter (ce qu’on appelle la prédictibilité) dans tous les cas d’utilisation possibles.

Cela vient en totale contradiction avec certaines idées sur le machine learning ou l’intelligence artificielle qui veulent que certaines décisions soient prises par l’objet lui-même ou que des algorithmes hyper complexes trouvés par un ordinateur (et la plupart du temps incompréhensibles pour un être humain) soient implantés dans l’objet en question.

Comment garantir le comportement du système si on ne comprend pas sa logique de décision ou si elle n’est pas définie à l’avance?

2 – Pour ou contre l’intelligence embarquée ?

2.1 Le précepte de l’intelligence déportée

Comme nous venons de le voir, les développeurs peuvent être frileux à l’idée d’embarquer des algorithmes qu’ils ne maîtrisent pas entièrement dans un objet connecté.

Mais, bien avant qu’on ne parle de machine learning ou d’intelligence artificielle, un précepte faisait déjà l’unanimité : “Il faut au maximum déporter l’intelligence de l’objet vers le serveur avec lequel il communique”.

La raison est simple : plus l’objet sera basique, plus son logiciel sera simple. Et plus son logiciel sera simple, plus il sera fiable et robuste.

A l’inverse, plus vous allez ajouter d’intelligence, plus vous allez ajouter de lignes de code et plus vous allez potentiellement insérer de bugs.

Et, comme expliqué plus haut, il est beaucoup plus facile de corriger un bug côté serveur que sur un objet déployé chez un client.

Donc si, par exemple, des données doivent être analysées, il vaut mieux que l’objet envoie ces données brutes vers un serveur et que ce dernier fasse l’analyse.

2.2 L’avènement de l’Edge computing

Prenant le contre-pied de ce précepte, l’Edge computing propose d’utiliser au maximum les ressources de chaque objet pour améliorer les fonctionnalités qu’ils fournissent.

Cela permet, entre autres :

  • d’améliorer la réactivité du système : si les données sont analysées par l’objet lui-même plutôt que d’être envoyées sur un serveur distant, la réponse du système n’est pas impactée par le temps de transmission de ces données brutes.
  • d’optimiser la quantité de données échangées entre l’objet et le serveur, ce qui limite les coûts de consommation de data et l’énergie nécessaire pour ces transmissions.

Dans l’exemple de notre tracker N402, la détection des événements lors d’une expédition (chocs, ouvertures de porte, grutage sur un bateau, dépassement de seuils de température ou d’humidité, etc…) est basée sur des données de divers capteurs (accéléromètres, pression, température, humidité, etc…). Nous avons décidé d’analyser toutes ces données dans le tracker lui-même, afin qu’il communique avec notre serveur uniquement lorsqu’un événement a réellement eu lieu. Cela permet de limiter grandement la fréquence et la quantité de données échangées (sans aucune perte d’information) et de garantir une autonomie de plusieurs années.

En résumé, nos petits objets autonomes n’auront jamais les mêmes capacités de calcul qu’un serveur, et le bon sens tend à limiter au maximum l’intelligence embarquée dans ces objets. Pour autant, si l’on peut garantir la fiabilité et la robustesse du logiciel embarqué, y intégrer des algorithmes complexes permet d’optimiser le système dans son ensemble, voire même de proposer aux clients des fonctionnalités innovantes.

Dans cette optique, est-il possible d’aller jusqu’à l’implémentation du machine learning dans ces petits objets? C’est ce que nous verrons bientôt dans la suite de cette série d’articles… 

par Julien Brongniart