FR3055717A1 - Structure informatique perfectionnee d'un objet connecte - Google Patents

Abstract

La présente invention concerne un dispositif communiquant, de type objet connecté, relié à un circuit de traitement comprenant au moins un processeur (PROC) coopérant avec une mémoire (MEM) apte à stocker des instructions d'un programme informatique pour piloter le fonctionnement de l'objet connecté lorsque lesdites instructions sont exécutées par le processeur. Le programme informatique est structuré selon trois couches applicatives basées respectivement sur : - un modèle de ressources définissant des fonctionnalités de bas niveau de l'objet connecté pour opérer au moins un service choisi, - un modèle d'artéfacts définissant un ou plusieurs services, parmi lesquels au moins un service est sélectionnable en tant que service choisi, et - un modèle de connaissances définissant des règles d'opération de chacun desdits services, le modèle d'artéfacts établissant un lien entre les règles associées à chaque service et les fonctionnalités pour opérer ce service.

Description

Titulaire(s) : ELECTRICITE DE FRANCE Société anonyme, INSTITUT MINES TELECOM Etablissement public.

Demande(s) d’extension

Mandataire(s) : CABINET PLASSERAUD.

STRUCTURE INFORMATIQUE PERFECTIONNEE D'UN OBJET CONNECTE.

FR 3 055 717 - A1 (5/) La présente invention concerne un dispositif communiquant, de type objet connecté, relié à un circuit de traitement comprenant au moins un processeur (PROC) coopérant avec une mémoire (MEM) apte à stocker des instructions d'un programme informatique pour piloter le fonctionnement de l'objet connecté lorsque lesdites instructions sont exécutées par le processeur. Le programme informatique est structuré selon trois couches applicatives basées respectivement sur:

- un modèle de ressources définissant des fonctionnalités de bas niveau de l'objet connecté pour opérer au moins un service choisi,

- un modèle d'artéfacts définissant un ou plusieurs services, parmi lesquels au moins un service est sélectionnable en tant que service choisi, et

- un modèle de connaissances définissant des règles d'opération de chacun desdits services, le modèle d'artéfacts établissant un lien entre les règles associées à chaque service et les fonctionnalités pour opérer ce service.

Structure informatique perfectionnée d’un objet connecté

La présente invention concerne le domaine des objets connectés.

Un contexte applicatif de l’invention est la maison intelligente. Les objets connectés peuvent être présents dans des maisons de particuliers. Chaque objet connecté est doté de capacités de capture de données de son environnement, d’actionnement d’un objet physique de son environnement ou les deux à la fois. L’objet connecté peut également mettre à disposition de son environnement un service s’il possède des capacités de calcul. On parle alors d’Internet des Objets (« IdO » ci-après).

La collaboration des objets connectés entre eux permettraient d’améliorer grandement les services que peuvent proposer ces objets. Il serait alors possible d’utiliser les fonctionnalités et les services qu’ils offrent dans le but de produire de nouveaux services plus complexes et régis par les besoins réels des utilisateurs.

Les architectures basées sur des modèles dits « de ressources » sont les plus déployées dans le domaine des communications dans l’Internet des Objets. Ce succès est dû notamment aux propriétés de faible couplage, de simplicité et d’évolutivité de ces architectures. Dans le but de standardiser les communications dans l’IdO, le consortium 0neM2M a été formé. 0neM2M a proposé une architecture dite « Restful » basée sur des ressources afin de faciliter l’interopérabilité entre les objets.

D'autres groupes de travail ont été formés dans le but de fournir un standard de communication pour l'IdO tels que l'alliance Allseen et qui a proposé le standard et la plateforme Alljoyn. Le consortium OIC (Open Interconnect Consortium) a mis en place la plateforme Iotivity. Comme 0neM2M, Alljoyn et Iotivity s'appuient sur des modèles qui sont basés sur des ressources et sur des communications Restful de type requête/réponse, augmentées par des principes de type publish/subscribe.

Ces groupes de travail ont fait le choix d’abstraire les objets sous forme de ressources et de standardiser les communications entre ces ressources en respectant les échanges Restfuls.

