FR3017738A1 - Commande d'equipement, perfectionnee et universelle - Google Patents

Description

Commande d'équipement, perfectionnée et universelle La présente invention concerne une commande d'équipement, plus particulièrement pour piloter le fonctionnement d'un tel équipement.

L'équipement peut être par exemple un équipement domotique tel qu'un appareil de restitution sonore (chaîne Hi-Fi, ou autre), un dispositif d'éclairage incluant au moins une lampe, une unité de détection comportant un ou plusieurs capteurs (par exemple d'intrusion, ou d'émanation de gaz toxique, ou autres), un ou plusieurs radiateurs électriques, ou autres. Habituellement, les équipements connus sont préprogrammés pour exécuter des applications en nombre limité Par exemple, un dispositif d'éclairage peut comporterun processeur et une mémoire stockant des données d'applications pour exécuter des programmes prédéfinis, par exemple s'allumer/s'éteindre à des horaires prédéterminés ou en fonction d'une détection par un capteur de présence, ou encore clignoter pour une lumière d'ambiance. Néanmoins, l'utilisation de tels équipements reste figée en fonction de leur pré-programmation.

La présente invention vient améliorer la situation. Elle propose à cet effet un procédé de commande d'un équipement, dans lequel une unité de commande, distante de l'équipement, exécute une application de commande de l'équipement, l'équipement étant,quant à lui, dépourvu d'un stockage de données de l'application.En particulier, le procédé, exécuté par l'unité de commande, comporte les étapes : obtenir des données de circuit que comporte l'équipement, pour piloter un fonctionnement de l'équipement, et adresser le circuit par une liaison sans fil pour transmettre à l'équipement des données de commande conformes aux données de circuit obtenues et relatives à l'exécution de l'application auprès de l'unité de commande Ainsi, la présente invention propose de déporter l'exécution de l'application et plus particulièrement l'exécution des calculs liés à l'application sur l'unité de commande distante, et de ne transmettre que des données de fonctionnement de bas niveau à l'équipement, en adressant directement le circuit de l'équipement.

Selon l'un des avantages que peut procurer alors l'invention, l'équipement peut être dépourvu de moyens informatiques sophistiqués (un processeur pour des calculs complexes ou des capacités de mémoire élevées), ce qui réduit le coût de fabrication de tels équipements. En outre, l'unité de commande distante peut, quant à elle, exécuter une multiplicité d'applications pour piloter une multiplicité de programmes possibles de fonctionnement de l'équipement. Ainsi, le fonctionnement de l'équipement n'est pas limité à un choix préprogrammé par son constructeur, ou prédéterminé en fonction de ses capacités de mémoire ou de calculs. Dès lors, l'unité de commande peut piloter une pluralité d'équipements. Par exemple, dans un mode de réalisation, on peut prévoirqu'une table de correspondance délivre des données de circuit que comporte un équipement en fonction d'un identifiant de cet équipement fourni en entrée de la table. Cet identifiant d'équipement permet alors d'obtenir, par consultation de la table de correspondance, toutes les données relatives à son circuit et qui sont nécessaires au pilotage à distance de l'équipement par l'unité de commande L'identifiant de l'équipement peut être une donnée telle qu'une suite de caractères ou un code-barres ou QRC, inscrite sur l'emballage commercial de l'équipement ou sur l'équipement même. En variante, cette donnée est lue par l'unité de commande par la liaison sans fil. Ainsi, dans une telle réalisation, l'unité de commande peut : recevoir de l'équipement l'identifiant de l'équipement par une liaison sans fil, et obtenir de la table de correspondance les données de circuit de l'équipement, pour piloter le fonctionnement de l'équipement. Les données de circuit de l'équipement peuvent comporterpar exemple des données d'entrées/sorties du circuit (par exemple des données d'adresses de ports d'entrée/sortie du circuit). En complément ou en variante, les données de circuit comportent au moins un fichier pilote propre à l'équipement. Un tel fichier pilote peut être typiquement un fichier dit « driver » qui peut comprendre d'ailleurs les données précitées d'entrées/sorties du circuit. Ainsi, on comprendra que, dans cette réalisation, l'unité de commande ne transmet à l'équipement que des commandes de bas niveau pour adresser directement le matériel « hardware » de l'équipement. « L'intelligence » nécessaire à l'exécution des applications est alors déportée sur l'unité de commande On peut prévoir alors dans une réalisation particulière, un terminal à disposition d'un utilisateur et comportant un module de communication sans fil, le terminal comportant en outre l'unité de commande précitée, l'application étant installée dans le terminal et exécutée par le terminal Le terminal peut être un mobile de type Smartphone par exemple, une tablette, un ordinateur portable ou fixe. Dans une forme de réalisation équivalente, le terminal peut envoyer les données de commande à une passerelle, par exemple domestique,qui s'interface entre : un réseau étendu auquel est relié le terminal, et un réseau local, par exemple sans fil, auquel est relié l'équipement pour recevoir les données de commande Ainsi, la passerelle relaye à destination de l'équipement les données de commande que lui transmet le terminal via le réseau étendu.

