Il y a un problème avec la technologie dans notre secteur. Nous sommes entourés de systèmes et d'appareils intelligents tout au long de la journée, une technologie qui a transformé nos expériences quotidiennes, mais la plupart des systèmes de notre environnement bâti sont entravés, restreints, conçus comme des maillons isolés d'une chaîne plutôt que comme un réseau de plateformes coopératives. Cette philosophie est obsolète et a conduit à une stagnation du marché, rempli d'appareils merveilleux qui, tout simplement, « ne fonctionnent pas ». Considérez les deux scénarios suivants :

Il est 7h du matin par une froide journée d'hiver. Vous êtes le premier arrivé au bureau. Vous cherchez votre carte d'accès dans votre portefeuille, vous la présentez pour entrer dans le bâtiment, montrez votre badge à la sécurité, puis appelez un ascenseur qui met une minute ou deux à arriver. En atteignant votre étage, faiblement éclairé par des lumières de sécurité standard, vous tâtonnez dans une obscurité quasi totale jusqu'à ce que vous trouviez l'interrupteur. « Il fait froid ! » marmonnez-vous, tout en entendant (en arrière-plan) le grondement du système de chauffage qui se met en marche pour la journée.

Cela semble assez simple. Très bien, considérez maintenant ceci :

Il est 7h du matin par une froide journée d'hiver. Vous êtes le premier arrivé au bureau. Vous franchissez la porte d'entrée, passez devant la sécurité — en traversant le système de reconnaissance faciale automatique — et vous vous dirigez vers les ascenseurs. L'ascenseur, qui vous attendait déjà, vous emmène à votre étage où les lumières de votre bureau sont déjà allumées et où le système CVC a réglé la température selon vos préférences. Pas besoin de tâtonner ou de chercher : le bâtiment a automatiquement pris en charge les tâches routinières nécessaires. Au lieu de cela, vous pouvez vous mettre directement au travail (ou, d'abord, à la machine à café).

Toutes les différences clés entre ces deux scénarios reposent sur l'interaction de l'utilisateur et la nécessité d'interagir avec un élément spécifique du bâtiment, comme l'interrupteur. Dans l'approche la plus automatisée et fluide, plusieurs systèmes de bâtiment interconnectés ont coopéré pour rendre votre vie et vos interactions plus faciles, plus rapides et plus fiables, allant même jusqu'à supprimer le besoin de certaines de ces étapes. Pensez aux différents systèmes en jeu dans ce scénario : systèmes de sécurité physiques et numériques, contrôle des ascenseurs, intégration du CVC et de l'éclairage — tous des systèmes de bâtiment standard — fonctionnant normalement indépendamment les uns des autres, mais qui, une fois combinés, servent à créer une expérience utilisateur plus complète et plus fluide. Comment passer du présent à un avenir où le second scénario est courant, et aller encore plus loin ? Comment est-ce que quelque chose comme cela pourrait fonctionner ? Une « infrastructure intelligente » est-elle seulement possible ?

Un écosystème plus intelligent

Chez TEECOMlabs, nous essayons constamment d'imaginer l'avenir de l'environnement bâti. Nous observons un paysage en constante évolution au sein d'un secteur qui reste passivement immobile, mais qui a le potentiel de lancer des tendances, d'améliorer notre façon d'utiliser notre environnement, d'innover et de susciter des percées majeures dans la manière dont nous interagissons quotidiennement avec notre entourage. Nous imaginons des bâtiments qui intègrent des solutions fluides centrées sur l'utilisateur par défaut, et non comme des fonctionnalités ajoutées ou « premium ». Dans cette vision, les bâtiments, les campus et même les organisations multi-sites à grande échelle auront une connaissance et un contrôle complets de tous leurs composants, capables d'un fonctionnement autonome grâce à des comportements intuitifs et auto-correcteurs.

