Premières notions

Introduction à la technologie LoRaWAN®

La technologie LoRa

LoRa est une technologie de communication radio propriétaire appartenant à la société Semtech. Elle est basée sur une modulation à étalement de spectre de type CSS (Chirp Spread Spectrum) avec comme principales caractéristiques un débit relativement faible de ses transmissions au profit d’une portée plus grande et d’une bonne résistance au bruit. Comme d’autres technologies radio apparues ces dernières années, LoRa a été développée dans l’optique d’être utilisée pour bâtir des réseaux longue portée à faible consommation énergétique (LPWAN ou Low Power Wide Area Network) pour de nombreux cas d’usage liés à ce qui est communément appelé l’Internet des objets. La technologie LoRa permet également d’utiliser des débits différents en choisissant un facteur d’étalement (SF ou Spreading Factor) différent. Diminuer le débit par exemple permettra d’augmenter la portée au détriment d’un temps d’émission plus long et d’une consommation plus grande et inversement.

 

Le protocole LoRaWAN®

LoRaWAN® est un protocole de communication basé autour de la technologie LoRa. Il est défini et promu par un groupement de différents acteurs (opérateurs de réseaux, fabricants d’objets communicants, etc.), réunis au sein de la LoRa Alliance. Ce protocole permet entre autres d’avoir un échange de données chiffré entre l’objet et le réseau, d’établir une communication bidirectionnelle ou d’optimiser le débit en fonction des conditions radio (ADR ou Adaptive Data Rate). Il est notamment défini pour être utilisé sur des bandes de fréquences non licenciées (contrairement aux réseaux de téléphonie mobile), sur la bande ISM 868 MHz en Europe ou la bande des 915 MHz aux Etats-Unis par exemple.

Note : les descriptions techniques du protocole ou de l’architecture réseau qui suivent se basent sur la version 1.0.2 du protocole LoRaWAN®. La version LoRaWAN® 1.1 est sortie récemment et n’est pas encore disponible sur le réseau Objenious. A date, peu de fabricants ont commencé à implémenter cette version.

Réseau LoRaWAN® d’Objenious

Le réseau LoRaWAN® d’Objenious peut être illustré par :

  • Gateways (passerelles) : elles permettent de recevoir les messages émis par les objets pour les transmettre au cœur de réseau et d’envoyer les messages transmis par le réseau vers les objets.
  • Lora Network Server (cœur de réseau) : il gère les flux de messages entre les objets et le réseau, configure le débit et la puissance d’émission des objets et globalement, gère tout ce qui est lié à la mise en œuvre du protocole LoRaWAN®.
  • KMS (Key Management System) : il stocke les clés de sécurité permettant l’activation d’un objet sur le réseau et l’échange sécurisé des messages entre l’objet et le réseau.
  • SPOT (plateforme de gestion Objenious) : elle permet entre autres d’enregistrer des objets sur le réseau, de les gérer et de visualiser leurs données.

La plateforme SPOT

La plateforme SPOT (Smart Portal of Things) d’Objenious est une plateforme dédiée aux objets connectés conçue pour piloter des centaines de millions d’objets hétérogènes et exploiter efficacement les données remontées.

Basée sur une solution logicielle cloud, la plateforme SPOT est hautement disponible et hébergée en Europe. Elle permet un usage transverse, multi secteurs et « multi tenants », et offre une indépendance totale vis-à-vis des fabricants de capteurs et des protocoles réseaux.

Principales fonctions de la plateforme SPOT :

  • Piloter votre parc d’objets en toute autonomie : de la connexion à la gestion de tout type d’objets, en passant par la supervision technique de votre parc de capteurs.
  • Analyser, visualiser et superviser votre activité grâce à une suite complète d’outils de visualisation et d’analyse de données et à des dashboards personnalisables en fonction des usages
  • Innover, créer et valoriser des services à valeur ajoutée grâce à des fonctionnalités avancées de gestion d’événements et de création de scénarios et à l’intégration d’applicatifs métiers

Les capteurs

Implémentation

Le protocole LoRaWAN® est relativement simple pour permettre son implémentation dans une large gamme d’objets ne disposant pas nécessairement d’une puissance de calcul importante et opérant principalement sur pile, de nombreux cas d’usage ayant comme objectif une durée de vie de plusieurs années en émettant seulement quelques messages par jour. Pour cela, le protocole définit notamment trois classes d’objets (A, B et C) qui se distinguent par une latence plus ou moins forte dans la communication descendante (downlink) du réseau vers l’objet. La classe A étant commune à tous les objets, les classes B et C sont des fonctionnalités supplémentaires ajoutées à la classe A.

Classe A :

  • L’émission de messages (uplink) est à l’initiative de l’objet. Une fenêtre d’écoute est ouverte quelques secondes après pour la réception éventuelle d’un downlink.
  • Elle est principalement destinée aux objets sur pile nécessitant de recevoir peu de downlinks ou sans besoin d’une latence faible.

Classe B :

  • Des fenêtres d’écoute périodiques et synchronisées avec le réseau sont ouvertes, même sans l’émission d’un uplink.
  • Elle consomme plus d’énergie et est principalement destinée aux objets nécessitant d’être contrôlés via downlink avec peu de latence.

Classe C :

  • L’objet est en écoute permanente (hormis lorsqu’il émet un uplink).
  • Elle est principalement destinée aux objets alimentés sur secteur et permet de ne pas avoir de latence sur les downlinks.
Méthodes d’activation

Le protocole LoRaWAN® dispose de deux méthodes d’activation pour autoriser un objet à communiquer sur le réseau.

OTAA : Over-The-Air Activation

C’est la méthode favorisée par Objenious et la seule disponible sur son réseau.

L’activation d’un objet se fait après un premier échange de messages entre l’objet et le réseau (nommés JoinRequest et JoinAccept).

Les clés de session permettant l’authentification et le chiffrement des messages sont générées suite à cet échange, avant d’être stockées dans l’objet.

ABP : Activation By Personalisation

Les clés de session permettant l’authentification et le chiffrement des messages sont stockées dès le départ dans l’objet, au moment de sa fabrication, ou plutôt de sa personnalisation.

Identifiants

Les différents identifiants permettant une activation sur le réseau sont les suivants :

 

Identifiant Description OTAA ABP
DevEUI Identifiant unique de l’objet Requis Recommandé
AppEUI Identifiant de l’entité pouvant gérer les JoinRequest de l’objet Requis Non requis
AppKey Clé primaire stockée dans l’objet permettant la procédure d’OTAA Requis Non requis
DevAddr Adresse de l’objet sur le réseau Généré Enregistré
NwkSKey Clé permettant de vérifier l’intégrité des messages Généré Enregistré
AppSKey Clé permettant de chiffrer les messages Généré Enregistré

 

Conception hardware

Choix du matériel

Bien choisir son matériel est essentiel pour le développement de son objet connecté. En effet, l’utilisation ne sera pas la même entre un kit de développement, un module ou des composants discrets lors du prototypage ou de la réalisation d’un produit industriel. Il est nécessaire de se poser la question de la destination de l’objet avant de choisir le matériel à intégrer.

