Brevet FR3152694A1 — publié le 20250307

Il est proposé un système de gestion de services pour une maison intelligente doté de capteurs et d’actionneurs, ainsi qu’un procédé, un programme informatique et un support d’enregistrement correspondants. Un module de représentation de connaissances stocke pour chaque service des jeux d’informations relatifs à des instants spécifiques, ainsi que des règles prédéterminées. Un module de proposition d'états, divisé entre un raisonneur et un module d’apprentissage automatique, est instancié pour chaque service. Le raisonneur applique des règles prédéterminées pour déterminer une proposition de valeur d'état de l'actionneur. Optionnellement, un raisonneur distinct applique des règles extraites pour déterminer une autre proposition. Le module d’apprentissage automatique utilise l'inférence pour formuler une autre proposition. Un décideur sélectionne une valeur d'état finale de l'actionneur sur la base des propositions. Figure de l’abrégé : Figure 1 Système et procédé de gestion de services pour une maison intelligente La présente divulgation concerne la maison intelligente et plus particulièrement un système et un procédé de gestion de services pour une maison intelligente, ainsi qu’un programme informatique et un support d’enregistrement non transitoire correspondants. La maison intelligente désigne une habitation équipée d’un ensemble de dispositifs connectés et d’une interface de commande proposant des services. Les dispositifs connectés peuvent par exemple inclure des éclairages, des appareils électroménagers, des stores et/ou volets, des équipements de chauffage et/ou de climatisation, des systèmes d’alarme, etc. La mise en œuvre des services implique une commande des dispositifs connectés afin d’automatiser des tâches normalement réalisées par les utilisateurs, ou habitants. Pour l’automatisation des tâches, il existe deux catégories principales d’approches. Les approches basées sur les connaissances permettent de créer des services en établissant une liste de règles, telles que des règles "if-then". Les services créés peuvent être explicables en montrant aux utilisateurs dans quelles situations certains propositions sont faites. Par exemple, [1] propose une plate-forme appelée Midgar, composée de plusieurs couches : couche de définition des processus, couche de génération de services, couche de processeur et de gestionnaire d'objets, et couche d'objets, afin de créer des services. [2] propose un système de maison intelligente à deux niveaux : bas et haut niveaux, où le bas niveau comprend l'exécution de divers dispositifs, et le haut niveau comprend la modélisation du système, la transformation des règles et le raisonnement du système, de manière à créer des services. Néanmoins, le principal inconvénient de ce type d'approche est l'existence de conflits lorsque plusieurs services font des propositions différentes. En outre, la création de services est manuelle et peut devenir complexe lorsque le nombre de services concernés est élevé. Enfin, les services créés sont statiques et ne peuvent pas évoluer pour s'adapter à l'environnement changeant et aux préférences des habitants. Les approches dirigées par les données constituent une autre catégorie principale d'approches pour la création de services de maison intelligente. Les services créés font des propositions grâce à l'analyse et à l'interprétation des données. En outre, les méthodes d'apprentissage automatique qui apprennent à partir des données et font des prédictions sur cette base sont à l'avant-garde de la prise de décision dirigée par les données [3]. Les services créés peuvent faire des propositions dynamiques pour s'adapter aux préférences de l'habitant après avoir pris en compte l'environnement. Par exemple, [4] propose un cadre d'apprentissage d'un modèle de situation pour libérer les habitants de la conception manuelle de services de maison intelligente. Ce modèle vise à fournir des services contextuels dans un environnement intelligent. [5] propose un système appelé ACHE qui contrôle la température, le chauffage et l'éclairage sans programmation préalable par l'habitant, et ce système vise à économiser les ressources énergétiques tout en respectant le comportement habituel de l'habitant. Cependant, l'inconvénient majeur des approches dirigées par les données, ou plus spécifiquement des approches d'apprentissage automatique, est que les services créés doivent faire face à une phase d'apprentissage et manquent d'explicabilité. Des tentatives d’hybridation de ces deux approches ont été menés. Par exemple, [6] propose une approche basée sur un réseau neuronal et des règles prédéfinies pour un système de maison intelligente, en utilisant des règles prédéfinies pour contrôler le système tout en collectant des données et en entraînant ensuite le réseau neuronal. Une fois que le réseau neuronal peut garantir une plus grande efficacité, le système passe à l'utilisation du réseau neuronal. L'étude [7] repose sur un principe similaire. Toutefois, ces deux travaux n'expliquent pas comment garantir que les règles prédéfinies peuvent couvrir toutes les situations possibles de l'environnement. En outre, lorsque seuls des services basés sur des données sont utilisés, les services créés ne sont pas explicables. Il existe un besoin pour une approche applicable à la gestion de services pour une maison intelligente et permettant de surmonter les inconvénients évoqués. Résumé La présente divulgation vient améliorer la situation. Il est proposé un système de gestion de services pour une maison intelligente comprenant une pluralité de capteurs et d’actionneurs, le système de gestion de services comprenant : un module de représentation de connaissances configuré pour stocker, pour chaque service : une série de jeux d’informations associés au service, chaque jeu correspondant à un instant « t » respectif et incluant au moins une donnée d’un capteur et une valeur d’état d’un actionneur, le cas échéant, une ou plusieurs règles prédéterminées, chaque règle permettant de déduire, sur la base d’un jeu d’informations à l’instant « t », une proposition de valeur d’état de l’actionneur à l’instant « t+1 », un module de proposition d’états instancié par service, comprenant : un raisonneur, activé pour les services ayant une règle prédéterminée, configuré pour recevoir un jeu d’informations courantes associé au service pour déterminer une première proposition de valeur d’état pour l’actionneur en appliquant la règle prédéterminée associée au service, un module d’apprentissage automatique configuré pour opérer sur le jeu d’informations courantes pour déterminer, par inférence, une deuxième proposition de valeur d’état pour l’actionneur, et un décideur configuré pour déterminer, à partir des propositions du module de proposition d’états, une valeur d’état finale à utiliser pour l’actionneur. Il est également proposé un procédé de gestion de services pour une maison intelligente équipée d'une pluralité de capteurs et d'actionneurs, le procédé comprenant les étapes consistant à : stocker, pour chaque service, dans un module de représentation de connaissances, une série de jeux d’informations associés au service, chaque jeu correspondant à un instant « t » respectif et incluant au moins une donnée d’un capteur et une valeur d’état d’un actionneur, le cas échéant, une ou plusieurs règles prédéterminées, chaque règle permettant de déduire, sur la base d’un jeu d’informations à l’instant « t », une proposition de valeur d’état de l’actionneur à l’instant « t+1 », pour un service ayant une règle prédéterminée, recevoir avec un raisonneur un jeu d’informations courantes associé au service et déterminer une première proposition de valeur d’état pour l’actionneur en appliquant la règle prédéterminée associée au service, utiliser un module d’apprentissage automatique pour opérer sur le jeu d’informations courantes et déterminer, par inférence, une deuxième proposition de valeur d’état pour l’actionneur, et déterminer, à partir des propositions obtenues, avec un décideur, une valeur d’état finale à utiliser pour l’actionneur. Il est également proposé un programme informatique comportant des instructions pour la mise en œuvre de ce procédé lorsque ce programme est exécuté par un processeur. Il est également proposé un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré le programme informatique. Le système, le procédé, le programme informatique et le support d’enregistrement présentent notamment les avantages suivants. De manière générale, la combinaison des caractéristiques du système et du procédé permettent de garantir une continuité de service, assurant que les actionneurs fonctionnent de manière optimale même en présence de conflits ou de lacunes dans les services ayant une ou plusieurs règles prédéterminées. Par ailleurs, l’intégration du raisonneur permet d’offrir une grande transparence dans la prise de décision, donnant aux utilisateurs une vision claire des raisons pour lesquelles certaines actions ont été recommandées. Enfin, l’intégration du module d’apprentissage automatique permet d’adapter avec fluidité les services en fonction des modifications de l'environnement et des besoins individuels des utilisateurs, garantissant ainsi une expérience utilisateur constamment optimisée. Cela réduit aussi considérablement la charge des utilisateurs en éliminant la nécessité d'une configuration manuelle fastidieuse. Le système évoqué peut optionnellement comporter une ou plusieurs des caractéristiques suivantes, seules ou combinées entre elles. L’homme du métier comprendra évidemment que ces caractéristiques peuvent aussi être formulées en tant qu’étapes du procédé évoqué. Le système peut comprendre un module d’extraction de règles configuré pour extraire de nouvelles règles liées au fonctionnement du module d’apprentissage automatique, et à des services respectifs, sur la base de données accumulées issues des capteurs et de comportements antérieurs des actionneurs. Le module de représentation de connaissances peut être également configuré pour stocker les règles extraites. Le module de proposition d’états peut en outre comprendre un raisonneur distinct pour les règles extraites, activé pour les services ayant une règle extraite, configuré pour recevoir le jeu d’informations courantes pour déterminer une troisième proposition de valeur d’état pour l’actionneur en appliquant la règle extraite associée au service. Cela permet une mise à jour dynamique des règles sans intervention manuelle, s'assurant que le système est toujours à jour avec les besoins et les comportements changeants des utilisateurs. Le module d’extraction de règles peut être configuré pour ajouter ou supprimer des règles extraites sur la base de critères prédéfinis. Cette gestion adaptative des règles permet d'ajuster et d'optimiser le système en fonction de l'efficacité des règles, garantissant que seules les règles les plus pertinentes sont conservées. Le système peut être configuré pour mettre à jour périodiquement les règles extraites en fonction de tendances récentes observées dans les données des capteurs ou les valeurs d’état des actionneurs. Cela garantit que le système ne devient pas obsolète et répond toujours aux besoins actuels des utilisateurs. Le système peut comprendre en outre un distributeur de services configuré pour obtenir, au fil du temps, des données issues des capteurs et des valeurs d’état des actionneurs, organiser les données et les valeurs d’état en jeux d’informations et associer chaque jeu d’informations à un service respectif. Cela optimise l'efficacité opérationnelle du système, garantissant que chaque service est traité avec les données les plus pertinentes et actuelles. Le distributeur de services peut être également configuré pour initier, avec le module de représentation de connaissances, une création d’une nouvelle instance de service. Cela assure que le système peut évoluer avec les besoins changeants de la maison intelligente et avec les ajouts, les remplacements ou encore les mises à jour logicielles et/ou matérielles des équipements connectés qui y sont installés. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 FIG. 1 représente un système de gestion de services destiné à une maison intelligente dans un exemple de réalisation. Fig. 2 FIG. 2 représente un circuit de traitement de données convenant pour la mise en œuvre d’un procédé de gestion de services destiné à une maison intelligente dans un exemple de réalisation. Dans la description qui va suivre, des chiffres de référence identiques désignent des éléments identiques ou ayant des fonctions similaires. Un exemple particulier de réalisation est à présent décrit. FIG. 1 représente schématiquement la structure d’un système (100) de gestion de services destiné à une maison intelligente comprenant un ensemble de dispositifs connectés (200) intégrant des capteurs (202) et des actionneurs (204) placés dans un environnement d’un utilisateur. Ce système de gestion est distinctif de par son approche hybride combinant une approche basée sur les connaissances et une autre dirigée par les données. Le système se compose principalement de modules orchestrés par des moyens informatiques, qu’ils soient logiciels ou matériels. Le cœur du système est constitué de trois modules principaux : un module (120) de représentation des données, un module (130) de proposition d'états, et un décideur (140). Le module de représentation des données stocke de manière organisée des règles et informations nécessaires au fonctionnement du module de proposition d’états. Il peut notamment comprendre un module d’ontologie (124) configuré pour stocker des informations en provenance des capteurs et des valeurs d’état des actionneurs. Ces informations et valeurs d’état correspondent à des instants « t » ou à des intervalles de temps [t ; t+1[ et peuvent être organisées en jeux d’informations respectivement associés à des services. Lorsqu’une même information est utile à la mise en œuvre de plusieurs services, elle peut être dupliquée afin que chacun de ces services soit associé à un jeu d’informations la comprenant. Le module de représentation des données comprend également un ou plusieurs modules (122, 126) de stockage de règles prédéfinies associées à des services spécifiques. Le module de proposition d'états émet des propositions de valeurs d’état pour les actionneurs. Dans un exemple d’implémentation, pour chaque service distinct géré par le système, une instance unique du module de proposition d'états est créée, lui permettant d'opérer spécifiquement sur les données et règles associées à ce service en particulier. Le décideur joue un rôle d’arbitrage, prenant des décisions basées sur les propositions fournies par le module de proposition d'états. De manière optionnelle, le système peut également intégrer un distributeur de services (110). Sa principale responsabilité est d’acheminer vers le module de représentation de données les informations en provenance des capteurs, après les avoir associées à des services spécifiques. Le distributeur de services facilite ainsi l'organisation des données au sein du module de représentation de données et leur traitement par le module de proposition d’états. Alternativement, dans certaines configurations, le rôle du distributeur peut, en partie ou en totalité, être assumé par les dispositifs connectés eux-mêmes et/ou par une plateforme tierce. Le module de proposition d'états se démarque par la présence d'au moins un raisonneur s'appuyant sur les règles prédéfinies stockées par le module de représentation des données et d’un module d'apprentissage automatique (134) s’appuyant sur les données issues des capteurs et sur les valeurs d’état des actionneurs. Les tests montrent que l'utilisation de ces deux éléments conjointement offre des performances supérieures par rapport à un système qui ne s'appuierait que sur l'apprentissage automatique sans l'intégration de règles prédéfinies. De manière optionnelle, mais hautement bénéfique pour les performances du système, le module de proposition d’états intègre deux raisonneurs distincts, le premier (132) traitant des règles dites « existantes », c’est-à-dire fixées au préalable, par exemple par un utilisateur du système, et le second (136) traitant des règles extraites, liées au fonctionnement du module d’apprentissage automatique sur la base de données accumulées issues des capteurs et de comportements antérieurs des actionneurs. Ces règles existantes et extraites peuvent être stockées séparément au niveau du module de représentation des données, par exemple dans un module de stockage de règles existantes (122) et un module de stockage de règles extraites (126). Le fonctionnement du raisonneur traitant les règles extraites impose la mise en place et l’activation d’un mécanisme d'extraction de ces règles. Il est à noter qu'à certains moments, notamment au début du processus d'apprentissage, le mécanisme d'extraction de règles peut être actif sans disposer de règles extraites. Dans ce scénario, le raisonneur de règles extraites ne pouvant pas fournir de propositions, le fonctionnement du module de proposition d’états serait semblable à une configuration ne comportant qu’un unique raisonneur et le module d'apprentissage automatique. Dans le cadre d'une optimisation des propositions, le système de gestion peut intégrer un gestionnaire (150) de règles extraites, comprenant notamment un module (152) d'extraction de règles et un module (154) de suppression de règles. Ce gestionnaire permet d’actualiser et affiner les règles au fil du temps, permettant au système d'évoluer et de s'adapter à de nouvelles situations ou préférences des habitants. Le processus de fonctionnement général du système de gestion de services au cours d’une itération de fonctionnement quelconque s'articule comme suit. Initialement et pour un instant courant, les dernières données observées, c’est-à-dire les valeurs d’état courantes des actionneurs et les informations courantes issues des capteurs, sont transmises au distributeur de services, qui identifie et sélectionne les capteurs et actionneurs pertinents pour chaque service. Ce distributeur transmet ensuite ces valeurs d’état courantes et informations courantes au module d’ontologie au sein du module de représentation de données, afin de mettre à jour les données associées. Occasionnellement, le distributeur de services peut indiquer au module d'ontologie la nécessité de créer de nouvelles instances pour les actionneurs, pour les capteurs ou même pour les services. L'ontologie actualisée, contenant les dernières données observées, est alors transmise au module d'apprentissage automatique du module de proposition d'états. Avant de formuler des propositions d'états pour les actionneurs, le module d’apprentissage automatique calcule des récompenses pour l'itération précédente et initie son entraînement. Les récompenses sont communiquées aux modules d'extraction et de suppression de règles du gestionnaire de règles pour décider de l'opportunité d'extraire ou de supprimer certaines règles se rapportant aux activités de l'itération précédente. Les règles extraites récemment, ainsi que les valeurs d'état du module d’ontologie, sont transmises au raisonneur de règles extraites du module de proposition d'états. Parallèlement, les règles existantes, qui sont par exemple prédéfinies et immuables sauf par intervention utilisateur, sont envoyées avec les valeurs d'état au raisonneur de règles existantes du module de proposition d’états. Le raisonneur de règles extraites, le module d’apprentissage automatique et le raisonneur de règles existantes élaborent en parallèle et pour chaque service supporté des propositions de valeurs d'état pour les actionneurs concernés. Ces propositions sont ensuite dirigées vers le décideur, qui détermine les valeurs d'état finales pour les actionneurs. De surcroît, le décideur transmet des informations aux modules d'extraction et de suppression de règles pour leur indiquer lesquels des états finaux des actionneurs ont été adoptés et par quels mécanismes. Les états déterminés sont relayés aux actionneurs. Tout changement d'état peut influencer les états surveillés. L'utilisateur dispose de deux options pour exprimer sa réaction. Premièrement, il peut modifier directement les états des actionneurs pour signifier un mécontentement. Deuxièmement, il a la possibilité de définir des valeurs cibles pour les états surveillés, ces dernières pouvant également être préconfigurées. Après leur mise à jour, les états des actionneurs sont à nouveau acheminés au distributeur de services, de même que les valeurs les plus récentes issues des capteurs, ce qui marque le début d'une nouvelle itération. Dans ce nouveau cycle, le module d’apprentissage automatique recalcule les récompenses pour la précédente itération. Avec ces récompenses et les informations fournies par le décideur lors de la précédente itération, de nouvelles règles peuvent être extraites ou des règles existantes supprimées. Les règles nouvellement extraites sont stockées dans la base de données du module de représentation de données, tandis que d'autres peuvent être retirées. Un exemple de fonctionnement des différents modules du système de gestion de services est à présent détaillé. Après avoir introduit la terminologie et le modèle général du système, le fonctionnement détaillé du distributeur de services est à présent décrit dans un exemple de réalisation. Conçu spécifiquement pour les services de maison intelligente, le distributeur de services permet de sélectionner les états observables associés aux services en question, tels que les états des actionneurs et les valeurs issues des capteurs. Le distributeur de services a deux fonctions principales: premièrement, il offre une visualisation optimisée des composants associés aux services, et deuxièmement, il signale au module d'ontologie quand de nouvelles instances pour les capteurs, les actionneurs et certains types de services sont nécessaires. Cette situation se produit en particulier lorsque de nouveaux composants sont ajoutés à la maison intelligente et que ces capteurs enregistrent des valeurs distinctes de zéro. Pour chaque service noté « z », le distributeur utilise un modèle de données noté « ztype,id » représenté par un tuple noté contenant cinq éléments indiquant respectivement l’identifiant unique du service, le type du service, l'emplacement, l'état surveillé, et la liste des dispositifs, actionneurs et/ou capteurs associés au service. Un exemple de tuple pourrait être . En outre, des modèles basés sur les données, noté dtype,id, peuvent être établis pour les actionneurs et les capteurs. Le modèle basé sur les valeurs d’état des actionneurs peut être représenté par une notation du type {id, type, location, W, Z, Sz,t, st}, et le modèle basé sur les données d'un capteur peut être représenté par une notation du type {id, type, location, W, Z, st}. Dans ces modèles, les éléments notés « id », « type » et « location » peuvent être interprétés de la même manière que pour les services. Cependant, ils se rapportent ici à l’actionneur ou au capteur spécifique considéré, et non au service. Ces modèles ont pour rôle de garder une trace des valeurs fonctionnelles et opérationnelles des dispositifs. L'élément « W » archive les valeurs possibles qu'un dispositif peut adopter. Par exemple, une fenêtre peut avoir des états possibles représentés par W = {0, 1} où 0 indique que la fenêtre est fermée et 1 qu’elle est ouverte. L'élément « Z » liste tous les services associés au dispositif actuel. En poursuivant l’exemple de la fenêtre, celle-ci pourrait être liée à un service de qualité de l'air identifié par « zair,1 » et à un service de régulation de température identifié par « ztemperature,2 ». Ainsi, Z serait représenté par Z = {zair,1, ztemperature,2}. L'élément « Sz,t » détaille l'état suggéré par un service spécifique « z » pour un dispositif à un instant « t ». Pour illustrer, considérons que Sz,t = {Sair,t = {1}, Stemperature,t = {0}} pour une fenêtre. Cette notation indique qu'à un instant t, un service de qualité de l'air propose d'ouvrir la fenêtre (valeur 1), tandis qu'un service de température suggère de la garder fermée (valeur 0). Enfin, l’élément « st » représente l'état actuel du dispositif à un instant « t ». Dans le cas de la fenêtre, si st = 0, cela signifie que la fenêtre est actuellement fermée à cet instant précis. Le fonctionnement détaillé du gestionnaire de règles extraites est à présent décrit dans un exemple de réalisation. Le rôle principal du gestionnaire de règles extraites est de mettre à jour les règles extraites dans le module de représentation des connaissances. Il est conçu pour répondre à la dynamique des maisons intelligentes. Pour accomplir cela, il prend en compte deux éléments essentiels : les propositions d'état du module d’intelligence artificielle à l’instant « t-1 » et la récompense évaluée à l’instant « t », qui reflète les réactions de l'utilisateur face aux propositions d'état émises précédemment. En se basant sur ces deux informations, le gestionnaire de règles extraites peut soit extraire de nouvelles règles, soit supprimer des règles précédemment extraites. Une règle extraite, ou plus généralement toute règle, peut être rédigée selon la structure suivante : « Si une certaine valeur observée x0 a une valeur spécifique, et/ou se situe dans une plage spécifique et/ou présente une moyenne donnée, alors un actionneur a0 prendra une valeur d’état particulière ». Plus généralement, une règle comporte deux parties : la condition « Si... » et la conclusion « alors... ». Une règle peut également être assortie d’une certaine fréquence d’occurrence. La condition est une condition d’application de la règle. Elle dépend ici des données actuelles d’un ou plusieurs capteurs et/ou des valeurs d'état d’un ou plusieurs actionneurs. La conclusion définit le résultat de l’application de la règle, ici une proposition de valeur d’état particulière pour au moins un actionneur. Des critères préétablis dictent l'extraction ou la suppression des règles. Ainsi, une règle peut être extraite si toutes les récompenses évaluées à l’instant courant sont positives. En revanche, une règle extraite ayant été appliquée à l’instant précédent « t-1 » peut être supprimée lorsque certaines conditions sont remplies, par exemple si une des récompenses évaluées à l’instant courant « t » s'avère négative. Un exemple de processus d'extraction de règles approprié peut être défini à partir des éléments suivants: les états d'entrée, notés « Xt-1 », obtenus à partir du module d'apprentissage automatique, les récompenses, notées « R t », qui représentent les réactions de l’utilisateur aux propositions d'états d'actionneurs faites à l’instant précédent « t-1 », les valeurs d’état finales des actionneurs, notés « A t-1 », déterminées à l’instant précédent « t-1 » par le décideur, une information, notée « Info t-1 », indiquant l’origine des propositions de valeurs d’état retenues par le décideur à l’instant précédent « t-1 » pour établir les valeurs d’état finales A t-1 , et les règles déjà extraites notées « GR t ». Dans cet exemple, une première vérification porte sur le fait que toutes les récompenses R t soient positives. Si toutes les récompenses sont positives, une deuxième vérification est menée : elle correspond à vérifier, à l’aide de l’information Info t-1 , si, parmi les valeurs d’états finales A t-1 , certaines avaient été proposées, pour un service donné, par le module d’apprentissage automatique à l’instant précédent « t-1 ». Si le résultat d’une de ces deux vérifications est négatif, alors aucune nouvelle règle n’est extraite. Si à l’inverse les résultats de la première puis de la deuxième vérification sont positifs, alors les états d’entrée X t-1 et les valeurs d’état finales A t-1 sont fournis en entrée du module d’extraction de règles (152) afin d’extraire une ou plusieurs règles et ainsi mettre à jour les règles GR t . Dans ce contexte, un exemple de module d’extraction de règles (152) adapté est l’extracteur PBRE (Pedagogic Based Rule Extractor) décrit dans [8]. De manière similaire, le processus de suppression des règles peut être défini par exemple à partir des éléments suivants : les règles déjà extraites notées « GR t », parmi les règles déjà extraites, celles notées « gr t-1 » dont l’application par le raisonneur de règles extraites à l’instant précédent « t-1 » a conduit à émettre des propositions d’états d’actionneurs, les récompenses associées « R t », et l’information « Info t-1 » indiquant l’origine des propositions de valeurs d’état retenues par le décideur à l’instant précédent « t-1 » pour établir les valeurs d’état finales A t-1 . Dans cet exemple, une première vérification porte sur le fait que toutes les récompenses R t soient positives. Si toutes les récompenses sont positives, alors aucune règle n’est effacée. Si au moins une des récompenses n’est pas positive, alors une deuxième vérification est menée : elle correspond à vérifier, à l’aide de l’information Info t-1 , si, parmi les valeurs d’états finales A t-1 , certaines avaient été proposées, pour un service donné, par le raisonneur pour les règles extraites à l’instant précédent « t-1 ». Si le résultat de cette deuxième vérification est négatif, alors aucune règle n’est effacée. Si à l’inverse le résultat de la deuxième vérification est positif, alors les règles gr t-1 sont effacées. Le fonctionnement détaillé du module de proposition d’états est à présent décrit dans un exemple de réalisation. Le ou les raisonneurs et le module d’apprentissage automatique forment des structures distinctes qui permettent chacune de définir des propositions de valeurs d’état pour les actionneurs afin de mettre en place des services. Isolément, ces structures peuvent être mises en œuvre de manière connue en soi. Un exemple de raisonneur adapté pour les règles prédéterminées est le raisonneur Pellet décrit dans [9]. Plusieurs exemples de modules d’apprentissage automatique adaptés sont décrits dans [10], et des résultats positifs ont été obtenus avec différentes architectures spécifiquement conçues pour gérer collectivement plusieurs services de maison intelligente, ou architectures SHOMA (pour « Smart HOme-based Multi-services Architectures », en anglais. Parmi celles-ci, les architectures EPbA et RSAbA décrites de manière détaillée dans ce même document [10] se sont révélées particulièrement adaptées. Un exemple de processus convenant pour décrire un fonctionnement d’un raisonneur de règles extraites est décrit ultérieurement dans le présent document. La raison d'être de cette séparation en structures distinctes est à présent décrite, suivie d'un aperçu du processus de proposition des valeurs d’états. Imaginons des scénarios où les valeurs d’état souhaitées sont facilement déterminables. Si quelqu'un veut obtenir une luminosité nulle dans une pièce, il est logique d'éteindre la lumière et de fermer les rideaux. Dans ce cas, il n'est pas nécessaire d'utiliser un module d’apprentissage automatique, qui nécessiterait un temps d’entraînement considérable, et le recours à un raisonneur capable d’appliquer des règles prédéterminées, existantes est préférable. Un avantage d’un tel raisonneur est l’explicabilité des décisions prises : un examen des règles prédéfinies permet à l’utilisateur de savoir dans quelle situation un service donné suggère certaines valeurs d’états pour certains actionneurs. Sur cette base, l’utilisateur peut éventuellement modifier les règles prédéterminées pour les adapter à ses préférences. Le raisonneur pour règles prédéfinies ne peut pas toujours couvrir toutes les situations possibles. En effet, les règles prédéfinies, en particulier celles fixées par les utilisateurs, peuvent être incomplètes ou conflictuelles. Par ailleurs, l’environnement, de même que les valeurs cibles d’état des actionneurs, peuvent évoluer dans le temps. Le module d’apprentissage automatique permet par nature de pallier ces inconvénients en fournissant systématiquement des propositions de valeurs d’état quelle que soit la situation en présence et quel que soit le service considéré. Il est possible d’utiliser, en tant que raisonneur pour règles prédéfinies, deux raisonneurs distincts afin de traiter différemment deux types de règles, celles dites « existantes » qui sont par exemple imposées à la conception du système ou fixées par les utilisateurs, et celles extraites qui sont issues d’une approche dirigée par les données, c’est-à-dire extraites au cours de l’entraînement du module d’apprentissage automatique. Les règles extraites sont indicatives de préférences supposées d’un utilisateur. Par exemple, pendant le processus d'apprentissage, le module d’apprentissage automatique peut parfois proposer au hasard des valeurs d’état pour les actionneurs, et ce processus d'exploration peut révéler des préférences d’un utilisateur qui était jusqu’alors inconnues car correspondant à des situations peu fréquentes. Bien que le module d’apprentissage automatique ait tendance à ignorer ces préférences supposées, précisément car peu fréquentes, il peut être utile de déterminer en parallèle, automatiquement, des règles extraites reflétant ces préférences et dont l’application est susceptible d’offrir les mêmes avantages d’explicabilité que pour des règles existantes. Une possibilité est alors de solliciter l’utilisateur pour confirmation, afin de n’adopter durablement ces règles extraites que si elles suggèrent des états d'actionneurs qui répondent effectivement aux préférences de l’utilisateur. Cette sollicitation peut être directe, sous la forme d’une requête accessible par une interface utilisateur, ou indirecte, sous la forme d’une surveillance des commandes manuelles des actionneurs par l’utilisateur. Une telle politique d’adoption durable des règles extraites permet au raisonneur pour règles extraites de générer des propositions de valeurs d’état généralement plus satisfaisantes pour les utilisateurs, en comparaison avec les propositions générées par le module d’apprentissage automatique. Un exemple simplifié de processus de proposition des valeurs d’état des actionneurs par les raisonneurs et le module d’apprentissage automatique peut être défini à partir des éléments suivants : les observations à l’instant courant « t », c’est-à-dire les informations courantes issues des capteurs et/ou les valeurs d’état courantes des actionneurs, notées « O t », les règles extraites mises à jour après avoir éventuellement effectué une extraction ou une suppression de règle à l’instant courant « t », notées « GR t », les règles existantes à l’instant courant « t », notées « ER t ». Dans cet exemple, le raisonneur pour les règles existantes applique les règles ER t aux observations O t pour déterminer des premières propositions de valeurs d’état courantes pour les actionneurs. Le module d’apprentissage automatique détermine des deuxièmes propositions de valeurs d’état courantes pour les actionneurs sur la base des observations O t . Le raisonneur pour les règles extraites filtre les observations O t , de manière à extraire des observations d’intérêt notées d t . Le raisonneur pour les règles extraites infère des troisièmes propositions de valeurs d’état courantes pour les actionneurs en appliquant les règles extraites GR t aux observations d’intérêt d t . Le processus d’extraction des observations d’intérêt et d’application des règles extraites peut se baser, en première approche, sur des valeurs ou plages de valeurs stipulées en tant que conditions d’application d’une ou plusieurs règles extraites GR t . Supposons par exemple que les observations courantes contiennent une mesure courante de température intérieure indique 15°C et que GR t contienne une unique règle, notée « Règle 1 », dont la condition est que la température intérieure soit inférieure à 18°C et dont la conclusion contienne une valeur d’état correspondant à une activation d’un appareil de chauffage. Dans cette situation, il peut être prévu d’extraire simplement la mesure courante de température intérieure en tant qu’observation d’intérêt et d’appliquer par suite la Règle 1 pour proposer d’activer l’appareil de chauffage. L’extraction des observations d’intérêt et l’application des règles extraites sont susceptibles de se complexifier lorsqu’un même ensemble d’observations courantes entre dans les conditions de plusieurs règles extraites. Il est donc nécessaire de prévoir, au sein du raisonneur pour les règles extraites, un mécanisme d’évitement de conflits afin de sélectionner une règle extraite à appliquer parmi plusieurs règles extraites candidates. Le mécanisme d’évitement de conflits peut se baser sur un ou plusieurs critères prédéfinis. Il est ainsi possible de comparer les observations O t avec les valeurs indiquées dans la condition de chacune des règles extraites candidates. Lorsqu’une condition spécifie une plage de valeurs, la moyenne de cette plage de valeurs peut par exemple être retenue pour les besoins de la comparaison. Cette comparaison peut s’effectuer par le calcul d’une valeur de similarité telle qu’un coefficient de corrélation produit-moment de Pearson. Une règle candidate dont la condition a la plus haute corrélation avec les observations courantes peut alors être privilégiée. Il peut toutefois arriver que plusieurs règles montrent une forte corrélation avec les observations courantes. Un critère supplémentaire peut être défini sur la base des conclusions des règles extraites qui peuvent être confrontées à un historique d’observations noté ( O i ... O t ) depuis un instant initial « i » jusqu’à l’instant courant « t » pour déterminer des fréquences d’occurrence. Une règle candidate dont la conclusion propose des valeurs d’état plus couramment observées dans le passé peut être considérée comme plus susceptible d’être le meilleur choix. La combinaison de ces deux critères prédéfinis – la corrélation avec les observations actuelles et la fréquence d'occurrence des valeurs d'état dans l'historique – forme un mécanisme robuste permettant sélectionner la règle la plus appropriée parmi les candidates. Cette approche assure que la règle choisie est non seulement pertinente à l'instant « t », mais aussi cohérente avec les observations antérieures. Les propositions de valeurs d’état issues, à l’instant courant « t », du module d’apprentissage automatique et, le cas échéant, du ou des raisonneurs sont transmises au décideur qui choisit les valeurs d’état finales pour l’instant courant parmi ces propositions. Un exemple de processus convenant pour décrire un fonctionnement du décideur est à présent décrit. Une hiérarchie de priorités peut être prédéfinie pour permettre au décideur de sélectionner à chaque instant les valeurs d’état parmi les propositions disponibles. Dans l’hypothèse où les règles existantes sont explicitement définies par les utilisateurs, il est judicieux que les propositions issues du raisonneur pour les règles existantes reçoivent la priorité maximale de manière à assurer la satisfaction des préférences des utilisateurs. Ainsi, lorsque, par exemple, le raisonneur pour les règles existantes propose de lever un volet roulant alors que le module d’apprentissage automatique propose, au même moment de le laisser baissé, le décideur opte pour lever le volet roulant par application de la hiérarchie de priorité. Il se peut que le raisonneur pour les règles existantes ne fournisse, à l’instant courant, aucune proposition de valeur d’état pour un actionneur donné. C’est le cas lorsque, compte tenu des observations courantes, les règles existantes susceptibles de s’appliquer ne spécifient dans leur conclusion aucune valeur d’état pour cet actionneur donné. Il se peut aussi que le raisonneur pour les règles existantes fournisse, à l’instant courant, plusieurs propositions contradictoires de valeurs d’état pour un même actionneur. Optionnellement, un mécanisme d’évitement de conflit peut être prévu pour hiérarchiser les règles existantes de manière à sélectionner une valeur d’état particulière pour cet actionneur tout en respectant au mieux les préférences des utilisateurs. Lorsque le raisonneur pour les règles existantes ne parvient pas à fournir une proposition de valeur d’état dépourvue de conflit à l’instant courant pour un actionneur donné, le décideur peut s’appuyer sur d’autres propositions. Il est proposé que dans cette situation, la priorité soit donnée aux propositions issues du raisonneur pour les règles extraites par rapport à celles issues du module d’apprentissage automatique. En effet, indépendamment des particularités du mécanisme d’extraction considéré, un avantage des propositions issues du raisonneur pour les règles extraites est leur explicabilité. Par ailleurs, le mécanisme d’extraction des règles tel que décrit précédemment prévoit, dans un mode de réalisation, qu’une règle ne soit extraite puis conservée qu’à la condition que l’utilisateur soit satisfait des valeurs d’état spécifiées dans sa conclusion. De plus, le raisonneur de règles extraites peut intégrer un mécanisme robuste d’évitement de conflit. Une conséquence de ces spécificités est que les règles extraites reflètent de manière fidèle la satisfaction de l’utilisateur, avec une plus grande précision que ne le permet le module d’apprentissage automatique. Cependant, il est difficile de s'assurer que les règles existantes comme extraites proposent des valeurs d’état pour tous les actionneurs quel que soit l'état de l'environnement. Ainsi, dans des situations où les raisonneurs ne fournissent aucune proposition vis-à-vis des valeurs d’état de certains actionneurs, il est proposé que le décideur sélectionne tout de même des valeurs d’état pour ces actionneurs, sur la base des propositions fournies par le seul module d’apprentissage automatique. Il est fait référence à FIG. 2 qui représente un circuit de traitement d’un appareil électronique tel qu’une tablette, un téléphone mobile, un ordinateur, une passerelle domestique, un serveur, une machine sur laquelle repose un service numérique décentralisé, etc... Le circuit de traitement (300) comprend un processeur (302) connecté à un dispositif de stockage de données (304) et à une interface de communication (306) filaire ou par ondes radioélectriques. L’appareil électronique peut être connecté en réseau, via l’interface de communication, à une pluralité d’objets ou équipements connectés dotés de capteurs ou d’actionneurs. Le dispositif de stockage de données stocke des instructions d’un programme informatique qui, lorsque le programme informatique est exécuté par le processeur, conduisent le processeur à mettre en œuvre les différents modules d’un système de gestion de service selon l’invention, tel que par exemple celui représenté en FIG. 1 . Le processeur peut en outre être capable de traiter des commandes reçues d’une interface utilisateur, par exemple d’une interface graphique ou vocale, notamment pour modifier des valeurs d’état des actionneurs et/ou ajouter, modifier ou supprimer des règles existantes ou des règles extraites. Le processeur peut en outre être capable de commander un dispositif de restitution d’informations, par exemple par affichage visuel, pour restituer des informations utiles à l’utilisateur telles que des mesures courantes issues des capteurs, des valeurs d’état courantes pour des actionneurs, et/ou des conditions de règles existantes ou extraites ayant conduit à l’application de valeurs d’état pour des actionneurs. Références bibliographiques [1] C. G. García et al., "Midgar: Generation of heterogeneous objects interconnecting applications. A Domain Specific Language proposal for Internet of Things scenarios," Computer Networks, pp. 143--158, 2014. [2] L. Mainetti et al., "A novel rule-based semantic architecture for IoT building automation systems," in 2015 23rd International Conference on Software, Telecommunications and Computer Networks (SoftCOM), 2015. [3] S. L. Brunton et al., "Data-driven science and engineering: Machine learning, dynamical systems, and control," Cambridge University Press, 2022. [4] O. Brdiczka et al., "Learning situation models in a smart home," IEEE Transactions on Systems, Man, and Cybernetics, Part B (Cybernetics), pp. 56--63, 2008. [5] M. C. Mozer, "The neural network house: An environment hat adapts to its inhabitants," in Proc. AAAI Spring Symp. Intelligent Environments, 1998, p. 58. [6] M. Woźniak et al., "Intelligent home systems for ubiquitous user support by using neural networks and rule-based approach," IEEE Transactions on Industrial Informatics, pp. 2651--2658, 2019. [7] D. A. Handelman et al., "Integrating neural networks and knowledge-based systems for intelligent robotic control," IEEE Control Systems Magazine, pp. 77--87, 1990. [8] M. Qiu et al. “PBRE: A Rule Extraction Method from Trained Neural Networks Designed for Smart Home Services”, Database and Expert Systems Applications. DEXA 2022. Lecture Notes in Computer Science, vol 13427. Springer, Cham. [9] E. Sirin et al. “Pellet: A practical owl-dl reasoner,” Journal of Web Semantics, vol. 5, no. 2, pp. 51–53, 2007. [10] M. Qiu, et al. "Reinforcement Learning Based Architectures for Dynamic Generation of Smart Home Services," 2022 21st IEEE International Conference on Machine Learning and Applications (ICMLA), Nassau, Bahamas, 2022, pp. 7-14. Système (100) de gestion de services pour une maison intelligente comprenant une pluralité de capteurs (202) et d’actionneurs (204), le système de gestion de services comprenant : un module (120) de représentation de connaissances configuré pour stocker, pour chaque service : une série de jeux d’informations associés au service, chaque jeu correspondant à un instant « t » respectif et incluant au moins une donnée d’un capteur et une valeur d’état d’un actionneur, le cas échéant, une ou plusieurs règles prédéterminées, chaque règle permettant de déduire, sur la base d’un jeu d’informations à l’instant « t », une proposition de valeur d’état de l’actionneur à un instant « t+1 », un module (130) de proposition d’états instancié par service, comprenant : un raisonneur (132), activé pour les services ayant une règle prédéterminée, configuré pour recevoir un jeu d’informations courantes associé au service pour déterminer une première proposition de valeur d’état pour l’actionneur en appliquant la règle prédéterminée associée au service, un module (134) d’apprentissage automatique configuré pour opérer sur le jeu d’informations courantes pour déterminer, par inférence, une deuxième proposition de valeur d’état pour l’actionneur, et un décideur (140) configuré pour déterminer, à partir des propositions du module de proposition d’états, une valeur d’état finale à utiliser pour l’actionneur. Système selon la revendication 1, comprenant également un module (150) d’extraction de règles configuré pour extraire de nouvelles règles liées au fonctionnement du module d’apprentissage automatique, et à des services respectifs, sur la base de données accumulées issues des capteurs et de comportements antérieurs des actionneurs, le module de représentation de connaissances est également configuré pour stocker les règles extraites, et le module de proposition d’états comprend en outre un raisonneur (136) distinct pour les règles extraites, activé pour les services ayant une règle extraite, configuré pour recevoir le jeu d’informations courantes pour déterminer une troisième proposition de valeur d’état pour l’actionneur en appliquant la règle extraite associée au service. Système selon la revendication 2, dans lequel le module d’extraction de règles est configuré pour ajouter ou supprimer des règles extraites sur la base de critères prédéfinis. Système selon la revendication 2 ou 3, configuré pour mettre à jour périodiquement les règles extraites en fonction de tendances récentes observées dans les données des capteurs ou les valeurs d’état des actionneurs. Système selon l’une des revendications 1 à 4, comprenant en outre un distributeur (110) de services configuré pour : obtenir, au fil du temps, des données issues des capteurs et des valeurs d’état des actionneurs, organiser les données et les valeurs d’état en jeux d’informations et associer chaque jeu d’informations à un service respectif. Système selon la revendication 5, dans lequel le distributeur de services est configuré pour initier, avec le module de représentation de connaissances, une création d’une nouvelle instance de service. Procédé de gestion de services pour une maison intelligente équipée d'une pluralité de capteurs (202) et d'actionneurs (204), le procédé comprenant les étapes consistant à : stocker, pour chaque service, dans un module (120) de représentation de connaissances, une série de jeux d’informations associés au service, chaque jeu correspondant à un instant « t » respectif et incluant au moins une donnée d’un capteur et une valeur d’état d’un actionneur, le cas échéant, une ou plusieurs règles prédéterminées, chaque règle permettant de déduire, sur la base d’un jeu d’informations à l’instant « t », une proposition de valeur d’état de l’actionneur à un instant « t+1 », pour un service ayant une règle prédéterminée, recevoir avec un raisonneur (132) un jeu d’informations courantes associé au service et déterminer une première proposition de valeur d’état pour l’actionneur en appliquant la règle prédéterminée associée au service, utiliser un module (134) d’apprentissage automatique pour opérer sur le jeu d’informations courantes et déterminer, par inférence, une deuxième proposition de valeur d’état pour l’actionneur, et déterminer, à partir des propositions obtenues, avec un décideur (140), une valeur d’état finale à utiliser pour l’actionneur. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 7 lorsque ce programme est exécuté par un processeur (300). Support d’enregistrement (304) non transitoire lisible par un ordinateur sur lequel est enregistré le programme informatique selon la revendication 8.