Journée Genève Les architectures permettant une l ... · Interopérabilité de base de données Format de la base de donnée est connu Des serveurs logiciels capable de la lire

Innovative Solutions

for BMS Architectures

Les architectures permettant une l’intégration des produits multi constructeurs sur tout protocole ouvert

Etat des lieux et perspectives !

Journée Genève



Newron System La solution GTB du groupe ABB

Société créée en 1993 dont le siège est à Toulouse (FR)

Expert en solutions globales de Gestion Technique du Bâtiment hétérogènes.

Editeur logiciel français spécialisé en « middleware » et multi protocole

Société membre du groupe ABB: pole de développement mondial de l’initiative

Building automation de ABB

Cœur de la solution Building Space ® de ABB

Anime un réseau d’une centaine d’intégrateurs en France et un peu plus

d’installateurs

Leader Européen sur logiciels terrains LonWorks & KNX

Centre de formation agréé en LonWorks, BACnet et KNX

R&D



Le business model différentiant de ABB Un positionnement nouveau sur ce marché ….

ABB n’a pas de pole de service et ne fait pas d’intégration en direct

Fini les GTB copier/coller: apporter de la valeur spécifique

ABB offre solution innovante autour d’un écosystème d’intégrateurs certifiés, formés,

compétents et équipés d’un studio logiciel constructeur performant

Uniquement basé sur des protocoles ouverts et interopérables : KNX, LonWorks et BACnet &

Modbus/M-Bus pour le comptage

Offre de produits mais ouvert à tout produit tiers sur protocole standard

Offre une supervision mais ouvert à tout superviseur ou logiciel tiers

UN BUSINESS MODEL DIFFERENTIANT

|

Slid

e 3

Projet Client final

Newron + Intégrateur

Exécution du projet

Satisfaction client



Les protocoles oui mais pourquoi …

Un réseau

Le protocole est le vecteur d’information réseau

Un réseau qui…

raccorde des équipements ;

interconnecte des lots (CVC, éclairage, ombrage,

détection, E/S…) au sein d’une solution.

… et ses problématiques :

Topologie/Câblage

Bande passante (débit)/Performance

Connectivité/Interopérabilité

Équipements multiconstructeurs

Filtrage des échanges de données



Les protocoles C’est la jungle de chez la jungle!

Les protocoles de GTB existants propriétaires! La GTB vient de la CVC N1 et N2 de JCI, Novanet Sauter, CCN Carrier, Cbus honeywell, ….

Les splits cassette (Toshiba, Mitsubishi, LG, …): avec des passerelles vers de l’ouvert

Des protocoles filaires ouverts et interopérables Standards du monde de la CVC: LonWorks, BACnet

Standards de l’électricité et comptage: KNX, Modbus, M-Bus

Natifs et encapsulables sur IP: BACnet, KNX, Modbus, LonWorks, ….

Les protocoles sans fils Zigbee, Wifi, 6LoPan, Zwave, M-Bus RF, KNX RF, …. Sans pile : En Ocean,

Propriétaires : IO, RTS, waveniss

Les protocoles orientés supervision et hypervision OPC UA, BACnet, oBIX

Les radio long range et faible débit a vocation IoT LoRa, SigFox, Qowisio



Management: logiciels de gestion

• Supervision/Visualisation du site (SCADA/IHM)

• Management de l’énergie (SME)

• (Re)cloisonnement

• Télécommande virtuelle/Tableau de bord web

Automation: Automatismes du bâtiment

• Programmation horaire et calendaire

• Historiques et tendances décentralisés

• Alarmes et gestion locale

• Autres automatismes et régulations PID

Terrain: les automates terminaux

• CVC (régulation centralisée + terminale)

• Eclairages , stores et volets roulants

• Mesure et comptage d’énergie

• E/S déportées (en armoires)

Le contexte protocolaire et interopérabilité Attention a savoir a quel niveau on se place

TERRAIN



Acquisitions (par scrutation ou sur événement)

Traitement local des alarmes

