System and process for managing services for a smart home

Abstract

A service management system for a smart home with sensors and actuators is proposed, along with a corresponding process, computer program, and data storage medium. A knowledge representation module stores information sets for each service at specific times, as well as predetermined rules. A state proposal module, divided between a reasoner and a machine learning module, is instantiated for each service. The reasoner applies predetermined rules to determine a proposed state value for the actuator. Optionally, a separate reasoner applies extracted rules to determine an alternative proposal. The machine learning module uses inference to formulate another proposal. A decision-maker selects a final state value for the actuator based on the proposals. Abstract figure: Figure 1

Description

Title of the invention: System and method for managing services for a smart home Technical field

[0001] The present disclosure relates to the smart home and more particularly to a system and method for managing services for a smart home, as well as a corresponding computer program and non-transitory recording medium. Prior art

[0002] A smart home refers to a home equipped with a set of connected devices and a control interface offering services.

[0003] Connected devices may for example include lighting, household appliances, blinds and / or shutters, heating and / or air conditioning equipment, alarm systems, etc.

[0004] The implementation of services involves controlling connected devices in order to automate tasks normally carried out by users, or residents.

[0005] For task automation, there are two main categories of approaches.

[0006] Knowledge-based approaches allow creating services by establishing a list of rules, such as "if-then" rules. The created services can be explainable by showing users in which situations certain propositions are made. For example, [1] proposes a platform called Midgar, composed of several layers: process definition layer, service generation layer, processor and object manager layer, and object layer, in order to create services. [2] proposes a smart home system with two levels: low and high levels, where the low level includes the execution of various devices, and the high level includes system modeling, rule transformation, and system reasoning, so as to create services.However, the main disadvantage of this type of approach is the existence of conflicts when several services make different proposals. In addition, the creation of services is manual and can become complex when the number of services involved is large. Finally, the services created are static and cannot evolve to adapt to the changing environment and the preferences of the inhabitants.

[0007] Data-driven approaches are another main category of approaches for creating smart home services. The services created make suggestions through data analysis and interpretation. In addition, machine learning methods that learn from data and make Predictions based on this are at the forefront of data-driven decision making [3]. The services created can make dynamic proposals to adapt to the inhabitant's preferences after taking the environment into account. For example, [4] proposes a framework for learning a situation model to free residents from manually designing smart home services. This model aims to provide contextual services in a smart environment. [5] proposes a system called ACHE that controls temperature, heating, and lighting without prior programming by the inhabitant, and this system aims to save energy resources while respecting the habitual behavior of the inhabitant. However, the major drawback of data-driven approaches, or more specifically machine learning approaches, is that the created services must face a learning phase and lack explainability.

[0008] Attempts to hybridize these two approaches have been made.

[0009] For example, [6] proposes a neural network and predefined rule-based approach for a smart home system, using predefined rules to control the system while collecting data and then training the neural network. Once the neural network can ensure higher efficiency, the system switches to using the neural network. The study [7] is based on a similar principle.

[0010] However, these two works do not explain how to guarantee that the predefined rules can cover all possible situations in the environment. Furthermore, when only data-driven services are used, the created services are not explainable.

[0011] There is a need for an approach applicable to the management of services for a smart home and capable of overcoming the disadvantages mentioned. Summary

[0012] The present disclosure improves the situation.

[0013] There is provided a service management system for a smart home comprising a plurality of sensors and actuators, the service management system comprising: a knowledge representation module configured to store, for each service: a series of sets of information associated with the service, each set corresponding to a respective instant “t” and including at least one piece of data from a sensor and a state value from an actuator, where appropriate, one or more predetermined rules, each rule making it possible to deduce, on the basis of a set of information at time “t”, a proposition of state value of the actuator at time “t+1”, a state proposal module instantiated by service, including: a reasoner, enabled for services having a predetermined rule, configured to receive a set of current information associated with the service to determine a first state value proposition for the actuator by applying the predetermined rule associated with the service, a machine learning module configured to operate on the current information set to determine, by inference, a second state value proposition for the actuator, and a decision maker configured to determine, from the proposals of the state proposal module, a final state value to be used for the actuator.

