Welcome to The LAB
Laboratoire de développement Digimat®

Nous vous offrons ici un ticket d'entrée pour venir découvrir quelques projets top secrets sur lesquels travaille notre équipe R&D Digimat®. L'occasion pour nous de vous tenir informé de nos petites ou grandes avancées technologiques. Nous écoutons bien volontiers vos remarques. Bon nombre des concepts ou fonctionnalités implémentés dans nos systèmes ont pour origine une demande particulière émise par l'un de nos clients. La mise à jour automatique des firmwares et des logiciels font que tout les utilisateurs peuvent en profiter.

Digimat Quick-Report Project
Le Big-Data a votre portee

Vous croyez tout savoir sur le monde de la GTB (Gestion Technique de Bâtiment) ? Voici Digimat QuickReport, le projet qui va vous faire changer d'optique sur le véritable rôle de la GTB. Ne croyez plus aveuglément au bon fonctionnement de vos installations, mais vérifiez par vous même que confort et efficience soient bien au rendez-vous.

Toutes les données de fonctionnement de votre parc de bâtiments sont automatiquement archivées dans des bases de données cloud et ce volume d'information est mis à votre disposition de manière transparente pour vous permettre d'élaborer des campagnes d'analyses à l'aide d'un puissant moteur, 100% configurable, présenté sous forme d'un éditeur interactif embarqué sur une page html. Les diagrammes souhaités sont automatiquement générés par les serveurs cloud a partir des données de fonctionnement disponibles.

Ce que l'on peut réaliser en quelques minutes avec Digimat QuickReport tient presque de l'exploit avec des outils traditionnels ;)

Algorithmes mathématiques spécialisés, widgets graphiques, scripts programmables, intégration de synoptiques MCR, création et publication de sources de données personnalisées sur des Webservices cloud, jamais une plateforme de suivi énergétique n'avait été à ce point intégrée aux systèmes qui produisent les données.

Digimat QuickReport est en cours de développement, mais les premiers tests de fonctionnement fournissent déjà des résultas bien au delà des attentes initiales, si bien que nous l'utilisons en interne comme principal outil pour mener les campagnes d'audit et d'optimisation énergétique qui nous sont confiées, que les données sources proviennent de systèmes Digimat... ou pas ;)

Vous allez adorer. Revenez bientôt, nous publierons des sessions vidéo démontrant l'incroyable potentiel de cet outil absolument génial. Du jamais vu selon nous. Voilà par exemple le type de suivi que vous pourrez désormais aisément faire par vous même directement depuis la plateforme QuickReport !

Optimisations MCR Low-Cost
Wireless IOT Sensors

La nouvelle sonde Digimat Wireless WiFi-MQTT fourni un capteur intelligent 5 en 1 autonome, fonctionnant sur batterie, capable de faire remonter automatiquement vers un serveur cloud MQTT les données suivantes :

  • Mesure de la température ambiante
  • Mesure de l'hygrométrie
  • Calculation du point de rosée
  • Mesure IAQ type CO2
  • Monitoring d'un contact libre de potentiel (pour reprise d'une alarme)

Un support pour carte SD intégré permet de stocker les mesures localement si une connectivité WiFi n'est pas disponible (fonctionnement en mode datalogger). Outre la connectivité normalisée MQTT, la sonde est programmée pour se connecter périodiquement sur le portail cloud Digimat IoT, permettant de reconfigurer à distance le fonctionnement de la sonde (changement des codes d'accès WiFi et des services MQTT, reparamétrage de la période d'échantillonage, signalisation du niveau de charge résiduel disponible, etc).

La sonde Digimat WiFi MQTT est particulièrement indiquée pour les cas suivants

  • Optimisations énergétiques (réseau de points de mesures IAQ en ambiance)
  • Monitoring & Alarming température locaux informatiques, caves à vins, etc.
  • Optimisation des points de consigne type "plafonds froids" en fournissant des points de mesures locaux (faux plafonds) permettant de calculer précisément les températures limites à l'aide du point de rosée
  • Fourniture d'un point de mesure plus ciblé, lorsqu'une sonde d'ambiance peu représentative (mal positionnée).
  • Problème d'esthétisme : dans certaines applications, les sondes d'ambiances usuelles trouvent difficilement leur place. Les sondes autonomes peuvent par contre aisément être déployées de manière invisible !

Pour les cas de figure sans couverture WiFi, nous préparons une version LoRa-WAN de ce capteur 5 en 1 ! Nous avons publié sur LinkedIn un article plus détaillé expliquant comment déployer ce type de capteurs dans le bâtiment.

DIGIMAT DMS
Cloud Monitoring Platform

L'expérience montre qu'il existe toujours un certain nombre "d'erreur de liens" sur les synoptiques MCR/GTB. Les utilisateurs découvrent (ou subissent) en général ces anomalies avec le temps en utilisant les systèmes de supervisions traditionnels.

Ce qui aurait pu en rester là est en passe de changer avec l'arrivée des systèmes de supervision WEB/Cloud. En effet la plateforme de monitoring centralisée Digimat DMS, grâce a la remontée automatisée de toutes les anomalies détectées, permet aux concepteurs d'être proactifs et de traiter ces erreurs dès qu'elles sont découvertes... par qui que ce soit. Aucune action de l'utilisateur n'est requise, le simple fait qu'il aie été confronté à une erreur est suffisant.

La capture video ci-dessus montre un certain nombre "d'erreurs de liens" découverts par des utilisateurs. Il est alors aisé de remonter à la source du problème et de publier dans la foulée un correctif. L'aspect collaboratif et constructif des systèmes cloud (par rapport aux postes de supervision locaux) impacte positivement la qualité des systèmes livrés.

SAIA-BURGESS EtherSBus
Open Source Python Communication Module

Nous avons développé et publié en "open source" un module Python permettant la création de passerelles de communication avec les systèmes d'automation PCD de SAIA Burgess. En 2 lignes de code Python, créez votre propre device EtherSBus capable de fournir ou recevoir des données avec un ou plusieurs systèmes SAIA via réseau IP.

