Article Automatisation des bâtiments , ICT

Quand l’informatique rencontre l’immotique

Pourquoi une telle incompréhension?

26.02.2018

Le monde de l’informatique s’intéresse de plus en plus au bâtiment. Or, quand ces deux mondes se rencontrent, cela fait des étincelles: ils ne se comprennent pas. Pire, ils ne se respectent pas. Pourquoi une telle incompréhension? Comment surmonter ce problème dans l’intérêt commun des filières, mais surtout du client final?

Pour commencer, un postulat simple et factuel: l’informatique (IT) a réussi l’interopérabilité ultime avec IP (Internet protocol) alors que le monde de la MCR (mesure contrôle régulation) ou de la GTB (gestion technique de bâtiment) en est encore à jongler avec une myriade de protocoles intrinsèquement interopérables et standard, mais non unifiés dans un bâtiment. Là où tous les équipements informatiques sont sur IP – branchés sur le même média et échangent sur le même protocole – les équipements de gestion technique de bâtiment sont hétérogènes: la production de chaud ou de froid et la ventilation communiquent en BACnet (building automation and control networks), les régulations terminales en LonWorks (local operating network), les contrôleurs d’équipements électriques en KNX, des compteurs en Modbus, voire en M-Bus (meter-bus), certains capteurs en EnOcean ou Lora, etc.

L’informatique a touché le Graal de l’interopérabilité pendant que le monde de la GTB en est encore à essayer d’aboutir à une table ronde uniforme… De fait, bien des acteurs de l’informatique ne comprennent pas le monde du bâtiment. Ils dénigrent cette filière, donnent des leçons et font preuve d’arrogance. En conséquence, le métier du bâtiment les regarde de haut en souriant en coin et en murmurant: «Viens-y mon ami, tu vas t’y casser les dents, tu ne sais même pas de quoi tu parles»… Peu constructif, direz-vous… Essayons d’enterrer la hache de guerre et de comprendre pourquoi une telle différence existe.

Un peu d’histoire

Les premiers réseaux industriels à interopérabilité minimale sont apparus dans le monde de l’industrie à la fin des années 70. Des protocoles comme Modbus et Jbus sont ainsi devenus populaires. D’autres, nés dans la foulée, comme CAN (controller area network), furent happés par l’industrie (automobile). À cette époque, quid des réseaux informatiques hors des réseaux d’initiés?

Ces protocoles sont orientés contrôle-commande et non échange/partage de données. Ainsi, Modbus est un protocole client-serveur totalement inadapté à l’informatique: le contrôle-commande nécessite fiabilité et simplicité, et non vitesse de communication et bande passante.

Trois standards de réseau de contrôle-commande associés au bâtiment ont ensuite fait leur apparition vers la fin des années 80, en 1987 plus précisément: EIBus (European installation bus), LonWorks et BACnet.

EIBus a été créé en Europe par des constructeurs actifs dans le domaine de l’automation des bâtiments dans l’objectif de réaliser des réseaux de produits multiconstructeurs. Il a particulièrement été accepté par les industriels allemands et suisses dans le monde de l’électricité, alors que la France a opté pour Batibus. En 1999 a eu lieu une convergence entre Batibus, EIBus et EHS (European home systems protocol) en une organisation d’abord appelée Konnex, puis KNX. Les fondateurs d’EIBus ont voulu garder une installation à travers un outil d’intégration unique ETS qui inclut la base de données des produits KNX du marché et garantit ainsi l’interopérabilité. La base de cette technologie est de pouvoir faire des liens «peer-to-peer», c’est-à-dire de point terrain à point terrain, et KNX excelle dans cette tâche. Par contre, la partie supervision et réseau a été occultée à la création de ce protocole. D’ailleurs, l’encapsulation de KNX sur IP a été tardive par rapport aux autres réseaux. Normal, direz-vous, cela venait d’une filière de contrôle-commande et, à l’époque, les réseaux IP n’étaient pas courants. De fait, EIBus, et ensuite KNX, sont très présents dans le monde de l’électricité, notamment dans leurs régions d’origine.

Le protocole LonWorks a également été créé en 1987, mais par une société indépendante américaine: Echelon Corporation. Cette société a souhaité créer un protocole de communication indépendant en termes de constructeurs et de filières. L’un de ses fondateurs est Mike Markkula, n° 3 d’Apple après Steve Wozniak et Steve Jobs. L’ADN de cette société était plus axé informatique, réseau, IT, etc. que bâtiment. Celle-ci souhaitait également créer un réseau de contrôle-commande totalement distribué avec, là encore, une volonté de liaison «peer-to-peer», mais avec une dimension réseau supplémentaire. Par exemple, là où KNX ne propose qu’un «groupe» comme lien entre les équipements, LonWorks propose un «binding» (liaison) avec des modes de propagation réseau (Unicast, Multicast, Broadcast), capable d’effectuer des routages et ainsi de segmenter des réseaux, d’établir des plages d’adresses et de s’attaquer à des réseaux bien plus grands en nombre de produits en réseau. De fait, LonWorks fut adopté par les industriels ayant un grand nombre d’équipements connectés, tels que le HVAC (heating, ventilation and air conditioning) en régulation terminale. Son encapsulation sur IP fut très rapide, car il avait été pensé en ce sens.