[0014] Also provided is a method of managing services for a smart home equipped with a plurality of sensors and actuators, the method comprising the steps of: store, for each service, in a knowledge representation module, a series of information sets associated with the service, each set corresponding to a respective instant “t” and including at least one data item from a sensor and a state value from an actuator, where appropriate, one or more predetermined rules, each rule making it possible to deduce, on the basis of a set of information at time “t”, a proposition of state value of the actuator at time “t+1”, for a service having a predetermined rule, receiving with a reasoner a set of current information associated with the service and determining a first state value proposition for the actuator by applying the predetermined rule associated with the service, use a machine learning module to operate on the current information set and determine, by inference, a second state value proposition for the actuator, and determine, from the proposals obtained, with a decision maker, a final state value to use for the actuator.

[0015] Also provided is a computer program comprising instructions for implementing this method when this program is executed by a processor.

[0016] Also provided is a non-transitory computer-readable recording medium on which the computer program is recorded.

[0017] The system, the method, the computer program and the recording medium have in particular the following advantages.

[0018] Generally speaking, the combination of the characteristics of the system and the method make it possible to guarantee continuity of service, ensuring that the actuators operate perform optimally even in the presence of conflicts or gaps in services having one or more predetermined rules.

[0019] Furthermore, the integration of the reasoner makes it possible to offer great transparency in decision-making, giving users a clear vision of the reasons why certain actions have been recommended.

[0020] Finally, the integration of the machine learning module allows for seamless adaptation of services based on changes in the environment and individual user needs, ensuring a constantly optimized user experience. This also significantly reduces user burden by eliminating the need for tedious manual configuration.

[0021] The system mentioned may optionally comprise one or more of the following features, alone or in combination with each other. Those skilled in the art will obviously understand that these features may also be formulated as steps of the method mentioned.

[0022] The system may include a rule extraction module configured to extract new rules related to the operation of the machine learning module, and respective services, based on accumulated data from the sensors and prior behaviors of the actuators. The knowledge representation module may also be configured to store the extracted rules. The state proposal module may further include a separate reasoner for the extracted rules, activated for services having an extracted rule, configured to receive the current information set to determine a third state value proposition for the actuator by applying the extracted rule associated with the service.

[0023] This allows dynamic updating of rules without manual intervention, ensuring that the system is always up to date with changing user needs and behaviors.

[0024] The rule extraction module can be configured to add or remove extracted rules based on predefined criteria.

[0025] This adaptive rule management allows the system to be adjusted and optimized based on the effectiveness of the rules, ensuring that only the most relevant rules are retained.

[0026] The system may be configured to periodically update the extracted rules based on recent trends observed in sensor data or actuator state values.

[0027] This ensures that the system does not become obsolete and always meets current user needs.

[0028] The system may further comprise a service distributor configured to obtain, over time, data from the sensors and status values ​​of the ac- donors, organize data and state values ​​information stakes and associate each information set with a respective service.

[0029] This optimizes the operational efficiency of the system, ensuring that each service is processed with the most relevant and current data.

[0030] The service distributor may also be configured to initiate, with the knowledge representation module, a creation of a new service instance.

[0031] This ensures that the system can evolve with the changing needs of the smart home and with additions, replacements or even software and / or hardware updates of the connected equipment installed therein. Brief description of the drawings

[0032] Other characteristics, details and advantages will appear on reading the detailed description below, and on analyzing the attached drawings, in which: Fig.l

[0033] [Fig.l] represents a service management system intended for a smart home in an exemplary embodiment. Fig. 2

[0034] [Fig.2] represents a data processing circuit suitable for implementing a service management method intended for a smart home in an exemplary embodiment. Description of the embodiments

[0035] In the following description, identical reference numerals designate identical elements or elements having similar functions.

[0036] A particular example of embodiment is now described.

[0037] [Fig.l] schematically represents the structure of a service management system (100) intended for a smart home comprising a set of connected devices (200) integrating sensors (202) and actuators (204) placed in a user's environment.

[0038] This management system is distinctive in its hybrid approach combining a knowledge-based approach and a data-driven approach. The system consists mainly of modules orchestrated by computer means, whether software or hardware.