Intégrez le tout dans un Raspberry Pi à CHF 40.--, stockez le résultat des lectures périodiques de données : vous venez de déployer en quelques minutes un puissant datalogger SAIA à coût quasi... nul. Le module Python "digimat.saia" est librement accessible sur le dépôt publique PyPi.

Cette librairie est encore en phase de mise au point, mais le potentiel est vraiment intéressant. Faites en bon usage ;) ou contactez nous si vous voulez par exemple faire remonter des données SAIA sur les systèmes de supervision WEB/Cloud Digimat RWS.

LoRa-WAN
Gateway Digimat vers l'infrastructure LoRa-WAN Swisscom

Avec la technologie de radio communication LoRa, le monde de l'internet des objets (IoT) entre dans une nouvelle ère. Une petite révolution. Le LoRa-WAN est une technologie de communication sans-fil autonome qui utilise son propre réseau herzien LPN (Low Power Network), totalement indépendant du réseau Natel 3G/4G.

En Suisse, Swisscom fourni aujourd'hui déjà une couverture quasi nationale. L'infrastructure LoRa WAN est spécifiquement conçue pour pouvoir transmettre de manière bidirectionnelle et sécurisée de petites quantités de données à très faible débit (au maximum 1 message de 255 bytes toutes les 10 minutes). Cela permet d'envisager le déploiement d'objets connectés autonomes tel que des sondes, des compteurs, des détecteurs d'alarmes... et cela même là où il n'y a pas de signal WiFi à disposition.

L'infrastructure réseau LoRa-WAN est entièrement gérée par Swisscom. La gestion des devices déployés sur l'infrastructure LPN Swisscom se fait par une interface WEB. Pour déployer un service (une application), il faut déclarer sur le portail de management LPN Swisscom l'adresse d'un WebService (Application Server) vers lequel seront retransmis tous les messages LoRa émis par les devices (uplink=device vers application). Une application peut également envoyer des messages vers les devices (downlink=application vers device) :

Les messages échangés entre l'application et l'infrastructure Swisscom (uplink/downlink) sont des requêtes HTTPS/POST formatées selon un "protocole" fourni par Swisscom (Application Development Guide, LPN-CMP to AS tunnel interface).

Vous devinez la suite ? Nous avons implémenté sur la plateforme cloud Digimat DCF un point d'entrée LPN-CMP permettant la communication avec l'infrastructure Swisscom LoRa-WAN !

Dès lors, n'importe quelle donnée publiée par un objet LoRa-WAN peut être associée à une variable Digimat DCF. On intègre donc en quelques clics tout le monde LoRa-WAN dans le monde MCR, grâce à la magie du cloud Digimat DCF !

Côté hardware, nous travaillons actuellement activement sur la mise au point d'un device LoRa-WAN autonone (sur batterie) intégrant de série une sonde de température, une sonde d'hygrométrie ainsi que 2 entrées digitales (pour le monitoring de toute information fournie par contact libre de potentiel). Un objet IoT parfait pour permettre la surveillance d'une cave à vin, d'une cave à cigares, du système de climatisation d'un local stratégique, etc. Pour les cas de figures ou un réseau WiFi serait disponible, une version MQTT sera également disponible ! En option, un capteur IAQ CO2/VOC pourra être intégré directement sur la sonde (à l'intérieur du boitier).

Les systèmes MCR Digimat sont prêts pour ne pas rater le virage LoRa. Nous ne sommes manifestement pas les seuls à nous y intéresser ;) Prometteur.

MYSTROM
Prise 230V 2.0, produit Suisse

La prise 230V MyStrom est non seulement pilotable via WiFi mais intègre également un compteur d'énergie. Pas cher, produit Suisse, simple. Tout pour plaire.

Ce produit est équipé de série d'une petite API http toute simple que nous avons implémentée dans notre environnement Digimat DCF. Dès lors, les prises MyStrom sont désormais directement pilotables depuis toute l'infrastructure cloud Digimat DCF, comme n'importe quel autre point HVAC ! Il est donc possible de se servir des API Digimat pour piloter ces éléments depuis n'importe où. Limite gadget, mais on aime. Cela dit, c'est un excellent moyen de couper (complètement, sans mise en veille) des équipements informatiques (imprimantes, photocopieurs, écrans, routeurs WiFi, téléphones, ...) lorsque les bureaux sont fermés (mis sous alarme, par exemple). Raccordé en amont d'une prise multiple, le compteur d'énergie intégré peut également fournir de précieuses informations.

HeatMap
Energy monitoring tools

Avec les diagrammes de type "HeatMap", les systèmes Digimat bénéficient désormais d'un nouveau type d'outil pour l'analyse comportementale des installations CVC. A terme, ces outils spécifiques (signatures d'énergie, diagrammes de Sankey) seront rassemblés dans une interface WEB/Cloud unifiée qui fera littéralement exploser le potentiel déjà important de la plateforme de supervision Cloud Digimat® RWS.

Depuis 2002, tous les système MCR Digimat sont nativement équipés pour faire remonter automatiquement vers des bases de données cloud toutes les informations enregistrées (températures, position des vannes ou clapets, etc). Cela permet de pouvoir disposer de données de fonctionnement à long terme. Il est alors possible de représenter l'ouverture d'une vanne -- par exemple -- sur une "HeatMap". On dispose alors immédiatement d'une cartographie comportementale annuelle de cet organe.

L'échelle horizontale représente le jour de l'année (du 1er janvier à gauche jusqu'au 31 décembre à droite). L'échelle verticale représente l'heure de la journée (de 00h00 en bas jusqu'à 24h00 en haut).

