Technologies

Les objets connectés au service des entreprises

Les objets connectés au service des entreprises
Jacques Rebérol (GRTgaz, à gauche) et Thomas Fournier (Groupe Identicar) ont présenté leurs usages des objets connectés à l'invitation de MC2I.

A l'invitation de MC2I le 14 juin 2016 à Paris, Jacques Rebérol (GRTgaz) et Thomas Fournier (Groupe Identicar) ont témoigné du rôle des objets connectés dans leurs entreprises respectives.

PublicitéLe 14 juin 2016 lors d'une matinée Le virage des objets intelligents connectés, la SSII MC2I a invité à témoigner deux entreprises. Jacques Rebérol, chargé de mission à la DSI de GRTgaz, et Thomas Fournier, DSI du Groupe Identicar, ont ainsi expliqué le rôle des objets connectés dans leurs entreprises. Mais ils ont aussi explicité les questions architecturales induites.
Contrairement à ce que certains consultants persistent à penser, les objets connectés ne sont pas une nouveauté en eux-mêmes. Au sein du Groupe Identicar, il existe des boîtiers de tracking de véhicules depuis une bonne quinzaine d'années. Ce groupe est en effet spécialisé dans la sécurité des véhicules (via la gravure des vitres par exemple) et divers services connexes comme l'assurance. Mais les technologies changent et les données exploitables s'enrichissent.

Des télécoms à la donnée informatique

