CH701294A1

CH701294A1 - multi-protocol system monitoring and management of heterogeneous smart objects.

Info

Publication number: CH701294A1
Application number: CH00794/10A
Authority: CH
Inventors: Sebastien Ziegler
Original assignee: Archimede Solutions Sarl; Mandat Internat Fond Pour La Cooperation Internationale; Sebastien Ziegler
Priority date: 2009-06-18
Filing date: 2010-05-19
Publication date: 2010-12-31
Also published as: WO2010146174A2; WO2010146174A3

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.The invention relates to a multi-protocol access, control and management system for interacting with heterogeneous objects using different communication protocols. Our invention makes it possible to integrate these heterogeneous objects in a common platform and to manage them in a homogeneous and coordinated way. Our invention thus facilitates the deployment, integration, monitoring, control, access, manipulation, interoperability, definition and application of rules, scalability, management and energy saving. the integration of various objects into an IPv6 addressing system. It allows to integrate and interact with all kinds of communicating objects in the state, without requiring special adaptation on the side of the objects. It allows new ways of interacting with communicating objects and optimizing the energy management of buildings. It also allows to develop a dual network architecture conducive to a distributed intelligence.

Description

Etat de la technique et quelques problèmes à surmonter:State of the art and some problems to overcome:

[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. [0001] A growing number of intelligent objects are present in our environment. Most of these objects use different communication protocols and often can not communicate with each other. It is therefore difficult to make them interact with each other, but also to manage them from a common management system. According to the International Telecommunication Union, the problem of interoperability is one of the main obstacles to the development of the Internet of Things.1 It is a question of finding a solution to integrate heterogeneous and fragmented objects into a unified management system and homogeneous to facilitate management. In the current state of the art, most of the solutions developed require either to develop bridges between two protocols (relatively heavy and rigid solution), or to adapt the objects themselves to a common communication protocol. An issue is to make interoperability between heterogeneous communicating objects using different communication protocols possible without having to modify these objects themselves in an easy and economical way.

[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. Some communication protocols are particularly adapted to certain contexts. For wireless protocols, for example, wireless sensors require energy efficient protocols such as ZigBee or 6LoWPAN; while wireless video cameras will need other protocols better suited to the fast transfer of larger data streams, such as WiFi for example. To want to use the same communication protocol for both cases would be sub-optimal. However, it would be useful to be able to allow these different devices to interact with each other. In addition, some communication protocols are subject to limited communication ranges. However, it would be useful to be able to benefit from these protocols while emancipating constraints of scope.

[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. [0003] The emergence of a new Internet extended to communicating objects requires new models and new means of access to objects. The goal is to exploit the power of IPv6 to manage a large and complex world of communicating objects. The emergence of the new IPv6 protocol will make it possible to use its large addressing capacity to assign addresses directly to objects. However, many of these smart objects are not adapted to this new protocol. It would be useful to allow these objects to benefit from IPv6 addresses without having to modify the objects in question. This is to allow the integration of objects not compatible with IPv6 in a universe of IPv6 objects.

[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. [0004] The fragmentation of communicating objects also limits the possibilities of managing them in an integrated and holistic manner. However, a system allowing to integrate all the communicating objects and to manage complementary parameters would certainly make it possible to improve the automation of the buildings. This would notably reduce the energy consumption of buildings by taking into account different relevant parameters from different sources (for example: temperature and presence sensors, space utilization planning, actuators of different types, information on the price of electricity, etc.). energy, etc.). This is to make possible a holistic management of smart objects.

Brève description de l’inventionBrief description of the 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;The present invention proposes to solve the problems of the state of the art cited above through a system for access, control and management of communicating objects characterized by the fact that: the system comprises at least one server connected to at least one data memory; the system comprises at least one multi-protocol interface connected to the server that allows connectivity with heterogeneous communicating objects that can use different protocols, - this or these interfaces can be physically dissociated from the server or servers while remaining connected to the servers through 'a main protocol; the server may use a main protocol, such as IPv6, to address and communicate remotely with the multi-protocol interface (s) and / or directly with objects comprising the main protocol; the system uses a metalanguage which makes it possible to bring back the specific information and instructions transmitted by the various communication protocols in a generic language, thus allowing a form of abstraction of the heterogeneous objects using different protocols by bringing them back into a common reference frame, - thus making possible form of interoperability between objects as well as the definition and application of rules or algorithms applicable by the system transversally to heterogeneous objects; the system uses a modular architecture and metalanguage to facilitate the integration of new protocols into the system, each new protocol can then interact through the metalanguage with objects from all the other protocols already installed; the system can seamlessly handle heterogeneous information and objects that use different communication protocols, including archaic protocols, without requiring special adaptation on the object side; the system allows the use of a common graphical user interface for the set of heterogeneous objects managed by the said system; the system allows a holistic management of an environment and heterogeneous objects that are there, with for example a better energy management of spaces managed by the said system;

[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. The system can also contribute for example to facilitate deployment, integration, monitoring, control, access, manipulation, interoperability, scalability, management and energy saving or the integration of various objects into an IPv6 addressing system.

Liste des dessinsList of drawings

[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 IPv6The invention will be explained in more detail with the aid of an exemplary embodiment shown in the following drawings: <Tb> Fig. 1 <sep> Global system <Tb> Fig. 2 <sep> Central Control System <Tb> Fig. 3 <sep> Multi-protocol card <Tb> Fig. 4 <sep> Software architecture multi-protocol card <Tb> Fig. 5 <sep> Protocolal metalanguage <Tb> Fig. 6 <sep> Metalanguage metacolum <Tb> Fig. 7 <sep> Modular middleware structure <Tb> Fig. 8 <sep> Modularized protocol architecture <Tb> Fig. 9 <sep> Dual network structure <Tb> Fig. 10 <sep> Dislocation of low and high protocol layers <Tb> Fig. 11 <sep> Multidimensional GUI <Tb> Fig. 12 <sep> Virtual IPv6 Addresses (IPv6 Proxy for Non-Compatible Objects) <Tb> Fig. 13 <sep> Optimization of energy management (multi-curve system) <Tb> Fig. 14 <sep> Interaction with the electricity network <Tb> Fig. 15 <sep> IPv6 Actuators

Glossaire - explication de certains termesGlossary - explanation of some terms

[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. [0008] Protocol: We mean by protocol, a communication protocol used by devices to communicate with each other. A protocol can be in a way assimilated to a language.

[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. [0009] Metalanguage: We mean by metalanguage, a generic language used by the system and whose instructions and commands can be translated into equivalent instructions and commands in different communications protocols. The metalanguage combines the instructions that make it possible to abstract the specific instructions of the different communication protocols into a common language.

[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. [0010] Protocol module: By protocol module we mean a piece of code that makes it possible to process all or part of a data stream of a particular communication protocol.

[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. Application module: By application module, we mean a piece of code that makes it possible to translate the instructions and commands contained in the application layer of a communication protocol into the metalanguage and 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. [0012] Multi-protocol interface: By multi-protocol interface we mean a card or a component that can support multiple physical interfaces to provide physical connectivity with objects that can use different communication protocols; the interface having at least a protocol physical interface, but most often multiple protocol physical interfaces. Objects: We generally mean the term objects, in the sense of communicating objects, which may be of different natures, such as sensors, actuators, devices or any other object able to transmit and / or receive data.

[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. [0013] Heterogeneous objects: By heterogeneous objects we mean a set of objects as defined above and which may contain objects that use a variable number of different communication protocols, from one to several.

[0014] Protocole principal: Nous entendons par protocole principal, le protocole utilisé par le ou les serveurs pour communiquer avec les interfaces multi-protocolaires. Main protocol: We mean by main protocol, the protocol used by the server or servers to communicate with the multi-protocol interfaces.

Description détaillée de l’inventionDetailed description of the 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;As indicated in the claims, the present invention relates to a multi-protocol access, control and management device for interacting with heterogeneous objects using different communication protocols. Our invention makes it possible to integrate these heterogeneous objects in a common platform and to manage them in a homogeneous and coordinated way. Our invention allows to: Facilitate the deployment and integration of heterogeneous communicating objects; Solve the problem of interoperability between communicating objects using incompatible communication protocols; Manage in an integrated and almost holistic way a set of heterogeneous objects, parameters and information; Integrate non-IPv6 compatible objects into an IPv6 environment and network; Facilitate the remote management of home automation objects; Reduce and optimize the energy consumption of spaces controlled by the system; To have a metalanguage that allows to interact in a homogeneous way with the different communication protocols; Easily edit and apply rules and algorithms that transcend the specifics of different communication protocols; Freely associate different communication protocols; Manage communicating objects existing in the state, without requiring any adaptation on the side of the objects in 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. Our invention consists of several innovative elements that together constitute a powerful and powerful control and management system. Some of the elements of the system can however be used independently. The present description constitutes a first embodiment, it being understood that the invention may be embodied in different ways and in different combinations of the innovative elements.

Système globalGlobal system

[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. Our overall system includes a system for accessing, controlling and managing communicating objects (devices, sensors, actuators, etc.) characterized by the fact that it can manage information and objects in an integrated manner. heterogeneous using different communication protocols, - thus facilitating deployment, integration, monitoring, control, access, manipulation, interoperability, definition and application of rules, scalability, management and energy saving or the integration of various objects in an IPv6 addressing system; and especially the ability to integrate and interact with all kinds of communicating objects in the state, without requiring special adaptation on the side of objects.

[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 externesFIG. 1 is a block diagram of our multi-protocol system of control and management of communicating objects. In this figure: <tb> A <sep> indicates the central control system <tb> B <sep> indicates the network connection (IPv6 type) between the control system and the mufti-protocol cards and / or objects connected to this network. <tb> C <sep> indicates the multi-protocol card (s) <tb> D <sep> indicates communicating objects using various communication protocols <tb> E <sep> indicates communicating objects compatible with the network used in B <tb> F <sep> indicates the graphical user interface <tb> G <sep> indicates an external server <tb> H <sep> indicates external information

Système de contrôle centralCentral control system

[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érieThe central control system performs several functions, and in particular: Ensure interoperability between the different communication protocols and ensure the conversion of information to metalanguage. Manage rules and algorithms to apply to objects and events Generate the graphical user interface Allow maintenance and configuration of the system Manage and store relevant information, including information from the periphery

[0020] Le système de contrôle central peut être installé sur un ordinateur quelconque ou dans un système embarqué. The central control system can be installed on any computer or in an embedded system.

[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)FIG. 2 shows the block diagram of an example of a central control system. In this figure: <tb> A <sep> indicates the central control system <tb> B <sep> indicates the GUI part <tb> C <sep> indicates the database <tb> D <sep> indicates the protocol modules (middleware) <tb> E <sep> indicates the application modules (middleware) <tb> F <sep> indicates the kernel <tb> G <sep> indicates the service modules <tb> H <sep> indicates the embedded web mini server (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 alarmesGUI - graphical user interface (B): This interface allows the user to configure his system and control it. In this case, the interface is generated via a web server, which allows its display and use from various devices with an Internet browser. This part can be decoupled from the central kernel and installed on another machine in order to lighten the server load and reduce its latency. Access to the GUI can benefit from standard authentication and security mechanisms. The GUI makes it possible to: Manage and configure the system, including multi-protocol cards (see and change their settings) Navigate and manage devices (see their features, edit them) Perform actions on devices Run scenarios Manage rules and their triggers Manage system logs and alarms

[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[0023] Database (C): The database stores all the persistent elements of the system. It contains information about: recognized devices recognized cards the protocol modules installed application modules installed installed service modules system nomenclature (device families, allowed actions on these devices) the list of rules (behavior of the system facing an event of a device, as well as the criteria for triggering them) spatial location elements (building, floor, room, room type) system logs

[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. A reserved part of the database makes it possible to store information specific to the service modules. For security reasons, this area is separate from the main area.

[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. [0025] Protocol modules (D): The protocol modules are OSGI bundles that all have the same standardized interface. They allow to use a specific communication protocol.

[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. Application modules (E): The application modules are OSGI bundles that all have the same standardized interface. They allow you to control and interpret the events of a device or device group of a manufacturer. They are based on a protocol module for low-level communication.

[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).Kernel (F): The kernel is an OSGI bundle. He is the conductor of the different elements of high level. Its role is notably to: Receive events from devices and process them (search for associated rules, order them and execute them according to different criteria). Ensure the smooth running of the rules by providing the execution context (device parameter, runtime engine, sdk for easy rule writing). Receive internal events and process them (create and manage new elements - map, device, ...). Manage scheduled rules.

[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. Service Modules (G): The service modules are OSGI bundles that all have the same standardized interface. They are used as function libraries. These can be called in rules ... They allow to easily extend the capabilities of the system, without the need to touch the heart of the latter.

[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. Embedded web server (H): The embedded web mini server exposes a number of web services allowing an external entity (such as the GUI) to interact with the central control system.

[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éesThe API offered in particular allows: run a scenario perform an action on one or more devices inform the server of an external change in the database

Carte multi-protocolaireMulti-protocol card

[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. We have developed a multi-protocol card that ensures physical connectivity with heterogeneous objects using different communication protocols, such as ZigBee, X10, WiFi, RS232, USB, RFID, KNX, Bluetooth. The card makes it possible to dissociate from the central system the physical connectivity with the communicating objects. It also allows remote control of objects that have a reduced communication range.

[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).FIG. 3 indicates the hardware architecture of an exemplary multi-protocol card that can be used by the system. In this figure: <tb> A <sep> indicates the central control system. <tb> B <sep> indicates the network connection between the control system and the multi-protocol card. <tb> C <sep> indicates the multi-protocol card. <tb> D <sep> indicates the physical network connection module that can use different physical media (Ethernet, WiFi, PLC, optical fiber, etc.). <tb> E <sep> indicates the processing unit of the card, including a CPU on which an embedded OS (type Windows CE or EmDebian for example) can run, RAM and a FLASH memory for the nonvolatile storage of data (eg firewalling filter configuration parameters) and software. <tb> G <sep> indicates physical interfaces of different protocols. <tb> H <sep> (optional) indicates one or more USB ports for adding USB interface dongles to easily scale the board and expand the number of managed protocols. <tb> J <sep> (optional) indicates a protocol dongle with USB interface. <tb> K <sep> indicates the communicating objects. <tb> L <sep> (optional) indicates sensors or connectors for sensors. <tb> M <sep> (optional) indicates actuators or connectors for actuators. <tb> N <sep> indicates the power supply of the card which can be of several types: a power supply via an external AC / DC converter (an AC adapter) or a 230V power supply with an on-board AC / DC converter ( eg in the case where it is a question of injecting the signal PLC directly on the electrical network).

[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. The multi-protocol card has its own IPv6 address. It connects to one or more central control systems that each have their own IPv6 address. The card - central system relationship is by default a client - server relationship, in order to facilitate the declaration and integration of the cards in the central control system. However, the card can also respond to requests for connections from an external control system to the card via an embedded web service. This allows the maintenance and configuration of the cards from an address different from that of the central control system. This also makes it possible, when the connection needs are very episodic, to open these connections only when the central control system deems it useful. If necessary, and to avoid abusive connections, the multi-protocol card is able to filter incoming connections against a list of IP addresses and ports registered in its configuration file saved on the card.

[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.FIG. 4 indicates the software architecture of the multi-protocol card used for the demonstrator. In this figure: <tb> A <sep> indicates the drivers needed to use the hardware of the card. <tb> B <sep> indicates the embedded operating system that abstracts from the hardware part and includes the low-level protocol stacks required for communication with the devices such as connected objects and the central control system (eg TCP / IPv6, UART, USB, HCI, ...). <tb> C <sep> indicates the library that disregards the communication management between the central control system and the multi-protocol card. This library provides a reliable bidirectional connection for each Daemon protocol to the central control system. <tb> D <sep> indicates the "Service Discovery" library that disregards the detection mechanism of the central control system. <tb> E <sep> indicates the master daemon which is responsible for: - o Use the "Service Discovery" library to find and advertise with a central control system. - Allow remote configuration of the multi-protocol card. - Detect the presence and / or activation of new physical interfaces on the multi-protocol card (eg the connection of a KNX dongle) and launch the corresponding protocol daemon), - Detect the absence and / or deactivation of physical interfaces on the multi-protocol card and stop the corresponding protocol daemon. - Detect the inactivity of a daemon (due to malfunction) and restart it <tb> F <sep> indicates one or more "protocol daemons". For each driver used on the multiprotocol board (UART, KNX, Bluetooth, ...) is a daemon. In this way, a malfunction of a daemon does not disturb other daemons. The responsibility of a protocol daemon is to: Transfer the data sent by an object connected to the multi-protocol card, and available through the corresponding driver, to the central control system using the Data Exchange Library. Transmit to an object connected to the multi-protocol card the data sent by the control system via the corresponding driver, Optionally incorporate the lower layers of a given protocol stack. Announce the availability of an interface on the multi-protocol card to the central system.

Serveur externe External server

[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. Our system allows to use the services of an external server to share and retrieve information, protocol modules or programmed elements. It can facilitate the identification and download of appropriate and authenticated protocol modules when the system finds new objects.

Métalangaqe protocolaire génériqueGeneric protocol metalanguage

[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. To facilitate interoperability between objects, we have created a generic language that covers the various functions and instructions of the communication protocols that we want to integrate. For lack of a more explicit term, we have called this generic language "metalanguage". This metalanguage facilitates the translation to and between the application layers of the different protocols used. The translation of the instructions and commands of the communication protocols to and from the metalanguage is done through "application modules". In some cases, these application modules can be summarized as a kind of bilingual dictionary that translates the specific instructions and commands of the communication protocol to and from the equivalent instructions of the system metalanguage. The addition of a new protocol then becomes easy, since it suffices to develop the "application module" which translates the specific instructions of a communication protocol to the metalanguage and vice versa. This allows the metalanguage to interact with all objects using the integrated communication protocols using the application modules. It also allows objects using different protocols to interact with one another through metalanguage. This saves time in terms of development and extension to new protocols. This also has an exponential effect on the number of possible inter-protocol interactions, since each new protocol can in principle interact with all protocols already integrated via metalanguage. This metalanguage can be developed in an ad hoc way starting from the targeted protocols, with the possibility of an incremental development with the integration of new protocols and / or the appearance of new functions in the already integrated protocols. This metalanguage can also be standardization.

[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.FIG. 5 indicates the principle of the metalanguage layer. In this figure: <tb> A <sep> indicates the different particular protocols. <tb> B <sep> indicates application modules that translate the instructions of the particular protocols into standard metalanguage instructions. <tb> C <sep> indicates the metalanguage used by the control system. <tb> D <sep> indicates the control system that uses the metalanguage.

[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». For example, a KNX instruction "DTP_Switch" given to light a device will be translated by the "KNX application module" in metalanguage with the equivalent instruction "Set_OnOff [1]". This same instruction can also be retranslated by the "application module X10" in language X10 with the binary instruction for "On": "00101".

Métacouche du métalangage (Modèle OSI +1)Metalanguage metacolor (OSI model +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. [0039] Referring to the OSI layer model, our metalanguage is equivalent to developing an architecture with an additional layer of abstraction using standardized metadata and which comes at the top of the "application layer" of the OSI model. This makes it possible to bring all the communication protocols back to a common language. This allows you to manipulate data and objects in a standardized way, regardless of the communication protocol used by the objects. This facilitates the development of the system and the extension to new protocols, by focusing the development on the application modules responsible for translating the instructions between the protocol (application layer) and the metalanguage.

[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.FIG. 6 indicates the dislocation of the low and high layers. In this figure: <tb> A <sep> indicates the classical layers of the OSI model <tb> B <sep> indicates the new layer of metalanguage that is superimposed on the application layer.

Architecture protocolaire modulaireModular protocol architecture

[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.Our system makes it possible to fragment the protocols into different modules corresponding to different layer levels of the OSI model, in order to be able to manage the communications in an ad hoc and modular way. We have generally dissociated: The "physical interfaces" that provide physical connectivity (low layers) with objects. These physical interfaces are usually located on multiprotocol cards and managed by the corresponding drivers and daemons; they can also be provided through protocol dongles connected to a USB port. Middleware managed "protocol modules" that process the intermediate layers of the communication protocol that are not supported by the elements that provide physical connectivity. The "application modules" responsible for processing the upper layers and translating them into metalanguage.

[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é. Some application modules may be superimposed. For example: a UPnP application module can call a specific application module corresponding to the communicating object concerned.

[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.This allows in particular: Facilitate the extension of the system to new protocols by simply adding new protocol modules. Optimally manage the different combinations of communication protocols (high layers) and physical media (low layers); the same protocol can be used on different physical media.

[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.FIG. 7 indicates the modular structure of the demonstrator middleware. In this figure: <tb> A <sep> indicates an application module, the purpose of which is to allow the abstraction towards the metalanguage of the functionalities of one or more types of objects connected to the different multi-protocol cards. An application module exposes to the kernel a list of methods (eg heatOn, turnLightOn, ...) representing the functionalities of a concrete object (eg KNX solenoid valve, X10 lamp, ..). An application module can directly communicate with a protocol daemon of a multi-protocol card (using the Data Exchange library) or call methods exposed by the various protocol modules (B) available. Method calls can be implemented synchronously (return method) as well as asynchronously (calling a procedure with the return of one or more values as events). <tb> B <sep> Specifies a protocol module whose purpose is to abstract a given protocol layer. A protocol module exposes to the application modules a list of primitives (methods) necessary for the operation of the protocol. An application module can directly communicate with a protocol daemon of a multi-protocol card (using the Data Exchange library) or call methods exposed by other protocol modules (B). Notes: The application and protocol modules work identically, they are distinguished only by their level of abstraction. The application and protocol modules can also communicate directly with objects on the network to which the central control system is connected as well as multi-protocol cards. <tb> C <sep> indicates the "Data Exchange" library that abstracts the communication between the central control system and the multi-protocol cards. It is the counterpart of the same library on the card side multi-protocol. <tb> D <sep> indicates the "Service Discovery" library that disregards the detection mechanism of the central control system. It is the counterpart of the same library on the card side multi-protocol. <tb> E <sep> indicates the network layer (ie IPv6) to which the central control system and the multi-protocol cards are connected. <tb> F <sep> indicates the kernel, which (through rules and scenarios) calls the different methods exposed by the application or protocol modules <tb> G <sep> indicates an event handler with a publish / subscribe mechanism. The data sent by the objects are transferred to this manager (publish) and annotated with a corresponding tag (p.e. RS232). The events are redirected to all the protocol and application modules that have subscribed to the corresponding tag (subscribe). The module that recognizes the event deals with its processing (eg calls a method, sending new events to the manager, notification of the kernel for executing rules, ...). If no module can handle the event (p.e. event of an unknown object), then the event handler informs the kernel of this unknown event. This one consults the external server and downloads / installs the application and protocol modules that are necessary for the treatment of the unknown event. <tb> H <sep> indicates a service module, which gives the kernel access to additional tools (eg send SMS / Email, access to reservation software, ...). <tb> I <sep> indicates the framework (of type OSGI) which allows loading, launching, updating and stopping of modules. In this way, the extensibility and evolution of the central control system is guaranteed.

[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étalangageFIG. 8 indicates the modular protocol structure of the system. In this figure: <tb> A <sep> indicates communicating objects using different communication protocols <tb> B <sep> indicates the "physical interfaces" to ensure connectivity to objects <tb> C <sep> indicates the "protocol modules" for processing and formatting the data according to the protocol standard in question. <tb> D <sep> indicates the "application modules" allowing to translate the instructions of the application layer towards the metalanguage and vice-versa. <tb> E <sep> indicates the control system that uses the metalanguage

Structure réseau dualeDual network structure

[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.Our system makes it possible to deploy a network architecture consisting of two protocol spaces with: A relatively homogeneous central space that is used by the control system to communicate with objects or multi-protocol cards. This central space can be based on an IPv6 type protocol (IPv6, 6LoWPAN, etc.); A heterogeneous peripheral space located behind multi-protocol cards using different communication protocols to adapt to the constraints and specificities of communicating objects. This makes it possible to take into account the range (distance) of the communication protocols of the objects, which can be very limited.

[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. This architecture optimizes the management of the central network. It also allows you to control objects with a limited range of communication from any distance across a multi-protocol map.

[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 communicantsFIG. 9 indicates the dual network structure recommended for system deployment. In this figure: <tb> A <sep> indicates the control system (s) <tb> B <sep> indicates the relatively homogeneous central network <tb> C <sep> indicates the multi-protocol interfaces (multi-protocol card or equivalent devices) <tb> D <sep> indicates relatively heterogeneous peripheral networks that may consist of multiple protocols <tb> E <sep> indicates communicating objects

Dislocation du traitement des couches basses et des couches hautes des protocoles de communicationDislocation of the treatment of the low layers and the high layers of the communication protocols

[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. Our system allows, when appropriate, to separate the processing sites of the lower layers and high layers of a communication protocol. Thus, the lower layers of a communication protocol (physical connectivity) can be processed by a multi-protocol card; while the upper layers (in particular the application layer) can be processed by the central control system. This makes it possible to limit the size of processes and the need for updates at the periphery. This makes it possible to optimize the computing power at the level of the central control system.

[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 communicantsFIG. 10 indicates the dislocation of the low and high layers. In this figure: <tb> A <sep> indicates the central control system that manages the upper layers of the protocols <tb> B <sep> indicates the network connection between the control system and the multi-protocol card <tb> C <sep> indicates the multi-protocol card that manages the lower layers of the protocols <tb> D <sep> indicates communicating objects

Multiplexage protocolaire:Protocol multiplexing:

[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. To facilitate the management of IP communication flows between the central control system and the multi-protocol cards, we used a protocol multiplexing. The lower layers of the object protocols are processed by the multi-protocol card, then strings are transmitted in IP packets to the server to handle the processing of the high layers of the protocol. Each protocol is transmitted on a different and specific port. This optimizes the speed of communication processing, each packet can be directly routed to the protocol module or the corresponding deamon.

Architecture réseau décentraliséeDecentralized network architecture

[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. The multi-protocol cards make it possible to develop a decentralized network architecture by allowing certain information flows to be filtered and processed at the level of the card itself. For example, the multi-protocol card can filter the information received from the temperature sensors and can decide to relay to the central control system only variables that have changed or to respect a minimum waiting time between the transmission of two variables of same type. This prevents superfluous information flows from flooding the network of the central control system. The card can also support rules that do not require the intervention of the central control system. For example: if the temperature is above a certain threshold, the multi-protocol card could give the order for itself to automatically close a radiator valve.

[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. Our system also allows to coexist several control systems in parallel. For example: a first central control system may be responsible for managing the energy consumption and temperatures of controlled buildings; while a second central control system can be responsible for managing access and building security. This is all the more simple as each control system can have its own Internet address. In addition, the use of IPv6 makes it possible to ensure direct connections between the control systems and the objects and multiprotocol cards concerned.

[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. This network architecture makes it possible to deploy a network in a much more modular and flexible manner. It also allows a very large scalability of the system.

Interface Graphique intuitive et multidimensionnelleIntuitive and multidimensional graphical interface

[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.We have invented an intuitive multi-dimensional graphical interface. Most GUIs are based on tree architecture and navigation. We have developed a multidimensional navigation that allows the user to navigate along multiple axes simultaneously to select a variable number of targeted objects. Each axis is composed of several levels of increasing precision. The more the user advances on an axis by adding more precise criteria of selection, the more he restricts the list of targeted objects. Navigation in each of the axes can be compared to a multidimensional zooming process. This allows the user a much more intuitive and immediate apprehension of the objects he wants to control. This system allows to better interact with an unlimited number of objects. In our demonstration we have developed two basic axes: Location axis: This axis is used to define the spatial scope of the objects involved in several stages: selection of the building (s), the floor (s), the type (s) of rooms, or even the room (s) targeted by the user. Typological axis: This axis makes it possible to define the typological or categorical scope of the targeted objects: selection of types of objects and / or particular objects.

[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. Our mechanism makes it very easy to select objects that would be difficult to select in a traditional tree approach. For example, to turn off the lights and radiators of bathrooms on the 3rd and 4th floor of building X. Our navigation mechanism makes it easy to integrate additional axes. For example: a personal axis that would change the scope of accessible objects based on a user or group of users.

[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.FIG. 11 shows an example of application of our multidimensional graphical interface. In this figure: <tb> A1 <sep> indicates the selection of a building <tb> A2 <sep> indicates the selection of a floor <tb> A3 <sep> indicates the selection of a type of part <tb> A4 <sep> indicates the selection of a part <tb> B1 <sep> indicates the selection of a large category of objects <tb> B2 <sep> indicates the selection of a particular family of objects <tb> B3 <sep> indicates the selection of a particular object <tb> C <sep> indicates an optional area for displaying information about objects matching the filter criteria <tb> D <sep> indicates an optional area for displaying possible actions on objects matching the filter criteria <tb> E <sep> indicates an optional graphical display area of the list of available options when selecting one of the elements of a navigation axis.

[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. The selection of elements A and B can be done for example with drop-down lists or icons that appear in zone E when one clicks on one of the elements (A1, A2, A3, A4, B1, B2, etc.) and corresponding to the available options. To facilitate user selection, when one of the elements is selected, it dynamically changes the list of options for other selection elements that depend on it. For example, the selection of an A1 building with only 2 floors will modify and limit the options available in A2 on these two particular floors, and in A3 and A4 on the rooms available in the selected building. The user can also directly select choices in A2 or A3 without going through a selection in A1. It could thus act on all the bathrooms (A3) of all its buildings. The selected elements are all filter criteria for selecting the corresponding objects from the system database.

[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. This selection mechanism according to several filter criteria, is also used by the rules and scenarios of the system to determine the scope of an action on a set of given objects. For example: turn off all rooms on the 3rd floor. These criteria can also be saved as predefined "targets" that can be reused in rules or scenarios.

Utilisation d’lPv6 pour un déploiement illimitée et facilité:Using IPv6 for unlimited deployment and ease:

[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.Our system allows to fully use the potential of IPv6 for the management of communicating objects. The use of the new IPv6 Internet Protocol as a vector for controlling objects makes it possible to manage a virtually unlimited number of objects remotely in a secure manner and facilitates the deployment of the system. IPv6 allows us to: Have a virtually limitless number of addresses for objects, allowing virtually unlimited scalability of the system. Benefit from the self-integration mechanisms of new objects that can find an IPv6 address by themselves to integrate into the network without requiring any particular configuration. Benefit from built-in security mechanisms, such as IPSec. Benefit from IPv6 properties for object mobility, which allows you to keep an address accessible regardless of the location of the object.

Adressage IPv6 virtuelVirtual IPv6 addressing

[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. Our system allows de facto to assign an IPv6 address to objects that are not intended to manage IPv6. This makes it possible to integrate heterogeneous objects not compatible with IPv6 into an IPv6 network. Our system then serves as an IPv6 proxy to allow applications to access these objects via IPv6. This allows us to control and communicate over IPv6 with objects that intrinsically do not understand IPv6. In fact, this allows us to directly extend the Internet to objects that were not intended for the 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 IPv6FIG. Figure 12 shows an example of virtual IPv6 addressing. In this figure: <tb> A <sep> indicates a source seeking to transmit information to the X object as an IPv6 packet. <tb> B <sep> indicates the webservice that will listen and receive the package from source A <tb> C <sep> indicates the central system that will be responsible for determining how to route the information and through which protocol. In particular, the system will be responsible for converting the instructions according to the application layer of the targeted object. <tb> D <sep> indicates the sending of an equivalent instruction either directly in the protocol of the object X, or via a multi-protocol card E. <tb> E <sep> indicates a multi-protocol card <tb> X and X <sep> indicate a communicating object that does not support 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. Note that the flow can be reversed. Similarly, if required, the system can also provide synchronous communication.

Extension de 6LoWPAN6LoWPAN extension

[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. The modular architecture makes it possible to use protocols provided for a type of physical medium on other types of physical media. It allows to consider new combinations, such as the use of 6LoWPAN on a PLC or Ethernet support.

Optimisation de la gestion énergétiqueOptimization of energy management

[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. Our system allows to manage much more holistically the energy consumption of buildings. It makes it possible to integrate the various parameters and sources of information into a common reference frame and to act on all the communicating objects and devices supported by the system while ignoring the fact that they use different communication protocols. It allows you to apply cross-sectional rules that integrate all of these elements.

[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.Our system allows in particular to manage the temperature of premises according to several temperature curves in parallel. It allows for example to assign to the same room: A reference T1 temperature curve when the part is not supposed to be used; A T2 reference curve when the part is supposed to be used, but no human presence is detected; A third reference curve T3 when a human presence is detected in the room.

[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. The second curve (T2) makes it possible to find a compromise between the potential of energy saving and the thermal inertia of the part which requires not having a temperature too low to allow the part to reach sufficiently quickly a satisfactory temperature (T3, comfort temperature required) when a person enters it. Such an approach reduces the energy consumption of the building.

[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. Our system allows to enrich these algorithms in a virtually unlimited way. For example, we can incorporate derogations, or adaptations of the curves, into the rules if the user has indicated to the system that he wants a temperature different from that proposed initially by the preprogrammed curves. We can also provide custom curves for a particular user. This mechanism can be applied to many areas such as hospitality and building management.

[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.FIG. 13 indicates an applied example of management of the temperature curves according to several parameters. In this figure: <tb> C <sep> indicates the central control system <tb> S <sep> indicates one or more temperature sensors <tb> P <sep> indicates one or more presence sensors <tb> O <sep> indicates one or more door open sensors <tb> V <sep> indicates one or more temperature actuators, such as solenoid valves <tb> R <sep> indicates the system management rules <tb> E <sep> indicates additional sources of data on the status of the room, such as occupancy schedule, check in and 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. In our example, the central control system will adjust the temperature of the controlled room, such as hotel rooms or offices, according to three statuses (S1: unoccupied S2 occupancy expected, but no presence detected; S3 human presence detected) with for each status, a reference temperature curve (respectively T1: minimum temperature, T2: intermediate temperature and T3: comfort temperature). The control system determines from the information source E (such as schedule of use, reservation system, etc.) whether the piece is supposed to be used (S2 or S3) or not (S1). If a presence sensor detects a human presence, the status changes from S2 to S3. If the door open sensor is activated, the system takes into consideration that the room may have been emptied and return the status to S2 until a presence is detected (if someone has remained in the room). the piece for example). In the case of a hotel, the check out of the client automatically sets the status to S1 if no arrival is planned in the short term. At the same time, the system knows the room temperature thanks to sensor S and can close actuator V if the temperature is higher than the reference temperature or open the valve if it is lower. The control system makes it possible to write rules in different ways, for example with the introduction of margins in the comparison of the reference temperatures (for example: to act only if the difference is greater than X ° C), or proportionality mechanisms in the action on the valve (for example: opening of X% per degree of deviation), etc.

Interaction avec le réseau électriqueInteraction with the electricity network

[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. Our system also allows to interact with external services. It allows, for example, to manage the energy consumption of a building according to the state of the demand or the price on the network. We can thus retrieve information on the price of energy in a given market, for example via a service module that questions a web service, and use this information to adapt the energy management of buildings controlled by the system. The system can reduce consumption during periods of high demand on the network and consume more during periods of low demand. This optimizes energy consumption in relation to the demand on the network. It also allows for new dynamic billing models based on market demand. If necessary, the system can thus optimize the energy bill compared to a dynamic billing calculated on a variable cost over time. It can also be used to optimize the selling price of energy from positive buildings (with renewable energy sources). Finally, since the price of energy is generally strongly correlated with the state of demand, our system can help to solve the problem of demand peaks on the energy grid by generating counter-cyclical behavior in relation to the evolution of demand. on the network. Our system can help mitigate the problem of demand peaks.

[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.FIG. 14 shows a diagram of possible interaction between a building managed by our control system and the power grid. In this figure: <tb> R <sep> indicates the regional energy network <tb> F <sep> indicates the energy supplier <tb> B <sep> indicates the building (s) that consume and eventually produce energy <tb> M <sep> indicates the market price of energy on which the network depends and which is transmitted to the central control system. The price M can for example be made available via a web service used by the central control system. It can also be transmitted directly to the central control system as soon as a change takes place on the market, in order to allow an update in real time. <tb> C <sep> indicates the central control system that can adapt the behavior of actuators in the building according to the market price. It suffices for it to write rules according to the price of energy.

[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. When the central control system receives a price M greater than a certain amount, it may decide to reduce energy consumption in managed buildings (B). For example, it may interrupt some appliances that use the energy in question (heating, air conditioning, washing or drying machines, etc.). As soon as the temperature M falls below a certain threshold, it can reset the devices that had been stopped. If necessary, it may also decide to limit certain interruptions in time, even if the price remains high (for a cold room for example). The system can also take into account past events to anticipate cyclical demand peaks and for example increase the heating or cooling of a room before the peak period.

Actuateurs et senseurs IPv6IPv6 actuators and sensors

[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é. Our control system can interact directly with sensors, actuators and devices of the IPv6 type. It allows the use of switches controlled by a small IPv6 controller and can communicate with the system via PLC (power line communication) or other physical media (IEEE 802.15.4, Ethernet, etc.). In addition, these actuators can integrate sensors, such as temperature and presence sensors. The combination IPv6 with PLC facilitates the deployment of control elements in an existing building with a virtually unlimited number of objects.

[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.FIG. 15 shows an example of an actuator - IPv6 sensor easily deployable. In this figure: <tb> S <sep> indicates the central control system <tb> L <sep> indicates the connection between the device and the central control system. This connection can be by default the power line itself via IPv6 on PLC, but alternatively via other physical media such as 802.15.4 preferably with 6LoWPAN. <tb> P <sep> indicates the physical interface of the device (PLC, 802.15.4 or other) <tb> W <sep> indicates the IP module for managing IP packets between the device and the central control system. This module can also perform address filtering services and communication ports. <tb> C <sep> indicates the controller which manages the application level of the packets. <tb> D <sep> indicates sensors <tb> E <sep> indicates actuators, such as electrical relays.

[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. This device makes it easy to deploy a home automation system in an existing building without requiring additional wiring.

Claims

1. System for access, control and management of communicating objects characterized by the fact that: The system comprises at least one server connected to at least one data memory; The system comprises at least one multi-protocol interface connected to the server that allows connectivity with heterogeneous communicating objects that can use different protocols, or these interfaces can be physically separated from the server or servers while remaining connected to the servers through a main protocol; The server can use a main protocol, such as IPv6, to remotely address and communicate with the multi-protocol interface (s) and / or directly with objects comprising the main protocol; The system uses a metalanguage which makes it possible to reduce the specific information and instructions transmitted by the various communication protocols in a generic language, thus allowing a form of abstraction of the heterogeneous objects using different protocols by bringing them into a common reference frame, thus possible a form of interoperability between objects as well as the definition and application of rules or algorithms applicable by the system transversally to heterogeneous objects; - the system uses a modular architecture and metalanguage to facilitate the integration of new protocols to the system, each new protocol can then interact through the metalanguage with objects of all other protocols already installed; The system can handle heterogeneous information and objects in an integrated manner using different communication protocols, including archaic protocols, without requiring special adaptation on the object side; The system allows the use of a common graphical user interface for the set of heterogeneous objects managed by the said system; The system allows a holistic management of an environment and heterogeneous objects that are there, with for example a better energy management of the spaces managed by the said system; the system can also contribute, for example, to facilitate deployment, integration, monitoring, control, access, manipulation, interoperability, scalability, management and energy saving or integration. various objects in an IPv6 addressing system.

2. System according to claim 1 characterized by a modular architecture of the system and means that make it easy to integrate new code elements, such as protocol or application modules to facilitate the evolution of the system, with: - different modules for different protocols; The possibility of fragmenting the processing of the various layers (in the sense of the OSI model) of a communication protocol into several relatively independent and complementary modules, including modules that ensure the conversion of data between the application layers of the protocols and the metalanguage; The possibility of using the high layers of a protocol on low layers of another protocol, such as for example the use of 6LoWPAN on a support of the PLC (Power line communication) or Ethernet type; The possibility of using an OSGI-type framework (or equivalent) to facilitate the management and integration of new modules or other pieces of code, without having to interrupt the system; A mechanism for the instructions supported by the protocol or application modules to be recorded and known by the system and allow the system to filter the instructions offered to the user and to the elements of the system itself, with the possibility of also declaring the instructions supported by a protocol or application module in the code of said module.

3. System according to claim 1 characterized in that the server uses a metalanguage and means for converting the different instructions and specific data application layers of different communication protocols in this common metalanguage, and vice versa, allowing it to treat all objects according to a common language, including: - the homogenization of data and variables at the metalanguage level; The possibility of using metalanguage to allow interoperability between objects using different communication protocols; - the possibility of facilitating integration, interaction and interoperability between heterogeneous objects; The possibility of facilitating the scalability of the system and the integration of new communication protocols, each protocol integrated with the metalanguage being in fact able to interact through the metalanguage with the objects of the other previously integrated protocols; - the use of an additional layer to the OSI model which is superimposed on the so-called "application" layers of the protocols and which makes it possible to integrate the different protocols in a homogeneous framework.

4. System characterized by the use of a network architecture consisting of two protocol spaces with: a central space used by the server or servers, which is relatively homogeneous and uses a main protocol, such as IPv6; and a heterogeneous peripheral space that can use different communication protocols; with notably: - the possibility of setting up a decentralized network architecture allowing different servers to interact simultaneously with different sensors, actuators, devices and multi-protocol cards; - a decentralized architecture allowing deployment of a distributed intelligence, especially at the periphery; The possibility of making the central control and management system coexist with autonomous control and management sub-systems interacting with peripheral objects, the central system being able to decide whether or not to intervene in the management of the objects of the sub-systems; -autonomous systems; - the possibility of coexisting several control systems with complementary tasks.

5. System according to one of claims 1 to 4, characterized by the dissociation of the place of treatment of the low layers and the high layers of the communication protocols, which allows in particular to ensure close physical connectivity with objects and centralized processing application layers at the level of the controller or controllers, regardless of the location and distance of objects, including: The possibility of using a protocol multiplexing, such as the use of communication ports (TCP, UDP or other), to facilitate and accelerate the transmission, routing and processing of data flows between the periphery (multi-user interfaces); protocol or other apparatus) and the central controller (s); The possibility of using IPv6 type addresses (such as IPv6 or 6LoWPAN).

6. A communicating object access, control and management system characterized by the use of IPv6 type addresses (such as IPv6 or 6LoWPAN) to address and facilitate interaction between the various elements of the deployed system and especially for: - facilitate the deployment and integration of the elements of the system; - be able to send system elements directly through IP addresses; - allow, if desired, to make elements of the system directly accessible from the Internet; - ensure the scalability of the system with a virtually unlimited number of available addresses; The portability of communication flows on different physical media; - the routing of communication flows; - and the protection of communication flows with systems such as IPSec; - give the possibility of interacting directly on sensors and actuators using IPv6 type addressing; - allow an almost unlimited and easy deployment of a network of communicating objects; - enable universal integration of objects, services and people; - facilitate the use of different physical media such as PLC (power line communication), Ethernet, fiber optics and RF (radio frequency).

7. System for accessing, controlling and managing communicating objects characterized by one or more multi-protocol interfaces comprising means for receiving / sending data according to one or more communication protocols, said data being encapsulated in the main protocol during the communication of said data with the server, - this interface providing physical connectivity with communicating objects, through different communication protocols, - and the interface between these communicating objects and one or more control systems, including: The possibility of dissociating the location of the multi-protocol interfaces from that of the central controller or controllers, making it possible in particular to solve the problems of scopes related to certain protocols; The possibility of using a protocol multiplexing, such as the use of communication ports (TCP, UDP or other), to facilitate and accelerate the transmission, routing and processing of data flows between the periphery (multi-purpose cards); protocol or other apparatus) and the central controller (s); The possibility of using IPv6 type addresses (such as IPv6 or 6LoWPAN) to facilitate the deployment and interaction between the multi-protocol interfaces and the central controllers; - the ability to filter incoming connections according to criteria such as home address and communication port to protect cards from unwanted intrusions; The possibility of managing certain monitoring and control tasks at the level of the multi-protocol interface in order to allow the deployment of a decentralized architecture with an intelligence partially distributed at the level of the multi-protocol interfaces; The possibility of having modular protocol elements that can be added or removed from the multi-protocol interface; - the fact that you can easily add protocols by adding protocol dongles on the USB bus of the multi-protocol interface; The possibility of integrating into the system heterogeneous objects that are not compatible with the main protocol, the multi-protocol interfaces thus ensuring connectivity with the objects in question without requiring special adaptation on the side of said objects and ensuring the transmission of information with the server through the main protocol; - the possibility of integrating into the system objects using archaic protocols as long as they are supported by the multi-protocol interface.

8. System according to one of claims 1 to 7 characterized by the possibility of integrating into a single platform heterogeneous objects using different communication protocols that allows them through the system to interact with each other to allow in particular: - to solve interoperability problems between objects using different communication protocols; - facilitate the development of rules for the management of home automation objects thanks to an abstract layer of metalanguage that allows to integrate and interact with heterogeneous objects through homogeneous variables and instructions; - launch discovery processes for new objects by scanning the different available protocols; To give the user the freedom to validate the new objects discovered before they are integrated in his network of objects; - facilitate the scalability and maintenance of the system; - to integrate objects using archaic and limited protocols in architectures and more advanced protocol systems.

9. System according to one of claims 1 to 8, characterized by the possibility of using a third party server for sharing and / or updating information or program elements, such as drivers, protocol modules, rules or algorithms, including: - the possibility for users to share resources or to make collective developments; - the possibility of using the external server to facilitate the maintenance of the systems; - the ability to use the external server to provide services.

10. System for access, control and management of communicating objects characterized by an intuitive and multidimensional Graphical User Interface using a multidimensional navigation system to access and select objects, including the possibility of using: - a typological axis (object or type of objects); - a topographical axis (location of objects); Additional axes, such as, for example, a personal axis making it possible to adapt the selection of objects according to the user or a time axis making it possible to adapt the selection of objects according to their accessibility at the chosen moment; The possibility of using this navigation along several axes to manage a set of potentially large and heterogeneous objects; - the possibility of using this system for intuitive interfaces and small size for portable devices, such as mobile phones, remote controls or PDAs.

11. System according to claim 10, characterized by the assignment of IPv6 type addresses (such as IPv6 or 6LoWPAN), including for objects not compatible with IPv6, notably allowing the system to serve as an IPv6 proxy for objects. not adapted to IPv6, - which allows in particular: - integration and universal addressing of objects, regardless of their communication protocol; To serve as a proxy between different communication protocols, and in particular between IPv6 and the other protocols; - Indirectly integrate non-IPv6-compatible objects into an IPv6 network, and allow seemingly direct access to these objects via specific IPv6 addresses.

12. System of access, control and management of communicating objects characterized by the use of an IPv6 type protocol (such as IPv6 or 6LoWPAN) to interact directly with devices, sensors and actuators, with the possibility of using such a protocol on different physical media and in particular on a support type PLC (Power Line Communication) to facilitate their deployment in buildings, with the possibility of using such a system for switches that can be controlled remotely and which can also integrate sensors such as for example: temperature, presence, light and / or consumption.

13. Method or system characterized by energy management of spaces and premises according to several temperature curves that are selected according to the context in order to optimize energy consumption and to adapt it to the actual needs of users, with: - the possibility of assigning specific curves to specific parts; An energy management of spaces according to at least three categories of thermal curves: - the relevant temperature curves for the parts that are supposed not to be used; - the relevant temperature curves for the parts that are supposed to be usable, but where no presence is detected; - the relevant temperature curves for rooms where a human presence is detected; - the possibility of reducing energy consumption by reducing the temperature of rooms according to their use, to lower levels when the room is not supposed to be used or intermediate when it is likely to be (re) occupied at short term so that it can reach a comfort temperature within a reasonable time given the thermal inertia; The possibility of adding an unlimited number of contextual temperature curves to determine reference temperatures, such as minima or maxima of temperatures depending on the moment and the context.

14. Method or system characterized by the possibility of using the information on the state of demand or price of energy on the energy network in question to adapt the energy behavior of the buildings managed, with the possibility of: - use the price of energy on the markets as an indicator of the state of demand and to identify demand peaks; - reduce the energy bill by reducing consumption when prices are high and favoring network consumption when prices and demand are low; - enable buildings with renewable energy to maximize revenues and the amount of energy sold to the grid during peak periods; - use information on the price of energy or the state of demand to adapt the energy behavior of spaces or buildings managed to help reduce the problem of demand peaks on the power grid by countercyclical behavior; - develop a new business and billing model based on the real-time energy price of the market.

15. System characterized by the possibility of using 6LoWPAN on other physical media than 802.15.4, such as Ethernet or PLC support, in order, among other things, to facilitate the deployment of a network in existing or already designed buildings.