FR 2779596 A1 19991210 FR 9807187 A 19980608 L'invention concerne un procédé de programmation d'actions de ressources, c'est à dire de fonctionnalités d'appareils, dans un réseau de communication domestique, notamment un réseau comportant un bus série IEEE 1394-1995. Dans un réseau de communication domestique auquel sont reliés des appareils audio/vidéo ou 'noeuds', un utilisateur devrait avoir la possibilité de programmer une action à effectuer par l'un des appareils à partir de n'importe quel appareil possédant un affichage. A titre d'exemple, il devrait être possible de programmer l'enregistrement d'une émission par un appareil d'enregistrement quelconque, par exemple un magnétoscope, à partir de n'importe quel téléviseur ou autre moyen de visualisation relié au réseau. L'invention a pour objet un procédé de programmation d'actions de ressources dans un réseau d'appareils domestiques caractérisé en ce qu'il comporte les étapes de: - émission d'une demande de programmation d'une action par une application vers une ressource principale, - réservation de ladite ressource principale auprès de son gestionnaire de ressources local, et le cas échéant, - réservation par ladite ressource principale de ressources impliquées dans l'accomplissement de l'action auprès des gestionnaires des ressources liés à ces ressources impliquées. Selon un mode de réalisation particulier, cette demande comporte un identificateur de la ressource principale et le cas échéant d'autres ressources impliquées dans l'accomplissement de l'action. Selon un mode de réalisation particulier, le procédé conforme à l'invention comporte l'étape de mémorisation par ladite ressource principale d'une structure de données transmise par l'application et caractérisant Il'action. Selon un mode de réalisation particulier, le procédé comporte en outre l'étape de mémorisation par le gestionnaire des ressources impliquées de données relatives aux horaires de l'action à effectuer. Selon un mode de réalisation particulier, la demande de programmation d'une action est formulée auprès d'un module logiciel distinct de la ressource principale mais localisée dans le même appareil que celle-ci, ledit module logiciel réservant ensuite la ressource principale et le cas échéant les ressources impliquées. D'autres caractéristiques et avantages de l'invention apparaîtront à travers la description de deux exemples de réalisation non limitatifs, illustrés par les figures jointes, parmi lesquelles: - la figure 1 est un schéma d'une partie d'un réseau domestique représentant le fonctionnement selon le premier exemple de réalisation, - la figure 2 est un schéma d'une partie d'un réseau domestique représentant le fonctionnement selon le second exemple de réalisation, - la figure 3 est un diagramme représentant des échanges de données selon le premier exemple de réalisation, - la figure 4 est un diagramme représentant des échanges de données selon le second exemple de réalisation. La présente description concerne un réseau domestique basé un sur bus série conforme à IEEE 1394-1995, ainsi que sur l'architecture dite architecture 'HAVi', définie dans le document 'The HAVi Architecture - Specification of the Home Audio/Video interoperability Architecture' en date du 11 mai 1998, version 0.8, publiée le 15 mai 1998 sur les sites Internet des entreprises Sony, Hitachi, Toshiba, Philips et Sharp. On se référera à ces documents pour plus de détails. Deux demandes de brevet déposées au même nom que la présente demande traitent plus en détail de certains aspects de l'architecture du réseau. Il s'agit de la demande de brevet français numéro 9805110 du 23 avril 1998 ayant pour titre 'Procédé de gestion d'objets dans un réseau de communication et dispositif de mise en oeuvre', ainsi que d'une demande de brevet français déposée le même jour que la présente demande et intitulée Procédé de gestion de priorités d'accès à des ressources dans un réseau domestique et appareil de mise en oeuvre'. La première demande de brevet concerne la mise en oeuvre de registres d'objets ou de ressources dans les appareils connectés au réseau, ce registre maintenant à jour la liste des ressources ou modules logiciels disponibles au niveau local dans un appareil, tandis que la seconde demande est relative à un gestionnaire des ressources qui maintient un état des ressources disponibles localement et participe à la résolution de conflits d'accès à - ou de réservation de - ces ressources. Pour exécuter une action, telle qu'un enregistrement d'émission, une application peut nécessiter un accès à des ressources publiques. On entend par ressources publiques dans le présent contexte des fonctionnalités d'appareils autres que l'appareil dans lequel s'exécute l'application, mais qui sont potentiellement accessibles par cette application. Font également partie des ressources publiques les ressources accessibles localement par I'application. Une application peut elle-même être une ressource. Les registres mentionnés plus haut maintiennent à jour une liste des ressources publiques disponibles, et une application peut déterminer quelles sont ces ressources en lançant une requête au niveau de son registre local, qui peut propager cette requête aux autres registres. L'appellation 'module logiciel' ('software module' selon la terminologie du document HAVi) désigne aussi bien des applications, des ressources que des services d'un appareil. La mise en ceuvre d'une action préprogrammée implique - une ressource principale appelée 'ressource cible' ou simplement cible', - le cas échéant, une ou plusieurs autres ressources publiques, appelées 'ressources impliquées', également nécessaires pour mettre en ceuvre l'action préprogrammée. Dans le cadre d'une demande d'enregistrement, la cible est par exemple la fonctionnalité d'enregistrement d'un appareil d'enregistrement digital (magnétoscope digital, DVD,...), tandis qu'une ressource impliquée est un tuner. D'autres ressources peuvent être nécessaires: par exemple un transcodeur, nécessaire pour traduire le format des données en celui de l'appareil d'enregistrement, un service de contrôle d'accès, pour autoriser l'accès à des programmes sécurisés,... On tiendra compte de la nécessité pour le procédé de mise en oeuvre de l'action préprogrammée de fonctionner normalement même si le dispositif d'affichage par l'intermédiaire duquel l'action a été programmée a été rendu inactif (par exemple, I'utilisateur a éteint le téléviseur lui ayant servi pour la programmation d'un magnétoscope). On se place dans l'hypothèse que ce dispositif ne comporte pas la ressource cible, ni les ressources impliquées. Remarques pour ce paragraphe: les deux parties (cause et effet) ont été inversées. C'est le fait que la ressource principale appartienne aux ressources impliquées, et pas au dispositif d'affichage, qui assure la robustesse de la programmation. En effet, après la programmation d'une action, I'utilisateur peut naturellement éteindre sa télé. Par contre, il y a peu de chances pour qu'il débranche volontairement un des appareils impliqués (il ne va pas enlever son magnétoscope du réseau si il vient juste de programmer un enregistrement). La cible accepte ou non l'action demandée par l'application. Au moment de la programmation de cette action, la cible doit identifier les ressources nécessaires pour l'accomplissement de l'action et les réserver pour la période de temps voulue. Au moment même de l'exécution de l'action, la cible et les ressources impliquées doivent se synchroniser. Ceci a pour conséquence que des informations relatives à l'action préprogrammée doivent être mémorisées dans le réseau. Selon un premier exemple de réalisation, c'est la cible qui mémorise ces informations et exécute l'action, tandis que selon un second mode de réalisation, c'est un autre module qui sera chargé de ces fonctions. Une action préprogrammée peut être définie par un certain nombre d'informations, collectées dans une structure de données particulière remplie par l'application programmant l'action et mémorisée selon l'exemple de réalisation soit par la ressource cible, soit par le module autre que la ressource cible qui gérera l'action. - Le type de l'action - Des paramètres relatifs à l'action - Une date Une heure de début - Une heure de fin - La périodicité de l'action - Un identificateur de la ressource cible - Les identificateurs des ressources impliquées - Des données utilisateur Le type de l'action dépend de la nature de la cible. A titre d'exemple l'action peut être 'ENREGISTRER' ou 'LECTURE' pour une ressource ayant une fonctionnalité de mémoire de masse, ou SELECTIONNERSERVICE' pour un démultiplexeur de télévision numérique. Les paramètres, optionnels, servent à définir l'action de manière plus spécifique. Un paramètre peut être un événement ou un service au sens de la norme de diffusion de vidéo numérique DVB (pour 'Digital Video Broadcast'). Dans ce cas, les paramètres comporteront un identificateur du type de paramètre, suivi de la valeur du paramètre. Certains appareils du réseau peuvent ne pas comporter des moyens de traitement pour fournir un service de ce niveau. Par exemple, un appareil d'enregistrement peut ne pas accepter de paramètres après une commande 'ENREGISTRER', car ne pouvant lui-même contrôler un tuner, tandis qu'un appareil plus complexe, ayant cette possibilité, pourra accepter une commande de type 'ENREGISTRER service X'. La date, les heures de début et de fin et la périodicité de l'action sont des informations classiques. L'identificateur de la ressource cible est nécessaire pour qu'une application puisse modifier une action déjà programmée. Ce champ n'est pas nécessaire si la cible mémorise directement l'action préprogrammée (i.e. si cette ressource est elle-même la ressource principale d'une action programmée). Si par exemple une application veut connaître quelle action programmée est associée à une ressource donnée, elle va demander à cette ressource les identifiants des ressources principales de chacune des actions programmées dans lesquelles cette ressource est impliquée. L'application va alors pouvoir consulter la structure de données de l'action programmée qu'elle a choisie, puis va pouvoir la modifier (cette application peut être par exemple celle d'une interface utilisateur, éventuellement commandée par un utilisateur autre que celui qui a programmé l'action qui va être modifiée). Les identificateurs des ressources impliquées sont utilisés selon le mode de réalisation, soit par la cible, soit par le module qui comporte la ressource requise. La liste permet soit à la cible, soit au module logiciel de demander des informations relatives aux ressources impliquées, par exemple par l'intermédiaire des registres, ou en leur transmettant directement des messages. Les données utilisateur comportent par exemple en texte clair la raison d'être de I 'action, ce qui peut être important en cas de conflit avec une action programmée antérieurement. Dans ce cas, lorsque le conflit doit être résolu par un utilisateur, typiquement celui programmant l'action plus récente, ces données peuvent lui donner des indications sur l'importance de l'action. Les ressources impliquées contactées soit par la ressource cible, soit par le module logiciel responsable de la gestion de l'action devront elles aussi mémoriser une partie du contenu de la structure de données ci-dessus: les informations relatives à I 'heure et, éventuellement, le type d'action, les paramètres, et les données utilisateur. Dans le cas ou les ressources impliquées savent gérer les actions programmées de façon autonome (voir figure 3), elles mémorisent toutes les informations relatives à l'action programmée. Dans le cas o les ressources impliquées sont pauvres (voir figure 4, présence d'un module logiciel responsable de la gestion de l'action), c'est ce module logiciel qui stocke toutes ces données: il mémorise donc que la ressource X doit faire une action Y à une heure Z, et ce pour chacune des ressources impliquées qui sont locales à son noeud (puisque dans un noeud peuvent exister plusieurs ressources, gérée par un seul module logiciel par noeud). Le premier exemple de réalisation est illustré par la figure 1. La partie du réseau représentée par cette figure comporte cinq appareils. L'appareil 1 est un téléviseur, localisé dans une cuisine et comportant une application 2 (par exemple une interface utilisateur permettant la programmation de l'ensemble des appareils du réseau). L'appareil 3 est également un téléviseur, situé cette fois dans la chambre à coucher et muni d'une application 4, similaire à l'application 2. L'appareil 5 est un décodeur de télévision satellite numérique comportant une ressource tuner 6 et un gestionnaire de ressources 7, tandis que l'appareil 8 est un dispositif d'enregistrement numérique de type DVD, comportant à ce titre la ressource d'enregistrement 9 et un gestionnaire de ressources 10. En dernier lieu, l'appareil 11 est par exemple un autre décodeur, qui possède une fonctionnalité de transcodage des données audio/vidéo codées selon un premier format (celui du décodeur 5) en un second format (celui de l'appareil d'enregistrement 8). L'appareil 11 possède par conséquent une ressource transcodage 12 et un gestionnaire de ressources 13. Les divers appareils, qui peuvent comporter d'autres modules logiciels que ceux illustrés, sont reliés par un bus série 14, par exemple un bus IEEE 1394-1995. Selon ce premier exemple de réalisation, la ressource cible, dans le présent cas la fonction enregistrement de l'appareil 8, intègre elle- même une application capable de gérer l'action d'enregistrement. On suppose qu'un utilisateur souhaite enregistrer une émission sur un service X, à 20h30, le 12 décembre 1999, pour une durée de deux heures. Bien que dans l'exemple de la figure 1, une seule ressource de type tuner et une seule ressource de type transcodage existent dans le réseau, I'utilisateur pourrait, dans un réseau o plusieurs ressources de même type coexisteraient, choisir entre plusieurs ressources de même type du réseau celle qu'il préférerait pour participer à l'exécution de l'action. Quand la ressource cible 9 reçoit l'action programmée de la part de lI'application 2, elle effectue une auto-réservation auprès du gestionnaire de ressources local 10, en procédant de la manière décrite dans la seconde demande de brevet mentionnée au début de cette description. Elle effectue d'autre part la réservation des ressources impliquées (tuner 6, transcodeur 12) auprès des gestionnaires des ressources distants (gestionnaires 7, respectivement 13). Chaque gestionnaire des ressources mémorise les données relatives à la réservation des ressources qui lui sont associées (c'est à dire des ressources ayant la même plate-forme d'exécution que ce gestionnaire des ressources). Une fois les réservations effectuées, la cible transmet un message de confirmation à l'application 2 à l'origine de l'action. En cas de conflit de réservation, par exemple en cas de préemption ou négociation d'une ressource déjà réservée pour une action donnée par une application programmant une autre action, le gestionnaire des ressources avertit la cible ayant programmé la première action par un message approprié. Chaque gestionnaire de ressources mémorise en effet dans ce but l'identificateur ou l'adresse du module logiciel qui a effectué une réservation. A ce stade, en cas de débranchement de l'appareil 1, I'action préprogrammée s'exécutera néanmoins, car toutes les informations relatives à l'action sont stockées au niveau de la cible. Un utilisateur peut modifier ou supprimer l'action préprogrammée à partir d'une autre application, telle que l'application 4. Si l'application 4 veut accéder à toutes les actions programmées concernant une ressource donnée (trouvée par l'intermédiaire du registre local de l'application), la ressource contactée par l'application peut donner les identifiants des ressources principales de chacune des actions programmées dans lesquelles elle est impliquée. La totalité de la structure de donnée décrivant l'action programmée peut être ensuite retrouvée en contactant directement chaque ressource principale. Au moment du début de l'action, la cible relie les différentes ressources grâce au module logiciel local appelé gestionnaire connexions ('SM' ou 'Stream Manager' selon la terminologie du document HAVi). Une ressource peut être désignée sous les termes de gestionnaire de composante fonctionnelle ('FCM' ou 'Function Component Manager' selon la terminologie HAVi). L'architecture peut alors être représentée par le schéma de la figure 3, o une application transmet une programmation d'action à l'interface de programmation d'application faisant partie de la cible. Le second exemple de réalisation est illustré par la figure 2. On suppose ici que des ressources n'intègrent pas d'applications capables de gérer les actions préprogrammées, c'est à dire qu'elles ne comportent pas d'interface de programmation d'application ('API' selon la terminologie du document HAVi) acceptant la structure de données décrite plus haut. On parlera dans ce cas de 'ressources passives'. Passif veut dire dans le contexte présent que la ressource n'a pas la caractéristique d'agenda (i.e. aucune capacité à mémoriser quelle action doit être lancée à une heure donnée). L'application initiatrice 15 de la programmation de l'action est toujours une interface localisée dans un téléviseur 16. L'appareil d'enregistrement 17 comporte la ressource d'enregistrement numérique 18, une autre ressource 19, ainsi qu'un gestionnaire des ressources 20. L'appareil 5 est identique à celui de la figure 1. Selon le présent exemple de réalisation, I'appareil 17 comporte également un gestionnaire d'actions préprogrammées 21. Ce gestionnaire d'actions 21 est un service au sens du document HAVi et effectue toutes les réservations nécessaires à l'accomplissement de l'action. Le gestionnaire d'actions 21 gère les ressources passives de l'appareil 17, mais aussi de l'appareil 5. La figure 4 est un schéma simplifié du principe du second exemple de réalisation. Pour programmer une action, une application s'adresse au gestionnaire d'actions préprogrammées, qui est obligatoirement présent dans l'appareil comportant la ressource cible. L'application agit à travers l'interface de programmation du gestionnaire d'actions, qui à son tour agit à travers l'interface de programmation de la cible. L'appareil comportant le gestionnaire et la cible est soit un appareil à fonctionnalités complètes appareil à fonctionnalités intermédiaires ('IAV'). Revendications 1. Procédé de programmation d'actions de ressources dans un réseau d'appareils domestiques caractérisé en ce qu'il comporte les étapes de: émission d'une demande de programmation d'une action par une application vers une ressource principale, - réservation de ladite ressource principale auprès de son gestionnaire de ressources local, et le cas échéant, - réservation par ladite ressource principale de ressources impliquées dans l'accomplissement de l'action auprès des gestionnaires des ressources liés à ces ressources impliquées. 2. Procédé selon la revendication 1, caractérisé en ce que cette demande comporte un identificateur de la ressource principale et le cas échéant d'autres ressources impliquées dans l'accomplissement de l'action. 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il comporte l'étape de mémorisation par ladite ressource principale d'une structure de données transmise par l'application et caractérisant l'action. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comporte en outre l'étape de mémorisation par le gestionnaire des ressources impliquées de données relatives aux horaires de l'action à effectuer. 5. Procédé selon l'une des revendication précédentes, caractérise en ce que la demande de programmation d'une action est formulée auprès d'un module logiciel distinct de la ressource principale mais localisée dans le même appareil que celle-ci, ledit module logiciel réservant ensuite la ressource principale et le cas échéant les ressources impliquées.