Sur chaque pixel (x, y) on représente alors la valeur (position, température, etc) de l'organe à l'instant (jour, heure) donné. La couleur du pixel représente la valeur à ce moment précis (par exemple en violet si la vanne est faiblement ouverte, ou en jaune si elle est ouverte à 100%). On peut donc aisément identifier (sans devoir analyser des milliers de données) un grand nombre de défauts, tel que

  • Si une vanne s'ouvre (et consomme de l'énergie) alors qu'elle ne serait pas sensé le faire !
  • Si des organes s'actionnent ponctuellement de manière contradictoire (destruction d'énergie)
  • Si les systèmes de récupération d'énergie ne fonctionnent pas quand ils devraient être actifs
  • Si des comportements changent sans raison (modifications non souhaitées d'horaires, paramétrages erronés)
  • Si les fonctions de freecooling ne sont pas exploitées
  • etc.

Si vous disposez d'un compte LinkedIn, rendez-vous sur cet article pour voir comment il est possible d'exploiter les diagrammes HeatMap sur un exemple concret !

Nous avons également intégré la fonction HeatMap sur la plateforme interactive "Telegram" de manière à pouvoir générer à la volée les analyses souhaitées. On demande au chatbot la génération d'une analyse (ici pour trois points donnés) et l'imagerie nous revient en retour après quelques secondes. Magique !

MQTT (Message Queue Telemetry Transport)
Le Graal pour l'internet des objets ?

Avec l'arrivée massive des objets connectés (IoT, Internet Of Things) vient tout naturellement la question du comment peut-on communiquer entre tous ces éléments. Dans le monde HVAC, avec un peu d'objectivité, nous devons admettre n'avoir jamais trouvé la solution ultime. Certains vous diront très convaincus qu'avec BACnet le miracle a déjà eu lieu. C'est évidemment une réponse un peu simpliste.

Avec l'Internet des "objets", il est clair que l'on se retrouve confronté à la même problématique, voir même pire, puisque les objets ne sont pas "simplement" disséminés dans une chaufferie ou dans un immeuble, mais sur toute la planète. Le seul vecteur commun étant finalement un accès Internet plus ou moins fiable avec tous les problèmes de sécurité et d'accès de bout en bout que cela peut impliquer. BACnet, par exemple, ne résout en rien la problématique difficile du transport des données entre sites. C'est d'ailleurs l'une des raisons pour lesquelles nous avons mis au point notre plateforme de communication cloud unifiée Digimat® DCF sur laquelle est basée la solution de supervision WEB/Cloud Digimat® RWS. Avec l'IoT, il faut repartir à zéro car les contraintes sont réellement différentes.

On commence donc à voir émerger des solutions crédibles large échelle (on ne traite plus des centaines ou milliers de points, mais bien des millions) pour l'interconnexion des différents objets et services : HomeKit de Apple, AWS IoT de Amazon, Google IoT CloudPlatform, Microsoft Azure IoT. En attendant que les grands se mettent d'accord (soyons optimiste), il est déjà possible d'avancer sérieusement sur le sujet. Le modèle émergeant semble être celui du "publisher/subscriber".

Pour comprendre, revenons un instant dans notre vieux monde HVAC des années 80. Il y a eu un jour l'arrivée du ModBus. En simplifiant à l'extrême, il s'agissait en fait d'un protocole permettant le transport et l'échange de données entre systèmes raccordés sur un même réseau (ou bus), le format des données échangées étant presque laissé libre. En connaissant comment et à quels emplacements étaient exposées les variables d'un système, on pouvait aisément lire et écrire dans ces "registres" depuis un autre système. ModBus sur TCP a notamment trouvé son succès dans l'industrie avec l'implémentation d'entrées/sorties déportées. Ce n'est que bien plus tard que des bus de terrains/protocoles ont cherchés à standardiser le format des valeurs/objets échangés (CANopen, BACnet, etc.). D'une certaine façon, la standardisation a également amené sont lot de complication, mais c'est un autre débat.

Avec l'IoT, on ne dispose pas encore de couche standardisée universelle type "BACnet" pour l'encodage et la transmission des données. Par contre il existe MQTT, une séduisante solution de transport des données taillée pour l'IoT (gestion de la masse, haute disponibilité, notifications bidirectionnelles quasi temps réel), mais "à la ModBus" c'est à dire avec une totale liberté sur le format des données échangées.

MQTT (Message Queue Telemetry Transport) est une architecture de communication normalisée OASIS depuis 2014, efficiente, ouverte et adaptée au transport des informations entres capteurs et systèmes connectés. En y réfléchissant bien, MQTT est un peu "le ModBus du cloud" pour le nouveau monde IoT. Peut-être pas tout à fait le Saint Graal, mais un sérieux candidat en tout cas.

Pour faire simple : sur MQTT, tout fournisseur d'information (un capteur, par exemple) fournira ses données (data) en les publiant (publish) sur un serveur (broker). Les données publiées sont identifiée par un "topic", une chaine de caractère au format libre du type "sensors/temperature/kitchen". Le format des données publiées ne suit aucune règle, c'est en fait une simple chaine de caractère qui peut faire jusqu'à 256Mb. On peut donc publier tout type d'information : la température donnée par une sonde, une photo, un fichier, des données JSON ou XML. Peu importe. De l'autre côté, il y a les consommateurs de données. Ceux qui veulent les recevoir s'abonnent (subscribe) simplement au topic souhaité. Des notions de qualité de service (qos) et de rémanence (retain) permettent de s'assurer de la transmission des messages du producteur vers le(s) consommateur(s).

Du point de vue sécuritaire, MQTT supporte nativement les connexions chiffrées TLS. La connexion n'est cependant pas chiffrée de bout en bout, mais seulement jusqu'au broker. C'est un point faible qui n'empêche pas les devices de s'échanger des données elles mêmes cryptées (par exemple avec AES) puisque le format des données est libre. Côté broker, il est possible d'utiliser des notions du type user/password pour définir les topics accessibles (read, write) par "utilisateur".

Presque magique. Si vous souhaitez comprendre plus en détail comment fonctionne MQTT, nous vous recommandons la lecture de des articles "MQTT Essentials" publiés par HiveMQ. C'est une excellente introduction sur le sujet.

Avec MQTT, l'implémentation côté device (publisher, subscriber) est simple, et c'est réellement là que réside tout l'intérêt, puisque les ressources côté "objet IoT" sont souvent limitées. De nombreuses librairies MQTT sont disponibles, quelque soit la plateforme ou le language de programmation utilisé. On citera notamment paho qui fourni probablement ce qui se fait de mieux en la matière. Côté broker, des implémentations opensource sont disponibles, comme mosquitto. On peut parfaitement faire tourner son propre broker, sur un simple Raspberry Pi, mais les brokers sont faits pour être hébergés sur le cloud. Des brokers publics sont disponibles pour les tests de mise au point (iot.eclipse.org:1883). Les services MQTT publics seront par contre hébergés sur des plateformes online crédibles tel que CloudMQTT (souvent hébergées sur le cloud Amazon).

MQTT est un sujet qui nous intéresse. Le monde HVAC doit impérativement s'ouvrir aux données fournies par les objets connectés (IoT), puisque le temps du simple "gadget" est révolu. Les systèmes MCR/GTB sont aujourd'hui d'excellents fournisseurs d'information, et MQTT offre une manière simple (pas la seule) de connecter des systèmes et des périphériques. Notre plateforme de communication unifiée cloud Digimat® DCF disposera bientôt d'un composant MQTT !

Au niveau CPU MCR, nous pouvons désormais directement souscrire ou publier des données MQTT en exploitant la technologie embarquée Digimat EBUS. Il s'agit d'un système d'entrées/sorties virtuel intégré dans chaque CPU (station) permettant de déclarer des E/S localement comme s'il s'agissait de données locales (type bus de terrain), mais dont l'implémentation est réalisée dans un module réseau déporté (un simple Raspberry Pi, par exemple) :

Si cela peut vous être utile, nous avons développé et publié sur PyPi le module digimat.mqtt permettant de dialoguer aisément et durablement avec des brokers MQTT. Le module intègre tous les mécanismes de reconnexion automatique en cas de perte de liaison et permet de travailler avec des objets (items) que l'on déclare au client MQTT. Les "objets" sont ensuite automatiquement mis à jour avec les messages reçus du broker MQTT. Il s'agit principalement d'un wrapper autour de l'excellent module paho-mqtt. A titre d'exemple, voici comment nous créons une souscription pour une sonde de température MQTT :

from digimat.mqtt import MQTTClient

client=MQTTClient('iot.eclipse.org', 1883)
sonde=client.createItem(topic='ch.digimat/debug/sensors/temperature/kitchen', qos=0)

[...]

print sonde.value

RWS2, La Supervision WEB
En route vers le pur HTML5

Avec Digimat® RWS nous proposons désormais une puissante solution de supervision WEB basée sur l'infrastructure cloud Digimat® DCF. RWS2 propose une solution "pur HTML5", compatible avec l'ensemble des explorateurs Internet récents quelque soit la plateforme (Windows, OSX, Linux). L'interface utilisateur à été simplifiée au maximum et adaptée à l'utilisation en mode "touch" (tablettes tactiles iOS ou Android).

Avec Digimat® RWS2, vous pouvez gérer votre parc de bâtiments où que vous soyez, quand vous le souhaitez. Le tout sans outils spécifique. Rapide, sécurisé, intuitif. Effet WOW assuré. Une plateforme résolument novatrice et indispensable, notamment mise au point pour

  • les équipes de Facility Management
  • les régies
  • les bureaux d'ingénieurs
  • les services d'audits
  • les services de suivis+optimisations énergétiques
  • les services d'astreinte

On n'avait jamais eu une vision aussi globale et instantanée sur un parc de bâtiment. La réactivité des équipes de maintenance s'en trouve décuplée. Les dérives de fonctionnement sont immédiatement identifiables. Il en résulte plus de confort pour les occupants et une diminution des frais de fonctionnement inutiles. La vidéo ci-dessous montre quelques unes des fonctionnalités offertes par la plateforme de supervision WEB/Cloud RWS2. Toutes les données affichées sont fournies en temps réel, sans trucage.

Cerise sur le gâteau, nous avons mis au point des solutions à faible coût qui permettent l'intégration de vos différents bâtiments sur la plateforme de supervision cloud DCF+RWS !

Digimat BACnet Client
Accès natif aux données BACnet 3rd party

Depuis le firmware 6.0.66, les CPU Digimat-3 permettent d'exposer l'ensemble des E/S au format BACnet/IP (fonction BACnet/IP Server). Désormais, les CPU sont également équipées d'un service BACnet/IP Client ! Il est donc possible d'intégrer nativement dans les configurations numériques (c'est-à-dire sans matériel spécifique) n'importe quelle donnée BACnet/IP fournie par un service 3rd party (lecture, écriture).

Pour accéder aux données BACnet/MSTP (typiquement fournies par des réseaux de régulateurs IRC), il suffit d'installer un routeur BACnet MSTP/IP. L'implémentation multithread (16 flux parallèles) du client BACnet dans les CPU Digimat permet de garantir une synchronisation rapide des données, même en cas de réponse "lente" de certains devices. Des états par défaut sont paramétrables en cas de rupture de la chaine de communication.

Digimat BACnet Bridge
Exposition des E/S au format BACNET

Les CPU Digimat-3 sont désormais équipées d'un service BACnet intégré exposant au format BACnet/IP l'ensemble des E/S MCR. La future mise à jour du firmware 6.0.66 apporte un support BACnet IP natif à l'ensemble de votre parc d'installations MCR. Toutes les révisions de CPU Digimat-3 installées depuis 2002 sont éligibles pour le déploiement du nouveau firmware ! Les services BACnet Digimat sont identifiés auprès de l'organisation ASHRAE avec le vendor-id 892.

L'implémentation du protocole repose sur la librairie open source BACnet Stack, validée avec succès sur l'ensemble des tests de conformités imposés par BACnet. Par sécurité, les services BACnet ont étés entièrement découplés du reste des services automation dans la CPU de manière à pouvoir éviter une problématique critique rencontrée dans bon nombre des automates du marché. En cas de surcharge générée au niveau BACnet par des outils d'interrogation externes incorrectement paramétrés, les tâches d'automation peuvent alors être lourdement impactées.

Avec le modèle d'implémentation que nous avons retenu, le serveur BACnet Digimat® puise les données dont il a besoin par communication réseau interne avec la couche automation (flèche rouge). Le trafic réseau BACnet est donc géré en amont avec un découplage total. En cas de crash, la couche BACnet redémarre et se resynchronise automatiquement, sans aucun impact sur la couche automation. L'image ci-dessous montre l'accès aux E/S d'une CPU avec un browser BACnet/IP open source (YABE).

Hormis les valeurs instantanées, les états de fonctionnement sont également remontés sur BACnet : état manuel, état d'alarme, état d'erreurs, flag EN/HORS service. L'exposition des E/S MCR sur BACnet est entièrement automatisée, aucune configuration n'étant nécessaire sur les CPU. Le nom de chaque ressource BACnet correspond aux identificateurs uniques rencontrés côté points MCR. Une sonde identifiée "r_9000_3_cio_13057_0" sur le système MCR est exposée avec le même nom côté BACnet. Les libellés des points sont automatiquement synchronisés ce qui permet une utilisation plus confortable depuis BACnet. Avec les technologies intégrées BACnet et Digimat® DCF, vous pouvez compter sur un système pleinement "ouvert" capable de s'intégrer aisément dans n'importe quelle infrastructure moderne.

Tout le cloud, zero invest
Noeud Digimat DCF Raspberry Pi

Il existe beaucoup de sites pour lesquels on souhaiterait pouvoir déployer les solutions de supervision cloud Digimat RWS mais les budgets disponibles ne permettent pas toujours de fournir la technologie nécessaire. Une solution consiste alors à utiliser l'infrastructure cloud Digimat existante. La mise en communication d'un système MCR avec les services cloud externes impose le déploiement d'un "serveur" sur site. En fonction de la taille du site et de la disponibilité souhaitée, il est désormais possible d'utiliser un simple Raspberry Pi (CHF 40.--) en guise de serveur local !

De fait, la barrière financière initiale tombe instantanément. Le coût de la supervision centralisée WEB peut aisément être intégrée dans le contrat d'entretien. Des logins peuvent être fournis à toute personne responsable (régie, facility, exploitants), alors que cela était difficilement envisageable avec les logiciels de supervision usuels. La technologie de supervision cloud centralisée n'a jamais été si proche de vos installations MCR !

Pour les amateurs, la technologie Digimat DCF est conçue sur la plateforme .NET (C#). Nous utilisons MONO comme support .NET sur Linux (Raspberry Pi). Le Raspberry Pi ne devant "que" assurer les tâches de communication et de routage+cryptage des messages DCF, sa puissance limitée est en fait amplement suffisante. Nous ne constatons aucune latence particulière à l'usage.

Monitoring consommation énergétique
Modélisation+prédiction des courbes de charges

Nous utilisons l'infrastructure cloud centralisée Digimat DCF pour alimenter en données notre nouvel outil d'analyse des courbes de charges. A partir des données enregistrées, nous créons un modèle mathématique de la courbe de charge d'un bâtiment (à partir du comptage électrique, par exemple). La modélisation peut ensuite être interrogée pour prédire la consommation dite "normale" en temps réel.

En comparant la consommation réelle avec la valeur issue du modèle prédictif il est possible de générer des indicateurs de performance. Un indicateur de performance durablement bas (4 heures, par exemple) peut être utilisé pour générer une alerte ou activer automatiquement des fonctions de "bridage". Appliquées à un parc de bâtiments, les méthodes d'analyses de ce type sont des outils qui peuvent rapidement s'avérer... rentables ;)

Le modèle actuel (v1.0) est bâti selon la méthode suivante en utilisant la librairie Pandas (Python Data Analysis Library). Les données de consommation (enregistrement 15 minutes de la puissance instantanée) sont extraites de la base de donnée Digimat DCF centralisée puis classifiées par jour de la semaine pour permettre une première analyse de forme et de cohérence :

Pour chaque profil (jour de la semaine -- DOW), on distingue les différentes courbes de charges mesurées en fonction d'un paramètre "variable", tel que la température moyenne extérieure du jour donné. Cela donne une représentation tridimensionnelle (x=temps, y=température moyenne, z=consommation). Chaque profil de charge (x,z) pour un y donné est lissé (déparasitage) et rééchantillonné+interpolé sur une période de 15 minutes (pour s'affranchir des données manquantes ou horodatage imprécis).

La modélisation est ensuite créée par analyse "transversale", quart d'heure par quart d'heure -- profils (y,z) pour chaque x donné. On obtient ainsi la consommation (puissance) donnée pour un quart d'heure donné et pour un jour de la semaine donné. Chaque profil 1/4 heure est ensuite lissé (déparasitage), représenté sur la figure ci-dessous par une courbe rouge

Il ne reste ensuite plus qu'a rechercher une représentation mathématique de chaque "profil 1/4 heure", par régression linéaire (ou polynomiale). Les profils 1/4 heure modélisés sont représentés en bleu sur la figure ci-dessous

Ces opérations sont répétées pour l'ensemble des jours de la semaine. Le modèle "mathématique" ainsi créé est fourni comme une classe/objet Python que l'on peut interroger pour prédire la consommation (puissance) à n'importe quelle heure de la semaine en fonction de la température extérieure moyenne (avérée ou prédite). Une interpolation est utilisée pour fournir les données en dehors des minutes 00, 15, 30 ou 45 (valeurs entre les lignes bleues).

Compliqué ? Pas vraiment en fait. Voici comment nous rapatrions sur l'environnement cloud Digimat DCF l'ensemble des données du compteur d'énergie dont l'id est r_157_1_moi_711_0 puis créons le modèle mathématique évoqué ci-dessus pour demander la puissance instantanée prédite à 12h05 pour un lundi (dow=0) dont la température moyenne extérieure serait de 25°C

cdc=DailyLoadCurve(dcf, dow=0, key='r_157_1_moi_711_0')
conso=cdc.model.predict(datetime.time(12, 5), 25.0)

ce qui nous retourne 663kW. Le modèle peut être interrogé pour obtenir d'autres informations. Par exemple, on peut demander une estimation de la puissance permanente (ruban)

ruban=cdc.model.predictRibbon()

ce qui nous retourne 109kW. Vérifier la pertinence des éléments enclenchés en permanence étant l'une des premières actions à mener, ce type d'information est évidemment très utile. La puissance de crête peut également être prédite selon le même principe

peak=cdc.model.predictPeak()

ce qui nous retourne 679kW. La génération du modèle présenté ci-dessus est entièrement automatisée et ne prend que quelques secondes de calcul. Il est donc aisément possible de remettre à jour le modèle périodiquement pour tenir compte des nouvelles données de consommation (fenêtre glissante sur les 3 dernières années, par exemple). Les images 3D montrées ci-dessus à titre d'exemple servent en fait à la validation visuelle d'un modèle. Voici comment nous obtenons la dernière image présentée ci-dessus

cdc.save('model.jpg', view=DailyLoadCurve.VIEW_MODELIZED_FIT)

A titre d'exemple "trivial", voici comment on pourrait par exemple se servir des données du modèle généré pour afficher la jauge ci-dessous qui indiquerait en live : la consommation réelle "actuelle" du bâtiment (aiguille), la consommation permanente prédite (bande jaune), la consommation live théorique prédite selon le modèle (bande verte) et la mise en évidence du niveau de consommation (zone rouge) qui dépasserait la consommation de pointe prédite pour les conditions extérieures actuelles

Garanti sans trucage ;)