Bien entendu, dans une autre réalisation, le terminal peut envoyer les données de commande à la passerelle via le réseau local et la passerelle transmet ces données à l'équipement. Une telle réalisation profite de la longue portée d'une passerelle domestique pour piloter les équipements présents dans une habitation par exemple. Dans une variante de réalisation, le terminal peut simplement relayer des données de commande de l'équipement issues d'un serveur distant comportant l'unité de commande D'ailleurs, dans cette autre forme de réalisation possible, un terminal à disposition d'un utilisateur peut accéder à une interface web pour gérer des préférences d'un utilisateur quant à l'exécution de l'application. Cette interface web est en liaison avec un serveur comportant l'unité de commande Ce serveur peut alors transmettre à une passerelle (par exemple domestique) des données de commande issues du serveur et la passerelle relaye ces données de commande à l'équipement. Ainsi, dans une telle réalisation, on utilise des moyens de calculs prévus dans le « Cloud » pour exécuter l'application. Selon l'un des avantages que procure l'invention, l'unité de commande peut être agencée pour exécuter une pluralité d'applications de commande de l'équipement.Le procédé comporte alors, dans une telle réalisation, suite à une sélection d'une application parmi ladite pluralité d'applications, l'adressage du circuit par la liaison sans fil pour transmettre à l'équipement des données de commande relatives à l'exécution de l'application sélectionnée. Selon l'un des autres avantages que procure l'invention, l'unité de commande est agencée pour exécuter une application de commande de plusieurs équipements à la fois.Le procédé comporte alors, dans une telle réalisation, les étapes : obtenir des données de circuit de chaque équipement, pour piloter des fonctionnements respectifs des équipements de la pluralité d'équipements, et adresser chaque circuit d'un équipement de la pluralité d'équipements par une liaison sans fil pour transmettre à cet équipement des données de commande conformes à cet équipement et relatives à l'exécution de l'application auprès de l'unité de commande On comprendra alors que l'invention permet de créer de nouvelles formes d'applications, capables de piloter plusieurs types d'équipements à la fois, par exemple la lecture d'un contenu audio sur un appareil de restitution sonore et un éclairage qui varie en fonction des intensités sonores du contenu dans un dispositif d'éclairage, lequel est piloté par l'unité de commande à cet effet. Dans une forme de réalisation, le procédé comporte en outre une étape mise en oeuvre par l'unité de commande de réception par la liaison sans fil de données issues de l'équipement. Par exemple, dans le cas où l'équipement comporte un capteur, ces données issues de l'équipement peuvent comporter des mesures effectuées par le capteur. Ainsi, par exemple, les données issues d'un équipement peuvent être utilisées pour élaborer les données de commande d'un autre équipement.