Néanmoins, ces réalisations ne permettent pas de définir de façon standard des compositions de service. Plusieurs travaux académiques ont été menés autour de la composition de web services Restful. Une approche consiste à adapter du langage de composition de services BPEL (pour « Business Process Execution Language ») aux services Restfuls. D’autres travaux portent sur la sémantique dans l’IdO, et proposent d’augmenter les ressources avec les aspects sémantiques afin de les rendre accessibles aux machines et aux êtres humains.

Toutefois, les objets qui composent l’Internet des Objets ont une nature très hétérogène. Ces objets vont du thermomètre communicant à la voiture communicante, en passant par l’aspirateur communicant. Ces objets possèdent aussi des caractéristiques très différentes. Certains objets sont mobiles et d’autres pas. Cette hétérogénéité ne permet pas de représenter de manière homogène tous les objets qui constituent l’Internet des Objets.

Aujourd’hui, dans l'IdO, il n’existe pas encore de cadre standard approuvé et adopté par la communauté scientifique et par les constructeurs d’objets connectés. Au contraire, la tendance est plutôt à produire des objets qui communiquent via des protocoles et des modèles propriétaires, qui sont basés sur des architectures verticales, ce qui conduit à l’apparition de silos technologiques. Dans le modèle actuel en silos, un service de sécurité et un service d’allumage automatique ne peuvent partager le même capteur de présence s’ils ne proviennent pas du même constructeur, et chaque service utilise ainsi son propre capteur de présence. L’architecture en silos est due au fort couplage entre les objets et les services qui s’appuient sur ces objets.

La présente invention vient améliorer cette situation.

Elle propose à cet effet un dispositif communiquant, de type objet connecté, relié à un circuit de traitement comprenant au moins un processeur coopérant avec une mémoire apte à stocker des instructions d’un programme informatique pour piloter le fonctionnement de l’objet connecté lorsque lesdites instructions sont exécutées par le processeur. En particulier, le programme informatique est structuré selon trois couches applicatives basées respectivement sur :

- un modèle de ressources définissant des fonctionnalités de bas niveau de l’objet connecté pour opérer au moins un service choisi,

- un modèle d’artéfacts définissant un ou plusieurs services, parmi lesquels au moins un service est sélectionnable en tant que service choisi, et

- un modèle de connaissances définissant des règles d’opération de chacun desdits services.

Le modèle d’artéfacts établit alors un lien entre les règles associées à chaque service et les fonctionnalités pour opérer ce service.

On comprendra ainsi que le modèle d’artéfacts permet de prédéfinir plusieurs services susceptibles d’utiliser plusieurs ressources en coopération (par exemple, des capteurs et/ou des actionneurs, dont les fonctionnalités sont définies par le modèle de ressources), et ce en fonction de règles d’opération définies par le modèle de connaissances. Une telle réalisation permet de casser les silos verticaux qui empêchent l’emploi de ressources de technologies différentes.

Ainsi, dans une forme de réalisation, le dispositif comporte une interface de communication via un réseau étendu, adaptée pour connecter le dispositif avec au moins un deuxième objet connecté, et le service choisi précité est opéré par une interaction entre le dispositif et le deuxième objet connecté. Dans une telle réalisation, le modèle d’artéfacts peut définir alors un service opérable par un objet connecté virtuel, référencé dans le modèle de ressources en tant qu’objet composite apte à opérer des fonctionnalités à la fois du dispositif et du second objet connecté.

Dans une forme de réalisation, le modèle d’artéfacts définit, pour chaque service, un ou plusieurs modes de fonctionnement de l’objet connecté pour opérer ce service.

Dans une réalisation où le dispositif est connecté à au moins un capteur, le modèle d’artéfacts définit, pour chaque service, au moins un type de données à mesurer par le capteur pour opérer le service.

Dans une réalisation où le dispositif est connecté à un actionneur, le modèle d’artéfacts définit, pour chaque service, au moins un type d’action à effectuer par l’actionneur pour opérer le service.

Dans un mode de réalisation, le modèle d’artéfacts définit en outre, pour chaque service, un cycle de vie propre à ce service.

Dans un mode de réalisation, le modèle d’artéfacts définit en outre, pour chaque service, un modèle d’information propre à ce service.

Dans un mode de réalisation, le modèle de connaissances est de type sémantique et enrichi par des données entrées par un utilisateur via une interface homme/machine à laquelle est connecté le dispositif.

Dans un mode de réalisation, le modèle de connaissances définit au moins des règles métier pour opérer un service.