Les boîtiers haut de gamme de suivi -commercialisés sous la marque Vodafone- sont branchés sur la batterie, installés et dissimulés par des professionnels. La géolocalisation par GPS est l'objet d'un dialogue par SMS avec le système central où réside la valeur du service. Au fil du temps, le boîtier a été amélioré, permettant une coupure du moteur à distance (via l'ordinateur de bord) sur une alerte de vol par exemple.
Mais le nouveau boîtier low cost WeTrack fonctionne sur des principes techniques comme business bien différents. Bien entendu, il y a toujours une géolocalisation GPS. Mais il existe aussi d'autres capteurs comme un accéléromètre ou un thermomètre. 90% de son volume (et de son poids) est constitué par les piles car le boîtier est autonome durant environ un an, évitant d'avoir à le faire poser par un professionnel (il suffit de le dissimuler dans une trappe quelconque). Il se connecte par GPRS. « Les réseaux de type Sigfox/Lora posent encore des problèmes de couverture ainsi que de bande passante pour les mises-à-jour » a observé Thomas Fournier.

La valeur est dans la donnée

La valeur réside dans les services tirés des données transmises. L'accéléromètre a initialement été prévu pour réaliser une détection de choc. En tel cas, l'assistance se déclenche immédiatement avec une géolocalisation du véhicule en détresse. Mais les données d'accélération/décélération peuvent être aussi utilisées pour une analyse du comportement du conducteur. Cette analyse permet d'adapter l'offre d'assurance. On est dès lors bien loin de la seule sécurité anti-vol ou même de la tout autant classique gestion de flotte de véhicules.
Logiquement, le risque réside aussi dans les données transmises. Ce sont indirectement des données personnelles très sensibles permettant de connaître les déplacements d'individus. Dans l'autre sens, l'objet peut être contrôlé à distance par un piratage de la transmission, comme une automobile dont on pourrait couper le moteur par exemple. Une attaque DDOS pourrait éventuellement bloquer le système mais la chose aurait un intérêt limité et n'a, de toutes façons, jamais été constatée.
Les risques sur les données personnelles sont tels que la CNIL est très vigilante. Ses recommandations comprennent donc notamment des obligations de destruction de données anciennes. Cela gêne l'étude d'historiques pour une analyse comportementale. Pour Thomas Fournier, « une parade est d'opérer des traitements en local dans le boîtier avant de transmettre des agrégats moins sensibles. »

PublicitéDes développements mixtes

Les volumes de données sont suffisamment faibles pour éviter d'avoir à se lancer dans des projets Big Data : une banale base SQLserver suffit amplement. Les problèmes techniques sont ailleurs. Et pas tellement dans chaque élément du projet mais plutôt dans l'agencement et la synchronisation de chaque élément. En effet, qui dit objet connecté dit objet matériel d'un côté et logiciel de l'autre. « Je ne peux pas faire du développement itératif sur un objet en me disant que je vais rajouter un transistor ici ou là ou faire évoluer le firmware tous les quatre matins » a souligné Thomas Fournier. Pour le boîtier, le principe est donc le « one-shot » avec ceinture et bretelles car il ne peut être question de rappeler tous les boîtiers chez les clients sans arrêt. Thomas Fournier explique une astuce : « il faut essayer de mettre le maximum de choses sous forme de paramètres faciles à mettre à jour à distance. »
La première étape est donc architecturale : il s'agit de clairement identifier ce qui va relever de l'objet, de la collecte-transmission et du back-office-datacenter. Chez Identicar, toute l'intelligence du traitement est dans le back-office, dans le datacenter. C'est plus complexe juridiquement mais évite les problèmes de mises-à-jour logicielles du boîtier, celui-ci restant avec des tâches basiques.

Pas facile de débuguer

Si le développement agile est totalement exclu pour le boîtier, Identicar utilise Scrum pour le développement des logiciels de back-office. A l'inverse, pour les boîtiers, les tests sont très approfondis pour éviter les soucis une fois déployés. Il s'agit de tester le boîtier isolé, puis dans le système en laboratoire puis sur le terrain réel, avec les problèmes éventuels de transmission dans les zones isolées.
Comme il y a peu d'indications sur un boîtier, certaines astuces peuvent surprendre, comme le fait de faire faire du Morse au logiciel embarqué avec la LED du témoin d'allumage pour donner des retours. Il est en effet souvent difficile de déterminer si un bug a une origine matérielle, logicielle ou mixte. Il faut aussi faire une montée en charge progressive, non seulement à cause de la problème de scalabilité du système informatique mais aussi pour une problématique industrielle : en grande série, les tolérances techniques des boîtiers peuvent être différentes du mode artisanal, induisant des bugs.
Thomas Fournier a terminé par trois recommandations : « d'abord, il faut une boucle de feed-back ; ensuite, il faut associer dans un même travail l'IT et le marketing ; enfin, il faut rapprocher les équipes techniques et celles du marketing. »

Des objectifs industriels

Si les objets connectés pour un usage au sein d'une large population sont assez bien connus, les utilisations industrielles ne sont pas moins intéressantes. Elles sont juste moins visibles. Par exemple, chez GRTgaz, la visibilité des installations n'est pas vraiment l'objectif. Gestionnaire du réseau de transport du gaz naturel, il opère plus de 32 000 kilomètres de canalisations de plus de 80 cm de diamètre entre d'une part les terminaux méthaniers portuaires et les points d'accès aux frontières du pays, d'autre part les réseaux locaux, gérés ou non par GRDF. GRTgaz dispose ainsi de 130 clients parmi lesquels EDF, GDF, 768 industriels gros consommateurs (dont 12 centrales électriques à gaz), 19 gestionnaires de réseaux locaux (comme GRDF) etc. Sur le territoire national, il dispose également de 27 stations de compression.
Le principal enjeu métier de GRTgaz est l'équilibrage des pressions dans le réseau. L'entreprise a eu recours aux objets connectés pour garantir cet équilibrage et informer tous ses clients dans un délai maximum de dix minutes. L'équilibrage concerne également la qualité calorifique du gaz, variable selon sa source (Algérie, Russie, etc.). « Lors d'un séminaire de direction sur L'Âge de la Donnée, il a été décidé de profiter du projet pour exploiter les données disponibles pour un maximum de finalités, par exemple la maintenance des installations » a relaté Jacques Rebérol. Les scénarios concernent donc bien sûr l'équilibrage mais aussi la maintenance et les télétransmissions. L'accès à distance aux installations (sécurisé !) permet bien sûr le télédiagnostic et la télémaintenance.

Une architecture complexe au service d'objectifs métiers multiples

L'architecture cible part du terrain. Les objets y sont de plusieurs sortes : compteurs, capteurs, calculatrices, chromatographes (analyse du gaz), compresseurs, etc. Les données mesurées sont ensuite télétransmises par 4G (à terme : 5G), fibre, ADSL, Lora ou, au pire, satellite (solution la plus chère réservée aux sites totalement isolés). Une plate-forme IoT va alors agréger les données des objets et les rapprocher de données tierces (SIG, GMAO...). Ces données vont être exposées au travers d'API avant d'être utilisées par des applications métier de gestion de l'énergie, de facturation, de pilotage, de surveillance, etc. Des services peuvent être associés : par exemple une aide à l'optimisation de al consommation. Parmi les applications, il en existe qui simulent des données pour éviter de les mesurer. « Mesurer coûte cher et la qualité de la mesure n'amène pas toujours un meilleur résultat que la simulation » a relevé Jacques Rebérol. Surtout que les métiers demandent de plus en plus de capteurs et de mesures...
Les objectifs de la collecte des données peuvent être multiples, tant internes qu'externes. La démarche baptisée Smart poursuit ainsi d'une part des objectifs de performance opérationnelle, de dé-silotage du SI, d'adaptation intelligence des infrastructures IT, d'autre part de services aux clients et partenaires, d'innovation en lien avec la transformation du marché et de politique de développement durable.

L'écueil du RTC

A l'heure actuelle, certains équipements sont reliés par la ligne téléphonique RTC (réseau téléphonique commuté). Cette ligne porte un courant électrique de 48V qui sert parfois à alimenter énergétiquement des capteurs. La fin du RTC, entre 2018 (fin de commercialisation) et 2021 (début de démantèlement), va amener un besoin d'alimentation autonome pour les objets connectés. L'alimentation par panneau solaire n'est pas toujours idéale. Jacques Rebérol a soupiré : « les chasseurs aiment tirer sur nos panneaux solaires au sommet des mats ». Il s'agit également de basculer du RTC avec protocole propriétaire Modbus au TCP/IP sur réseaux banalisés et diversifiés. Outre les délais contraintes imposés par Orange, ce chantier entraînera des coûts de travaux de génie civil et ne devra pas être mené sans garantir que soit maintenue une qualité optimale du service.

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis