[go: up one dir, main page]

EP3241118A1 - Boitier de communication et de gestion d'equipements - Google Patents

Boitier de communication et de gestion d'equipements

Info

Publication number
EP3241118A1
EP3241118A1 EP15817467.2A EP15817467A EP3241118A1 EP 3241118 A1 EP3241118 A1 EP 3241118A1 EP 15817467 A EP15817467 A EP 15817467A EP 3241118 A1 EP3241118 A1 EP 3241118A1
Authority
EP
European Patent Office
Prior art keywords
data
communication
communication box
equipment
platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP15817467.2A
Other languages
German (de)
English (en)
Inventor
Malo JENNEQUIN
Mustapha MICHRAFY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS filed Critical Bull SAS
Publication of EP3241118A1 publication Critical patent/EP3241118A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/2818—Controlling appliance services of a home automation network by calling their functionalities from a device located outside both the home and the home network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/803—Application aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q9/00—Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom

Definitions

  • the invention relates to a communication and equipment management box, in a multi-vendor and multi-service system, for managing the data of a set of objects or equipment connected to a network.
  • o to automate actions thanks to geolocation for example: open a gate, switch on the heating, manage the lighting, activate an alarm;
  • Internet of Things actors are numerous and varied, as examples: connected equipment manufacturers, publishers / distributors of residential services, telecommunications operators, energy companies, insurers.
  • an actor proposes an offer based on a certain number of equipment, sensors, and / or actuators selected from another identified supplier. This therefore requires close collaborative work between the concerned actor and the research and development teams of the identified supplier, in order to propose a product integration solution.
  • Some Internet of Things players for their part, offer a wide variety of connected devices, while remaining, sometimes, their own developer of user services. Although collaboration with research and development teams is then facilitated, these actors are still unable to integrate equipment from different providers in their platforms, these platforms being proprietary. More generally, all of the solutions integrated into the same platform are currently solutions that integrate a priori equipment vendors determined. The possibilities of retrospective integration of equipment, sensors, and / or actuators remain very limited. These possibilities are, moreover, dependent on the characteristics of the supplier solutions that have to evolve, for example depending on the proprietary protocols employed and their evolutions. Therefore, these solutions lack adaptability;
  • a communication box commonly referred to as "box” then interconnects the various equipment, sensors or actuators with service platforms or external networks.
  • the user is often obliged to use a communication box by vendor, which implies ergonomic problems in his home;
  • providers in charge of developing user services may want to access a set of reliable data in order, for example, to design residential services without necessarily being an equipment supplier.
  • equipment Generally, equipment suppliers offer equipment with the possibility to remotely control them, access their data, set up scenarios, and support protocols (eg KNX, Zigbee,
  • the present invention aims to address the aforementioned problems.
  • a communication box for managing a plurality of user equipment including sensors and actuators installed in a predefined environment comprising
  • a first communication interface for recovering at least one measurement measured by at least one of said plurality of user equipment
  • a second communication interface for communicating at least one command to at least one actuator of said plurality of user equipments
  • this communication box said measurement is recovered according to a first communication protocol and said command is communicated according to a second communication protocol, the first protocol being different from the second protocol.
  • this communication box is, furthermore, configured to transmit at least one datum to a central data platform.
  • this communication box has a non-addressable private address from said central data platform.
  • said datum is a parameter associated with a piece of equipment of said plurality of user equipments.
  • this communication box further comprises an application programming interface.
  • this communication box is, furthermore, configured to receive said command.
  • this local area network further comprises an integrated access device interfaced with said communication box.
  • Fig. 1 is a diagram showing a multi-vendor and multi-service data management system according to one embodiment
  • Fig. 2 is a data modeling relational schema according to one embodiment
  • Fig. 3 is a class diagram of a node of the data modeling relational schema according to one embodiment
  • Fig. 4 is a class diagram of another node of the data modeling relational schema according to one embodiment
  • Fig. 5 is a topological diagram describing another node of the data modeling relational schema according to one embodiment
  • FIG. 6 is a topological diagram describing another node of the data modeling relational schema according to one embodiment
  • Fig. 7 is a topological subset describing another node of the data modeling relational schema according to one embodiment
  • Fig. 8 is a diagram illustrating the elements relating to a service according to one embodiment
  • Fig. 9 is a diagram illustrating the relationship between different services according to one embodiment.
  • Fig. 10 is a figure illustrating an action manager according to one embodiment
  • FIG. 11 illustrates a data flow relating to an action consumer according to one embodiment
  • Figure 12 illustrates the establishment of a tunnel, for a communication mechanism between a communication box and a proxy according to one embodiment
  • FIG. 13 illustrates remote handling of the communication box for the communication mechanism with a proxy according to one embodiment
  • Fig. 14 illustrates transmission of an action request to an equipment associated actuator for the proxy communication mechanism according to one embodiment
  • FIG. 15 illustrates the feedback of a measurement of a sensor associated with an equipment for the communication mechanism with a proxy according to one embodiment
  • FIG. 16 illustrates the establishment of a connection between a central platform and a communication box for a communication mechanism implementing the UPnP protocol according to one embodiment
  • FIG. 17 illustrates the remote control of the communication box for the communication mechanism implementing the UPnP protocol according to one embodiment
  • Fig. 18 illustrates transmission of an action request to an equipment associated actuator for the communication mechanism implementing the UPnP protocol according to one embodiment
  • FIG. 19 illustrates the feedback of a measurement of a sensor associated with an item of equipment for the communication mechanism implementing the UPnP protocol according to one embodiment
  • FIG. 20 illustrates the establishment of a connection between a central platform and a communication box for a communication mechanism implementing the XMPP protocol according to one embodiment
  • FIG. 21 illustrates remote handling of the communication box for the communication mechanism implementing the XMPP protocol according to one embodiment
  • Fig. 22 illustrates the transmission of an action request to an equipment associated actuator for the communication mechanism implementing the XMPP protocol according to one embodiment
  • FIG. 23 illustrates the feedback of a measurement of a sensor associated with an equipment for the communication mechanism implementing the XMPP protocol according to one embodiment
  • FIG. 24 illustrates the establishment of a connection between a central platform and a communication box for a communication mechanism implementing the STUN protocol according to one embodiment
  • FIG. 25 illustrates remote handling of the communication box for the communication mechanism implementing the STUN protocol according to one embodiment
  • Fig. 26 illustrates the transmission of an action request to an equipment associated actuator for the communication mechanism implementing the STUN protocol according to one embodiment
  • Fig. 27 illustrates the operation of a software platform according to one embodiment
  • FIG. 28 illustrates an example of distribution of the elements of the software platform according to one embodiment
  • FIG. 29 illustrates the realization of the unified access structure according to one embodiment
  • FIG. 30 illustrates an operation of the unified access structure with equipment operating in a synchronous mode according to one embodiment
  • FIG. 31 illustrates an operation of the unified access structure with equipment operating according to an asynchronous mode according to one embodiment.
  • Fig. 1 is a diagram showing a multi-vendor and multi-service data management system 100 according to one embodiment.
  • the data management system 100 is interfaced with the following entities:
  • Equipment 1 disposed locally in a place or a predefined physical environment, for example in an indoor environment such as a home or office.
  • Equipment 1 is provided (arrow 3) by equipment suppliers 2, that is to say technology manufacturers.
  • the equipment 1 comprises sensors and makes it possible to go back to a central data platform 4, via a box-type communication box 5, of the quantifiable data and / or of the change of states associated with the data. measurements or status reports of said sensors (eg temperature measurement, position of a switch associated with a lighting system).
  • the equipment 1 is connected to the communication box 5 via a wired or wireless network.
  • the communication box 5 exchanges, locally or remotely, data with the central data platform 4, via another network, for example the Internet.
  • the equipment 1 can perform physical actions (eg turn on the heating) via one or more actuators.
  • an actuator performs an action following receipt of an action notification communicated from the communication box 5.
  • the data exchanged between each equipment item 1 and the communication box 5, for example data transmission measured by the sensors or action notifications to an actuator of a device 1, are communicated according to one or more protocols 6 symbolized by a double arrow.
  • a protocol 6 associated with a device can be a KNX, Zigbee, Wifi or Z-wave protocol;
  • user service providers 7 typically players in the Internet world, developing and providing the user with user services targeted to a particular domain, for example security services, comfort, or well-being.
  • these user service providers 7 have a complete business logic and perform user services based on data and basic services, provided prior to the central data platform 4.
  • these user service providers 7 interface (arrow 8) with the central data platform 4 in a service architecture oriented mode, commonly referred to as SOA (acronym for "Oriented Service! Architecture");
  • - data providers 9 of the Internet world providing for example meteorological data, news or social networks, to trace quantifiable data (eg weather measurements) or change of state data.
  • these data providers 9 interface (arrow 10) also with the central data platform 4 in an SOA service oriented mode;
  • elementary service providers 11 actors of the internet world, providing basic services to the central data platform 4 (eg implementation of a notification service), these services being used by the user service providers 7, as services "Basic" to realize the user services.
  • these basic service providers 11 interface (arrow 12) also with the central data platform 4 in an SOA service architecture oriented mode.
  • any provider may optionally play a plurality of roles.
  • a data provider 9 may also be an equipment provider 2 and a user service provider 7.
  • the data management system 100 takes into account several dimensions:
  • a multi-service dimension that is to say integrates and proposes a plurality of types of user services, for example home automation and e-health;
  • the equipment 1 supported by the system 100 can come from different manufacturers, and include characteristics specific to each of these manufacturers;
  • the system 100 performs an analysis of data provided by equipment 1 or data providers 9, these data possibly being abstracted in advance to preserve their confidentiality. The results of the analysis then allow the system 100 to provide correlations, trends, predictions on these data;
  • the data management system 100 comprises the following entities, the operation of which will be detailed later:
  • the box-type communication box 5 can, for example, be deployed in the user's home.
  • This box makes it possible to interconnect one or more devices 1 via a wired or wireless link according to a predetermined protocol that is a function of the manufacturer (ex: TCP / IP, ZigBee, Wifi) and to exchange data with the central data platform 4.
  • a predetermined protocol that is a function of the manufacturer (ex: TCP / IP, ZigBee, Wifi) and to exchange data with the central data platform 4.
  • the communication box 5 allows
  • multi-vendor equipment that is to say, supports and manages a plurality of protocols, as well as the identifications and isolations of the data / resources of each of the services executed in parallel in this box; o guarantee secure and reliable communication with the central data platform 4; o to provide the central data platform 4 with exploitable multi-vendor data from the sensors of the equipment 1;
  • the central data platform 4 concentrating and federating all the data coming from the communication boxes 5 deployed in various places (eg homes, offices), the data coming from the data providers, as well as the basic services necessary for the development of new user services.
  • the central data platform 4 is configured to:
  • raw data from sensors can be formatted / structured by the central data platform 4 in a pivot format, making it possible to abstract these data, such as an XML type format;
  • a user service provider may have limited access to a certain type of data; o ensure the segregation of data and basic services.
  • this makes it possible, in a multi-vendor environment, to make available to a set of providers 7 of user services the rich and multiple nature of the data, and this in a controlled manner by
  • o ensure the confidentiality of data, for example, an anonymization of data via an abstraction method (eg abstraction of data in the same pivot format); o federate a set of basic services provided by the 11 basic service providers, in order to have a global, coherent and controlled ecosystem; o provide the basic services to the user service providers 7 for carrying out these services, as examples, of the workflow-type services
  • Big Data Analytics provides usable data to an analytics mega-data module called Big Data Analytics
  • a mega-data analysis module 13 (called “Big Data Analytics”) configured to analyze the data of the central data platform 4 with which it is interfaced.
  • the mega-data analytics module 13 makes it possible, in particular, to establish, and then make available to the user service providers 7, correlations, trends, and / or predictions of the data recorded in the central data platform 4, by generating data reports. 'analysis (reporting services).
  • FIGS. 2 to 7 illustrate a pre-established data topology embodiment, according to a unified modeling language, UML, the acronym for "Unified Modeling Language", this topology is detailed later.
  • a data topology is used by the central platform 4 or the Big Data Analytics 13 module to classify the data recorded in the central data platform 4.
  • a data topology describing a data classification pattern is prerecorded in the central data platform 4, and leveraged by the latter to classify the data.
  • the central data platform 4 is configured to identify the source of a data, for example a measurement resulting from a sensor by reading its sound at the head, and then according to its source to classify it according to the topology. prerecorded.
  • a pre-established topology is prerecorded in the mega-data analytic module 13.
  • the latter is then configured to order / structure the data of the central data platform 4 in a database of this platform (eg a NoSQL database).
  • a database of this platform eg a NoSQL database.
  • the functions of the central data platform 4 and the mega-data analytic module 13 are performed by a single module (not shown).
  • the data recorded / manipulated in the central data platform 4 is in the form of business objects, that is to say relative data structures, as examples, to equipment 1, objects Meus or entities interfacing and exchanging data with the data management system 100.
  • the data management system 100 comprises the following business objects:
  • Each home is associated with a unique identifier on the platform, identified by a type (eg individual, business) and associated with its own characteristics (boxes, equipment, sensors, actuators);
  • Box this object designates any communication box 5 encapsulating services / functionalities and supporting different communication protocols.
  • at least one communication unit 5 is associated, that is to say a "box” object, this object comprising a unique identifier;
  • Equipment each equipment 1 is installed in a home, is connected only to a single communication box 5, and includes a unique identifier;
  • Sensor a sensor makes it possible to measure a physical quantity or to identify a change and is associated with a single piece of equipment 1;
  • an actuator is used to trigger an action following an event and is associated with a single device 1.
  • FIG. 2 An example of a topology is shown in Figure 2, in the form of a tree structure composed of nodes and stops, in accordance with the UML standard.
  • This tree includes, here, a root node "Root”, the other nodes pertaining to the entities of the platform. More particularly, each node of this model is associated with a class diagram, which will be described later.
  • the relationship between each entity is represented by a stop (link) and a cardinality.
  • the cardinalities of FIG. 2 are here proposed by way of purely illustrative example. For example, in this figure we see that the cardinality of the stop connecting the "Root" node to the "Entity” node is here "1. * ", which means that the "Root” node has one or more class instances. described in the "Entity” class.
  • the arrows in this figure illustrate the dependencies between the different nodes, the nodes of this model being the following ones:
  • Entity node this node designates a place, a person, an animal
  • Data node this node represents the data of the central data platform 4.
  • the sources of these data are the sensors, the aggregate data of a sensor, the data from the data providers 9 (ex: data environmental, data from social networks, or more generally any internet data);
  • infrastructure node this node describes the different objects relating to the home environment, such as the objects "Box”, “Equipment”, “Sensor”, “Actuator” previously mentioned.
  • infrastructure There are two types of infrastructure: managed or unmanaged.
  • managed infrastructure denotes any object associated with a communication box 5 and, more generally, any connected object that can exchange data with the central data platform 4 and that can be supervised by the data management system 100. .
  • a managed infrastructure is inventoried in the data management system 100 and configurable under the responsibility of this system.
  • unmanaged infrastructure means any object or equipment 1 that can not be supervised by the data management system 100.
  • Such an infrastructure remains however inventoried, that is to say, known data management system 100;
  • actor node such a node designates the actors of the platform.
  • An actor may be a user of the platform, a user service provider 7, a equipment supplier 2 or a service consumer.
  • the role of each actor makes it possible to define the access rights to the data and services;
  • ITN Provider Information Technology Provider
  • this node describes all the providers of the central data platform 4: service providers 7 and / or service providers 11 elementary;
  • “Client Account” node this node describes the account of a customer who subscribes to a set of services offered by the central data platform 4, or any user having equipment 1 supporting services offered by the central data platform 4 .
  • FIG. 3 then describes the class diagram associated with the "Data" node previously described, that is to say the classes inheriting the "Data” node to classify the different types of data.
  • a data item may include a measurement unit, for example refer to a temperature or a pressure measured by a sensor.
  • a physical quantity may be associated with a plurality of measurement units.
  • a temperature measurement it is possible to associate Celsius and Fahrenheit units; a data item may not include a measurement, for example when it relates to a state (eg: open or closed state of a door);
  • a data item may be of the media type, for example text, an image or video.
  • Data may furthermore comprise a plurality of sources
  • “Sensor data” these data come from sensors, and are for example raw data (untreated) returned by the sensors, or a set of aggregated data according to a predetermined structure (eg structured according to a pivot format), this together relating to the measurements of at least one sensor; “Environmental data”: these are data that are not provided by the system 100. These data relate to a set of aggregated data of a predetermined geographical area (eg region, city) and may relate as examples temperatures, pressures or particle levels; "Internet data” says “web data”: this data can be text, image, video or any other multimedia support provided by a data provider 9.
  • Figure 4 illustrates a class diagram describing the instances of the "Entity” node.
  • a datum relating to the "Entity” class may be classified in one of the following instances (“subclasses”):
  • “Place” class any space equipped with sensors, for example a business or a home;
  • Object class generally any object placed in a physical space (eg office, home) using one or more sensors to measure a physical quantity or a state.
  • a physical space e.g office, home
  • an object may be a refrigerator equipped with a temperature sensor and transmission / reception means.
  • a place may comprise a plurality of objects.
  • Figure 5 is a topological diagram describing the different types of place and their compositions.
  • the system 100 aims to manage all the equipment 1 or connected objects deployed in different locations, said equipment 1 or objects being themselves arranged in specific areas and provided with sensors.
  • a place is either a business or a home.
  • data relating to the "Location" class can be categorized in the "Home” or "Company” instances.
  • the “Home” class includes here for instance the following classes: “Kitchen”, “Dining room”, “Stay”, “Room”, “Guest room”, “Cellar”, “Garden”, “Garage”.
  • the “Enterprise” class can be implemented by the following bodies: “Home”, “Meeting Room”, “Office”, “Executive Office”, “Open Area” commonly referred to as “Open Space” Anglicism , “Technical Room”, “Archive”, “Sanitary”.
  • the characteristics of the "Sensor" class introduced in FIG. 2 make it possible to provide data to the basic service providers 11 for the development of reliable services.
  • a sensor can be described not the following characteristics:
  • reaction time of the sensor
  • Figure 6 illustrates a topological diagram for classifying a data pertaining to the "Sensor" class.
  • the "Sensor" class includes for instances:
  • a class "physical magnitude sensor” this type of sensor allows measurement of a physical quantity such as a flow of water, gas, electricity consumption, a temperature value, pressure, or a humidity rate ;
  • Sensor of state this type of sensor makes it possible to identify the state of an object, for example the state of a door (closed or opened).
  • Other examples include a presence sensor, or an image sensor.
  • the "Actor” node of FIG. 2 comprises for instance the "Role” node, an actor of the system 100 that can combine different roles.
  • Figure 7 illustrates the topological subset relating to this latter entity.
  • the "Role” class includes the following instances:
  • Data Provider class: a data provider 9 provides data that will be exploited by the services offered by the central data platform 4;
  • Equipment Provider an equipment supplier 2 provides hardware objects for the system 100 such as sensors, equipment 1, actuators;
  • Service Provider class: a user service provider 7 provides and exposes the user services on the central data platform 4;
  • Service consumer class refers to the actors operating the services exposed by the central data platform 4.
  • a builder Household appliance equipment can leverage data from the 4 Central Data Platform to adapt its offer.
  • a user service provider 7 or equipment provider 2 can use services exposed by the central data platform 4.
  • the actor is both a service / equipment provider and a service consumer;
  • User class designates a person, situated for example in a home or a company, having at least one communication box 5 of type
  • FIG. 8 is a topological diagram illustrating, according to the UML standard, the modeling of a service.
  • the node symbolizing the "Service” class is connected by stops to the following instances: "Supplier”, “Consumer”, “Interface”, “Type of service”.
  • a service of the data management system 100 has the following characteristics:
  • the data management system 100 makes it possible to provide user services and manage these services from their technical design to their deployment.
  • the central data platform 4 offers basic services and elaborate services, the latter being carried out via a fixed number of basic services.
  • Figure 9 illustrates the topological relationship between these different services, we distinguish:
  • request-type services these services concern the data.
  • the data can be raw data relating to sensors or aggregated data;
  • notification services these services perform a set of specific operations, relying on the data stored in the central data platform 4.
  • these services make it possible to carry out a diagnosis, or to recommend a scenario relating to equipment 1, in order to optimize the consumption of non-renewable energies such as electricity, gas, and water;
  • these services are performed according to a predetermined sequence of workflows, commonly referred to as the "workflow”. These services make it possible to carry out a set of operations by making common use of the basic services.
  • the set of previously described nodes, as well as their topological subsets constitute a semantic data model.
  • the Big Data Analytics mega-data module 13 (or the central data platform 4) is configured to apply a processing on the data recorded in the central platform 4.
  • the analytic mega-data module 13 classifies, segments, aggregates, abstracts and / or formats any data from the central platform 4.
  • each data item includes a characteristic identifier of its origin, for example an identifier relating to the address of an internet network or a communication box
  • the analytics module 13 of big data classifies according to these identifiers the raw or aggregated user data from the sensors, or the data internet provided by 9 data providers.
  • the mega-data analytics module 13 optionally proceeds to this data at an abstraction / anonymization step, making it possible to preserve their confidentiality, and then makes them accessible to the user service providers 7.
  • the mega-data analytics module 13 provides services for different phases of use of the data stored in the central data platform 4. We distinguish the following phases:
  • this phase identifies trends by analyzing data from the internet and social networks.
  • the analytic mega-data module 13 provides data analysis tools and methods (eg Pig / Hive) for the user service providers 7.
  • these tools enable the user service providers 7 to identify subjects relating to the data recorded in the central data platform 4, and to develop statistical indicators with respect to these subjects.
  • the mega-data analytics module 13 conducts analysis on data from social networks or search engine queries, which data is provided by the data providers 9 to the central data platform 4.
  • the result of the analysis carried out by the mega-data analytics module 13 is then returned to the user service provider 7 in the form of keywords, enabling it to identify a relevant topic of topicality with a view to realizing user services;
  • the central data platform 4 provides reliable (possibly abstract) data
  • the analytic mega-data module 13 offers tools for the analysis of these data.
  • the analytic mega-data module 13 proposes statistical tools based on
  • PCA principal component analysis
  • MCA multiple correspondence analysis
  • clustering o methods of grouping data commonly referred to as "clustering".
  • the reliable data analyzed / correlated by the analytic mega-data module 13 are made available to the various user service providers 7 via a reporting service (of the "reporting" type) and refer, by way of examples. , sensor data, environmental data, or user data;
  • this phase allows different providers 7 of user services to deploy their services in the data management system 100.
  • the analytic mega-data module 13 provides the user service providers 7 with service lifecycle management tools and control tools capable of guaranteeing prerequisites for the deployment of a service. in the data management system 100;
  • this phase implements recommendation algorithms to recommend services to data management system 100 stakeholders. For example, during this phase, it is recommended that basic services to user service providers 7, user services and / or user service usage scenarios to individuals be used.
  • the recommendation services provided by the data management system 100 are based on collaborative filtering methods.
  • a Collaborative filtering is carried out, for example, by the analytic mega-data module 13 by applying a method able to compare the users with each other (eg type of service used, type of data consumed, user behavior), or elements noted in advance (eg user services previously noted by their customers).
  • the data management system 100 proposes during this phase an equipment self-tuning service 1. To do this, the setting of a device 1 is stored for a predefined period in the central platform 4.
  • a "best scenario" service is provided by the data management system 100, in order to advocate or reproduce the best scenario for a user service, such as setting up a device or managing a device. a resource (eg water, gas, electricity).
  • a resource eg water, gas, electricity.
  • the recommendation of the best scenario is based on the result of an analysis conducted by the analytic mega-data module 13, this analysis being performed on information reported by equipment 1 of a similar category of users. To do this, we use clustering algorithms of the "k-means" or "canopy” type.
  • the implementation of the best scenario service is carried out via the following steps:
  • the data management system 100 proposes to customers to note the user services they use in an online shop, or to the user service providers 7 to note the basic services made available to them for carrying out the services. users.
  • a phase makes it possible to anticipate the obsolescence of the services.
  • the platform uses learning algorithms based on statistical methods, such as logistic regression methods or tree methods.
  • the mega-data analytics module 13 is configured to associate each service with a threshold, and calculate a score relating to said service. If the service score is below the threshold, then the service then identified by the mega-data analytics module 13 as obsolete, the user service providers 7 are then notified.
  • the central data platform 4 relates to access (with segregation) to data and user services.
  • the central data platform 4 indeed plays a pivotal role in the management and transmission of data with the communication boxes 5, the analytic big data analytics module 13 (Big Data Analytics) and the various data actors / consumers. such as the user service providers 7.
  • the central data platform 4 is associated with equipment implementing the AAA protocol.
  • the central data platform 4 exhibits a or several application programming interfaces called “API” (acronym for “Application Programming Interface”), and optionally a graphical user interface called "GUI" (Graphical User Interface), allowing the data provisioning of data consumers (customers, suppliers). user services), applications that consume data, and to manage data access permissions, for example based on preconfigured roles and thresholds.
  • API application programming interface
  • GUI graphical user interface
  • the exposure of one or more API application programming interfaces by the central data platform 4 is dedicated to the suppliers and allows:
  • the exposure of one or more application programming API interfaces dedicated to the end users allows through a front layer (eg: website, mobile applications) to propose
  • end users of equipment the purchase of online user services, for example via an online store offered by an application;
  • the integration of the data in the central data platform 4 is seen by the different entities as an intermediate layer, ensuring the transit of information flows between:
  • the communication boxes 5 that is to say the information from the sensors of each equipment 1;
  • semantic base such as the semantic data model previously described
  • a service management portal facilitates automated interactions with the equipment 1 or information systems suppliers.
  • the various devices (equipment 1, sensors, actuators) connected to a communication box 5 can come from different vendors, who do not have prior knowledge of each other, these devices being at the supported by the communication box 5 and the central data platform 4.
  • the central data platform 4 then trivializes the data coming from said devices, exposing them as services (eg action, alert, data), thus allowing the development of services relating to multiple devices and / or multiple vendors, these services being subsequently deployed at the level of the central data platform 4 or the different communication boxes 5.
  • the integration of the data into the central data platform 4 makes it possible subsequently to undertake a list of actions communicated by the central data platform 4 to at least one communication box 5, said box being connected to a certain number of equipments 1.
  • these actions are determined according to the semantic model, and are possibly related:
  • a preconfigured action trigger event for example, an action configured to be triggered at a predefined date or time
  • the central data platform 4 when receiving an event such as a notification or a metric, the central data platform 4 via a data integration layer:
  • the event may optionally contain parameters associated with a specific equipment 1;
  • using the mega-data analytics module 13 classifies the event with the help of a semantic database, and establishes a correlation between this event and an associated service;
  • an execution mechanism eg associated with the equipment 1
  • said mechanism being configured to generate an action associated with the service as well as the event
  • a communication box 5 in the downward direction: from the central data platform 4 to a communication box 5, for example when sending a command to a device 1 of the actuator type; in the uplink direction: from a communication box 5 to the central data platform 4, for example when a measurement coming from a sensor of a device 1 is being raised.
  • a communication box 5 is located in an "internal" local network (eg LAN) and connects to an "external" remote network (eg Internet) via an integrated access device, commonly referred to as IAD ("Integrated") Access Device ").
  • IAD integrated access device
  • the integrated access device IAD is provided by an Internet access provider and allows to exchange data streams of different types via a single connection.
  • each previously described communication box 5 connects to the central data platform 4 behind an integrated access device IAD.
  • the integrated access device IAD establishes a connection with the central data platform 4.
  • the integrated access device IAD and the central data platform 4 have public addresses, while the communication box 5, located behind the integrated access device IAD, has a private address, not addressable from the central data platform 4.
  • such an architecture makes it possible for any communication box 5 located behind the integrated access device IAD to be able to initiate a data connection (uplink) to any broad internet platform while remaining protected from external threats.
  • any communication box 5 arrives via the integrated access device IAD to reach the central data platform 4, for example during the feedback of measurements or events returned by sensors.
  • the central data platform 4 has no means to reach the communication box 5, because of its private addressing behind the integrated IAD access device.
  • the communication box 5 may be temporarily unavailable from the point of view of the integrated access device IAD, for example in case of temporary disconnection or a simple electrical disconnection.
  • any integrated access device IAD provides a network address translation rules function, commonly referred to as NAT ("Network Address Translation"), for matching a public address / an output port of the integrated access device IAD a private address / an input port relating to a communication box 5.
  • NAT Network Address Translation
  • Such a function is however not performed by default and requires for its activation the configuration of rules.
  • the remote control and the sending of action to one or more devices 1, connected to a communication box 5, from the central data platform 4, are realized by the implementation of four mechanisms whose general operation is briefly recalled here:
  • a box-type communication box 5 establishes a connection via a transmission control protocol, hereinafter referred to as TCP, the acronym for Transmission Control Protocol.
  • TCP transmission control protocol
  • This connection is established via the creation of a tunnel from the communication box 5 to a proxy server associated with a remote platform.
  • a tunnel is established between a communication box 5 and a proxy disposed in the central platform 4 data.
  • the tunnel is then kept open by the communication box 5, for example by sending dummy packets ("dummy packets"), or re-opened in case of disconnection.
  • the creation of this tunnel takes place in the uplink direction, that is to say from the communication box 5 to the central data platform 4.
  • the establishment of the tunnel then allows the flow of information rising or falling between the communication box 5 and the central platform 4 data.
  • the central data platform 4 sees the communication box 5, as if the IAD integrated access device was absent and implements a bidirectional data exchange mechanism.
  • Such a mechanism nevertheless remains highly resource-consuming on the proxy servers by maintaining open TCP connections with the different communication boxes;
  • IGD protocol Internet protocol
  • the IGD protocol is described in the UPnP (Universal Plug and Play) standard.
  • UPnP Universal Plug and Play
  • the "boxes" of the operators that is to say the integrated access devices IAD in this document, propose functions of the router type, "firewall” ("firewall” in English) and
  • UPN User Planar Planar Planar Planar Planar Planar Planar Planar Planar Planar Planar
  • Some network applications such as peer-to-peer P2P applications, sometimes offer when installing on a computer machine an automatic configuration option via the use of a "UPnP” type mechanism.
  • the principle of this mechanism consists, via a UPnP controller present in the integrated access device IAD, to configure via the IGD protocol, a NAT "Network Address Translation" function of the traffic light.
  • This configuration makes it possible in particular to establish a mapping between the public ports / public addresses of the IAD, and the private ports / private addresses of connected objects behind the firewall of the IAD, and this in a manner transparent to the user.
  • the IGD protocol establishes, via the NAT function, a correspondence between a private address and a private port to a communication box deployed in a local network, and a public address and a public port to the central data platform 4 deployed. on the Internet.
  • this mechanism then allows the central data platform 4 to then see the communication box 5, as if the integrated access device IAD was absent and proposes a bidirectional data exchange mechanism.
  • This mechanism nevertheless presents risks of the security type: the reconfiguration of the firewall is potentially open to any third party software connected to the local network of the IAD, and once the "mapping" set up, the communication box 5 is potentially exposed to risks of attacks from the Internet.
  • This messaging protocol is based on the TCP, XML protocols and replaces the Jabber protocol which is an instant messaging protocol.
  • the XMPP protocol is described in specification TR-069. In particular, Annex K.2 of Version 1.4 of this specification
  • a CPE is, for example, the communication box 5 deployed in a local area network.
  • this appendix is summarized here, additional details can be found in this one:
  • Auto-Configuration Server establishes a connection with an XMPP server.
  • the ACS self-configuration server and the XMPP server are, for example, installed in an Internet network;
  • said self-configuration server ACS activates the use of the XMPP protocol at a CPE by configuring an XMPP object "XMPP Connection object", optionally providing a set of authorized Jabber identifiers;
  • said CPE establishes an XMPP connection (by the uplink) with the XMPP server; o
  • the ACS self-configuration server tries to communicate with the CPE, it sends an "XMPP Connection Request” message to the XMPP server.
  • This message is an XMPP "stanza”, commonly referred to as “XMPP IQ Stanza”, and includes a "Connection Request” connection request indicating an authorized Jabber identifier for origin, referring to the ACS auto-configuration server, and indicating for destination an identifier relating to the CPE.
  • the XMPP server then sends the message "XMPP IQ
  • the ACS auto-configuration server is associated with the central data platform 4.
  • this then makes it possible to implement an "alarm clock” type mechanism, making it possible to reduce the consumption of resources compared with the preceding mechanisms: any CPE, for example each communication box, is warned (“awakening") that it must contact the central data platform 4 with a rising stream in order to retrieve the downstream data stream in return.
  • any CPE for example each communication box, is warned (“awakening") that it must contact the central data platform 4 with a rising stream in order to retrieve the downstream data stream in return.
  • such a mechanism makes it possible to improve the security of the communication box 5;
  • STUN simple traversal through NAT
  • CPE eg the communication box
  • IAD Internet-connected device
  • NAT Network-on-distance Protocol
  • UDP User Datagram Protocol
  • the use of this protocol requires the assistance of a third party, namely a STUN server deployed in a public network such as the Internet.
  • the STUN protocol is described in the TR-111 specification ("Applying TR-069 to Remote Management of Home Networking Devices", December 2005).
  • the "2.2 Procedures” part of this specification describes the procedure of the STUN protocol so that a CPE can receive a UDP connection request from a remote ACS auto-configuration server.
  • the ACS autoconfiguration server and the STUN server are deployed on the public address side of the NAT function of the integrated access device IAD.
  • Part 2 of the TR-111 specification is summarized here, additional details can be found in this:
  • the ACS auto-configuration server enables the use of the STUN protocol for the CPE (if this configuration is not enabled by default) and designates a STUN server to communicate with the CPE;
  • the CPE uses the STUN protocol, to find out if it is behind a NAT gateway with an allocated private address;
  • the CPE uses the procedure defined by the STUN standard to discover the expiration of its data link behind the NAT gateway ("binding timeout");
  • the CPE In order to perform the "mapping" step, the CPE periodically sends STUN link requests to the STUN server, called "STUN Binding Requests". This makes it possible to keep the link of the STUN server.
  • the CPE determines the public IP address and the public port used for the link of the NAT gateway (used to listen for "UDP Connection Requests")
  • the CPE transfers the determined “mapping" information to the server.
  • ACS auto-configuration, for example by sending a "STUN Binding Request" message;
  • the ACS auto-configuration server then establishes a UDP connection with the CPE, by sending a message of "UDP Connection Request" UDP connection request to the port and public address of the NAT gateway, determined by the CPE;
  • the ACS auto-configuration server and the STUN server are associated with the central data platform 4.
  • this then makes it possible to implement an "alarm clock” type mechanism, making it possible to reduce the consumption of resources compared with the preceding mechanisms: any CPE, for example each communication box, is warned (“awakening") that it must contact the central data platform 4 with a rising stream in order to retrieve the downstream data stream in return.
  • any CPE for example each communication box, is warned (“awakening") that it must contact the central data platform 4 with a rising stream in order to retrieve the downstream data stream in return.
  • such a mechanism is relatively resource-inefficient on the central data platform 4.
  • the periodic sending of requests "STUN
  • Binding request "which leaves open the NAT gateway, potentially exposes the CPE to external attacks.
  • each of the mechanisms introduced above will be able to offer remote handling, as well as sending action to equipment 1 connected to a communication box 5.
  • one or more of these four mechanisms are chosen according to the technical constraints and operational.
  • a single mechanism is selected for each communication box 5 based, as examples, the security level of the mechanism, its complexity of implementation, its resource consumption, and / or its level of security. dependency on the IAD integrated access device. This choice can, for example, rely on the table previously exposed.
  • ACS auto-configuration servers are then deployed, making it possible to manage the communication boxes 5 and the initialization of the various mechanisms.
  • an abstraction layer is also implemented via a manager 14 of actions, integrated at the level of the central data platform 4, offering a unified interface, that is to say independent of the type of mechanism implemented and therefore the protocol used by this mechanism.
  • the abstraction layer for example, is made using a method for formatting the data received / recorded by this layer in a pivot format.
  • the manager 14 is configured to manage
  • each communication box 5 uses a single mechanism of "tunnel via proxy", "UPnP", “XMPP” type, or "STUN”, selected at the time of their deployment and in accordance with the operational constraints.
  • the selected mechanism is stored in the central data platform 4 via a database associated with the action manager 14.
  • the action manager 14 is configured to:
  • Setting waiting is particularly advantageous when the communication box 5 is temporarily unavailable, for example during a loss of connection with the central data platform 4;
  • o to process the action request 16 for example: identify the targeted equipment (identifier, address), identify the communication box to which it is connected, identify the communication mechanism to be used with said communication box 5 to transmit the action request 16. These different identifications are, for example, made by comparing the identifier of the equipment with a set of pre-recorded information in the database;
  • the mechanisms based on the XMPP and STUN protocols are of the "wake up" type: the communication box 5 is warned that it must contact the central data platform 4 by a rising stream in order to recover in return the descending data stream. In order to support this mechanism, two components are then realized:
  • a wakeup agent made on the communication box 5 by the establishment of a middleware layer, commonly referred to as angling "middleware” layer.
  • angling Middleware
  • the production of such a layer allows any application of the communication box 5 to subscribe to a wake up service, allowing it to be woken by a central application;
  • Wakeup Server via the realization of a middleware layer on the central data platform 4, allowing any "consumer” action service (integrated or not on the central data platform 4) to wake up an application of the communication box 5.
  • FIG. 11 illustrates the functional flow of data relating to an action consumer, such as a user service provider 7: the action consumer 17 pushes (stream 18) an action request 16 to the action manager 14 of the central data platform 4.
  • This request 16 action includes information on the type of action to be performed and the equipment 1 targeted by this action (eg equipment identifier, description of the action).
  • This action request 16 may optionally be accompanied by a validity expiry date and an address, for example a "uniform resource locator" address, referred to as the URL, for notifying the reception and / or processing of the request. 16 by the communication box 5;
  • the stock manager 14 stores (stream 19) queued in the database 15 this request and acknowledges (stream 20) the action request 16 issued to notify the consumer 17 of action that it has well taken into account;
  • the actions manager 14 identifies the communication box 5 and its corresponding access mechanism, then transmits the action request 16 to the communication box 5.
  • the transmission of the action request 16 depends on the type of communication mechanism, two situations that may arise
  • ⁇ manager 14 shares contacts the housing 5 via the public communication address provided by the tunnel, or the integrated access device IAD in the case of a UPnP mechanism;
  • the action manager 14 sends (stream 21) a request to the communication box 5 to provide it with the request 16 for action. Otherwise, the action manager 14 waits for the re-establishment of the tunnel or UPnP reconfiguration to then send the action request 16, possibly managing the expiry dates of the action request 16;
  • the action manager 14 contacts the alarm server ( "Wakeup Server” middleware layer) of the platform 4 data central;
  • this wake-server attempts to wake housing 5 of communication by a low level protocol (XMPP in STUN or as appropriate).
  • a low level protocol XMPP in STUN or as appropriate.
  • the content of the alarm message to the communication box 5 is limited, and can be limited to the type of alarm, for example: an alarm for action on the equipment 1 or an alarm clock for a remote control of
  • this message relates ideally to a protocol in non-connected mode, for example to the "user datagram protocol" said UDP.
  • the wake-up server also manages retransmission functions, because the communication box 5 is not necessarily accessible at the time of removal of the action;
  • the alarm message reaches the alarm agent ( "Wakeup Agent") of the latter, which is then in charge of analyzing the type of alarm and initiating the connection to platform 4 central data and towards the right application to recover the pending actions;
  • the communication box 5 then executes or transmits to the equipment 1 to which it is connected, the action request 16 and returns (stream 22) a report to the manager 14 of actions;
  • the stock manager 14 (flow 23) then reports to the consumer 17 shares, the proper execution of the action associated with its initial application (if specified in the initial application).
  • Figure 12 illustrates the main flows of a communication mechanism, for implementing a tunnel between the communication box 5 and a proxy server 24.
  • a communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address located behind the integrated access device IAD.
  • the integrated access device IAD has, moreover, a second communication port, allowing it to be addressable from an external network 26, for example an Internet network, via a public address.
  • a central data platform 4 includes an action manager 14 associated with a database, as well as an ACS auto-configuration server 27 as described in specification TR-069.
  • the proxy server 24 is deployed in a proxy platform 28, able to exchange data with the central data platform 4.
  • each communication box 5 being permanently connected with a proxy server
  • such an architecture allows a same proxy server to manage a plurality of communications boxes in a specific proxy platform.
  • Each proxy platform 28 uses a certain number of TCP connections with the central data platform 4, this number being independent of the number of communication boxes to which it is connected. To do this, it is possible to use multiplexing techniques.
  • such an architecture allows the 24 proxys servers to be seen from the central data platform 4, as virtual instances of the communication boxes 5, but deployed on a public network (eg Internet). Such a configuration is particularly advantageous because it makes it possible to overcome the problems concerning the addressing of the communication boxes 5 in a private network.
  • the self-configuration server ACS 27 located in the central data platform 4 makes it possible to inform any communication box 5 during its initialization of the proxy server to which it is attached.
  • the establishment of the tunnel between the communication box 5 and the proxy server 24 is now described. The establishment of this tunnel occurs at each initialization of the communication box 5 and comprises the following steps:
  • this communication is declared to the central data platform 4 via the autoconfiguration server 27 ACS according to the management protocol TR-069;
  • the communication box 5 is then taken into account by the central data platform 4, and the latter chooses a proxy server 24 to establish a tunnel with the communication box 5, and associates it with the communication box 5 .
  • the proxy server 24 is chosen by the central data platform 4, according to geographical proximity and availability;
  • the communication box 5 establishes (flow 30 of the figure) then a TCP connection with the proxy server 24, and sends a message (non-standard) link "BIND" to indicate its identification.
  • the "BIND" message comprises the identifier of the communication box 5, as well as the parameters of the TCP connection (ex: address and remote port, socket).
  • the receipt of this message by the proxy server 24 will therefore allow the latter to manage the virtual instance of the box 5 of communication, retaining for this instance the identifier of the communication box 5, as well as the parameters of the TCP connection;
  • this TCP connection is then kept permanently open by the communication box 5.
  • FIG. 13 then illustrates, for the preceding architecture, the main data flows enabling remote handling of the communication box 5 and / or equipment 1:
  • an external actor 31 such as a user service provider 7, sends (stream 32) a start-up request, for a communication box 5 or a device 1, to the autoconfiguration server 27 ACS;
  • the autoconfiguration server 27 ACS sends (stream 33) then a connection request message "Connection Request", in accordance with the specification TR-069, to the proxy server 24, specifying in this message a identifier relating to the recipient final grip, for example relating to a communication box 5 (or a device 1) targeted;
  • the proxy server 24 selects the virtual instance of the communication box 5, and therefore the corresponding tunnel 34;
  • the proxy server 24 then transmits via the corresponding tunnel 34 the connection request "Connection Request” to the communication box 5 (stream 35);
  • the communication box 5 then processes the request and transmits
  • FIG. 14 illustrates, for the same architecture, the main data streams making it possible to transmit an action request 16 to an actuator associated with a device 1: an external actor 37 such as an action consumer sends (stream 38) an action request 16 to the action manager 14 of the central data platform 4;
  • an external actor 37 such as an action consumer sends (stream 38) an action request 16 to the action manager 14 of the central data platform 4;
  • the stock manager 14 then stores said action request 16 in the database 15 and then sends the action request 16 to the proxy server.
  • the action manager 14 opens a TCP connection and is configured to send (stream 39) two requests to the proxy server 24:
  • a first request which is a (non-standard) connection request "CONNECT", including the identification of the targeted communication box 5.
  • CONNECT non-standard connection request
  • the "CONNECT" message makes it possible to specify to the proxy server 24 that the following requests, namely the requests for action, must address the communication box 5; a second request corresponding to the action request 16, according to a syntax identical to the case of a communication unit 5 directly visible from the Internet, for example a syntax http (s);
  • the proxy server 24 selects the virtual instance of the target communication box 5 and the corresponding tunnel 34.
  • this realizes a temporary association within the proxy server, between the connection of the actions manager 14 to this server and the tunnel 34 of the communication box 5;
  • the proxy server 24 then acknowledges the actions manager 14 the good reception of the connection request message "CONNECT". As long as the action manager 14 does not receive this acknowledgment, for example when the tunnel 34 is not established, the action manager 14 is configured to periodically reissue this message or wait for the restoration of the tunnel 34;
  • the action manager 14 when the acknowledgment of the "CONNECT" message is received by the action manager 14, the latter then transmits the second request, ie the action request 16 to the server
  • the proxy server 24 sends (stream 40) then through the tunnel 34 the action request 16 as received to the targeted communication box 5;
  • the communication box 5 then executes the requested action or else transmits it to the device 1 concerned for execution, then returns (flow 41) then a report to the proxy server 24 via the tunnel 34;
  • the server 24 proxy transmits (flow 42) then the report as received to the manager 14 actions;
  • the action manager 14 if requested, the action manager 14 then notifies (stream 43) the external actor 37 of the good execution of its initial action request by the communication box 5 or the equipment 1 concerned.
  • FIG. 15 again illustrates, for the same mechanism, the main data flows making it possible to trace a measurement of a sensor associated with a piece of equipment 1.
  • the central data platform 4 furthermore comprises a manager 44 of measurements associated with a data base 441, making it possible to manage (store and / or make available) the data associated with the sensors of the different equipment 1.
  • the process of measurement feedback to the central data platform 4 from the sensor of a Equipment 1 connected to a communication box 5 is as follows: the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1;
  • the communication box 5 sends (stream 45) then to the proxy server 24, via the previously established tunnel 34, the measurement by a message indicating that the target is the measurement manager 44, for example by using a message of the "GET" type http (s) ";
  • the proxy server 24 then initiates a TCP connection to the measurement manager 44 and transmits (flow 46) the measurement.
  • FIG. 16 illustrates the main flows implemented for establishing a connection between the central data platform 4 and a communication box 5 for a communication mechanism implementing the UPnP protocol.
  • the communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address;
  • the integrated access device IAD has a second communication port, enabling it to be addressable from an external network, for example an internet network, via a public address;
  • the central data platform 4 comprises an action manager 14 associated with a database 15 (not shown in this figure), as well as an ACS auto-configuration server 27 as described in the specification TR-069 .
  • the box 5 communicates to the central data platform 4 by the autoconfiguration server ACS 27 via the management protocol TR-069;
  • the communication box 5 is then taken into account by the central data platform 4, and the latter activates in the communication box 5 the use of the UPnP protocol;
  • the communication box 5 then transmits UPnP requests to the integrated access device IAD, in order to open a public TCP communication port, thereby enabling activation (stream 47) of the NAT network address translation function;
  • the communication box 5 transmits (stream 48) then to the server
  • FIG. 17 then illustrates, for the preceding mechanism, the main data streams, allowing remote handling of the communication box 5 and / or equipment 1:
  • an external actor 31 such as a user service provider 7 sends (flow 49) a start-up request to the autoconfiguration server 27 ACS;
  • the autoconfiguration server 27 ACS sends (stream 50) a "Connection Request” message, in accordance with the specification TR-069, to the communication box 5. To do this, it sends the "Connection Request” message to the public address of the integrated access device IAD, on the public TCP port opened during UPnP establishment. The integrated access device IAD then transmits the message to the communication box 5 by applying the NAT network address translation function;
  • the communication box 5 then processes the command and sends (stream 51) back an "Inform request" message, in accordance with the standard TR-069, to the server 27 for auto-configuration ACS to notify the processing the request;
  • the handling of the communication box 5 then follows the protocol TR-069, as any type of network topology with a CPE (here the box 5 communication).
  • FIG. 18 illustrates, for the same mechanism, the main data streams making it possible to transmit an action request to an actuator associated with a device 1:
  • an external actor 37 such as a post action consumer (stream 52) a request for action to the stock 14 data center platform manager 4;
  • the stock manager 14 then stores said request in the database 15 and then sends (stream 53) the request to the communication box 5. To do this, it sends the request to the public address of the integrated access device IAD on the open public TCP port when establishing the UPnP.
  • the device
  • the integrated access access IAD then transmits via the use of the NAT network address translation function the request to the communication box;
  • the communication box 5 then executes the requested action, or otherwise transmits it to the equipment 1 concerned for execution, then returns (flow 54) then a report to the action manager 14.
  • the action manager 14 is configured to periodically reissue this message or wait for the reset function to resume.
  • NAT UPnP network address translation if requested, the stock manager 14 (flow 55) then informs the external actor 37 of the proper execution of its initial action request by the communication box 5 or the equipment 1 concerned.
  • FIG. 19 again illustrates, for the same mechanism, the main data flows making it possible to trace a measurement of a sensor associated with a device 1, towards the central data platform measurement manager 44:
  • the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1;
  • the communication box 5 initiates (stream 56) then a connection, for example of the type "http (s)" to the manager 44 of measurements of the platform 4 central data;
  • the communication box 5 finally transmits the measurement by a message indicating that the target is the measurement manager 44, for example by using a message of the type "GET http (s)".
  • FIG. 20 then illustrates the main flows implemented for establishing a connection between the central data platform 4 and a communication box 5 for a communication mechanism implementing the XMPP protocol. Just as before:
  • the communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address;
  • the integrated access device IAD has a second communication port, enabling it to be addressable from an external network 26, for example an internet network, via a public address;
  • the central data platform 4 comprises an action manager 14 associated with a data base, as well as an ACS auto-configuration server 27 as described in the specification TR-069.
  • an http proxy server 57 and an XMPP proxy server 58 are deployed in a platform 28 proxy, the platform 28 proxy being able to exchange data with the platform 4 central data.
  • each communication box 5 is permanently connected to an XMPP proxy server 58.
  • the realization of such an architecture allows a same XMPP proxy server 58 to manage a plurality of communication boxes 5 in a specific platform 28.
  • the HTTP proxy servers 57 will be used for the upload of measurements or the recovery of actions via http requests.
  • Each platform 28 proxy uses, for its part, a fixed number of connections with the platform 4 central data, this number of connections being independent of the number of communication box 5 to which it is connected. To do this, it is possible to use multiplexing techniques. Furthermore, depending on the number of communication boxes 5, it is possible, if necessary, to add additional proxy platforms, as well as XMPP proxy servers 57 and HTTP proxy servers 57, thus participating in the extensibility of this architecture.
  • the autoconfiguration server 27 ACS located in the central data platform 4 then makes it possible to inform any communication box 5 when it initializes the XMPP proxy server 58 to which it is attached. Similarly, during the configuration of the communication box 5, when it is started, the ACS self-configuration server 27 is in charge of informing the communication box 5 of its proxy proxy server 57.
  • the establishment of an XMPP connection between the communication box 5 and the XMPP proxy server 58 is now described.
  • the establishment of this connection occurs at each initialization of the communication box 5 and comprises the following steps:
  • the communication box 5 reports to the central data platform 4 by the autoconfiguration server 27 ACS via the management protocol TR-069;
  • the communication box 5 is then taken into account by the central data platform 4, and the latter chooses a proxy proxy server XMPP 58, for example according to a geographical proximity and a server availability 58 proxy
  • the self-configuration server ACS 27, establishes (stream 59) then a connection with the XMPP proxy server 58, which will then be kept open by the ACS self-configuration server 27; then via the "SetParameterValues" message of the protocol TR-069, the server 27 of ACS self-configuration active in the communication box 5, the use of the XMPP protocol by providing (stream 60) the address of the server, and as Jabber credentials allowed.
  • the identifiers the identifiers
  • Authorized Jabbers are declared identically in the XMPP proxy server 58 and the ACS auto-configuration server 27, and allow any XMPP client, for example the communication box 5, to identify themselves during the XMPP exchanges; -
  • the communication box 5 establishes (stream 61 of the figure) then an XMPP connection with the XMPP proxy server 58, this connection will then be kept permanently open by the communication box 5.
  • FIG. 21 illustrates, for the architecture and the preceding mechanism, the main data flows enabling remote handling of the communication box 5 and / or equipment 1:
  • an external actor 31 such as a user service provider 7 sends (flow 62) a start-up request to the autoconfiguration server 27 ACS;
  • the autoconfiguration server 27 ACS sends (stream 63) then, in accordance with appendix K.2 of the specification TR-069, a connection request message "Connection Request" in XMPP ("stanza” XMPP) of type “XMPP IQ Stanza") to the XMPP proxy server 58.
  • the autoconfiguration server 27 ACS specifies in this message, the final recipient of the grip, for example a targeted communication box 5, and the source of this message identified by an authorized Jabber identifier.
  • the structure of such a message is in particular detailed in the appendix K.2.3.1 of specification TR-069;
  • the XMPP proxy server 58 (stream 64) then transmits the message to the communication box 5 via the XMPP protocol; the communication box 5 then receives the message, and generates an XMPP response message ("XMPP IQ Stanza” XMPP stanza) of the "result" type if the previous message is correctly taken into account, or of type "Error” otherwise.
  • the structures of these response messages are respectively detailed in Annex K.2.3.2 and K.2.3.3 of Specification TR-069;
  • the communication box 5 then processes the request and sends (stream 65) an "Inform request" message, in accordance with the specification TR-069, to the autoconfiguration server 27 ACS to notify it of the processing.
  • the request ; the handling of the communication box 5 (or equipment 1), then follows the protocol TR-069, as any type of network topology with a CPE (here the box 5 communication).
  • FIG. 22 illustrates, for the same architecture and the same protocol, the main data streams making it possible to transmit an action request 16 to an actuator associated with a device 1:
  • an external actor 37 such as an action consumer sends (stream 66) an action request 16 to the action manager 14 of the central data platform 4;
  • the action manager 14 then stores said action request 16 in the database 15, then sends the action request 16 via an "Action Request” message in XMPP ("XMPP IQ Stanza” type message) to the server 58 XMPP proxy.
  • the "Action Request” message comprises an originator Jabber authorized and recipient as the box 5 communication.
  • the "Action Request” message since the "Action Request” message is not described in the specification TR-069, it is possible to draw inspiration from the structure of the "Connection Request” message described in appendix K.2.3.1 of this specification. specification, to implement this message.
  • An exemplary embodiment of the "Action Request” message is given below.
  • the XMPP proxy server 58 receives the "Action Request” message, and then acts as a "wake-up server", by transmitting (stream 68) this message to the communication box 5 via the XMPP protocol .
  • the XMPP proxy server 58 is capable of storing said message if the communication box 5 is disconnected, and then reissuing it when reconnecting the communication box 5;
  • the communication box 5 then receives the message, and generates an XMPP response message (XMPP stanza "XMPP IQ Stanza") of the "result" type if the previous message is correctly taken into account, or of the "error” type otherwise .
  • XMPP response message XMPP stanza "XMPP IQ Stanza" of the "result" type if the previous message is correctly taken into account, or of the "error” type otherwise .
  • the structures of these response messages are respectively detailed in Annex K.2.3.2 and K.2.3.3 of Specification TR-069;
  • the communication box 5 then initiates an http (s) connection to retrieve requests for pending actions.
  • This connection is established (stream 69) with proxy server 57 of proxy platform 28, which itself will interrogate (stream 70) the stock manager 14 with a view to retrieving the requests for actions, for example via a message of the type "GET http".
  • the use of the http proxy server 57 in the proxy platform 28 then makes it possible to optimize the resources of the central data platform 4 by avoiding multiple http connections initiated directly from the different communications boxes 5; the action manager 14 then provides in response the action requests to the communication box 5 via the connection established with the XMPP proxy server 58.
  • the action manager 14 manages, moreover, the expiry of the requests for actions according to two modes:
  • the communication box 5 then executes the requested action or else transmits it to the device 1 concerned for execution, then returns, via the http proxy server 57, a report to the action manager 14;
  • the share manager 14 if requested, the share manager 14 then notifies (stream 71) the external actor 37 of the good execution of its initial action request by the communication box 5 or the equipment 1 concerned.
  • FIG. 23 again illustrates, for the same architecture, the main data flows making it possible to trace a measurement of a sensor associated with a piece of equipment 1.
  • the central data platform 4 comprises a measurement manager 44 associated with a data base 441, making it possible to manage (store and / or make available) the data associated with the sensors of the different equipment 1.
  • the process of measurement feedback to the central data platform 4 from the sensor of a connected equipment 1 to a communication box 5 is as follows:
  • the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1;
  • the communication box 5 initiates (stream 72) an http (s) connection to the proxy proxy http server 57 of the platform 28: the http proxy server 57 then initiates an http (s) connection to the metrics manager 44 of the central data platform 4;
  • the communication box 5 sends (stream 73) then to the server 57 http proxys, via the http (s) established connection, the measurement by a message indicating that the target is the manager 44 measures, for example using a message of the type "GET http
  • FIG. 24 illustrates the main flows implemented for the establishment of a tunnel, for a communication mechanism between the communication box 5 and the central data platform 4, for a communication mechanism implementing the STUN protocol.
  • the communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address.
  • This private address is, as an example, addressable via a gateway / NAT network address translation function constituting the integrated access device IAD;
  • the integrated access device IAD has a second communication port, enabling it to be addressable from an external network, for example an internet network, via a public address;
  • the central data platform 4 comprises an action manager 14 associated with a database 15 (not shown in this figure), as well as an ACS auto-configuration server 27 as described in the specification TR-069 .
  • the central data platform 4 includes a STUN server 74, in accordance with the TR-111 specification. As explained below, such a server will establish a "tunnel" awakening between the central platform 4 data and the communication box 5.
  • the establishment of the connection between the communication box 5 and the central data platform 4 is now described.
  • the establishment of this connection occurs at each initialization of the communication box 5 and comprises the following steps: at the time of its initialization, the communication box 5 declares itself to the central data platform 4 by the autoconfiguration server 27 ACS via the management protocol TR-069;
  • the communication box 5 is then taken into account by the central data platform 4, and the latter activates in the communication box the use of the STUN protocol;
  • the communication box 5 transmits (stream 75) STUN Binding Requests STUN link requests to the STUN server 74 of the central data platform 4, in accordance with part 2.2 of the TR-111 specification.
  • the responses of the STUN server 74 to these requests then allow the communication box 5 to discover the public address of the integrated access device IAD.
  • the communication box 5 transmits (stream 76) then the identified public address of the integrated access device IAD, to the auto-configuration server ACS 27 via the management protocol TR-069.
  • the identification of the public address of the integrated access device IAD enables the communication box 5 to discover the presence of a gateway / NAT function in the integrated access device IAD, and to establish through this gateway / function a UDP connection with the server 74 STUN in order to keep this connection open, the communication box 5 sends (flow 77) then periodically a STUN link request message of type "Binding
  • this period is configured in such a way that the integrated access device IAD does not deactivate the NAT function after a period of inactivity, and is at the same time sufficiently long in order to avoid saturation in server resources. 74 STUN.
  • the communication box 5 performs a learning mechanism, initially sending "Binding Request" connection request messages with a low period, and then progressively increasing the transmission period of these messages. . This determines a limit period for which the box no longer receives a "Binding Response" connection response from the server 74 STUN. From this state, the period identified as usable by the communication box 5 is the period before this period.
  • FIG. 25 illustrates, for the preceding mechanism, the main data flows allowing remote handling of the communication box 5 and / or equipment 1:
  • an external actor 31 such as a user service provider 7 sends (stream 78) a start-up request to the ACS auto-configuration server 27;
  • the autoconfiguration server 27 ACS contacts (stream 79) the server 74 STUN, in accordance with the specification TR-111, and asks it to send a connection request message "Connection Request" according to the UDP protocol, destination of the communication box 5.
  • the realization of such a message is described in section 2.2.2.3 of this specification.
  • the STUN server 74 is then the only element allowed by the integrated access device IAD to use the NAT network address translation function to the communication box. In fact, following the establishment of the connection with the STUN server 74, the integrated access device IAD only knows the address relating to the STUN server 74 and the UDP port used with this server;
  • the STUN server 74 (stream 80) then sends a connection request UDP message to the communication box 5 to the public UDP port of the integrated access device IAD (used by the translation gateway function / gateway). NAT network address to establish the connection with the communication box 5).
  • the integrated access device IAD then transmits this message to the communication box 5 via the NAT network address translation gateway function;
  • the communication box 5 then processes the command and sends back an "Inform request" message, in accordance with the TR-069 standard, to the ACS auto-configuration server 27 (stream 81) to inform it of the processing of the request;
  • FIG. 26 illustrates, for the same mechanism, the main data streams making it possible to transmit an action request 16 to an actuator associated with a device 1:
  • an external actor 37 such as an action consumer sends (stream 82) an action request 16 to the action manager 14 of the central data platform 4;
  • the action manager 14 then stores said action request 16 in the database 15, and then contacts the server 74 STUN (stream 83), in accordance with the specification TR-111, and asks it to send a message "Action Request" in
  • the message "Action Request” is not described in the specification TR-111, we can be inspired by the structure of the message “Connection Request” described in section 2.2.2.3 of this specification, for implement this message.
  • An exemplary embodiment of the "Action Request” message is given below. This specifies a non-empty path associated with the uniform resource identifier called "URI” of this message. To build this message, add the highlighted path “ActionRequest”, between a field of type "hostname”, here "10.1.1.1:8080", and the arguments of this message specified after the "? »:
  • the STUN server 74 is then the only element allowed by the integrated access device IAD to use the NAT function to the communication box. In fact, following the establishment of the connection with the STUN server 74, the integrated access device IAD only knows the address relating to the STUN server 74 and the UDP port used with this server;
  • the server 74 STUN sends (flow 84) then to the communication box 5 a UDP action request message "Action Request" to the public UDP port of the integrated access device IAD (used by the translation gateway function). NAT network address to establish the connection with the communication box 5). The integrated access device IAD transmits then this message to the communication box 5 by applying the NAT network address translation function;
  • the communication box 5 receives the message and sends an acknowledgment message (action response) "Action Response", in accordance with the TR-111 standard, to the server 74 STUN.
  • the "Action Response” message is a UDP message made similarly to the "Action Request” message, via the use of a non-empty path.
  • An example embodiment for this message is given below:
  • the server 74 STUN does not receive this response response acknowledgment "Action Response", for example when the NAT UDP function is not established, the server 74 STUN is configured to periodically reissue the UDP message "Action Request" or wait the restoration of the NAT network address translation function;
  • the communication box 5 then initiates (uplink) an http (s) connection to the stock manager (stream 85) in order to retrieve the requests for pending actions;
  • the action manager 14 then provides in response the action requests to the communication box 5, while managing the expiry of the requests for actions according to two modes:
  • the communication box 5 then executes the requested action or otherwise transmits it to the device 1 concerned for execution, then returns a report to the action manager 14; if requested, the stock manager 14 (flow 86) then informs the external player 37 of the good execution of his request 16 initial action by the communication box 5 or the equipment 1 concerned.
  • the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1;
  • the communication box 5 initiates (stream 56) then a connection, for example of the "http (s)" type, to the data manager 44 of the central data platform 4;
  • the communication box 5 finally transmits the measurement by a message indicating that the target is the measurement manager 44, for example by using a message of the type "GET http (s)".
  • a communication box 5 (box type) is deployed in a specific environment or physical location, comprising one or more equipment 1, each of these equipment 1 providing user services.
  • each communication box 5 serves:
  • the communication box 5 is also shared between several actors, for example equipment vendors 1 or 7 providers of user services. Therefore, the communication box 5 houses common and specific software components (including user services) to said actors, to manage the communication with the different equipment 1 or perform a local data processing on the data from these equipments 1. In this context, it is commonly spoken of architecture "multi-tenants".
  • the communication box 5 thus implements a platform i ntergi sky services. On this platform, the functions specific to each actor, for example the communication protocol used with a device 1 or the specific processing of data associated with a device 1, are deployed by the actors in the form of service-oriented software components. .
  • a failure or a diversion of a software component associated with an actor therefore, must not impact and degrade the behaviors of the software components relating to the other actors hosted on the same platform. For example, a memory overflow resulting from a coding anomaly of a service must not propagate in the platform, under the risk of causing the "crash" of the other services.
  • the equipment 1 connected to the communication box 5 is heterogeneous and based on different communication protocols. Thus, commonly a software component initially communicating with equipment 1 according to a protocol, will evolve when the equipment 1 changes because the associated protocol is also evolve. In addition, the change of a device 1 can also cause a modification of the access method of the communication box 5 to the data of the equipment 1.
  • the communication box 5 initially accesses the data of the device 1. 1 equipment via a method of "pull" type: the equipment 1 exposes an API application programming interface and the communication box 5 takes the initiative to recover the measurements of a sensor associated with this equipment 1. A change this equipment 1 then leads to the use of a push access method: the data are pushed at the initiative of the equipment 1 to the communication box 5. As a result, the software component to communicate with this equipment must also evolve.
  • a multi-tenant java platform providing isolation between services hosted by the platform.
  • a Java / OSGi platform based on a Haas model (hardware as a service) is implemented via application components placed in a shared container called "Kernel” and in separate and sealed containers. "Features”.
  • a platform is made so that the memory space allocated to each container is accessible only if the latter is configured to allow access.
  • the access of an authorized user to a container is then performed through an API programming application interface, which limits the access of the user to the strict necessary. It is thus impossible to use stack overflow techniques to circumvent the control and illicit access to the container's memory zone from the outside.
  • the container memory can not be accessed or corrupted from outside the container, the "Kernel” shared container and the “Features” sealed containers running within a Java JVM, and this one authorizing only the execution of isolated or communicating containers only through explicitly exposed and controlled methods.
  • the programming code components of the "Kernel” is then considered as reliable (without anomalies), while the user services are grouped in separate "Features” specific to each provider.
  • such a structure then guarantees a strong isolation between the user services, preventing any failure of one service having an impact on the others, ensures a management of the material resources (ex: memory occupation, computing resources) by "Feature” and limits the error propagation of any software component.
  • Figure 27 illustrates the operating concept of a software platform 87 with the previously described features.
  • the software platform 87 is a platform shared between several users, two in this example, and hosts all the services of the users each relating to a device.
  • a first service 88 refers to a first equipment 89
  • a second service 90 relates to a second equipment 91.
  • the first equipment 89 and the second equipment 91 are connected externally to the software platform 87 of the housing 5 of communication, and use for their exchanges respectively a first and a second protocol.
  • any remote / remote service accessible via an API application programming interface, can substitute for a device 89, 91.
  • any service allowing generalization can be understood.
  • the element 91 may be a remote service instead of the second equipment, this service using the second protocol.
  • the specific software components, including the services 88, 90, specific to each user are respectively isolated in sealed containers 92, 93, commonly referred to as "sandbox" or "Feature”.
  • a unified API application programming interface 94 then makes it possible to access the devices 89, 91 or remote services from the services 88, 90 applications, or more generally to any external software or hardware element, called “eThing", connected to the platform 87 software of the communication box 5.
  • a first and a second adapter 95, 96 protocol is respectively associated with the first and second equipment 89,91, each of these adapters being respectively interfaced with a first and a second adapter 97,98 "eThing
  • the adapters specific to the same equipment are isolated in the same sealed container ("Feature").
  • the protocol adapters 95, 96 and the adapters 97, 98 of "eThing" element are respectively deployed in the containers 92, 93.
  • the same protocol adapter may possibly be shared between several users.
  • the unified API application programming interface 94, the protocol adapters 95, 96 and the adapters 97, 98 of "eThing" elements thus constitute a unified access structure ("framework"). say an access layer to connected equipment 1, 89, 91.
  • FIG. 28 illustrates an example of distribution of the elements of the software platform 87 previously described, combined with a Java / OSGi approach based on a Haas model (acronym for "Hardware as a Service") produced by application components placed in a container 100 shared said "Kernel”, and in separate containers 101, 102 and sealed says "Features”.
  • a Haas model ascronym for "Hardware as a Service
  • Java interfaces 103 constituting the unified API application programming interface 94, detailed later, and data classes corresponding to the objects exchanged at the application programming interface 94, for example structured data (eg binary, Boolean) recovered by the equipment 1, 89, 91;
  • structured data eg binary, Boolean
  • protocol adapters 104 shared by all users, that is to say shared by different services, for example Zigbee adapters, or serial ports; o common user services 105, for example a rules engine, and a service for publishing data to a REST-type interface (acronym for "Representational State Transfer”);
  • each container 101, 102 separate "Features” (software components), specific to a user, embarks
  • User-specific services 106, 107 for example preprocessing services on the data of a device 1, 89, 91;
  • protocol adapters 108, 109 specific to their equipment
  • Adapters 110, 111 of "eThing" elements implementing the unified API application programming interface interface 94.
  • Figure 29 illustrates the realization of the unified access framework (framework) 99, including the unified API application programming interface 94.
  • the latter is interfaced with an "eThing" element adapter via an interface designated hereafter as interface element 112 "eThing", this interface being an OSGi service.
  • interface element 112 "eThing" is the "eThing” element adapter 97 of the first device 89 (not shown).
  • the element adapter 97 "eThing” is itself interfaced with the protocol adapter 95.
  • the unified API 94 application programming interface, the "eThing" element adapter 97 and the protocol adapter 95 thus constitute the unified access structure 99.
  • each device 89 or more generally any connected "eThing" element, is represented in the unified access structure 99 by an OSGi service implementing the "eThing" element interface 112, this service comprising the following attributes : a state, a unique identifier, a name, a seller, a version, a serial number, a description.
  • an element adapter 97 "eThing” implements the OSGi interface “eThing”, is interfaced with a protocol adapter 95 via a "bindProtocolAdapter ()” method, this method being able to associate any protocol adapter 95 with any "eThing” element, and includes for fields: a "Status” status, a unique identifier "UID”, a name “NAME”, a vendor “VENDOR”, a "VERSION” version, a number of series “SERIAL_NUMBER", a description "DESCRIPTION”
  • the functions of the equipment 1, 89, 91 are represented by OSGi services implementing an abstract element function interface 113 named "eThingFunction" and three basic interfaces:
  • Control Control Interface 116 for controlling the state of a device and / or acting on it, and comprising two functions
  • BinaryControl in the case where the state associated with the sensor of a device is of binary type.
  • the value of this state is then represented by a class named "BinaryData”;
  • MultiLevelControl in the case where the state of the sensor associated with a device comprises several states (multivalued).
  • the value of this state is then represented by a class named "MultiLevelData”;
  • a sensor interface 119 called "Sensor”, for collecting, periodically or not, a value from a sensor of a device 1, 89, 91, according to two functions:
  • BinarySensor if the associated sensor is of binary type.
  • MultiLevelSensor a multi-level sensor function 121 named "MultiLevelSensor", if the associated sensor case is multivalued. The value is then represented by the class named "MultiLevelData”.
  • a new equipment 1, 89, 91 or added service is supported in the system by the addition of adapter 97 elements "eThing" via an "eThingAdapter” class implementing the previously described interfaces.
  • the element adapter 97 "eThing" is connected to the protocol adapter 95, the latter exposing a service with an OSGi interface adapted to the specific communication protocol of this equipment 89.
  • the specific interfaces adapted to the communication protocols comprise two basic interfaces named "CommProtocolAdapter" and
  • Each service in the "ProtocolAdapter” interface exposes at least the following two properties: type, vendor.
  • Each type of protocol adapter 95 then defines an OSGi interface that extends the "CommProtocolAdapter" interface.
  • an interface composed of associated methods, parameters and return values
  • each protocol adapter is associated with a Protocol Adapter Factory (PAF), which enables the creation of a protocol adapter with appropriate properties.
  • PAF Protocol Adapter Factory
  • each PAF protocol adapter factory defines an interface that extends the "ProtocolAdapterFactory” interface.
  • the protocol adapter created by the PAF protocol adapter factory is then associated with an "eThing" element adapter.
  • the "eThing" element adapter can then optionally notify the PAF protocol adapter factory that it no longer uses the protocol adapter, thereby freeing up any resources.
  • An exemplary embodiment of protocol adapter 95, extending the OSGi class "ProtocolAdapter”, presenting for properties a type “TYPE” and a vendor “VENDOR” is given below:
  • each protocol adapter is associated with a PAF protocol adapter factory, extending the "ProtocolAdapterFactory" interface and realized as follows:
  • ProtocolAdapterFactory ⁇
  • ProtocolA dapterException
  • ProtocolA dapterException
  • the unified access framework 99 comprises the following two programmatic interfaces:
  • a publication / subscription interface 122 named "publish / subscribe”, allowing, according to an event mode o the asynchronous reception of events or data originating from a device 1, 89, 91 or from a service, after a step d subscription / subscription of the user, to the structure 99 ("framework") unified access (eg to a specific service 88, 90);
  • Asynchronous publishing from the unified access framework eg: from a specific 88, 90 service, data or events to a device 1, 89, 91 or service related to one or more subscribed users;
  • a request interface 123 allowing, according to a synchronous mode, the retrieval, reading / writing of data from / to equipment 1, 89, 91 or service, to / from the structure 99 ( "Framework”) unified access (eg to / from a specific service 88, 90).
  • the request interface 123 named “request” makes it possible to send requests on the data reading equipment 1 (89, 91) ("GET” type message) or write (message “eThing") of type "SET” on an attribute or invocation of an operation).
  • a static method comprising as arguments the "uid” identifier of the "eThing” element, as well as the name the "eThingFunction” element function.
  • the publication / subscription interface 122 named "publish / subscribe”, in turn:
  • ⁇ D extends Data> publishDatafD publisher data, String eThingName, eThingVersion String, String eThingUid, String eThingFunctionName)
  • this makes it possible to reinject data from an application service or at a higher level than the unified API application programming interface interface 94 on this interface, for example, from a complex event processing engine CEP, acronym for "Complex". Event Processing ".
  • CEP complex event processing engine
  • Such a CEP engine can be both a consumer and a producer of data on the API application programming interface 94.
  • the production of data results from the creation of a new event by the CEP engine (eg by correlation of other events), these data being then consumed by applications via the publication / subscription interface 122 publish / subscribe "; to subscribe to data produced on "eThings" elements, by defining an event filter called “EventFilter”, allowing to record an event "listener” on the service, commonly designated by anglicism "Listener”.
  • EventFilter an event filter
  • a callback function is used, commonly referred to as "callback”.
  • the "callback" callback function makes it possible to implement an event interface 124 relating to the "eThing" element function called interface "EThingFunctionEvent" which has only one method:
  • EventFilter eventFilter EventFilter.eventFilter (context);
  • eventFilter registerEThingFunctionEventHandlerfhdl, Data .class, getNamef), getVersionf), getUidf), null);
  • the set of user application services are based on the unified API application programming interface 94, allowing an abstraction of the devices 1, 89, 91 and the underlying communication protocols.
  • the unified API application programming interface 94 offers a means of abstracting the access mode to the devices 1, 89, 91 that it is synchronous (pull data mode) for the reading or the data writing, or whether it is asynchronous or linked to an event (pushed data mode "push") for reading data from the equipment 1, 89, 91, via the interfaces 122, 123 of publication / subscription "publish” / subscribe “and” request "request.
  • any mode not implemented natively by a device 1, 89, 91 is then simulated by the structure 99 ("framework") unified access.
  • FIG. 30 illustrates, by way of example, a piece of equipment 1 operating in a synchronous mode (pull mode), interfaced with the structure 99
  • a unified access framework comprising the unified API application programming interface 94, which structure is interfaced with a first user service 125 based on synchronous mode, and a second user service 126 based on an asynchronous mode.
  • the first user service 125 therefore uses the request interface 123 "request", while the second service 126 user uses the publication / subscription interface 122 "publish / subscribe" of the API 94 application unified application programming interface.
  • Unified Access Framework 99 In this example, the request modes emanating from the first user service 125 are represented by the arrow 127, while the publication / subscription modes "publish / subscribe" are respectively represented by the arrows 128, 129.
  • the synchronous mode "request” in writing and reading is implemented by a simple delegation, that is to say by a simple method call, on the native interface of the equipment 1: we then use messages like "SET” in propagated writing (arrow 130) on the equipment 1 and "GET” in reading returning the last value / data read on the equipment 1.
  • the latter mode is then simulated by the unified access framework 99 by retrieving periodically (arrow 131), via the request interface 123, the data on the equipment. and memorizing the last data read. The latter data is then sent to the publication / subscription interface "publish / subscribe" 122.
  • FIG. 31 illustrates a piece of equipment 1 operating in an event mode (push mode) interfaced with the unified access structure (framework) 99 comprising the unified API application programming interface 94, this structure being interfaced with a first synchronous mode based user service 125, and a second user service based on an asynchronous mode.
  • the first user service 125 therefore uses the request interface 123 "request”, while the second service 126 user uses the publication / subscription interface "publish / subscribe” of the unified API application programming interface interface 94.
  • structure 99 ("framework") unified access.
  • the request modes emanating from the first user service 125 are represented by the arrow 127, while the publication / subscription modes "publish / subscribe” are respectively represented by the arrows 128, 129.
  • the equipment 1 pushes its data to the publication / subscription interface 122 "publish / subscribe”.
  • the arrow 128 relates to the propagation of the data that the equipment 1 pushes (arrow 132) at each new event.
  • the equipment 1 being this time based on asynchronous mode, the structure 99 ("framework") unified access simulates this time the synchronous mode by storing the last data pushed by the equipment 1 via the interface 122 publication / subscription "Publish / subscribe”. This data is then sent to the request interface 123 "request”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Telephonic Communication Services (AREA)
  • Selective Calling Equipment (AREA)