Dans ce mode de réalisation, le modèle de connaissances définit en outre des règles de médiation pour un service issu d’une combinaison de services, selon une politique de règles prédéterminées.

La présente invention vise aussi un programme informatique pour piloter le fonctionnement d’un objet connecté lorsque lesdites instructions sont exécutées par un processeur que comporte l’objet connecté. Selon l’invention, le programme informatique est structuré selon trois couches applicatives basées respectivement sur :

- un modèle de ressources définissant des fonctionnalités de bas niveau de l’objet connecté pour opérer au moins un service choisi,

- un modèle d’artéfacts définissant un ou plusieurs services, parmi lesquels au moins un service est sélectionnable en tant que service choisi, et

- un modèle de connaissances définissant des règles d’opération de chacun desdits services, le modèle d’artéfacts établissant un lien entre les règles associées à chaque service et les fonctionnalités pour opérer ce service.

D’autres avantages et caractéristiques de l’invention apparaîtront à la lecture de la description détaillée ci-après d’exemples de réalisation de la présente invention, et à l’examen des dessins annexés sur lesquels :

- la figure 1 illustre le modèle de ressources précité,

- la figure 2 illustre le modèle d’artéfacts précité,

- la figure 3 illustre le modèle de connaissances précité, et

- la figure 4 illustre un dispositif au sens de l’invention.

Les mêmes références aux dessins désignent des éléments identiques ou équivalents d’une figure à l’autre. Par ailleurs, les traits joignant les blocs sur les figures 1, 2, 3 montrent les interactions entre blocs logiques. Le signe « 1 » sur ces traits désignent des nombres d’éléments relatifs à ces interactions, et le signe « * » désigne la possibilité de prévoir plus d’un seul élément dans l’interaction. Ainsi par exemple sur la figure 1, le modèle qui est représenté prévoit un objet connecté OBJ pour une ressource associée RES, bijectivement.

La mise en œuvre de l’invention permet de parvenir à une architecture horizontale qui découple les objets connectés des services offerts dans la maison pour que plusieurs services puissent avoir accès aux données d’un même objet s’ils en ont le besoin. Les caractéristiques de l’invention permettent de gérer le contrôle d’accès simultané au même objet par plusieurs services.

L’invention propose de regrouper dans une même architecture plusieurs couches de modèles propres à des approches respectives distinctes (puis de les adapter et les compléter afin de casser les silos technologiques actuels de l’IdO). L’architecture proposée est une architecture horizontale décrivant de manière transverse l’interaction des objets connectés entre eux, ainsi que les interactions avec les utilisateurs finaux. Cette architecture a pour but de faciliter la collaboration entre les objets en mettant en œuvre trois niveaux d’architecture, correspondant aux approches précitées : ressources, artefacts et connaissances.

Le modèle de ressources correspond à celui développé par le consortium 0neM2M.

Le modèle d’artefacts s’appuie sur les «Business Artefacts». H s’agit initialement d’une approche visant la modélisation de processus métiers dans une entreprise. Ce modèle a été adapté dans le cadre de la présente invention et est détaillé en référence à la figure 2 présentée plus loin.

Au-delà de l'interopérabilité entre les objets, ces objets peuvent collaborer entre eux dans le but d'offrir de nouveaux services aux utilisateurs. H est donc possible de composer dynamiquement les services offerts par les objets afin de produire de nouveaux services plus complexes et de les mettre à disposition des utilisateurs. Ces nouveaux services peuvent ensuite être réutilisés et/ou recomposés pour créer encore d’autres services.

En matière de composition de services, aujourd’hui la description des flux de composition de services (ou « workflows ») se fait après la mise en place des services. Au moment où le workflow est mis en œuvre, le compositeur de services a connaissance de tous les services qui interviennent dans la composition. Cette vision manque de dynamisme dans le cas où il est souhaité que le flux de composition puisse s’adapter à son contexte. En effet, le processus de composition de service doit se faire de manière dynamique en fonction de la disponibilité des objets connectés et des données contextuelles renvoyées par ces objets.