Des paramètres comme la maturité du projet, le coût cible, la capacité de développement ou encore les délais sont à prendre en compte.

Kit de développement

Les kits de développement ou cartes de développement sont des produits proposant plusieurs fonctionnalités déjà intégrées. Les kits de développements permettent de concevoir rapidement des prototypes de capteurs ou de services liés à l’IoT.

Le choix du kit pourra alors se faire en fonction des capteurs intégrés ou des interfaces disponibles pour tester rapidement la faisabilité technique du projet, ou bien le module ou les composants utilisés sur le kit, comme le type de microcontrôleur, qui seront retenus pour la phase d’industrialisation. Il y aura alors moins de développement de nouveau code pour passer d’une phase à l’autre.

Module

Les modules sont des composants électroniques qui intègrent la partie radio et une partie microcontrôleur. Ils peuvent comporter une librairie implémentant la partie protocolaire LoRaWAN® et permettent de programmer son application sur le microcontrôleur du module. La librairie peut alors être ouverte (code source disponible) ou fermée. Ils peuvent également être fourni comme un modem. Il faudra alors utiliser un microcontrôleur externe pour communiquer avec le module et le contrôler.

Le premier type offre l’avantage d’utiliser un seul microcontrôleur mais ouvre au risque d’introduire des dysfonctionnements dans le fonctionnement du module et de la gestion du protocole. Le deuxième type est plus sûr de ce point de vue-là mais aura un coût supplémentaire.

Composants discrets

Réaliser une carte électronique en intégrant soi-même les composants radio (à partir d’une puce radio LoRa) nécessite une bonne connaissance en développement radio. Le routage, l’adaptation d’antenne ou encore l’immunité au bruit doit alors être géré soi-même.

Cela peut se justifier pour des raisons de gestion des coûts s’il est prévu un fort volume de fabrication ou de maîtrise de l’architecture par exemple.

Design de l’antenne

Le design de l’antenne est une étape primordiale dans la conception de l’objet et il doit être pensé dès le départ du projet car il aura un impact à la fois sur le design de la carte électronique et sur celui du boitier. Chacun aura une influence sur l’autre et doit être adapté à l’usage qui sera fait de l’objet.

Le sujet est en réalité plus global que le seul design de l’antenne. Il s’agit en effet de celui des performances radio de l’objet, à la fois en émission et en réception.

L’antenne n’est pas le seul élément qui aura un impact sur celles-ci. Une alimentation qui crée des parasites pourra par exemple diminuer largement la sensibilité en réception de l’objet en générant du bruit parasite.

Des bureaux spécialisés existent pour aider à la conception de l’antenne et du design de la carte en général.

Le fait que l’objet soit placé dans un environnement extérieur ou intérieur (outdoor, indoor, deep-indoor), qu’il soit en mouvement ou non, qu’il soit installé contre un mur ou une paroi métallique peut avoir un impact important sur la qualité de la transmission, voire même sur la batterie.

  • Polarisation des antennes

Les antennes des gateways sont installées verticalement. Si l’antenne de l’objet est installée horizontalement le bilan radio sera fortement impacté.

  • Type et format de l’antenne

Les antennes sont variées et des critères de performances, de tailles, de répétabilité de la production ou de coût seront à prendre en compte. Elles peuvent être filaires, imprimées sur PCB, PIFA ou hélicoïdales, etc.

  • Déport de l’antenne

Lorsque l’objet doit être installé dans une baie informatique, dans une cave ou au fond d’un puit, il peut être opportun de prévoir un déport d’antenne.

Objet avec connectivités multiples

Un objet peut prévoir d’utiliser plusieurs technologies radio (Wi-Fi, GSM, LoRaWAN®, etc.) qui devront alors cohabiter. Le design des antennes peut alors devenir encore plus complexe pour éviter que ces technologies ne se perturbent entre elles. Il est vivement conseillé de s’adresser à un bureau d’étude afin de vérifier que les différentes antennes et composants tiers ne perturbent pas les transmissions radios.

Alimentation de l’objet

Le choix de l’alimentation va se faire en fonction de l’autonomie souhaitée pour l’objet, de ses conditions d’utilisation, à la fois au niveau fonctionnel et environnemental, et va également impacter le choix des composants (mode veille plus ou moins efficace d’un composant, ajout ou non d’une super capacité, etc.).

Dans la plupart des cas, il s’agira d’une pile non rechargeable qui a souvent une autodécharge plus faible que les batteries rechargeables et conviendront à des objets qui seront installés plusieurs années sans intervention. La chimie de la pile va par exemple avoir des conséquences sur sa capacité, sur le courant qu’elle sera capable de délivrer ou encore sur les températures pour lesquelles elle pourra fonctionner.

L’alimentation pourra aussi être une batterie rechargeable ou venir d’une source d’alimentation externe selon les cas d’usage, ou une combinaison entre alimentation externe et batterie de secours.

La fixation de la pile doit également prise en considération. Elle pourra être soudée ou mise dans un support, remplaçable ou non, etc.

Conception mécanique

Le design mécanique de l’objet pourra prendre en compte des éléments tels que l’environnement dans lequel il va évoluer ou son mode de fixation.

Pour l’environnement, des paramètres comme la température vont être considérés, la résistance à l’humidité avec les indices de protection IP, les atmosphères explosives avec la certification ATEX ou bien la résistance mécanique aux chocs ou aux vibrations (norme IEC 68.2.6, etc.). Tous ces éléments affectent évidemment le choix des composants électroniques et le design de la carte.

Le type de fixation pourra prendre en compte des critères comme la facilité d’installation ou de désinstallation ou encore la position de l’antenne de l’objet. Il pourra être vissé, clipsé, aimanté, cerclé, etc.

Il faudra également penser à l’identification du produit. Elle pourra se faire par simple étiquetage (la position devra être choisie pour être lisible après installation) ou via un lecteur NFC ou d’autres méthodes.

Un point important de sécurité concerne l’AppKey de l’objet. Il s’agit d’une clé secrète qui ne doit pas être affichée.

Conception firmware

Messages

L’utilisation des réseaux LPWAN impose souvent des contraintes sur l’utilisation des bandes de fréquence, qui sont libres et donc partagées. La principale contrainte est celle du duty-cycle qui limite le temps d’émission d’un objet. Dans le cas d’un objet LoRaWAN® sur la bande 886 MHz, elle est généralement de 1% (cf. norme ETSI EN 300 220).

Les gateways, comme n’importe quel autre objet utilisant cette bande, sont également soumises à ces limitations. Les capacités downlink du réseau sont donc plus limitées que les capacités uplink car la ressource est partagée entre tous les objets qu’une gateway doit adresser.

Différents éléments sont à prendre en compte lors de l’élaboration du fonctionnement de l’objet.

 

Fréquence d’envoi : il est conseillé de réduire l’émission des messages au minimum utile pour l’utilisation souhaitée. C’est-à-dire ne pas chercher à utiliser le maximum des ressources permises sur la bande, mais au contraire avoir une utilisation raisonnée.

 

