• 12 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 03/02/2020

Découvrez le fonctionnement d’un objet communicant

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Appréhendez le fonctionnement d’une application qui tourne sur un objet communicant

Bonjour, bienvenue dans ce cours où nous allons découvrir ensemble le fonctionnement d’un objet connecté.

En premier lieu, qu’est-ce qu’un objet connecté ?

Quelques premiers exemples d'objets simples :

  • une sonde de température ;

  • un détecteur de fumée ;

  • un capteur météo.

Cela peut être aussi un objet plus complexe.

Exemple : une caméra de vidéo-surveillance qui envoie des alertes quand un événement se produit dans une région observée.

Pour cela, un objet connecté est donc composé des éléments suivants :

  • un processeur ;

  • une mémoire ;

  • une interface de communication pour transmettre et recevoir des données ou de l’information de contrôle ;

  • des sondes ou des fonctionnalités matérielles pour mesurer un événement ;

  • une application qui va mesurer, analyser, prendre la décision de transmettre l’information, coder l’information puis la transmettre.

C’est donc un système embarqué, un ordinateur réduit, souvent dédié à une application, qui peut être autonome en énergie.

Prenons un exemple de système d'objet connecté et détaillons-en le fonctionnement.

Imaginons que nous ayons un capteur de température dans cette pièce. Et que l’application embarquée envoie une alerte dès que la température dépasse les 30 degrés dans cette pièce.

En permanence, la sonde de notre objet connecté mesure la température.

Une fois la mesure réalisée, elle est stockée dans une mémoire de l’objet puis analysée par l’application :

  • si la température est inférieure à 30 degrés, il ne se passe rien ;

  • si la température est supérieure à 30 degrés, l’application embarquée dans l’objet connecté prépare un message d’alerte, stocke la température mesurée, par exemple 32 degrés, l’heure, l’identité du capteur.

Comme les objets connectés sont souvent autonomes, et que l’interface de communication consomme beaucoup d’énergie, en particulier s’il s’agit d’une interface de transmission radio, alors cette interface de communication est souvent éteinte.

Ainsi, l’application doit demander le réveil de cette interface, donner le message d’alerte préparé précédemment. Le paquet de données est alors transmis vers le serveur ; c’est un message de type PUT, qui signifie que l’on dépose l’information applicative sur le serveur.

Dans la suite du cours, nous verrons donc comment ces messages sont véhiculés – on dira qu’ils sont routés – vers le serveur.

Découvrez une architecture de communication client-serveur

Dans la section précédente, nous avons découvert le fonctionnement applicatif d’un objet connecté. Nous allons maintenant faire nos premiers pas dans l’architecture de communication pour comprendre les échanges de données.

Internet apparaît, plus que jamais, comme le réseau de convergence qui permet :

  • de favoriser l’interopérabilité de plusieurs réseaux de communication, comme les réseaux 4G ou de votre opérateur ADSL ;

  • de supporter des objets connectés hétérogènes tels que votre téléphone, votre télé connectée et votre capteur de température ;

  • grâce à sa flexibilité, de supporter plusieurs types de trafic comme la voix, le web ou... la remontée de données de température.

Bref, c’est un réseau incontournable lorsque l’on veut rendre une information accessible à distance.

Ainsi, si vous voulez transmettre une information issue d’un objet connecté, vous passerez forcément par Internet. Il est donc important de comprendre l’approche retenue dans ce réseau, pour standardiser les dialogues entre machines distantes.

Historiquement, Internet impose une architecture de communication, appelée architecture client-serveur. Notez qu’au cours de la dizaine d’années qui vient de s’écouler, une architecture alternative est apparue : c’est l’architecture pair-à-pair, que vous connaissez peut-être sous le nom de peer-to-peer ou encore de P2P. Comme cette architecture n’est pas encore utilisée pour collecter les données d’objets connectés, nous ne l’aborderons pas.

Une architecture client-serveur, c’est quoi ?

C’est tout d’abord un serveur, accessible à distance grâce à une connexion Internet, via lequel nous pouvons stocker de l’information et interroger l’information qui y est stockée.

  • Le serveur possède donc souvent une base de données, attend des requêtes qui viennent de l’extérieur et y répond.

  • Le client, c’est la machine distante qui veut accéder au serveur, encore une fois pour transmettre ou demander des informations.

Dans une architecture client-serveur, les premiers échanges se font à l’initiative du client, vers le serveur qui est lui, en attente de clients. Bien évidemment, un serveur peut traiter les informations d’un grand nombre de clients.

Les dialogues entre un client et un serveur sont souvent appelés des échanges de bout-en-bout car ils se font entre la source et la destination des données échangées, en étant agnostiques de ce qu’il y a au milieu.

Les échanges sont basés sur la notion de requête et de réponse.

Dans la section suivante, nous allons voir tous les équipements et protocoles qui sont présents entre client et serveur.

Reconnaissez les équipements réseau faisant la connexion entre client et serveur