En outre, l’accessibilité des règles de composition de services est un point important à résoudre. Dans le cadre de l’Internet des Objets, le processus de composition de services et les règles qui en découlent sont souvent destinés à satisfaire un besoin ou une demande de l’utilisateur. Cette demande est formulée de manière déclarative en décrivant des objectifs à atteindre. Or, les règles de composition sont souvent écrites dans des langages impératifs qui décrivent une procédure à suivre plutôt qu’un but à atteindre. Ces langages sont aussi souvent techniques (programmation machine) pour des utilisateurs non-initiés. La mise en œuvre de l’invention permet de faire en sorte que les utilisateurs puissent dans un premier temps valider les règles qui leur sont proposées par le compositeur de services et dans un deuxième temps de les compléter ou les modifier.

En effet, selon une démarche de l’invention, on cherche à abstraire les objets du monde réel dans un modèle de ressources afin d’homogénéiser la très grande variété de ces objets. Ces choix permettent aussi de casser les silos de communication puisque tous les objets, quelle que soit leur nature, peuvent avantageusement communiquer de la même manière en utilisant une interface uniforme.

Un contexte d'application la présente invention est le domaine énergétique dans la maison connectée. Ici, des objets connectés sont présents dans les maisons des particuliers et chaque objet connecté met à disposition de son environnement un service élémentaire. Les différents objets sont interconnectés pour les faire collaborer afin de réutiliser les services qu’ils offrent et de les composer dans le but de produire de nouveaux services plus riches. La proposition d’architecture s’appuie sur trois niveaux de modèles :

- un modèle de ressources (figure 1),

- un modèle d’artefacts (figure 2)

- et un modèle de connaissances (figure 3), selon trois couches applicatives interconnectées comme décrit ci-après.

Ces couches sont respectivement des programmes informatiques de bas niveau (en partie au moins du langage machine, pour adresser au moins certains composants hardware d’un objet), de niveau intermédiaire, et de niveau supérieur (basé sur des connaissances acquises dans des contextes précédemment rencontrés et/ou par apprentissages de certains choix de rutilisateur, en opération).

Le premier niveau de l’architecture est un modèle de ressources. Ce modèle a pour but de répondre à la problématique d’hétérogénéité des objets et de leurs communications dans l’internet des objets. Dans ce modèle, pour tout type d’objet connecté, sa typologie et ses caractéristiques, il est représenté sous forme d’une ressource. Les ressources sont adressables et disponibles sur internet. Le modèle de ressources permet donc d’uniformiser la nature des objets en les encapsulant dans une ressource. Ce modèle permet aussi d’uniformiser l’accès aux ressources. Contrairement aux architectures à base de services SOA (« Service Oriented Architectures ») où les méthodes d’accès aux services diffèrent d’un service à un autre, les architectures à base de ressources ROA (« Resource Oriented Architectures ») uniformisent l’accès aux ressources. Ces ressources sont alors accessibles et interrogeables de manière unique sur internet. Pour tout type de ressource sur le Web, cette ressource est toujours interrogée en utilisant les mêmes méthodes dites CRUD (pour « Create, Retrieve, Update et Delete »).

Dans ce modèle en référence à la figure 1, il est proposé de représenter chaque objet connecté OBJ, (notamment d’un système d’objets interconnectés) par une ressource RES. A un moment donné, un objet est localisé à un endroit (emplacement EMP). Cet emplacement est décrit par un attribut « endroit actuel » (appelé dans le modèle « CurrentPlace ») de la classe relative à l’objet connecté. Un objet peut être un capteur, un actionneur ou les deux en même temps. En fonction de son type, un objet peut mesurer et fournir des données de son environnement s’il est de type capteur. Il peut offrir un moyen d’agir sur son environnement via des actions s’il est actionneur. Les données et les actions qui peuvent être fournies par les objets connectés sont définies par des types de données DAT (pour « DataType ») et des types d’actions ACT (pour « ActionType »). Tous les types de données et types d’actions qui peuvent être fournies par des objets connectés sont répertoriées dans un catalogue CAT. Sur le modèle de ressources de la figure 1, chaque objet connecté est caractérisé par un ensemble de types de données et de types d’actions qu’il peut offrir. Dans le contexte de la maison connectée par exemple, le référentiel de la maison HR (pour « HomeRepository ») décrit le plan de la maison et tous les endroits qui s’y trouvent. Un endroit est une localisation géographique de la maison sur laquelle peut se trouver un ou plusieurs objets. L’endroit peut être un mur M ou une pièce CH. Le référentiel de la maison décrit aussi tous les objets connectés qui sont présents dans la maison, ce qui permet de prendre en compte les préférences de confort de ses habitants par exemple. H décrit les habitants de la maison INH et les visiteurs occasionnels. H décrit enfin tous les services qui sont en exécution dans la maison.

