Description du Bilan du Projet WSO2 d'IOT

1. [CONFIDENTIEL] LE BILAN!

2. 1. PLAN

3. 3
v Schéma Général
v La Chaine IOT
v L’API Manager
v Le collecteur
v DataGraf
v Datascan
PLAN
v Budgets dépensés
v Les actions à mettre en oeuvre
v Annexes

4. 2. SCHÉMA GÉNÉRAL

5. 5
ARCHITECTURE GÉNÉRALE IMAGINÉE EN 2017
Voilà ce que nous avons imaginé en 2017
Ce qui a été installé :
• Un cluster ESB
• Un gestionnaire d’API
• Un Gestionnaire d’identité
• Un outil pour extraire les données et
les envoyer vers des systèmes
externes
• Une application ”in house”
DATASCAN
• Une application ”in house” de
DATAGRAF.
• L’envoi des informations vers du
machine Learning =>SnowFlake.
• La connexion à des Apis Externes.
Ce qui n’a pas encore été fait :
• La connexion à la BlockChain
• La connexion à d’autres Data Lake en
direct.

6. 3. LA CHAINE IOT

7. 7
v Réception des mesures des différents opérateurs
(Sigfox/TTN), d’autres peuvent facilement être
ajoutés.
v Alertes des capteurs techniques et de seuils.
v Renvoie sous forme d’Apis des informations
v La CIOT a été adapté pour l’ensemble des clients
de [CONFIDENTIEL]
OBJECTIFS
v Utilisation de Microservices développés en JAVA pour décoder le
Payload des capteurs et rendre ainsi agnostique au capteur la
CIOT.

8. 8
v La chaine IOT a été initialement construite pour un POC pour le groupe
Michel puis étendu à l’ensemble des prospects de [CONFIDENTIEL]
v Développée sur le cluster (système redondant) WSO2 EI.
v La communication est exclusivement faite au travers d’Apis on dispose
de 56 APIs, voir liste en annexe.
v Utilisation des technologies comme Redis afin de bénéficier de cache
pour les données.
v Mise en place de tableaux de bord de suivi du fonctionnement de
l’ensemble de la chaine (voir annexe)
DÉVELOPPEMENTS

9. 9
v Difficultés sur les Alertes :
Nous préconisons la mise en place d’un nouveau tableau de bord.
Ainsi que d’un système de notification
v La structure de la base de données de la CIOT est basée sur le POC le groupe Michel.
Voir explication en annexe
Nous disposons d’une solution alternative, si [CONFIDENTIEL] est intéressé (elle a été testée avec plus de 100
000 capteurs)
v Pas de campagne de « tests ».
Notamment sur les alertes.
v Pas d’environnement de tests avec des données fiables.
v Manque quelques APIs (suppression des capteurs,…)
v Utilisation d’un module de Gestion du cache non commandé par [CONFIDENTIEL].
v Documentation existante mais incomplète.
PROBLÈMES SUR LA CIOT 1/2

10. 10
v Les Microservices Java sont appelés directement par L’ESB, nous recommandons de les
installer derrière l’API Manager. Ainsi il sera possible de leur faire passer une XSLT et de
différencier les capteurs entre eux.
v Manque de spécifications ou incomplètes et interprétables de façons équivoques.
v Deux problèmes depuis Mai 2019, liés à une panne de base de données de notre Provider
le 13 février 2020 et la seconde à une saturation du serveur pendant son backup. Reprise
des données à notre compte, aucune perte de donnée malgré une indisponibilité de 2 fois
1:30 et un fois 2:20.
PROBLÈMES SUR LA CIOT 2/2

11. 4. L’API Management

12. 12
v Permettre à certains clients de [CONFIDENTIEL]
de pouvoir récupérer des données sous forme de
messages.
v Développement en mode test pour un client de
[CONFIDENTIEL]
Les développements pour cet outil n’ont jamais été
facturés
v Intégration d’un outil de gestion des identités
v Objectif de fonctionnement atteint, pas de retour
de « RUN »
OBJECTIFS

13. 13
v Peu de problème technique
v Les Apis ont été construites en mode « basique » et initialement pour un seul client. Elles ne
sont pas étanches, un étranger ne peut pas se connecter mais un utilisateur peut voir, à
condition de disposer de la référence du capteur, les données d’un capteur qui ne lui
appartient pas.
v Nous préconisons de passer sur la nouvelle version de l’APIM qui offrira de nouvelles
fonctionnalités et notamment la simplification de la connexion tout en offrant l’étanchéité
(avec reprise des développements)
v Nous préconisons également d’étendre l’utilisation du gestionnaire d’identité à l’ensemble
des outils de [CONFIDENTIEL] :
Api- Manager
DataScan
Datagraph
PROBLÈMES SUR L’API MANAGEMENT

14. 5. Le collecteur