D'autres exemples de réalisations combinant la commande de différents types d'équipements sont donnés dans la description détaillée qui suit. La présente invention vise aussi un programme informatique, comportant des instructions pour la mise en oeuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur. Un tel programme peut être installé auprès de l'unité de commande, pour la gestion des commandes de bas niveau d'un ou plusieurs équipements. Un ordinogramme de l'algorithme général d'un tel programme est illustré en figure 2 commentée ci-après. La présente invention vise aussi une unité de commande : comprenant au moins un module d'exécution d'une application de commande d'un équipement et reliée à un module de communication sans fil pour adresser un circuit de l'équipement avec des données de commande relatives à l'exécution de l'application auprès de l'unité de commande, pour la mise en oeuvre du procédé ci-avant. On comprendra que l'unité de commande peut être intégrée à un terminal du type présenté ci-avant (et se présenter sous la forme d'un module informatique utilisant typiquement un processeur, une mémoire de stockage, et une interface de communication sans fil), ou encore être intégrée à un serveur capable de transmettre des données de commande à une passerelle comme indiqué ci-avant, ou encore être intégrée dans la passerelle elle-même. La présente invention vise aussi un équipement, comprenant un module de communication sans fil pour recevoir sur un circuit de l'équipement des données de commande relatives à une application exécutée auprès d'une unité de commande distante, pour la mise en oeuvre du procédé ci-avant. Comme indiqué, un tel équipement peut ne comporter en mémoire qu'un identifiant qu'il communique, après interrogation d'une unité de commande, pour déterminer auprès de l'unité de commande ses données de circuit.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après d'exemples de réalisation, et des dessins annexés sur lesquels : - la figure 1 illustre un exemple de mise en oeuvre de l'invention ; - la figure 2 illustreles étapes principales d'un exemple de procédé au sens de l'invention ; la figure 3 illustre l'appairage entre une unité de commande UP et un circuit UD1 d'un équipement ; la figure 4 illustre la mise en fonctionnement d'un équipement en coopération avec l'unité de commande UP ; la figure 5 illustre un exemple de réalisation utilisant quatre équipements RS, HP, LED, BR pour au moins deux applications.

On se réfere à la figure 1 sur laquelle des équipements tels qu'un dispositif de restitution sonore RS, un dispositif d'éclairage EC, ou autres, comportent un module de communication sans fil (respectivement RF4, RF5), ainsi qu'une mémoire (respectivement M4, M5) stockant, dans l'exemple représenté, un identifiant propre à l'équipement (ou plus particulièrement au type d'équipement ayant un circuit spécifique donné). Un terminal TER, à disposition d'un utilisateur, peut alors exécuter une application (typiquement grâce à un processeur P2, coopérant avec une mémoire de travail et/ou de stockage M2),I1 peut transmettre ensuite, par un module de communication sans fil RF, des données de commande directement à des circuits des équipements, via une liaison sans fil (flèches F 1 1 et F12 respectivement). Pour ce faire, dans une étape préalable, le terminal TER peut interroger chacun des équipements par la liaison sans fil (par exemple NFC, Zigbee, wifi, Bluetooth, ou autre) et récupérer les identifiants respectifs des équipements pour en déduire des données sur les circuits de ces équipements (typiquement des données d'entrées /sorties de ces circuits). Il peut s'agir typiquement de données d'un fichier pilote (ou « driver ») comportant notamment des données concernant des ports d'entrée/sortie de circuits hardware d'un équipement. De telles données peuvent être fournies par un serveur distant SER, stockant une table de correspondance TC qui reçoit en entrée un identifiant d'équipement que transmet le terminal et fournit en sortie les données de circuit de l'équipement (double flèche F21). Ainsi, les calculs liés à l'exécution de l'application sont effectués par une unité de commande qui peut être implantée dans le terminal (sous la forme par exemple d'un module informatique utilisant le processeur P2 et la mémoire M2 du terminal). Cette unité de commande exécute alors les calculs liés à l'exécution de l'application et détermine ensuite des commandes de bas niveau à adresser directement au circuit de l'équipement. Ces commandes de bas niveau sont plus particulièrement transmises au module de communication sans fil RF du terminal (par exemple une interface wifi, ou Bluetooth, ou Zigbee, ou NFC, ou autre) qui les émet à destination du ou des modules de communication sans fil RF4, RF5 des équipements. Ces commandes de bas niveau, une fois reçues par un module de communication d'un équipement, sont transmises ensuite au circuit de cet équipement pour commander directement le fonctionnement de l'équipement (consignes, transmises à la volée, d'allumer ou d'éteindre une ou plusieurs lampes désignées, par exemple). Ainsi, les équipements n'exécutent que des commandes de bas niveau que transmet le terminal. Dans une réalisation variante ou complémentaire, le terminal, par exemple pour une autre application, peut accéder sur une interface Web pour régler des paramètres d'une application qui, elle, est exécutée auprès d'un serveur SER comportant à cet effet un processeur P1 et une mémoire Ml. Le serveur peut alors délivrer des commandes de bas niveau à une passerelle GW entre le réseau étendu RE (auquel est relié le serveur SER) et un réseau local auquel les équipements RS et EC sont reliés. Ensuite, la passerelle GW relaye les commandes de bas niveau aux équipements RS et EC par une liaison sans fil (flèches F23 et F24). Dans une autre variante encore, l'application peut être exécutée par la passerelle GW et recevoir, par exemple par une liaison sans fil, des paramètres choisis par un utilisateur sur le terminal TER (flèche 31). À cet effet, la passerelle peut elle-même comporter un processeur P3, une mémoire M3 pour effectuer les calculs liés à l'exécution de l'application.

Dans une autre variante encore, le procédé peut être implémenté par un matériel différent, comme suit. Une carte de lecture en champ proche (NFC) ou un terminal récupère par une liaison NFC les identifiants des équipements RS et EC. Ensuite, le terminal transmet ces identifiants à un serveur distant, ou par une deuxième lecture en champ proche, cette fois entre la carte et la passerelle GW, la passerelle récupère les identifiants d'équipements et les transmet à un serveur distant. Ce serveur distant exécute une application donnée pour délivrer ensuite des consignes de bas niveau aux équipements via le terminal, ou via la passerelle et la carte. On a représenté sur la figure 2 les différentes étapes mises en oeuvre dans un exemple de réalisation de l'invention (indépendamment du type de matériel utilisé pour cette mise en oeuvre). Ainsi, après une première étape S21 de récupération d'un identifiant ID d'un équipement, une table de correspondance TC est consultée à l'étape S22, pour en déduire à l'étape S23 des données d'entrée/sortie d'un circuit de l'équipement. Ensuite, l'application est exécutée à l'étape S24 (sur un terminal, ou sur un serveur, ou sur une passerelle, ou autres) et les données de commande issues de cette exécution sont transmises à l'étape S25 à l'équipement, par une liaison sans fil. En particulier, ces commandes sont conformes aux données d'entrée/sortie du circuit de l'équipement, pour être directement interprétables par ce dernier. Bien entendu, les exemples de réalisation présentés ci-avant, notamment en référence à la figure 1, ne doivent pas être interprétés limitativement et ont pour vocation d'expliquer les principes généraux liés à l'invention. En effet, de nombreuses automatisations industrielles ou pour le grand public peuvent faire appel à des automates programmables ou de petites unités de calculs reliées à des entrées et sorties utiles à une application considérée. Comme, actuellement, les automates programmables/unités de calculs sont souvent dupliqués pour une application donnée pour un équipement, il est proposéde déporter les entrées et sorties de l'automate programmable/unité de calcul sur un dispositif spécifique, le lien entre l'unité de calcul et l'équipement étant construit après identification par un mécanisme de type NFC, ou autre technique de communication sans fil. Les avantages de la solution sont notamment : de réduire les coûts de la partie utile, contenant les entrées et sorties du circuit, en limitant le circuit de l'équipement au minimum, grâce au déport des processus de commande de bas niveau avec un processus d'identification ; de permettre une émulation de la partie « calculateur » sur un calculateur central (sur un terminal mobile, un serveur, ou autre) communiquant par exemple avec plusieurs circuits E/S, en s'affranchissant de besoins de hardware spécifiques des applications, de simplifier l'appairage des entrées/sorties d'un circuit d'équipement avec le calculateur central en prévoyant la configuration des parties nécessaires de ces deux unités lors d'une étape préalable par simple usage de NFC ou radiofréquence, - de permettre un déport sécurisé des entrées/sorties (E/S)associées à un processus de commande Bien entendu, il peut être prévu des applications de l'invention de nature domestique, mais aussi industrielle qui permettent alors de réduire les coûts des équipements déployés, en réduisant les risques associés à l'installation de processeurs coûteux dans des environnements peu propices, ou en simplifiant les opérations de maintenance et remplacement des E/S d'un équipement. Par ailleurs, dans une application destinée à un utilisateur de terminal doté d'un module de communication sans fil (par exemple un Smartphone ou une tablette, ou autres), on peut : développer une application émulatrice d'une application que l'on charge sur le terminal, et qui présente également une interface utilisateur (GUI) pour configurer les objets (les équipements et les processus de commande) ; développer également un module des entrées/sorties déporté, sous forme d'une carte avec lecture NFC, avec les quelques entrées et sorties identiques à celles de l'équipement, un module radiofréquence nécessaire à la communication à distance entre ce module et le terminal (par exemple Bluetooth 4, ou autre) ainsi qu'un module NFC permettant d'apparier la carte E/S au terminal sur lequel se trouve l'application émulatrice/GUI ; prévoir aussi une plateforme de développement permettant de configurer l'appariement de la carte E/S, ainsi que les caractéristiques matérielles de la carte. Cette plateforme peut mettre aussi à disposition un serveur sur le Cloud où pourront être proposés les programmes associés aux objets. Il est alors possible de créer un objet (un processus pour un type d'équipement donné) qui utilise la carte E/S.Dans un exemple de réalisation, cette carte E/S peut être implantée dans l'équipement sous la forme d'un module E/S. L'équipement peut être une lampedans un exemple de réalisation donné ci-après. Dans ce cas,l'interrupteur de la lampe peut être connecté avec le module E/S. Il est alors possible de développer un code informatique nécessaire à cet équipement (par exemple : clignoter). La lampe peut ensuite être utilisée avec l'application/GULAinsi, seul le module E/S est installé dans la lampeet sa référence NFC est configurée pour pointer vers le programme de la lampe. Lorsqu'un utilisateur achète une lampe « compatible » avec cette application, lors de l'installation, il rapproche son terminal de celle-ci pour l'apparier en utilisant une lecture NFC qui déclenche la recherche du software associé à cette lampe.Le terminal rapatrie ce software dans l'application émulatrice/GUI. Le software configure la communication radiofréquence (Bluetooth par exemple) entre le terminal et le module E/S de la lampe, et présente dans l'interface GUI les fonctions possibles de la lampe (allumer et clignoter) et les éventuels programmes d'usages proposés. L'utilisateur peut choisir alors dans l'application/GUI d'associer une fonction de son choix disponible (soit générique, telle que la réception d'un email, soit spécifique à la lampe et donnée par son constructeur, ou encore associée à une application tierce, ou autres).Par exemple, lorsqu'il reçoit un nouvele-mail, sa lampe clignote trois fois. Sinon, elle reste éteinte ou allumée au choix de l'utilisateur. Le programme peut se poursuivre, par exemple si l'utilisateur quitte son domicile avec son terminal de sorte que les équipements perdent leur connexion, par l'application d'un statut par défaut (par exemple : lampe éteinte). Lorsque l'utilisateur revient chez lui, son terminal détecte les équipements via le Bluetooth, initie les reconnexions, puis son application/GUI effectue des mises à jour éventuelles des statuts des équipements. On se réfere maintenant à la figure 3 pour décrire un exemple de réalisation particulier dans lequel on prévoit un dispositif spécifique en tant qu'unité de commande, appelée ci-après « unité principale » UP, et des circuits spécifiques d'équipement (connectés aux équipements, par exemple à l'interrupteur d'une lampe), appelés ci-après « unités déportées » UD1, UD2. L'unité principale UP peut être un automate programmable et/ou une unité de calcul. Elle possède un ou plusieurs ports d'entrée/sortie E/S numérotés de 1 à n. Ces ports peuvent avoir des fonctions, des brochages et des caractéristiques électriques particuliers. Un utilisateur possède une unité déportée UD, avec son propre port d'E/S. Cette unité UD est supposée être associée à une configuration « k » des entrées/sorties E/S de l'unité principale. Cette unité déportée UD possède un identifiant (numéro d'identification par exemple) qui indique à la fois le type d'entrée/sortie E/S (« k » dans l'exemple) ainsi qu'un identifiant unique caractéristique de l'unité déportée. On décrit dans un premier temps ci-après l'activation et la connexion de l'unité déportée UD1. L'unité déportée est « approchée » de l'unité principale pour effectuer l'appairage. Ceci peut se faire d'au moins deux manières : l'unité déportée UD1 est approchée physiquement de l'unité principale (flèche 3a) par une liaison NFC et l'appairage s'effectue en direct ; l'unité déportée UD1 est approchée physiquement d'un terminal de communication TER et un logiciel implanté dans ce terminal établit, via un réseau de télécommunications (par exemple le réseau étendu RE), la connexion avec l'unité principale UP pour effectuer le même mécanisme d' appairage (flèche 3b).