En référence à la figure 2, la deuxième couche de Γarchitecture s’articule autour d’un modèle d’artefacts. Ce modèle permet d’offrir une architecture horizontale et de casser les silos des architectures verticales qui sont habituellement mises en place. Le modèle d’artefacts permet à plusieurs services d’avoir accès aux mêmes objets et aux données qu’ils génèrent. Le modèle d’artefacts permet aussi d’abstraire le modèle de ressources afin d’en avoir une vue plus globale. Ainsi, chaque service a une vue des ressources qui correspond à ses besoins. Dans le cadre d’une maison connectée par exemple, au lieu d’avoir une vue générale de toutes les ressources qui décrivent tous les objets, le modèle d’artefacts se charge de sélectionner uniquement les données nécessaires pour chaque service. Chaque service a alors une vue restreinte des objets de la maison mais les vues peuvent se croiser et plusieurs services peuvent avoir accès aux mêmes ressources. Le modèle d’artefacts s’appuie sur des représentations globales dites « Business Artifacts » pour chaque service, selon une approche proposée pour la modélisation de processus métier dans une entreprise. Pour des détails de cette approche, on peut se référer au document :

Kamal Bhattacharya, Richard Hull, Jianwen Su, et al. A data-centric design methodology for business processes. Handbook of Research on Business Process Modeling, pages 503-531, 2009.

Dans ce modèle d’artefacts en référence à la figure 2, un service SER est un ensemble logiciel qui s’exécute pour atteindre un objectif défini par l’utilisateur. Chaque service décrit un ensemble de types de données (DAT) et de types d’actions (ACT) dont il a besoin pour s’exécuter. Il est rappelé ici que les mêmes références aux dessins désignent des éléments identiques ou équivalents d’une figure à l’autre. On comprendra ainsi que ce deuxième modèle peut accéder au catalogue CAT de la figure 1 pour accéder aux types d’action et de données nécessaires. En outre, un service peut avoir plusieurs modes de fonctionnement MOD. Dans ce modèle de la figure 2, un artefact ART est créé pour chaque service (comme une représentation globale du service et des règles/fonctionnalités associées). L’artefact a pour fonction de récolter toutes les données contextuelles nécessaires à la bonne exécution du service. L’artefact fait le lien entre :

- le service (dont les connaissances peuvent être définies dans le modèle de la figure 3) et,

- les ressources (dont le modèle est représenté sur la figure 1) qui représentent les objets auxquels il a besoin d’accéder via les types de données et les types d’actions fournies par les objets.

L’artefact est décrit par un modèle d’information INFM (pour « Information Model ») et un cycle de vie DV (ou « Life Cycle »). Le modèle d’information décrit la structure de l’artefact et le cycle de vie décrit l’évolution de l’artefact au fur et à mesure de l’exécution du service.

La troisième couche de l’architecture est une couche sémantique permettant d’enrichir l’architecture avec les aspects sémantiques qui s’articulent autour d’un modèle de connaissances. En matière de composition de services, le modèle de connaissances permet de rendre plus dynamique le processus de composition en l’adaptant à son contexte. Le modèle cadre le nommage des données en concordance avec des vocabulaires métier standardisés. Ainsi, les données sont typées de manière standardisée en fonction du genre d’informations qu’elles représentent. Par exemple, les données représentant des températures sont toujours désignées par un même type « température ». H est alors plus simple de remplacer une donnée manquante par une autre donnée (issue d’un autre capteur ou reçue antérieurement) qui est du même type et qui a les mêmes caractéristiques. Il est aussi plus simple d’intégrer dans le processus de composition de nouvelles données, et donc de nouveaux objets, du moment où leurs types sont déjà connus par le compositeur de services. A partir de ce vocabulaire, sont écrites des règles métier qui décrivent la politique de composition de services en fonction de son contexte. Les règles métier dynamisent le processus de composition de services en lui permettant de s’adapter à son contexte. Dans un deuxième temps, le modèle de connaissances permet d’écrire des règles et des politiques métier dans un langage proche du langage naturel.