Gestion locale des historiques

Gestion des plages horaires

Passerelles entre protocoles

Script automate

Visualisations Web

Interopérabilité produit Premier niveau interopérabilité

Appareils Capteurs Actionneurs Automates paramétrables

Supports physiques Bus de terrain Paire torsadée (TP), radio (RF), infrarouge (IR), courant porteur (CPL)… Encapsulés sur IP (parfois)

Technologies

Interconnexion des équipements

Le fameux PEER 2 PEER

Gestion individuelle

Communication monoprotocole

Action/Mesure Réaction

Pas ou peu d’interface

Équipements Horizontal



Second niveau interopérabilité Interopérabilité logicielle

Imagerie / gestion alarmes / archives / plage horaires

Gestion énergétique et établissement de rapports

Supervision / conduite de site web

télécommande à distance virtuelle

Hypervision sur Cloud

Interfaces SAP

Superviseur SCADA Poste de conduite de site Serveur web Energy Management

IP

Technologies

( )

Équipements Support physique



Troisième niveau interopérabilité Interopérabilité de base de données

Format de la base de donnée est connu

Des serveurs logiciels capable de la lire

Un contenu exploitable et multi vendeur

Plusieurs logiciels qui les comprenne

Description complète du site

RENOVATION / QUALITE / « NIM »

Description Site Les produits techniques Leur localisation Leur configuration Leurs échanges

Disque dur / Fichier Base de données API / SDK

Technologies

(EDE)

Son role Support physique

LNS

ETS

(CSV)



Quatrième niveau interopérabilité Interopérabilité: bâtiment vers services

NE PAS FIGER LE CLOUD DU FOURNISSEUR

NE PAS SE LIMITER A L’HYPERVISUER CONSTRUCTEUR

Un contenu exploitable et multi vendeur

Plusieurs logiciels qui les comprenne

Description complète du site

RENOVATION / QUALITE / « NIM »

Proposer des données interopérables aux acteurs services Les méthodes d’échanges Les data models

Middleware Framework

Technologies

Son role Support physique

Web services FTP Push XML oBIX BACnet Web Services OPC UA

Label Ready 2 Services



On apprends de l’histoire Genèse de KNX

Bus EIB (European Installation Bus) créé en 1987 par quelques fabricants d’équipements européens du domaine de l’énergie et des techniques du bâtiment.

Interopérabilité « échange de terrain à terrain » (peer to peer : capacité d’échanges entre entités de même nature)

Produits interopérables

Association EIBA créée en 1990

Convergence Batibus-EIBus-EHS Association Konnex en 1997

Konnex KNX

3 modes de configuration : A (Automatic), E (Easy), S (System)

Normalisé ISO/CEI 14543 et CEN EN 13321



KNX : matériels et installations électriques Protocoles GTB

Vision KNX de l’ouverture

Interopérabilité au niveau TERRAIN

Système basé sur l’interopérabilité produit

Plusieurs produits de plusieurs constructeurs

Multiconstructeur

Non interopérable

Pas de liens possibles entre équipements

Ouvert / standardisé / interopérable

Même support de transmission

Liens possibles entre équipements



Protocoles GTB Genèse de LonWorks

Créé en 1988 par la société californienne Echelon

(qui en possède toujours les droits).

Cofondé par Mike Markkula, co-fondateur d’Apple.

Vision réseau / IT : interopérabilité « de terrain à terrain »

Réseau IT : adressage point à point (unicast),

multidiffusion (multicast), diffusion générale (broadcast)

Interopérabilité produit : label LonMark, créé en 1994.

Interopérabilité système : logiciel LNS, créé en 1997.

Standardisé EIA 709.x EIA 852 par Echelon en 1999,puis normalisé EN

14908 en Europe.

Immense succès en commande CVC/bâtiments tertiaires



LonWorks : la filière CVC régulation terminale Protocoles GTB

Vision LonWorks de l’ouverture

Interopérabilité au niveau TERRAIN

Système global avec la supervision