SNMP Monitoring
Les locaux stratégiques communiquent avec vos services IT

Les ingénieurs IT ne sont pas familiers avec les techniques de communication GTB usuelles, par contre ils sont extrêmement bien équipés en outils de monitoring+reporting SNMP. Notre interface SNMP permet de lier aisément ces deux mondes. La mise en commun des informations permet de mutualiser les investissements réalisés (en évitant le doublement des équipements) tout en améliorant l'efficience globale des systèmes (meilleure coordination entre équipements).

Il est désormais possible d'exposer au format SNMP n'importe quel point disponible dans l'infrastructure Digimat DCF. Les systèmes déployés pour la gestion de la température des locaux stratégiques ou DataCenter peuvent ainsi aisément transmettre les données de fonctionnement aux services IT.

La passerelle Digimat DCF-SNMP offre également la possibilité de recevoir des ordres d'écriture (SET), ce qui permet de transmettre des données externes disponibles dans l'infrastructure IT vers les systèmes GTB. Par exemple, la température interne des racks d'un DataCenter (information disponible dans les serveurs) peut être injectée dans nos systèmes, de manière à compléter les informations fournies par les sondes d'ambiance. Les informations publiées au format SNMP sont exposées au travers d'une numérotation normalisée "1.3.6.1.4.1.47521.xxx" (Digimat PEN registered number 47521).

DIGIMAT REMOTE BLOCK
Interface de programmation libre OpenSource

La configuration numérique d'une CPU est traditionnellement réalisée à partir d'un logiciel de programmation graphique par bloc fonctionnel (Digimat® Builder). Lorsque la situation l'exige, ou lorsque l'on veut faire les choses par soi-même en toute liberté, il est parfois utile de pouvoir élaborer directement en code informatique les algorithmes complexes dont on a besoin. En intégrant le code directement dans le runtime local on pourrait aisément mettre en danger la CPU (saturation des ressources systèmes, par exemple).

Avec la technologie embarquée "Digimat® RemoteBlock", on utilise un bloc fonctionnel conventionnel dans la configuration numérique (bloc de type "REM"). On peut librement définir le nombre d'entrées/sorties du bloc et ainsi le connecter aux autres conditions logiques usuelles. Au niveau de la configuration numérique, ce type de bloc peut donc être simplement considéré comme une "boîte noire" (ou interface).

L'implémentation de la fonctionnalité du bloc (contenu de la "boîte noire") est par contre entièrement réalisée dans un module externe relié par réseau TCP/IP, fournissant le service Digimat® RemoteBlock Server. Un simple Raspberry Pi à 40 CHF est une plateforme amplement suffisante pour commencer ;) Nous fournissons publiquement sur PyPi le module Python digimat.remoteblock. Cela permet de commencer à programmer en mode objet en quelques minutes.