De ce fait, il constitue une passerelle entre :

- le modèle d’artefacts qui est écrit dans un langage technique et

- l’utilisateur comprenant le langage naturel (via des interfaces homme/machine, bien entendu).

Dans ce modèle de connaissances (voir figure 3), comme dans le modèle d’artefacts, un service SER est un ensemble logiciel qui s’exécute pour atteindre un objectif qui a été défini par l’utilisateur. Pour atteindre cet objectif, le service SER peut être décomposé en plusieurs macro-activités PRD relatives à des processus métier (ou « Business Process »). Chaque macro-activité est décrite par un ensemble de règles métier REG (ou « Business Rules »). Un service peut avoir plusieurs modes de fonctionnement MOD et s’exécute dans un contexte donné CTX. Chaque mode sélectionne un sous-ensemble des règles métier applicables dans ce mode de fonctionnement. Le contexte CTX est donc une entité complexe qui inclue toutes les données contextuelles qui sont nécessaires au service. Toutes les informations qui sont présentes dans le contexte sont nommées en fonction d’un vocabulaire métier décrit dans le catalogue CAT. L’interaction entre différents services est gérée par une politique POL (ou « Policy ») qui met en œuvre un certain nombre de règles d’interaction NEG dites « de médiation » (ou « Weaving Rules »).

Comme indiqué précédemment, il convient d’observer que certains éléments de modèle sont communs à plusieurs modèles (par exemple, l’élément de modèle propre au service SER). En accédant à cet élément commun, on peut donc passer d’un niveau de modélisation à un autre (d’une figure à l’autre, en se référant aux dessins annexés).

On décrit ci-après quelques exemples de navigation entre les trois niveaux de modèle.

Les cas de navigation particuliers présentés ci-après à titre d’exemple permettent d’introduire chaque élément de modèle et ses liens logiques avec les autres éléments de modèle.

Le premier exemple est relatif à la mise en place d’un nouveau service dans la maison intelligente (ou « smart home »).

Le premier cas de navigation démarre au niveau du modèle de connaissances par l’élément de modélisation « Service » SER. La mise en place d’un nouveau service dans la maison intelligente se caractérise tout d’abord par la définition d’un ensemble de règles de fonctionnement REG (Business Rules) regroupées par des procédures PRD relatives à des règles métier (Business Processes). Le paramétrage du service est effectué par la sélection d’un mode de fonctionnement MOD qui, à son tour, active ou inhibe les règles de fonctionnement décrites auparavant (processus en boucle).

Tous les éléments de description du service à ce niveau de modélisation (processus, règles et modes de fonctionnement) utilisent un vocabulaire tiré d’un catalogue de termes (CAT) et qui en constitue le contexte d’exécution (CTX). L’élément de modélisation CAT constitue un premier moyen de changer de niveau de modélisation (élément commun avec le modèle de ressources).

On considère en outre une situation où le nouveau service coexiste avec des services précédemment installés dans la maison. Dans cette hypothèse, les règles de gestion des conflits avec les autres services NEG (Weaving Rules) sont regroupées dans un recueil de « bonnes pratiques » correspondant à la politique POL (Policy).

La mise en place du nouveau service déclenche la création d’un artefact ART dans le niveau de modélisation d’artefacts. La navigation utilise l’élément de modélisation Service SER commun aux deux niveaux pour passer du niveau du modèle de connaissances au niveau modèle d’artefacts. Ensuite, dans le niveau de modèle d’artefacts, on suit le lien de l’élément de modèle Service SER vers l’élément de modèle d’Artefact ART.

L’artefact correspond dans une certaine mesure à l’implémentation du service. On peut considérer que le modèle de connaissances correspond à la spécification du service alors que le modèle d’artefact correspond à la réalisation du service.

La description de l’artefact comprend deux parties :

- une partie statique (appelée Information Model) INFM et

- une partie dynamique DV (Life Cycle).

La partie statique constitue le modèle d’information utilisé pour réaliser le service alors que la partie dynamique décrit les automatismes mis en place (machines états/transitions). L’artefact doit supporter tous les modes de fonctionnement décrits dans le niveau de modélisation de connaissances (lien vers le bloc MOD) et la description de l’artefact exploite, dans le catalogue du modèle de ressources, les types d’action ACT (ActionType) pour décrire les transitions d’états et les types de données DAT (DataType) pour décrire le modèle d’information et les états du modèle dynamique.