[0039] The core of the system consists of three main modules: a data representation module (120), a state proposal module (130), and a decision maker (140).

[0040] The data representation module stores in an organized manner rules and information necessary for the operation of the state proposal module. It may in particular comprise an ontology module (124) configured to store in formations from the sensors and the state values ​​of the actuators. This information and state values ​​correspond to instants "t" or to time intervals [t; t+l[ and can be organized into sets of information respectively associated with services. When the same information is useful for the implementation of several services, it can be duplicated so that each of these services is associated with a set of information comprising it. The data representation module also comprises one or more modules (122, 126) for storing predefined rules associated with specific services.

[0041] The state proposal module issues state value proposals for the actuators. In an exemplary implementation, for each distinct service managed by the system, a unique instance of the state proposal module is created, allowing it to operate specifically on the data and rules associated with that particular service.

[0042] The decision maker plays an arbitration role, making decisions based on the proposals provided by the state proposal module.

[0043] Optionally, the system may also integrate a service distributor (110). Its main responsibility is to route the information from the sensors to the data representation module, after associating it with specific services. The service distributor thus facilitates the organization of the data within the data representation module and its processing by the state proposal module. Alternatively, in certain configurations, the role of the distributor may, in part or in full, be assumed by the connected devices themselves and / or by a third-party platform.

[0044] The state proposal module is distinguished by the presence of at least one reasoner based on the predefined rules stored by the data representation module and a machine learning module (134) based on the data from the sensors and on the state values ​​of the actuators. Tests show that the use of these two elements together offers superior performance compared to a system which would only rely on machine learning without the integration of predefined rules.

[0045] Optionally, but highly beneficial for the performance of the system, the state proposal module integrates two separate reasoners, the first (132) processing so-called "existing" rules, i.e. rules set in advance, for example by a user of the system, and the second (136) processing extracted rules, linked to the operation of the automatic learning module on the basis of accumulated data from the sensors and previous behaviors of the actuators. These existing and extracted rules can be stored separately at the data representation module, for example in an existing rules storage module (122) and an extracted rules storage module (126).

[0046] The operation of the reasoner processing the extracted rules requires the implementation and activation of a mechanism for extracting these rules. It should be noted that at certain times, particularly at the beginning of the learning process, the rule extraction mechanism may be active without having extracted rules. In this scenario, since the extracted rule reasoner cannot provide proposals, the operation of the state proposal module would be similar to a configuration comprising only a single reasoner and the machine learning module.

[0047] As part of an optimization of the proposals, the management system can integrate a manager (150) of extracted rules, including in particular a module (152) for extracting rules and a module (154) for deleting rules. This manager makes it possible to update and refine the rules over time, allowing the system to evolve and adapt to new situations or preferences of the inhabitants.

[0048] The general operating process of the service management system during any operating iteration is as follows.

[0049] Initially and for a current instant, the last observed data, i.e. the current state values ​​of the actuators and the current information from the sensors, are transmitted to the service distributor, which identifies and selects the relevant sensors and actuators for each service. This distributor then transmits these current state values ​​and current information to the ontology module within the data representation module, in order to update the associated data.

[0050] Occasionally, the service distributor may indicate to the ontology module the need to create new instances for actuators, for sensors or even for services. The updated ontology, containing the latest observed data, is then transmitted to the machine learning module of the state proposal module.

[0051] Before formulating state proposals for the actuators, the machine learning module calculates rewards for the previous iteration and initiates its training. The rewards are communicated to the rule extraction and deletion modules of the rule manager to decide whether to extract or delete certain rules relating to the activities of the previous iteration.

[0052] The recently extracted rules, along with the state values ​​from the ontology module, are transmitted to the extracted rule reasoner of the state proposal module. At the same time, existing rules, which are for example predefined and immutable except by user intervention, are sent with the state values ​​to the existing rule reasoner of the state proposal module.

[0053] The extracted rules reasoner, the machine learning module and the existing rules reasoner develop in parallel and for each supported service state value proposals for the relevant actuators. These proposals are then directed to the decision maker, which determines the final state values ​​for the actuators. In addition, the decision maker passes information to the rule extraction and deletion modules to indicate which of the final states of the actuators have been adopted and by which mechanisms.

[0054] The determined states are relayed to the actuators. Any change in state can influence the monitored states. The user has two options for expressing his reaction. First, he can directly change the states of the actuators to indicate dissatisfaction. Second, he has the option of defining target values ​​for the monitored states, which can also be preconfigured.

[0055] After updating, the actuator states are sent back to the service distributor, along with the most recent values ​​from the sensors, marking the start of a new iteration. In this new cycle, the machine learning module recalculates the rewards for the previous iteration. With these rewards and the information provided by the decision maker in the previous iteration, new rules can be extracted or existing rules deleted. The newly extracted rules are stored in the database of the data representation module, while others can be removed.

[0056] An example of the operation of the different modules of the service management system is now detailed.

[0057] Having introduced the terminology and the general model of the system, the detailed operation of the service distributor is now described in an exemplary embodiment.

[0058] Designed specifically for smart home services, the service distributor allows you to select observable states associated with the services in question, such as actuator states and values ​​from sensors.

[0059] The service distributor has two main functions: first, it provides an optimized visualization of the components associated with the services, and second, it signals to the ontology module when new instances for sensors, actuators and certain types of services are needed. This situation occurs in particular when new components are added to the smart home and these sensors record values ​​other than zero.

[0060] For each service noted “z”, the distributor uses a data model noted “ztype,id” represented by a tuple noted <id, type, location, p, D> containing five elements indicating respectively the unique identifier of the service, the type of service, the location, the monitored state, and the list of devices, actuators and / or sensors associated with the service.

[0061] An example tuple could be <id:' 12345', type: 'Contrôle de la qualité de l’air', location: 'living room', p: 'air quality', D: '{air quality sensor, air purifier, fan, humidifier}'>.

[0062] Furthermore, data-based models, denoted dtype,id, can be established for actuators and sensors. The model based on the state values ​​of the actuators can be represented by a notation of the type {id, type, location, W, Z, Sz,t, st], and the model based on the data of a sensor can be represented by a notation of the type {id, type, location, W, Z, st}. In these models, the elements denoted "id", "type" and "location" can be interpreted in the same way as for services. However, here they relate to the specific actuator or sensor considered, and not to the service.

[0063] These models are used to keep track of the functional and operational values ​​of devices. The "W" element stores the possible values ​​that a device can adopt. For example, a window can have possible states represented by W = {0, 1} where 0 indicates that the window is closed and 1 that it is open. The "Z" element lists all the services associated with the current device. Continuing with the window example, it could be linked to an air quality service identified by "zair, 1" and a temperature control service identified by "ztemperature, 2". Thus, Z would be represented by Z = {zair, 1, ztemperature, 2}. The "Sz, t" element details the state suggested by a specific service "z" for a device at a time "t". To illustrate, consider that Sz,t = {Sair,t = {1}, Stemperature,t = {0}} for a window.This notation indicates that at time t, an air quality service suggests opening the window (value 1), while a temperature service suggests keeping it closed (value 0). Finally, the "st" element represents the current state of the device at time "t". In the case of the window, if st = 0, it means that the window is currently closed at that precise moment.

[0064] The detailed operation of the extracted rules manager is now described in an exemplary embodiment.

[0065] The main role of the extracted rules manager is to update the extracted rules in the knowledge representation module. It is designed to meet the dynamics of smart homes.

[0066] To accomplish this, it takes into account two essential elements: the state proposals of the artificial intelligence module at time "t-1" and the reward evaluated at time "t", which reflects the user's reactions to the state proposals previously issued. Based on these two pieces of information, the extracted rules manager can either extract new rules or delete previously extracted rules.

[0067] An extracted rule, or more generally any rule, can be written according to the following structure: “If a certain observed value xO has a specific value, and / or lies within a specific range and / or has a given average, then an actuator aO will take on a particular state value.

[0068] More generally, a rule has two parts: the condition "If..." and the conclusion "then...". A rule can also be accompanied by a certain frequency of occurrence.

[0069] The condition is a condition for applying the rule. Here it depends on the current data of one or more sensors and / or the state values ​​of one or more actuators.

[0070] The conclusion defines the result of the application of the rule, here a particular state value proposition for at least one actuator.

[0071] Pre-established criteria dictate the extraction or deletion of rules.

[0072] Thus, a rule can be extracted if all the rewards evaluated at the current time are positive. On the other hand, an extracted rule having been applied at the previous time "t-1" can be deleted when certain conditions are met, for example if one of the rewards evaluated at the current time "t" turns out to be negative.

[0073] An example of a suitable rule extraction process can be defined from the following: the input states, denoted “Xt-1”, obtained from the machine learning module, the rewards, noted “R,” which represent the user’s reactions to the actuator state proposals made at the previous instant “t-1,” the final state values ​​of the actuators, denoted “A,,” determined at the previous instant “t-1” by the decision maker, information, noted “lnfot l”, indicating the origin of the state value proposals retained by the decision-maker at the previous instant “t-1” to establish the final state values ​​At_], and the rules already extracted noted “GRt”.

[0074] In this example, a first check concerns the fact that all the rewards Rt are positive. If all the rewards are positive, a second check is carried out: it corresponds to checking, using the information Infot ], whether, among the final state values ​​Ahl, some had been proposed, for a given service, by the automatic learning module at the previous instant “t-1”. If the result of one of these two checks is negative, then no new rule is extracted. If, conversely, the results of the first and then the second check are positive, then the input states X, i and the final state values ​​A^ are provided as input to the rule extraction module (152) in order to extract one or more rules and thus update the rules GRt. In this context, an example of a suitable rule extraction module (152) is the PB RE extractor (Pedagogy Based Rule Extractor) described in [8].