Voici comment on peut créer son propre serveur RemoteBlock. Le serveur fournira l'implémentation de l'ensemble des RemoteBlocks demandés par la CPU. Notre exemple n'implémentera qu'un seul type de bloc. Commençons par importer le module digimat.remoteblock

from digimat.remoteblock import BlockServer, Block

Implémentons ensuite un nouveau type de bloc nommé "Add" qui renvoie sur son unique sortie une valeur correspondant à la somme de toutes les valeurs envoyées sur ses entrées. Le code proposé ci dessous, bien que très simple, gère déjà parfaitement tous les blocs "Add" qui seront déclarés dans la CPU distante, quel que soit le nombre d'entrées défini sur chaque bloc. Pour bien faire, les entrées non connectées sont ici ignorées (test "isValid()").

class BlockAdd(Block):

    def onInit(self):
        self.setNbOutputs(1)

    def onEvaluate(self):
        value=0.0
        unit=None

        for io in self.inputs():
            if io.isValid():
                value+=io.value
                if unit is None:
                    unit=io.unit

        self.output(0).set(value, unit)

Toutes les communications réseaux entre la CPU et le serveur RemoteBlock sont gérées automatiquement : reconnexions automatiques, gestion de la bande passante. En cas de perte de communication, des valeurs par défaut peuvent être définies. Tout le système est géré de manière dynamique : les nouveaux blocs sont automatiquement instanciés dans le serveur, et supprimés après une période de non utilisation. Il ne reste alors plus qu'à lancer notre serveur RemoteBlock