Enfin, l’élément de modélisation Service SER, commun aux deux niveaux, est utilisé pour passer du niveau du modèle de connaissances au niveau de modèle de ressources. Cette dernière étape consiste en l’enrichissement du « répertoire de la maison » HR (ou « Home Repository ») avec le nouveau service.

On décrit ci-après un autre exemple d’application dans lequel un objet connecté est ajouté. Ce deuxième cas de navigation démarre au niveau du modèle de ressources par l’élément de modélisation Objet Connecté OBJ.

L’ajout d’un nouvel objet connecté dans la maison intelligente est tout d’abord déclaré dans le « répertoire de la maison » (Home Repository).

Il lui est ensuite associé un « double » numérique (Resource, dans le bloc RES) qui permet de masquer ses spécificités techniques et de les faire apparaître à son environnement sous une forme homogène d’un ensemble de données DAT (Data Type) qu’il peut fournir (dans le cas d’un capteur notamment) et d’un ensemble d’actions ACT (Action Type) qu’il peut effectuer (dans le cas d’un actionneur). Ces deux ensembles viennent enrichir le catalogue CAT et sont rendus accessibles au niveau de la modélisation des connaissances (dans le catalogue CAT) et au niveau de la modélisation d’artefacts (ActionType ACT, Data Type DAT).

Efn objet connecté sophistiqué constitué d’un ensemble de capteurs ou d’actionneurs peut par ailleurs être considéré comme une ressource composite.

On se réfère maintenant à la figure 4 pour décrire un exemple de structure d’un dispositif au sens de l’invention. Il s’agit d’un dispositif communiquant DIS, de type objet connecté, et comportant une interface de communication COM via un réseau étendu NW (par exemple l’internet des objets), pour une communication avec d’autres objets connectés OBJ2 afin de fournir un service enrichi par exemple, et/ou encore avec un serveur central SV pilotant une flotte d’objets connectés par exemple. L’interface de communication COM est reliée à un circuit de traitement de données incluant un processeur PROC apte à coopérer avec une mémoire de travail MEM, laquelle mémoire MEM est capable de stocker des instructions de programme informatique selon rinvention. Dans l’exemple illustré, le dispositif DIS comporte un tel processeur et la mémoire précitée. Dans une variante, le dispositif connecté peut être relié via le réseau NW à un tel processeur PROC et la mémoire MEM, prévus alors dans le serveur SV par exemple.

Le processeur peut être relié en outre à une interface homme/machine pour permettre à un utilisateur d’entrer des données de services souhaités, ces données étant alors interprétées par le modèle de reconnaissances décrit ci-avant en référence à la figure 3. Le processeur peut être relié en outre à un capteur CAP via une interface INI pour recevoir des données mesurées par le capteur (par exemple de température ou autre) et dont le type de données est défini par le modèle d’artéfacts en lien avec chaque service prévu et impliquant un fonctionnement du capteur. Le processeur peut être relié en outre à un actionneur ACTI (par exemple un appareil de chauffage ou une commande de fermeture/ouverture de stores, ou autres) via une interface IN2 pour émettre des consignes de fonctionnement de l’actionneur. Ces consignes sont définies selon des types d’action par le modèle d’artéfacts en lien avec chaque service prévu et impliquant le fonctionnement de l’actionneur ACTI. Une fois un service sélectionné, au moins un type de données DAT et au moins un type d’action ACT sont aussi répertoriées par le modèle de ressources pour la mise en œuvre du service sélectionné.

Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ciavant à titre d’exemple ; elle s’étend à d’autres variantes.

Par exemple, précédemment, il a été présenté séparément deux cas de navigation correspondant à la mise en place d’un nouveau service et à l’ajout d’un nouvel objet connecté dans la maison intelligente. Il peut néanmoins arriver qu’ils soient combinés, la mise en place d’un service entraînant l’ajout d’un ou plusieurs objets connectés ou, inversement, l’ajout d’un nouvel objet connecté permettant la mise en place d’un ou plusieurs services.

Par ailleurs, l’arrêt d’un service ou le retrait d’un objet connecté constituent deux autres cas de navigation.