Abstract

Boitier (5) de communication pour la gestion d'une pluralité d'équipements (1) utilisateur incluant des capteurs et des actionneurs installés dans un environnement prédéfini, ce boitier (5) comprenant -une première interface de communication pour récupérer au moins une mesure mesurée par au moins un capteur de ladite pluralité d'équipements(1) utilisateur; -une deuxième interface de communication pour communiquer au moins une commande à au moins un actionneur de ladite pluralité d'équipements (1) utilisateur; -des moyens pour isoler les ressources pour la récupération de ladite première donnée et pour la communication de ladite commande.

Description

BOITIER DE COMMUNICATION ET DE GESTION D'EQUIPEMENTS
L'invention a trait à un boîtier de communication et de gestion d'équipements, dans un système multi-vendeurs et multi-services, permettant la gestion de données d'un ensemble d'objets ou d'équipements connectés à un réseau.
Avec l'émergence de l'internet des objets, de plus en plus de services sont proposés aux particuliers et aux professionnels, par exemples des services pour des domiciles ou des bureaux comprenant des objets connectés. Dans un contexte domotique, il est possible via des équipements/objets comprenant des capteurs et des actionneurs, déployés dans une maison et connectés à un réseau, de proposer des services assurant :
le confort domestique, permettant
o d'automatiser et piloter des équipements à partir d'un poste fixe, ou à distance, par exemples : via une télécommande, un ordinateur portable, un téléphone ;
o d'automatiser des actions grâce à la géo-localisation, par exemples : ouvrir un portail, allumer le chauffage, gérer l'éclairage, activer une alarme ;
des économies d'énergie, permettant
o d'éviter le gaspillage en supprimant les dépenses inutiles ; o d'assurer un niveau de confort optimal ;
o de maîtriser la consommation d'électricité en optimisant par exemples : le chauffage, l'éclairage ou la production d'eau chaude ;
une protection domiciliaire par des systèmes permettant
o de superviser des personnes fragiles, âgées ou handicapées ;
o de surveiller des enfants afin de prévenir tout risque d'accident ;
o de détecter des intrusions, des chutes de personnes, des fuites d'eau, et déclencher une alarme le cas échéant.
Cependant, les systèmes existants proposant ces services présentent divers inconvénients ou limitations :
les acteurs de l'internet des objets sont nombreux et variés, à titre d'exemples : fabricants d'équipements connectés, éditeurs/distributeurs de services domiciliaires, opérateurs de télécommunications, énergéticiens, assureurs. Typiquement, un acteur propose une offre basée sur un certain nombre d'équipements, de capteurs, et/ou d'actionneurs, sélectionnés chez un autre fournisseur identifié. Ceci nécessite donc un travail collaboratif étroit entre l'acteur concerné et les équipes de recherche et développement du fournisseur identifié, en vue de proposer une solution d'intégration des produits. Certains acteurs de l'internet des objets proposent, quant à eux, une large variété d'équipements connectés, tout en demeurant, parfois, leur propre développeur de services utilisateurs. Bien que la collaboration avec les équipes de recherche et développement s'en voit alors facilitée, ces acteurs demeurent cependant incapables d'intégrer des équipements de fournisseurs distincts dans leurs plateformes, ces plateformes étant propriétaires. Plus généralement, l'ensemble des solutions intégrées dans une même plateforme sont couramment des solutions qui intègrent a priori des équipements de vendeurs déterminés. Les possibilités d'intégrations a posteriori d'équipements, de capteurs, et/ou d'actionneurs, restent quant à elles très limitées. Ces possibilités sont, en outre, dépendantes des caractéristiques des solutions fournisseurs amenées à évoluer, par exemple dépendantes des protocoles propriétaires employés et de leurs évolutions. Par conséquent, ces solutions manquent d'adaptabilité ;
les équipements, capteurs ou actionneurs connectés des systèmes proposant des services, sont généralement propriétaires, c'est-à-dire se rapportent à un même vendeur/fournisseur. Un boîtier de communication, couramment désigné sous l'appellation « box », assure alors l'interconnexion des différents équipements, capteurs ou actionneurs avec des plateformes de services ou des réseaux externes. Ainsi, pour différents services fournis par des vendeurs différents, l'utilisateur est souvent obligé d'utiliser un boîtier de communication par vendeur, ce qui implique des problèmes d'ergonomie dans son domicile ;
les équipements propriétaires connectés à un même boîtier de communication sont hétérogènes et reposent couramment sur des protocoles de communication différents non-standardisés. Par conséquent, dans le cadre d'un contexte multi-vendeurs, si un équipement change, son protocole de communication change lui aussi fréquemment. Ceci implique une dépendance du boîtier vis- à-vis des équipements, le boîtier devant alors supporter le nouveau protocole de l'équipement, c'est-à-dire garantir les accès et échanges avec ce nouvel équipement ;
plusieurs vendeurs peuvent être amenés, avec leurs accords, à proposer des services distincts sur un même boîtier. Des services multi-vendeurs sont donc alors exécutés en parallèles sur le même boîtier. Ceci n'implique cependant pas de partager l'ensemble des données ou ressources associées à ces services, les vendeurs ne souhaitant par exemple pas partager des données confidentielles. Par ailleurs, l'exécution d'un service doit pouvoir se dérouler indépendamment des autres services exécutés en parallèles, par exemple indépendamment des ressources mémoires utilisées par d'autres services utilisateurs. Ainsi, le dysfonctionnement d'un service ne doit pas impacter les ressources des services voisins. Il existe donc des besoins de « cloisonnement » des services exécutés en parallèles sur un même boîtier, particulièrement pour des services utilisateurs issus de vendeurs différents ;
des fournisseurs en charge de développer des services utilisateurs peuvent vouloir accéder à un ensemble de données fiables en vue, par exemple, de concevoir des services domiciliaires sans nécessairement être un fournisseur d'équipements. Dans un contexte multi-vendeurs et multiservices, il convient notamment de déployer des services sur une plateforme, cette dernière garantissant à la fois un accès à des données fiables provenant d'équipements de vendeurs distincts, et assurer la communication ainsi que le pilotage de ces équipements. Généralement, les fournisseurs d'équipements proposent des équipements avec des possibilités de les piloter à distance, accéder à leurs données, mettre en place des scénarios, et supporter des protocoles (par exemple KNX, Zigbee,
Z-Wave). Cependant, les services proposés par ces fournisseurs se limitent au seul équipement, ou ne concernent qu'un seul fournisseur/vendeur. Le fournisseur de services doit par conséquent être un fournisseur d'équipements et ne dispose pas d'accès aux données générées par les équipements multi- vendeurs. Le fournisseur d'équipements dispose donc de données de portée très réduite, limitant fortement les informations utiles à l'élaboration d'un service utilisateur. Notamment, il n'existe actuellement pas de plateforme permettant de regrouper un ensemble de données multi-vendeurs et multi-services, en vue de garantir un accès centralisé à ces données, un pilotage d'équipements multi-vendeurs et la mise en place de scénarios multi-services (ex : déclencher le chauffage en dessous d'une température seuil). La réalisation d'une telle plateforme implique des problèmes techniques concernant la sécurisation des données, leur accès ainsi que la gestion des échanges entre une telle plateforme et les équipements.
La présente invention a pour but de répondre aux problèmes précités.
A cet effet, il est proposé, selon un premier aspect, un boîtier de communication pour la gestion d'une pluralité d'équipements utilisateur incluant des capteurs et des actionneurs installés dans un environnement prédéfini, ce boîtier comprenant
une première interface de communication pour récupérer au moins une mesure mesurée par au moins un capteur de ladite pluralité d'équipements utilisateur ;
- une deuxième interface de communication pour communiquer au moins une commande à au moins un actionneur de ladite pluralité d'équipements utilisateur ;
des moyens pour isoler les ressources pour la récupération de ladite première donnée et pour la communication de ladite commande.
Avantageusement, dans ce boîtier de communication, ladite mesure est récupérée selon un premier protocole de communication et ladite commande est communiquée selon un deuxième protocole de communication, le premier protocole étant différent du deuxième protocole. Avantageusement, ce boîtier de communication est, en outre, configuré pour transmettre au moins une donnée à une plateforme centrale de données.
Avantageusement, ce boîtier de communication, dispose d'une adresse privée non adressable depuis ladite plateforme centrale de données.
Avantageusement, dans ce boîtier de communication, ladite donnée est un paramètre associé à un équipement de ladite pluralité d'équipements utilisateur.
Avantageusement, ce boîtier de communication comprend, en outre, une interface de programmation applicative.
Avantageusement, ce boîtier de communication est, en outre, configuré pour recevoir ladite commande.
Il est proposé, selon un deuxième aspect, un réseau local comprenant ledit boîtier de communication résumé ci-dessus.
Avantageusement, ce réseau local comprend, en outre, un dispositif d'accès intégré interfacé avec ledit boîtier de communication.
D'autres objets et avantages de l'invention apparaîtront à la lumière de la description de modes de réalisation, faite ci-après en référence aux dessins annexés dans lesquels :
la figure 1 est un diagramme représentant un système de gestion de données multi-vendeurs et multi-services selon un mode de réalisation ;
la figure 2 est un schéma relationnel de modélisation de données selon un mode de réalisation ;
la figure 3 est un diagramme de classe d'un nœud du schéma relationnel de modélisation de données selon un mode de réalisation ;
la figure 4 est un diagramme de classe d'un autre nœud du schéma relationnel de modélisation de données selon un mode de réalisation ;
la figure 5 est un diagramme topologique décrivant un autre nœud du schéma relationnel de modélisation de données selon un mode de réalisation ;
- la figure 6 est un diagramme topologique décrivant un autre nœud du schéma relationnel de modélisation de données selon un mode de réalisation ; la figure 7 est un sous-ensemble topologique décrivant un autre nœud du schéma relationnel de modélisation de données selon un mode de réalisation ;
la figure 8 est un diagramme illustrant les éléments relatifs à un service selon un mode de réalisation ;
la figure 9 est un diagramme illustrant la relation entre différents services selon un mode de réalisation ;
la figure 10 est une figure illustrant un gestionnaire d'actions selon un mode de réalisation ;
- la figure 11 illustre un flux de données relatives à un consommateur d'action selon un mode de réalisation ;
la figure 12 illustre l'établissement d'un tunnel, pour un mécanisme de communication entre un boîtier de communication et un proxy selon un mode de réalisation ;
- la figure 13 illustre la prise en main à distance du boîtier de communication pour le mécanisme de communication avec un proxy selon un mode de réalisation ;
la figure 14 illustre la transmission d'une demande d'action vers un actionneur associé à un équipement pour le mécanisme de communication avec un proxy selon un mode de réalisation ;
la figure 15 illustre la remontée d'une mesure d'un capteur associé à un équipement pour le mécanisme de communication avec un proxy selon un mode de réalisation ;
la figure 16 illustre l'établissement d'une connexion entre une plateforme centrale et un boîtier de communication pour un mécanisme de communication implémentant le protocole UPnP selon un mode de réalisation ;
la figure 17 illustre la prise en main à distance du boîtier de communication pour le mécanisme de communication implémentant le protocole UPnP selon un mode de réalisation ; la figure 18 illustre la transmission d'une demande d'action vers un actionneur associé à un équipement pour le mécanisme de communication implémentant le protocole UPnP selon un mode de réalisation ;
- la figure 19 illustre la remontée d'une mesure d'un capteur associé à un équipement pour le mécanisme de communication implémentant le protocole UPnP selon un mode de réalisation ; la figure 20 illustre l'établissement d'une connexion entre une plateforme centrale et un boîtier de communication pour un mécanisme de communication implémentant le protocole XMPP selon un mode de réalisation ;
- la figure 21 illustre la prise en main à distance du boîtier de communication pour le mécanisme de communication implémentant le protocole XMPP selon un mode de réalisation ; la figure 22 illustre la transmission d'une demande d'action vers un actionneur associé à un équipement pour le mécanisme de communication implémentant le protocole XMPP selon un mode de réalisation ;
la figure 23 illustre la remontée d'une mesure d'un capteur associé à un équipement pour le mécanisme de communication implémentant le protocole XMPP selon un mode de réalisation ; - la figure 24 illustre l'établissement d'une connexion entre une plateforme centrale et un boîtier de communication pour un mécanisme de communication implémentant le protocole STUN selon un mode de réalisation ;
la figure 25 illustre la prise en main à distance du boîtier de communication pour le mécanisme de communication implémentant le protocole STUN selon un mode de réalisation ; la figure 26 illustre la transmission d'une demande d'action vers un actionneur associé à un équipement pour le mécanisme de communication implémentant le protocole STUN selon un mode de réalisation ;
la figure 27 illustre le fonctionnement d'une plateforme logicielle selon un mode de réalisation ;
la figure 28 illustre un exemple de répartition des éléments de la plateforme logicielle selon un mode de réalisation ;
- la figure 29 illustre la réalisation de la structure d'accès unifié selon un mode de réalisation ;
la figure 30 illustre un fonctionnement de la structure d'accès unifié avec un équipement fonctionnant selon un mode synchrone selon un mode de réalisation ;
- la figure 31 illustre un fonctionnement de la structure d'accès unifié avec un équipement fonctionnant selon un mode asynchrone selon un mode de réalisation. La figure 1 est un diagramme représentant un système 100 de gestion de données multi-vendeurs et multi-services selon un mode de réalisation. Le système 100 de gestion de données est interfacé avec les entités suivantes :
- un ou plusieurs équipements 1 disposés localement dans un lieu ou un environnement physique prédéfini, par exemple dans un environnement intérieur tel un domicile ou un bureau. Les équipements 1 sont fournis (flèche 3) par des fournisseurs 2 d'équipements, c'est-à-dire des constructeurs technologiques. Avantageusement, les équipements 1 comprennent des capteurs et permettent de remonter à une plateforme 4 centrale de données, via l'intermédiaire d'un boîtier 5 de communication de type « box », des données quantifiables et/ou de changement d'états associées aux mesures ou relevés d'état desdits capteurs (ex : mesure de température, position d'un commutateur associé à un système d'éclairage). Pour ce faire, les équipements 1 sont connectés au boîtier 5 de communication par l'intermédiaire d'un réseau filaire ou sans fil. Le boîtier 5 de communication échange quant à lui, de manière locale ou distante, des données avec la plateforme 4 centrale de données, par l'intermédiaire d'un autre réseau, par exemple Internet. En outre, les équipements 1 permettent d'effectuer des actions physiques (ex : allumer le chauffage) via l'intermédiaire d'un ou plusieurs actionneurs. Typiquement, un actionneur effectue une action suite à la réception d'une notification d'action communiquée depuis le boîtier 5 de communication. Les données échangées entre chaque équipement 1 et le boîtier 5 de communication, par exemple des remontées de données mesurées par les capteurs ou des notifications d'action à destination d'un actionneur d'un équipement 1, sont communiquées selon ou un plusieurs protocoles 6 symbolisés par une double flèche. A titre d'exemples, un protocole 6 associé à un équipement peut être un protocole KNX, Zigbee, Wifi ou Z-wave ;
des fournisseurs 7 de services utilisateurs, typiquement des acteurs du monde d'Internet, élaborant et fournissant à l'utilisateur des services utilisateurs ciblés sur un domaine particulier, par exemple des services relatifs à la sécurité, au confort, ou au bien-être. Avantageusement, ces fournisseurs 7 de services utilisateurs disposent d'une logique métier complète et réalisent des services utilisateurs sur la base de données et de services élémentaires, fournis préalablement à la plateforme 4 centrale de données. Avantageusement, ces fournisseurs 7 de services utilisateurs s'interfacent (flèche 8) avec la plateforme 4 centrale de données selon un mode orienté architecture de service, couramment désigné sous le sigle SOA (acronyme anglais de « Service Orientée! Architecture ») ;
- des fournisseurs 9 de données du monde internet, fournissant par exemple des données météorologiques, d'actualités ou encore issues de réseaux sociaux, permettant de remonter des données quantifiables (ex : mesures météo) ou des données de changement d'état. Avantageusement, ces fournisseurs 9 de données, s'interfacent (flèche 10) aussi avec la plateforme 4 centrale de données selon un mode orienté architecture de service SOA ;
des fournisseurs 11 de services élémentaires, acteurs du monde internet, fournissant des services élémentaires à la plateforme 4 centrale de données (ex : implémentation d'un service de notification), ces services étant utilisés par les fournisseurs 7 de services utilisateurs, comme des services « basiques » permettant de réaliser les services utilisateurs. Avantageusement, ces fournisseurs 11 de services élémentaires, s'interfacent (flèche 12) aussi avec la plateforme 4 centrale de données selon un mode orienté architecture de service SOA.
Par ailleurs, tout fournisseur peut éventuellement jouer une pluralité de rôles. Par exemple, un fournisseur 9 de données peut aussi être un fournisseur 2 d'équipement et un fournisseur 7 de services utilisateurs.
Avantageusement, le système 100 de gestion de données prend en compte plusieurs dimensions :
une dimension multi-services, c'est-à-dire intègre et propose une pluralité de types de services utilisateur, par exemple domotiques et e-santé ;
une dimension multi-vendeurs, les équipements 1 supportés par le système 100 peuvent provenir de différents constructeurs, et comprennent des caractéristiques propres à chacun de ces constructeurs ;
une dimension multi-niveaux, les données et les services élémentaires peuvent être fournis :
o au niveau des équipements 1 par au moins un boîtier 5 de communication ;
o au niveau du système 100 de gestion de données. Par exemple, le système 100 réalise une analyse de données fournies par des équipements 1 ou des fournisseurs 9 de données, ces données étant éventuellement abstraites au préalable pour préserver leur confidentialité. Les résultats de l'analyse permettent alors au système 100 de mettre à disposition des corrélations, tendances, prédictions sur ces données ;
o au niveau des fournisseurs 7 de services utilisateurs, par la fourniture via le système 100 de gestion de données (éventuellement abstraites au préalable), de tendances/corrélations concernant ces données, et de services élémentaires pour réaliser les services utilisateurs.
Pour ce faire, le système 100 de gestion de données comprend les entités suivantes, dont le fonctionnement sera détaillé d'avantage ultérieurement :
le boîtier 5 de communication de type « box » pouvant, par exemple, être déployé au domicile de l'utilisateur. Ce boîtier permet d'interconnecter un ou plusieurs équipements 1 via une liaison filaire ou sans fil selon un protocole prédéterminé fonction du constructeur (ex : TCP/IP, ZigBee, Wifi) et d'échanger des données avec la plateforme 4 centrale de données. Avantageusement, le boîtier 5 de communication permet
o la gestion d'équipements 1 multi-vendeurs, c'est-à-dire supporte et gère une pluralité de protocoles, ainsi que les identifications et isolations des données/ressources de chacun des services exécutés en parallèle dans ce boîtier ; o de garantir une communication sécurisée et fiable avec la plateforme 4 centrale de données ; o de fournir à la plateforme 4 centrale de données des données multi-vendeurs exploitables issues des capteurs des équipements 1 ;
o de réceptionner des notifications issues de la plateforme 4 centrale de données, se rapportant, à titre d'exemples à une prise en main à distance pour administration ou un envoi d'action(s) à exécuter par un ou plusieurs équipement 1 auquel il est interconnecté ;
la plateforme 4 centrale de données concentrant et fédérant la totalité des données provenant des boîtiers 5 de communication déployés en divers lieux (ex : domiciles, bureaux), les données issues des fournisseurs de données, ainsi que les services élémentaires nécessaires à l'élaboration de nouveaux services utilisateurs. Avantageusement, la plateforme 4 centrale de données est configurée pour :
o assurer un stockage centralisé et organisé des données, les données peuvent par exemple être organisées en fonction
■ de leur structure : données brutes issues des capteurs, consolidées, agrégées et/ou abstraites. A titre d'exemple, pour des raisons de confidentialité, des données brutes remontées depuis un capteur peuvent être formatées/structurées par la plateforme 4 centrale de données selon un format pivot, permettant d'abstraire ces données, tel un format de type XML ;
■ de leur origine : données issues des capteurs, remontées par les équipements 1 ou provenant d'un fournisseur 9 de données externe ;
■ de leur droit d'accès et de leur identification : un fournisseur 7 de services utilisateurs peut avoir un accès limité à un certain type de données ; o assurer la ségrégation des données et des services élémentaires. Avantageusement, ceci permet dans un environnement multi-vendeurs de faire bénéficier à un ensemble de fournisseurs 7 de services utilisateurs de la nature riche et multiple des données, et ce de manière contrôlée par
■ une identification et une authentification des consommateurs de ces données, ici les fournisseurs 7 de services utilisateurs ;
■ une restriction de l'accessibilité aux données/services, conformément aux droits des consommateurs de ces données ;
■ un suivi de l'usage des consommations de données/services pour chacun de ces consommateurs ;
o assurer la confidentialité des données, par exemple, une anonymisation des données via une méthode d'abstraction (ex : abstraction des données selon un même format pivot); o fédérer un ensemble de services élémentaires fournis par les fournisseurs 11 de services élémentaires, de façon à disposer d'un écosystème global, cohérent et contrôlé ; o fournir les services élémentaires aux fournisseurs 7 de services utilisateurs pour la réalisation desdits services, à titre d'exemples, des services de type flux de travail
(couramment désigné sous l'anglicisme « Workflow »), ou des services de traitement d'événements complexes CEP (acronyme anglais de « Complex Event Processing ») ;
o garantir une communication sécurisée et fiable avec les différents boîtiers 5 de communication ;
o fournir des données exploitables à un module 13 analytique de méga-donnée dit « Big Data Analytics » ;
un module 13 analytique de méga-donnée (dit « Big Data Analytics ») configuré pour analyser les données de la plateforme 4 centrale de données avec laquelle il est interfacé. Le module 13 analytique de méga-donnée permet notamment d'établir, puis mettre à disposition des fournisseurs 7 de services utilisateurs, des corrélations, tendances, et/ou prédictions des données enregistrées dans la plateforme 4 centrale de données, en générant des rapports d'analyses ( services de « reporting »).
Avantageusement, les données issues de la plateforme 4 centrale nnées sont identifiées, puis classifiées en fonction d'une topologie de données préétablie. A titre d'exemple, les figures 2 à 7 illustrent un mode de réalisation de topologie de données préétablie, selon un langage de modélisation unifié, dit UML, acronyme anglais de « Unified Modeling Language », cette topologie est détaillée ultérieurement.
Selon, divers modes de réalisations, une topologie de données est utilisée par la plateforme 4 centrale ou le module 13 analytique de méga-donnée (« Big Data Analytics ») pour classifier les données enregistrées dans la plateforme 4 centrale de données. Ainsi, dans un mode de réalisation, une topologie de données décrivant un modèle de classification de données est préenregistrée dans la plateforme 4 centrale de données, et mise à profit par cette dernière pour classifier les données. A titre d'exemple, la plateforme 4 centrale de données est configurée pour identifier la provenance d'une donnée, par exemple une mesure issue d'un capteur par lecture de son en tête, puis en fonction de sa provenance la classifier suivant la topologie préenregistrée. Dans un autre mode de réalisation, une topologie préétablie est préenregistrée dans le module 13 analytique de méga-donnée. Ce dernier est alors configuré pour ordonner/structurer les données de la plateforme 4 centrale de données, dans une base de donnée de cette plateforme (ex : une base NoSQL). Dans un autre mode de réalisation, les fonctions de la plateforme 4 centrale de données et du module 13 analytique de méga-donnée sont réalisées par un même et unique module (non représenté).
Avantageusement, les données enregistrées/manipulées dans la plateforme 4 centrale de données se présentent sous la forme d'objets métiers, c'est-à-dire de structures de données relatives, à titre d'exemples, à des équipements 1, des objets, des Meus ou des entités s'interfaçant et échangeant des données avec le système 100 de gestion de données. Dans un mode de réalisation, dans un contexte domotique, le système 100 de gestion de données comprend les objets métiers suivants :
« Domicile » : chaque domicile est associé à un identifiant unique sur la plateforme, identifié par un type (ex : particulier, entreprise) et associé à des caractéristiques qui lui sont propres (boîtiers, équipements, capteurs, actionneurs) ;
« Box » : cet objet désigne tout boîtier 5 de communication encapsulant des services/fonctionnalités et supportant différents protocoles de communication. A chaque domicile, on associe au moins un boîtier 5 de communication, c'est-à-dire un objet « Box », cet objet comprenant un identifiant unique ;
« Equipement », chaque équipement 1 est installé dans un domicile, est relié uniquement à un seul boîtier 5 de communication, et comprend un unique identifiant ;
« Capteur », un capteur permet de mesurer une grandeur physique ou identifier un changement et est associé à un seul équipement 1 ;
- « Actionneur » , un actionneur permet de déclencher une action suite à un événement et est associé à un seul équipement 1.
Par ailleurs, afin de classifier et discriminer les données enregistrées dans la plateforme 4 centrale de données, comme exposé précédemment, une topologie de données préétablie est mise en œuvre.
Un exemple de topologie est représenté sur la figure 2, sous la forme d'une arborescence composée de nœuds et d'arrêtés, en accord avec la norme UML. Cette arborescence comprend, ici, un nœud racine « Racine », les autres nœuds se rapportant aux entités de la plateforme. Plus particulièrement, chaque nœud de ce modèle est associé à un diagramme de classe, qui sera décrit ultérieurement. Avantageusement, la relation entre chaque entité est représentée par une arrête (lien) et une cardinalité. Les cardinalités de la figure 2 sont ici proposées à titre d'exemple purement illustratif. On constate par exemple sur cette figure que la cardinalité de l'arrête reliant le nœud « Racine » au nœud « Entité » est ici de « 1.* », ce qui signifie que le nœud « Racine » comporte une ou plusieurs instances de classe décrites dans la classe « Entité ». Les flèches de cette figure, illustrent les dépendances entre les différents nœuds, les nœuds de ce modèle étant les suivants :
nœud « Entité » : ce nœud désigne un lieu, une personne, un animal ;
nœud « Données » : ce nœud représente les données de la plateforme 4 centrale de données. Les sources de ces données sont les capteurs, les données agrégées d'un capteur, les données issues des fournisseurs 9 de données (ex : données environnementales, données des réseaux sociaux, ou plus généralement toutes données internet) ;
nœud « Infrastructure » : ce nœud décrit les différents objets relatifs à l'environnement domiciliaire, tels que les objets « Box », « Equipement », « Capteur », « Actionneur » précédemment cités. On distingue, par ailleurs, deux type d'infrastructures : gérée ou non gérée. On désigne, ici, par infrastructure gérée, tout objet associé à un boîtier 5 de communication, et plus généralement tout objet connecté, pouvant échanger des données avec la plateforme 4 centrale de données, et pouvant être supervisé par le système 100 de gestion de données. Ainsi, une infrastructure gérée est inventoriée dans le système 100 de gestion de données et configurable sous la responsabilité de ce système.
- Par opposition, on entend par infrastructure non-gérée, tout objet ou équipement 1 ne pouvant être supervisé par le système 100 de gestion de données. Une telle infrastructure reste cependant inventoriée, c'est-à-dire connu du système 100 de gestion de données ;
- nœud « Acteur» un tel nœud désigne les acteurs de la plateforme. Un acteur peut être un utilisateur de la plateforme, un fournisseur 7 de services utilisateurs, un fournisseur 2 d'équipements ou encore un consommateur de services. Avantageusement, le rôle de chaque acteur permet de définir les autorisations d'accès aux données et services ;
nœud « Fournisseur de technologie de l'information », couramment désigné sous l'anglicisme « Fournisseur IT » : ce nœud décrit l'ensemble des fournisseurs de la plateforme 4 centrale de données : fournisseurs 7 de services utilisateurs et/ou fournisseurs 11 de services élémentaires ;
nœud « Compte client »: ce nœud décrit le compte d'un client ayant souscrit à un ensemble de services proposés par la plateforme 4 centrale de données, ou tout utilisateur disposant d'équipements 1 supportant des services proposés par la plateforme 4 centrale de données.
La figure 3 décrit ensuite le diagramme de classe associé au nœud « Données » précédemment décrit, c'est-à-dire les classes héritant du nœud « Données » permettant de classifier les différents types de données. Comme on peut le constater sur ce schéma, une donnée : peut comporter une unité de mesure, par exemple se rapporter à une température ou une pression mesurée par un capteur. En outre, une grandeur physique peut être associée à une pluralité d'unités de mesures. A titre d'exemple, pour une mesure de température on peut associer des unités Celsius et Fahrenheit ; une donnée peut ne pas comporter de mesure, par exemple lorsqu'elle porte sur un état (ex : état ouvert ou fermé d'une porte) ;
une donnée peut être de type média, par exemple être du texte, une image ou de la vidéo.
Une donnée peut par ailleurs comporter une pluralité de sources
« Données capteurs » : ces données sont issues de capteurs, et sont par exemple des données brutes (non-traitées) retournées par les capteurs, ou un ensemble de données agrégées selon une structure prédéterminée (ex : structurées selon un format pivot), cet ensemble se rapportant aux mesures d'au moins un capteur ; « Données environnementales » : ce sont des données qui ne sont pas fournies par le système 100. Ces données se rapportent à un ensemble de données agrégées d'une zone géographique prédéterminée (ex : région, ville) et peuvent concerner à titre d'exemples des températures, pressions ou taux de particules ; « Données internet » dit « données web » : ces données peuvent être du texte, de l'image, de la vidéo ou tout autre support multimédia proposé par un fournisseur 9 de données.
La figure 4 illustre un diagramme de classes décrivant les instances du nœud « Entité ». En référence à cette figure, dans ce modèle de topologie, une donnée se rapportant à la classe « Entité » peut être classifiée dans une des instances (« sous-classes ») suivantes :
classe « Etre vivant », comprenant comme instances possibles o une classe « Personne » : à titre d'exemple pour des services d'e-Santé une personne peut être équipée de capteurs pour mesurer sa tension, sa température et disposer d'un dispositif connecté (ex : montre) pour la transmission desdites mesures associées aux capteurs ; o une classe « Animal » : un animal peut à titre d'exemple être équipé d'un collier ou d'une puce électronique permettant de le localiser ;
classe « Lieu » : tout espace muni de capteurs, par exemple une entreprise ou un domicile ;
classe « Objet » : généralement tout objet disposé dans un espace physique (ex : bureau, maison) utilisant un ou plusieurs capteurs pour mesurer une grandeur physique ou un état. A titre d'exemple, dans un domicile, un objet peut être un réfrigérateur équipé d'un capteur de température et de moyens d'émission/réception. Avantageusement, un lieu peut comprendre une pluralité d'objets.
La figure 5 est un diagramme topologique décrivant les différents types de lieu ainsi que leurs compositions. Le système 100 vise en effet à gérer l'ensemble des équipements 1 ou objets connectés déployés sur différents lieux, lesdits équipements 1 ou objets étant eux même disposés dans des zones spécifiques et munis de capteurs. Dans cet exemple, un lieu est soit une entreprise soit un domicile. Ainsi, dans cet exemple, une donnée se rapportant à la classe « Lieu » peut être catégorisée dans les instances « Domicile » ou « Entreprise ».
La classe « Domicile » comprend ici pour instances les classes suivantes : « Cuisine », « Salle à manger », « Séjour », « Chambre », « Chambre d'ami », « Cave », « Jardin », « Garage ».
La classe « Entreprise » peut quant à elle être implémentée par les instances suivantes: « Accueil », « Salle de réunion », « Bureau », « Bureau de direction », « Aire ouverte » couramment désignée sous l'anglicisme « Open space », « Local technique », « Archive », « Sanitaire ».
Il est entendu que la modélisation de ces lieux est par la suite extensible en fonction des besoins.
Avantageusement, les caractéristiques la classe « Capteur » introduite en figure 2, permettent de fournir des données aux fournisseurs 11 de services élémentaires pour le développement de services fiables. Couramment, un capteur peut être décrit pas les caractéristiques suivantes :
son étendue de mesure : les valeurs extrêmes pouvant être mesurées par le capteur ; sa résolution : la plus petite variation de grandeur mesurable par le capteur ;
sa sensibilité : la variation du signal de sortie par rapport à la variation du signal d'entrée ;
- sa précision : aptitude du capteur à donner une mesure proche de la valeur vraie ;
sa rapidité : temps de réaction du capteur ;
son protocole : protocole supporté, interface de communication utilisée.
La figure 6 illustre un diagramme topologique permettant de classifier une donnée se rapportant à la classe « Capteur ». Sur cette figure, la classe « Capteur » comprend pour instances :
une classe « Capteur de grandeur physique » : ce type de capteur permet de mesures une grandeur physique comme un débit d'eau, de gaz, une consommation d'électricité, une valeur de température, de pression, ou encore un taux d'humidité ;
une classe « Capteur d'état » : ce type de capteur permet d'identifier l'état d'un objet, par exemple l'état d'une porte (fermée ou ouverte). On peut citer à titre d'autres exemple, un capteur de présence, ou un capteur d'image.
Le nœud « Acteur » de la figure 2 comprend pour instance le nœud « Rôle », un acteur du système 100 pouvant cumuler différents rôles.
La figure 7 illustre le sous-ensemble topologique se rapportant à cette dernière entité. Avantageusement, la classe « Rôle » comprend les instances suivantes :
classe « Fournisseur de données » : un fournisseur 9 de données fournit des données qui seront exploités par les services proposés par la plateforme 4 centrale de données ;
classe « Fournisseur d'équipements » : un fournisseur 2 d'équipements fournit des objets matériels pour le système 100 tels que des capteurs, équipements 1, actionneurs ;
classe « Fournisseur de services » : un fournisseur 7 de services utilisateurs fournit et expose les services utilisateurs sur la plateforme 4 centrale de données ;
- classe « Consommateur de services » : cette instance désigne les acteurs exploitant des services exposés par la plateforme 4 centrale de données. A titre d'exemple, un constructeur d'équipements électroménagers peut exploiter les données de la plateforme 4 centrale de données pour adapter son offre. Par ailleurs, un fournisseur 7 de services utilisateurs ou un fournisseur 2 d'équipements peut utiliser des services exposés par la plateforme 4 centrale de données. Dans ce cas, l'acteur est à la fois fournisseur de services/d'équipements et consommateur de services ;
classe « Utilisateur » : cette instance désigne une personne, située par exemple dans un domicile ou d'une entreprise, disposant au moins d'un boîtier 5 de communication de type
« Box ».
La figure 8, est un diagramme topologique illustrant, selon la norme UML, la modélisation d'un service. Sur cette figure le nœud symbolisant la classe « Service » est relié par des arrêtes aux instances suivantes : « Fournisseur » , « Consommateur » , « Interface », « Type de service ». Avantageusement, un service du système 100 de gestion de donnée comporte les caractéristiques suivantes :
il est exposé (arrête « fournir par ») par un fournisseur (fournisseur 7 de services utilisateurs et/ou fournisseurs 11 de services élémentaires) sur la plateforme 4 centrale de données ; il est consommé (arrête « offrir par ») par des acteurs (ex : clients, fournisseurs) du système 100 de gestion de données ; il est associé à une interface prédéterminée. Sur la plateforme 4 centrale de données, dans la majorité des cas, le service dispose
(arrête « disposer ») d'une interface réseau ;
il est déployé sur la plateforme 4 centrale de données, c'est-à- dire sur le « Cloud », ou déployé localement sur le boîtier 5 de communication. Le lieu de déploiement conditionne le type de service (arrête « avoir »).
Avantageusement, le système 100 de gestion de données permet de fournir des services utilisateurs et de gérer ces services depuis leurs conception technique jusqu'à leur déploiement. Pour ce faire, la plateforme 4 centrale de données propose des services élémentaires et des services élaborés, ces derniers étant réalisés via un nombre déterminé de services élémentaires. La figure 9 illustre la relation topologique existant entre ces différents services, on y distingue :
les services de type requête : ces services portent sur les données. Avantageusement, en interrogeant via des requêtes la base de données constitutive de la plateforme 4 centrale de données, il est possible de fournir des données à un ou plusieurs acteurs du système 100. A titre d'exemple, les données peuvent être des données brutes relatives aux capteurs ou des données agrégées ;
- les services d'actionnement : il s'agit des services qui font appel aux actionneurs d'équipements 1 afin de réaliser une action ;
les services de notification : ces services effectuent un ensemble d'opérations déterminées, en s'appuyant sur les données stockées dans la plateforme 4 centrale de données. A titre d'exemples, ces services permettent de réaliser un diagnostic, ou préconiser un scénario relatif à un équipement 1, afin d'optimiser la consommation d'énergies non-renouvelables tel que l'électricité, le gaz, et l'eau ;
les services élaborés : il s'agit des services qui sont réalisés selon une séquence prédéterminée de flux de tâches, couramment désignées sous l'anglicisme « workflow ». Ces services permettent de réaliser un ensemble d'opérations en faisant couramment appel aux services élémentaires.
Avantageusement, l'ensemble des nœuds précédemment décrits, ainsi que leurs sous-ensembles topologiques, constituent un modèle sémantique de données. Basé sur ce modèle sémantique, le module 13 analytique de méga-donnée dit « Big Data Analytics » (ou la plateforme 4 centrale de données), est configuré pour appliquer un traitement sur les données enregistrées dans la plateforme 4 centrale. A titre d'exemple, le module 13 analytique de méga-donnée classifie, segmente, agrège, abstrait et/ou formate toute donnée de la plateforme 4 centrale. Par exemple, en supposant que chaque donnée comprend un identifiant caractéristique de son origine, par exemple un identifiant relatif à l'adresse d'un réseau internet ou d'un boîtier 5 de communication, le module 13 analytique de mégadonnée classifie en fonction de ces identifiants les données utilisateurs brutes ou agrégées issues des capteurs, ou les données internet fournies par les fournisseurs 9 de données. Par ailleurs, le module 13 analytique de méga-donnée procède éventuellement sur ces données à une étape d'abstraction/d'anonymisation, permettant de préserver leur confidentialité, puis les rend accessibles aux fournisseurs 7 de services utilisateurs.
Avantageusement, le module 13 analytique de méga-donnée propose des services pour différentes phases d'utilisation des données stockées dans la plateforme 4 centrale de données. On distingue les phases suivantes :
- phase de veille et tendances : cette phase permet d'identifier des tendances en analysant des données issues d'internet et des réseaux sociaux. Pour cette phase, le module 13 analytique de méga-donnée met à disposition des outils et des méthodes d'analyse de données (ex : Pig/Hive) à destination des fournisseurs 7 de services utilisateurs. Avantageusement, ces outils permettent aux fournisseurs 7 de services utilisateurs d'identifier des sujets relatifs aux données enregistrées dans la plateforme 4 centrale de données, et d'élaborer des indicateurs statistiques par rapport à ces sujets. A titre d'exemple, le module 13 analytique de méga-donnée conduit une analyse sur des données issues de réseaux sociaux ou de requêtes de moteurs de recherches, ces données étant fournies par les fournisseurs 9 de données à la plateforme 4 centrale de données. Le résultat de l'analyse réalisé par le module 13 analytique de méga-donnée est alors retourné au fournisseur 7 de services utilisateurs sous forme de mots clés, lui permettant d'identifier un sujet pertinent d'actualité en vue de réaliser des services utilisateurs ;
phase d'élaboration des services cette phase permet aux fournisseurs 7 de services utilisateurs d'élaborer des services. Pour ce faire, la plateforme 4 centrale de données fournit des données fiables (éventuellement abstraites), et le module 13 analytique de méga-donnée propose des outils permettant l'analyse de ces données. Selon divers modes de réalisations, le module 13 analytique de méga-donnée propose des outils statistiques basés sur
o des méthodes de corrélation de données, par exemples des corrélations de ■ Pearson pour des variables quantitatives continues ;
■ Spearman pour des données ordinales en tenant compte de leurs rangs ;
■ Kendall pour des données ordinales en tenant compte de leurs rangs ;
o des méthodes d'analyse de données, telles
■ des méthodes d'analyse en composantes principales (ACP) pour étudier et visualiser des corrélations entre plusieurs variables ;
■ des méthodes d'analyse de correspondances multiples (ACM) pour analyser la liaison entre des variables qualitatives ;
o des méthodes de regroupement de données couramment désignées sous l'anglicisme « clustering ».
Avantageusement, les données fiables à analysées/corrélées par le module 13 analytique de méga-donnée sont mises à disposition des différents fournisseurs 7 de services utilisateurs via un service de rapport (de type « reporting ») et se rapportent, à titres d'exemples, à des données des capteurs, des données environnementales, ou des données utilisateurs ;
phase de déploiement d'un service : cette phase permet à différents fournisseurs 7 de services utilisateurs de déployer leurs services dans le système 100 de gestion de données. Pour cette phase, le module 13 analytique de méga-donnée met à disposition des fournisseurs 7 de services utilisateurs des outils de gestion du cycle de vie du service et des outils de contrôle apte à garantir des pré-requis pour le déploiement d'un service dans le système 100 de gestion de données ;
phase de recommandation des services : cette phase met en œuvre des algorithmes de recommandation pour préconiser des services aux acteurs du système 100 de gestion de données. On recommande, par exemple, durant cette phase, des services élémentaires aux fournisseurs 7 de services utilisateurs, des services utilisateurs et/ou des scénarios d'utilisation de services utilisateurs à des particuliers. Avantageusement, les services de recommandation fournis par le système 100 de gestion de données sont basés sur des méthodes de filtrage collaboratif. Un filtrage collaboratif est réalisé, à titre d'exemple, par le module 13 analytique de méga-donnée en appliquant une méthode apte à comparer les utilisateurs entre eux (ex : type de service utilisés, type de données consommées, comportement utilisateur), ou des éléments notés au préalable (ex : services utilisateurs préalablement notés par leurs clients). Dans un mode de réalisation, le système 100 de gestion de données propose durant cette phase un service d'autoréglage d'équipements 1. Pour ce faire, le réglage d'un équipement 1 est mémorisé durant une période prédéfinie dans la plateforme 4 centrale de données, le réglage est ensuite appliqué à un ou plusieurs autres équipements 1 du même type. Dans un mode de réalisation, un service dit « du meilleur scénario » est proposé par le système 100 de gestion de données, afin de préconiser ou reproduire le meilleur scénario pour un service utilisateur, tel le réglage d'un appareil ou la gestion d'une ressource (ex : eau, gaz, électricité). Avantageusement, la recommandation du meilleur scénario, est basée sur le résultat d'une analyse conduite par le module 13 analytique de méga-donnée, cette analyse étant réalisée sur des informations remontées par des équipements 1 d'une catégorie d'utilisateurs similaires. Pour ce faire, on utilise des algorithmes de regroupement (« clustering ») de type « k-means » ou « canopy ». A titre d'exemple, la mise en place du service de meilleur scénario est réalisée via les étapes suivantes :
o sélection de l'équipement 1 ou de la ressource ;
o segmentation des utilisateurs ;
o application d'une méthode de type « canopy » pour calculer un ensemble de clusters d'utilisateurs ;
o application d'une méthode de type « k-means », afin d'identifier le meilleur scénario relatif à chaque cluster ; phase de notation des services (« scoring ») : cette phase, permet d'attribuer un score et identifier les services non- pertinents. Le système 100 de gestion de donnée, propose par exemple à des clients de noter les services utilisateurs qu'ils utilisent dans une boutique en ligne, ou aux fournisseurs 7 de services utilisateurs de noter les services élémentaires mis à leur disposition pour la réalisation des services utilisateurs. Avantageusement, une telle phase permet d'anticiper l'obsolescence des services. Pour ce faire la plateforme fait appel à des algorithmes d'apprentissage, basés sur des méthodes statistiques, par exemple des méthodes de régression logistique ou des méthodes d'arbre. Avantageusement, pour anticiper l'obsolescence des services, le module 13 analytique de mégadonnée est configuré pour associer à chaque service un seuil, et calculer un score relatif audit service. Si le score du service est inférieur au seuil, alors le service alors identifié par le module 13 analytique de méga-donnée comme obsolète, les fournisseurs 7 de services utilisateurs s'en voient alors notifiés.
Un des enjeux de la plateforme 4 centrale de données concerne l'accès (avec ségrégation) aux données et services utilisateurs. La plateforme 4 centrale de données joue en effet un rôle pivot dans la gestion et la transmission des données avec les boîtiers 5 de communication, le module 13 analytique de méga-donnée (« Big Data Analytics ») et les différents acteurs/consommateurs de données tels que les fournisseurs 7 de services utilisateurs. Ainsi, dans un mode de réalisation, on associe à la plateforme 4 centrale de données un équipement implémentant le protocole AAA
(acronyme anglais de « Authentication, Authorization, Accounting»), qui réalise des fonctions d'authentification, d'autorisation, et de traçabilité des données et services exposés par la plateforme 4 centrale de données. Avantageusement, ceci permet de se prémunir qu'un consommateur de données n'accède à des données ou services auxquels il n'a pas droit ou susceptibles de déroger aux règles de la vie privée. A titre d'exemples, après authentification, un consommateur est autorisé à appeler un service de la toile (couramment désigné sous l'anglicisme « service web ») de type REST (acronyme de « Representational State Transfer ») ou SOAP
(acronyme de « Simple Object Access Protocol»), ou encore appeler un service un certain nombre de fois par unité de temps (ex : mille fois par mois). L'appel de services REST ou SOAP permet notamment la lecture des données émanant des équipements 1 ou du module 13 méga-donnée, et permet l'envoi d'actions vers les équipements 1. En outre, la plateforme 4 centrale de données expose une ou plusieurs interfaces de programmation applicatives dites « API » (acronyme anglais de « Application Programming Interface »), et optionnellement une interface graphique utilisateur dite « GUI » (acronyme anglais de « Graphical User Interface »), permettant le provisionnement en données des consommateurs de données (clients, fournisseurs 7 de services utilisateurs), des applications consommatrices de données, et permettant de gérer les autorisations d'accès aux données, par exemple en fonction des rôles et de seuils préconfigurés.
Avantageusement, l'exposition d'une ou plusieurs interfaces de programmation applicative API par la plateforme 4 centrale de données est dédiée aux fournisseurs et permet :
aux fournisseurs 11 de services élémentaires de gérer un ensemble de services (« bundles ») crées par les différents fournisseurs et déployés sur la plateforme 4 centrale de données (ex : validation du déploiement, des versions, mutualisation, statistiques) ;
aux fournisseurs 7 de services utilisateurs, consommateurs de services élémentaires et de données, d'accéder de façon authentifiée, contrôlée et comptabilisée, au travers d'une couche frontale (ex : site internet, applications mobiles), aux informations produites par le module 13 analytique de méga-donnée (« Big Data Analytics »), après que ce dernier module ait traité (ex : analysé, corrélé, regroupé, formaté, abstrait) les données utilisateurs remontées par les différents boîtiers 5 de communication.
De même, on met à disposition sur chaque boîtier 5 de communication un ensemble d'interfaces de programmation applicative API dédiées cette fois aux utilisateurs finaux.
Avantageusement, l'exposition d'une ou plusieurs interfaces de programmation applicative API dédiée aux utilisateurs finaux, permet au travers d'une couche frontale (ex : site internet, applications mobiles) de proposer
aux utilisateurs finaux d'équipements 1, l'achat de services utilisateur en ligne, par exemple via l'intermédiaire d'une boutique en ligne proposée par une application ;
l'accès tout aussi bien aux informations globales (ex: données statistiques) portant sur le parc des boîtiers 5 de communication, qu'aux informations individuelles par service acheté (accès authentifié, contrôlé et comptabilisé) ;
au paramétrage de chaque service utilisateur (configuration personnalisée) ;
- l'accès à des services de notation et de recommandation pour chaque service acheté.
Avantageusement, l'intégration des données dans la plateforme 4 centrale de données est vue par les différentes entités comme une couche intermédiaire, assurant le transit des flux d'information entre :
les boîtiers 5 de communications, c'est-à-dire les informations provenant des capteurs de chaque équipement 1 ;
une base sémantique, tel le modèle sémantique de données précédemment décrit ;
- l'ensemble des services accessibles au consommateur final constituant un portail de services ;
les interfaces de programmation applicative API constituant un portail de gestion des services. Avantageusement, un tel portail facilite les interactions automatisées avec les équipements 1 ou les systèmes d'information des fournisseurs.
Notamment, dans un contexte multi-vendeurs, les différents dispositifs (équipements 1, capteurs, actionneurs) connectés à un boîtier 5 de communication peuvent provenir de différents vendeurs, qui n'ont pas préalablement connaissance les uns des autres, ces dispositifs étant à la fois supportés par le boîtier 5 de communication et la plateforme 4 centrale de données. La plateforme 4 centrale de données banalise alors les données provenant desdits dispositifs, en les exposant comme des services (ex : d'action, d'alerte, de données), permettant ainsi le développement de services relatifs à de multiples dispositifs et/ou de multiples vendeurs, ces services étant déployés par la suite au niveau de la plateforme 4 centrale de données ou des différents boîtiers 5 de communication.
Par ailleurs, l'intégration des données dans la plateforme 4 centrale de données permet par la suite d'entreprendre une liste d'actions, communiquée par la plateforme 4 centrale de données à au moins un boîtier 5 de communication, ledit boîtier étant relié à un nombre déterminé d'équipements 1. Avantageusement, ces actions sont déterminées en fonction du modèle sémantique, et sont possiblement liées :
à des données de métriques d'équipements 1 remontées par un boîtier 5 de communication ;
- un événement déclencheur d'action préconfiguré, à titre d'exemple, une action configurée pour être déclenchée à une date ou une heure prédéfinie ;
des notifications poussées par des interfaces de programmation applicative API exposées par la plateforme 4 centrale de données, poussées par exemple au travers d'un portail internet ou une application mobile, se rapportant à une demande d'action utilisateur ou fournisseur.
Ainsi, lors de la réception d'un événement tel qu'une notification ou une métrique, la plateforme 4 centrale de données via une couche d'intégration de données :
enregistre dans un historique l'événement reçu s'il s'agit d'un événement provenant d'un boîtier 5 de communication.
L'événement peut éventuellement contenir des paramètres associés à un équipement 1 déterminé ;
- à l'aide du module 13 analytique de méga-donnée classifie l'événement avec l'aide d'une la base sémantique, et établit une corrélation entre cet événement et un service associé ;
si le service existe, envoie des données associées à l'événement vers un mécanisme d'exécution (ex : associé à l'équipement 1), ledit mécanisme étant configuré pour générer une action associée au service ainsi qu'à l'événement ;
pousse via un mécanisme de type « push » l'action générée vers le boîtier 5 de communication correspondant.
Par ailleurs, un autre enjeu de la plateforme 4 centrale de données concerne son interfaçage avec les boîtiers 5 de communication. L'interface de la plateforme 4 centrale de données avec les boîtiers 5 de communication doit en effet gérer les flux de données :
dans le sens descendant : de la plateforme 4 centrale de données vers un boîtier 5 de communication, par exemple lors de l'envoi d'une commande vers un équipement 1 de type actionneur ; dans le sens montant : d'un boitier 5 de communication vers la plateforme 4 centrale de données, par exemple lors de la remontée d'une mesure issue d'un capteur d'un équipement 1. Couramment, un boitier 5 de communication est localisé dans un réseau local « interne » (ex : LAN) et se connecte à un réseau distant « externe » (ex : Internet) par l'intermédiaire d'un dispositif d'accès intégré, couramment désigné sous l'anglicisme IAD (« Integrated Access Device »). Le dispositif d'accès intégré IAD est fourni par un fournisseur d'accès réseau internet et permet d'échanger des flux de données de différentes natures via une unique connexion. Ainsi, chaque boitier 5 de communication précédemment décrit se connecte à la plateforme 4 centrale de données derrière un dispositif d'accès intégré IAD. Afin d'assurer une communication entre chaque boitier 5 de communication et la plateforme 4 centrale de données, le dispositif d'accès intégré IAD établit une connexion avec la plateforme 4 centrale de données. Pour établir cette connexion, le dispositif d'accès intégré IAD et la plateforme 4 centrale de données disposent d'adresses publiques, tandis que le boitier 5 de communication, situé derrière le dispositif d'accès intégré IAD, dispose d'une adresse privée, non adressable depuis la plateforme 4 centrale de données. Avantageusement, une telle architecture permet que tout boitier 5 de communication situé derrière le dispositif d'accès intégré IAD, puisse être à l'initiative d'une connexion de donnée (flux montant) vers toute plateforme internet au sens large tout en restant protégé des menaces externes.
Ainsi, dans le sens montant, tout boitier 5 de communication arrive par l'intermédiaire du dispositif d'accès intégré IAD à atteindre la plateforme 4 centrale de données, par exemple lors de la remontée de mesures ou d'événements retournés par des capteurs. Cependant, dans le sens descendant, par exemple pour la gestion d'actions à envoyer aux équipements 1, la plateforme 4 centrale de données ne dispose pas de moyens permettant d'atteindre le boitier 5 de communication, du fait de son adressage privé derrière le dispositif d'accès intégré IAD. Par ailleurs, le boitier 5 de communication peut être momentanément indisponible du point de vue du dispositif d'accès intégré IAD, par exemples en cas de déconnexion temporaire ou d'un simple débranchement électrique. Couramment, tout dispositif d'accès intégré IAD propose une fonction de règles de traduction d'adresse réseau, couramment désignées sous l'anglicisme NAT (« Network Address Translation»), permettant de faire correspondre à une adresse publique/un port de sortie du dispositif d'accès intégré IAD une adresse privée/un port d'entrée relatif à un boîtier 5 de communication. Une telle fonction n'est cependant pas réalisée par défaut et nécessite pour son activation la configuration de règles.
En outre, le développement de mécanismes permettant la prise en main à distance (ex : pour administration) et l'envoi d'action à des équipements 1, connectés à un boîtier 5 de communication, depuis la plateforme 4 centrale de données n'est pas implémenté dans l'architecture courante.
Selon divers modes de réalisations, la prise en main à distance et l'envoi d'action à un ou plusieurs équipements 1, connectés à un boîtier 5 de communication, depuis la plateforme 4 centrale de données, sont réalisés par l'implémentation de quatre mécanismes dont le fonctionnement général est ici brièvement rappelé :
mécanisme de communication de type « tunnel via proxy ». Couramment, pour ce mécanisme, un boîtier 5 de communication de type « Box » établit une connexion via un protocole de contrôle de transmissions, désigné par la suite sous l'appellation TCP, acronyme anglais de « Transmission Control Protocol ». Cette connexion est établie via la création d'un tunnel depuis le boîtier 5 de communication vers un serveur proxy associé à une plateforme distante. Ainsi, dans les modes de réalisations développés ultérieurement, un tunnel est établi entre un boîtier 5 de communication et un proxy disposé dans la plateforme 4 centrale de données. Le tunnel est alors maintenu ouvert par le boîtier 5 de communication, par exemple via l'envoi de paquets factices (« dummy packets »), ou ré-ouvert en cas de déconnexion. La création de ce tunnel s'effectue dans le sens montant, c'est-à-dire du boîtier 5 de communication vers la plateforme 4 centrale de données. L'établissement du tunnel permet, par la suite, la circulation d'informations montantes ou descendantes entre le boîtier 5 de communication et la plateforme 4 centrale de données. Avantageusement, grâce au proxy, la plateforme 4 centrale de données voit alors le boitier 5 de communication, comme si le dispositif d'accès intégré IAD était absent et implémente un mécanisme d'échange de données bidirectionnel. Un tel mécanisme demeure néanmoins fortement consommateur de ressources sur les serveurs proxy du fait de maintenir des connexions TCP ouvertes avec les différents boîtiers 5 de communication ;
mécanisme de communication basé sur le protocole de contrôle de « dispositif de passerelle internet », désigné par la suite sous l'appellation protocole IGD, acronyme anglais de « Internet
Gateway Device Protocol ». Le protocole IGD est décrit dans la norme UPnP (acronyme anglais de « Universal Plug and Play »). Couramment les « box » des opérateurs, c'est-à-dire les dispositifs d'accès intégré IAD dans ce document, proposent des fonctions de type routeur, « pare-feu » (« firewall » en anglais) et
« UPnP ». Certaines applications réseaux, telles des applications de type pair-à-pair P2P, proposent parfois lors de leur installation sur une machine informatique une option de configuration automatique via l'utilisation d'un mécanisme de type « UPnP ». Le principe de ce mécanisme consiste, via un contrôleur UPnP présent dans le dispositif d'accès intégré IAD, à configurer via le protocole IGD, une fonction « traduction d'adresse réseau » NAT (« Network Address Translation » en anglais) du pare-feu. Cette configuration permet notamment d'établir une correspondance (« mapping » en anglais) entre les ports publics/les adresses publiques de l'IAD, et les ports privés/adresses privés d'objets connectés derrière le pare-feu de l'IAD, et ce de manière transparente pour l'utilisateur. Par exemple, le protocole IGD établit via la fonction NAT, une correspondance entre une adresse privée et un port privé vers un boitier 5 de communication déployé dans un réseau local, et une adresse publique et un port public vers la plateforme 4 centrale de données déployée sur internet. Avantageusement, l'utilisation de ce mécanisme, permet alors à la plateforme 4 centrale de données de voir alors le boitier 5 de communication, comme si le dispositif d'accès intégré IAD était absent et propose un mécanisme d'échange de données bidirectionnel. Ce mécanisme présente néanmoins des risques de type sécuritaire : la reconfiguration du pare-feu est potentiellement ouverte à tout logiciel tiers connecté au réseau local de l'IAD, et une fois le « mapping » mis en place, le boîtier 5 de communication est potentiellement exposé à des risques d'attaques issues d'Internet. Par ailleurs, un tel mécanisme nécessite le support de l'UPnP par l'IAD et que cette fonction soit activée dans l'IAD ; mécanisme de communication utilisant le protocole « extensible de présence et de messagerie », désigné par la suite sous la dénomination protocole XMPP, acronyme anglais de « Extensible
Messaging and Présence Protocol ». Ce protocole de messagerie est basé sur les protocoles TCP, XML et remplace le protocole Jabber qui est un protocole de messagerie instantanée. Le protocole XMPP est décrit dans la spécification TR-069. Notamment, l'annexe K.2 de la version 1.4 de cette spécification
(Novembre 2013), décrit un mécanisme utilisant le protocole XMPP pour traiter via la fonction NAT, la problématique d'une requête de connexion « Connection Request » à destination d'un « Equipement des locaux d'abonné » couramment désigné sous la dénomination CPE, acronyme anglais de « Customer Premises
Equipaient ». Un CPE est, à titre d'exemple, le boîtier 5 de communication déployé dans un réseau local. A des fins de compréhension, cette annexe est ici résumée, des détails supplémentaires pouvant être trouvés dans celle-ci :
o un serveur d'auto-configuration ACS (acronyme anglais de
« Auto-Configuration Server ») établit une connexion avec un serveur XMPP. Le serveur d'auto-configuration ACS et le serveur XMPP sont, à titre d'exemple, installés dans un réseau internet ;
o ledit serveur d'auto-configuration ACS active l'utilisation du protocole XMPP au niveau d'un CPE par la configuration d'un objet XMPP « XMPP Connection object », en fournissant optionnellement un ensemble d'identifiants Jabber autorisés ;
o ledit CPE établit une connexion XMPP (par la voie montante) avec le serveur XMPP ; o lorsque le serveur d'auto-configuration ACS cherche à communiquer avec le CPE il envoie un message « XMPP Connection Request » audit serveur XMPP. Ce message est une « strophe » XMPP, désignée couramment sous la dénomination « XMPP IQ Stanza », et comprend une requête de connexion « Connection Request » indiquant pour origine un identifiant Jabber autorisé, se rapportant au serveur d'auto-configuration ACS, et indiquant pour destination un identifiant relatif au CPE.
o le serveur XMPP transmet alors le message « XMPP IQ
Stanza » au CPE approprié ;
o le CPE envoie en retour un message « Inform Request » à destination du serveur d'auto-configuration ACS.
Dans les modes de réalisations décrits par la suite, on associe le serveur d'auto-configuration ACS à la plateforme 4 centrale de données. Avantageusement, ceci permet alors de réaliser un mécanisme de type « réveil », permettant de diminuer la consommation de ressources par rapport aux mécanismes précédents: tout CPE, par exemple chaque boîtier 5 de communication, est prévenu (« réveil ») qu'il doit contacter la plateforme 4 centrale de données par un flux montant afin de récupérer en retour le flux de données descendant. Avantageusement, un tel mécanisme permet une amélioration de la sécurisation du boîtier 5 de communication ;
mécanisme de communication basé sur le protocole « traversée simple UDP à travers les NAT », désigné par la suite sous la dénomination protocole « STUN », acronyme anglais de « Simple Traversai of UDP through NATs ». Le protocole STUN permet à une application d'un CPE (ex : le boîtier 5 de communication) connecté à un IAD derrière un pare-feu, de découvrir la présence éventuelle d'une fonction (c'est-à-dire une passerelle) NAT de l'IAD, et obtenir la correspondance (« mapping ») de l'application avec l'adresse publique et le port UDP (anglicisme de « User Datagram Protocol ») du dispositif d'accès intégré IAD attribué par la passerelle NAT. L'utilisation de ce protocole nécessite l'assistance d'une tierce partie, à savoir un serveur STUN déployé dans un réseau public tel Internet. Le protocole STUN est décrit dans la spécification TR-111 (« Applying TR-069 to Remote Management of Home Networking Devices », Décembre 2005). Notamment, la partie «2.2 Procédures» de cette spécification décrit la procédure du protocole STUN pour qu'un CPE puisse recevoir une requête de connexion UDP depuis un serveur d'auto-configuration ACS distant. Le serveur d'auto- configuration ACS et le serveur STUN sont déployés du côté de l'adresse publique de la fonction NAT du dispositif d'accès intégré IAD. A des fins de compréhension, la partie 2 de la spécification TR-111 est ici résumée, des détails supplémentaires pouvant être trouvés dans celle-ci :
o le serveur d'auto-configuration ACS active l'utilisation du protocole STUN pour le CPE (si cette configuration n'est pas activée par défaut) et désigne un serveur STUN pour communiquer avec le CPE ;
o le CPE utilise alors le protocole STUN, pour découvrir si il se situe derrière une passerelle NAT avec une adresse privée allouée ;
o si oui, le CPE utilise la procédure définie par la norme STUN pour découvrir l'expiration de sa liaison de donnée derrière la passerelle NAT (« binding timeout ») ;
o afin d'effectuer l'étape de « mapping » le CPE envoie périodiquement des requêtes de liaisons STUN à destination du serveur STUN, dites « STUN Binding Requests ». Ceci permet de maintenir ouverte la liaison du
CPE via la passerelle NAT, cette liaison permettant au CPE d'écouter d'éventuelles requêtes de connexion UDP (« UDP Connection Requests ») ;
o lorsque le CPE détermine l'adresse IP publique et le port public utilisé pour la liaison de la passerelle NAT (utilisés pour l'écoute de messages « UDP Connection Requests »), le CPE transfère les informations de « mapping » déterminées au serveur d'auto-configuration ACS, par exemple via l'envoi d'un message « STUN Binding Request » ;
o le serveur d'auto-configuration ACS établit alors une connexion UDP avec le CPE, via l'envoi d'un message de requête de connexion UDP « UDP Connection Request » vers le port et l'adresse publique de la passerelle NAT, déterminés par le CPE ;
Dans les modes de réalisations décrits par la suite, on associe le serveur d'auto-configuration ACS et le serveur STUN à la plateforme 4 centrale de données. Avantageusement, ceci permet alors de réaliser un mécanisme de type « réveil », permettant de diminuer la consommation de ressources par rapport aux mécanismes précédents: tout CPE, par exemple chaque boîtier 5 de communication, est prévenu (« réveil ») qu'il doit contacter la plateforme 4 centrale de données par un flux montant afin de récupérer en retour le flux de données descendant. Avantageusement, un tel mécanisme est assez peu consommateur de ressources sur la plateforme 4 centrale de données. Cependant, l'envoi périodique de requêtes « STUN
Binding request » qui laisse ouvert la passerelle NAT, expose potentiellement le CPE à des attaques externes.
Le tableau ci-dessous, recense les avantages et inconvénients de chacun des mécanismes précédemment introduits :
Actuellement, les mécanismes introduits ci-dessus ne permettent pas la prise en main à distance (ex : pour administration) et l'envoi d'action à des équipements 1, connectés à un boîtier 5 de communication, depuis la plateforme 4 centrale de données.
Ainsi, après implémentation, chacun des mécanismes introduit ci- dessus sera apte à proposer la prise en main à distance, ainsi que l'envoi d'action à des équipements 1 connectés à un boîtier 5 de communication.
Selon divers modes de réalisations, lors du déploiement du système 100 de gestion de données, particulièrement des boîtiers 5 de communication, on choisit un ou plusieurs de ces quatre mécanismes en fonction des contraintes techniques et opérationnelles. Avantageusement, on sélectionne un unique mécanisme pour chaque boîtier 5 de communication en fonction, à titres d'exemples, du niveau de sécurisation du mécanisme, de sa complexité de mise en œuvre, de sa consommation de ressources, et/ou de son niveau de dépendance vis-à-vis du dispositif d'accès intégré IAD. Ce choix peut, à titre d'exemple, s'appuyer sur le tableau précédemment exposé.
Selon divers modes de réalisations, lors de l'implémentation de ces mécanismes, on déploie alors des serveurs d'auto-configuration ACS, permettant de gérer les boîtiers 5 de communication et l'initialisation des différents mécanismes.
En référence à la figure 10, on réalise par ailleurs, une couche d'abstraction via un gestionnaire 14 d'actions, intégré au niveau de la plateforme 4 centrale de données, offrant une interface unifiée, c'est-à-dire indépendante du type de mécanisme implémenté et donc du protocole employé par ce mécanisme. La couche d'abstraction, est à titre d'exemple, réalisée à l'aide d'une méthode permettant de formater les données réceptionnées/enregistrées par cette couche selon un format pivot.
Avantageusement, le gestionnaire 14 est configuré pour gérer
(ex : recevoir, transmettre, mettre en attente) les actions à destination des différents équipements 1. Sur la figure 10, chaque boîtier 5 de communication utilise un seul mécanisme de type « tunnel via proxy», « UPnP », « XMPP », ou « STUN », sélectionné lors du de leur déploiement et en accord avec les contraintes opérationnelles. En outre, pour chaque boîtier 5 de communication, le mécanisme sélectionné est mémorisé dans la plateforme 4 centrale de données, via une base 15 de données associée au gestionnaire 14 d'actions.
Avantageusement, lors de la réception d'une requête 16 d'action
(ex : une action poussé par un consommateur d'action) à destination d'un un équipement 1 connecté à un boîtier 5 de communication, le gestionnaire d'action 14 est configuré pour :
stocker l'action réceptionnée dans la base 15 de données, permettant ainsi
o une mise en attente temporaire, le temps que le boîtier 5 de communication reçoive la requête 16 d'action. La mise en attente est particulièrement avantageuse lorsque le boîtier 5 de communication est temporairement indisponible, par exemple lors d'une perte de connexion avec la plateforme 4 centrale de données ;
o de traiter la requête 16 d'action, par exemples : identifier l'équipement ciblé (identifiant, adresse), identifier le boîtier 5 de communication auquel il est connecté, identifier le mécanisme de communication à employer avec ledit boîtier 5 de communication pour transmettre la requête 16 d'action. Ces différentes identifications, sont par exemple réalisées par comparaison de l'identifiant de l'équipement avec un ensemble informations préenregistrées dans la base 15 de données ;
déclencher l'action sur l'équipement 1 en transmettant la requête 16 d'action à son boîtier 5 de communication, via un mécanisme de communication approprié, identifié dans la base 15 de données.
Par ailleurs, comme exposé précédemment, les mécanismes basés sur les protocoles XMPP et STUN sont de type « réveil » : le boîtier 5 de communication, est prévenu qu'il doit contacter la plateforme 4 centrale de données par un flux montant afin de récupérer en retour le flux de données descendant. Afin de supporter ce mécanisme, on réalise alors deux composants :
un agent de réveil (« Wakeup Agent ») réalisé sur le boîtier 5 de communication par la mise en place d'une couche intergicielle, couramment désignée sous l'anglicisme couche « middleware ». Avantageusement, la réalisation d'une telle couche permet à toute application du boîtier 5 de communication de souscrire à un service de réveil, lui permettant d'être réveillée par une application centrale ;
un serveur de réveil (« Wakeup Server ») via la réalisation d'une couche intergicielle sur la plateforme 4 centrale de données, permettant à tout service « consommateur » d'action (intégré ou non sur la plateforme 4 centrale de données) de réveiller une application du boîtier 5 de communication.
La figure 11, illustre le flux fonctionnel de données relatives à un consommateur 17 d'action, tel un fournisseur 7 de services utilisateurs : le consommateur 17 d'action pousse (flux 18) une requête 16 d'action vers le gestionnaire 14 d'actions de la plateforme 4 centrale de données. Cette requête 16 action comporte des informations sur le type d'action à effectuer et l'équipement 1 ciblé par cette action (ex : identifiant de l'équipement, description de l'action). Cette requête 16 d'action peut éventuellement être accompagnée d'une date limite de validité et d'une adresse, par exemple une adresse de type « localisateur uniforme de ressource » dite URL, pour notifier la réception et/ou le traitement de la requête 16 d'action par le boîtier 5 de communication ;
le gestionnaire 14 d'actions stocke (flux 19) en file d'attente dans la base 15 de données cette demande et acquitte (flux 20) la requête 16 d'action émise pour notifier au consommateur 17 d'action que celle-ci a bien été prise en compte ;
à partir de l'identification de l'équipement 1 ciblé, le gestionnaire 14 d'actions identifie le boîtier 5 de communication et son mécanisme d'accès correspondant, puis transmet la requête 16 d'action au boîtier 5 de communication. La transmission de la requête 16 d'action est fonction du type de mécanisme de communication, deux situations pouvant survenir
o si le mécanisme de communication est de type bidirectionnel (de type « tunnel via proxy » ou UPnP) :
■ le gestionnaire 14 d'actions contacte le boîtier 5 de communication via l'adresse publique fournie par le tunnel, ou par le dispositif d'accès intégré IAD dans le cas d'un mécanisme UPnP ;
■ si, selon le cas, le tunnel est ouvert ou la configuration UPnP effectuée, le gestionnaire 14 d'actions envoie (flux 21) une requête au boîtier 5 de communication pour lui fournir la requête 16 d'action. Sinon, le gestionnaire 14 d'actions attend le rétablissement du tunnel ou la reconfiguration UPnP pour alors envoyer la requête 16 d'action, en gérant éventuellement les dates limites de validité de la requête 16 d'action ;
o si le mécanisme est de type « réveil » (STUN ou XMPP) ■ le gestionnaire 14 d'actions contacte le serveur de réveil (« Wakeup Server », couche intergicielle) de la plateforme 4 centrale de données ;
■ ce serveur de réveil tente alors de réveiller boîtier 5 de communication par un protocole de bas niveau (en STUN ou XMPP selon le cas). Avantageusement, le contenu du message de réveil à destination du boîtier 5 de communication est limité, et peut se restreindre au type de réveil, par exemples : un réveil pour action sur l'équipement 1 ou un réveil pour une prise en main à distance de l'équipement 1. En outre, ce message se rapporte idéalement à un protocole en mode non-connecté, par exemple au « protocole de datagramme utilisateur » dit UDP. Le serveur de réveil gère par ailleurs des fonctionnalités de retransmission, car le boîtier 5 de communication n'est pas forcément accessible au moment de la dépose de l'action ;
■ une fois le boîtier 5 de communication accessible, le message de réveil parvient à l'agent de réveil (« Wakeup Agent ») de ce dernier, qui est alors en charge d'analyser le type de réveil et d'initier la connexion vers la plateforme 4 centrale de données et vers la bonne application pour récupérer les actions en attente ;
■ la plateforme 4 centrale de données via l'intermédiaire de son gestionnaire 14 d'actions fournit (flux 21) alors les requêtes d'actions en attentes (dont ladite requête 16 d'action) au boîtier 5 de communication, en gérant éventuellement la date limite de validité de chacune des requêtes ;
le boîtier 5 de communication exécute ou transmet alors aux équipements 1 auquel il est connecté, la requête 16 d'action et retourne (flux 22) un compte-rendu au gestionnaire 14 d'actions ;
le gestionnaire 14 d'actions notifie (flux 23) alors au consommateur 17 d'actions, la bonne exécution de l'action associée à sa demande initiale (si précisé lors de la demande initiale).
Avantageusement, le flux fonctionnel décrit ci-dessus est unifié, c'est-à-dire comporte les mêmes étapes, et ce quelque soit le mécanisme considéré. Le fonctionnement desdits mécanismes implémentés est maintenant décrit pour les cas de figures suivants : prise en main à distance d'un équipement 1, envoi d'action à un équipement 1, remontée de mesure du capteur d'un équipement 1 à destination de la plateforme 4 centrale de données.
La figure 12 illustre les principaux flux d'un mécanisme de communication, pour mettre en œuvre un tunnel entre le boîtier 5 de communication et un serveur 24 proxy. Sur cette figure, un boîtier 5 de communication est interfacé avec un dispositif 25 d'accès intégré IAD, via premier un port de communication, le boîtier 5 de communication étant uniquement adressable via une adresse privée située derrière le dispositif 25 d'accès intégré IAD. Le dispositif 25 d'accès intégré IAD dispose, par ailleurs, d'un deuxième port de communication, lui permettant d'être adressable depuis un réseau 26 externe, par exemple un réseau internet, via une adresse publique. Une plateforme 4 centrale de données comprend un gestionnaire 14 d'actions associé à une base 15 de données, ainsi qu'un serveur 27 d'auto-configuration ACS tel que décrit dans la spécification TR-069. Par ailleurs, pour des raisons d'extensibilité, le serveur 24 proxy est déployé dans une plateforme 28 mandataire, apte à échanger des données avec la plateforme 4 centrale de données. Avantageusement, chaque boîtier 5 de communication étant connecté en permanence avec un serveur 24 proxy, une telle architecture permet qu'un même serveur 24 proxy puisse gérer une pluralité de boîtier 5 de communications dans une plateforme 28 mandataire spécifique. Chaque plateforme 28 mandataire, utilise quant à elle un nombre déterminé de connexions TCP avec la plateforme 4 centrale de données, ce nombre étant indépendant du nombre de boîtier 5 de communication auquel il est connecté. Pour ce faire, on peut éventuellement utiliser des techniques de multiplexage. Avantageusement, une telle architecture permet aux serveurs 24 proxys d'être vus de la plateforme 4 centrale de données, comme des instances virtuelles des boîtiers 5 de communication, mais déployés sur un réseau public (ex : Internet). Une telle configuration est particulièrement avantageuse, car elle permet de s'affranchir des problématiques concernant l'adressage des boîtiers 5 de communication dans un réseau privé. Par ailleurs, en fonction du nombre de boîtiers 5 de communication, il est possible si nécessaire d'ajouter des plateformes 28 mandataires supplémentaires, participant ainsi à l'extensibilité de cette architecture. Le serveur 27 d'auto-configuration ACS disposé dans la plateforme 4 centrale de données, permet d'informer tout boîtier 5 de communication, lors de son initialisation, du serveur 24 proxy auquel il est rattaché. L'établissement du tunnel entre le boîtier 5 de communication et le serveur 24 proxy est maintenant décrit. L'établissement de ce tunnel survient à chaque initialisation du boîtier 5 de communication et comprend les étapes suivantes :
lors de son initialisation, le boîtier 5 ce communication se déclare à la plateforme 4 centrale de données via le serveur 27 d'auto- configuration ACS selon le protocole de gestion TR-069 ;
le boîtier 5 de communication est alors pris en compte par la plateforme 4 centrale de données, et celle-ci choisit un serveur 24 proxy en vue d'établir un tunnel avec le boîtier 5 de communication, et l'associe au boîtier 5 de communication. A titre d'exemple, le serveur 24 proxy est choisi par la plateforme 4 centrale de données, en fonction d'une proximité géographique et d'une disponibilité ;
cette association est transmise au serveur 27 d'auto- configuration ACS ;
- puis via un message « SetParameterValues », dont la structure est définie dans le protocole TR-069, le serveur 27 d'auto- configuration ACS active dans le boîtier 5 de communication, l'usage du tunnel en lui fournissant (flux 29 de la figure) l'adresse du serveur 24 proxy ;
- le boîtier 5 de communication établit (flux 30 de la figure) alors une connexion TCP avec le serveur 24 proxy, et envoie un message (non-standard) de liaison « BIND » pour lui indiquer son identification. Avantageusement, le message « BIND » comprend l'identifiant du boîtier 5 de communication, ainsi que les paramètres de la connexion TCP (ex : adresse et port distant, socket). La réception de ce message par le serveur 24 proxy, va donc permettre à ce dernier de gérer l'instance virtuelle du boîtier 5 de communication, en conservant pour cette instance l'identifiant du boîtier 5 de communication, ainsi que les paramètres de la connexion TCP ;
cette connexion TCP est ensuite maintenue ouverte en permanence par le boîtier 5 de communication.
La figure 13, illustre ensuite pour l'architecture précédente, les principaux flux de données permettant la prise en main à distance du boîtier 5 de communication et/ou des équipements 1 :
un acteur 31 externe, tel un fournisseur 7 de services utilisateurs, envoie (flux 32) une requête de prise en main, pour un boîtier 5 de communication ou un équipement 1, au serveur 27 d'auto- configuration ACS ;
le serveur 27 d'auto-configuration ACS envoie (flux 33) alors un message de requête de connexion « Connection Request », en accord avec la spécification TR-069, au serveur 24 proxy, en spécifiant dans ce message un identifiant relatif au destinataire final de la prise en main, par exemple relatif à un boîtier 5 de communication (ou un équipement 1) ciblé ;
grâce à l'identifiant du boîtier 5 de communication, le serveur 24 proxy sélectionne alors l'instance virtuelle du boîtier 5 de communication, et donc le tunnel 34 correspondant ;
le serveur 24 proxy transmet alors via le tunnel 34 correspondant la requête de connexion « Connection Request » au boîtier 5 de communication (flux 35) ;
- le boîtier 5 de communication traite alors la requête et émet (flux
36) en retour un message « Inform request » en accord avec la spécification TR-069, à destination du serveur 27 d'auto- configuration ACS, pour lui notifier le traitement de la requête ; la prise en main du boîtier 5 de communication (ou de l'équipement 1), suit ensuite le protocole TR-069, comme tout type de topologie réseau avec un CPE (ici le boîtier 5 de communication).
La figure 14, illustre pour la même architecture, les principaux flux de données permettant de transmettre une requête 16 d'action vers un actionneur associé à un équipement 1 : un acteur 37 externe tel un consommateur d'action envoie (flux 38) une requête 16 d'action vers le gestionnaire 14 d'actions de la plateforme 4 centrale de données ;
le gestionnaire 14 d'actions stocke alors ladite requête 16 d'action dans la base 15 de données, puis envoie la requête 16 d'action au serveur 24 proxy. Pour ce faire, le gestionnaire 14 d'actions ouvre une connexion TCP et est configuré pour envoyer (flux 39) deux requêtes au serveur 24 proxy :
o une première requête, qui est une requête (non-standard) de connexion « CONNECT », comprenant l'identification du boîtier 5 de communication ciblé. Avantageusement, le message « CONNECT » permet de spécifier au serveur proxy 24 que les requêtes suivantes, à savoir les demandes d'action, doivent s'adresser au boîtier 5 de communication ; o une deuxième requête correspondant à la requête 16 d'action, selon une syntaxe identique au cas d'un boîtier 5 de communication directement visible d'internet, par exemple une syntaxe http(s) ;
avantageusement, grâce au message de requête de connexion « CONNECT » (première requête), le serveur 24 proxy sélectionne l'instance virtuelle du boiter 5 de communication ciblé et le tunnel 34 correspondant. Avantageusement, ceci réalise une association temporaire au sein du serveur 24 proxy, entre la connexion du gestionnaire 14 d'actions à ce serveur et le tunnel 34 du boîtier 5 de communication ;
le serveur 24 proxy acquitte alors au gestionnaire 14 d'actions la bonne réception du message de requête de connexion « CONNECT ». Tant que le gestionnaire 14 d'actions ne reçoit pas cet acquittement, par exemple lorsque le tunnel 34 n'est pas établi, le gestionnaire 14 d'actions est configuré pour réémettre périodiquement ce message ou attendre le rétablissement du tunnel 34 ;
lorsque l'acquittement du message « CONNECT » est reçu par le gestionnaire 14 d'action, celui-ci transmet alors la deuxième requête, c'est à a dire la demande 16 d'action au serveur
24 proxy ; le serveur 24 proxy envoie (flux 40) alors par le tunnel 34 la requête 16 d'action telle que reçue au boîtier 5 de communication ciblé ;
le boîtier 5 de communication exécute alors l'action demandée ou sinon la transmet à l'équipement 1 concerné pour exécution, puis retourne (flux 41) ensuite un compte-rendu au serveur 24 proxy via le tunnel 34 ;
le serveur 24 proxy transmet (flux 42) alors le compte-rendu tel que reçu au gestionnaire 14 d'actions ;
- si demandé, le gestionnaire 14 d'actions notifie (flux 43) alors à l'acteur 37 externe de la bonne exécution de sa demande d'action initiale par le boîtier 5 de communication ou l'équipement 1 concerné.
La figure 15, illustre encore pour le même mécanisme, les principaux flux de données permettant de remonter une mesure d'un capteur associé à un équipement 1. Sur cette figure, la plateforme 4 centrale de données comprend, en outre, un gestionnaire 44 de mesures associé à une base 441 de donnée, permettant de gérer (stocker et/ou mettre à disposition) les données associées aux capteurs des différents équipements 1. Le processus de remontée de mesure vers la plateforme 4 centrale de données depuis le capteur d'un équipement 1 connecté à un boîtier 5 de communication est le suivant : le boîtier 5 de communication récupère la mesure issue dudit capteur et transmise par l'équipement 1 ;
- le boîtier 5 de communication envoie (flux 45) alors au serveur 24 proxy, par le tunnel 34 précédemment établi, la mesure par un message indiquant que la cible est le gestionnaire 44 de mesures, par exemple en utilisant un message du type « GET http(s) » ;
- le serveur 24 proxy initie alors une connexion TCP vers le gestionnaire 44 de mesures et transmet (flux 46) la mesure.
La figure 16 illustre les principaux flux mis en œuvre pour l'établissement d'une connexion entre la plateforme 4 centrale de données, et un boîtier 5 de communication, pour un mécanisme de communication implémentant le protocole UPnP. Tout comme précédemment : le boitier 5 de communication est interfacé avec un dispositif 25 d'accès intégré IAD, via premier un port de communication, le boitier 5 de communication étant uniquement adressable via une adresse privée ;
- le dispositif 25 d'accès intégré IAD dispose d'un deuxième port de communication, lui permettant d'être adressable depuis un réseau 26 externe, par exemple un réseau internet, via une adresse publique ;
la plateforme 4 centrale de données comprend un gestionnaire 14 d'actions associé à une base 15 de données (non-représentés sur cette figure), ainsi qu'un serveur 27 d'auto-configuration ACS tel que décrit dans la spécification TR-069.
Le processus suivant est exécuté à chaque initialisation du boitier 5 de communication:
- lors de son initialisation, le boitier 5 ce communication se déclare à la plateforme 4 centrale de données par le serveur 27 d'auto- configuration ACS via le protocole de gestion TR-069 ;
le boitier 5 de communication est alors pris en compte par la plateforme 4 centrale de données, et celle-ci active dans le boitier 5 de communication l'utilisation du protocole UPnP ;
le boitier 5 de communication émet alors des requêtes UPnP vers dispositif 25 d'accès intégré IAD, afin d'ouvrir un port de communication TCP public, permettant ainsi l'activation (flux 47) de la fonction de traduction d'adresse réseau NAT ;
- le boitier 5 de communication transmet (flux 48) alors au serveur
27 d'auto-configuration ACS, via le protocole TR-069, le port TCP public ouvert sur le dispositif 25 d'accès intégré IAD correspondant à la traduction d'adresse NAT vers le boitier 5 de communication.
La figure 17, illustre ensuite pour le mécanisme précédent, les principaux flux de données, permettant la prise en main à distance du boitier 5 de communication et/ou des équipements 1 :
tout d'abord un acteur 31 externe tel un fournisseur 7 de services utilisateurs envoie (flux 49) une requête de prise en main au serveur 27 d'auto-configuration ACS ;
le serveur 27 d'auto-configuration ACS envoie (flux 50) alors un message « Connection Request », en accord avec la spécification TR-069, vers le boitier 5 de communication. Pour ce faire, il envoie le message « Connection Request » à l'adresse publique du dispositif 25 d'accès intégré IAD, sur le port TCP public ouvert lors de l'établissement UPnP. Le dispositif 25 d'accès intégré IAD transmet alors le message au boitier 5 de communication en appliquant la fonction de traduction d'adresse réseau NAT ;
le boitier 5 de communication traite alors l'ordre et émet (flux 51) en retour un message « Inform request », en accord avec la norme TR-069, à destination du serveur 27 d'auto-configuration ACS pour lui notifier le traitement de la requête ;
la prise en main du boitier 5 de communication (ou de l'équipement 1), suit alors par la suite le protocole TR-069, comme tout type de topologie réseau avec un CPE (ici le boitier 5 de communication).
La figure 18, illustre pour le même mécanisme, les principaux flux de données permettant de transmettre une demande d'action vers un actionneur associé à un équipement 1 :
un acteur 37 externe tel un consommateur d'action poste (flux 52) une demande d'action vers le gestionnaire 14 d'actions de la plateforme 4 centrale de données ;
le gestionnaire 14 d'actions stocke alors ladite demande dans la base 15 de données, puis envoie (flux 53) la demande au boitier 5 de communication. Pour ce faire, il envoie la demande à l'adresse publique du dispositif 25 d'accès intégré IAD sur le port TCP public ouvert lors de l'établissement de l'UPnP. Le dispositif
25 d'accès intégré IAD transmet alors via l'utilisation de la fonction de traduction d'adresse réseau NAT, la demande au boitier 5 de communication ;
le boitier 5 de communication exécute alors l'action demandée, ou sinon la transmet à l'équipement 1 concerné pour exécution, puis retourne (flux 54) ensuite un compte-rendu au gestionnaire 14 d'actions. Tant que le gestionnaire 14 d'actions ne reçoit pas ce compte-rendu, par exemple lorsque la fonction NAT UPnP n'est pas établie, le gestionnaire 14 d'action est configuré pour réémettre périodiquement ce message ou attendre le rétablissement de la fonction de traduction d'adresse réseau NAT UPnP ; si demandé, le gestionnaire 14 d'actions notifie (flux 55) alors à l'acteur 37 externe de la bonne exécution de sa demande d'action initiale par le boîtier 5 de communication ou l'équipement 1 concerné.
La figure 19, illustre encore pour le même mécanisme, les principaux flux de données permettant de remonter une mesure d'un capteur associé à un équipement 1, vers le gestionnaire 44 de mesures de plateforme 4 centrale de données :
le boîtier 5 de communication récupère la mesure issue dudit capteur et transmise par l'équipement 1 ;
le boîtier 5 de communication initie (flux 56) ensuite une connexion, par exemple de type « http(s) » vers le gestionnaire 44 de mesures de la plateforme 4 centrale de données ;
le boîtier 5 de communication transmet finalement la mesure par un message indiquant que la cible est le gestionnaire 44 de mesures, par exemple en utilisant un message du type « GET http(s) ».
La figure 20 illustre ensuite les principaux flux mis en œuvre pour l'établissement d'une connexion entre la plateforme 4 centrale de données, et un boîtier 5 de communication, pour un mécanisme de communication implémentant le protocole XMPP. Tout comme précédemment :
le boîtier 5 de communication est interfacé avec un dispositif 25 d'accès intégré IAD, via premier un port de communication, le boîtier 5 de communication étant uniquement adressable via une adresse privée ;
le dispositif 25 d'accès intégré IAD dispose d'un deuxième port de communication, lui permettant d'être adressable depuis un réseau 26 externe, par exemple un réseau internet, via une adresse publique ;
la plateforme 4 centrale de données comprend un gestionnaire 14 d'actions associé à une base 15 de données, ainsi qu'un serveur 27 d'auto-configuration ACS tel que décrit dans la spécification TR-069.
Par ailleurs, pour des raisons d'extensibilité, un serveur 57 proxy http et un serveur 58 proxy XMPP, réalisés en accord avec la norme TR-069 sont déployés dans une plateforme 28 mandataire, la plateforme 28 mandataire étant apte à échanger des données avec la plateforme 4 centrale de données. Avantageusement, chaque boitier 5 de communication étant connecté en permanence avec un serveur 58 proxy XMPP. Avantageusement, la réalisation d'une telle architecture permet qu'un même serveur 58 proxy XMPP puisse gérer une pluralité de boitier 5 de communications dans une plateforme 28 mandataire spécifique. Comme exposé ultérieurement, les serveurs 57 proxy http seront quant à eux, utilisés lors de la remontée de mesures ou la récupération d'actions via des requêtes http. Chaque plateforme 28 mandataire utilise, quant à elle, un nombre déterminé de connexions avec la plateforme 4 centrale de données, ce nombre de connexions étant indépendant du nombre de boitier 5 de communication auquel elle est connectée. Pour ce faire, on peut éventuellement utiliser des techniques de multiplexage. Par ailleurs, en fonction du nombre de boîtiers 5 de communication, il est possible, si nécessaire, d'ajouter des plateformes 28 mandataires supplémentaires, ainsi que des serveurs 58 proxy XMPP et des serveurs 57 proxy http, participant ainsi à l'extensibilité de cette architecture. Le serveur 27 d'auto-configuration ACS disposé dans la plateforme 4 centrale de données, permet alors d'informer tout boitier 5 de communication lors de son initialisation du serveur 58 proxy XMPP auquel il est rattaché. De même, lors de la configuration du boitier 5 de communication, lors de son démarrage, le serveur 27 d'auto-configuration ACS est en charge d'informer le boitier 5 de communication de son serveur 57 proxy http mandataire.
L'établissement d'une connexion XMPP entre le boitier 5 de communication et le serveur 58 proxy XMPP est maintenant décrit. L'établissement de cette connexion survient à chaque initialisation du boitier 5 de communication et comprend les étapes suivantes :
lors de son initialisation, le boitier 5 de communication se déclare à la plateforme 4 centrale de données par le serveur 27 d'auto- configuration ACS via le protocole de gestion TR-069 ;
le boitier 5 de communication est alors pris en compte par la plateforme 4 centrale de données, et celle-ci choisit un serveur 58 proxy XMPP mandataire, par exemple en fonction d'une proximité géographique et d'une disponibilité serveur 58 proxy
XMPP, et l'associe au boitier 5 de communication ; cette association est ensuite transmise au serveur 27 d'auto- configuration ACS ;
le serveur 27 d'auto-configuration ACS, établit (flux 59) alors une connexion avec le serveur 58 proxy XMPP, qui sera ensuite maintenue ouverte par le serveur 27 d'auto-configuration ACS ; puis via le message « SetParameterValues » du protocole TR- 069, le serveur 27 d'auto-configuration ACS active dans le boîtier 5 de communication, l'usage du protocole XMPP en lui fournissant (flux 60) l'adresse du serveur, ainsi que les identifiants Jabber autorisés. Avantageusement, les identifiants
Jabber autorisés sont déclarés de manière identique dans le serveur 58 proxy XMPP et le serveur 27 d'auto-configuration ACS, et permettent à tout client XMPP, par exemple au boîtier 5 de communication, de s'identifier au cours des échanges XMPP ; - le boîtier 5 de communication établit (flux 61 de la figure) alors une connexion XMPP avec le serveur 58 proxy XMPP, cette connexion sera ensuite maintenue ouverte en permanence par le boîtier 5 de communication.
La figure 21, illustre pour l'architecture et le mécanisme précédent, les principaux flux de données permettant la prise en main à distance du boîtier 5 de communication et/ou des équipements 1 :
tout d'abord un acteur 31 externe tel un fournisseur 7 de services utilisateurs envoie (flux 62) une requête de prise en main au serveur 27 d'auto-configuration ACS ;
- le serveur 27 d'auto-configuration ACS envoie (flux 63) alors, en accord avec l'annexe K.2 de la spécification TR-069, un message de requête de connexion « Connection Request » en XMPP (« strophe » XMPP de type « XMPP IQ Stanza ») au serveur 58 proxy XMPP. Le serveur 27 d'auto-configuration ACS spécifie dans ce message, le destinataire final de la prise en main, par exemple un boîtier 5 de communication ciblé, ainsi que la source de ce message identifiée par un identifiant Jabber autorisé. La structure d'un tel message est notamment détaillé dans l'annexe K.2.3.1 delà spécification TR-069 ;
- le serveur 58 proxy XMPP transmet (flux 64) ensuite le message au boîtier 5 de communication via le protocole XMPP ; le boitier 5 de communication réceptionne alors le message, et génère un message de réponse en XMPP (« strophe » XMPP de type « XMPP IQ Stanza ») de type « résultat » en cas de bonne prise en compte du message précédent, ou de type « erreur » sinon. Les structures de ces messages de réponse, sont respectivement détaillé dans l'annexe K.2.3.2 et K.2.3.3 de la spécification TR-069 ;
le boitier 5 de communication traite alors la requête et émet (flux 65) en retour un message « Inform request », en accord avec la spécification TR-069, à destination du serveur 27 d'auto- configuration ACS pour lui notifier le traitement de la requête ; la prise en main du boitier 5 de communication (ou de l'équipement 1), suit alors par la suite le protocole TR-069, comme tout type de topologie réseau avec un CPE (ici le boitier 5 de communication).
La figure 22, illustre pour la même architecture et le même protocole, les principaux flux de données permettant de transmettre une requête 16 d'action vers un actionneur associé à un équipement 1 :
un acteur 37 externe tel un consommateur d'action envoie (flux 66) une requête 16 d'action vers le gestionnaire 14 d'actions de la plateforme 4 centrale de données;
le gestionnaire 14 d'actions stocke alors ladite requête 16 d'action dans la base 15 de données, puis envoie la requête 16 d'action via un message « Action Request » en XMPP (message de type « XMPP IQ Stanza ») au serveur 58 proxy XMPP.
Avantageusement, le message « Action Request » comprend pour origine un identifiant Jabber autorisé et comme destinataire le boitier 5 de communication. Selon divers modes de réalisations, le message « Action Request » n'étant pas décrit dans la spécification TR-069, on peut s'inspirer de la structure du message « Connection Request » décrit dans l'annexe K.2.3.1 de cette spécification, pour implémenter ce message. Un exemple de réalisation du message « Action Request » est donné ci-dessous. Dans cet exemple, on spécifie notamment une requête 16 d'action (champs « actionRequest ») de type « get », un identifiant Jabber se rapportant à l'émetteur de la requête 16 d'action (champs « from = ... »), ici le gestionnaire 14 d'actions, un identifiant Jabber pour un destinataire (champs « to=... ») de la requête 16 d'action, ici le boîtier 5 de communication, un identifiant de message (champs « id ») et des informations de connexion tel un nom d'utilisateur et un mot de passe (champs « username », « password »), ces informations étant constitutives d'un message de type « XMPP IQ Stanza » (champs « iq ») : iq from = "[PF-identity]" to = "L@D/R" id = "cr001" type = "get">
<actionRequest xmlns = "urn:bull-org:cwmp:xmppActReq-1 -0">
<username>username</username>
<password>password</password>
</actionRequest>
</iq > le serveur 58 proxy XMPP, réceptionne le message « Action Request », puis agit alors comme un serveur de réveil (« Wakeup server »), en transmettant (flux 68) ce message au boîtier 5 de communication via le protocole XMPP. Par ailleurs, le serveur 58 proxy XMPP est capable de stocker ledit message si le boîtier 5 de communication est déconnecté, puis le réémettre lors de la reconnexion du boîtier 5 de communication ;
le boîtier 5 de communication réceptionne alors le message, et génère un message de réponse en XMPP (strophe XMPP « XMPP IQ Stanza ») de type « résultat » en cas de bonne prise en compte du message précédent, ou de type « erreur » sinon. Les structures de ces messages de réponse, sont respectivement détaillé dans l'annexe K.2.3.2 et K.2.3.3 de la spécification TR- 069 ;
le boîtier 5 de communication initie ensuite une connexion http(s) afin de récupérer les demandes d'actions en attente. Cette connexion est établie (flux 69) avec le serveur 57 proxy http de la plateforme 28 mandataire, qui lui-même va interroger (flux 70) le gestionnaire 14 d'actions en vue de récupérer les demandes d'actions, par exemple via un message du type « GET http ». Avantageusement, l'utilisation du serveur 57 proxy http dans la plateforme 28 mandataire, permet alors d'optimiser les ressources de la plateforme 4 centrale de données, en lui évitant de multiples connexions http initiées directement depuis les différents boîtiers 5 de communications ; le gestionnaire 14 d'action fournit alors en réponse les demandes d'action au boîtier 5 de communication, via la connexion établie avec le serveur 58 proxy XMPP. Le gestionnaire 14 d'action gère, par ailleurs, la péremption des demandes d'actions selon deux modes :
o selon un mode asynchrone si le boîtier 5 de communication n'est pas disponible, via le message XMPP de réveil transmis par le serveur 57 proxy http ;
o selon un mode synchrone, par une transmission en « temps-réel » des actions au boîtier 5 de communication si celui est disponible (sous réserve de la validité temporelle de l'action, fonction par exemple d'un seuil temporel préconfiguré) ;
le boîtier 5 de communication exécute alors l'action demandée ou sinon la transmet à l'équipement 1 concerné pour exécution, puis retourne ensuite, par l'intermédiaire du serveur 57 proxy http, un compte-rendu au gestionnaire 14 d'action ;
si demandé, le gestionnaire 14 d'actions notifie (flux 71) alors à l'acteur 37 externe de la bonne exécution de sa demande d'action initiale par le boîtier 5 de communication ou l'équipement 1 concerné.
La figure 23, illustre encore pour la même architecture, les principaux flux de données permettant de remonter une mesure d'un capteur associé à un équipement 1. Sur cette figure, la plateforme 4 centrale de données comprend, un gestionnaire 44 de mesures associé à une base 441 de donnée, permettant de gérer (stocker et/ou mettre à disposition) les données associées aux capteurs des différents équipements 1. Le processus de remontée de mesure vers la plateforme 4 centrale de données depuis le capteur d'un équipement 1 connecté à un boîtier 5 de communication est le suivant :
le boîtier 5 de communication récupère la mesure issue dudit capteur et transmise par l'équipement 1 ;
le boîtier 5 de communication initie (flux 72) une connexion http(s) vers le serveur 57 proxy http de la plateforme 28 mandataire : le serveur 57 proxy http initie alors une connexion http(s) vers le gestionnaire 44 de mesures de la plateforme 4 centrale de données ;
le boîtier 5 de communication envoie (flux 73) alors au serveur 57 proxys http, via la connexion http(s) établie, la mesure par un message indiquant que la cible est le gestionnaire 44 de mesures, par exemple en utilisant un message du type « GET http
(S ».
La figure 24 illustre les principaux flux mis en œuvre pour l'établissement d'un tunnel, pour un mécanisme de communication entre le boîtier 5 de communication et la plateforme 4 centrale de données, pour un mécanisme de communication implémentant le protocole STUN. Tout comme précédemment :
le boîtier 5 de communication est interfacé avec un dispositif 25 d'accès intégré IAD, via premier un port de communication, le boîtier 5 de communication étant uniquement adressable via une adresse privée. Cette adresse privée est à titre d'exemple adressable via un passerelle/fonction de traduction d'adresse réseau NAT constitutive du dispositif 25 d'accès intégré IAD ; - le dispositif 25 d'accès intégré IAD dispose d'un deuxième port de communication, lui permettant d'être adressable depuis un réseau 26 externe, par exemple un réseau internet, via une adresse publique ;
la plateforme 4 centrale de données comprend un gestionnaire 14 d'actions associé à une base 15 de données (non-représentés sur cette figure), ainsi qu'un serveur 27 d'auto-configuration ACS tel que décrit dans la spécification TR-069.
Par ailleurs, la plateforme 4 centrale de données comprend un serveur 74 STUN, en accord avec la spécification TR-111. Comme exposé plus loin, un tel serveur permettra d'établir un « tunnel » de réveil entre la plateforme 4 centrale de données et le boîtier 5 de communication.
L'établissement de la connexion entre le boîtier 5 de communication et la plateforme 4 centrale de données est maintenant décrit. L'établissement de cette connexion survient à chaque initialisation du boîtier 5 de communication et comprend les étapes suivantes : lors de son initialisation, le boîtier 5 de communication se déclare à la plateforme 4 centrale de données par le serveur 27 d'auto- configuration ACS via le protocole de gestion TR-069 ;
le boîtier 5 de communication est alors pris en compte par la plateforme 4 centrale de données, et celle-ci active dans le boîtier 5 de communication l'utilisation du protocole STUN ;
le boîtier 5 de communication émet (flux 75) alors des requêtes de liaisons STUN « STUN Binding Requests » à destination du serveur 74 STUN de la plateforme 4 centrale de données, en accord avec la partie 2.2 de la spécification TR-111. Les réponses du serveur 74 STUN à ces requêtes, permettent alors au boîtier 5 de communication de découvrir l'adresse publique du dispositif 25 d'accès intégré IAD. Le boîtier 5 de communication transmet (flux 76) alors l'adresse publique identifiée du dispositif 25 d'accès intégré IAD, au serveur 27 d'auto-configuration ACS via le protocole de gestion TR-069. Avantageusement, l'identification de l'adresse publique du dispositif 25 d'accès intégré IAD, permet au boîtier 5 de communication de découvrir la présence d'une passerelle/fonction NAT dans le dispositif 25 d'accès intégré IAD, et d'établir au travers cette passerelle/fonction une connexion UDP avec le serveur 74 STUN afin de maintenir cette connexion ouverte, le boîtier 5 de communication, envoie (flux 77) alors par la suite périodiquement un message de requête de liaison STUN de type « Binding
Request ». Avantageusement, cette période est configurée de manière à ce que le dispositif 25 d'accès intégré IAD ne désactive pas la fonction NAT suite à une période d'inactivité, et soit à la fois suffisamment longue afin d'éviter la saturation en ressources du serveur 74 STUN. Ainsi, dans un mode de réalisation, le boîtier 5 de communication effectue un mécanisme d'apprentissage, en émettant initialement des messages de requête de connexion « Binding Request » avec une période faible, puis en augmentant progressivement la période d'émission de ces messages. On détermine ainsi une période limite pour laquelle le boîtier ne reçoit plus de réponse de connexion « Binding Response » de la part du serveur 74 STUN. A partir de cet état, la période identifiée comme utilisable par le boîtier 5 de communication est la période précédent cette période limite.
La figure 25, illustre pour le mécanisme précédent, les principaux flux de données permettant la prise en main à distance du boîtier 5 de communication et/ou des équipements 1 :
tout d'abord un acteur 31 externe tel un fournisseur 7 de services utilisateurs envoie (flux 78) une requête de prise en main au serveur 27 d'auto-configuration ACS;
le serveur 27 d'auto-configuration ACS contacte (flux 79) le serveur 74 STUN, en accord avec la spécification TR-111, et lui demande d'envoyer un message de requête de connexion « Connection Request » selon le protocole UDP, à destination du boîtier 5 de communication. La réalisation d'un tel message est décrite dans la partie 2.2.2.3 de cette spécification. Le serveur 74 STUN est alors le seul élément autorisé par le dispositif 25 d'accès intégré IAD à utiliser la fonction de traduction d'adresse réseau NAT vers le boîtier 5 de communication. En effet, suite à l'établissement de la connexion avec le serveur 74 STUN, le dispositif 25 d'accès intégré IAD ne connaît que l'adresse relative au serveur 74 STUN ainsi que le port UDP utilisé avec ce serveur ;
le serveur 74 STUN envoie (flux 80) ensuite au boîtier 5 de communication un message UDP de requête de connexion « Connection Request », vers le port UDP public du dispositif 25 d'accès intégré IAD (utilisé par la fonction/passerelle de traduction d'adresse réseau NAT pour établir la connexion avec le boîtier 5 de communication). Le dispositif 25 d'accès intégré IAD transmet alors ce message au boîtier 5 de communication via la fonction/passerelle de traduction d'adresse réseau NAT ;
- le boîtier 5 de communication traite alors l'ordre et émet en retour un message « Inform request », en accord avec la norme TR-069, à destination du serveur 27 d'auto-configuration ACS (flux 81) pour lui notifier le traitement de la requête ;
la prise en main du boîtier 5 de communication (ou de l'équipement 1), suit alors par la suite le protocole TR-069, comme tout type de topologie réseau avec un CPE (ici le boîtier 5 de communication). La figure 26, illustre pour le même mécanisme, les principaux flux de données permettant de transmettre une requête 16 d'action vers un actionneur associé à un équipement 1 :
un acteur 37 externe tel un consommateur d'action envoie (flux 82) une requête 16 d'action vers le gestionnaire 14 d'actions de la plateforme 4 centrale de données ;
le gestionnaire 14 d'actions stocke alors ladite requête 16 d'action dans la base 15 de données, puis contacte alors le serveur 74 STUN (flux 83), en accord avec la spécification TR- 111 , et lui demande d'envoyer un message « Action Request » en
UDP, à destination du boîtier 5 de communication. Selon divers modes de réalisations, le message « Action Request » n'étant pas décrit dans la spécification TR-111, on peut s'inspirer de la structure du message « Connection Request » décrit dans la partie 2.2.2.3 de cette spécification, pour implémenter ce message. Un exemple de réalisation du message « Action Request » est donné ci-dessous. Celui-ci spécifie un chemin non- vide associé à l'identifiant uniforme de ressource dit « URI » de ce message. Pour construire ce message, on ajoute le chemin surligné «ActionRequest », entre un champ de type « hostname », ici « 10.1.1.1:8080 », et les arguments de ce message spécifiés après le « ? » :
| http://10.1.1.1 :8080/ActionRequest?ts = 1120673700&id=1234 n = CPE57689&cn=XTG RWIPC6D3IPXS3&sig = 3545F7B5820D76A3DF45A3A509DA8D8C38F13512
Le serveur 74 STUN est alors le seul élément autorisé par le dispositif 25 d'accès intégré IAD à utiliser la fonction NAT vers le boîtier 5 de communication. En effet, suite à l'établissement de la connexion avec le serveur 74 STUN, le dispositif 25 d'accès intégré IAD ne connaît que l'adresse relative au serveur 74 STUN ainsi que le port UDP utilisé avec ce serveur ;
le serveur 74 STUN envoie (flux 84) ensuite au boîtier 5 de communication un message UDP de requête d'action « Action Request », vers le port UDP public du dispositif 25 d'accès intégré IAD (utilisé par la fonction/passerelle de traduction d'adresse réseau NAT pour établir la connexion avec le boîtier 5 de communication). Le dispositif 25 d'accès intégré IAD transmet alors ce message au boitier 5 de communication en appliquant la fonction de traduction d'adresse réseau NAT ;
le boitier 5 de communication réceptionne le message et émet un message de prise en compte (réponse d'action) « Action Response », en accord avec la norme TR-111, à destination du serveur 74 STUN. Avantageusement, le message « Action Response », est un message UDP réalisé de manière similaire au message « Action Request », via l'utilisation d'un chemin non vide. Un exemple de réalisation pour ce message est donné ci- dessous :
http://10.1.1.1:8080/ActionRequest?ts = 1120673700&id=1234&un = CPE57689&cn=XTG RWIPC6D3IPXS3&sig = 3545F7B5820D76A3DF45A3A509DA8D8C38F13512
Tant que le serveur 74 STUN ne reçoit pas cette réponse d'acquittement « Action Response », par exemple lorsque la fonction NAT UDP n'est pas établi, le serveur 74 STUN est configuré pour réémettre périodiquement le message UDP « Action Request » ou attendre le rétablissement de la fonction de traduction d'adresse réseau NAT ;
le boitier 5 de communication initie ensuite (par voie montante) une connexion http(s) vers le gestionnaire 14 d'actions (flux 85) afin de récupérer les demandes d'actions en attente ;
le gestionnaire 14 d'action fournit alors en réponse les demandes d'action au boitier 5 de communication, tout en gérant la péremption des demandes d'actions selon deux modes :
o selon un mode asynchrone si le boitier 5 de communication n'est pas disponible, via un message UDP de réveil ;
o selon un mode synchrone, par une transmission en « temps-réel » des actions au boitier 5 de communication si celui est disponible (sous réserve de la validité temporelle de l'action, fonction par exemple seuil temporel préconfiguré) ;
le boitier 5 de communication exécute alors l'action demandée ou sinon la transmet à l'équipement 1 concerné pour exécution, puis retourne ensuite un compte-rendu au gestionnaire 14 d'action; si demandé, le gestionnaire 14 d'actions notifie (flux 86) alors à l'acteur 37 externe de la bonne exécution de sa requête 16 d'action initiale par le boîtier 5 de communication ou l'équipement 1 concerné.
Par ailleurs, pour cette architecture, les principaux flux de données permettant de remonter une mesure d'un capteur associé à un équipement 1, vers le gestionnaire 44 de mesures de plateforme 4 centrale de données, sont les mêmes que ceux de la figure 19, décrivant ces flux pour un mécanisme implémentant l'UPnP :
le boîtier 5 de communication récupère la mesure issue dudit capteur et transmise par l'équipement 1 ;
- le boîtier 5 de communication initie (flux 56) ensuite une connexion, par exemple de type « http(s) » vers le gestionnaire 44 de mesures de la plateforme 4 centrale de données ;
le boîtier 5 de communication transmet finalement la mesure par un message indiquant que la cible est le gestionnaire 44 de mesures, par exemple en utilisant un message du type « GET http(s) ».
Les enjeux techniques et modes de réalisations concernant le boîtier 5 de communication sont maintenant décrits. Comme exposé précédemment, un boîtier 5 de communication (de type « box ») est déployé dans un environnement ou lieu physique déterminé, comprenant un ou plusieurs équipements 1, chacun de ces équipements 1 proposant des services utilisateurs. Avantageusement, chaque boîtier 5 de communication sert :
de passerelle protocolaire entre les réseaux (filaires ou sans fils) des équipements 1 locaux, capteurs, actionneurs et la plateforme
4 centrale de données, cette dernière accessible via un réseau 26 externe depuis un dispositif 25 d'accès intégré IAD ;
à l'exécution de services, lorsqu'il est préférable de les exécuter localement plutôt qu'au niveau de la plateforme 4 centrale de données, par exemple pour des raisons d'autonomie des équipements 1.
Le boîtier 5 de communication est par ailleurs partagé entre plusieurs acteurs, par exemples des vendeurs d'équipements 1 ou des fournisseurs 7 de services utilisateurs. Par conséquent, le boîtier 5 de communication héberge des composants logiciels communs et spécifiques (notamment les services utilisateurs) auxdits acteurs, permettant de gérer la communication avec les différents équipements 1 ou effectuer un traitement de données local sur les données issues de ces équipements 1. On parle couramment, dans ce contexte, d'architecture « multi-tenants ». Le boîtier 5 de communication implémente ainsi une plateforme i ntergi ciel le de services. Sur cette plateforme, les fonctions propres à chaque acteur, à titre d'exemple le protocole de communication employé avec un équipement 1 ou le traitement spécifique de données associées à un équipement 1, sont déployées par les acteurs sous la forme de composants logiciels orientés services. Une défaillance ou un détournement d'un composant logiciel associé à un acteur, ne doit donc pas impacter et dégrader les comportements des composants logiciels relatifs aux autres acteurs hébergés sur une même plateforme. A titre d'exemple, un débordement mémoire résultant d'une anomalie de codage d'un service ne doit pas se propager dans la plateforme, sous risque de provoquer l'interruption (« crash ») des autres services. En outre, en l'absence de standard, les équipements 1 connectés au boîtier 5 de communication sont hétérogènes et basés sur des protocoles de communication différents. Ainsi, couramment un composant logiciel communicant initialement avec équipements 1 selon un protocole, devra évoluer lorsque l'équipement 1 change car le protocole associé se voit aussi évoluer. En outre, le changement d'un équipement 1 peut aussi engendrer une modification de la méthode d'accès du boîtier 5 de communication aux données de l'équipement 1. A titre d'exemple, le boîtier 5 de communication accède initialement aux données d'un équipement 1 via une méthode de type « pull » : l'équipement 1 expose une interface de programmation applicative API et le boîtier 5 de communication prend l'initiative de récupérer les mesures d'un capteur associé à cet équipement 1. Un changement de cet équipement 1 entraine alors l'utilisation d'une méthode d'accès de type « push » : les données sont poussées à l'initiative de l'équipement 1 vers le boîtier 5 de communication. Par conséquent, le composant logiciel permettant de communiquer avec cet équipement doit lui aussi évoluer.
Ainsi, pour parer à ses inconvénients on réalise dans le boîtier 5 de communication, une plateforme logicielle de services fondée sur le langage Java et en accord avec la norme OSGi (acronyme anglais de « Open Services Gateway initiative »), multi-tenant et intégrant une interface de programmation applicative API unifiée d'accès aux équipements 1 ou services connectés. Avantageusement, une telle plateforme logicielle permet d'assurer :
une fiabilité et une isolation forte entre les composants logiciels d'utilisateurs différents ;
- une indépendance des services applicatifs vis-à-vis des protocoles de communication avec les équipements 1 ou les services de données ;
une indépendance des services applicatifs vis-à-vis des méthodes d'accès (ex : « pull », « push ») aux équipements 1 ou aux services de données.
Une telle plateforme logicielle est réalisée par l'agrégation :
d'une couche d'accès aux équipements 1 connectés, dont la réalisation est décrite ultérieurement ;
d'une plateforme java multi-tenants assurant l'isolation entre les services hébergés par la plateforme. On peut pour ce type de plateforme, s'appuyer sur des plateformes existantes de l'état de l'art. A titre d'exemple, on réalise une plateforme Java/OSGi basée sur un modèle Haas (acronyme anglais de « Hardware as a Service ») via des composants applicatifs disposés dans un conteneur partagé dit « Kernel » et dans des conteneurs séparés et étanches dit « Features ». Avantageusement, une telle plateforme est réalisée de sorte à ce que l'espace mémoire alloué à chaque conteneur ne soit accessible, que si ce dernier est configuré pour en autoriser l'accès. L'accès d'un utilisateur autorisé à un conteneur, par exemple lors de l'invocation d'une méthode, s'effectue alors au travers d'une interface applicative de programmation API, qui limite l'accès de l'utilisateur au strict nécessaire. Il est ainsi impossible d'utiliser des techniques de débordement de pile pour contourner le contrôle et accéder illicitement à la zone mémoire du conteneur depuis l'extérieur.
Avantageusement, la mémoire du conteneur ne peut être ni accédée ni corrompue depuis l'extérieur du conteneur, le conteneur partagé « Kernel » et les conteneurs étanches « Features » s'exécutant au sein d'une machine virtuelle Java JVM, et celle-ci n'autorisant en son sein que l'exécution de conteneurs isolés ou ne communicant qu'au travers de méthodes explicitement exposées et contrôlées. Le code de programmation des composants du « Kernel » est alors considéré comme fiable (ne comportant pas d'anomalies), tandis que les services utilisateurs sont regroupés dans des « Features » distinctes propres à chaque fournisseur. Avantageusement, une telle structure garantit alors une isolation forte entre les services utilisateurs, prévenant que toute défaillance d'un service ait un impact sur les autres, assure une gestion des ressources matérielles (ex : occupation mémoire, ressources de calcul) par « Feature » et limite la propagation d'erreur de tout composant logiciel.
La figure 27 illustre le concept de fonctionnement d'une plateforme 87 logicielle avec les caractéristiques précédemment décrites. La plateforme 87 logicielle est une plateforme partagée entre plusieurs utilisateurs, deux dans cet exemple, et héberge l'ensemble des services des utilisateurs se rapportant chacun un équipement. Dans cet exemple, un premier service 88 se rapporte à un premier équipement 89, et un deuxième service 90 se rapporte à un deuxième équipement 91. Le premier équipement 89 et le deuxième équipement 91 sont connectés de manière externe à la plateforme 87 logicielle du boîtier 5 de communication, et utilisent pour leurs échanges respectivement un premier et un deuxième protocole. Par ailleurs, dans un autre mode de réalisation, tout service distant/éloigné, accessible via une interface de programmation applicative API, peut se substituer à un équipement 89, 91. On entend, ici, par service distant/éloigné tout service permettant de généraliser une source de donnée tel un équipement 89,91 ou encore tout service déployé dans le « Nuage » de type « logiciel en tant que service » dit SaaS, acronyme anglais de « Software as a Service ». Par exemple, l'élément 91 peut être un service distant en lieu et place du deuxième équipement, ce service faisant appel au deuxième protocole. Avantageusement, les composants logiciels spécifiques, comprenant les services 88, 90, propres à chaque utilisateur sont respectivement isolés dans des conteneurs 92, 93 étanches, couramment désignés sous l'appellation « sandbox » ou « Feature ». Une interface 94 de programmation applicative API unifiée permet alors l'accès aux équipements 89, 91 ou à des services distants depuis les services 88, 90 applicatifs, ou plus généralement à tout élément logiciel ou matériel extérieur, dit « eThing », connecté à la plateforme 87 logicielle du boîtier 5 de communication. Ainsi, pour assurer à la fois le support d'éléments (ex : équipements 89, 91 ou services distants) gérés par un utilisateur, et le support des protocoles de communication associés à ces éléments, on déploie entre l'interface 94 de programmation applicative API unifiée et tout élément « eThing », un adaptateur protocolaire relatif au protocole de l'élément, ainsi qu'un adaptateur d'élément, dit adaptateur «eThing », ces adaptateurs se présentant sous forme de composants logiciels, tels des services OSGi.
Ainsi, dans l'exemple illustré, un premier et un deuxième adaptateur 95, 96 protocolaire est respectivement associé au premier et au deuxième équipement 89,91, chacun de ces adaptateurs étant respectivement interfacé avec un premier et un deuxième adaptateur 97,98 « eThing », ces adaptateurs implémentant l'interface 94 de programmation applicative API unifiée. Avantageusement, les adaptateurs spécifiques à un même équipement sont isolés dans un même conteneur étanche (« Feature »). Par exemple, les adaptateurs 95, 96 protocolaire et les adaptateurs 97, 98 d'élément « eThing » sont respectivement déployés dans les conteneurs 92, 93. Cependant, un même adaptateur de protocole peut éventuellement être partagé entre plusieurs utilisateurs. Avantageusement, l'interface 94 de programmation applicative API unifiée, les adaptateurs 95, 96 protocolaires et les adaptateurs 97, 98 d'éléments « eThing » constituent ainsi une structure 99 (« framework ») d'accès unifié, c'est- à-dire une couche d'accès aux équipements 1, 89, 91 connectés.
La figure 28 illustre un exemple de répartition des éléments de la plateforme 87 logicielle précédemment décrite, combinée avec une approche Java/OSGi basée sur un modèle Haas (acronyme anglais de « Hardware as a Service ») réalisé par des composants applicatifs disposés dans un conteneur 100 partagé dit « Kernel », et dans des conteneurs 101, 102 séparés et étanches dit « Features ». Dans cet exemple :
le conteneur 100 partagé « Kernel », réputé fiable, embarque
o des interfaces 103 Java constitutives de l'interface 94 de programmation applicative API unifiée, détaillées ultérieurement, et des classes de données correspondant aux objets échangés au niveau de l'interface 94 programmation applicative, par exemple des classes de données structurées (ex : binaires, booléennes) remontées par les équipements 1, 89, 91 ;
o des adaptateurs 104 protocolaires partagés par tous les utilisateurs, c'est-à-dire partagés par différents services, par exemple des adaptateurs Zigbee, ou de ports série ; o des services 105 communs utilisateurs, par exemple un moteur de règles, et un service de publication des données vers une interface de type REST (acronyme de « Representational State Transfer ») ;
- chaque conteneur 101, 102 séparé « Features » (composants logiciels), spécifique à un utilisateur, embarque
o des services 106, 107 spécifiques à un utilisateur, par exemple des services de prétraitement sur les données d'un équipement 1, 89, 91 ;
o des adaptateurs 108, 109 protocolaires spécifiques à leur équipement ;
o des adaptateurs 110, 111 d'éléments « eThing » implémentant l'interface 94 de programmation applicative API unifiée.
La figure 29 illustre la réalisation de la structure 99 (« framework ») d'accès unifié, comprenant l'interface 94 de programmation applicative API unifiée. Cette dernière est interfacée avec un adaptateur d'éléments « eThing via une interface désignée par la suite comme interface 112 d'élément « eThing », cette interface étant un service OSGi. Dans cet exemple, l'adaptateur d'éléments « eThing » est l'adaptateur 97 d'éléments « eThing » du premier équipement 89 (non- représenté). L'adaptateur 97 d'éléments « eThing » est lui-même interfacé avec l'adaptateur 95 protocolaire. L'interface de programmation applicative API 94 unifiée, l'adaptateur d'éléments « eThing » 97 et l'adaptateur protocolaire 95 sont donc constitutifs de la structure 99 d'accès unifié. Dans cette structure, chaque équipement 89, ou plus généralement tout élément connecté « eThing », est représenté dans la structure 99 d'accès unifié par un service OSGi implémentant l'interface 112 d'élément « eThing », ce service comportant les attributs suivants : un état, un identifiant unique, un nom, un vendeur, une version, un numéro de série, une description. Ainsi, dans l'exemple ci-dessous, un adaptateur 97 d'éléments « eThing » implémente l'interface OSGi « eThing », est interfacé avec un adaptateur 95 protocolaire via une méthode « bindProtocolAdapter() », cette méthode étant apte à associer tout adaptateur 95 protocolaire avec tout élément « eThing », et comprend pour champs : un état « Status », un identifiant unique « UID », un nom « NAME », un vendeur « VENDOR », une version « VERSION », un numéro de série « SERIAL_NUMBER », une description « DESCRIPTION »
package com.bull.everythink.etmf.api.ethings;
import com.bull.everythink.etmf.api.protocoladapters.ProtocolAdapter;
public interface EThing {
enum Status {
UNRESOLVED,
STOPPED,
STARTED
}
String PROPERTY_NAME = "eThing.name";
String PROPERTY_VENDOR = "eThing.vendor";
String PROPERTY_VERSION = "eThing.version";
String PROPERTY_SERIAL_NUMBER = "eThing.serial.number";
String PROPERTY_DESCRIPTION = "eThing.description";
String PROPERTY_UID = "eThing.uid";
Status getStatus();
void bindProtocolAdapterfProtocolAdapter protocol Adapter);
void unbindProtocolAdapterf);
void startf);
void stopf);
String getUIDQ;
Les fonctions de l'équipement 1, 89, 91 (ou du service) sont quant à elles représentées par des services OSGi implémentant une interface 113 abstraite de fonction d'éléments nommée « eThingFunction » et trois interfaces de bases :
une interface 114 d'alarme nommée « Alarm a, permettant de générer les alarmes issues de l'équipement, ces alarmes étant décrites par une classe 115 nommée « AlarmData »;
une interface 116 de contrôle « Control », permettant de contrôler l'état d'un équipement et/ou d'agir dessus, et comprenant deux fonctions
o une fonction 117 de contrôle binaire nommée « BinaryControl », dans le cas où l'état associé au capteur d'un équipement est de type binaire. La valeur de cet état est alors représentée par une classe nommée « BinaryData » ; o une fonction 118 de contrôle multi-niveau nommée « MultiLevelControl », dans le cas où l'état du capteur associé à un équipement comprend plusieurs états (multivalué). La valeur de cet état est alors représentée par une classe nommée « MultiLevelData » ;
une interface 119 de capteur nommée « Sensor », permettant de collecter, périodiquement ou non, une valeur issue d'un capteur d'un équipement 1, 89, 91, selon deux fonctions :
o une fonction 120 de capteur binaire nommée « BinarySensor », si le capteur associé est de type binaire.
La valeur est alors représentée par la classe nommée « BinaryData » ;
o une fonction 121 de capteur multi-niveau nommée « MultiLevelSensor » , si le cas capteur associé est multivalué. La valeur est alors représentée par la classe nommée « MultiLevelData ».
Des exemples de réalisation de l'interface 113 abstraite de fonction d'éléments « eThingFunction », de l'interface de base « Alarm » et de la classe « AlarmData » sont donnés ci-dessous :
public interface EThingFunction<D extends Data> {
String PROPERTY_NAME = "eThing.function.name";
String PROPERTY_DESCRIPTION = "eThing.function.description";
String TOPIC_DATA_PUBLISHED = "com/bull/everythink/etmf/ethings/functions/data/PUBLISHED";
Map<String, ?> getPropertiesf);
Class<D> supportedDataf);
} public interface Alarm<A extends AlarmData> extends EThingFunction<A> {
}
public class AlarmData implements Data {
private long timestamp;
private Map<String, String> metadata = new HashMap<String, String>();
private int type;
public AlarmDatafint type, Map<String, String> metadata) {
thisftype, new Date().getTime(), metadata);
}
public AlarmDatafint type, long timestamp, Map<String, String> metadata) {
this.timestamp = timestamp;
this.type = type;
if (metadata != null) {
this. metadata. putAII(metadata);
}
}
public int getTypef) { return type;
}
public Map<String, String> getMetadataf) {
return metadata;
}
public long getTimestampf) {
return timestamp;
}
}
Avantageusement, un nouvel équipement 1, 89, 91 ou service ajouté est supporté dans le système par l'ajout adaptateur 97 d'éléments « eThing », via une classe « eThingAdapter » implémentant les interfaces précédemment décrites.
Ainsi, pour la communication avec le premier équipement 89, l'adaptateur 97 d'éléments « eThing » est connecté à l'adaptateur 95 protocolaire, ce dernier exposant un service avec une interface OSGi adaptée au protocole de communication spécifique de cet équipement 89. Avantageusement, les interfaces spécifiques adaptées aux protocoles de communication, comportent deux interfaces de base nommées « CommProtocolAdapter » et
« ProtocolAdapterFactory ».
Chaque service de l'interface « ProtocolAdapter » expose au moins les deux propriétés suivantes : type, vendeur.
Chaque type d'adaptateur 95 protocolaire définit alors une interface OSGi qui étend l'interface « CommProtocolAdapter » . Par étendre une interface (composée de méthodes, paramètres et valeurs de retour associés), on entend, ici, reprendre une interface existante à un niveau d'abstraction plus générique, et à lui ajouter de nouvelles méthodes qui lui sont propre. En outre, on associe à chaque adaptateur protocolaire un fabrique d'adaptateur protocolaire, dite « Protocol Adapter Factory » (PAF), permettant de créer un adaptateur protocolaire avec des propriétés appropriées. Avantageusement, chaque fabrique d'adaptateur protocolaire PAF définit une interface qui étend l'interface « ProtocolAdapterFactory ». L'adaptateur protocolaire créé par la fabrique d'adaptateur protocolaire PAF, est ensuite associé à un adaptateur d'élément « eThing ». L'adaptateur d'élément « eThing » pourra ensuite éventuellement notifier la fabrique d'adaptateur protocolaire PAF qu'il n'utilise plus l'adaptateur protocolaire, permettant ainsi de libérer des éventuelles ressources. Un exemple de réalisation d'adaptateur 95 protocolaire, étendant la classe OSGi « ProtocolAdapter », présentant pour propriétés un type « TYPE » et un vendeur « VENDOR » est donné ci-dessous :
Pour cet exemple, chaque adaptateur protocolaire est associé à une fabrique d'adaptateur protocolaire PAF, étendant l'interface « ProtocolAdapterFactory » et réalisé de la manière suivante :
package com .bu II .everythink.etmf :.api .protocol adapter s; import ja va.util.Dictionary; public interface ProtocolAdapterFactory {
ProtocolAdapter createProtocolAdapter(Dictionary<?, ?> properties) throws
ProtocolA dapterException ;
void releaseProtocol AdapterfP rotocol Adapter protocol Adapter) throws
ProtocolA dapterException;
}
Par ailleurs, la structure 99 (« framework ») d'accès unifié, plus précisément l'interface 94 de programmation applicative, comprend les deux interfaces programmatiques suivantes :
une interface 122 de publication/souscription nommée « publish/subscribe », permettant, selon un mode événementiel o la réception asynchrone d'événements ou de données issues d'un équipement 1, 89, 91 ou d'un service, après une étape d'abonnement/souscription de l'utilisateur, vers la structure 99 (« framework ») d'accès unifié (ex : à destination d'un service 88, 90 spécifique) ;
o la publication asynchrone depuis la structure 99 (« framework ») d'accès unifié (ex : à partir d'un service 88, 90 spécifique), de données ou d'événements vers un équipement 1, 89, 91 ou service relatif à un ou plusieurs utilisateurs abonnés ;
une interface 123 de requête nommée « request » permettant, selon un mode synchrone, la récupération, la lecture/l'écriture de données issues/à destination d'un équipement 1, 89, 91 ou service, vers/depuis la structure 99 (« framework ») d'accès unifié (ex : à destination/depuis un service 88, 90 spécifique). Avantageusement, l'interface 123 de requête nommée « request » permet d'envoyer des requêtes sur les équipements 1, 89, 91 (services « eThing ») de lecture de données (message de type « GET ») ou d'écriture (message de type « SET» sur un attribut ou invocation d'une opération). Dans une mode de réalisation pour créer des requêtes vers un élément (équipement 1, 89, 91 ou service), on utilise une méthode statique, comprenant pour arguments l'identifiant « uid » de l'élément « eThing », ainsi que le nom de la fonction d'élément « eThingFunction ».
On utilise ensuite une méthode pour :
lire les données sur un équipement (commande « getData ») :
<D extends Data> D getData(Class<D> rawDataType)
écrire des données vers un équipement (commande « sendData ») :
<D extends Data> Request sendDatafD data)
L'interface 122 de publication/souscription nommée « publish/subscribe », permet quant à elle :
de produire des données sur cette interface en renseignant un identifiant d'équipement « eThing » :
<D extends Data> Publisher publishDatafD data, String eThingName, String eThingVersion , String eThingUid, String eThingFunctionName)
Avantageusement, ceci permet de réinjecter des données depuis un service applicatif ou de plus haut niveau que l'interface 94 de programmation applicative API unifiée sur cette interface, par exemple, depuis un moteur de traitement d'événements complexes CEP, acronyme anglais de « Complex Event Processing ». Un tel moteur CEP peut être à la fois consommateur et producteur de données sur l'interface 94 de programmation applicative API. Dans cet exemple, la production de données résulte de la création d'un nouvel événement par le moteur CEP (ex : par corrélation d'autres événements), ces données étant ensuite consommées par des applications via l'interface 122 de publication/souscription « publish/subscribe » ; de souscrire à des données produites sur des éléments « eThings », en définissant un filtre d'événement dit « EventFilter » , permettant d'enregistrer un « écouteur » d'événement sur le service, couramment désigné par l'anglicisme « listener ». Lorsque des données correspondant au filtre sont publiées, on utilise une fonction de rappel, couramment désignés sous l'anglicisme « callback ». Avantageusement, la fonction de rappel « callback » permet d'implémenter une interface 124 d'événement relative à la fonction d'élément « eThing » dite interface 124 « EThingFunctionEvent » qui n'a qu'une seule méthode :
void handleEThingFunctionEvent(EThingFunctionEvent<D> event)
Un exemple d'utilisation de « listener », permettant à une application consommatrice de données d'un équipement 1, 89, 91 d'enregistrer un « callback » (oud' invoquer une méthode lorsque ses données seront disponibles) est donné ci-dessous :
est donné ci-dessous :
EventFilter eventFilter = EventFilter.eventFilter(context) ;
MyHandler<Data> hdl = new MyHandlerf ...);
eventFilter. registerEThingFunctionEventHandlerfhdl, Data .class, getNamef), getVersionf), getUidf), null);
Avantageusement, l'ensemble des services applicatifs utilisateurs s'appuient sur l'interface 94 de programmation applicative API unifiée, permettant une abstraction des équipements 1, 89, 91 et des protocoles de communication sous-jacents. Ainsi, le remplacement d'un équipement 1, 89, 91, par un nouvel équipement reposant sur un protocole de communication différent, mais proposant les mêmes services, c'est-à-dire les mêmes fonctions, n'a alors aucun impact sur le code du service utilisateur lié à l'interface 94 de programmation applicative API unifiée. En outre, l'interface 94 de programmation applicative API unifiée offre un moyen d'abstraire le mode d'accès aux équipements 1, 89, 91 qu'il soit synchrone (mode de données tirées « pull ») pour la lecture ou l'écriture de données, ou qu'il soit asynchrone ou lié à un événement (mode de données poussées « push ») pour la lecture de données issues des équipements 1, 89, 91, via les interfaces 122, 123 de publication/souscription « publish/subscribe » et de requête « request ». Avantageusement, tout mode non implémenté nativement par un équipement 1, 89, 91 est alors simulé par la structure 99 (« framework ») d'accès unifié. La figure 30, illustre à titre d'exemple, un équipement 1 fonctionnant, selon un mode synchrone (mode tiré « pull »), interfacé avec la structure 99 (« framework ») d'accès unifié comprenant l'interface 94 de programmation applicative API unifiée, cette structure étant interfacé avec un premier service utilisateur 125 basé sur mode synchrone, et un deuxième service utilisateur 126 basé sur un mode asynchrone. Le premier service 125 utilisateur utilise donc l'interface 123 de requête « request », tandis que le deuxième service 126 utilisateur utilise l'interface 122 de publication/souscription « publish/subscribe » de l'interface de programmation applicative API 94 unifiée de la structure 99 (« framework ») d'accès unifié. Dans cet exemple, les modes de requêtes émanant du premier service 125 utilisateur sont représentés par la flèche 127, tandis que les modes de publication/souscription « publish/subscribe » sont respectivement représentés par les flèches 128, 129.
Le mode synchrone « request » en écriture et lecture, est implémenté par une simple délégation, c'est-à-dire par un simple appel de méthode, sur l'interface native de l'équipement 1 : on utilise alors des messages de type « SET » en écriture propagé (flèche 130) sur l'équipement 1 et « GET » en lecture retournant la dernière valeur/donnée lue sur l'équipement 1.
Le mode événementiel étant asynchrone, ce dernier mode est alors simulé par la structure 99 (« framework ») d'accès unifié en récupérant périodiquement (flèche 131), via l'interface 123 de requête « request », les données sur l'équipement et en mémorisant la dernière donnée lue. Cette dernière donnée est alors envoyée vers l'interface 122 de publication/souscription « publish/subscribe ».
Avantageusement, la période de collecte est configurable via l'interface 113 abstraite de fonction d'éléments « eThingFunction ». La figure 31, illustre, un équipement 1 fonctionnant, selon un mode événementiel (mode « push »), interfacé avec la structure 99 (« framework ») d'accès unifié comprenant l'interface 94 de programmation applicative API unifiée, cette structure étant interfacée avec un premier service 125 utilisateur basé sur mode synchrone, et un deuxième service 126 utilisateur basé sur un mode asynchrone. Le premier service utilisateur 125 utilise donc l'interface 123 de requête « request », tandis que le deuxième service 126 utilisateur utilise l'interface 122 de publication/souscription « publish/subscribe » de l'interface 94 de programmation applicative API unifiée de la structure 99 (« framework ») d'accès unifié. Dans cet exemple, les modes de requêtes émanant du premier service 125 utilisateur sont représentés par la flèche 127, tandis que les modes de publication/souscription « publish/subscribe » sont respectivement représentés par les flèches 128, 129. A la différence de l'exemple précédent, l'équipement 1 pousse ses données vers l'interface 122 de publication/souscription « publish/subscribe ». Ainsi, la flèche 128 se rapporte à la propagation des données que l'équipement 1 pousse (flèche 132) à chaque nouvel événement. L'équipement 1 étant cette fois basé sur mode asynchrone, la structure 99 (« framework ») d'accès unifié simule cette fois le mode synchrone en mémorisant la dernière donnée poussée par l'équipement 1 via l'interface 122 de publication/souscription « publish/subscribe ». Cette donnée est alors envoyée vers l'interface 123 de requête « request ». Ensuite, comme précédemment, le mode synchrone « request » en écriture et lecture, est implémenté par une simple délégation sur l'interface native de l'équipement : on utilise alors des messages de type « SET» en écriture propagé (flèche 130) sur l'équipement 1 et « GET » en lecture retournant la dernière valeur lue sur l'équipement 1.