Des plateformes logicielles intégrées à l'infrastructure physique permettront aux sites de se gérer eux-mêmes à grande échelle, bien au-delà de la capacité humaine manuelle. En d'autres termes, un contrôleur logiciel intelligent qui orchestre l'infrastructure physique et numérique d'un bâtiment sera un composant standard et nécessaire de cette architecture. Cette conception de matériel et de logiciels auto-suffisants dépend de la connexion entre tous les systèmes du bâtiment. Mais plus important encore, elle nécessite l'utilisation de plateformes conçues avec une ouverture à la communication et à l'accessibilité, par exemple la capacité de communiquer librement avec un tel système logiciel intelligent dès le départ. Nous avons qualifié cette mesure de : «Est-ce que cela joue le jeu de la coopération ?»

La plateforme matérielle a-t-elle la capacité d'envoyer et de recevoir des données la concernant ? Peut-elle être contrôlée et gérée à distance ? En somme, est-elle capable de fonctionner comme une partie d'un tout connecté plus vaste ? Ou bien le produit, la plateforme ou le système se cloisonne-t-il, devenant une sorte de « boîte noire » incapable de communiquer efficacement et ouvertement avec d'autres systèmes ? Malheureusement, un certain nombre de plateformes et de produits actuellement commercialisés tombent dans cette catégorie de « boîte noire ». Cela est dû à l'approche en « jardin clos » adoptée par de nombreux fabricants et fournisseurs pour leurs gammes de produits : ils fonctionnent bien avec les équipements de la même marque, mais sont spécifiquement conçus pour ne pas bien fonctionner avec les autres. Que ce choix de conception soit délibéré pour maintenir les utilisateurs dans cet écosystème fermé, ou qu'il résulte indirectement d'une décision de ne pas investir dans le développement d'outils adaptés, le résultat est le même : rien ne communique avec rien. Nous voyons bien le dilemme : pourquoi permettre délibérément à vos clients d'utiliser les produits de vos concurrents ?

Il est parfois difficile d'imaginer un avenir interconnecté car, comme le montre l'état actuel des systèmes d'entreprise, l'interopérabilité n'est pas toujours rentable. Alors, pourquoi s'en préoccuper ? Voici pourquoi : dans le scénario du jardin clos, personne n'est gagnant. Les utilisateurs bénéficient d'une expérience médiocre, les fabricants ne sont pas incités à mettre à jour ou à moderniser leurs produits (ils ne le font donc que pour rester compétitifs), et les entreprises sont contraintes d'adopter ces écosystèmes fermés sans nécessairement envisager toutes les options possibles, et probablement meilleures, qui s'offrent à elles. Les fabricants ne devraient pas sacrifier une fonctionnalité (qui devrait être) impérative au détriment de l'expérience utilisateur. Pour rendre les choses encore plus frustrantes, nous avons assisté ces dernières années à une refonte de la communication électronique : de nombreux nouveaux standards (REST, AMQP, SOAP, etc.) ont rendu la communication entre plusieurs appareils extrêmement simple. Et pourtant, malgré tous ces protocoles et API*parmi lesquels choisir, les fabricants ont, dans l'ensemble, soit choisi de croire que la solution logicielle qu'ils ont développée est clairement la meilleure (et évidemment la seule valable), soit simplement choisi d'ignorer totalement ces concepts technologiques.

La coopération est la clé

C'est ici que je lance un appel à l'action : il appartient à nous, acteurs de l'industrie AEC, de pousser tous nos fabricants et fournisseurs vers des plateformes plus ouvertes.Certains de ces systèmes deviennent déjà plus évolutifs, intégrant des technologies intelligentes et des mécanismes de contrôle plus performants, et certains fabricants ont déjà commencé à utiliser des logiciels open source et à intégrer des API avec des spécifications publiques ; il serait dommage de voir des produits avec un tel potentiel rester invendus sur les étagères, simplement parce qu'ils reposent sur des plateformes propriétaires restreintes et/ou ne s'intègrent pas bien avec d'autres systèmes. Il convient également de noter explicitement qu'un fabricant décidant de créer sa propre API avec ses propres protocoles et spécifications, puis de l'intégrer à ses plateformes, n'est PAS la même chose que l'intégration d'API basées sur des spécifications publiques. Ce changement de paradigme ne se fera pas du jour au lendemain, mais pour l'instant, nous devrions commencer par poser aux fabricants les bonnes questions : « Votre plateforme est-elle connectée et sécurisée ? Votre plateforme dispose-t-elle d'une API ouverte ? Est-elle capable de coopérer avec les appareils d'autres fabricants ? » Si la réponse n'est pas systématiquement « Oui », vous devriez peut-être chercher de meilleures options.