Taille : tout comme pour la fréquence d’envoi, réduire la taille des messages diminue le temps d’émission et donc les risques d’interférences entre deux objets. Mais c’est un critère à mettre en balance avec d’autres comme le format des données ou le nombre d’envois. Le protocole permet d’utiliser un nombre d’octets différents selon le SF, mais celui-ci étant contrôlé par le réseau, il est conseillé de se limiter au cas le plus défavorable, à savoir 51 octets pour SF12. Dans certains cas, des techniques de compression de données peuvent également être appliquées.

 

Format des données : utiliser un format de données qui peut être décrit sans connaissance préalable de la configuration de l’objet est recommandé. Par exemple, pour un objet relevant plusieurs températures périodiquement avant de les envoyer et ayant une période configurable, un octet peut être utilisé pour décrire cet intervalle.

 

Fiabilisation de la remontée d’information : la nature du réseau et du protocole ne permet pas de garantir qu’un message émis sera nécessairement reçu. Selon le cas d’usage, la tolérance du système à la perte de messages sera différente. Des stratégies peuvent être employées pour en limiter les impacts. L’une d’entre elles consiste à utiliser la redondance d’information. Par exemple, un objet émettant un relevé de température toutes les heures pourrait choisir d’émettre toutes les heures les températures des deux dernières heures. Cela augmente bien entendu la taille des données et il y a donc un compromis à trouver.

 

Messages avec acquittement : le protocole permet l’émission de message requérant un acquittement du réseau (Confirmed message), au contraire des messages classiques (Unconfirmed message). Il est conseillé de ne pas ou très peu utiliser ce type de message. Comme mentionné, la ressource downlink est bien plus rare que la ressource uplink. Il est donc nécessaire de limiter cette utilisation aux cas où la réception doit être garantie entièrement, comme pour des alarmes de sécurité se déclenchant occasionnellement. Des stratégies simples n’utilisant pas de ressource downlink, comme la répétition des messages, peuvent suffire à augmenter de manière importante la probabilité de réception.

Cycle de vie

Tout comme la conception hardware et mécanique doit tenir compte des différentes phases de la vie de l’objet (installation, démarrage, etc.), avec des choix à faire sur les interfaces avec l’utilisateur (indicateurs lumineux, boutons, etc.) ou le type de fixation, le développement du firmware soulève également des questions qui peuvent être différentes selon les étapes du cycle de vie.

 

Démarrage et installation de l’objet :

  • L’objet peut-il être démarré et installé sans que l’activation sur le réseau ne soit complète ? Il est recommandé d’avoir une stratégie d’émission des JoinRequest plus rapprochée pour les premières tentatives et de plus en plus éloignée ensuite. Cela permet d’augmenter les chances d’activation après le démarrage mais également de laisser l’objet sur site si l’activation n’a pas réussi immédiatement, sans pour autant surconsommer.
  • Il peut être utile d’avoir une phase d’émission de quelques messages après une activation réussie pour permettre d’évaluer sommairement le niveau de réception de l’objet sur le réseau.
  • L’objet est-il prévu pour être installé unitairement ou au cours d’un processus d’installation en grand nombre ? Dans ce dernier cas, l’utilité du point précédent est à mettre en regard du nombre important de collisions entre messages de plusieurs objets que cela peut entrainer.

 

Fonctionnement de l’objet :

  • Il est recommandé de pouvoir reconfigurer l’objet par l’envoi de downlink. Si d’autres moyens sont également permis, il faudra se poser la question de qui aura accès à cette reconfiguration et comment en contrôler l’accès si nécessaire.

 

Mise à jour de l’objet :

  • Il est important de pouvoir mettre à jour le firmware de l’objet pour palier à d’éventuelles failles. La mise à jour au travers du réseau (FUOTA ou Firmware Upgrade Over The Air) n’est pas encore standardisée à date mais d’autres méthodes peuvent être employées (mise à jour avec accès physique, à courte distance, etc.). Dans tous les cas, il faut également différents aspects pour sécuriser les mises à jour (autorisation, vérification de l’intégrité, etc.).

 

Arrêt de l’objet :

  • Une fois démarré, l’objet doit-il pouvoir être éteint ? Tout objet n’a pas forcément vocation à pouvoir être éteint facilement. Certains par exemple pourront être éteint uniquement via un downlink pour restreindre cette fonctionnalité.

Tous ces points sont à évaluer en fonction des bénéfices et des risques qui peuvent y être associés, et des coûts, difficultés d’implémentation, ergonomie ou simplicité d’utilisation qui en découlent.

Gestion des identifiants et sécurité

La clé de sécurité AppKey est le secret à conserver dans l’objet et à ne pas divulguer. Elle permet de sécuriser les échanges entre l’objet, le réseau et l’application finale.

L’AppKey doit impérativement être unique par objet. Cela permet de limiter les risques si un attaquant obtient une clé. Dans ce cas, un seul objet sera compromis.

De préférence, une AppKey doit être aléatoire ou au moins pseudo-aléatoire. Il faut éviter de générer des clés au travers d’un schéma facilement identifiable, comme la concaténation de l’AppEUI et du DevEUI par exemple.

Les risques et les méthodes à implémenter pour y pallier sont à évaluer à tous les niveaux, de la conception à la fabrication en usine, jusqu’à l’utilisateur final.

Par exemple, lors de la conception, si certaines informations sont destinées à être accessibles au travers d’une interface série (période d’émission de l’objet, etc.), il est vivement déconseillé de rendre l’AppKey accessible. L’utilisation d’un Secure Element, sorte de coffre électronique permettant de stocker les clés, peut également être envisagée.

Lors de la fabrication, l’échange d’information entre le moment de la génération de la clé et l’introduction dans l’objet peut aussi comporter des risques. Tout comme l’échange entre le fabricant et l’utilisateur final. Des méthodes comme le chiffrement des informations lors des échanges peuvent être utilisés pour limiter la fuite des clés de sécurité.

Intégration Objenious Starter

Objenious Starter

L’offre on-line Objenious Starter vous offre une série d’outils pour le développement de capteur ou d’une solution applicative.

En quelques instants, vos souscrirez à l’offre et créer votre compte. Sans paramétrage vous avez accès à l’ensemble des fonctionnalités de la plateforme SPOT, de l’ajout du capteur à la visualisation des données.

L’accès à l’ensemble du réseau national LoRaWAN® d’Objenious est instantané et vous fournit un environnement propice à votre développement. L’offre Objenious Starter bénéficie au même titre que les autres offres Objenious d’une sécurité renforcée de bout en bout.

Objenious Starter intervient à la suite du développement Firmware et Hardware, et vous permet de visualiser les messages.

 

Souscrire en ligne

Notion de profil de capteur

Le profil de capteur désigne une catégorie de capteur. C’est une notion structurante dans la plateforme SPOT puisqu’elle permet de gérer plusieurs capteurs ensemble. Le profil de capteur permet de configurer en détail votre capteur, en sélectionnant le modèle de ce dernier, le forfait et les données affichées. Ainsi des capteurs adressant le même cas d’usages posséderont le même profil de capteur.