Claims

REVENDICATIONS
1. Boîtier (5) de communication pour la gestion d'une pluralité d'équipements (1) utilisateur incluant des capteurs et des actionneurs installés dans un environnement prédéfini, ce boîtier (5) comprenant une première interface de communication pour récupérer au moins une mesure mesurée par au moins un capteur de ladite pluralité d'équipements (1) utilisateur ;
une deuxième interface de communication pour communiquer au moins une commande à au moins un actionneur de ladite pluralité d'équipements (1) utilisateur;
des moyens pour isoler les ressources pour la récupération de ladite première donnée et pour la communication de ladite commande.
2. Le boîtier (5) de communication de la revendication précédente, dans lequel ladite mesure est récupérée selon un premier protocole de communication et ladite commande est communiquée selon un deuxième protocole de communication, le premier protocole étant différent du deuxième protocole.
3. Le boîtier (5) de communication de la revendication 1 ou 2, étant, en outre, configuré pour transmettre au moins une donnée à une plateforme (4) centrale de données.
4. Le boîtier (5) de communication de l'une quelconque des revendications précédentes, disposant d'une adresse privée non adressable depuis ladite plateforme (4) centrale de données.
5. Le boîtier (5) de communication de la revendication 3, dans lequel ladite donnée est un paramètre associé à un équipement de ladite pluralité d'équipements (1) utilisateur.
6. Le boîtier (5) de communication de l'une quelconque des revendications précédentes, comprenant en outre une interface de programmation applicative.
7. Le boîtier (5) de communication de l'une quelconque des revendications précédentes, étant, en outre, configuré pour recevoir ladite commande.
8. Un réseau local comprenant ledit boîtier (5) de communication de l'une quelconque des revendications précédentes.
9. Le réseau local de la revendication précédente comprenant, en outre, un dispositif d'accès intégré interfacé avec ledit boîtier (5) de communication.
EP15817467.2A 2014-12-31 2015-12-03 Boitier de communication et de gestion d'equipements Ceased EP3241118A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463494A FR3031208B1 (fr) 2014-12-31 2014-12-31 Boitier de communication et de gestion d'equipements
PCT/FR2015/053305 WO2016107996A1 (fr) 2014-12-31 2015-12-03 Boitier de communication et de gestion d'equipements