server=BlockServer()
server.serveForEver()

Saurez-vous en faire bon usage ? Ah, avant d'oublier de vous le dire, le serveur RemoteBlock que nous venons de créer ensemble est capable de gérer plusieurs connexions simultanées. Autrement dit, il suffit de déployer un seul serveur sur l'ensemble du réseau GTB !

Cerise sur le gâteau, il est parfaitement possible de se servir du debugger python interactif pdb (ou sa version boostée pdb++) pour la mise au point du code ! Nous avons intégré des triggers activables depuis les outils de supervision pour permettre l'arrêt en mode debug directement sur le bloc souhaité.

Google Calendar
Integration GTB entre services Cloud

L'infrastructure cloud Digimat DCF peut désormais être mise en communication avec divers services cloud tiers. Pour exemple, il est ainsi possible d'utiliser le service de planification Google Calendar comme fournisseur de données. Les salles de conférences sont ainsi directement réservées sur le calendrier online (via Browser ou Smartphone). Les zones inoccupées peuvent être automatiquement basculées en mode standby, sans action de l'utilisateur (économie d'énergie).

Le système GTB se synchronise sur les événements planifiés et enclenche automatiquement les systèmes de gestion du confort pour les zones concernées. Des points de consignes particuliers peuvent être soumis directement sur la tâche planifiée "Google". Selon les conditions climatiques, les heures d'enclenchement peuvent être automatiquement anticipées. On donne ainsi aux exploitants un réel pouvoir de contrôle sans devoir leur fournir des outils de supervision spécifiques (problèmes de coût+sécurité).

Data Analysis
Le système MCR comme fournisseur de donnée

Grâce à l'infrastructure Digimat DCF, les systèmes MCR deviennent de véritables fournisseurs d'information. Toutes les données enregistrées localement sont capables de remonter automatiquement dans une base de donnée centralisée hébergée dans un datacenter sécurisé. Des mécanismes de réplication automatique peuvent alors être aisément mis en place pour approvisionner en information les auditeurs externes spécialisés (audits énergétique, par exemple).

Un site comme le Centre Commercial La Praille génère plus de 800'000 records par jour. Le traitement de ces informations commence à devenir un métier spécialisé et des outils informatiques spécifiques sont indispensables. Lorsque l'on cherche à trouver une solution puissante et open source, on trouve rapidement le duo de choc Pandas et Matplotlib. A l'origine prévus pour la communauté scientifique (physique, mathématiques, finance), ces outils permettent de manipuler aisément de grandes quantités de données. Pour ceux qui veulent s'y mettre, nous recommandons la lecture de l'ouvrage Python for Data Analysis :