Le protocole BACnet est lui aussi américain, né en 1987, mais il est supporté par un syndicat de sociétés dans le monde du HVAC: l’Ashrae (American society of heating, refrigerating and air-conditioning engineers). Ce syndicat a créé un groupe de travail, le SPC 135, dans le but d’harmoniser les solutions HVAC et de rendre leurs supervisions interopérables et exploitables en grappes. À cette époque, les gros industriels HVAC possèdent leur propre protocole propriétaire et ce groupe de travail est créé pour proposer une interface commune de supervision et d’échange de données. Aucun des protocoles propriétaires ne peut être choisi. De ce fait, l’Ashrae crée un métaprotocole: BACnet. Ce protocole n’a aucune vocation à faire des liens «peer-to-peer». Il doit uniformiser la supervision de systèmes de constructeurs différents sur des protocoles différents, soit au sein d’un même site, soit en multisite. Il est donc organisé pour travailler sur tous les supports physiques de communication des solutions propriétaires: ARCnet (attached resource computer network), Ethernet, RS232, RS485 et UDP (user datagram protocol). Mais surtout, il apporte la totalité des fonctions nécessaires à une supervision centrale interopérable en embarquant des objets archivage, alarme et plage horaires, le rendant supérieur en matière de supervision.

À la lumière de ces informations, les positionnements des protocoles s’éclaircissent. KNX offre une excellente interopérabilité terrain, il est fort en Allemagne et en Suisse et il est adopté dans le secteur électrique. LonWorks propose également une excellente interopérabilité terrain, mais il est plus utilisé dans la filière HVAC, dans de grands réseaux. BACnet, quant à lui, est plus fort en matière de supervision et de lien de protocoles propriétaires, car il a été créé pour cela. Comme, de surcroît, il appartient à la filière HVAC, les automates de production l’ont adopté.

Des notions différentes de l’interopérabilité

Face à cette myriade de protocoles, l’IT se gausse, mais en fait elle ne comprend pas la problématique. L’interopérabilité IT n’est pas la même que celle du contrôle-commande. L’IT a peu de types (integer, Boolean, string, real, etc.), alors que Lon ou KNX en a plus de 200! En effet, lorsqu’il s’agit d’effectuer des liens peer-to-peer, le récepteur doit recevoir de l’émetteur, et être à même de comprendre non seulement la valeur, mais aussi l’unité… Si l’on travaille avec un capteur russe, un actionneur anglais et une supervision française, que se passe-t-il si l’on envoie une valeur en «real» avec une sonde en kelvin, un actionneur en Fahrenheit et une supervision en Celcius?

De fait, en MCR, l’interopérabilité doit monter au niveau de la définition du datamodel, c’est-à-dire de la structure des données. La filière est même allée plus loin en créant des profils fonctionnels, soit des profils définissant la fonction des différents objets. Le profil fonctionnel d’une lampe à variation d’intensité pourra, par exemple, être utilisé pour toutes les lampes à variations d’intensité, mais sera différent de celui utilisé pour une lampe «on/off». Il est fondamental que la filière informatique comprenne cette différence essentielle en matière de notion d’inter­opérabilité. D’ailleurs, elle tâte cette problématique du bout des doigts en travaillant sur l’interopérabilité de l’IoT… Le protocole Thread en fait les frais, comme ZigBee en a fait les frais avant lui: leur manque d’interopérabilité ne leur a pas permis, mis à part dans le domaine de l’éclairage pour ZigBee, de se déployer à grande échelle. Il a fallu des années pour créer des data­models et profils fonctionnels acceptés par les différents industriels du domaine déjà bien établis sur leurs marchés.

L’autre différence importante est résumée dans un terme anglo-saxon particulièrement bien adapté: legacy. Il s’agit de l’existant, de l’héritage, voire du boulet que l’on traîne. Le bâtiment a un existant titanesque et les constructeurs se doivent de veiller de surcroît à une compatibilité ascendante. Depuis la fin des années 1970, il existe des automates dans des bâtiments communiquant avec des protocoles divers et variés. Depuis des années, des constructeurs fabriquent des produits dont le cœur de métier est de bien réguler et pas de bien communiquer. Face à ceci, l’informatique est une technologie jeune, sans réel existant, encombrante, dopée par les marchés du «consumer» et du B2C (business to consumer, des entreprises aux particuliers). L’IT a seulement eu à «tuer» X25 et à fléchir le lobby télécom pour tendre vers l’interopérabilité. Si l’on met en perspective avec ce que devrait «tuer» l’industrie du bâtiment…