Publications (1)

Publication Number Publication Date
EP3241118A1 true EP3241118A1 (fr) 2017-11-08

Family

ID=52988244

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15817467.2A Ceased EP3241118A1 (fr) 2014-12-31 2015-12-03 Boitier de communication et de gestion d'equipements

Country Status (4)

Country Link
US (1) US10505750B2 (fr)
EP (1) EP3241118A1 (fr)
FR (1) FR3031208B1 (fr)
WO (1) WO2016107996A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015200210A1 (de) * 2015-01-09 2016-07-14 Siemens Aktiengesellschaft Sichere Übermittlung von sensiblen Messdaten in einemAutomatisierungsnetzwerk
WO2018198460A1 (fr) * 2017-04-28 2018-11-01 日本電信電話株式会社 Système et procédé de conversion d'espace d'id
CA3110691A1 (fr) * 2018-08-24 2020-02-27 Lutron Technology Company Llc Dispositif de detection d'occupant
US11394627B1 (en) * 2019-07-31 2022-07-19 Express Scripts Strategie Development, Inc. Systems and methods for monitoring inter-application communications in complex computing ecosystems
CN112073244A (zh) * 2020-09-09 2020-12-11 上海诺行信息技术有限公司 基于tr069协议的消息处理方法及系统
CN113315824B (zh) * 2021-05-26 2023-04-18 武汉悦学帮网络技术有限公司 一种应用的灰度发布方法、装置及应用的灰度发布系统
CN114500612B (zh) * 2022-04-06 2022-07-05 深圳航天信息有限公司 物联网本地组网的方法、装置、电子设备及存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2015179A1 (fr) * 2007-07-13 2009-01-14 Alcatel Lucent Système de gestion à distance et procédé pour objets de service
CN201854450U (zh) * 2010-11-19 2011-06-01 上海波顿无线传感技术有限公司 用于环境监测物联网的网关模块
US9413827B2 (en) * 2013-02-25 2016-08-09 Qualcomm Incorporated Context aware actions among heterogeneous internet of things (IOT) devices
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US9814084B2 (en) * 2014-08-07 2017-11-07 Belkin International Inc. Location and pairing of devices on a local area network using a unique identifier
US20160028856A1 (en) * 2014-07-24 2016-01-28 Miiicasa Taiwan Inc. Method, system and apparatus for providing services across networks
WO2016097822A1 (fr) * 2014-12-17 2016-06-23 Nokia Technologies Oy Procédé et appareil de surveillance locale de données et commande d'actionneur dans un réseau de l'internet des objets
TWI663782B (zh) * 2016-10-14 2019-06-21 天邁科技股份有限公司 具導電膠天線之殼體結構

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GAMA KIEV ET AL: "Towards Dynamic Component Isolation in a Service Oriented Platform", 24 June 2009, SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 104 - 120, ISBN: 978-3-540-74549-5, XP047385759 *