Il s’agit d’un prérequis indispensable pour la déclaration (ou provisionning) de vos capteurs sur la plateforme SPOT.

La configuration et création du profil de capteur peuvent s’effectuer de deux manières distinctes :

  • A partir d’un modèle de capteur :
    Des profils de capteurs pré-intégrés sont à disposition depuis la plateforme SPOT. Ils correspondent aux capteurs validés et référencés par les équipes d’Objenious et visible sur le catalogue web.
    En utilisant ces profils de capteurs, il vous reste plus qu’à les personnaliser avec des icônes, libellés ainsi que les données remontées lorsque les modèles possèdent un CODEC.
  • A partir d’un template vide (from scratch) :
    La création d’un profil de capteur à partir d’un template vide est également accessible grâce à l’offre Objenious Starter. Cette méthode est recommandée lorsque vous créez votre propre device puisque vous allez pouvoir associer ce profil de capteur à un CODEC que vous aurez préalablement développé.

Des champs pour la configuration de votre capteur seront également disponibles.

N’hésitez pas à lire le paragraphe 4.5 sur le développement de CODEC pour s’approprier la notion.

Provisionning des capteurs

Le provisionning désigne l’étape qui permet d’ajouter vos capteurs sur la plateforme SPOT. Certaines étapes sont nécessaires avant le provisionning, comme la création d’un profil de capteur.

Afin d’effectuer le provisionning, munissez-vous des identifiants du capteur, à savoir l’appEUI, DevEUI et appKey. (voir chapitre 1.4.3).

Cette action est instantanée et des informations sont à disposition pour avoir des indications en cas d’échec du provisionning.

Afin de répondre aux différentes problématiques pour l’ajout de capteurs, la plateforme SPOT d’Objenious dispose de plusieurs outils pour réaliser le provisionning de vos objets :

  • via un fichier Excel : Le template mis à disposition des clients, permet d’importer massivement les capteurs.
  • via un formulaire : Le formulaire directement accessible sur la plateforme SPOT, permet d’ajouter rapidement et simplement des capteurs unitairement.
  • via une API : L’API permet d’ajouter des capteurs sur la plateforme depuis le système SI d’un client.

Monitoring & KPI

Une fois votre capteur déclaré sur la plateforme, plusieurs indicateurs sont mis à disposition de l’utilisateur pour surveiller et contrôler la connectivité de ceux-ci sur la plateforme SPOT. La richesse des informations à dispositions, telles que la puissance du signal (RSSI), rapport signal sur bruit (SNR), le spreading factor (SF), la redondance spatiale et bien d’autres, vous donne la possibilité d’évaluer rigoureusement la qualité de de votre connexion au réseau LoRaWAN® d’Objenious.

De plus, différentes plages de précision, allant d’un message à une semaine, vous permettent de choisir la granularité adéquate à votre besoin.

Développement codec

Le codec vous permet le décodage des différentes trames remontées par votre capteur. Les informations sont alors transformées en valeur métier.

Solution applicative

Visualisation des données

La visualisation des données est uniquement possible, si le modèle de capteur possède un CODEC, permettant le décodage des données (compatible SPOT Vision ou développement d’un CODEC).

La visualisation des données s’effectue à plusieurs niveaux et différentes granularités sur la plateforme SPOT, offrant plusieurs éventualités sur :

  • la page dédiée d’un capteur (Accès à l’historique des messages et mesures)
  • la page « Mesures » (Tableau avec les valeurs de l’ensemble de votre parc de capteurs)
  • les tableaux de bords configurables (dashboarding)

Pour faciliter le traitement des données, il est possible d’exporter toutes ces informations en fichier csv.

Tableaux de bords (dashboarding)

Afin d’avoir une vue d’ensemble ou accéder aux informations critiques d’un coup d’œil, il est peut-être crucial de disposer de tableaux de bords mettant graphiquement en avant ces données. C’est pourquoi le portail de data visualisation est conçu pour faciliter l’accès aux informations collectées. Ainsi vous pouvez créer en quelques instants des représentations graphiques correspondant à votre besoin. L’outil de dashboarding possède une forte capacité d’adaptation, grâce à des tableaux de bord et à des widgets (élément visuel) métiers facilement paramétrables.

Pour concevoir ces tableaux de bord (dashboarding), une bibliothèque de widgets est proposée, avec plusieurs catégories d’usage (gestion de parc, indicateurs métiers, alertes). Les possibilités de paramétrage des widgets sont importantes, permettant ainsi la personnalisation des affichages.

  • Des widgets de gestion de parc : permettant par exemple de suivre une cartographie détaillée du parc, la position des capteurs et la visualisation des alertes, des statistiques d’évolution du parc selon les statuts techniques des capteurs, des consommations en termes de nombre de messages reçus ou envoyés au global dans le parc ou pour un capteur donné, ou alors la répartition de la flotte par type des capteurs.
  • Des widgets métiers : comme par exemple l’historique de mesures, des cartes métier avec une représentation graphique des données remontées selon un code couleur paramétrable, le suivi des consommations par période, les indicateurs unitaires des capteurs clés ou alors une synthèse par groupe des indicateurs métier s
  • Des widgets alerting : pouvant suivre les alertes en cours de toute ou partie du parc

Intégration sur une application tierce

Dans le cadre d’un développement d’une solution, vous serez amené à récupérer les informations ou automatiser des tâches. Dans ce but le portail propose divers outils pour une intégration facilitée de la plateforme SPOT avec votre application, particulièrement pour les actions les plus courantes.

Les données et la plupart des fonctionnalités de la plateforme sont accessibles à travers des APIs ouvertes type REST, permettant notamment la gestion de parc.

Le routage permet d’envoyer au fil de l’eau la totalité ou d’une partie des messages du parc de capteurs vers une ou plusieurs destinations.

Le routage peut se faire avec le protocole HTTPS ou alors via une intégration directe avec les plateformes cloud suivantes :

  • Azure IoTHub,
  • Azure EventHub,
  • Google PubSub,
  • Google IoTCore.

Industrialisation

 

Les conceptions hardware et firmware d’un objet doivent tenir compte de la phase d’industrialisation qui en résultera. Entre autres, le banc de tests utilisé en fin de chaîne de production doit si possible inclure des tests fonctionnels, mécaniques et de performances radio.

Les aspects visés lors des différentes certifications de l’objet (marquage CE, norme EN 300 220, indice de protection IP pour l’étanchéité et la résistance à la poussière, norme IEC 68.2.6 pour la résistance aux vibrations, etc.) peuvent être pris en compte pour s’assurer de la qualité et de la répétabilité lors de la fabrication.

En dernière étape, le processus de référencement d’un objet sur le réseau Objenious inclut également une phase de tests.