Le dernier point de divergence est celui qui fait le plus mal: la durée de vie d’un bâtiment est de 40 ans, la durée de vie en IT est de 3 ans. Comment faire coexister ces différences? Comment faire monter une tortue dans un TGV lancé à pleine vitesse? Ou plutôt, comment faire monter un troupeau de tortues qui ne parlent pas le même langage et qui ne vont pas à la même vitesse dans ce même TGV? Il s’agit là du cœur du problème. Comment rendre un bâtiment qui a 40 ans d’existence dépareillée interopérable avec l’IT?

Une réconciliation nécessaire dans l’intérêt global

Or, il faut que l’IT et le secteur du bâtiment se comprennent et se respectent! Cette compréhension est indispensable dans un monde où le bâtiment est non seulement intelligent, mais devient smart, c’est-à-dire intelligent, mais surtout connecté et communiquant vers des services. Le smart building nécessite une rencontre entre les métiers traditionnels du bâtiment, comme le HVAC, le courant faible, le courant fort, le contrôle d’accès, etc., et ceux de l’informatique et des réseaux de communication. Le nombre d’équipements connectés à un réseau intelligent intrabâtiment va croître de façon exponentielle. Les automates conventionnels de MCR ne représenteront qu’une part des équipements de ce réseau. Bien d’autres capteurs et actionneurs devront s’y connecter.

Il faut donc repenser notre mode de fonctionnement, notre modèle d’affaires, notre positionnement, notre canal au marché, car les mondes qui rencontrent la vague numérique en prennent les modèles d’affaires. Qui peut sincèrement penser qu’un réseau informatique peut être composé uniquement d’équipements d’une seule marque? Il faudrait que celle-ci propose la totalité des équipements connectables sur IP (PC, téléphones, imprimantes, photocopieurs, machines à café, badgeuses, etc.)… Impossible! La MCR et la GTB subiront la même règle et ceci va fortement impacter la filière traditionnelle HVAC, reine de la MCR. Il est illusoire de penser qu’une marque pourra offrir la totalité des capteurs et actionneurs nécessaires. Nous entrons dans un monde intégré où il faut pouvoir, comme en IT, déployer tout produit de toute marque pour faire un réseau, c’est-à-dire une solution où les échanges de données sont inter­opérables et offrent in fine une solution globale.

C’est en vue de cet objectif que le groupe ABB propose des solutions de GTB agnostiques en termes de marque et de protocole, connectables vers tout service tiers. Toutefois, notre filière doit également se mélanger avec les filières de l’IT et de l’énergie, comme le propose l’association SBA (Smart building alliance for smart cities) en France, et proposer un label d’inter­opérabilité et de garantie de connectabilité à des services tiers: le label R2S (ready to services).

Notre monde va recevoir de plein fouet la vague numérique. Cette dernière a d’ailleurs déjà touché quelques côtes (les taxis, les hôtels, etc.). Le monde du bâtiment ne sera pas épargné et ce tsunami approche du rivage. Donc, soit les industriels de la MCR se mettent en ordre de marche pour surfer sur la vague, soit ils resteront statiques face à elle, hypnotisés et figés par la masse arrivant à pleine vitesse… Agissons et ne subissons pas la disruption imposée, dans le respect de la maîtrise d’ouvrage et des preneurs ou locataires.

Smart Home 2018

15 mars 2018, Lausanne

L’auteur de cet article sera l’un des intervenants qui feront part de leurs connaissances et expériences à l’occasion du forum Smart Home 2018. Un programme riche et varié attend les participants. Il y sera notamment question d’optimisation de la consommation énergétique, de l’évolution du marché de la technique du bâtiment et des futures opportunités. Le rôle de plus en plus important de l’informatique dans ce domaine sera également discuté, tout comme les conséquences qui en résultent en matière de planification et pour l’installateur. La question de la sécurité des données personnelles fera, quant à elle, l’objet de l’intégralité d’une session. Le forum Smart Home 2018 propose en outre aux professionnels de la domotique un tour d’horizon des systèmes actuels ainsi que de nombreuses démonstrations à découvrir en visitant les divers stands de l’exposition accompagnante.

www.electrosuisse.ch/smart-home-2018

Auteur
Serge Le Men

est vice-président et cofondateur de l’association Smart buildings alliance for smart cities et responsable Solutions smartbuildings Newron chez ABB.

  • ABB France
    F-31100 Toulouse

Commentaire

Veuillez calculer 2 plus 8.