[0075] Similarly, the process of deleting rules can be defined for example from the following elements: the rules already extracted noted “GRt”, among the rules already extracted, those noted "gr,," whose application by the reasoner of rules extracted at the previous instant "t-1" led to the emitting of proposals for actuator states, the associated rewards “Rt”, and the information “lnfot l” indicating the origin of the state value proposals retained by the decision maker at the previous instant “t-1” to establish the final state values ​​Ahl.

[0076] In this example, a first check is carried out on the fact that all the rewards Rt are positive. If all the rewards are positive, then no rule is deleted. If at least one of the rewards is not positive, then a second check is carried out: it corresponds to checking, using the information Infot i, whether, among the final state values ​​At.i, some had been proposed, for a given service, by the reasoner for the rules extracted at the previous instant "t-1". If the result of this second check is negative, then no rule is deleted. If, conversely, the result of the second check is positive, then the rules gr,, are deleted.

[0077] The detailed operation of the state proposal module is now described in an exemplary embodiment.

[0078] The reasoner(s) and the machine learning module form separate structures that each allow state value proposals to be defined for the actuators in order to implement services.

[0079] In isolation, these structures can be implemented in a manner known per se. An example of a suitable reasoner for predetermined rules is the Pellet reasoner described in [9]. Several examples of suitable machine learning modules are described in