Premières notions

  • Introduction à la technologie LoRaWAN® add remove

    La technologie LoRa

    LoRa est une technologie de communication radio propriétaire appartenant à la société Semtech. Elle est basée sur une modulation à étalement de spectre de type CSS (Chirp Spread Spectrum) avec comme principales caractéristiques un débit relativement faible de ses transmissions au profit d’une portée plus grande et d’une bonne résistance au bruit. Comme d’autres technologies radio apparues ces dernières années, LoRa a été développée dans l’optique d’être utilisée pour bâtir des réseaux longue portée à faible consommation énergétique (LPWAN ou Low Power Wide Area Network) pour de nombreux cas d’usage liés à ce qui est communément appelé l’Internet des objets. La technologie LoRa permet également d’utiliser des débits différents en choisissant un facteur d’étalement (SF ou Spreading Factor) différent. Diminuer le débit par exemple permettra d’augmenter la portée au détriment d’un temps d’émission plus long et d’une consommation plus grande et inversement.

     

    Le protocole LoRaWAN®

    LoRaWAN® est un protocole de communication basé autour de la technologie LoRa. Il est défini et promu par un groupement de différents acteurs (opérateurs de réseaux, fabricants d’objets communicants, etc.), réunis au sein de la LoRa Alliance. Ce protocole permet entre autres d’avoir un échange de données chiffré entre l’objet et le réseau, d’établir une communication bidirectionnelle ou d’optimiser le débit en fonction des conditions radio (ADR ou Adaptive Data Rate). Il est notamment défini pour être utilisé sur des bandes de fréquences non licenciées (contrairement aux réseaux de téléphonie mobile), sur la bande ISM 868 MHz en Europe ou la bande des 915 MHz aux Etats-Unis par exemple.

    Note : les descriptions techniques du protocole ou de l’architecture réseau qui suivent se basent sur la version 1.0.2 du protocole LoRaWAN®. La version LoRaWAN® 1.1 est sortie récemment et n’est pas encore disponible sur le réseau Objenious. A date, peu de fabricants ont commencé à implémenter cette version.

  • Réseau LoRaWAN® d’Objenious add remove

    Le réseau LoRaWAN® d’Objenious peut être illustré par :

    • Gateways (passerelles) : elles permettent de recevoir les messages émis par les objets pour les transmettre au cœur de réseau et d’envoyer les messages transmis par le réseau vers les objets.
    • Lora Network Server (cœur de réseau) : il gère les flux de messages entre les objets et le réseau, configure le débit et la puissance d’émission des objets et globalement, gère tout ce qui est lié à la mise en œuvre du protocole LoRaWAN®.
    • KMS (Key Management System) : il stocke les clés de sécurité permettant l’activation d’un objet sur le réseau et l’échange sécurisé des messages entre l’objet et le réseau.
    • SPOT (plateforme de gestion Objenious) : elle permet entre autres d’enregistrer des objets sur le réseau, de les gérer et de visualiser leurs données.
  • La plateforme SPOT add remove

    La plateforme SPOT (Smart Portal of Things) d’Objenious est une plateforme dédiée aux objets connectés conçue pour piloter des centaines de millions d’objets hétérogènes et exploiter efficacement les données remontées.

    Basée sur une solution logicielle cloud, la plateforme SPOT est hautement disponible et hébergée en Europe. Elle permet un usage transverse, multi secteurs et « multi tenants », et offre une indépendance totale vis-à-vis des fabricants de capteurs et des protocoles réseaux.

    Principales fonctions de la plateforme SPOT :

    • Piloter votre parc d’objets en toute autonomie : de la connexion à la gestion de tout type d’objets, en passant par la supervision technique de votre parc de capteurs.
    • Analyser, visualiser et superviser votre activité grâce à une suite complète d’outils de visualisation et d’analyse de données et à des dashboards personnalisables en fonction des usages
    • Innover, créer et valoriser des services à valeur ajoutée grâce à des fonctionnalités avancées de gestion d’événements et de création de scénarios et à l’intégration d’applicatifs métiers
  • Les capteurs add remove

    Implémentation

    Le protocole LoRaWAN® est relativement simple pour permettre son implémentation dans une large gamme d’objets ne disposant pas nécessairement d’une puissance de calcul importante et opérant principalement sur pile, de nombreux cas d’usage ayant comme objectif une durée de vie de plusieurs années en émettant seulement quelques messages par jour. Pour cela, le protocole définit notamment trois classes d’objets (A, B et C) qui se distinguent par une latence plus ou moins forte dans la communication descendante (downlink) du réseau vers l’objet. La classe A étant commune à tous les objets, les classes B et C sont des fonctionnalités supplémentaires ajoutées à la classe A.

    Classe A :

    • L’émission de messages (uplink) est à l’initiative de l’objet. Une fenêtre d’écoute est ouverte quelques secondes après pour la réception éventuelle d’un downlink.
    • Elle est principalement destinée aux objets sur pile nécessitant de recevoir peu de downlinks ou sans besoin d’une latence faible.

    Classe B :

    • Des fenêtres d’écoute périodiques et synchronisées avec le réseau sont ouvertes, même sans l’émission d’un uplink.
    • Elle consomme plus d’énergie et est principalement destinée aux objets nécessitant d’être contrôlés via downlink avec peu de latence.

    Classe C :

    • L’objet est en écoute permanente (hormis lorsqu’il émet un uplink).
    • Elle est principalement destinée aux objets alimentés sur secteur et permet de ne pas avoir de latence sur les downlinks.
    Méthodes d’activation

    Le protocole LoRaWAN® dispose de deux méthodes d’activation pour autoriser un objet à communiquer sur le réseau.

    OTAA : Over-The-Air Activation

    C’est la méthode favorisée par Objenious et la seule disponible sur son réseau.

    L’activation d’un objet se fait après un premier échange de messages entre l’objet et le réseau (nommés JoinRequest et JoinAccept).

    Les clés de session permettant l’authentification et le chiffrement des messages sont générées suite à cet échange, avant d’être stockées dans l’objet.

    ABP : Activation By Personalisation

    Les clés de session permettant l’authentification et le chiffrement des messages sont stockées dès le départ dans l’objet, au moment de sa fabrication, ou plutôt de sa personnalisation.

    Identifiants

    Les différents identifiants permettant une activation sur le réseau sont les suivants :

     

    Identifiant Description OTAA ABP
    DevEUI Identifiant unique de l’objet Requis Recommandé
    AppEUI Identifiant de l’entité pouvant gérer les JoinRequest de l’objet Requis Non requis
    AppKey Clé primaire stockée dans l’objet permettant la procédure d’OTAA Requis Non requis
    DevAddr Adresse de l’objet sur le réseau Généré Enregistré
    NwkSKey Clé permettant de vérifier l’intégrité des messages Généré Enregistré
    AppSKey Clé permettant de chiffrer les messages Généré Enregistré

     