L'unité déportée passe alors d'un état inactif UD1 à un état actif UD2. Elle peut alors être éloignée ensuite de l'unité principale (cas de la flèche 3a) ou du terminal de communication qui a servi de relais (cas de la flèche 3b). L'unité déportée UD2 reste alors active. Toutefois, elle ne peut recevoir et émettre des informations avec l'unité principale que dans les cas suivants : - lorsque l'unité déportée UD peut accéder à l'unité principale car elles sont reliées à un même réseau local sans fil RL (flèche 5a), ou lorsque l'unité déportée peut accéder à l'unité principale en utilisant le mobile comme routeur (flèche 5b). Dans les deux derniers cas, les liaisons entre l'unité déportée et l'unité principale, ou entre l'unité déportée et le mobile peuvent être établies avec tout type de communication locale sans fil (NFC, Bluetooth, Zigbee, ou autres). On décrit maintenant en référence à la figure 4 l'initiation du fonctionnement d'une telle installation, suite à l'appairage illustré sur la figure 3.

L'unité déportée UD est initialement inactive. Elle n'a pas été « reconnue » par l'unité principale et ne possède pas, à ce stade du moins, de logiciel nécessaire à son fonctionnement. Elle contient en revanche un identifiant unique permettant de connaître son type (notamment le type d'entrées/sorties qu'elle contient). L'unité déportée est « approchée » de l'unité principale pour effectuer l'appairage conformément à l'une des manières (flèches 3a, 3b) présentées ci-avant en référence à la figure 3. L'unité déportée UD fournit alors à l'unité principale UP son identifiant unique. Ensuite, dans une forme de réalisation, l'unité principale UP peut interroger un serveur d'identification d'unités déportées (suite à la réception d'un identifiant) et de fourniture d'applications spécifiques dites API (pour « Application Program Interface »). Ce serveur SER est fonctionnellement distinct de l'unité principale et peut être accessible via un réseau étendu (ou local via une passerelle), ou même être présent dans une même machine physique que l'unité principale UP.

L'identifiant unique de l'unité déportée permet à ce service de reconnaître le type d' entrée/sortie qui est géré par cette unité déportée UD (et accessoirement, de récupérer quelques informations de service : constructeur, version matérielle et logicielle, etc.). Le service d'identification et de fourniture d'API retourne à l'unité principale l'ensemble des informations matérielles et logicielles nécessaires au pilotage de l'unité déportée (notamment le fichier pilote ou « driver logiciel » nécessaire et les fonctions offertes par l'interface de programmation et de commande). Ces informations sont mémorisées par l'unité principale UP dans son propre gestionnaire d'API référencé G-API. C'est à travers cette fonction que l'unité principale conserve la mémoire de l'ensemble des unités déportées qui lui ont été appairées, leurs identifiants ainsi que l'ensemble des drivers nécessaires à leur pilotage. L'unité déportée est alors activée par l'unité principale de deux manières : - lorsque l'unité déportée peut accéder à l'unité principale, car elles sont sur le même réseau local sans fil (par exemple sur le réseau domestique) RL (flèche 7a), ou - lorsque l'unité déportée peut accéder à l'unité principale en utilisant le mobile comme routeur (flèche 7b). Ainsi, lorsque le lien entre l'unité déportée et l'unité principale est opérationnel (typiquement quand l'unité déportée est accessible pour l'unité principale via un réseau local ou via le réseau étendu et un routeur), l'unité principale UP peut commander les ports d'entrées/sorties de l'unité déportée UD et/ou recevoir éventuellement des signaux depuis celle-ci (par exemple des mesures de capteurs). En effet, il n'est pas fait d'hypothèse sur le niveau d'intelligence supposé des diverses unités déportées. On indique d' ailleurs que certaines unités déportées peuvent éventuellement recevoir en outre des informations supplémentaires telles qu'une mise à jour de leur logiciel de base ou des informations de sécurité. Ainsi, l'unité principale propose, via un service d'accès ouvert aux programmes applicatifs, l'accès à l'ensemble des API des unités déportées qui lui sont associées. Toute nouvelle application sollicitant ces API peut ainsi commander au choix une ou plusieurs des unités déportées associées à l'unité principale, avec une logique propre à cette application.30 On décrit maintenant en référence à la figure 5 un exemple de réalisation d'une application utilisant quatre équipements à la fois. Plus particulièrement, on présente ici deux cas d'usages possibles avec deux applications simultanément présentes, et qui peuvent adresser quatre équipements. Ainsi, quatre équipements sont supposés ici appairés avec l'unité principale UP, selon le mode de fonctionnement décrit précédemment, qui sont dans cet exemple une enceinte de restitution sonore RS,un haut-parleur HP par exemple de sirène d'intérieur,une lampe LED incluant aussi un haut-parleur, etun bracelet de détection de chutes BR. Dans cet exemple, les quatre équipements intègrent chacun une unité déportée UD du type ci-avant et sont supposés connectés à l'unité principale UP via une liaison Bluetooth.

Après appairage, les API des unités déportées de ces quatre équipements (i.e. les circuits de ces équipements par exemple reliés à un interrupteur pour allumer une lampe ou reliés à un capteur pour recevoir un signal directement de ce capteur) sont rendues accessibles aux applicatifs après consultation du serveur SER présenté précédemment en référence à la figure 4. Pour cet exemple, on suppose que les API proposées permettent d'accéder aux fonctions suivantes : - pour l'enceinte RS : * envoi d'un morceau sonore (choisi par l'applicatif), -pour la sirène d'intérieur HP : * commande et arrêt du signal d'alarme (1' applicatif n'ayant ici que la possibilité de lancer ou d'arrêter le signal), - pour la lampe LED : * commande et arrêt de la lampe, * envoi d'un morceau sonore (choisi par l'applicatif), -pour le bracelet détecteur de chute BR : * détection de présence et de mouvement, * réception par l'applicatif d'un signal d'alerte en cas de chute. A partir de ces API, deux applicatifs différents peuvent ainsi accéder simultanément aux API adressant ces équipements. On peut supposer ces applicatifs s'exécutant en tâche de fond.

Par exemple, une application d'ambiance adresse et contrôle les équipements RS, LED et BR. L'équipement HP n'est pas utilisé ici. Ainsi, lorsque l'utilisateur porteur du bracelet BR pénètre dans la maison, une détection de présence est remontée par l'unité principale vers l'application. Cette application peut alors simultanément ou successivement : - envoyer sur l'équipement LED un ordre d'allumage de la LED, ainsi qu'un morceau sonore (par exemple une séquence sonore de bienvenue), et envoyer sur l'équipement RS un second morceau sonore (par exemple, une musique d' ambiance).

Lorsque l'utilisateur sort de la maison, l'application est avertie (perte de la détection de présence du bracelet) et peut couper à la fois la lumière sur l'équipement LED et les séquences sonores en cours sur les équipements RS et LED. Une autre application, de sécurité, peut adresser et contrôler l'ensemble des équipements. En cas de chute de l'utilisateur, le bracelet BR remonte un signal, qui est transmis vers l'application par l'API de l'unité principale. Cette application peut alors : envoyer simultanément un message sonore sur les équipements RS et LED, par exemple pour tenter de réveiller l'utilisateur, en même temps, faire clignoter la lampe de l'équipement LED pour attirer son attention d'une autre manière, et après une durée préprogrammée (paramétrable dans l' application), si aucun signal de nouveau mouvement ne remonte du bracelet BR, commander la sirène d'intérieur HP pour appeler du secours (auprès du voisinage par exemple). On comprendra alors que toute l'intelligence est ici dans les applications. Les API ouvertes par l'unité principale ne gèrent que des fonctions de bas niveau sur les divers circuits des équipements.

Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemple ; elle s'étend à d'autres variantes. Ainsi par exemple, on a décrit ci-avant en référence à la figure 1, une réalisation dans laquelle l'unité de commande est implantée dans un terminal de communications, ou encore auprès d'un serveur distant pour mener les calculs liés à une application. Néanmoins, comme présenté ci-avant en référence aux figures 3 à 5, l'unité de commande peut être implantée dans un dispositif spécifique, tel que l'unité principale précitée UP. Un terminal peut encore intervenir pour choisir des paramètres d'une application (d'ambiance ou de sécurité par exemple, en choisissant alors, via une interface homme/machine du terminal, une musique ou un type d'éclairage tamisé, ou une durée de temporisation avant de déclencher une alarme). Les calculs de l'application peuvent être exécutés sur le terminal ou sur l'unité de commande, mais l'application de commande elle-même, avec en particulier la conversion des commandes pour être interprétées par le circuit d'un équipement, sont alors réalisées par l'unité de commande au sens de l'invention.

Claims (14)

1. REVENDICATIONS1. Procédé de commande d'un équipement, dans lequel une unité de commande, distante de l'équipement, exécute une application de commande de l'équipement, l'équipement étant dépourvu d'un stockage de données de l'application, le procédé,exécuté par l'unité de commande,comportant les étapes : obtenir des données de circuit que comporte l'équipement, pour piloter un fonctionnement de l'équipement, et adresser le circuit par une liaison sans fil pour transmettre à l'équipement des données de commande conformes aux données de circuit obtenues et relatives à l'exécution de l'application auprès de l'unité de commande
2. 2. Procédé selon la revendication 1, dans lequel on prévoit une table de correspondance délivrant des données de circuit que comporte un équipement en fonction d'un identifiant de cet équipement fourni en entrée de la table.
3. 3. Procédé selon la revendication 2, dans lequel l'unité de commande : reçoit de l'équipement l'identifiant de l'équipement par une liaison sans fil, et obtient de la table de correspondance les données de circuit de l'équipement, pour piloter le fonctionnement de l'équipement.
4. 4. Procédé selon l'une des revendications précédentes, dans lequel les données de circuit de l'équipement comportent des données d'entrées/sorties du circuit.
5. 5. Procédé selon l'une des revendications précédentes, dans lequel lesdites données de circuit comportent au moins un fichier pilote propre à l'équipement.
6. 6. Procédé selon l'une des revendications précédentes, dans lequel un terminal à disposition d'un utilisateur et comportant un module de communication sans fil comporte en outre ladite unité de commande, ladite application étant installée dans le terminal.
7. 7. Procédé selon l'une des revendications précédentes, dans lequel l'unité de commande est agencée pour exécuter une pluralité d'applications de commande de l'équipement, le procédé comportant, suite à une sélection d'une application parmi ladite pluralitéd' applications, l' adressage du circuit par la liaison sans fil pour transmettre à l'équipement des données de commande relatives à l'exécution de l'application sélectionnée.
8. 8. Procédé selon l'une des revendications précédentes, dans lequel l'unité de commande est agencée pour exécuter une application de commande d'une pluralité d'équipements à la fois, le procédé comportant les étapes : obtenir des données de circuit de chaque équipement, pour piloter des fonctionnements respectifs des équipements de la pluralité d'équipements, et adresser chaque circuit d'un équipement de la pluralité d'équipement par une liaison sans fil pour transmettre à cet équipement des données de commande conformes aux données de circuit obtenues pour cet équipement et relatives à l'exécution de l'application auprès de l'unité de commande
9. 9. Procédé selon l'une des revendications précédentes, comportant en outre une étape mise en oeuvre par l'unité de commande de réception par la liaison sans fil de données issues de l' équipement.
10. 10. Procédé selon la revendication 9, dans lequel, l'équipement comportant un capteur, les données issues de l'équipement comportent des mesures effectuées par le capteur.
11. 11. Procédé selon l'une des revendications 9 et 10, combinées à la revendication 8, dans lequel les données issues d'un équipement sont utilisées pour élaborer les données de commande d'un autre équipement.
12. 12. Programme informatique, comportant des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 11, lorsque ce programme est exécuté par un processeur.
13. 13. Unité de commande, comprenant au moins un module d'exécution d'une application de commande d'un équipement et reliée à un module de communication sans fil pour adresser un circuit de l'équipement avec des données de commande relatives à l'exécution de l'application auprès de l'unité de commande, pour la mise en oeuvre du procédé selon l'une des revendications 1 à 11.
14. 14. Equipement, comprenant un module de communication sans fil pour recevoir sur un circuit de l'équipement des données de commande relatives à une application exécutée auprès d'une unité de commande distante, pour la mise en oeuvre du procédé selon l'une des revendications 1 à 11.