Après avoir vu le fonctionnement d’un objet connecté et découvert l’architecture client-serveur, il est temps de s’interroger sur les éléments présents dans le réseau, entre notre objet connecté et le serveur distant.

Nous allons donc voyager au cœur d’Internet et aller à la rencontre des différents équipements qui composent le réseau.

Notre capteur, ainsi que le serveur, possèdent deux identifiants :

  • un nom canonique, par exemple capteur.domain.com pour l’objet connecté et serveur.database.com pour le serveur ;

  • un identifiant logique qui correspond à l’adresse IP, l’adresse Internet, comme par exemple, 134.214.202.44 pour l’objet connecté et 88.77.66.55 pour le serveur.

Notez que, bien souvent, l’adresse IP permet une localisation géographique plus ou moins fine.

Parce que les machines connectées à Internet sont souvent manipulées par des humains, il est plus facile, pour nous, de se souvenir du nom canonique que de la série de 4 nombres correspondant à l’adresse IP.

Ainsi, dans l’objet connecté, nous devons configurer l’identité du serveur distant pour permettre l’acheminement des données... mais les protocoles de routage utilisés par Internet ne connaissent que les adresses IP.

Quand le capteur de température veut envoyer des données au serveur, il va créer un paquet IP avec l’adresse IP de la source, le capteur donc,  et l’adresse IP du destinataire, le serveur, ainsi que d’autres informations que nous aborderons plus tard.

Le capteur ne connaissant que le nom canonique du serveur distant va donc interroger l’annuaire DNS indiqué dans le capteur pour connaître l’adresse IP du serveur.

Ainsi, avant d’envoyer une donnée, le capteur, ici, va commencer par envoyer une requête au serveur DNS.

Lorsque la réponse est obtenue, le paquet est complété avec l’adresse IP de destination et prêt à être envoyé. Parfois, les objets connectés sont configurés avec uniquement l’adresse IP du serveur. Dans ce cas, aucune requête DNS n’est nécessaire.

Quand le paquet IP est prêt à être envoyé, il va être acheminé, on dit routé, vers le serveur.

Les machines chargées de router sont les routeurs : ils calculent les routes possibles en fonction de la charge dans le réseau et de paramètres de qualité de service, comme le délai de bout en bout.

La meilleure route est alors choisie de proche en proche pour atteindre le serveur.

C'est bien souvent le plus court chemin, autrement dit la route avec le moins de routeurs intermédiaires afin de diminuer le temps de traitement et la longueur du chemin.

Vous verrez, dans la partie 2 de ce cours, comment calculer un plus court chemin.

Enfin, outre les routeurs, les paquets échangés entre l’objet connecté et le serveur peuvent traverser d’autres équipements tels que :

  • un firewall pour bloquer/analyser certains trafics et se protéger d’attaques ;

  • un routeur sans fil ;

  • une box ADSL ;

  • un réseau cellulaire 4G pour fournir la connectivité de l’objet connecté à Internet.

Définissez les messages échangés entre client et serveur (publish, get)

Maintenant que nous avons une vision d’ensemble du fonctionnement d’un objet connecté et de comment les échanges d’informations peuvent se faire avec le serveur, attardons-nous sur les messages échangés entre le client et le serveur.

Il nous faut distinguer deux types de messages :

  • les messages applicatifs, qui contiennent les données mesurées et collectées par l’objet connecté ;

  • les messages qui sont liés à Internet et ses protocoles.

Nous avons évoqué les messages applicatifs précédemment : ce sont les messages de type PUBLISH ainsi que les messages de type GET et PUT. Les messages liés à Internet sont les messages que nous avons évoqués précédemment et que nous avons appelés les paquets IP. Nous y reviendrons en détail dans la partie 4 de ce cours.

  • Les messages de type GET sont les messages utilisés par le serveur pour interroger un objet connecté depuis un serveur.

  • Les messages de type PUT sont les messages utilisés par le client pour communiquer des données au serveur suite à une requête de celui-ci.

  • Les messages de type PUBLISH sont des messages envoyés par l’objet connecté, que ce soit de façon périodique ou événementielle.

Parfois, nous devons être sûr que les messages envoyés sont bien reçus par le destinataire. Ainsi, apparaissent des mécanismes d’acquittement et des temporisateurs visant à permettre la fiabilité des échanges.

Par exemple, lorsqu’un serveur envoie un GET, il va armer un temporisateur dont la durée est calculée pour permettre la réception du message PUT. Si à expiration du temporisateur, le serveur n’a pas reçu de réponse PUT, alors le serveur va considérer que le message GET a été perdu et il va pouvoir le retransmettre.

Nous avons terminé le premier chapitre de ce cours et nous avons maintenant une vision d’ensemble du fonctionnement de notre objet connecté et de ses interactions avec Internet. Dans le chapitre suivant, nous allons étudier plus en détail les échanges d’informations de l’objet connecté avec le serveur.

Exemple de certificat de réussite
Exemple de certificat de réussite