L'évolution du « Hub »

En R&D, nous n'attendons pas que le futur s'invente tout seul. Nous voulions une expérience utilisateur fluide et sans friction, de l'automatisation, un écosystème de bâtiment autonome. Et nous le voulions aujourd'hui, pas dans un an ou dans cinq ans. Nous avons donc commencé par une expérience qui nous a permis de constater par nous-mêmes les avantages d'un avenir connecté : une plateforme pour connecter TOUT notre matériel, nos plateformes et nos systèmes afin qu'ils fonctionnent et interagissent de manière coopérative, un pont pour relier toutes sortes de matériels au sein d'un réseau unique, intelligent et performant.

« Alexa, aurais-tu l'amabilité de... ? »

Tout a commencé avec un interrupteur. Dans les bureaux de TEECOM à Oakland, nous utilisons la série Legrand Wattstopper DLM (gestion numérique de l'éclairage) composée d'interrupteurs, de luminaires, de variateurs, de boutons et de câbles interconnectés, le tout relié par un réseau propriétaire, fermé et basse tension. Bien que le système fonctionne normalement comme on pourrait s'y attendre (on appuie sur l'interrupteur, la lumière s'allume), notre objectif était de voir si nous pouvions contrôler le système d'éclairage par commande vocale via Amazon Alexa. Comme par exemple : « Alexa, allume les lumières parce qu'il est 7h du matin, j'ai froid et je n'y vois rien. »Nous avons été confrontés à l'absence d'interface appropriée avec notre système d'éclairage Wattstopper. Le module de contrôle série n'a jamais été conçu pour être une API ; ce n'est rien de plus qu'une simple interface de communication. Nous avons donc installé des ampoules Philips Hue, ce qui nous a apporté des fonctionnalités supplémentaires, une interface davantage axée sur les applications et des capacités incluant la gestion dynamique des couleurs et la température de couleur variable. L'API Philips Hue et le module de contrôle série Legrand Wattstopper (l'interface) n'ayant jamais été conçus pour fonctionner ensemble, nous avons développé une application logicielle pour coupler les systèmes et les connecter à une skill Alexa personnalisée. Nous avons baptisé ce logiciel «LabLight.»

LabLight : le premier grand unificateur

LabLight interrogeait chacun des systèmes d'éclairage, demandait une mise à jour de leur état et maintenait activement une base de données de leur statut. Avec l'introduction de notre « processeur de contexte », il est devenu possible d'utiliser le laboratoire et de faire fonctionner simultanément deux systèmes d'éclairage différents sans avoir à gérer les chevauchements et les conflits (comme se retrouver dans le noir ou être ébloui parce que tous les systèmes étaient allumés à pleine puissance). Le logiciel LabLight est devenu de plus en plus complexe à maintenir à mesure que nous ajoutions des fonctionnalités et intégrions davantage de capteurs, d'appareils et d'équipements déjà présents dans notre laboratoire. Il est vite devenu évident que nous avions besoin de quelque chose de plus adaptable et évolutif pour les applications plus vastes que nous envisagions. Il nous fallait une mise à niveau. Voici : The Hub plateforme.

The Hub : un successeur logique

The Hub est composé d'une plateforme logicielle à trois niveaux.

1. Le niveau le plus bas (le premier), celui des pilotes, est spécialisé pour chaque API avec laquelle nous interagissons (Philips Hue, Brivo ACS, Wattstopper, Liftmaster, etc.).

2. Le deuxième niveau, celui des contrôleurs, relie tous les pilotes au sein d'un domaine particulier (audiovisuel, éclairage, sécurité, réseau, etc.). L'objectif de ce deuxième niveau est de simplifier le code requis pour toutes les applications situées au-dessus, tout en garantissant que tous les pilotes fonctionnent correctement en dessous.

Par exemple, nous disposons d'un contrôleur audiovisuel qui intègre notre processeur de signal numérique (DSP) audio et les différents téléviseurs/écrans du laboratoire, ainsi qu'un contrôleur de sécurité distinct qui gère le système Brivo ACS, la porte de garage et notre système de sécurité. « LabLight » a été réaffecté en tant que contrôleur d'éclairage et se situe également à ce niveau.

3. Le niveau supérieur (le troisième) se compose d'applications qui incluent actuellement notre interface Web, un contrôleur de salle (surveillance et gestion de notre espace de laboratoire), des affichages graphiques, des outils d'automatisation et de reporting, entre autres. De telles applications intègrent des fonctions pouvant nécessiter une interface avec diverses plateformes dans plusieurs domaines. D'un point de vue programmation, cette hiérarchie arborescente est beaucoup plus propre que la construction d'une architecture logicielle « plate ».

Une nouvelle dimension, une nouvelle interface

L'architecture en couches de The Hub a ajouté une nouvelle dimension de capacités au matériel de notre laboratoire. Grâce à la création et à l'utilisation d'applications de haut niveau — capables d'utiliser les informations d'un système pour en contrôler intelligemment un autre — toutes nos plateformes intégrées et nos systèmes de bâtiment sont devenus des composants modulaires d'une machine fonctionnelle globale, plutôt que des rouages et des pièces fonctionnant indépendamment sans organisation centrale. Plutôt qu'un enchevêtrement d'infrastructures faiblement connectées, The Hub a tout relié. Nous pouvions partager des données et gérer intelligemment plusieurs plateformes entre différents domaines — et différents fabricants. Nous pouvions contrôler tous ces systèmes, acquérir leurs données et métriques, et tirer parti des capacités de chacun pour créer de nouveaux usages efficaces.

Un premier exemple utilisant ce style d'« intégration coopérative » était une application que nous avons créée et qui utilisait à la fois les serrures Brivo ACS (sécurité) et l'ouvre-porte de garage Liftmaster : pour accéder au laboratoire, il fallait badger sur la serrure, et la porte du laboratoire se déverrouillait. Désormais, si vous badgiez deux fois, la porte de garage électrique s'ouvrait également (Brivo → The Hub → Liftmaster). Un autre exemple utilise le logiciel d'éclairage automatisé de The Hub.

Comme nous superposons plusieurs systèmes d'éclairage (par exemple Wattstopper et Hue), nous pouvons créer une infinité de combinaisons de scènes, d'ambiances, d'effets ou de réglages au sein du laboratoire. Le Hub gère toute la complexité opérationnelle, facilitant ainsi le passage d'un effet à l'autre. De plus, le Hub sait désormais ajuster automatiquement la température de couleur de l'éclairage au petit matin et en fin de soirée en fonction du lever et du coucher du soleil, ce qui est meilleur pour notre santé.

Automatisation : construire des couches d'intuition

Avec le nombre croissant de systèmes électroniques installés dans l'infrastructure d'un bâtiment, les tâches de gestion, l'entretien périodique et la surveillance des systèmes sont de plus en plus confiés à des systèmes informatiques automatisés, qui nécessitent une fraction du temps et peuvent traiter des volumes de données bien plus importants que les humains. Cependant, laisser un système informatique effectuer une tâche fastidieuse n'est qu'un aspect de l'automatisation.

Par exemple, lorsque nous essayons d'apprendre à un système à automatiser des actions qui ne sont pas intrinsèquement bien définies, c'est là que l'intelligence entre en jeu. L'intuition et, parfois, la conjecture font partie intégrante de la construction d'une plateforme plus autonome. Une chose est de faire en sorte que les lumières s'allument lorsque vous entrez dans une pièce et s'éteignent quelque temps après votre départ, mais c'en est une tout autre de faire en sorte qu'elles s'allument automatiquement avant même que vous n'y entriez. En d'autres termes, vous pourriez considérer l'allumage des lumières en réponse à vos mouvements comme une sorte de réflexe. Un comportement intuitif consisterait pour la pièce à anticiper votre arrivée et à allumer les lumières avant même que vous ne soyez sur place.

Interactivité intelligente

L'un des avantages les plus directs que nous avons observés avec le Hub est sa capacité à répondre à une intention. Cela s'est illustré par un changement fondamental dans notre façon d'interagir avec notre espace : nous avons commencé à délaisser les actions explicites (ou les interfaces action-réaction spécifiques, comme un interrupteur) pour nous concentrer davantage sur l'expression de notre intention sous-jacente.

Par exemple, alors qu'auparavant, pour préparer une salle à une présentation, nous aurions effectué une série de tâches opérationnelles séquentielles et fastidieuses, nous pouvons désormais simplement dire « Je veux commencer ma présentation » et laisser toutes ces actions intermédiaires s'exécuter automatiquement. Ce changement, capable d'abstraire toute la complexité liée à l'interface avec un espace, représentait une amélioration majeure par rapport au fonctionnement manuel et à l'utilisation de commandes explicites. Bien que le Hub ne remplace pas intrinsèquement ces commandes, il augmente les capacités de nos systèmes grâce à l'automatisation et à une programmation intelligente.

L'avenir intelligent

L'attrait pour des systèmes interconnectés et coopératifs est vaste. Qu'il s'agisse de collecte de données, d'interfaces intelligentes plus performantes ou de gestion automatisée, il existe un nombre infini de cas d'utilisation potentiels pouvant être construits sur des systèmes interconnectés.

Cependant, comme je l'ai déjà dit, la nécessité fondamentale réside dans la capacité de ces systèmes à fonctionner ensemble. Dans le cas du Hub, nous avons dû reconstruire une grande partie des logiciels et des mécanismes de bas niveau qui, à notre avis, auraient dû être intégrés par défaut dans ces appareils. C'est acceptable pour la R&D, mais difficilement évolutif — la plateforme Hub que nous avons construite peut servir de solution de transition, mais ce n'est pas une solution à long terme à l'échelle de l'industrie. Cela prouve que même certains appareils cloisonnés peuvent fonctionner de manière coopérative via un intermédiaire — bien qu'avec un travail supplémentaire et un « middleware » servant de pont — mais s'appuyer sur cette architecture logicielle « middleware » (qui n'est qu'une étape intermédiaire) n'est pas une bonne stratégie pour un déploiement à long terme.

Créer des connexions significatives

Le terme « appareils intelligents », bien que vaste, implique généralement une connectivité accrue, une capture/connaissance des données améliorée, ou les deux. Nous devrions voir sur le marché beaucoup plus de matériel et de plateformes intégrant ces technologies « intelligentes », mais ce n'est pas le cas. La tendance aux services et plateformes interconnectés qui a imprégné d'autres marchés technologiques n'a pas encore pénétré le secteur AEC de manière significative. Dans un secteur où la stratégie de marché du « jardin clos » est dominante, des expressions comme « connectivité ouverte » et « architecture coopérative » sont rarement garanties.

Les appareils plus ouverts et plus connectés s'imposeront donc naturellement, à mesure que nous nous orienterons vers des systèmes plus imbriqués, et ce, indépendamment de toute autre considération fonctionnelle. Pourquoi choisir de se verrouiller chez un fabricant spécifique s'il existe une catégorie d'appareils équivalents qui fonctionnent avec le reste de votre infrastructure ? Les entreprises qui ne privilégient pas les plateformes ouvertes et connectées se retrouveront bientôt dépassées, obsolètes et, peu après, laissées pour compte. Pour être prêts à affronter un avenir plus connecté, nous devons commencer par un terrain de jeu plus coopératif.

*API : Interface de programmation d'application – un ensemble de spécifications utilisées dans les programmes logiciels pour communiquer avec d'autres composants logiciels ou matériels.