Conception hardware

  • Choix du matériel add remove

    Bien choisir son matériel est essentiel pour le développement de son objet connecté. En effet, l’utilisation ne sera pas la même entre un kit de développement, un module ou des composants discrets lors du prototypage ou de la réalisation d’un produit industriel. Il est nécessaire de se poser la question de la destination de l’objet avant de choisir le matériel à intégrer.

    Des paramètres comme la maturité du projet, le coût cible, la capacité de développement ou encore les délais sont à prendre en compte.

    Kit de développement

    Les kits de développement ou cartes de développement sont des produits proposant plusieurs fonctionnalités déjà intégrées. Les kits de développements permettent de concevoir rapidement des prototypes de capteurs ou de services liés à l’IoT.

    Le choix du kit pourra alors se faire en fonction des capteurs intégrés ou des interfaces disponibles pour tester rapidement la faisabilité technique du projet, ou bien le module ou les composants utilisés sur le kit, comme le type de microcontrôleur, qui seront retenus pour la phase d’industrialisation. Il y aura alors moins de développement de nouveau code pour passer d’une phase à l’autre.

    Module

    Les modules sont des composants électroniques qui intègrent la partie radio et une partie microcontrôleur. Ils peuvent comporter une librairie implémentant la partie protocolaire LoRaWAN® et permettent de programmer son application sur le microcontrôleur du module. La librairie peut alors être ouverte (code source disponible) ou fermée. Ils peuvent également être fourni comme un modem. Il faudra alors utiliser un microcontrôleur externe pour communiquer avec le module et le contrôler.

    Le premier type offre l’avantage d’utiliser un seul microcontrôleur mais ouvre au risque d’introduire des dysfonctionnements dans le fonctionnement du module et de la gestion du protocole. Le deuxième type est plus sûr de ce point de vue-là mais aura un coût supplémentaire.

    Composants discrets

    Réaliser une carte électronique en intégrant soi-même les composants radio (à partir d’une puce radio LoRa) nécessite une bonne connaissance en développement radio. Le routage, l’adaptation d’antenne ou encore l’immunité au bruit doit alors être géré soi-même.

    Cela peut se justifier pour des raisons de gestion des coûts s’il est prévu un fort volume de fabrication ou de maîtrise de l’architecture par exemple.

  • Design de l’antenne add remove

    Le design de l’antenne est une étape primordiale dans la conception de l’objet et il doit être pensé dès le départ du projet car il aura un impact à la fois sur le design de la carte électronique et sur celui du boitier. Chacun aura une influence sur l’autre et doit être adapté à l’usage qui sera fait de l’objet.

    Le sujet est en réalité plus global que le seul design de l’antenne. Il s’agit en effet de celui des performances radio de l’objet, à la fois en émission et en réception.

    L’antenne n’est pas le seul élément qui aura un impact sur celles-ci. Une alimentation qui crée des parasites pourra par exemple diminuer largement la sensibilité en réception de l’objet en générant du bruit parasite.

    Des bureaux spécialisés existent pour aider à la conception de l’antenne et du design de la carte en général.

    Le fait que l’objet soit placé dans un environnement extérieur ou intérieur (outdoor, indoor, deep-indoor), qu’il soit en mouvement ou non, qu’il soit installé contre un mur ou une paroi métallique peut avoir un impact important sur la qualité de la transmission, voire même sur la batterie.

    • Polarisation des antennes

    Les antennes des gateways sont installées verticalement. Si l’antenne de l’objet est installée horizontalement le bilan radio sera fortement impacté.

    • Type et format de l’antenne

    Les antennes sont variées et des critères de performances, de tailles, de répétabilité de la production ou de coût seront à prendre en compte. Elles peuvent être filaires, imprimées sur PCB, PIFA ou hélicoïdales, etc.

    • Déport de l’antenne

    Lorsque l’objet doit être installé dans une baie informatique, dans une cave ou au fond d’un puit, il peut être opportun de prévoir un déport d’antenne.

  • Objet avec connectivités multiples add remove

    Un objet peut prévoir d’utiliser plusieurs technologies radio (Wi-Fi, GSM, LoRaWAN®, etc.) qui devront alors cohabiter. Le design des antennes peut alors devenir encore plus complexe pour éviter que ces technologies ne se perturbent entre elles. Il est vivement conseillé de s’adresser à un bureau d’étude afin de vérifier que les différentes antennes et composants tiers ne perturbent pas les transmissions radios.

  • Alimentation de l’objet add remove

    Le choix de l’alimentation va se faire en fonction de l’autonomie souhaitée pour l’objet, de ses conditions d’utilisation, à la fois au niveau fonctionnel et environnemental, et va également impacter le choix des composants (mode veille plus ou moins efficace d’un composant, ajout ou non d’une super capacité, etc.).

    Dans la plupart des cas, il s’agira d’une pile non rechargeable qui a souvent une autodécharge plus faible que les batteries rechargeables et conviendront à des objets qui seront installés plusieurs années sans intervention. La chimie de la pile va par exemple avoir des conséquences sur sa capacité, sur le courant qu’elle sera capable de délivrer ou encore sur les températures pour lesquelles elle pourra fonctionner.

    L’alimentation pourra aussi être une batterie rechargeable ou venir d’une source d’alimentation externe selon les cas d’usage, ou une combinaison entre alimentation externe et batterie de secours.

    La fixation de la pile doit également prise en considération. Elle pourra être soudée ou mise dans un support, remplaçable ou non, etc.

  • Conception mécanique add remove

    Le design mécanique de l’objet pourra prendre en compte des éléments tels que l’environnement dans lequel il va évoluer ou son mode de fixation.

    Pour l’environnement, des paramètres comme la température vont être considérés, la résistance à l’humidité avec les indices de protection IP, les atmosphères explosives avec la certification ATEX ou bien la résistance mécanique aux chocs ou aux vibrations (norme IEC 68.2.6, etc.). Tous ces éléments affectent évidemment le choix des composants électroniques et le design de la carte.

    Le type de fixation pourra prendre en compte des critères comme la facilité d’installation ou de désinstallation ou encore la position de l’antenne de l’objet. Il pourra être vissé, clipsé, aimanté, cerclé, etc.

    Il faudra également penser à l’identification du produit. Elle pourra se faire par simple étiquetage (la position devra être choisie pour être lisible après installation) ou via un lecteur NFC ou d’autres méthodes.

    Un point important de sécurité concerne l’AppKey de l’objet. Il s’agit d’une clé secrète qui ne doit pas être affichée.

