CH701294A1 - Système multi-protocolaire de contrôle et de gestion d'objets communicants hétérogènes. - Google Patents
Système multi-protocolaire de contrôle et de gestion d'objets communicants hétérogènes. Download PDFInfo
- Publication number
- CH701294A1 CH701294A1 CH00794/10A CH7942010A CH701294A1 CH 701294 A1 CH701294 A1 CH 701294A1 CH 00794/10 A CH00794/10 A CH 00794/10A CH 7942010 A CH7942010 A CH 7942010A CH 701294 A1 CH701294 A1 CH 701294A1
- Authority
- CH
- Switzerland
- Prior art keywords
- objects
- protocol
- possibility
- protocols
- ipv6
- Prior art date
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 6
- 238000004891 communication Methods 0.000 claims abstract description 79
- 230000010354 integration Effects 0.000 claims abstract description 20
- 230000006978 adaptation Effects 0.000 claims abstract description 7
- 238000000034 method Methods 0.000 claims description 18
- 230000007246 mechanism Effects 0.000 claims description 12
- 238000012545 processing Methods 0.000 claims description 11
- 238000005265 energy consumption Methods 0.000 claims description 10
- 238000011161 development Methods 0.000 claims description 7
- 230000003993 interaction Effects 0.000 claims description 7
- 230000008569 process Effects 0.000 claims description 7
- 230000006399 behavior Effects 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 claims description 4
- 238000012423 maintenance Methods 0.000 claims description 4
- 230000002093 peripheral effect Effects 0.000 claims description 4
- 230000000295 complement effect Effects 0.000 claims description 3
- 238000006243 chemical reaction Methods 0.000 claims description 2
- 230000018109 developmental process Effects 0.000 claims 2
- 238000010494 dissociation reaction Methods 0.000 claims 1
- 230000005593 dissociations Effects 0.000 claims 1
- 239000000835 fiber Substances 0.000 claims 1
- 238000000265 homogenisation Methods 0.000 claims 1
- 229920001690 polydopamine Polymers 0.000 claims 1
- 230000009977 dual effect Effects 0.000 abstract description 4
- 238000007726 management method Methods 0.000 description 23
- 230000000875 corresponding effect Effects 0.000 description 12
- 230000009471 action Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000005611 electricity Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000010438 heat treatment Methods 0.000 description 2
- 230000007257 malfunction Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000004378 air conditioning Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000004020 conductor Substances 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 238000001035 drying Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000001667 episodic effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000005406 washing Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
- Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Abstract
L’invention concerne un système d’accès, de contrôle et de gestion multi-protocolaire permettant d’interagir avec des objets hétérogènes utilisant différents protocoles de communication. Notre invention permet d’intégrer ces objets hétérogènes dans une plateforme commune et de les gérer de façon homogène et coordonnée. Notre invention facilite ainsi le déploiement, l’intégration, le monitoring, le contrôle, l’accès, la manipulation, l’interopérabilité, la définition et l’application de règles, la scalabilité, la gestion et l’économie d’énergie ou encore l’intégration d’objets divers dans un système d’adressage de type IPv6. Il permet d’intégrer et d’interagir avec toutes sortes d’objets communicants en l’état, sans requérir d’adaptation particulière du côté des objets. Il permet notamment de nouvelles manières d’interagir avec les objets communicants et d’optimiser la gestion énergétique de bâtiments. Il permet également de développer une architecture réseau duale propice à une intelligence distribuée.
Description
Etat de la technique et quelques problèmes à surmonter:
[0001] Un nombre croissant d’objets intelligents sont présents dans notre environnement. Or, la plupart de ces objets utilisent des protocoles de communications différents et ne peuvent souvent pas communiquer les uns avec les autres. Il est donc difficile de les faire interagir les uns avec les autres, mais également de les gérer à partir d’un système de gestion commun. Selon l’Union Internationale des Télécommunications, le problème de l’interopérabilité est un des principaux obstacles au développement de l’Internet des objets.1 Il s’agit de trouver une solution pour intégrer des objets hétérogènes et fragmentés dans un système de gestion unifié et homogène pour en faciliter la gestion. En l’état actuel de la technique la plupart des solutions développées requièrent soit de développer des passerelles entre deux protocoles (solution relativement lourde et rigide), soit d’adapter les objets eux-mêmes à un protocole de communication commun. Un enjeu est de rendre possible de façon facile et économique l’interopérabilité entre des objets communicants hétérogènes utilisant des protocoles de communications différents sans devoir modifier ces objets eux-mêmes.
[0002] Certains protocoles de communication sont particulièrement adaptés à certains contextes. Ainsi, dans le cadre des protocoles sans fil, les capteurs sans fil ont besoin de protocoles économes en consommation énergétique, tels que ZigBee ou 6LoWPAN; alors que des caméras vidéos sans fil auront besoin d’autres protocoles mieux adaptés au transfert rapide de flux de données plus importants, tels que WiFi par exemple. Vouloir utiliser le même protocole de communication pour les deux cas de figure serait sub-optimal. Or, il serait utile de pouvoir permettre à ces différents appareils d’interagir les uns sur les autres. Par ailleurs, certains protocoles de communication sont soumis à des portées de communication limitées. Or, il serait utile de pouvoir bénéficier de ces protocoles tout en s’émancipant des contraintes de portée.
[0003] L’émergence d’un nouvel Internet étendu aux objets communicants requiert de nouveaux modèles et de nouveaux moyens d’accès aux objets. Il s’agit dés lors d’exploiter la puissance d’IPv6 pour gérer un univers large et complexe d’objets communicants. L’émergence du nouveau protocole IPv6 permettra d’utiliser sa grande capacité d’adressage pour attribuer des adresses directement à des objets. Or, nombre de ces objets intelligents ne sont pas adapté à ce nouveau protocole. Il serait utile de pouvoir permettre à ces objets de bénéficier d’adresses IPv6 sans devoir modifier les objets en question. Il s’agit de permettre l’intégration d’objets non compatible avec IPv6 dans un univers d’objets IPv6.
[0004] La fragmentation des objets communicants limite également les possibilités de les gérer de façon intégrée et holistique. Or, un système permettant d’intégrer l’ensemble des objets communicants et de gérer des paramètres complémentaires permettrait certainement d’améliorer l’automation des bâtiments. Cela permettrait notamment de réduire la consommation énergétique des bâtiments en prenant en compte différents paramètres pertinents provenant de différentes sources (par exemple: capteurs de température et de présence, planification d’utilisation des espaces, actuateurs de différents types, information sur le prix de l’énergie, etc.). Il s’agit de rendre possible une gestion holistique des objets intelligents.
Brève description de l’invention
[0005] La présente invention propose de résoudre les problèmes de l’état de la technique cités ci-dessus grâce à un système d’accès, de contrôle et de gestion d’objets communicants caractérisé par le fait que:
le système comprend au moins un serveur relié à au moins une mémoire de données;
le système comprend au moins une interface multi-protocolaire connectée au serveur qui permet une connectivité avec des objets communicants hétérogènes pouvant utiliser différents protocoles,- cette ou ces interfaces pouvant être dissociées physiquement du ou des serveurs tout en restant connectées aux serveurs par le biais d’un protocole principal;
le serveur peut utiliser un protocole principal, tel qu’IPv6, pour adresser et communiquera distance avec la ou les interfaces multi-protocolaires et/ou directement avec des objets comprenant le protocole principal;
le système utilise un métalangage qui permet de ramener les informations et instructions spécifiques transmises par les différents protocoles de communication dans un langage générique, permettant ainsi une forme d’abstraction des objets hétérogènes utilisant différents protocoles en les ramenant dans un référentiel commun,- rendant ainsi possible une forme d’interopérabilité entre les objets ainsi que la définition et l’application de règles ou algorithmes applicables par le système de façon transversale à des objets hétérogènes;
le système utilise une architecture modulaire et le métalangage pour faciliter l’intégration de nouveaux protocoles au système, chaque nouveau protocole pouvant dés lors interagir à travers le métalangage avec des objets de tous les autres protocoles déjà installés;
le système peut gérer de façon intégrée des informations et des objets hétérogènes qui utilisent différents protocoles de communication, y compris des protocoles archaïques, sans requérir d’adaptation particulière du côté des objets;
le système permet l’utilisation d’une interface graphique utilisateur commune pour l’ensemble des objets hétérogènes gérés par le dit système;
le système permet une gestion holistique d’un environnement et des objets hétérogènes qui s’y trouvent, avec par exemple une meilleure gestion énergétique des espaces gérés par le dit système;
[0006] le système pouvant aussi contribuer par exemple à faciliter le déploiement, l’intégration, le monitoring, le contrôle, l’accès, la manipulation, l’interopérabilité, la scalabilité, la gestion et l’économie d’énergie ou encore l’intégration d’objets divers dans un système d’adressage de type IPv6.
Liste des dessins
[0007] L’invention va être exposée de manière plus détaillée à l’aide d’un exemple de réalisation représenté dans les dessins suivants:
<tb>Fig. 1 <sep>Système global
<tb>Fig. 2 <sep>Système de contrôle central
<tb>Fig. 3<sep>Carte multi-protocolaire
<tb>Fig. 4<sep>Architecture software carte multi-protocolaire
<tb>Fig. 5<sep>Métalangage protocolaire
<tb>Fig. 6<sep>Métacouche du métalangage
<tb>Fig. 7<sep>Structure modulaire du middleware
<tb>Fig. 8<sep>Architecture protocolaire modularisée
<tb>Fig. 9<sep>Structure réseau duale
<tb>Fig. 10<sep>Dislocation des couches protocolaires basses et hautes
<tb>Fig. 11<sep>GUI multidimensionnelle
<tb>Fig. 12<sep>Adresses IPv6 virtuelles (proxy IPv6 pour des objets non compatibles)
<tb>Fig. 13<sep>Optimisation de la gestion énergétique(système multi-courbes)
<tb>Fig. 14<sep>Interaction avec le réseau électrique
<tb>Fig. 15<sep>Actuateurs IPv6
Glossaire - explication de certains termes
[0008] Protocole:Nous entendons par protocole, un protocole de communication utilisé par des appareils pour communiquer entre eux. Un protocole peut être d’une certaine manière assimilé à un langage.
[0009] Métalangage: Nous entendons par métalangage, un langage générique utilisé par le système et dont les instructions et commandes peuvent être traduites en des instructions et commandes équivalentes dans différents protocoles de communications. Le métalangage réunit les instructions qui permettent d’abstraire les instructions spécifiques des différents protocoles de communication en un langage commun.
[0010] Module protocolaire: Nous entendons par module protocolaire un élément de code qui permet de traiter tout ou partie d’un flux de données d’un protocole de communication particulier.
[0011] Module applicatif: Nous entendons par module applicatif, un élément de code qui permet de traduire les instructions et commandes contenues dans la couche applicative d’un protocole de communication vers le métalangage et vice-versa.
[0012] Interface multi-protocolaire: Nous entendons par interface multi-protocolaire une carte ou un composant pouvant supporter plusieurs interfaces physiques pour assurer la connectivité physique avec des objets pouvant utilisant différents protocoles de communication; l’interface ayant au minimum une interface physique protocolaire, mais le plus souvent plusieurs interfaces physiques protocolaires. Objets: Nous entendons généralement le terme objets, dans le sens d’objets communicants, pouvant être de différentes natures, tels que des capteurs, des actuateurs, des appareils ou tout autre objet à même de transmettre et/ou de recevoir des données.
[0013] Objets hétérogènes: Nous entendons par objets hétérogènes, un ensemble d’objets tels que définis précédemment et pouvant contenir des objets qui utilisent un nombre variable de protocoles de communication différents, de un à plusieurs.
[0014] Protocole principal: Nous entendons par protocole principal, le protocole utilisé par le ou les serveurs pour communiquer avec les interfaces multi-protocolaires.
Description détaillée de l’invention
[0015] Comme indiqué dans les revendications, la présente invention concerne un dispositif d’accès, de contrôle et de gestion multi-protocolaire permettant d’interagir avec des objets hétérogènes utilisant différents protocoles de communication. Notre invention permet d’intégrer ces objets hétérogènes dans une plateforme commune et de les gérer de façon homogène et coordonnée. Notre invention permet notamment de:
Faciliter le déploiement et l’intégration d’objets communicants hétérogènes;
Résoudre le problème de l’interopérabilité entre des objets communicants utilisant des protocoles de communication incompatibles;
Gérer de façon intégrée et quasi holistique un ensemble d’objets, de paramètres et d’informations hétérogènes;
Intégrer des objets non compatibles avec IPv6 dans un environnement et un réseau de type IPv6;
Faciliter la gestion à distance des objets domotiques;
Réduire et optimiser la consommation énergétique des espaces contrôlés par le système;
Disposer d’un métalangage qui permet d’interagir de façon homogène avec les différents protocoles de communication;
Editer et appliquer facilement des règles et des algorithmes qui transcendent les spécificités des différents protocoles de communication;
Associer librement différents protocoles de communication;
Gérer des objets communicants existants en l’état, sans requérir la moindre adaptation du côté des objets en question;
[0016] Notre invention est constituée de plusieurs éléments novateurs qui constituent ensemble un système de contrôle et de gestion puissant et performant. Certains des éléments du système peuvent cependant être utilisés de façon indépendante. La présente description constitue un premier mode de réalisation, étant entendu que l’invention peut être matérialisée de différentes manières et selon différentes combinaisons des éléments novateurs.
Système global
[0017] Notre système global constitue notamment un système d’accès, de contrôle et de gestion d’objets communicants (appareils, capteurs, actuateurs, etc.) caractérisé par le fait qu’il peut gérer de façon intégrée des informations et des objets hétérogènes qui utilisent différents protocoles de communication,- permettant ainsi de faciliter le déploiement, l’intégration, le monitoring, le contrôle, l’accès, la manipulation, l’interopérabilité, la définition et l’application de règles, la scalabilité, la gestion et l’économie d’énergie ou encore l’intégration d’objets divers dans un système d’adressage de type IPv6; et surtout la possibilité d’intégrer et d’interagir avec toutes sortes d’objets communicants en l’état, sans requérir d’adaptation particulière du côté des objets.
[0018] La fig. 1 est un schéma de principe de notre système multi-protocolaire de contrôle et de gestion des objets communicants. Sur cette figure:
<tb>A<sep>indique le système de contrôle central
<tb>B<sep>indique la connexion réseau (p.e. de type IPv6) entre le système de contrôle et les cartes mufti-protocolaires et/ou des objets connecté à ce réseau.
<tb>C<sep>indique la ou les cartes multi-protocolaires
<tb>D<sep>indique les objets communicants utilisant divers protocoles de communication
<tb>E<sep>indique des objets communicants compatibles avec le réseau utilisé en B
<tb>F<sep>indique l’interface graphique utilisateur
<tb>G<sep>indique un serveur externe
<tb>H<sep>indique des informations externes
Système de contrôle central
[0019] Le système de contrôle central remplit plusieurs fonctions, et notamment:
Assurer l’interopérabilité entre les différents protocoles de communication et assurer la conversion des informations vers le métalangage.
Gérer des règles et des algorithmes à appliquer aux objets et aux événements
Générer l’interface graphique utilisateur
Permettre la maintenance et la configuration du système
Gérer et stocker les informations pertinentes, notamment les informations qui remontent de la périphérie
[0020] Le système de contrôle central peut être installé sur un ordinateur quelconque ou dans un système embarqué.
[0021] La fig. 2 présente le schéma de principe d’un exemple de système de contrôle central. Sur cette figure:
<tb>A<sep>indique le système de contrôle central
<tb>B<sep>indique la partie d’interface graphique utilisateur
<tb>C<sep>indique la base de données
<tb>D<sep>indique les modules protocolaires (middleware)
<tb>E<sep>indique les modules applicatifs (middleware)
<tb>F<sep>indique le kernel
<tb>G<sep>indique les modules de service
<tb>H<sep>indique le mini serveur web embarqué (web services)
[0022] GUI - interface graphique utilisateur (B): Cette interface permet à l’utilisateur de configurer son système et de le piloter. Dans le cas présent, l’interface est générée via un serveur web, ce qui permet son affichage et son utilisation depuis divers appareils disposant d’un navigateur Internet. Cette partie peut être découplée du noyau central et être installée sur une autre machine afin d’alléger la charge du serveur et réduire son temps de latence. L’accès à la GUI peut bénéficier de mécanismes d’authentifications et de sécurisation standards. La GUI permet notamment de:
Gérer et configurer le système, y compris les cartes multi-protocolaires (voir et modifier leur paramétrage)
Naviguer dans les périphériques et les gérer (voir leurs caractéristiques, les modifier)
Exécuter des actions sur des périphériques
Exécuter des scénarios
Gérer les règles et leurs critères de déclenchements
Gérer les logs systèmes et les alarmes
[0023] Base de données (C): La base de données stocke tous les éléments persistants du système. On y retrouve les informations concernant notamment:
les périphériques reconnus
les cartes reconnues
les modules protocolaires installés
les modules applicatifs installés
les modules de services installés
la nomenclature du système (les familles de périphériques, les actions permises sur ces périphériques)
la liste des règles (comportement du système face à un événement d’un périphérique, ainsi que les critères de leur déclenchement)
les éléments de localisation spatiale (bâtiment, étage, pièce, type de pièce)
les logs systèmes
[0024] Une partie réservée de la base de données permet de stocker des informations propres aux modules de service. Pour des raisons de sécurité, cette zone est distincte de la zone principale.
[0025] Modules protocolaires (D): Les modules protocolaires sont des bundles OSGI qui ont tous la même interface standardisée. Ils permettent d’utiliser un protocole de communication spécifique.
[0026] Modules applicatifs (E): Les modules applicatifs sont des bundles OSGI qui ont tous la même interface standardisée. Ils permettent de piloter et d’interpréter les événements d’un périphérique ou d’un groupe de périphérique d’un constructeur. Ils reposent sur un module protocolaire pour la communication bas niveau.
[0027] Kernel (F): Le kernel est un bundle OSGI. Il est le chef d’orchestre des différents éléments de haut niveau. Son rôle est notamment de:
Recevoir les événements des périphériques et de les traiter (chercher les règles associées, les ordonner et les exécuter selon différents critères).
Assurer le bon déroulement des règles en fournissant le contexte d’exécution (paramètre du périphérique, moteur d’exécution, sdk pour faciliter l’écriture de règle).
Recevoir les événements internes et les traiter (créer et gérer les nouveaux éléments - carte, périphérique,...).
Gérer les règles programmées (schedule).
[0028] Modules de service (G): Les modules de service sont des bundles OSGI qui ont tous la même interface standardisée. Ils sont utilisés comme librairies de fonctions. Ces dernières peuvent être appelées dans des règles... Ils permettent donc d’étendre très facilement les capacités du système, sans avoir besoin de toucher le cœur de ce dernier.
[0029] Serveur web embarqué (H): Le mini serveur web embarqué expose un certain nombre de web services permettant à une entité externe (telles que la GUI) d’interagir avec le système de contrôle central.
[0030] L’API offerte permet notamment de:
exécuter un scénario
exécuter une action sur un ou plusieurs périphériques
informer le serveur d’une modification externe dans la base de données
Carte multi-protocolaire
[0031] Nous avons développé une carte multi-protocolaire qui permet d’assurer la connectivité physique avec des objets hétérogènes utilisant différents protocoles de communication, tels que ZigBee, X10, WiFi, RS232, USB, RFID, KNX, Bluetooth. La carte permet de dissocier du système central la connectivité physique avec les objets communicants. Cela permet aussi de contrôler à distance des objets qui ont une portée de communication réduite.
[0032] La fig. 3 indique l’architecture hardware d’un exemple de carte multi-protocolaire pouvant être utilisée par le système. Sur cette figure:
<tb>A<sep>indique le système de contrôle central.
<tb>B<sep>indique la connexion réseau entre le système de contrôle et la carte multi-protocolaire.
<tb>C<sep>indique la carte multi-protocolaire.
<tb>D<sep>indique le module de connexion physique au réseau qui peut utiliser différents supports physiques (Ethernet, WiFi, PLC, fibre optique, etc.).
<tb>E<sep>indique l’unité de traitement de la carte, englobant une CPU sur laquelle peut tourner un OS embarqué (type Windows CE ou EmDebian par exemple), de la RAM et une mémoire FLASH pour le stockage non volatile de données (p.e. paramètres de configuration de filtrage de firewalling) et de logiciels.
<tb>G<sep>indique des interfaces physiques de différents protocoles.
<tb>H<sep>(optionnel) indique un ou plusieurs ports USB permettant d’ajouter des dongles avec interface USB afin de faire évoluer facilement la carte et d’élargir le nombre de protocoles gérés.
<tb>J<sep>(optionnel) indique un dongle protocolaire avec interface USB.
<tb>K<sep>indique les objets communicants.
<tb>L<sep>(optionnels) indique des capteurs ou des connecteurs pour des capteurs.
<tb>M<sep>(optionnels) indique des actuateurs ou des connecteurs pour des actuateurs.
<tb>N<sep>indique l’alimentation de la carte qui peut être de plusieurs natures: une alimentation via un convertisseur AC/DC externe (un adaptateur secteur) ou une alimentation 230V avec un convertisseur AC/DC embarqué sur la carte (p.e. dans le cas ou il s’agit d’injecter le signal PLC directement sur le réseau électrique).
[0033] La carte multi-protocolaire dispose de sa propre adresse IPv6. Elle se connecte à un ou plusieurs systèmes centraux de contrôle qui disposent chacun de leur propre adresse IPv6. La relation carte - système central est par défaut une relation client -serveur, afin de faciliter la déclaration et l’intégration des cartes dans le système de contrôle central. Cependant, la carte peut aussi répondre à des demandes de connexions d’un système de contrôle externe vers la carte via un service web embarqué. Cela permet notamment la maintenance et la configuration des cartes depuis une adresse différente de celle du système de contrôle central. Cela permet aussi, lorsque les besoins de connexions sont très épisodiques, de n’ouvrir ces connexions que lorsque le système de contrôle central le juge utile. Le cas échéant, et afin d’éviter les connexions abusives, la carte multi-protocolaire est capable de filtrer les connexions entrantes par rapport à une liste d’adresses IP et de ports inscrits dans son fichier de configuration enregistré sur la carte.
[0034] La fig. 4 indique l’architecture software de la carte multi-protocolaire utilisée pour le démonstrateur. Sur cette figure:
<tb>A<sep>indique les pilotes nécessaires pour l’utilisation du hardware de la carte.
<tb>B<sep>indique le système d’exploitation embarqué qui fait abstraction de la partie hardware et qui comprends les pilles protocolaires de bas niveau nécessaires pour la communication avec les périphériques tels que les objets connecté et le système de contrôle central (p.e. TCP/IPv6, UART, USB, HCI,...).
<tb>C<sep>indique la librairie qui fait abstraction de la gestion de communication entre le système de contrôle central et la carte multi-protocolaire. Cette librairie permet une connexion fiable bidirectionnelle pour chaque «Daemon protocol» vers le système de contrôle central.
<tb>D<sep>indique la librairie «Service Discovery» qui fait abstraction du mécanisme de détection du système de contrôle central.
<tb>E<sep>indique le master daemon dont la responsabilité est de:
– o Utiliser la librairie de «Service Discovery» pour trouver un système de contrôle central et de s’annoncer auprès de celui-ci.
– Permettre la configuration à distance de la carte multi-protocolaire.
– Détecter la présence et/ou l’activation de nouvelles interfaces physiques sur la carte multi-protocolaire (p.e. le branchement d’un dongle KNX) et de lancer le daemon protocolaire correspondant),
– Détecter l’absence et/ou la désactivation d’interfaces physiques sur la carte multi-protocolaire et de stopper le daemon protocolaire correspondant.
– Détecter l’inactivité d’un daemon (p.e. du à un malfonctionnement) et de le redémarrer
<tb>F<sep>indique un ou plusieurs «daemons protocolaires». Pour chaque pilote utilisé sur la carte multiprotocolaire (UART, KNX, Bluetooth,...) correspond un daemon.De cette façon, un dysfonctionnement d’un daemon ne perturbe pas les autres daemons. La responsabilité d’un daemon protocolaire est de:
Transférer les données envoyées par un objet connecté à la carte multi-protocolaire, et disponibles à travers le pilote correspondant, vers le système de contrôle central en utilisant la «Data Exchange Library».
Transmettre à un objet branché sur la carte multi-protocolaire les données envoyées par le système de contrôle via le pilote correspondant,
Eventuellement incorporer les couches basses d’une pile de protocole donnée.
Annoncer la disponibilité d’une interface sur la carte multi-protocolaire au système central.
Serveur externe
[0035] Notre système permet d’utiliser les services d’un serveur externe pour partager et récupérer des informations, des modules protocolaires ou des éléments programmés. Il peut faciliter l’identification et le téléchargement de modules protocolaires appropriés et authentifiés lors de la découverte de nouveaux objets par le système.
Métalangaqe protocolaire générique
[0036] Pour faciliter l’interopérabilité entre les objets, nous avons créé un langage générique qui couvre les différentes fonctions et instructions des protocoles de communication que l’on souhaite intégrer. Faute de terme plus explicite, nous avons appelé ce langage générique: «métalangage». Ce métalangage facilite la translation vers et entre les couches applicatives des différents protocoles utilisés. La traduction des instructions et commandes des protocoles de communication vers et depuis le métalangage est effectuées par le biais de «module applicatifs». Ces modules applicatifs peuvent dans certains cas se résumer à une sorte de dictionnaire bilingue qui traduit les instructions et commandes spécifiques du protocole de communication vers et depuis les instructions équivalentes du métalangage du système. L’ajout de nouveau protocole devient dés lors aisé, puisqu’il suffit de développer le «module applicatif» qui traduit les instructions spécifiques d’un protocole de communication vers le métalangage et vice-versa. Cela permet au métalangage d’interagir avec tous les objets utilisant les protocoles de communication intégrés à l’aide des modules applicatifs. Cela permet également à des objets utilisant des protocoles’différents d’interagir les uns avec les autres à travers le métalangage. Cela permet un gain de temps en termes de développement et d’extension à de nouveaux protocoles. Cela a de plus un effet exponentiel sur le nombre d’interactions inter-protocolaires possibles, puisque chaque nouveau protocole, peut en principe interagir avec tous les protocoles déjà intégrés via le métalangage. Ce métalangage peut être développé de façon ad hoc en partant des protocoles visés, avec la possibilité d’un développement incrémental avec l’intégration de nouveaux protocoles et/ou l’apparition de nouvelles fonctions dans les protocoles déjà intégrés. Ce métalangage peut aussi être standardisation.
[0037] La fig. 5 indique le principe de la couche de métalangage. Sur cette figure:
<tb>A<sep>indique les différents protocoles particuliers.
<tb>B<sep>indique des modules applicatifs qui traduisent les instructions des protocoles particuliers en instructions standardisées du métalangage.
<tb>C<sep>indique le métalangage utilisé par le système de contrôle.
<tb>D<sep>indique le système de contrôle qui utilise le métalangage.
[0038] Par exemple, une instruction KNX «DTP_Switch» données pour allumer un appareil sera traduite par le «module applicatif KNX» en métalangage avec l’instruction équivalente «Set_OnOff[1]». Cette même instruction pourra aussi être retraduite par le «module applicatif X10» en langage X10 avec l’instruction binaire pour «On»: «00101».
Métacouche du métalangage (Modèle OSI +1)
[0039] Si l’on se réfère au modèle des couches OSI, notre métalangage équivaut à développer une architecture avec une couche supplémentaire d’abstraction utilisant des métadonnées standardisées et qui vient au dessus de la «couche applicative» du modèle OSI. Cela permet de ramener tous les protocoles de communication à un langage commun. Cela permet de manipuler des données et des objets de façon standardisée, quel que soit le protocole de communication utilisé par les objets. Cela facilite le développement du système et l’extension à de nouveaux protocoles, en focalisant le développement sur les modules applicatifs chargés de traduire les instructions entre le protocole (couche applicative) et le métalangage.
[0040] La fig. 6 indique la dislocation des couches basses et hautes. Sur cette figure:
<tb>A<sep>indique les couches classiques du modèle OSI
<tb>B<sep>indique la nouvelle couche de métalangage qui vient se superposer à la couche applicative.
Architecture protocolaire modulaire
[0041] Notre système permet de fragmenter les protocoles en différents modules correspondant à différents niveaux de couches du modèle OSI, afin de pouvoir gérer les communications de façon ad hoc et modulaire. Nous avons généralement dissocié:
Les «interfaces physiques» qui assurent la connectivité physique (couches basses) avec les objets. Ces interfaces physiques sont généralement situées sur les cartes multiprotocolaires et gérées par les pilotes et daemons correspondants; elles peuvent aussi être assurées par le biais de dongles protocolaires connectés sur un port USB.
Les «modules protocolaires» gérés au niveau du middleware qui traitent les couches intermédiaires du protocole de communication non prises en charge par les éléments assurant la connectivité physique.
Les «modules applicatifs» chargés de traiter les couches supérieures et de les traduire en métalangage.
[0042] Certains modules applicatifs peuvent se superposer. Par exemple: un module applicatif UPnP peut appeler un module applicatif spécifique correspondant à l’objet communicant concerné.
[0043] Cela permet notamment de:
Faciliter l’extension du système à de nouveaux protocoles par le simple ajout de nouveaux modules protocolaires.
Gérer de façon optimale les différentes combinaisons de protocoles de communication (couches hautes) et de supports physiques (couches basses); un même protocole pouvant être utilisé sur différents supports physiques.
[0044] La fig. 7 indique la structure modulaire du middleware du démonstrateur. Sur cette figure:
<tb>A<sep>indique un module applicatif, dont le but est de permettre l’abstraction vers le métalangage des fonctionnalités d’un ou de plusieurs types objets connectés aux différent cartes multi-protocolaires. Un module applicatif expose au kernel une liste de méthodes (p.e. heatOn, turnLightOn,...) représentant les fonctionnalités d’un objet concret (p.e. Electrovanne KNX, Lampe X10,..). Un module applicatif peut directement communiquer avec un daemon protocole d’une carte multi-protocolaire (à l’aide de la librairie Data Exchange) ou appeler des méthodes exposé par les divers modulés protocolaires (B) disponibles. Les appels des méthodes peuvent être implémentés de façon synchrone (méthode avec valeur de retour) comme de façon asynchrone (appel d’une procédure avec le retour d’une ou plusieurs valeurs sous forme d’événements).
<tb>B<sep>Indique un module protocolaire, dont le but est de faire abstraction d’une couche protocolaire donnée. Un module protocolaire expose aux modules applicatifs une liste de primitives (méthodes) nécessaires à l’exploitation du protocole. Un module applicatif peut directement communiquer avec un daemon protocole d’une carte multi-protocolaire (à l’aide de la librairie Data Exchange) ou appeler des méthodes exposé par d’autres modules protocolaires (B). Remarques: Les modules applicatifs et protocolaires fonctionnent de manière identique, ils se distinguent seulement par leur niveau d’abstraction. Les modules applicatifs et protocolaires peuvent aussi directement communiquer avec des objets qui se trouvent sur le réseau auquel est connecté le système de contrôle central ainsi que les cartes multi-protocolaires.
<tb>C<sep>indique la librairie «Data Exchange» qui fait l’abstraction de la communication entre le système de contrôle central et les cartes multi-protocolaires. Elle est la contrepartie de la même librairie du coté carte multi-protocolaire.
<tb>D<sep>indique la librairie «Service Discovery» qui fait abstraction du mécanisme de détection du système de contrôle central. Elle est la contrepartie de la même librairie du coté carte multi-protocolaire.
<tb>E<sep>indique la couche réseau (p.e. IPv6) auquel sont connecté le système de contrôle central et les cartes multi-protocolaires.
<tb>F<sep>indique le kernel, qui (à travers de règles et de scénarios) appelle les différentes méthodes exposées par les modules applicatifs ou protocolaires
<tb>G<sep>indique un gestionnaire d’événements possédant un mécanisme de publish/subscribe. Les données envoyées par les objets sont transférées vers ce gestionnaire (publish) et annotées avec un tag correspondant (p.e. RS232). Les événements sont redirigés vers tous les modules protocolaires et applicatifs qui se sont inscrit au tag correspondant (subscribe). Le module qui reconnaît l’événement s’occupe de son traitement (p.e. appelle d’une méthode, émission de nouveaux événements vers le gestionnaire, notification du kernel pour exécution de règles,...). Si aucun module ne peut traiter l’événement (p.e. événement d’un objet inconnu), alors le gestionnaire d’événements informe le kernel de cet événement inconnu. Celui-ci consulte le server externe et télécharge/installe les modules applicatifs et protocolaires qui sont nécessaires pour le traitement de l’événement inconnu.
<tb>H<sep>indique un module service, qui donne au kernel accès à des outils supplémentaires (p.e. envoie de SMS/Email, accès à des logiciel de réservation, ...).
<tb>I<sep>indique le framework (de type OSGI) qui permet le chargement, le lancement, la mise à jour et l’arrêt de modules. De cette façon, l’extensibilité et l’évolution du système de contrôle central est garanti.
[0045] La fig. 8 indique la structure protocolaire modulaire du système. Sur cette figure:
<tb>A<sep>indique les objets communicants utilisant différents protocoles de communication
<tb>B<sep>indique les «interfaces physiques» permettant d’assurer la connectivité avec les objets
<tb>C<sep>indique les «modules protocolaires» permettant de traiter et de mettre en forme les données selon le standard du protocole en question.
<tb>D<sep>indique les «modules applicatifs» permettant de traduire les instructions de la couche applicative vers le métalangage et vice-versa.
<tb>E<sep>indique le système de contrôle qui utilise le métalangage
Structure réseau duale
[0046] Notre système permet de déployer une architecture réseau constituée de deux espaces protocolaires avec:
Un espace central relativement homogène qui est utilisé par le système de contrôle pour communiquer avec les objets ou les cartes multi-protocolaires. Cet espace central peut s’appuyer sur un protocole de type IPv6 (IPv6, 6LoWPAN, etc.);
Un espace périphérique hétérogène situé derrière les cartes multi-protocolaires utilisant différents protocoles de communication pour s’adapter aux contraintes et aux spécificités des objets communicants visés. Cela permet de tenir compte de la portée (distance) des protocoles de communication des objets qui peut être très limitée.
[0047] Cette architecture permet d’optimiser la gestion du réseau central. Elle permet également de contrôler des objets ayant une portée de communication limitée depuis n’importe quelle distance à travers une carte multi-protocolaire.
[0048] La fig. 9 indique la structure duale du réseau recommandée pour le déploiement du système. Sur cette figure:
<tb>A<sep>indique le ou les systèmes de contrôle
<tb>B<sep>indique le réseau central relativement homogène
<tb>C<sep>indique les interfaces multi-protocolaires (carte multi-protocolaire ou appareils équivalents)
<tb>D<sep>indique les réseaux périphériques relativement hétérogènes pouvant être constitués de plusieurs protocoles
<tb>E<sep>indique les objets communicants
Dislocation du traitement des couches basses et des couches hautes des protocoles de communication
[0049] Notre système permet, lorsque cela est opportun, de dissocier les lieux de traitement des couches basses et des couches hautes d’un protocole de communication. Ainsi, les couches basses d’un protocole de communication (connectivité physique) peuvent être traitées par une carte multi-protocolaire; alors que les couches hautes (en particulier la couche applicative) peuvent être traitées par le système de contrôle central. Cela permet de limiter la taille des processus et les besoins de mises à jour en périphérie. Cela permet de disposer d’optimiser la puissance de calcul au niveau du système de contrôle central.
[0050] La fig. 10 indique la dislocation des couches basses et hautes. Sur cette figure:
<tb>A<sep>indique le système de contrôle central qui gère les couches hautes des protocoles
<tb>B<sep>indique la connexion réseau entre le système de contrôle et la carte-multi-protocolaire
<tb>C<sep>indique la carte multi-protocolaire qui gère les couches basses des protocoles
<tb>D<sep>indique les objets communicants
Multiplexage protocolaire:
[0051] Pour faciliter la gestion des flux de communication IP entre le système de contrôle central et les cartes multi-protocolaires, nous avons utilisé un multiplexage protocolaire. Les couches basses des protocoles des objets sont traitées par la carte multi-protocolaire, puis des strings sont transmis dans des paquets IP au serveur pour qu’il gère le traitement des couches hautes du protocole. Chaque protocole est transmis sur un port différent et spécifique. Cela permet d’optimiser la rapidité de traitement des communications, chaque paquet pouvant être directement routé vers le module protocolaire ou le deamon correspondant.
Architecture réseau décentralisée
[0052] Les cartes multi-protocolaires permettent de développer une architecture réseau décentralisée en permettant de filtrer et de traiter certains flux d’information au niveau de la carte elle-même. Par exemple, la carte multi-protocolaire peut filtrer les informations reçues des capteurs de températures et peut décider de ne relayer vers le système de contrôle central que des variables qui ont changé ou de respecter un délai d’attente minimal entre la transmission deux variables de même type. Cela permet d’éviter que des flux d’informations superflues inondent le réseau du système de contrôle central. La carte peut également prendre en charge des règles ne requérant pas l’intervention du système de contrôle central. Par exemple: si la température est supérieure à un certain seuil, la carte multi-protocolaire pourrait donner l’ordre d’elle-même de fermer automatiquement une vanne de radiateur.
[0053] Notre système permet également de faire coexister plusieurs systèmes de contrôle en parallèle. Par exemple: un premier système de contrôle central peut être chargé de gérer la consommation énergétique et les températures des bâtiments contrôlés; alors qu’un deuxième système de contrôle central peut être chargé de gérer les accès et la sécurité des bâtiments. Cela est d’autant plus simple que chaque système de contrôle peut disposer de sa propre adresse Internet. Par ailleurs, l’utilisation d’IPv6 permet d’assurer des connexions directes entre les systèmes de contrôle et les objets et cartes-multiprotocolaires concernés.
[0054] Cette architecture réseau permet de déployer un réseau de façon beaucoup plus modulaire et flexible. Elle permet également une très grand scalabilité du système.
Interface Graphique intuitive et multidimensionnelle
[0055] Nous avons inventé une interface graphique intuitive multidimensionnelle. La plupart des interfaces graphiques reposent sur une architecture et une navigation en arborescence. Nous avons développé une navigation multidimensionnelle qui permet à l’utilisateur de naviguer selon plusieurs axes simultanément pour sélectionner un nombre variable d’objets ciblés. Chaque axe est composé de plusieurs niveaux de précision croissante. Plus l’utilisateur avance sur un axe en ajoutant des critères plus précis de sélection, plus il restreint la liste des objets ciblés. La navigation dans chacun des axes peut être comparée à un processus de zoom multidimensionnel. Cela permet à l’utilisateur une appréhension beaucoup plus intuitive et immédiate des objets qu’il souhaite contrôler. Ce système permet de mieux interagir avec un nombre illimité d’objets. Dans notre démonstration nous avons développé deux axes de base:
Axe de localisation: Cet axe permet de définir la portée spatiale des objets visés en plusieurs étapes: sélection du ou des bâtiments, du ou des étages, du ou des types de pièces, voire de la ou des pièces visées par l’utilisateur.
Axe typologique: Cet axe permet de définir la portée typologique ou catégorielle des objets visés: sélection de types d’objets et/ou d’objets particuliers.
[0056] Notre mécanisme permet très facilement de sélectionner des objets qui seraient difficile à sélectionner dans une approche traditionnelle en arborescence. Par exemple, pour éteindre les lampes et les radiateurs des salles de bains du 3eme et 4eme étage de l’immeuble X. Notre mécanisme de navigation permet d’intégrer facilement des axes supplémentaires. Par exemple: un axe personnel qui permettrait de modifier l’étendue des objets accessibles en fonction d’un utilisateur ou d’un groupe d’utilisateurs.
[0057] La fig. 11 indique un exemple d’application de notre interface graphique multidimensionnelle. Sur cette figure:
<tb>A1<sep>indique la sélection d’un bâtiment
<tb>A2<sep>indique la sélection d’un étage
<tb>A3<sep>indique la sélection d’un type de pièce
<tb>A4<sep>indique la sélection d’une pièce
<tb>B1<sep>indique la sélection d’une grande catégorie d’objets
<tb>B2<sep>indique la sélection d’une famille d’objets particulière
<tb>B3<sep>indique la sélection d’un objet particulier
<tb>C<sep>indique une zone optionnelle d’affichage des informations sur les objets correspondant aux critères de filtre
<tb>D<sep>indique une zone optionnelle d’affichage des actions possibles sur les objets correspondant aux critères de filtre
<tb>E<sep>indique une zone optionnelle d’affichage sous forme graphique de la liste des options disponibles lorsque l’on sélectionne un des éléments d’un axe de navigation.
[0058] La sélection des éléments A et B peut se faire par exemple avec de listes déroulantes ou des icônes qui apparaissent dans la zone E lorsque l’on clique sur un des éléments (A1, A2, A3, A4, B1, B2, etc.) et qui correspondent aux options disponibles. Pour faciliter la sélection par l’utilisateur, lorsqu’un des éléments est sélectionné, il modifie dynamiquement la liste des options des autres éléments de sélection qui en dépendent. Par exemple la sélection d’un bâtiment A1 qui ne posséderait que 2 étages modifie et limite les options disponibles en A2 à ces deux étages particuliers, et en A3 et A4 aux pièces disponibles dans le bâtiment sélectionné. L’utilisateur peut aussi directement sélectionner des choix en A2 ou en A3 sans passer par une sélection en A1. Il pourrait ainsi agir sur l’ensemble des salles de bains (A3) de tous ses bâtiments. Les différents éléments sélectionnés sont autant de critères de filtres pour sélectionner les objets correspondants à partir de la base de données du système.
[0059] Ce mécanisme de sélection selon plusieurs critères de filtres, est aussi utilisé par les règles et les scénarios du système pour déterminer la portée d’une action sur un ensemble d’objets donnés. Par exemple: éteindre toutes les chambres du 3eme étage. Ces critères peuvent également être sauvegardés sous forme de «cibles» prédéfinies qui peuvent être réutilisées dans les règles ou les scénarios.
Utilisation d’lPv6 pour un déploiement illimitée et facilité:
[0060] Notre système permet d’utiliser pleinement le potentiel d’IPv6 pour la gestion des objets communicants. L’utilisation du nouveau protocole Internet IPv6 comme vecteur de contrôle des objets, permet de gérer un nombre pratiquement illimité d’objets à distance de façon sécurisée et facilite le déploiement du système. IPv6 nous permet notamment de:
Disposer d’un nombre d’adresses pratiquement illimité pour les objets, ce qui permet une scalabilité pratiquement illimitée du système.
Bénéficier des mécanismes d’auto-intégration de nouveaux objets qui peuvent trouver par eux-mêmes une adresse IPv6 pour s’intégrer au réseau sans requérir de configuration particulière.
Bénéficier des mécanismes de sécurité intégrés, tels que IPSec.
Bénéficier des propriétés d’IPv6 pour la mobilité des objets, qui permettent de conserver une adresse accessible indépendamment du lieu de l’objet.
Adressage IPv6 virtuel
[0061] Notre système permet de facto d’attribuer une adresse IPv6 à des objets qui ne sont pas prévus pour gérer IPv6. Cela permet notamment d’intégrer des objets hétérogènes non compatibles avec IPv6 dans un réseau IPv6. Notre système sert alors de proxy IPv6 pour permettre à des applications d’accéder à ces objets via IPv6. Cela nous permet de contrôler et de communiquer via IPv6 avec des objets qui intrinsèquement ne comprennent pas IPv6. De fait, cela nous permet d’étendre directement le réseau Internet à des objets qui n’étaient pas prévus pour Internet.
[0062] La fig. 12 indique un exemple d’adressage IPv6 virtuel. Sur cette figure:
<tb>A<sep>indique une source cherchant à transmettre une information à l’objet X sous la forme d’un paquet IPv6.
<tb>B<sep>indique le webservice qui va écouter et recevoir le paquet de la source A
<tb>C<sep>indique le système central qui va se charger de déterminer comment router l’information et à travers quel protocole. Le système va notamment se charger de convertir les instructions conformément à la couche applicative de l’objet visé.
<tb>D<sep>indique l’envoi d’une instruction équivalente soit directement dans le protocole de l’objet X, soit via une carte multi-protocolaire E.
<tb>E<sep>indique une carte multi-protocolaire
<tb>X et X ́<sep>indiquent un objet communicant qui ne supporte pas le protocole IPv6
[0063] A noter que le flux peut être inverse. De même, si cela est requis, le système peut aussi assurer une communication synchrone.
Extension de 6LoWPAN
[0064] L’architecture modulaire permet d’utiliser des protocoles prévus pour un type de support physique sur d’autres types de supports physiques. Il permet d’envisager des nouvelles combinaisons, telles que l’utilisation de 6LoWPAN sur un support PLC ou Ethernet.
Optimisation de la gestion énergétique
[0065] Notre système permet de gérer de façon beaucoup plus holistique la consommation énergétique de bâtiments. Il permet d’intégrer les différents paramètres et sources d’information dans un cadre de référence commun et d’agir sur l’ensemble des objets et appareils communicants supportés par le système en faisant abstraction du fait qu’ils utilisent différents protocoles de communication. Il permet d’appliquer des règles transversales qui intègrent l’ensemble de ces éléments.
[0066] Notre système permet notamment de gérer la température de locaux selon plusieurs courbes de températures en parallèle. Il permet par exemple d’attribuer à la même pièce:
Une courbe de température T1 de référence lorsque la pièce n’est pas sensée être utilisée;
Une courbe de référence T2 lorsque la pièce est sensée être utilisée, mais qu’aucune présence humaine n’est détectée;
Une troisième courbe de référence T3 lorsqu’une présence humaine est détectée dans la pièce.
[0067] La deuxième courbe (T2) permet de trouver un compromis entre le potentiel d’économie d’énergie et l’inertie thermique de la pièce qui requiert de ne pas avoir une température trop basse pour permettre à la pièce d’atteindre assez rapidement une température satisfaisante (T3, température de confort requise) lorsqu’une personne y entre. Une telle approche permet de réduire la consommation énergétique du bâtiment.
[0068] Notre système permet d’enrichir ces algorithmes de façon quasiment illimitée. Nous pouvons par exemple intégrer dans les règles des dérogations, ou des adaptations des courbes, si l’utilisateur a indiqué au système qu’il souhaitait une température différente à celle proposée initialement par les courbes préprogrammées. Nous pouvons également prévoir des courbes personnalisées pour un utilisateur particulier. Ce mécanisme peut s’appliquer à de nombreux domaines tels que l’hôtellerie et la gestion des bâtiments.
[0069] La fig. 13 indique un exemple appliqué de gestion des courbes de températures selon plusieurs paramètres. Sur cette figure:
<tb>C<sep>indique le système de contrôle central
<tb>S<sep>indique un ou plusieurs capteurs de température
<tb>P<sep>indique un ou plusieurs capteurs de présence
<tb>O<sep>indique un ou plusieurs capteurs d’ouverture de porte
<tb>V<sep>indique un ou plusieurs actuateurs de température, tels que des électrovannes
<tb>R<sep>indique les règles de gestion du système
<tb>E<sep>indique des sources de données complémentaires sur le statut de la chambre, telles que planning d’occupation, check in et check out.
[0070] Dans notre exemple, le système de contrôle central va adapter la température de la pièce contrôlée, telle que des chambres d’hôtel ou des bureaux, selon trois statuts (S1: inoccupée; S2 occupation prévue, mais pas de présence détectée; S3 présence humaine détectée) avec pour chaque statut, une courbe de températures de référence (respectivement T1: température minimale, T2: température intermédiaire et T3: température de confort). Le système de contrôle détermine à partir de la source d’information E (tel que planning d’utilisation, système de réservation, etc.) si la pièce est sensée être utilisée (S2 ou S3) ou non (S1). Si un capteur de présence détecte une présence humaine, le statut passe de S2 à S3. Si le capteur d’ouverture de porte est activé, le système prend en considération que la pièce s’est peut-être vidée et remet le statut en S2 jusqu’à ce qu’une présence soit détectée (si quelqu’un est resté dans la pièce par exemple). S’il s’agit d’un hôtel, le check out du client met automatiquement le statut en S1 si aucune arrivée n’est prévue à court terme. Parallèlement, le système connaît la température de la pièce grâce au capteur S et peut fermer l’actuateur V si la température est supérieure à la température de référence ou ouvrir la vanne si elle est inférieure. Le système de contrôle permet de rédiger des règles de différentes manières, par exemple avec l’introduction de marges dans la comparaison des températures de référence (par exemple: n’agir que si l’écart est supérieur à X°C), ou des mécanismes de proportionnalité dans l’action sur la vanne (par exemple: ouverture de X% par degré d’écart), etc.
Interaction avec le réseau électrique
[0071] Notre système permet également d’interagir avec des services externes. Il permet, par exemple, de gérer la consommation énergétique d’un bâtiment en fonction de l’état de la demande ou du prix sur le réseau. Nous pouvons ainsi récupérer les informations sur le prix de l’énergie sur un marché donné, via par exemple un module service qui questionne un service web, et utiliser cette information pour adapter la gestion énergétique des bâtiments contrôlés par le système. Le système peut réduire la consommation lors des périodes de fortes demandes sur le réseau et consommer d’avantage lors des périodes de faibles demandes. Cela permet d’optimiser la consommation énergétique par rapport à la demande sur le réseau. Cela permet aussi d’envisager de nouveaux modèles facturation dynamique en fonction de la demande sur le marché. Le cas échéant, le système peut ainsi optimiser la facture énergétique par rapport à une facturation dynamique calculée sur un coût variable dans le temps. Il peut aussi servir à optimiser le prix de vente de l’énergie des bâtiments positifs (ayant des sources d’énergies renouvelables). Enfin, le prix de l’énergie étant généralement fortement corrélé à l’état de la demande, notre système peut contribuer à résoudre le problème des pics de demande sur le réseau énergétique en générant un comportement anticyclique par rapport à l’évolution de la demande sur le réseau. Notre système peut ainsi contribuer à atténuer le problème des pics de demande.
[0072] La fig. 14 indique un schéma d’interaction possible entre un bâtiment géré par notre système de contrôle et le réseau électrique. Sur cette figure:
<tb>R<sep>indique le réseau énergétique régional
<tb>F<sep>indique le fournisseur d’énergie
<tb>B<sep>indique le ou les bâtiments qui consomment et éventuellement produisent de l’énergie
<tb>M<sep>indique le prix du marché de l’énergie dont dépend le réseau et qui est transmis au système de contrôle central. Le prix M peut par exemple être mis à disposition par le biais d’un webservice utilisé par le système de contrôle central. Il peut aussi être transmis directement au système de contrôle central dés qu’un changement a lieu sur le marché, afin de permettre une mise à jour en temps réel.
<tb>C<sep>indique le système de contrôle central qui peut adapter le comportement des actuateurs dans le bâtiment en fonction du prix du marché. Il suffit pou cela d’écrire des règles en fonction du prix de l’énergie.
[0073] Lorsque le système de contrôle central reçoit un prix M supérieur à un certain montant, il peut décider de réduire la consommation énergétique dans les bâtiments gérés (B). Il peut par exemple interrompre certains appareils utilisant l’énergie en question (chauffage, climatisation, machines à laver ou à sécher, etc.). Dés que la température M descend au dessous d’un certain seuil, il peut réenclencher les appareils qui avaient été arrêtés. Si nécessaire, il peut aussi décider de limiter certaines interruptions dans le temps, même si le prix reste élevé (pour une chambre froide par exemple). Le système peut aussi prendre en compte des événements passés pour anticiper des pics de demande cycliques et par exemple accroître le chauffage ou le refroidissement d’une pièce avant la période de pointe.
Actuateurs et senseurs IPv6
[0074] Notre système de contrôle peut interagir directement avec des capteurs, des actuateurs et des appareils de type IPv6. Il permet ainsi d’utiliser des interrupteurs contrôlé par un petit contrôleur IPv6 et pouvant communiquer avec le système via PLC (power line communication) ou via d’autres supports physiques (IEEE 802.15.4, Ethernet, etc.). Par ailleurs, ces actuateurs peuvent intégrer des capteurs, tels que des capteurs de température et de présence. La combinaison IPv6 avec PLC permet de faciliter le déploiement des éléments de contrôle dans un bâtiment existant avec un nombre d’objets pratiquement illimité.
[0075] La fig. 15 indique un exemple d’actuateur - senseur IPv6 facilement déployable. Sur cette figure:
<tb>S<sep>indique le système de contrôle central
<tb>L<sep>indique la connexion entre le dispositif et le système de contrôle central. Cette connexion peut être par défaut la ligne électrique elle-même via IPv6 sur PLC, mais alternativement via d’autres supports physiques tels que 802.15.4 de préférence avec 6LoWPAN.
<tb>P<sep>indique l’interface physique du dispositif (PLC, 802.15.4 ou autre)
<tb>W<sep>indique le module IP permettant de gérer les paquets IP entre le dispositif et le système de contrôle central. Ce module peut également effectuer des services de filtrage des adresses et des ports de communication.
<tb>C<sep>indique le contrôleur qui gère notamment le niveau applicatif des paquets.
<tb>D<sep>indique des capteurs
<tb>E<sep>indique des actuateurs, tels que relais électrique.
[0076] Ce dispositif, permet de déployer très facilement un système de gestion domotique dans un bâtiment existant sans requérir de câblage supplémentaire.
Claims (15)
1. Système d’accès, de contrôle et de gestion d’objets communicants caractérisé par le fait que:
– le système comprend au moins un serveur relié à au moins une mémoire de données;
– le système comprend au moins une interface multi-protocolaire connectée au serveur qui permet une connectivité avec des objets communicants hétérogènes pouvant utiliser différents protocoles,-cette ou ces interfaces pouvant être dissociées physiquement du ou des serveurs tout en restant connectées aux serveurs par le biais d’un protocole principal;
– le serveur peut utiliser un protocole principal, tel qu’IPv6, pour adresser et communiquer à distance avec la ou les interfaces multi-protocolaires et/ou directement avec des objets comprenant le protocole principal;
– le système utilise un métalangage qui permet de ramener les informations et instructions spécifiques transmises par les différents protocoles de communication dans un langage générique, permettant ainsi une forme d’abstraction des objets hétérogènes utilisant différents protocoles en les ramenant dans un référentiel commun,- rendant ainsi possible une forme d’interopérabilité entre les objets ainsi que la définition et l’application de règles ou algorithmes applicables par le système de façon transversale à des objets hétérogènes;
– le système utilise une architecture modulaire et le métalangage pour faciliter l’intégration de nouveaux protocoles au système, chaque nouveau protocole pouvant dés lors interagir à travers le métalangage avec des objets de tous les autres protocoles déjà installés;
– le système peut gérer de façon intégrée des informations et des objets hétérogènes qui utilisent différents protocoles de communication, y compris des protocoles archaïques, sans requérir d’adaptation particulière du côté des objets;
– le système permet l’utilisation d’une interface graphique utilisateur commune pour l’ensemble des objets hétérogènes gérés par le dit système;
– le système permet une gestion holistique d’un environnement et des objets hétérogènes qui s’y trouvent, avec par exemple une meilleure gestion énergétique des espaces gérés par le dit système;
le système pouvant aussi contribuer par exemple à faciliter le déploiement, l’intégration, le monitoring, le contrôle, l’accès, la manipulation, l’interopérabilité, la scalabilité, la gestion et l’économie d’énergie ou encore l’intégration d’objets divers dans un système d’adressage de type IPv6.
2. Système selon revendication 1 caractérisé par une architecture modulaire du système et des moyens qui permettent de facilement intégrer de nouveaux éléments de codes, tels que des modules protocolaires ou applicatifs pour faciliter l’évolution du système, avec:
– des modules différents pour les différents protocoles;
– la possibilité de fragmenter le traitement des différentes couches (au sens du modèle OSI) d’un protocole de communication en plusieurs modules relativement indépendants et complémentaires, dont des modules qui assurent la conversion des données entre les couches applicatives des protocoles et le métalangage;
– la possibilité d’utiliser les couches hautes d’un protocole sur des couches basses d’un autre protocole, comme par exemple l’utilisation de 6LoWPAN sur un support de type PLC (Power line communication) ou Ethernet;
– la possibilité d’utiliser un framework de type OSGI (ou équivalent) pour faciliter la gestion et l’intégration de nouveaux modules ou autres éléments de code, sans devoir interrompre le système;
– un mécanisme pour que les instructions supportées par les modules protocolaires ou applicatifs soient enregistrées et connues par le système et permettent au système de filtrer les instructions proposées à l’utilisateur et aux éléments du système lui-même, avec la possibilité également de déclarer les instructions supportées par un module protocolaire ou applicatif dans le code du dit module.
3. Système selon revendication 1 caractérisé par ce que le serveur utilise un métalangage et des moyens pour convertir les différentes instructions et données spécifiques des couches applicatives de différents protocoles de communication dans ce métalangage commun, et inversement, lui permettant de traiter tous les objets selon un langage commun, avec notamment:
– l’homogénéisation des données et des variables au niveau du métalangage;
– la possibilité d’utiliser le métalangage pour permettre l’interopérabilité entre des objets utilisant différents protocoles de communication;
– la possibilité de faciliter l’intégration, l’interaction et l’interopérabilité entre des objets hétérogènes;
– la possibilité de faciliter Pévolutivité du système et l’intégration de nouveaux protocoles de communication, chaque protocole intégré au métalangage étant de fait capable d’interagir à travers le métalangage avec les objets des autres protocoles précédemment intégrés;
– l’utilisation d’une couche supplémentaire au modèle OSI qui vient se superposer aux couches dites «applicatives» des protocoles et qui permet d’intégrer les différents protocoles dans un cadre homogène.
4. Système caractérisé par l’utilisation d’une architecture réseau constituée de deux espaces protocolaires avec: un espace central utilisé par le ou les serveurs, qui est relativement homogène et qui utilise un protocole principal, tel que IPv6; et un espace périphérique hétérogène pouvant utiliser différents protocoles de communication; avec notamment:
– la possibilité de mettre en place une architecture réseau décentralisée permettant à différents serveurs d’interagir simultanément avec différents capteurs, actuateurs, appareils et cartes multi-protocolaires;
– une architecture décentralisée permettant de déploiement d’une intelligence distribuée, notamment à la périphérie;
– la possibilité de faire coexister le système de contrôle et de gestion central avec des sous systèmes de contrôle et de gestion autonomes interagissant avec les objets situés en périphérie,- le système central pouvant décider d’intervenir ou non dans la gestion des objets des sous-systèmes autonomes;
– la possibilité de faire coexister plusieurs systèmes de contrôle chargés de tâches complémentaires.
5. Système selon une des revendication 1 à 4, caractérisé par la dissociation du lieu de traitement des couches basses et des couches hautes des protocoles de communication, ce qui permet notamment d’assurer une connectivité physique de proximité avec les objets et un traitement centralisé des couches applicatives au niveau du ou des contrôleurs, quel que soit la localisation et la distance des objets, avec notamment:
– la possibilité d’utiliser un multiplexage protocolaire, tel que l’utilisation des ports de communication (TCP, UDP ou autre), pour faciliter et accélérer la transmission, le routage et le traitement des flux de données entre la périphérie (interfaces multi-protocolaires ou autres appareils) et le ou les contrôleurs centraux;
– la possibilité d’utiliser des adresses de type IPv6 (telles qu’IPv6 ou 6LoWPAN).
6. Système d’accès, de contrôle et de gestion d’objets communicants caractérisé par l’utilisation d’adresses de type IPv6 (telles qu’IPv6 ou 6LoWPAN) pour adresser et faciliter l’interaction entre les différents éléments du système déployé et notamment pour:
– faciliter le déploiement et l’intégration des éléments du système;
– pouvoir adresser directement les éléments du système à travers des adresses IP;
– permettre, si cela est souhaité, de rendre des éléments du système directement accessibles depuis le réseau Internet;
– assurer la scalabilité du système avec un nombre pratiquement illimité d’adresses disponibles;
– la portabilité des flux de communication sur différents supports physiques;
– le routage des flux de communication;
– et la protection des flux de communication avec des systèmes tels qu’IPSec;
– donner la possibilité d’interagir directement sur des capteurs et des actuateurs utilisant un adressage de type IPv6;
– permettre un déploiement quasiment illimité et facilité d’un réseau d’objets communicants;
– permettre une intégration universelle des objets, des services et des personnes;
– faciliter l’utilisation de différents supports physiques tels que PLC (power line communication), Ethernet, fibre optique et RF (radio frequency).
7. Système d’accès, de contrôle et de gestion d’objets communicants caractérisé par une ou plusieurs interfaces multi-protocolaires comprenant des moyens pour recevoir/envoyer des données selon un ou plusieurs protocoles de communication, lesdites données étant encapsulées dans le protocole principal lors de la communication desdites données avec le serveur,- cette interface assurant une connectivité physique avec des objets communicants, à travers différents protocoles de communication,- et faisant l’interface entre ces objets communicants et un ou plusieurs systèmes de contrôle, avec notamment:
– la possibilité de dissocier la localisation des interfaces multi-protocolaire de celle du ou des contrôleurs centraux, permettant notamment de résoudre les problèmes de portées liées à certains protocoles;
– la possibilité d’utiliser un multiplexage protocolaire, tel que l’utilisation des ports de communication (TCP, UDP ou autre), pour faciliter et accélérer la transmission, le routage et le traitement des flux de données entre la périphérie (cartes multi-protocolaires ou autres appareils) et le ou les contrôleurs centraux;
– la possibilité d’utiliser des adresses de type IPv6 (telles qu’IPv6 ou 6LoWPAN) pour faciliter le déploiement et l’interaction entre les interfaces multi-protocolaires et les contrôleurs centraux;
– la possibilité de filtrer les connexions entrantes selon des critères tels qu’adresse d’origine et port de communication pour protéger les cartes des intrusions non voulues;
– la possibilité de gérer certaines tâches de monitoring et de contrôle au niveau de l’interface multi-protocolaire afin de permettre le déploiement d’une architecture décentralisée avec une intelligence en partie distribuée au niveau des interfaces multi-protocolaires;
– la possibilité d’avoir des éléments protocolaires modulaires qui peuvent être ajoutées ou enlevés de l’interface multi-protocolaire;
– le fait que de pouvoir facilement ajouter des protocoles par l’ajout de dongles protocolaires sur le bus USB de l’interface multi-protocolaire;
– la possibilité d’intégrer au système des objets hétérogènes non compatibles avec le protocole principal, l’interfaces multi-protocolaire assurant alors la connectivité avec les objets en question sans requérir d’adaptation particulière du côté des dits objets et assurant la transmission des informations avec le serveur à travers le protocole principal;
– la possibilité d’intégrer dans le système des objets utilisant des protocoles archaïques pour autant qu’ils soient supportés par l’interface multi-protocolaire.
8. Système selon une des revendications 1 à 7 caractérisé par la possibilité d’intégrer dans une même plateforme des objets hétérogènes utilisant différents protocoles de communication qui leur permet à travers le système d’interagir les uns avec les autres pour permettre notamment:
– de résoudre des problèmes d’interopérabilité entre des objets utilisant différents protocoles de communication;
– faciliter le développement de règles de gestion des objets domotiques grâce à une couche abstraite de métalangage permettant d’intégrer et d’interagir avec des objets hétérogènes à travers des variables et des instructions homogènes;
– de lancer des processus de découverte des nouveaux objets en scannant les différents protocoles disponibles;
– de donner la liberté à l’utilisateur de valider les nouveaux objets découverts avant qu’ils ne soient intégrés dans son réseau d’objets;
– de faciliter Pévolutivité et la maintenance du système;
– d’intégrer des objets utilisant des protocoles archaïques et limités dans des architectures et des systèmes protocolaires plus évolués.
9. Système selon une des revendications 1 à 8, caractérisé par la possibilité d’utiliser un serveur tiers pour le partage et/ou la mise à jour d’informations ou d’éléments de programmes, tels que des drivers, des modules protocolaires, des règles ou des algorithmes, avec notamment:
– la possibilité pour les utilisateurs de partager des ressources ou de faire des développements collectifs;
– la possibilité d’utiliser le serveur externe pour faciliter la maintenance des systèmes;
– la possibilité d’utiliser le serveur externe pour offrir des services.
10. Système d’accès, de contrôle et de gestion d’objets communicants caractérisé par une Interface Graphique d’Utilisation intuitive et multidimensionnelle utilisant un système de navigation multidimensionnel pour accéder et sélectionner des objets, avec notamment la possibilité d’utiliser:
– un axe typologique (objet ou type d’objets);
– un axe topographique (localisation des objets);
– des axes supplémentaires, tels que par exemple un axe personnel permettant d’adapter la sélection des objets en fonction de l’utilisateur ou un axe temporel permettant d’adapter la sélection des objets en fonction de leur accessibilité à l’instant choisi;
– la possibilité d’utiliser cette navigation selon plusieurs axes pour gérer un ensemble d’objets potentiellement volumineux et hétérogène;
– la possibilité d’utiliser ce système pour des interfaces intuitives et de taille réduites pour des appareils portables, tels que téléphones portables, des télécommandes ou des PDA.
11. Système selon la revendication 10, caractérisé par l’affectation d’adresses de type IPv6 (tels qu’IPv6 ou 6LoWPAN), y compris pour des objets non compatibles avec IPv6, permettant notamment au système de servir de proxy IPv6 pour des objets non adaptés à IPv6,- ce qui permet notamment:
– une intégration et un adressage universel des objets, quel que soit leur protocole de communication;
– de servir de proxy entre différents protocoles de communication, et notamment entre IPv6 et les autres protocoles;
– d’intégrer indirectement des objets non compatibles avec IPv6 dans un réseau IPv6, et de permettre un accès qui semble direct à ces objets via des adresses IPv6 spécifiques.
12. Système d’accès, de contrôle et de gestion d’objets communicants caractérisé par l’utilisation d’un protocole de type IPv6 (tel qu’lpv6 ou 6LoWPAN) pour interagir directement avec des appareils, des capteurs et des actuateurs, avec la possibilité d’utiliser un tel protocole sur différents supports physiques et notamment sur un support de type PLC (Power line Communication) pour faciliter leur déploiement dans des bâtiments, avec la possibilité d’utiliser un tel système pour des interrupteurs pouvant être contrôlés à distance et qui peuvent également intégrer des capteurs tels que par exemple: température, présence, lumière et/ou consommation.
13. Méthode ou système caractérisé par une gestion énergétique d’espaces et de locaux selon plusieurs courbes de températures qui sont sélectionnées en fonction du contexte afin d’optimiser la consommation énergétique et de l’adapter aux besoins effectif des usagers, avec:
– la possibilité d’attribuer des courbes spécifiques à des pièces spécifiques;
– une gestion énergétique des espaces selon au moins trois catégories de courbes thermiques:
– les courbes des températures pertinentes pour les pièces qui sont censées ne pas être utilisée;
– les courbes des températures pertinentes pour les pièces qui sont sensées pouvoir être utilisées, mais où aucune présence n’est détectée;
– les courbes des températures pertinentes pour les pièces où une présence humaine est détectée;
– la possibilité de réduire la consommation énergétique en réduisant la température des pièces en fonction de leur utilisation, à des niveaux plus bas lorsque la pièce n’est pas sensée être utilisée ou intermédiaire lorsqu’elle risque d’être (ré-)occupée à court terme de façon à pouvoir atteindre une température de confort dans un délai raisonnable compte tenu de l’inertie thermique;
– la possibilité d’ajouter un nombre illimité de courbes de températures contextuelles pour déterminer des températures de référence, telles que des minima ou des maxima de températures en fonction du moment et du contexte.
14. Méthode ou système caractérisé par la possibilité d’utiliser l’information sur l’état de la demande ou du prix de l’énergie sur le réseau énergétique en question pour adapter le comportement énergétique des bâtiments gérés, avec la possibilité de:
– utiliser le prix de l’énergie sur les marchés comme indicateur de l’état de la demande et pour identifier les pics de demandes;
– réduire la facture énergétique en réduisant la consommation lorsque les prix sont élevés et de privilégier une consommation sur le réseau lorsque les prix et la demande sont bas;
– permettre aux bâtiments disposant d’énergies renouvelables de maximiser les revenus et la quantité d’énergie vendue au réseau électrique lors des périodes de pointes;
– utiliser l’information sur le prix de l’énergie ou l’état de la demande pour adapter le comportement énergétique des espaces ou bâtiments gérés afin de contribuer à réduire le problème des pics de demande sur le réseau électrique par un comportement anticyclique;
– développer un nouveau modèle d’affaire et de facturation basé sur le prix de l’énergie en temps réel du marché.
15. Système caractérisé par la possibilité d’utiliser 6LoWPAN sur d’autres supports physiques que le 802.15.4, tels que Ethernet ou un support PLC, afin entre autre de faciliter le déploiement d’un réseau dans des bâtiments existants ou déjà conçus.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP09163041 | 2009-06-18 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CH701294A1 true CH701294A1 (fr) | 2010-12-31 |
Family
ID=43086167
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CH00794/10A CH701294A1 (fr) | 2009-06-18 | 2010-05-19 | Système multi-protocolaire de contrôle et de gestion d'objets communicants hétérogènes. |
Country Status (2)
| Country | Link |
|---|---|
| CH (1) | CH701294A1 (fr) |
| WO (1) | WO2010146174A2 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112084127A (zh) * | 2020-08-24 | 2020-12-15 | 珠海格力电器股份有限公司 | 分布式控制器及分布式自控系统 |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9565657B2 (en) * | 2014-07-22 | 2017-02-07 | Honeywell International Inc. | IOT enabled wireless one-go/all-go platform sensor network solution for connected home security systems |
| FR3031821B1 (fr) * | 2015-01-15 | 2018-03-02 | Comthings | Systeme de prise de controle d'un dispositif domotique |
| CN104929018B (zh) * | 2015-07-15 | 2017-05-03 | 合肥工业大学 | 一种用于计算压路机施工次数的方法 |
| CN108089450B (zh) * | 2016-11-23 | 2021-04-27 | 阿里巴巴集团控股有限公司 | 智慧建筑控制方法、装置及系统 |
| CN106647577B (zh) * | 2016-12-29 | 2019-11-26 | 福建永东南建设集团有限公司 | 一种建筑智能化集成模块装置 |
| US10412663B2 (en) | 2017-03-21 | 2019-09-10 | Ademco Inc. | Systems and methods for detecting and avoiding radio interference in a wireless sensor network |
| CN109032089A (zh) * | 2018-07-25 | 2018-12-18 | 珠海格力智能装备有限公司 | 工业设备的数据采集方法及装置 |
| US11265725B2 (en) | 2019-02-15 | 2022-03-01 | Ademco Inc. | Systems and methods for allocating wireless communication channels |
| CN111343151A (zh) * | 2020-02-06 | 2020-06-26 | 武汉时波网络技术有限公司 | 一种基于paas模式的能源监管设备管理系统 |
| CN112153125B (zh) * | 2020-09-11 | 2023-08-18 | 福建星网视易信息系统有限公司 | 物联网实现方法、智控盒以及基于物联网的数字娱乐系统 |
| CN112881794A (zh) * | 2021-03-23 | 2021-06-01 | 长春市吉佳通达信息技术有限责任公司 | 一种侵入式低频电能消耗数据采集系统 |
| CN114553745A (zh) * | 2022-01-21 | 2022-05-27 | 浙江航芯科技有限公司 | 一种家长控制装置及方法 |
| CN116032971B (zh) * | 2023-01-10 | 2024-03-22 | 吉林大学 | 一种面向数字孪生机加车间的全要素智能感知实现方法 |
| CN116233283B (zh) * | 2023-05-05 | 2023-07-25 | 湖南盛鼎科技发展有限责任公司 | 一种设备通信协议的动态扩展和热插拔方法 |
| CN117749615B (zh) * | 2024-02-19 | 2024-06-07 | 成都九洲电子信息系统股份有限公司 | 基于对象组合化的采管控通信链路构建方法、系统及装置 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6085238A (en) * | 1996-04-23 | 2000-07-04 | Matsushita Electric Works, Ltd. | Virtual LAN system |
| JP2007081456A (ja) * | 2005-09-09 | 2007-03-29 | Matsushita Electric Works Ltd | 変換装置 |
| JP2007096539A (ja) * | 2005-09-27 | 2007-04-12 | Matsushita Electric Works Ltd | 変換装置 |
| US20090037938A1 (en) * | 2007-07-31 | 2009-02-05 | Tridium Inc. | Programmable control engine on wireless device |
| US20090234512A1 (en) * | 2007-12-28 | 2009-09-17 | Server Technology, Inc. | Power distribution, management, and monitoring systems and methods |
| US20100094981A1 (en) * | 2005-07-07 | 2010-04-15 | Cordray Christopher G | Dynamically Deployable Self Configuring Distributed Network Management System |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0810755B1 (fr) * | 1996-05-31 | 2003-04-16 | Hewlett-Packard Company, A Delaware Corporation | Systèmes et procédés pour le fonctionnement d'une station de gestion de réseau |
| US6785730B1 (en) * | 1999-02-16 | 2004-08-31 | Rebecca S. Taylor | Generic communications protocol translator |
| US8042049B2 (en) * | 2003-11-03 | 2011-10-18 | Openpeak Inc. | User interface for multi-device control |
| US20050234600A1 (en) * | 2004-04-16 | 2005-10-20 | Energyconnect, Inc. | Enterprise energy automation |
| US20070136217A1 (en) * | 2005-12-13 | 2007-06-14 | Peter Johnson | Method and apparatus for remotely monitoring electricity rates |
| US8149849B2 (en) * | 2006-08-31 | 2012-04-03 | Sony Ericsson Mobile Communications Ab | Zigbee/IP gateway |
| KR100874652B1 (ko) * | 2007-06-26 | 2008-12-17 | 한국전자통신연구원 | 이기종 센서네트워크를 위한 통합 인터페이스 장치 및 그방법 |
-
2010
- 2010-05-19 CH CH00794/10A patent/CH701294A1/fr not_active Application Discontinuation
- 2010-06-18 WO PCT/EP2010/058670 patent/WO2010146174A2/fr active Application Filing
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6085238A (en) * | 1996-04-23 | 2000-07-04 | Matsushita Electric Works, Ltd. | Virtual LAN system |
| US20100094981A1 (en) * | 2005-07-07 | 2010-04-15 | Cordray Christopher G | Dynamically Deployable Self Configuring Distributed Network Management System |
| JP2007081456A (ja) * | 2005-09-09 | 2007-03-29 | Matsushita Electric Works Ltd | 変換装置 |
| JP2007096539A (ja) * | 2005-09-27 | 2007-04-12 | Matsushita Electric Works Ltd | 変換装置 |
| US20090037938A1 (en) * | 2007-07-31 | 2009-02-05 | Tridium Inc. | Programmable control engine on wireless device |
| US20090234512A1 (en) * | 2007-12-28 | 2009-09-17 | Server Technology, Inc. | Power distribution, management, and monitoring systems and methods |
Non-Patent Citations (2)
| Title |
|---|
| [Online] Epoque, EPODOC / EPO, JP2007081456 A (MATSUSHITA ELECTRIC WORKS LTD) 12.04.2007 * |
| [Online] Epoque, EPODOC / EPO, JP2007096539 A (MATSUSHITA ELECTRIC WORKS LTD) 12.04.2007 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112084127A (zh) * | 2020-08-24 | 2020-12-15 | 珠海格力电器股份有限公司 | 分布式控制器及分布式自控系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010146174A3 (fr) | 2011-03-31 |
| WO2010146174A2 (fr) | 2010-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CH701294A1 (fr) | Système multi-protocolaire de contrôle et de gestion d'objets communicants hétérogènes. | |
| Al-Qaseemi et al. | IoT architecture challenges and issues: Lack of standardization | |
| US10833947B2 (en) | Remotely assigned, bandwidth-limiting internet access apparatus and method | |
| US10756963B2 (en) | System and method for developing run time self-modifying interaction solution through configuration | |
| CN105765526B (zh) | 通过网络从远程磁盘镜像进行引导 | |
| US8443071B2 (en) | Data server system and method | |
| CN109313543B (zh) | 机器对机器系统中的动态用户界面 | |
| JP6043303B2 (ja) | 産業用フィールド機器を産業用無線ネットワークに結合するためのアダプタ装置、および関連するシステムおよび方法 | |
| CN106161163B (zh) | 一种高集成度的多媒体智能家庭网关、管理系统及电视盒 | |
| WO2015183865A1 (fr) | Passerelle virtuelle | |
| EP3318035B1 (fr) | Procédé de contrôle d'une installation domotique | |
| CN103312715A (zh) | 一种面向Web 服务的家庭网络系统架构 | |
| CN103997521A (zh) | 一种基于路由器的文件操作方法、装置及路由器 | |
| WO2012128719A1 (fr) | Dispositif capteur | |
| Mingozzi et al. | An open framework for accessing things as a service | |
| Sai et al. | Smart Home Messenger Notifications System using IoT | |
| EP3318019A1 (fr) | Installation domotique et procédé de constitution de la topologie d'une installation domotique | |
| WO2016193636A1 (fr) | Procédés de génération de module de code logiciel conditionnel et procédé de contrôle d'au moins une installation domotique d'un bâtiment | |
| Detti et al. | Virtual iot systems: Boosting iot innovation by decoupling things providers and applications developers | |
| Tahir et al. | Wi-Fi Aided Home Energy Management System and AC Prediction through Temperature and Humidity Sensors | |
| EP3679689B1 (fr) | Procédé de configuration et/ou de maintenance d'un système domotique pour un bâtiment et système domotique associé | |
| EP3318017B1 (fr) | Procédé de découverte de la configuration d'une installation domotique | |
| Akribopoulos et al. | Building a platform-agnostic wireless network of interconnected smart objects | |
| WO2018229396A1 (fr) | Procédé de configuration d'un dispositif domotique appartenant à une installation domotique | |
| EP3350967B1 (fr) | Procédé de configuration et procédé de contrôle d'une installation domotique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AZW | Rejection (application) |