15. 15
v Importer les informations de Tuffigo
et de Galizen, les consolider puis les
exporter vers SnowFlake
Galizen toutes les heure et tous les jours
Tuffigo tous les ¼ heure et tous les jours
v L’export se fait tous les jours sous
forme de fichier (alors qu’initalement
ce fut demandé à la mesure).
v Le collecteur est lié à un client de
[CONFIDENTIEL] le « Groupe Michel »,
c’est une des raisons pour laquelle il
n’est pas intégré à la chaine IOT.
OBJECTIFS

16. 16
v Peu de problème technique si on enlève les incidents liés aux certificats
v Des pannes de certificats chez le fournisseurs d’APIs qui ont nécessité de créer des
procédures de reprises de données, ces changements ne sont pas anticipés.
v Pas d’environnement de test
v Pas de spécifications précises, on nous a dit textuellement « on avance en marchant »
v Urgence puis plus aucune nouvelle
v Changement des Postulats de départ.
v Commande de 3 flux et on en a fait 4 !
v Un 5eme flux est en attente de commande SKOV.
v Aucune recette de la part de [CONFIDENTIEL].
v Le serveur du collecteur est un serveur dédié, car les procédures sont lourdes et on
avançait délicatement.
PROBLÈMES SUR LE COLLECTOR

17. 6. Datagraf

18. 18
v Cet outil est basé sur la stack logiciel
Telegraf/Influxdb/Grafana ainsi que le système de
Queue Kafka et le Stream Processor de WSO2.
OBJECTIFS
v Il a deux objectifs :
Nous permettre de suivre les serveurs, leurs capacités, leur problèmes…
o Avec des tableaux dont la propriété est à ExtraFlow, mais qui peuvent être cédés.
Permettre à [CONFIDENTIEL] de vendre des tableaux complémentaires à
DataScan, comme pour le groupe Michel où il est possible de visualiser des
informations techniques comme le RSSI et le SNR des capteurs et des Gateways.

19. 19
v Peu de problème technique
v Dans le cadre du groupe Michel un tableau avec les 110 Elevage avait été demandé, mais
Le groupe Michel n’a jamais pu fournir cette liste. Nous avons donc décidé de réaliser un
ensemble d’ APIs qui permet de créer les tableaux à partir de DataScan. Pour le moment
seul « Extraflow » peut activer cette création. Nous allons donner les droits à
[CONFIDENTIEL] sur DataScan, uniquement pour le « groupe Michel ». Un ticket existe à cet
effet car il reste certains choix techniques à prendre et une adaptation à réaliser (qu’une
fois de plus nous prendrons à notre charge).
Nous avons fait une proposition pour une vente globale de cette fonctionnalités afin de l’étendre à tout
groupement de [CONFIDENTIEL], pour 4090 €, ce fut refusé par [CONFIDENTIEL].
PROBLÈMES SUR DATAGRAPH

20. 7. DataScan

21. 21
v Cet outil est basé sur le logiciel PIMCORE dont
DATASOLUTION est le partenaire Stratégique en
France.
v Il permet d’administrer la chaine IOT pour
[CONFIDENTIEL] et de visualiser les données pour
les clients de [CONFIDENTIEL].
OBJECTIFS
v Il offre un Back-office, celui de Pimcore, pour tout le paramétrage technique
et un Front-Office, celui de Datascan pour le paramétrage fonctionnel
v Il pilote entièrement la chaine IOT par APIs.
v Il est développée en responsive design afin de s’adapter aux écrans des
tablettes et des smartphones.

22. 22
v Il permet de gérer :
Les groupements
Les capteurs
Les sites=>bâtiments=>Salles
Les utilisateurs
La visualisation et les affectations des alertes.
v Un mode spécial pour les éleveurs leur permet de visualiser un
tableau de bord dédié.
v Pour accélérer les affichages on utilise une API qui met les données
en cache.
OBJECTIFS

23. 23
v L’environnement de Qualification n’est plus à jour, il serait bon de recopier et anonymiser la Production,
mais cela implique une recopie également des données de la chaine IOT.
v Le problème majeur ce sont les spécifications que nous n’interprétons pas comme le souhaite
[CONFIDENTIEL], on a cependant des tickets en cours.
v La fluctuation du modèle de données, on dispose à ce jour encore de peu de données il est envisageable
de tout reprendre afin de remettre les données à plat.
v Il manque quelques APIs pour les échanges entre Datascan et la CIOT, notamment la suppression d’un
capteur dans la chaine IOT.
v Il manque un système de notification interne à Datascan, plus claire, dans la cas ou Datascan ne pourrait
pas envoyer ses informations à la CIOT
v Une gestion des alertes passées, et une meilleure gestion de l’affichage des alertes.
v Il est remonté un manque de performance mais une fois que la gestion des alertes sera reprise et après
quelques ajustements, je pense que la vitesse sera plus rapide..
v Un Bug de TTN ne nous permet pas d’activer les gateways enregistrées automatiquement sur TTN (Amiel
Lavon conscient de ce bug et de notre incapacité à conclure devait se renseigner auprès d’autres
fournisseurs de [CONFIDENTIEL])
PROBLÈMES SUR DATASCAN