Conception firmware

  • Messages add remove

    L’utilisation des réseaux LPWAN impose souvent des contraintes sur l’utilisation des bandes de fréquence, qui sont libres et donc partagées. La principale contrainte est celle du duty-cycle qui limite le temps d’émission d’un objet. Dans le cas d’un objet LoRaWAN® sur la bande 886 MHz, elle est généralement de 1% (cf. norme ETSI EN 300 220).

    Les gateways, comme n’importe quel autre objet utilisant cette bande, sont également soumises à ces limitations. Les capacités downlink du réseau sont donc plus limitées que les capacités uplink car la ressource est partagée entre tous les objets qu’une gateway doit adresser.

    Différents éléments sont à prendre en compte lors de l’élaboration du fonctionnement de l’objet.

     

    Fréquence d’envoi : il est conseillé de réduire l’émission des messages au minimum utile pour l’utilisation souhaitée. C’est-à-dire ne pas chercher à utiliser le maximum des ressources permises sur la bande, mais au contraire avoir une utilisation raisonnée.

     

    Taille : tout comme pour la fréquence d’envoi, réduire la taille des messages diminue le temps d’émission et donc les risques d’interférences entre deux objets. Mais c’est un critère à mettre en balance avec d’autres comme le format des données ou le nombre d’envois. Le protocole permet d’utiliser un nombre d’octets différents selon le SF, mais celui-ci étant contrôlé par le réseau, il est conseillé de se limiter au cas le plus défavorable, à savoir 51 octets pour SF12. Dans certains cas, des techniques de compression de données peuvent également être appliquées.

     

    Format des données : utiliser un format de données qui peut être décrit sans connaissance préalable de la configuration de l’objet est recommandé. Par exemple, pour un objet relevant plusieurs températures périodiquement avant de les envoyer et ayant une période configurable, un octet peut être utilisé pour décrire cet intervalle.

     

    Fiabilisation de la remontée d’information : la nature du réseau et du protocole ne permet pas de garantir qu’un message émis sera nécessairement reçu. Selon le cas d’usage, la tolérance du système à la perte de messages sera différente. Des stratégies peuvent être employées pour en limiter les impacts. L’une d’entre elles consiste à utiliser la redondance d’information. Par exemple, un objet émettant un relevé de température toutes les heures pourrait choisir d’émettre toutes les heures les températures des deux dernières heures. Cela augmente bien entendu la taille des données et il y a donc un compromis à trouver.

     

    Messages avec acquittement : le protocole permet l’émission de message requérant un acquittement du réseau (Confirmed message), au contraire des messages classiques (Unconfirmed message). Il est conseillé de ne pas ou très peu utiliser ce type de message. Comme mentionné, la ressource downlink est bien plus rare que la ressource uplink. Il est donc nécessaire de limiter cette utilisation aux cas où la réception doit être garantie entièrement, comme pour des alarmes de sécurité se déclenchant occasionnellement. Des stratégies simples n’utilisant pas de ressource downlink, comme la répétition des messages, peuvent suffire à augmenter de manière importante la probabilité de réception.

  • Cycle de vie add remove

    Tout comme la conception hardware et mécanique doit tenir compte des différentes phases de la vie de l’objet (installation, démarrage, etc.), avec des choix à faire sur les interfaces avec l’utilisateur (indicateurs lumineux, boutons, etc.) ou le type de fixation, le développement du firmware soulève également des questions qui peuvent être différentes selon les étapes du cycle de vie.

     

    Démarrage et installation de l’objet :

    • L’objet peut-il être démarré et installé sans que l’activation sur le réseau ne soit complète ? Il est recommandé d’avoir une stratégie d’émission des JoinRequest plus rapprochée pour les premières tentatives et de plus en plus éloignée ensuite. Cela permet d’augmenter les chances d’activation après le démarrage mais également de laisser l’objet sur site si l’activation n’a pas réussi immédiatement, sans pour autant surconsommer.
    • Il peut être utile d’avoir une phase d’émission de quelques messages après une activation réussie pour permettre d’évaluer sommairement le niveau de réception de l’objet sur le réseau.
    • L’objet est-il prévu pour être installé unitairement ou au cours d’un processus d’installation en grand nombre ? Dans ce dernier cas, l’utilité du point précédent est à mettre en regard du nombre important de collisions entre messages de plusieurs objets que cela peut entrainer.

     

    Fonctionnement de l’objet :

    • Il est recommandé de pouvoir reconfigurer l’objet par l’envoi de downlink. Si d’autres moyens sont également permis, il faudra se poser la question de qui aura accès à cette reconfiguration et comment en contrôler l’accès si nécessaire.

     

    Mise à jour de l’objet :

    • Il est important de pouvoir mettre à jour le firmware de l’objet pour palier à d’éventuelles failles. La mise à jour au travers du réseau (FUOTA ou Firmware Upgrade Over The Air) n’est pas encore standardisée à date mais d’autres méthodes peuvent être employées (mise à jour avec accès physique, à courte distance, etc.). Dans tous les cas, il faut également différents aspects pour sécuriser les mises à jour (autorisation, vérification de l’intégrité, etc.).

     

    Arrêt de l’objet :

    • Une fois démarré, l’objet doit-il pouvoir être éteint ? Tout objet n’a pas forcément vocation à pouvoir être éteint facilement. Certains par exemple pourront être éteint uniquement via un downlink pour restreindre cette fonctionnalité.

    Tous ces points sont à évaluer en fonction des bénéfices et des risques qui peuvent y être associés, et des coûts, difficultés d’implémentation, ergonomie ou simplicité d’utilisation qui en découlent.

  • Gestion des identifiants et sécurité add remove

    La clé de sécurité AppKey est le secret à conserver dans l’objet et à ne pas divulguer. Elle permet de sécuriser les échanges entre l’objet, le réseau et l’application finale.

    L’AppKey doit impérativement être unique par objet. Cela permet de limiter les risques si un attaquant obtient une clé. Dans ce cas, un seul objet sera compromis.

    De préférence, une AppKey doit être aléatoire ou au moins pseudo-aléatoire. Il faut éviter de générer des clés au travers d’un schéma facilement identifiable, comme la concaténation de l’AppEUI et du DevEUI par exemple.

    Les risques et les méthodes à implémenter pour y pallier sont à évaluer à tous les niveaux, de la conception à la fabrication en usine, jusqu’à l’utilisateur final.

    Par exemple, lors de la conception, si certaines informations sont destinées à être accessibles au travers d’une interface série (période d’émission de l’objet, etc.), il est vivement déconseillé de rendre l’AppKey accessible. L’utilisation d’un Secure Element, sorte de coffre électronique permettant de stocker les clés, peut également être envisagée.

    Lors de la fabrication, l’échange d’information entre le moment de la génération de la clé et l’introduction dans l’objet peut aussi comporter des risques. Tout comme l’échange entre le fabricant et l’utilisateur final. Des méthodes comme le chiffrement des informations lors des échanges peuvent être utilisés pour limiter la fuite des clés de sécurité.