[10] , and positive results have been obtained with different architectures specifically designed to collectively manage several smart home services, or SHOMA architectures (for "Smart HOme-based Multiservices Architectures", in English). Among these, the EPbA and RSAbA architectures described in detail in this same document

[10] have proven to be particularly suitable.

[0080] An example process suitable for describing an operation of an extracted rule reasoner is described later in this document.

[0081] The rationale for this separation into distinct structures is now described, followed by an overview of the process of proposing state values.

[0082] Let us imagine scenarios where the desired state values ​​are easily determined lousy. If someone wants to achieve zero brightness in a room, it makes sense to turn off the lights and close the curtains. In this case, there is no need to use a machine learning module, which would require considerable training time, and it is preferable to use a reasoner capable of applying predetermined, existing rules. One advantage of such a reasoner is the explainability of the decisions made: a review of the predefined rules allows the user to know in which situation a given service suggests certain state values ​​for certain actuators. Based on this, the user can optionally modify the predetermined rules to suit their preferences.

[0083] The reasoner for predefined rules cannot always cover all possible situations. Indeed, the predefined rules, in particular those set by users, may be incomplete or conflicting. Furthermore, the environment, as well as the target state values ​​of the actuators, may change over time. The machine learning module inherently makes it possible to overcome these drawbacks by systematically providing proposals for state values ​​regardless of the situation in question and regardless of the service considered.