Nous avons commencé à utiliser Pandas pour permettre la génération automatisée de rapports à partir des données archivées par nos systèmes. Nous publions publiquement sur PyPi un module digimat.sankey permettant d'extraire et de représenter diverses informations relatives aux compteurs d'énergie (diagrammes de Sankey, signatures d'énergie, etc). Les premiers résultats obtenus sont déjà très prometteurs.

Live Dashboard
Le tableau de bord temps réel de vos installations

Avec l'infrastructure cloud Digimat DCF, l'information est toujours à portée de main. Nous avons réalisé un système de moniteur live permettant l'affichage d'informations présentées comme un "tableau de bord" sur des écrans TV. La solution est basée sur un nano ordinateur Raspberry Pi raccordé à une TV HD ou un moniteur 24'' via port HDMI. Nous utilisons l'environnement open source Dashing comme moteur graphique.

Le concept est simple et modulaire. Les données sont automatiquement mises à jour toutes les N minutes en utilisant les API DCF/RWS disponibles. Le tableau de bord peut donc être installé à n'importe quel endroit du moment qu'il est raccordé au réseau Internet (n'impose pas forcément le raccordement sur le réseau AdB). La facilité de déploiement d'un tel système est déconcertante.

Energy Monitoring & Auditing
Digimat® comme fournisseur de données

Les systèmes Digimat sont capables de collecter, archiver et fournir les données énergétiques aux entreprises tierces mandatées pour les exploiter. Sur demande, nous implémentons les modules d'injection automatisés nécessaires pour alimenter en données les différents services tiers disponibles sur le marché tel que

Chaque solution d'injection de données est réalisée sur mesure en fonction des besoins. De la pose des compteurs à la livraison des données nous pouvons vous fournir tout le support dont vous avez besoin. Nous sommes certifiés CMVP (Dominique Charvieux, Frédéric Hess). Des services de monitoring spécifiques peuvent être mis en place pour détecter et signaler automatiquement toute anomalie détectée dans la chaine de transmission des informations.

Integration DCF
Dans les automates MCR Digimat

Avec les nouveaux points DcfBi (DFC Bus Item), tout l'environnement cloud Digimat DCF est directement accessible depuis les automates MCR Digimat. On peut donc importer sans difficulté dans une station n'importe quelle variable disponible sur l'environnement cloud. Besoin d'intégrer la sonde extérieure du bâtiment d'à côté ? Un jeu d'enfant. Saurez vous par contre comprendre le challenge qui se cache derrière cet exemple à priori trivial ?

Toute la mécanique complexe de mise en communication est automatiquement et dynamiquement créée en fonction des points demandés. En cas de non disponibilité, un système de fallback permet de se replier sur une valeur ou condition disponible localement.

DEMO
DCF RWS PYTHON API

L'ensemble des données accessibles sur la plateforme cloud Digimat DCF est utilisable au travers de plusieurs API, prouvant aux utilisateurs les plus avertis le caractère 100% ouvert du système. La DEMO ci-dessous illustre de manière basique l'utilisation de l'API Digimat DCF RWS au travers du wrapper Python digimat.rws disponible publiquement sur la plateforme PyPi.

Une fois connecté au service RWS API, on peut manipuler n'importe quelle donnée -- où que l'on se trouve, où que se trouve la donnée et quelque soit le type de la donnée. L'accès est ainsi direct, 100% dématérialisé et standardisé. On peut accéder de la même manière à n'importe quelle autre donnée, quelque soit le système fournissant cette information et où que l'on se trouve (sans avoir à établir une connexion avec le bâtiment) ! L'exemple ci-dessous montre un cas de figure plus classique dans le monde MCR/CVC :

Telegram
Smartphone interaction

Avec notre plateforme Digimat® WebGate (cloud alarming), nous proposons déjà depuis longtemps le support de la transmission des alarmes par Email, SMS (via BulkSMS), Pushover, Digimat® Cloud Printer, etc. La transmission des alarmes via WhatsApp est également supportée à titre officieux, mais cette plateforme n'est pas une solution ouverte. Telegram semble enfin offrir une sérieuse alternative à WhatsApp ! Telegram est disponible gratuitement pour iOS, Android, OSX, Windows et Linux. La plateforme de transmission Digimat®-Telegram est actuellement en test sur nos serveurs.

Nous utilisons l'infrastructure cloud DCF pour générer et transmettre avec l'alarme l'image des synoptiques concernés ! En utilisant le principe du groupe de discussion, les utilisateurs peuvent par exemple "chater" ensemble lorsqu'une alarme est reçue.

Le côté interactif (chat) peut également être exploité sur cette plateforme. On peut aisément imaginer pouvoir quittancer une alarme par l'envoi d'un message, ou encore obtenir sur demande la liste des alarmes actives sur un site, avec génération automatique des synoptiques concernés en temps réel. Le tout sans aucun logiciel spécifique !

Le "chat" n'est alors plus forcément un simple gadget pour jeune, mais un réel canal d'information live. L'exemple suivant montre un utilisateur Telegram qui demande au système de lui fournir un bilan énergétique temps réel du circuit de production d'eau glacée d'un centre commercial en activité. Les différentes mesures de puissances sur site sont interrogées par l'infrastructure cloud Digimat® DCF puis modélisées par un diagrame de sankey. Le tout est retourné à l'utilisateur en une simple image. Un jeu d'enfant alors que la technique sous-jacente nécessaire est plutôt impressionnante :

Danfoss XML Interface
Intégration données production froid commercial

L'accès aux données internes des automates de production du froid commercial permet d'optimiser les systèmes de récupération de chaleur (point crucial et sensible dans les installations modernes). Les nouveaux firmwares des automates Danfoss (type AK255) fournissent en standard une interface de communication XML via TCP/IP. Nous avons implémenté ce protocole de manière à pouvoir reprendre sur nos systèmes MCR toutes les mesures souhaitées. Il est ainsi possible de représenter sur les synoptiques MCR les installations de production froid commercial et de suivre les échanges thermiques à distance comme s'il s'agissait d'une installation CVC usuelle.

Pi.IRC
Un IRC pour Geek (et les autres)

Avec Digimat® IO.BOARD, nous développons actuellement une nouvelle génération de régulateurs autonomes. Une carte de 15 entrées/sorties dont 4 entrées analogiques universelles forme la base de ce système. Jusqu'à 6 cartes peuvent être pluggées ensemble par des connecteurs latéraux fournissant un bus local (data+power). Sur la première carte, on installe le plugin processeur. Communication externe via Ethernet TCP/IP et possibilité d'alimentation PoE. Le hardware est déjà opérationel.

N2 OPEN
Pas si ouvert que cela

Les nouveaux régulateurs IRC Johnson TUC03 disposent d'une caractéristique intéressante : il est possible de changer le protocole de communication par un simple switch. On bascule alors du protocole Metasys N2Open vers le protocole BACnet MSTP. Il est donc possible de remplacer les vieux régulateurs IRC (9100) lorsqu'ils sont défectueux par les nouveaux en conservant la communication N2. Lorsque tous les régulateurs auront étés remplacés, la boucle bus peut basculer sur BACnet (système ouvert) sans remplacer le câblage ! N2 est implémenté depuis l'origine dans les systèmes Digimat®, mais les TUC03 parlent le N2Open. Malgré de nombreuses demandes, Johnson ne donne pas accès à ce protocole "open". Nous l'avons donc décodé par reverse engineering ;) et nous mettons à disposition le fruit de nos recherches. Le module Python digimat.n2 permet de décoder les trames N2Open. Il est librement téléchargeable sur PyPi.

ESPA
DECT ALARMING

La transmission d'alarme DECT via protocole ESPA est implémentée depuis de nombreuses années dans nos systèmes. Il arrive régulièrement qu'il faille mettre en place des bancs de tests ESPA pour valider la transmission des alarmes sur du nouveau matériel. Les logiciels ESPA publiquement disponibles sont souvent dépassés et peu modulables. Nous avons mis au point un module Python digimat.espa librement téléchargeable sur PyPi permettant d'implémenter rapidement des clients+serveurs ESPA. L'exemple ci-dessous montre comment créer un serveur ESPA gérant simultanément 2 canaux ESPA. Le genre d'interface que l'on peut acheter assez cher sur le marché ;) Servez vous !

from digimat.espa import LinkSerial, Server, MultiChannelServer

class MyMultiChannelServer(MultiChannelServer):
    def onNotification(self, notification):
        print notification
        if notification.isName('calltopager'):
            print "[%s]->paging(%s, %s)" % (notification.source,
                 notification.callAddress,
                 notification.message)

servers=MyMultiChannelServer()

link=LinkSerial('ts940', 'COM1', 9600, 'N', 8, 1)
servers.add(Server(link))

link=LinkSerial('espa2', 'COM2', 9600, 'N', 8, 1)
servers.add(Server(link))

servers.run()