Also Published As

Publication number Publication date
US20180152313A1 (en) 2018-05-31
US10505750B2 (en) 2019-12-10
FR3031208B1 (fr) 2018-02-02
WO2016107996A1 (fr) 2016-07-07
FR3031208A1 (fr) 2016-07-01

Similar Documents

Publication Publication Date Title
EP3241118A1 (fr) Boitier de communication et de gestion d&#39;equipements
EP3241121A1 (fr) Systeme de gestion de donnees d&#39;equipements utilsateurs
CN105706469B (zh) 管理机器对机器设备
Kleinfeld et al. glue. things: a Mashup Platform for wiring the Internet of Things with the Internet of Services
Fazio et al. The need of a hybrid storage approach for iot in paas cloud federation
Di Martino et al. A semantic IoT framework to support RESTful devices' API interoperability
EP3241308B1 (fr) Boitier d&#39;interconnexion d&#39;equipements utilisateurs
EP3241316B1 (fr) Methode de communication entre un gestionnaire d&#39;action distant et un boitier de communication
Zhurakovskyi et al. Smart House Management System
EP3318017A1 (fr) Procédé de découverte de la configuration d&#39;une installation domotique
FR3076022A1 (fr) Virtualisation d&#39;un objet connecte
EP3817294B1 (fr) Procede et module pour la regulation de la connectivite d objets connectes
Almeida Plataforma de Monitorização em IoT de Recolha de Dados Sobre o Conforto Térmico Interior
Rachidi Design and implementation of a framework for self-configuring devices using TR-069
Rodrigues Large scale interoperability in the context of Future Internet
FR3017505A1 (fr) Procedes de controle et de proposition de controle d&#39;un equipement connecte a un reseau de communication, equipements, systeme, produits programmes d&#39;ordinateur et supports de donnees correspondants
FR3082028A1 (fr) Agregation d&#39;objets connectes.
FR2980664A1 (fr) Prise en compte de la localisation dans la determination de la disponibilite des objets physiques dans l&#39;internet des objets
Sun et al. Handbook of Research on Demand-Driven Web Services: Theory, Technologies, and
Thomsen Home Appliance Integration by Pervasive Computing
FR3026517A1 (fr) Dispositif et procede de transfert bidirectionnel de donnees entre un terminal de communication et un module compatible isobus

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170630

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201019

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230330

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20230911