[0084] It is possible to use, as a reasoner for predefined rules, two distinct reasoners in order to process two types of rules differently, those called "existing" which are for example imposed on the design of the system or set by the users, and those extracted which come from a data-driven approach, that is to say extracted during the training of the machine learning module.

[0085] The extracted rules are indicative of assumed preferences of a user. For example, during the learning process, the machine learning module may sometimes randomly propose state values ​​for the actuators, and this exploration process may reveal preferences of a user that were previously unknown because they correspond to infrequent situations. Although the machine learning module tends to ignore these assumed preferences, precisely because they are infrequent, it may be useful to determine in parallel, automatically, extracted rules reflecting these preferences and whose application is likely to offer the same advantages of explainability as for existing rules.

[0086] One possibility is then to solicit the user for confirmation, in order to only sustainably adopt these extracted rules if they suggest actuator states that actually meet the user's preferences. This solicitation can be direct, in the form of a query accessible by a user interface, or indirect, in the form of monitoring the manual commands of the actuators by the user. Such a policy of sustainable adoption of the extracted rules allows the reasoner for extracted rules to generate proposals for genera- significantly more satisfactory for users, compared to the proposals generated by the machine learning module.

[0087] A simplified example of the process of proposing actuator state values ​​by the reasoners and the machine learning module can be defined from the following elements: the observations at the current time “t”, i.e. the current information from the sensors and / or the current state values ​​of the actuators, noted “Ot”, the extracted rules updated after possibly having carried out an extraction or a deletion of a rule at the current time “t”, noted “GRt”, the rules existing at the current time “t”, noted “ER,”.

[0088] In this example, the reasoner for existing rules applies the rules ER, to the observations Ot to determine first current state value proposals for the actuators. The machine learning module determines second current state value proposals for the actuators based on the observations Ot. The reasoner for extracted rules filters the observations Ot, so as to extract observations of interest denoted dt. The reasoner for extracted rules infers third current state value proposals for the actuators by applying the extracted rules GRt to the observations of interest dt.

[0089] The process of extracting observations of interest and applying the extracted rules may be based, as a first approach, on values ​​or ranges of values ​​stipulated as conditions for applying one or more extracted rules GRt.

[0090] Suppose for example that the current observations contain a current indoor temperature measurement indicating 15°C and that GRt contains a single rule, noted “Rule 1”, the condition of which is that the indoor temperature is less than 18°C ​​and the conclusion of which contains a state value corresponding to an activation of a heating appliance. In this situation, it may be planned to simply extract the current indoor temperature measurement as an observation of interest and subsequently apply Rule 1 to propose activating the heating appliance.

[0091] The extraction of observations of interest and the application of extracted rules are likely to become more complex when the same set of current observations falls within the conditions of several extracted rules. It is therefore necessary to provide, within the reasoner for extracted rules, a conflict avoidance mechanism in order to select an extracted rule to be applied from among several candidate extracted rules.

[0092] The conflict avoidance mechanism may be based on one or more predefined criteria.

[0093] It is thus possible to compare the observations Ot with the values ​​indicated in the condition of each of the extracted candidate rules. When a condition specifies a range of values, the average of this range of values ​​can, for example, be retained for the purposes of comparison. This comparison can be carried out by calculating a similarity value such as a Pearson product-moment correlation coefficient. A candidate rule whose condition has the highest correlation with the current observations can then be favored.

[0094] However, it may happen that several rules show a strong correlation with current observations. An additional criterion can be defined based on the conclusions of the extracted rules which can be compared with a history of observations noted (O,... O,) from an initial time "i" until the current time "t" to determine frequencies of occurrence. A candidate rule whose conclusion proposes state values ​​more commonly observed in the past can be considered as more likely to be the best choice.