Enfin, les autres mises à jour du « répertoire de la maison » (Home Repository) telles que l’agrandissement de la maison (ajout d’une pièce, élément de modélisation Room) ou de la famille (une naissance, élément de modélisation INH) constituent des points d’entrée dans le niveau de modélisation de ressources qui impactent également les autres niveaux de modélisation.

Claims (11)

1. REVENDICATIONS

   1. Dispositif communiquant, de type objet connecté, relié à un circuit de traitement comprenant au moins un processeur (PROC) coopérant avec une mémoire (MEM) apte à stocker des instructions d’un programme informatique pour piloter le fonctionnement de l’objet connecté lorsque lesdites instructions sont exécutées par le processeur, caractérisé en ce que le programme informatique est structuré selon trois couches applicatives basées respectivement sur :

   - un modèle de ressources définissant des fonctionnalités de bas niveau de l’objet connecté pour opérer au moins un service choisi (SER),

   - un modèle d’artéfacts définissant un ou plusieurs services, parmi lesquels au moins un service est sélectionnable en tant que service choisi (SER), et

   - un modèle de connaissances définissant des règles d’opération (REG, NEG, PRD) de chacun desdits services, le modèle d’artéfacts établissant un lien entre les règles associées à chaque service et les fonctionnalités pour opérer ce service.
2. 2. Dispositif selon la revendication 1, caractérisé en ce qu’il comporte une interface de communication via un réseau étendu, adaptée pour connecter le dispositif avec au moins un deuxième objet connecté, en ce que ledit service choisi est opéré par une interaction entre le dispositif et le deuxième objet connecté, et en ce que le modèle d’artéfacts définit un service opérable par un objet connecté virtuel, référencé dans le modèle de ressources en tant qu’objet composite apte à opérer des fonctionnalités à la fois du dispositif et du second objet connecté.
3. 3. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le modèle d’artéfacts définit, pour chaque service, un ou plusieurs modes de fonctionnement (MOD) de l’objet connecté pour opérer ce service.
4. 4. Dispositif selon l’une des revendications précédentes, caractérisé en ce que, le dispositif étant connecté à au moins un capteur (CAP), le modèle d’artéfacts définit, pour chaque service, au moins un type de données à mesurer par le capteur (DAT) pour opérer le service.
5. 5. Dispositif selon Tune des revendications précédentes, caractérisé en ce que, le dispositif étant connecté à un actionneur (ACT), le modèle d’artéfacts définit, pour chaque service, au moins un type d’action à effectuer par T actionneur (DAT) pour opérer le service.
6. 6. Dispositif selon Tune des revendications précédentes, caractérisé en ce que le modèle d’artéfacts définit, pour chaque service, un cycle de vie (DV) propre à ce service.
7. 7. Dispositif selon Tune des revendications précédentes, caractérisé en ce que le modèle d’artéfacts définit, pour chaque service, un modèle d’information (INFM) propre à ce service.
8. 8. Dispositif selon Tune des revendications précédentes, caractérisé en ce que le modèle de connaissances est de type sémantique et enrichi par des données entrées par un utilisateur via une interface homme/machine (IHM) à laquelle est connecté le dispositif.
9. 9. Dispositif selon Tune des revendications précédentes, caractérisé en ce que le modèle de connaissances définit au moins des règles métier (REG) pour opérer un service.
10. 10. Dispositif selon la revendication 9, caractérisé en ce que le modèle de connaissances définit en outre des règles de médiation (NEG) pour un service issu d’une combinaison de services, selon une politique (POL) de règles prédéterminées.
11. 11. Programme informatique pour piloter le fonctionnement d’un objet connecté lorsque lesdites instructions sont exécutées par un processeur que comporte l’objet connecté, caractérisé en ce que le programme informatique est structuré selon trois couches 5 applicatives basées respectivement sur :

    - un modèle de ressources définissant des fonctionnalités de bas niveau de l’objet connecté pour opérer au moins un service choisi (SER),

    - un modèle d’artéfacts définissant un ou plusieurs services, parmi lesquels au moins un service est sélectionnable en tant que service choisi (SER), et

    10 - un modèle de connaissances définissant des règles d’opération (REG, NEG, PRD) de chacun desdits services, le modèle d’artéfacts établissant un lien entre les règles associées à chaque service et les fonctionnalités pour opérer ce service.

    1/2