De l’équipement terrain au système

Centralisation Sous-ensembles

propriétaires

Ouvert

Multiconstructeur



Créé par le groupe de travail SPC-135P de l’ASHRAE (American Society of Heating, Refrigerating, and Air conditioning Engineers)

en 1988.

Groupement d’acteurs du CVC ayant déjà leurs propres protocoles de communication :

=> Multiplication des solutions propriétaires ;

=> Consensus : créer un « méta-protocole », standard commun.

Pas besoin d’interopérabilité « terrain vers terrain » mais interopérabilité verticale avec

la supervision: automation vers supervision

De 1995 à 2001 : plusieurs spécifications sur différents supports (TCP/IP, réseau

Ethernet, liaison série RS, protocole LonTalk…)

Aujourd’hui : seulement TCP/IP et MS/TP (maître-esclave à passage de jeton).

Certification BACnet en 2000 : création des laboratoires BTL (BACnet Testing Laboratories)

Plusieurs versions du standard BACnet

Protocoles GTB Genèse de BACnet



Origine BACnet : supervision centralisée CVC

Protocoles GTB

Vision BACnet de l’ouverture

Îlots d’automatisation

Système commun couvrant tout le terrain

Un META protocole standard

Supervision locale

Hypervision

Protocole(s)

Supervision

BACnet

Protocole(s)



Les architectures de GTB Casser les codes des architectures traditionnelles

|

Slid

e

17

Solution centralisée Solution décentralisée

Ces vieilles architectures de GTB traditionnelles ont des limites

La solution centralisée: la vielle solution historique Pas de performance, pas de gestion optimisée des usages, si perte du SCADA ?

La solution décentralisée: la solution des constructeurs Trop chère, surdimensionnée, travaille par ilot, intégration difficile, emprisonne la donnée



Les architectures de GTB Evolution des solutions et convergence IP

|

Slid

e

18



Les architectures de GTB L’architecture distribuée

|

Slid

e

19

Basée sur la convergence IP : IP est le connecteur universel

Moins chère, plus de performances, re-zoning complet possible, sur mesure

Libère la donne sur IP et permet de segmenter le lot GTB



Les architectures de GTB Le câblage suit le design



Les architectures de GTB Le câblage suit le design

|

Slid

e

21



Les architectures de GTB Convergence IP apporte sécurité

Le mode secours en natif et peu onéreux



Quelles tendances Vers UN protocole unique: le HIGHLANDER?

La réponse terrain est évidente: NON !

• L’existant est trop important au niveau terrain

• Le fameux LEGACY anglo saxon

Mais des critères qui portent

• PAN, HOME: Sans fil, profils, battery less, CEM poussée

• BAN, BUILDING: paire torsadée avec IP, profils, standards

La réponse supervision: … POURQUOI PAS …

• BACnet se positionne sérieusement sur ce créneau

• OPC UA comme la dernière norme orientée XML

La réponse SmartBuilding: OUIIIII !

• Besoin nouveau : pas d’existant ouvert et volonté (SBA)

• Impact des frameworks multiprotocolaires

Une convergence IP au niveau du transport!

• Certificats de Sécurité / Big data et gestion des données

• Virtualisation



Quels leaders? La révolution du driver de la technologies !!!

Le tertiaire n’est pas le driver !

Mais la domotique!

IoT: orienté domotique avec des services usagers

• Les business models sont enfin présents

• VRAIE valeur ajoutée pour usager => marché

• Business dans le cloud

Vers une volonté de standardisation

• Thread, Alljoyn, AllSeen Alliance, Hypercat,

Un eco système d’application

• Plus ou moins ouvertes: Homekit APPLE … APP dev

• Google BRIO with Nest …

L’IT pousse et drive le marché

Living Space


for BMS Architectures www.newron-system.com

Serge LE MEN [email protected] 06 20 76 10 81

Documents

Journée Genève Les architectures permettant une l ... · Interopérabilité de base de données Format de la base de donnée est connu Des serveurs logiciels capable de la lire