[0095] The combination of these two predefined criteria - correlation with current observations and frequency of occurrence of state values ​​in history - forms a robust mechanism for selecting the most appropriate rule among the candidates. This approach ensures that the chosen rule is not only relevant at time "t", but also consistent with previous observations.

[0096] The state value proposals issued, at the current time “t”, by the automatic learning module and, where applicable, by the reasoner(s) are transmitted to the decision maker who chooses the final state values ​​for the current time from among these proposals.

[0097] An example of a process suitable for describing an operation of the decision maker is now described.

[0098] A hierarchy of priorities can be predefined to allow the decision maker to select state values ​​at any time from the available proposals.

[0099] In the event that the existing rules are explicitly defined by the users, it is advisable for the proposals from the reasoner for the existing rules to receive the maximum priority so as to ensure the satisfaction of the users' preferences. Thus, when, for example, the reasoner for the existing rules proposes to raise a roller shutter while the machine learning module proposes, at the same time, to leave it lowered, the decision maker opts to raise the roller shutter by applying the priority hierarchy.

[0100] It may be that the reasoner for existing rules does not provide, at the current time, any state value proposition for a given actuator. This is the case when, taking into account current observations, the existing rules likely to apply do not specify in their conclusion any state value for this given actuator.

[0101] It is also possible that the reasoner for the existing rules provides, at the current time, several contradictory proposals of state values ​​for the same actuator. Optionally, a conflict avoidance mechanism can be provided to prioritize the existing rules so as to select a particular state value for this actuator while best respecting the preferences of the users.

[0102] When the reasoner for existing rules fails to provide a conflict-free state value proposition at the current time for a given actuator, the decision maker can rely on other propositions.

[0103] It is proposed that in this situation, priority be given to the proposals from the reasoner for the extracted rules over those from the machine learning module. Indeed, regardless of the particularities of the extraction mechanism considered, an advantage of the proposals from the reasoner for the extracted rules is their explainability.

[0104] Furthermore, the rule extraction mechanism as described above provides, in one embodiment, that a rule is extracted and then retained only on the condition that the user is satisfied with the state values ​​specified in its conclusion. In addition, the extracted rule reasoner can integrate a robust conflict avoidance mechanism. A consequence of these specificities is that the extracted rules faithfully reflect the user's satisfaction, with greater precision than the machine learning module allows.

[0105] However, it is difficult to ensure that existing rules as extracted propose state values ​​for all actuators regardless of the state of the environment.

[0106] Thus, in situations where the reasoners do not provide any proposal regarding the state values ​​of certain actuators, it is proposed that the decision maker still selects state values ​​for these actuators, on the basis of the proposals provided by the machine learning module alone.

[0107] Reference is made to [Fig.2] which represents a processing circuit of an electronic device such as a tablet, a mobile phone, a computer, a home gateway, a server, a machine on which a decentralized digital service is based, etc.

[0108] The processing circuit (300) comprises a processor (302) connected to a data storage device (304) and to a wired or radio wave communication interface (306). The electronic device can be connected in a network, via the communication interface, to a plurality of connected objects or equipment equipped with sensors or actuators.

[0109] The data storage device stores instructions of a program in computer program which, when the computer program is executed by the processor, leads the processor to implement the different modules of a service management system according to the invention, such as for example that represented in [Fig.l].

[0110] The processor may further be capable of processing commands received from a user interface, for example from a graphical or voice interface, in particular to modify state values ​​of the actuators and / or add, modify or delete existing rules or extracted rules.

[0111] The processor may further be capable of controlling an information rendering device, for example by visual display, to render useful information to the user such as current measurements from the sensors, current state values ​​for actuators, and / or existing or extracted rule conditions that led to the application of state values ​​for actuators. Bibliographic references

[0112] [1] CG Garcia et al., “Midgar: Generation of heterogeneous objects interconnecting applications. A Domain Spécifie Language proposai for Internet of Things scénarios," Computer Networks, pp. 143—158, 2014.

[0113] [2] L. Mainetti et al., "A novel rule-based semantic architecture for loT building au tomation Systems," in 2015 23rd International Conférence on Software, Télécommunications and Computer Networks (SoftCOM), 2015.