24. 8 Budgets

25. 25
BUDGETS
Type/an 2018 2019 2020
RUN 4 415,00 € 8 809,00 € 10 300,00 €
BUIILD 26 302,00 € 73 936,00 € 10 000,00 €
v Pour réaliser l’ensemble des travaux présentés dans ce document.
v L’année 2020, il s’agit du compte réversibilité, de la TMA et un reliquat
de factures de 2019.
v ExtraFlow n’a pas gagné d’argent sur ce projet, mais celui-ci a
également servi de moteur à son développement.
v Pour exemple les 56 APIs de connexions entre la CIOT et DataScan
réalisées on été facturées moins de 15000 euros. Soit 270 € l’API!

26. 9.Actions

27. 27
v Il reste un certain nombre de tickets à écouler environ une petite dizaine d’anomalies sont encore
présentes, les autre tickets sont des évolutions ou nécessitent une intervention de votre part.
Dont un seul pose un vrai problème car il n’est pas ré solvable sans l’aide de TTN (ticket 396)
v Nous avons repris une phase de tests complète des alertes depuis le 1er Mai.
v Reprise des projets avec Mr Latry, première réunion le 5/05, il reste à trouver le cadre contractuel.
v Suite à la réunion du 23 Avril, des réponses aux questions ont été apportées mais nous sommes toujours
en attente de vos choix (au 6/05 19:00)
ACTIONS EN COURS

28. 28
v La mise en place d’un système de notification pour tous les « outils », comme OneSignal
v Uniformiser les accès à l’ensemble des ressources en utilisant WSO2 Identity server
v Migrer sur la nouvelle version de la Chaine IOT.
v Ajouter un fournisseur (SKOV) sur le « collecteur »
v Lancer une campagne de test sur les Alertes. (en cours)
v Construire un contrat d’hébergement ou reconstruction d’un environnement chez Altenov et MCO chez
DATASOLUTION en attendant votre autonomie.
v Construire un contrat de TMA au temps passé.
v Mettre en place un environnement de tests/qualité/qualification/préprod et le faire vivre.
ACTIONS A METTRE EN OEUVRE

29. 29
v Installer un processus de recette.
v Définir des spécifications.
v Améliorer la documentation.
v Augmenter le nombre de tableaux de bord pertinents
v Migrer le serveur Datascan dans une version plus récente de PIMCORE
v Ajouter des fonctions de publishing pour la diffusion des mesures
v Améliorer la formation des utilisateurs et notamment au travers du Back-Office de Pimcore
v Basculer les processus de Mise à jour en Asynchrone entre DataScan et la chaine IOT.
v Clôturer les tickets d’anomalies et d’évolution sur le redmine
v Créer un réseau Lora, comme proposé il y a un an et demandé par [CONFIDENTIEL], [CONFIDENTIEL]
serait alors maitre de l’ensemble de la chaine.
v Enregistrer les Alertes / Mesures dans Une BlockChain afin de les Notariser.
ACTIONS A METTRE EN OEUVRE

30. Annexes

31. Liste des APIs

32. 32
v Lorsque le projet a été lancé il était tourné vers un constructeur de capteur qui ne proposait que deux
types de mesures par message, on s’est donc calé sur cette dimension. Il est ensuite apparu que des
capteurs pourraient disposer de dizaines de type de mesures. Pour le moment seul deux mesures sont
significatives, les autres sont accessibles mais ne peuvent donner lieu à des alertes ou des affichage sous
forme de graphe dans DataScan.
v Dans la CIOT il y a deux concepts « Profils de capteur » et « Capteurs » dans la cadre du POC c’était
suffisant. Mais lors de la généralisation on se rend compte qu’il manque une dimension, le «Type de
capteur ».
Le type est directement importé des informations des constructeurs, son algorithme de décodage, la typologie des mesures, etc..
Le profil lui rassemble les informations qui le spécifie pour un client. Le profil des « capteurs de réfrigérateur » qui comportera les
données de seuils, les donnés d’affichage. Mais aussi de transformations exemple de °C et °F.
Enfin le capteur lui même qui pourra avoir des données propres comme sa fréquence d’émission,
v Dans la nouvelle version que nous avons construite ces différentes notions existent. Enfin nous incluons
également l’abonnement à des « queues » directement et non plus uniquement par réception de message
au format http.
LES RAISONS QUI FONT DE CIOT UN POC

33. 33
Tableaux de suivis

34. SIÈGE PARISIEN
224 rue du Faubourg Saint Antoine
75012 PARIS
+33 (0)1 83 79 02 05
www.datasolution.fr