Intégration Objenious Starter

  • Objenious Starter add remove

    L’offre on-line Objenious Starter vous offre une série d’outils pour le développement de capteur ou d’une solution applicative.

    En quelques instants, vos souscrirez à l’offre et créer votre compte. Sans paramétrage vous avez accès à l’ensemble des fonctionnalités de la plateforme SPOT, de l’ajout du capteur à la visualisation des données.

    L’accès à l’ensemble du réseau national LoRaWAN® d’Objenious est instantané et vous fournit un environnement propice à votre développement. L’offre Objenious Starter bénéficie au même titre que les autres offres Objenious d’une sécurité renforcée de bout en bout.

    Objenious Starter intervient à la suite du développement Firmware et Hardware, et vous permet de visualiser les messages.

     

    Souscrire en ligne

  • Notion de profil de capteur add remove

    Le profil de capteur désigne une catégorie de capteur. C’est une notion structurante dans la plateforme SPOT puisqu’elle permet de gérer plusieurs capteurs ensemble. Le profil de capteur permet de configurer en détail votre capteur, en sélectionnant le modèle de ce dernier, le forfait et les données affichées. Ainsi des capteurs adressant le même cas d’usages posséderont le même profil de capteur.

    Il s’agit d’un prérequis indispensable pour la déclaration (ou provisionning) de vos capteurs sur la plateforme SPOT.

    La configuration et création du profil de capteur peuvent s’effectuer de deux manières distinctes :

    • A partir d’un modèle de capteur :
      Des profils de capteurs pré-intégrés sont à disposition depuis la plateforme SPOT. Ils correspondent aux capteurs validés et référencés par les équipes d’Objenious et visible sur le catalogue web.
      En utilisant ces profils de capteurs, il vous reste plus qu’à les personnaliser avec des icônes, libellés ainsi que les données remontées lorsque les modèles possèdent un CODEC.
    • A partir d’un template vide (from scratch) :
      La création d’un profil de capteur à partir d’un template vide est également accessible grâce à l’offre Objenious Starter. Cette méthode est recommandée lorsque vous créez votre propre device puisque vous allez pouvoir associer ce profil de capteur à un CODEC que vous aurez préalablement développé.

    Des champs pour la configuration de votre capteur seront également disponibles.

    N’hésitez pas à lire le paragraphe 4.5 sur le développement de CODEC pour s’approprier la notion.

  • Provisionning des capteurs add remove

    Le provisionning désigne l’étape qui permet d’ajouter vos capteurs sur la plateforme SPOT. Certaines étapes sont nécessaires avant le provisionning, comme la création d’un profil de capteur.

    Afin d’effectuer le provisionning, munissez-vous des identifiants du capteur, à savoir l’appEUI, DevEUI et appKey. (voir chapitre 1.4.3).

    Cette action est instantanée et des informations sont à disposition pour avoir des indications en cas d’échec du provisionning.

    Afin de répondre aux différentes problématiques pour l’ajout de capteurs, la plateforme SPOT d’Objenious dispose de plusieurs outils pour réaliser le provisionning de vos objets :

    • via un fichier Excel : Le template mis à disposition des clients, permet d’importer massivement les capteurs.
    • via un formulaire : Le formulaire directement accessible sur la plateforme SPOT, permet d’ajouter rapidement et simplement des capteurs unitairement.
    • via une API : L’API permet d’ajouter des capteurs sur la plateforme depuis le système SI d’un client.
  • Monitoring & KPI add remove

    Une fois votre capteur déclaré sur la plateforme, plusieurs indicateurs sont mis à disposition de l’utilisateur pour surveiller et contrôler la connectivité de ceux-ci sur la plateforme SPOT. La richesse des informations à dispositions, telles que la puissance du signal (RSSI), rapport signal sur bruit (SNR), le spreading factor (SF), la redondance spatiale et bien d’autres, vous donne la possibilité d’évaluer rigoureusement la qualité de de votre connexion au réseau LoRaWAN® d’Objenious.

    De plus, différentes plages de précision, allant d’un message à une semaine, vous permettent de choisir la granularité adéquate à votre besoin.

  • Développement codec add remove

    Le codec vous permet le décodage des différentes trames remontées par votre capteur. Les informations sont alors transformées en valeur métier.

Solution applicative

  • Visualisation des données add remove

    La visualisation des données est uniquement possible, si le modèle de capteur possède un CODEC, permettant le décodage des données (compatible SPOT Vision ou développement d’un CODEC).

    La visualisation des données s’effectue à plusieurs niveaux et différentes granularités sur la plateforme SPOT, offrant plusieurs éventualités sur :

    • la page dédiée d’un capteur (Accès à l’historique des messages et mesures)
    • la page « Mesures » (Tableau avec les valeurs de l’ensemble de votre parc de capteurs)
    • les tableaux de bords configurables (dashboarding)

    Pour faciliter le traitement des données, il est possible d’exporter toutes ces informations en fichier csv.

  • Tableaux de bords (dashboarding) add remove

    Afin d’avoir une vue d’ensemble ou accéder aux informations critiques d’un coup d’œil, il est peut-être crucial de disposer de tableaux de bords mettant graphiquement en avant ces données. C’est pourquoi le portail de data visualisation est conçu pour faciliter l’accès aux informations collectées. Ainsi vous pouvez créer en quelques instants des représentations graphiques correspondant à votre besoin. L’outil de dashboarding possède une forte capacité d’adaptation, grâce à des tableaux de bord et à des widgets (élément visuel) métiers facilement paramétrables.

    Pour concevoir ces tableaux de bord (dashboarding), une bibliothèque de widgets est proposée, avec plusieurs catégories d’usage (gestion de parc, indicateurs métiers, alertes). Les possibilités de paramétrage des widgets sont importantes, permettant ainsi la personnalisation des affichages.

    • Des widgets de gestion de parc : permettant par exemple de suivre une cartographie détaillée du parc, la position des capteurs et la visualisation des alertes, des statistiques d’évolution du parc selon les statuts techniques des capteurs, des consommations en termes de nombre de messages reçus ou envoyés au global dans le parc ou pour un capteur donné, ou alors la répartition de la flotte par type des capteurs.
    • Des widgets métiers : comme par exemple l’historique de mesures, des cartes métier avec une représentation graphique des données remontées selon un code couleur paramétrable, le suivi des consommations par période, les indicateurs unitaires des capteurs clés ou alors une synthèse par groupe des indicateurs métier s
    • Des widgets alerting : pouvant suivre les alertes en cours de toute ou partie du parc
  • Intégration sur une application tierce add remove

    Dans le cadre d’un développement d’une solution, vous serez amené à récupérer les informations ou automatiser des tâches. Dans ce but le portail propose divers outils pour une intégration facilitée de la plateforme SPOT avec votre application, particulièrement pour les actions les plus courantes.

    Les données et la plupart des fonctionnalités de la plateforme sont accessibles à travers des APIs ouvertes type REST, permettant notamment la gestion de parc.

    Le routage permet d’envoyer au fil de l’eau la totalité ou d’une partie des messages du parc de capteurs vers une ou plusieurs destinations.

    Le routage peut se faire avec le protocole HTTPS ou alors via une intégration directe avec les plateformes cloud suivantes :

    • Azure IoTHub,
    • Azure EventHub,
    • Google PubSub,
    • Google IoTCore.

Industrialisation

  •   add remove

    Les conceptions hardware et firmware d’un objet doivent tenir compte de la phase d’industrialisation qui en résultera. Entre autres, le banc de tests utilisé en fin de chaîne de production doit si possible inclure des tests fonctionnels, mécaniques et de performances radio.

    Les aspects visés lors des différentes certifications de l’objet (marquage CE, norme EN 300 220, indice de protection IP pour l’étanchéité et la résistance à la poussière, norme IEC 68.2.6 pour la résistance aux vibrations, etc.) peuvent être pris en compte pour s’assurer de la qualité et de la répétabilité lors de la fabrication.

    En dernière étape, le processus de référencement d’un objet sur le réseau Objenious inclut également une phase de tests.