[0114] [3] S. L. Brunton et al., "Data-driven science and engineering: Machine leaming, dynamical Systems, and control," Cambridge University Press, 2022.

[0115] [4] O. Brdiczka et al., "Leaming situation models in a smart home," IEEE Tran sactions on Systems, Man, and Cybernetics, Part B (Cybernetics), pp. 56—63, 2008.

[0116] [5] M. C. Mozer, "The neural network house: An environment hat adapts to its in habitants," in Proc. AAAI Spring Symp. Intelligent Environments, 1998, p. 58.

[0117] [6] M. Wozniak et al., "Intelligent home Systems for ubiquitous user support by using neural networks and rule-based approach," IEEE Transactions on Industrial In-formatics, pp. 2651—2658, 2019.

[0118] [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.

[0119] [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.

[0120] [9] E. Sirin et al. “Pellet: A practical owl-dl reasoner,” Journal of Web Semantics, vol. 5, no. 2, pp. 51-53, 2007.

[0121]

[10] M. Qiu, et al. "Reinforcement Leaming Based Architectures for Dynamic Gé nération of Smart Home Services," 2022 21st IEEE International Conférence on Machine Learning and Applications (ICMLA), Nassau, Bahamas, 2022, pp. 7-14.

Claims

Claims

1. Service management system (100) for a smart home comprising a plurality of sensors (202) and actuators (204), the service management system comprising: a knowledge representation module (120) configured to store, for each service: a series of sets of information associated with the service, each set corresponding to a respective time “t” and including at least one data item from a sensor and a state value of an actuator, where appropriate, one or more predetermined rules, each rule making it possible to deduce, on the basis of a set of information at time “t”, a state value proposition of the actuator at time “t+1”, a state proposition module (130) instantiated per service, comprising: a reasoner (132), activated for services having a predetermined rule, configured to receive a set of current information associated with the service to determine a first state value proposition for the actuator by applying the predetermined rule associated with the service, a machine learning module (134) configured to operate on the current information set to determine, by inference, a second state value proposition for the actuator, and a decider (140) configured to determine, from the proposals of the state proposal module, a final state value to be used for the actuator.

2. The system of claim 1, further comprising a rule extraction module (150) configured to extract new rules related to the operation of the machine learning module, and to respective services, based on accumulated data from the sensors and previous behaviors of the actuators, the knowledge representation module is also configured to store the extracted rules, and the state proposal module further comprises a separate reasoner (136) for the extracted rules, activated for services having an extracted rule, configured to receive the current information set to determine a third state value proposition for the actuator by applying the extracted rule associated with the service.

3. The system of claim 2, wherein the rule extraction module is configured to add or delete extracted rules based on predefined criteria.

4. The system of claim 2 or 3, configured to periodically update the extracted rules based on recent trends observed in sensor data or actuator state values.

5. System according to one of claims 1 to 4, further comprising a distributor (110) of services configured to: obtain, over time, data from the sensors and the state values of the actuators, organize the data and the state values of the information sets and associate each set of information with a respective service.

6. The system of claim 5, wherein the service distributor is configured to initiate, with the knowledge representation module, a creation of a new service instance.

7. A method for managing services for a smart home equipped with a plurality of sensors (202) and actuators (204), the method comprising the steps of: storing, for each service, in a knowledge representation module (120), a series of sets of information associated with the service, each set corresponding to a respective time "t" and including at least one data item of a sensor and a state value of an actuator, where appropriate, one or more predetermined rules, each rule making it possible to deduce, on the basis of a set of information at time "t", a state value proposition of the actuator at time "t+1", for a service having a predetermined rule, receiving with a reasoner (132) a set of current information associated with the service and determining a first state value proposition for the actuator by applying the predetermined rule associated with the service,using a machine learning module (134) to operate on the current information set and determine, by inference, a second state value proposition for the actuator, and determining, from the obtained propositions, with a decision maker (140), a final state value to be used for the actuator.,

8. Computer program comprising instructions for implementing implementation of the method according to one of claims 1 to 7 when this program is executed by a processor (300).

9. A non-transitory computer-readable recording medium (304) having recorded thereon the computer program of claim 8.

Images