FR2823626A1 - Procede et dispositif de configuration d'une unite fonctionnelle ayant un caractere temporaire dans un reseau de communication - Google Patents
Procede et dispositif de configuration d'une unite fonctionnelle ayant un caractere temporaire dans un reseau de communication Download PDFInfo
- Publication number
- FR2823626A1 FR2823626A1 FR0105041A FR0105041A FR2823626A1 FR 2823626 A1 FR2823626 A1 FR 2823626A1 FR 0105041 A FR0105041 A FR 0105041A FR 0105041 A FR0105041 A FR 0105041A FR 2823626 A1 FR2823626 A1 FR 2823626A1
- Authority
- FR
- France
- Prior art keywords
- functional unit
- command
- terminal
- information
- configuration
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 37
- 230000015654 memory Effects 0.000 claims abstract description 94
- 238000000034 method Methods 0.000 claims abstract description 93
- 230000008569 process Effects 0.000 claims description 28
- 230000009471 action Effects 0.000 claims description 21
- 230000008859 change Effects 0.000 claims description 18
- 230000006870 function Effects 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 5
- 238000000605 extraction Methods 0.000 claims description 2
- 239000003086 colorant Substances 0.000 claims 2
- 238000012360 testing method Methods 0.000 description 12
- 230000004048 modification Effects 0.000 description 10
- 238000012986 modification Methods 0.000 description 10
- 230000004044 response Effects 0.000 description 9
- 239000013589 supplement Substances 0.000 description 5
- 238000010586 diagram Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- RSPISYXLHRIGJD-UHFFFAOYSA-N OOOO Chemical compound OOOO RSPISYXLHRIGJD-UHFFFAOYSA-N 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 239000010453 quartz Substances 0.000 description 1
- VYPSYNLAJGMNEJ-UHFFFAOYSA-N silicon dioxide Inorganic materials O=[Si]=O VYPSYNLAJGMNEJ-UHFFFAOYSA-N 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40123—Interconnection of computers and peripherals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Human Computer Interaction (AREA)
- Small-Scale Networks (AREA)
- Information Transfer Systems (AREA)
Abstract
Dans un réseau de communication, un procédé de lecture par un noeud contrôleur, de la mémoire de configuration d'un terminal connecté au réseau, le terminal pouvant comporter au moins une unité fonctionnelle ayant un caractère temporaire et ayant été configurée selon un procédé de configuration conforme à l'invention. Le procédé comporte les étapes suivantes : envoi (604), par le noeud contrôleur, d'une demande de lecture des informations de configuration relative à au moins une unité fonctionnelle du terminal; réception (605) par le noeud contrôleur des informations de configuration, et sauvegarde (606) de ces informations; analyse des informations sauvegardées et détermination (607) du caractère temporaire d'au moins une unité fonctionnelle correspondant à ces informations; pour chaque unité fonctionnelle dont le caractère est déterminé comme étant temporaire, mémorisation (608) de l'état initial de l'unité fonctionnelle, et mise à jour (608) automatique de l'état mémorisé en fonction des informations de configuration sauvegardées, par laquelle le changement d'état de l'unité fonctionnelle est automatiquement pris en compte dans le noeud contrôleur.
Description
2s
1 2823626
L'invention concerne un procédé de configuration d'une unité
fonctionnelle dans un terminal connecté à un réseau de communication.
L'invention concerne encore un procédé de lecture, par un nceud contrôleur connecté au réseau de communication, de la mémoire de configuration d'un terminal connecté au réseau, le terminal comportant au moins une unité fonctionnelle configurée selon un procédé de configuration
conforme à l'invention.
L'invention concerne aussi un procédé de traitement d'une commande générée par un n_ud contrôleur connecté au réseau, la commande étant destinée à un terminal connecté au réseau, le terminal comportant au moins une unité fonctionnelle configurée selon un procédé de configuration
conforme à l'invention.
L'invention concerne aussi un procédé de fourniture d'informations de configuration, ces informations étant sauvegardées par un n_ud contrôleur dans le réseau de communication, et concernant des unités fonctionnelles incorporées dans une pluralité de terminaux connectés au réscau, les informations ayant été obtenues par un procédé de configuration conforme à l'invention. L'invention concerne également des dispositifs aptes à mettre en
_uvre les procédés précités.
L'invention s'applique particulièrement à un réseau de
communication dont l'architecture est basée sur le standard IEEE 1394.
2 2823626
Le standard IEEE 1394 définit une technologie de bus série à haute vitesse destiné à interconnecter des produits d'électronique grand public et des systèmes informatiques, tels que par exemple des télévisions numériques, des ordinateurs personnels, des magnétoscopes numériques, des caméscopes numériques, des imprimantes, des télécopieurs, etc. Le standard IEEE 1394 (parfois désigné par fire wIre) définit par ailleurs des modes de communication isochrone et asynchrone pour le transfert de données, ce qui le
rend idéalement adapté aux applications multimédia.
De manière classique dans un tel système de communication, les unités fonctionnelles des dispositifs, encore appelés terminaux, connectées au bus peuvent être répertorices par un terminal appelé classiquement "contrôleur". Dans ce but, le contrôleur lit une mémoire, dite "de configuration", incorporce dans chacun des équipements connectés au bus. Selon les spécifications définies par l'association "1394 Trade Association" (TA), cette opération est appelée "protocole de découverte et d'énumération" (en anglais,
discovery and enumeration protocol).
L'opération d'énumération n'est effectuée qu'après une procébure d'initialisation du bus. Celle-ci est déclenchée lors de l'apparition d'un signal Bus_Reset sur le bus. Un tel signal peut appara^tre pour plusieurs raisons telles que, par exemple, à la suite d'une erreur lors d'une requête générée par une application, suite à la connexion d'un nouveau dispositif sur le bus, ou,
inversement, à la suite de la déconnexion d'un dispositif présent sur le bus.
Lors de la création du standard IEEE 1394 en 1995, il était communément admis qu'un terminal possédait une mémoire de configuration figée lors de sa fabrication (c.-à-d., le terminal possède une adresse unique et une mémoire de configuration figée). Cependant, récemment, il est apparu que cette affirmation n'était plus exacte, ainsi dans la nouvelle version du standard IEEE1394 en 2000 a été incluse la possibilité pour un terminal donné d'avoir une mémoire de configuration qui peut évoluer (c.-à-d., le terminal possède une
adresse unique mais une mémoire de configuration variable).
En effet, une unité fonctionnelle peut être chargée au travers d'un autre réseau de communication, par ex. I'lnternet, ou à partir d'une carte
3 2823626
mémoire amovible. Ceci est également le cas lorsque l'on procède à la mise à jour d'un équipement. Cela implique alors une modification en conséquence de
la mémoire de configuration du terminal et une réinitialisation du système.
De même, lorsqu'une unité fonctionnelle est retirée d'un terminal, la mémoire de configuration du terminal est modifiée et le système réinitialisé. Ainsi, avec les capacités croissantes des dispositifs de pouvoir changer de fonctionnalités et de pouvoir changer de configuration, dans un réseau basé sur un bus série de type IEEE 1394, les opérations de réinitialisation (bus reset) seront de plus en plus fréquentes, de manière à permettre la déclaration des nouvelles fonctionnalités sur le bus et la validation de ces changements de configuration (ajout, retrait, modification, ou mise à jour
de fonctionnalités) par le ou les contrôleurs présents sur le bus.
Dans ce contexte, la multiplication des opérations de réinitialisation de bus (bus reset) présente l'inconvénient d'interrompre' à chaque réinitialisation, le mode opératoire du bus. Cet inconvénient est d'autant plus marqué que le nombre de terminaux sur le bus ayant des capacités à
modifier dynamiquement leur configuration est élevé.
La présent invention vise notamment à apporter une solution à cet inconvénient, en proposant en particulier un mode de déclaration d'unités
fonctionnelles qui intogre un caractère temporaire desUites unités.
A cet effet, la présente invention concerne, selon un premier aspect, un procédé de configuration d'une unité fonctionnelle dans un terminal connecté à un réseau de communication, I'unité fonctionnelle étant configurée conformément à des informations de configuration contenues dans une mémoire de configuration du terminal. La mémoire de configuration est
accessible à distance au travers du réseau par au moins un n_ud contrôleur.
Ce procédé est remarquable en ce qu'il comporte, lorsque l'unité fonctionnelle à configurer présente un caractère temporaire relatif à son état de fonctionnement vis-à-vis du réscau, une étape de création, dans la mémoire de configuration, d'au moins une première information caractéristique d'une action à appliquer à l'unité fonctionnelle, et d'au moins une seconde information spécifiant la nature du caractère temporaire de cette action. En accédant
4 2823626
auxdites première et seconde informations, un n_ud contrôleur peut ainsi prendre en compte automatiquement un changement d'état de l'unité fonctionnelle. Il est ainsi possible de pré-programmer des changements d'état d'unités fonctionnelles et donc des services offerts par ces unités, et d'en informer automatiquement des n_uds contrôleurs sur le réseau sans qu'il soit
nécessaire de réinitialiser le réseau.
Selon une caractéristique particulière de l'invention, I'action à appliquer à l'unité fonctionnelle, consiste à changer l'état de l'unité fonctionnelle relatif à sa disponibilité sur le réseau. D'autre part, la nature du caractère temporaire consiste en la définition d'une durée relative à la validité dans le
temps de chaque état possible de l'unité fonctionnelle.
Outre la diminution du nombre de réinitialisations du réseau (par ex. Bus Reset), cette caractéristique permet, par exemple, de contrôler automatiquement dans le temps des autorisations d'accès à une unité
fonctionnelle donnée.
Selon un mode préféré de réalisation de l'invention, le procédé de configuration comporte en outre une étape d'initialisation de l'unité fonctionnelle, cette étape comprenant la création d'un registre mémoire dont la valeur est indicative de l'état courant de l'unité fonctionnelle, et d'un temporisateur dont l'expiration déclenche un changement d'état de l'unité fonctionnelle. Selon un deuxième aspect, la présente invention concerne un procédé de lecture, par un n_ud contrôleur connecté à un réseau de communication, de la mémoire de configuration d'un terminal connocté au réseau, le terminal pouvant comporter au moins une unité fonctionnelle ayant un caractère temporaire, configurée selon un procédé de configuration tel que brièvement défini supra. Le procédé de lecture est remarquable en ce qu'il comporte les étapes suivantes:
2823626
(a) - envoi, par le n_ud contrôleur, d'une demande de lecture des informations de configuration relatives à au moins une unité fonctionnelle du terminal; (b) - réception par le n_ud contrôleur desdites informations de configuration, et sauvegarde de ces informations; (c) - analyse des informations sauvegardées et détermination du caractère temporaire d'au moins une unité fonctionnelle correspondant à ces informations; (d) - pour chaque unité fonctionnelle dont le caractère est déterminé comme étant temporaire, mémorisation de l'état initial de l'unité fonctionnelle, et mise à jour automatique de l'état mémorisé en fonction des informations de configuration sauvegardées. Le changement d'état de l'unité fonctionnelle est ainsi automatiquement pris en compte dans le n_ud contrôleur. De cette façon, on minimise les réinitialisations du réseau nécessaires pour prendre en compte des changements de configuration des fonctionnalités présentes sur le réseau. En effet, le caractère variable (temporaire) d'une unité fonctionnelle est explicitement codé dans la mémoire de configuration et est pris en compte par un contrôleur, lors d'une procédure
dite "d'énumération" initiale.
Selon un mode particulier de réalisation, I'étape notée (d) ci-
dessus, inclut la créstion d'un registre dont la valeur est indicative de l'état initial de l'unité fonctionnelle, et la création d'un temporisateur dont l'expiration
déclenche, dans le n_ud contrôleur, une mise à jou r de la valeu r dud it registre.
Selon un troisième aspect, I'invention concerne un procédé de fourniture d'informations de configuration. Les informations sont préalablement sauvegardées par un n_ud contrôleur dans un réscau de communication, et concernent des unités fonctionnelles incorporces dans une pluralité de terminaux connectés au réseau, ces informations ayant été obtenues selon un procédé de configuration tel que brièvement décrit plus haut. Conformément à
6 2823626
I'invention, le procédé de fourniture d'informations est remarquable en ce qu'il comporte les étapes suivantes, mises en _uvre pour chacun desdits terminaux: - extraction, de la mémoire du n_ud contrôleur, des informations de configuration du terminal; - création d'une première fenêtre sur un écran de visualisation, dans laquelle sont affichées des informations générales relatives au terminal, permettant notamment à un utilisateur d'identifier le terminal considéré ainsi que la ou les unités fonctionnelles incorporées dans celui-ci; - création dans la fenêtre d'autant de premières icônes distinctes qu'il y a d'unités fonctionnelles dans le terminal, les informations spécifiques relatives à une unité fonctionnelle particulière étant accessibles à l'utilisateur en sélectionnant l'icône correspondante au moyen d'un dispositif de sélection adapté; - détermination du caractère temporaire ou non de chacune desdites unités fonctionnelles et création, pour chacune des unités fonctionnelles déterminées comme ayant un caractère temporaire, d'une icône additionnelle affichée à proximité de la première icône correspondante, I'icône additionnelle étant indicative de ce caractère temporaire, les informations relatives au caractère tempora ire de l'u n ité fonctio n nel le con sid érée éta nt accessibles à l'utilisateur en sélectionnant l'icône correspondante au moyen
d'un dispositif de sélection adapté.
Grâce à un tel procédé, mis en _uvre dans une interface utilisateur appropriée, il devient possible pour un utilisateur de reprogrammer
une unité fonctionnelle.
Selon un quatrième aspect, I'invention concerne d'une part, un procédé de traitement d'une commande par un nceud contrôleur connocté à un réseau de communication, la commande étant destinée à un terminal connecté au réseau, le terminal comportant au moins une unité fonctionnelle ayant un caractère temporaire et étant configurée selon un procédé de configuration en conformité avec la présente invention. D'autre part l'invention concerne un procédé de traitement par un terrninal connecté à un réseau de communication, d'une commande reçue via le réseau, la commande étant destince à une unité fonctionnelle incorporée dans le terminal, I'unité fonctionnelle ayant un caractère temporaire et étant configurée selon un procédé de configuration
conforme à la présente invention.
L'invention vise également un dispositif, tel qu'un système informatique, connecté à un réseau de communication, ce dispositif comportant des moyens adaptés à la mise en _uvre de tout ou partie de la pluralité de procédés tels que brièvement définis plus haut. L'invention vise aussi un réscau
de communication comportant au moins un tel dispositif.
La présente invention concerne encore un programme d'ordinateur apte à mettre en _uvre tout ou partie de la pluralité des procédés brièvement décrits supra, lorsque le programme est chargé et exécuté dans un système d'ordinateur incorporé ou constituant un terminal ou un n_ud
contrôleur connecté à un réseau de communication.
L'invention vise aussi un support d'informations, tel que par exemple, une disquette ou un compact disque (CD) contenant un tel
programme d'ordinateur.
Les avantages de ce dispositif, programme d'ordinateur, et de ce support d'informations, sont identiques à ceux des divers procédés en
conformité avec l'invention, tels que brièvement exposés supra.
D'autres particularités et avantages de l'invention appara^tront
encore dans la description ci-après.
Aux dessins annexés, donnés à titre d'exemples de réalisation non limitatifs: - la Figure 1 est un schéma blocs représentant un système IEEE 1394, composé d'équipements ou n_uds connectés sur un bus série IEEE 1394, dans lequel on peut implémenter l'invention; - la Figure 2 est un schéma blocs représentant l'architecture interne d'un n_ud, connecté au système de la Fig. 1, dans lequel on peut mettre en _uvre l'invention; - la Figure 3 représente la structure de donnces classique de la mémoire de configuration incorporée dans un n_ud tel que représenté à la Fig. 2; - la Figure 4, composée des Figs. 4A-4D, illustre la manière dont la mémoire de configuration de la Fig. 3, peut être organisée à partir de l'utilisation de clés dites "étendues"; - la Figure 5, composée des Figs. 5A-5C illustre la définition d'un nouveau jeu de clés étendues grâce auquel on peut déclarer le caractère temporaire d'une unité fonctionnelle dans un n_ud connecté sur le bus; - la Figure 6 est un organigramme illustrant les traitements exécutés, après initialisation du bus IEEE1394, par un n_ud contrôleur pour lire et analyser les mémoires de configuration incorporces dans les équipements connectés sur le bus; - la Figure 7 est un organigramme illustrant le processus de mise à jour des informations d'état d'une unité fonctionnelle ayant un caractère temporaire; - la Figure 8 est un organigramme illustrant le traitement effectué par un terminal connecté sur le bus, lors de la réception d'une demande de lecture de mémoire de configuration, en provenance d'un autre terminal connecté sur le bus; - la Figure 9 est un organigramme illustrant un procédé de fourniture d'informations de configuration relatives aux n_uds connectés à un bus IEEE1394, le procédé étant mis en _uvre par un dispositif contrôleur; - La Figure 10 est un organigramme illustrant la procédure mise en _uvre dans un terminal pour effectuer une modification de sa mémoire de configuration; - La Figure 11 est un organigramme illustrant un processus mis en _uvre par un terminal contrôleur pour émettre une commande, via un bus IEEE1394, à destination d'un terminal comportant une unité fonctionnelle ayant un caractère temporaire; - La Figure 12 est un organigramme illustrant le processus mis en _uvre par un terminal connecté à un bus IEEE1394, lors de la réception d'une commande à destination d'une unité fonctionnelle ayant un caractère
temporaire, incorporée dans le terminal.
La FIG. 1 est un schéma blocs représentant un exemple de réseau de communication dans lequel on peut implémenter l'invention. Le réseau ou système IEEE1394 représenté à la FIG. 1, est composé
d'équipements ou n_uds connectés sur un bus série IEEE1394.
Dans cet exe mple, on retrouve successive ment, con nectés au bus IEEE1394, un récepteur satellite 1, un récepteur de télévision numérique 2, un lecteur de disques vidéo numériques (DVD) 3, un ordinateur personnel (PC) 4 connecté à Internet par l'intermédiaire d'un modem 10 et comportant un lecteur
de carte mémoire 11, un caméscope numérique (DVCR) 5 et une imprimante 6.
Chacun de ces dispositifs constitue un n_ud pour ce réseau de communication bâti autour du bus IEEE1394. Dans cet exemple, l'ordinateur personnel (PC) 4
eVou la télévision numérique 2 peuvent assurer le rôle de n_ud contrôleur.
Le bus IEEE 1394, représenté ici par des connecteurs 8 et des câbles 9, est basé sur le standard IEEE1394-1995 et son supplément IEEE1394a-2000. Par ailleurs, chacun de ces n_uds inclut une mémoire de configuration compatible avec les standards IEEE1212-2000 et IEEE1394a
2000.
En bref, le standard IEEE1394 décrit un bus série haute vitesse à bas coût incluant: - une couche physique pour différents média physiques; - un mécanisme d'accès au bus; - un mécanisme d'allocation automatique d'adresses; - deux modes de communication isochrone et asynchrone;
- des fonctions de contrôle du bus.
Le standard IEEE1212 décrit quant à lui une architecture de registres de contrôle et d'état pour un bus, incluant: - un système d'adressage; - un jeu de messages minimum; - un jeu de registres de contrôle et d'état; - la structure d'une mémoire de configuration avec un jeu de clés. On pourra se reporter aux spécifications de ces standards pour
obtenir de plus amples détails.
En liaison avec la FIG. 2, on va décrire maintenant l'architecture interne d'un n_ud IEEE1394 tel que représenté à la FIG. 1, dans lequel on
peut mettre en _uvre l'invention selon un mode préféré de réalisation.
L'architecture du n_ud est de type système informatique bâti autour d'un processeur. Comme représenté à la FIG. 2, le n_ud 101 comporte un processeur 104 chargé d'exécuter les instructions des programmes stockés dans une mémoire non volatile ROM 103 et notamment le ou les programmes nécessaires à la mise en _uvre de l'invention. Les données nécessaires (c'est à-dire les "variables") au processeur 104 pour l'exécution des programmes,
sont stockées dans une mémoire volatile RAM 108.
Le n_ud 101 comporte un module 107 contenant une ou plusieurs unités fonctionnelles. Par exemple, le n_ud constitué du dispositif de lecture DVD 3 (Fig. 1) comporte une unité fonctionnelle de décodage vidéo
MPEG2 et une unité fonctionnelle de lecture de disques DVD.
Un espace mémoire, constituant la mémoire de configuration du n_ud, est associé au module 107. La mémoire de configuration contient les informations caractéristiques liées à la configuration de ou des unités fonctionnelles contenues dans le module fonctionnel 107. Il est à noter qu'un
dispositif 101 peut comporter plusieurs modules 107.
La mémoire de configuration du n_ud ainsi qu'une sauvegarde de celle-ci, est aménagée dans un composant mémoire 106 de type non volatile et réinscriptible, par exemple une mémoire FLASH. Cependant, selon une variante d'implémentation, la mémoire de configuration peut utiliser la mémoire FLASH 106 ainsi que la mémoire ROM 103. Dans ce cas la mémoire ROM contient les informations de configuration qui sont figées (c.-à-d., fixes, statiques) tandis que la mémoire FLASH contient les informations susceptibles
de changer (c.-à-d., dynamiques).
Un bus interne local 109 relie entre eux les différents éléments du
n_ud 101 et assure ainsi leur interopérabilité.
Le n_ud 101 comporte également une interface utilisateur 105 pouvant comprendre, par exemple, un écran, un clavier, une souris, un lecteur de carte mémoire, un modem, des diodes électroluminescentes (LED) ou des boutons. L'interface utilisateur 105 permet à un utilisateur d'entrer des commandes qui seront transmises au processeur (CPU) 104 par l'intermédiaire
du bus local 109, avant d'être interprétées par celui-ci.
Le noeud 101 comporte également une horloge temps réel 110
permettant de fournir au n_ud une date système (datè/heure/minute/seconde) .
En outre, le n_ud 101 comporte une interface de communication 102 basée sur le standard IEEE1394-1995 et son supplément IEEE1394a 2000. Cette interface permet l'échange de donnces entre le module fonctionnel 107 du n_ud considéré et un module similaire d'un autre n_ud connecté sur le bus. Finalement, le n_ud 101 est connecté à un bus série IEEE1394 (9) au
moyen de connecteurs 8.
La FIG. 3 représente la structure de donnces classique de la mémoire de configuration incorporée dans un n_ud tel que représenté à la
FIG. 2.
La structure de la mémoire de configuration exposoe ici, en liaison avec la FIG. 3, est compatible avec les standards IEEE1212-2000 et
1 EEE 1394a-2000.
Comme représenté à la FIG. 3, la mémoire de configuration comprend notamment une sous-partie 31 appelée "Bus Information Block", BIB, (bloc d'information de bus); une sous-partie 32 appelée "Roof Director/' (répertoire racine); une ou plusieurs sous-parties appelées "Unif Director/' (répertoire d'unité) optionnelles; enfin une zone 34 relative à des informations
spécifiques au constructeur (Other vendor dependent information).
La sous-partie Bus_lnfo_Block (BIB) 31 contient des informations qui précisent les caractéristiques du bus de communication, ici de type IEEE 1394. Les différents champs s'y rapportant sont définis en section 8.3.2. 5.4 du
standard IEEE1394-1995 et en section 8.3.2.5 du supplément IEEE1394.a-
2000. Il est à noter que parmi ces champs, le champ "generation" (en gras sur la figure) est utilisé pour indiquer un changement dans la mémoire de configuration. A cet effet, la donnée qu'il contient est incrémentée à chaque modification de la mémoire de conflguration, cependant sans pouvoir reprendre
une valeur déjà utilisoe au cours des 60 secondes précédentes.
La sous-partie Root_Directory (32) contient des informations générales (par exemple le fabricant) sur le terminal correspondant à la mémoire de configuration considérée, ainsi que des pointeurs, par exemple dans le champ "unit_directory_offset" (en gras sur la figure), pointant sur des
informations plus détaillées.
Pour obtenir plus d'informations sur les différents champs pouvant être utilisés dans cette sous-partie, on pourra se rapporter à la section 7.6 du
standard I EEE 1212-2000.
Par ailleurs, d'autres documents viennent compléter les définitions générales contenues dans les spécifications des standards IEEE1212-2000 et IEEE1394a-2000. Ainsi, on pourra se reporter au document "Configuration ROM for A V/C devices 1.0", en date du 15 mars 2000, publié par l'association "1394 Trade Association" (TA), et au document "The HA VI Architecture version 0.8", en date du 11 mai 1998, publié par le consortium HAVI. Dans ces document, il est défini des règles supplémentaires pour l'interopérabilité des
équipements répondant à leurs spécifications respectives.
Conformément au standard IEEE1212-2000, les informations contenues dans les sous-parties Root Directory (32) et Unit Directory (34) de la mémoire de configuration illustrée ici sont structurées grâce à l'utilisation de clés. Une clé est un indicateur de la donnée qui la suit, le couple {clé, donnée} formant ainsi un "tout" compréhensible, par exemple par un dispositif contrôleur extérieur. Chaque clé est identifiée dans la mémoire de configuration par un
identiflant.
Ainsi dans la sous-partie Root Directory représentée à la FIG. 3, I'identifiant '03' (en hexadécimal, c.-à-d.,"OOOO 0011" en binaire sur 8 bits) id entifie la clé correspo nd ant au mod u le fab ricant (module_vendor_id). Le champ qui suit les 8 bits correspondant à l'identifiant de la clé contient les
données correspondant au module fabricant.
De même, dans la sous-partie unit_directory 33 de la mémoire de configuration, les clés ayant pour identifiant, respectivement, '12' et '13' (en hexadécimal) précèdent, respectivement, la donnée définissant le type d'unité fonctionnelle (champ unif_spec_id), et celle définissant la version du code logiciel correspondant à cette unité fonctionnelle (champ unif_soffware_version). Comme cela sera détaillé dans la suite de l'exposé, selon le mode préféré de réalisation de l'invention décrit ici, on utilisera principalement le champ "generation" de la partie BIB 31 de la mémoire de configuration ainsi qu'un jeu spécifique de clés dites "étendues" défini dans la sous-partie
"Unit_Director/' (33) de la mémoire de configuration.
La FIG. 4 illustre ia manière dont est structurce une mémoire de configuration telle que représentée à la FIG. 3, en liaison avec l'utilisation de "clés étendues" telles que définies dans la nouvelle révision du standard
IEEE1212-2000 (section 7.5.2).
La FIG. 4A reprend le format d'une sous-partie d'une mémoire de configuration relatif à l'utilisation de clés, tel que décrit précédemment en relation avec la FIG. 3. Comme représenté à la Fig. 4A, un tel sous-ensemble de la mémoire (par ex., la sous-partie unit_directory), comporte d'abord un champ "length" contenant une information correspondant à la taille du sous ensemble considéré, suivi d'un champ "crc" (Cyc/ic Redundancy Checks) contenant une information relative à la détection d'erreurs. Ensuite, la sous partie considérce comporte des "couples" {clé, donnce} successifs (champs key
et data), chaque couple représentant une "ligne" de la sous-partie considérée.
Par exemple, une clé "fabricant" (vendor en anglais) sera suivie du nom du
fabricant sous forme textuelle ou codé, selon la définition de la clé.
Dans la nouvelle révision du standard IEEE1212-2000 section 7.5.2, on définit le concept de "clé étendue" (extended key). Selon ce concept, il
est possible de définir un jeu de clés étendues associé à une entité particulière.
Chaque jeu de clés étendues utilise plusieurs "lignes" ou couples {clé, donnee} classiques d'une sous-partie de la mémoire de configuration, tels que définis
plus haut.
Chaque jeu de clés étendues comporte d'abord, en utilisant un premier couple {clé, donnée} classique, une information indiquant que l'information qui suit identifie un jeu de clés, suivi d'un identificateur de l'organisation ou du fabricant responsable du jeu de clés considéré. Ce jeu de clés est valide uniquement pour le sous- ensemble considéré (par exemple un
"Unit_Dlrectory') tant qu'un autre jeu de clés n'est pas choisi.
Dans un couple {clé, donnée} classique suivant en mémoire, on identifie d'abord que l'information qui suit identifie une clé étendue particulière, puis on donne l'identificateur de la clé. Enfin, dans un troisième couple {clé, donnée}, on identifie d'abord que la donnce qui va suivre est la valeur donnce à la clé étendue identifiée dans le couple {clé, donnce} précédent, puis on fournit cette valeur. Il y a autant de "troisième couple" {clé, donnée} que de clésétendues dans le jeu considéré.
Les FlGs. 4B-4D illustrent le format d'un jeu de clés étendues comportant une seule clé. Ainsi, dans cet exemple, le jeu de clés étendues
utilise 3 couples {clé, donnée} successifs.
A la FIG. 4B, le champ clé contenant la valeur '1 C' en hexadécimal ('00011100' èn binaire) indique que le champ donnée qui suit
(champ Extended_Key_Specifier ID) identifie un jeu de clés étendues.
A la FIG. 4D, le champ clé contient la valeur '1 D' en hexadécimal indiquant que le champ donnée qui suit (champ Extended_key_lD), identifie une clé étendue particulière du jeu (dans cet exemple, cette clé étendue est unique). Enfin, à la FIG. 4C, le champ clé comprend une première partie "type" indiquant la localisation dans la mémoire du champ donnce qui suit (type = '00' en binaire, signifie que le champ donnce est contigu). Le champ clé comprend une seconde partie, valant'1E' en hexadécimal sur6 bits ('01 1110' en binaire), indiquant que le champ donnce qui suit (champ value), contient la
1 5 2823626
valeur associée à la clé étendue identifiée dans le champ Extended_key_lD qui précède. La FIG. 5, composée des FlGs. 5A-5D illustre la définition d'un nouveau jeu de clés étendues grâce auquel on peut déclarer le caractère temporaire d'une unité fonctionnelle dans un n_ud connocté sur un bus série
de type IEEE 1394.
Ce jeu de clés étendues utilise, dans une mémoire de configuration, le format décrit précédemment en relation avec la FIG. 4. Par ailleurs, ce jeu de clés permet conformément à l'invention de spécifier un type d'actions avec, par exemple, une date d'activation ou une durée d'exécution, pour l'unité fonctionnelle correspondant au sous-ensemble (Unit_Directory) dans lequel ce jeu est présent. Une action pourra être par exemple, la validation
ou l'invalidation de l'unité fonctionnelle correspondante.
Le tableau de la FIG. 5A résume un jeu de clés étendues pouvant être utilisé conformément à l'invention pour spécifier des actions liées au
caractère temporaire d'une unité fonctionnelle.
- La colonne du tableau référencée par l'étiquette "Extended_Key_lD" correspond au champ du même nom représenté à la FIG. 4C. Dans cette colonne, chaque ligne du tableau identifie de manière unique une clé étendue particulière du jeu. La colonne du milieu référencée par l'étiquette "Nom" fournit le nom attribué à la clé identifiée par la donnce correspondante de la colonne de gauche. Enfin, la colonne de droite référencée par l'étiquette "Utilisaflon de l'entrée Extended_Key_lD", spécifie le type d'action
engendrée par l'utilisation de la clé.
Ainsi, à la première ligne de la colonne de gauche du tableau, une première clé est identifiée par l'identifiant: "actf616fmt,6", o "act,6" est un champ dont la valeur (hexadécimale) variable est indicative du type d'action à mettre en _uvre; et "fmt,6" est un champ dont la valeur (hexadécimale) variable permet de
paramétrer dans le temps le type d'action défini par la donnce actf6.
Cette clé est nommée (colonne du milieu) "Fct_temp_durce", et, selon la définition à la colonne de droite du tableau, cette clé permet de spécifier une action (dont le type est paramétré par le champ "act") appliquce pendant une
durce dont le format est paramétré par le champ "fmf'.
De même, à la seconde ligne du tableau, une seconde clé identifiée par l'identifiant "act626fmt6" est nommée "Fct_temp_date", et permet de spécifier une action (dont le type est paramétré par le champ "acf') qui est déclenchée à
une date dont le format est paramétré par le champ "fmt".
Selon la troisième ligne du tableau, une troisième clé identifiée par "act636fmt6" avec fmt ayant une valeur fixée égale à '3' (en hexadécimal), est nommée "Fct_temp_cycle" et permet de spécifier une action (dont le type est paramétré par le champ "act") en fonction d'un registre dit "registre de temps de
cycle" (cycle time register- CTR) et au format paramétré par le champ "fmt".
L'action spécifiée est alors une action de type périodique lice à la valeur d'un
champ "cycle" du registre CTR du terminal considéré.
Le registre CTR est contenu dans une mémoire locale du terminal considéré connecté au bus, et contient une valeur de temps, contenue dans le champ cycle permettant de définir une date commune à tous les n_uds présents sur le bus. Le registre CTR est cadencé par une horloge matérielle à base de quartz présente dans le dispositif. Dans une implémentation préférée, cette horloge possède une fréquence de 24,576 MHz. Périodiquement la valeur de temps contenue dans chaque registre CTR est synchronisée par un système ma^tre d'horloge (clock master) présent sur le bus. De cette façon, tous les
systèmes présents sur le bus possèdent la même référence de temps.
De retour à la FIG. 5A, à la dernière ligne du tableau, une quatrième clé identifiée par "act646fmt6" avec les champs act et fmt ayant une valeur fixée égale à '0' (en hexadécimal), et nommée "Fct_temp_calendrier,', permet de
spécifier un calendrier.
Comme exposé ci-dessus, selon la valeur attribuce aux champs act et fmt, I'action spécifiée par la clé concernée est différente. L'interprétation des valeurs attribuces à ces champs permet de définir le format du champ "value" (valeur), de la clé étendue considérée, tel que décrit précédemment en liaison
avec la FIG. 4D.
A titre d'exemple, on donne ci-dessous l'interprétation des champs act et
fmt en fonction de certaines valeurs prédéterminées.
À Valeurs attribuées au champ"acf'
act ='O': valeur non significative.
act = '1': unité fonctionnelle non disponible.
act = '2': unité fonctionnelle disponible.
act = autre: disponible pour attribution future.
À Valeurs attribuces au champ "fmt"
fmt = 'O': valeur non significative.
fmt = '1': format: annce / mois / jour.
fmt = '2': format: jour-de-la-semaine / heures
/ minutes / secondes.
fmt = '3': nombre de cycles isochrones.
fmt = autre: disponible pour attribution future.
Les FlGs. 5B-5D illustrent différents formats du champ "value" (valeur)
tel que défini à la FIG. 4D, en fonction de la valeur attribuée au champ fmt.
Ainsi, la FIG. 5B illustre le format du champ "value" d'une clé étendue en conformité avec l'invention, lorsque le champ fmt vaut '1', c.-à-d., lorsqu'il
correspond à un format: année / mois / jour.
La FIG. 5C illustre le format du champ "value" d'une clé étendue en conformité avec l'invention, lorsque le champ fmt vaut '2', c.-à-d., lorsqu'il
correspond à un format: jour-de-la-semaine (jds) / heures / minutes / secondes.
A titre d'exemple, si le "sous-champ" jds du champ value vaut '0000000'
(en binaire sur 7 bits) cela signifie que ce champ n'est pas utilisé. Si le sous-
champ jds vaut '1000000' cela signifie "lundi"; si jds vaut '0100000' cela signifie
"mardi"; si jds vaut '1100000' cela signifie "lundi et mardi".
La FIG. 5D illustre le format du champ "value" d'une clé étendue en conformité avec l'invention, lorsque le champ fmt vaut '3', c.-à-d., lorsqu'il correspond à une action périodique dans le temps appliquée à l'unité fonctionnelle concernée par cette clé. Le champs "value" de cette clé comporte en particulier un sous-champ "init" indiquant une valeur initiale et un sous champ "modulo" permettant de définir la périodicité de l'action. Plus spécifiquement, I'action préalablement définie par le champ act (voir supra), est active lorsque l'équation suivante est vérifice: la valeur du champ cycle du
registre CTR modulo 2x (2 à la puissance X) est égale à la valeur du sous-
champ init, avec X étant la valeur (décimale) du sous-champ modulo. La quatrième clé, nommée"Fct_temp_calendrieY', définie à la FIG. 5A, permet, en spécifiant un calendrier, de combiner l'utilisation des trois clés précédentes de maniè re séquentielle da n s le tem ps. De même qu e l es autres clés étendues, cette clé comporte un champ value dans une paire classique {clé, donnée} telle qu'illustré à la FIG. 4D, le champ value indiquant la longueur
du bloc définissant le calendrier.
En référence à la FIG. 6, on va décrire les traitements exécutés par un n_ud contrôleur, après initialisation du bus IEEE1394, pour lire et analyser les mémoires de configuration incorporées dans les équipements
connectés sur le bus.
Lors de chaque initialisation du bus (Bus Reset), le contrôleur
archive dans sa mémoire locale la liste des n_uds (terminaux) présents (c. -à-
d., connectés) sur le bus. Cette liste contient, pour chaque n_ud, un identificateur du n_ud et son adresse logique. La liste peut être stockée en mémoire non-volatile (par ex. mémoire FLASH 106, Fig. 2) ou bien en mémoire RAM (108). Dans ce dernier cas, la liste est recopiée en mémoire non volatile
avant un arrêt du contrôleur.
Ensuite, comme illustré à l'étape 601, pour chaque équipement dont l'adresse est présente dans la liste de terminaux précitée, le contrôleur
effectue, au travers du bus IEEE1394, une demande de lecture du sous-
ensemble "Bus Information BlocK' (BIB) de la mémoire de configuration de
l'équipement considéré.
Puis on passe au test de l'étape 602 dans laquelle le contrôleur attend une réponse à sa demande de lecture. Lorsque le contrôleur reçoit une réponse à sa demande de lecture - c.-à-d., un paquet est envoyé par le n_ud considéré contenant l'information BIB de ce n_ud - on passe à l'étape 603 dans laquelle le contrôleur vérifie s'il a déjà archivé la mémoire de configuration de cet équipement. Cela est réalisé en vérifiant dans le sous-ensemble "Bus Information BlocK' que pour le couple node_vendor lD et chip_lD (cf. Fig. 3, 31) considéré, le champ generation associé n'a pas changé depuis la précédente lecture du sous-ensemble "Bus Information BlocK' relatif à ce n_ud. Dans la négative, on passe au test 609 pour vérifier s'il existe un autre équipement connecté au bus dont le sous-ensemble "Bus Information BlocK' n'a pas encore été lu. Dans la négative, cette procédure se termine;
dans le cas contraire, on revient à l'étape 601 précédemment décrite.
Dans l'affirmative au test 603, c'est-à-dire lorsque la mémoire de configuration du n_ud considéré a changé ou s'il s'agit de la première lecture du sous-ensemble "Bus Information BlocK' (ce qui est détecté par un couple
node_vendor_lD et chip_lD inconnu), on passe à l'étape 604.
A l'étape 604, le contrôleur commence par archiver (c.-à-d.
mémoriser) le sous-ensemble BIB reçu, puis il effectue l'opération proprement dite de lecture de la mémoire de configuration du n_ud considéré. Pour cela, le contrôleur effectue, au travers du bus IEEE1394, une demande de lecture de la partie de la mémoire de configuration associée au sous-ensemble "BIB" préalablement archivé, il s'agit en particulier du sous-ensemble "Unit_Director/'
(cf. Fig. 3, 33) de la mémoire de configuration.
On passe alors à l'étape de test 605, dans laquelle le contrôleur attend une réponse à cette demande. Lorsque la réponse à la demande de lecture est reçue par le contrôleur, celui-ci, à l'étape 606, archive en mémoire la copie de la mémoire de configuration contenue dans la réponse en provenance
de l'équipement considéré.
A l'étape suivante 607, on détermine si la copie de la mémoire de
configuration reçue et archivée est relative à une unité fonctionnelle temporaire.
A cette fin, la (copie de la) mémoire de configuration est parcourue afin d'y détecter au moins une clé étendue du type de celles décrites précédemment en
liaison avec le tableau de la FIG. 5A.
Dans l'affirmative, la mémoire de configuration est analysée. Puis, à l'étape 608, pour chaque unité fonctionnelle temporaire identifiée, on procède
à la validation de cette unité. A cet effet, un registre représentant l'état de celle-
ci est initialisé, et un temporisateur (timer en anglais) permettant de détecter le
prochain changement d'état de l'unité fonctionnelle considérée est déclenché.
Enfin, toujours à cette étape, une procédure de mise à jour (décrite plus loin en liaison avec la FIG. 7) est activoe à l'échéance du temporisateur précité. On
passe ensuite à l'étape de test 609.
Inversement, si aucune unité fonctionnelle ayant un caractère temporaire, n'est identifice, on passe directement à l'étape de test 609, dans laquelle on vérifie s'il existe un autre équipement connecté au bus dont le sous ensemble "Bus Informaflon BlocK' n'a pas encore été lu, c'est-àdire si la liste susmentionnce des n_uds connectés au bus n'a pas encore été entièrement parcourue. Si c'est le cas, on passe à nouveau à l'étape 601 et le processus recommence tel que décrit précédemment. Au contraire, si tous les n_uds
connectés au bus ont été testés, la procédure se termine là.
Comme mentionné précédemment, il est implémenté dans le n_ud contrôleur, pour chaque unité fonctionnelle temporaire relative à un équipement donné connecté sur le bus: - d'une part un temporisateur, dont la valeur initiale est fixée selon le format du champ "value" de la clé étendue correspondant à cette unité fonctionnelle dans la mémoire de configuration de cet équipement (voir plus
haut description relative à la Fig. 5);
- d'autre part un registre, appelé ci-après "registre d'état", dont la valeur est indicative de l'état de l'unité fonctionnelle; - enfin, un processus de mise à jour de l'état de l'unité fonctionnelle considérée est activée à échéance du temporisateur (c.-à-d.,
lorsque la durce codée dans le temporisateur est expirée).
L'état de l'unité fonctionnelle considérée est détermince par le type d'action associée à la clé étendue qui gère cette unité. Ainsi, dans l'exemple donné plus haut en liaison avec la FIG. 5A, selon la valeur attribuée au champ act de la clé considérée, I'état de l'unité pourra être disponible (act = 2') ou non-disponible (act = '1'). Cependant on peut prévoir d'autres valeurs de
21 2823626
ce champ ayant d'autres significations, comme par exemple, "partiellement disponible". Le processus de mise à jour, exécuté dans le contrôleur, permet à celui-ci d'être continuellement "informé" des changements d'état de fonctionnalité de tous les dispositifs connectés sur le bus, dont il assure la supervision (sans générer d'échanges de paquets de contrôle supplémentaires et en diminuant le nombre de Bus Reset). Ainsi, à titre d'exemple, le contrôleur peut avoir pour fonction de contrôler à distance un dispositif tel qu'une
télévision numérique ou bien une caméra, connectées sur le bus.
En liaison avec la FIG. 7, on va maintenant décrire le processus de mise à jour des informations d'état d'une unité fonctionnelle ayant un caractère temporaire. Ce processus est mis en _uvre au cours de l'étape 608 de la FIG. 6 comme exposé plus haut. Il est à noter qu'un processus similaire est également mise en _uvre dans un équipement comportant une unité fonctionnelle temporaire, afin de gérer le caractère temporaire de cette
fonctionnalité (voir, infra, description en liaison avec Fig. 10).
Comme illustré à la FIG. 7, le processus de mise à jour de l'état d'une unité fonctionnelle, commence par une étape de test, 701, dans laquelle il est déterminé si le temporisateur associé à l'unité fonctionnelle considérée est
expiré ou non.
Si c'est le cas, cela signifie que l'unité fonctionnelle, dans le dispositif qui l'héberge, doit changer d'état conformément à la condition codée dans le champ value de la clé étendue correspondante. Dans ce cas, à l'étape 702 on procède à la mise à jour de cet état, conformément à la clé étendue de cette unité, en modifiant la valeur contenue dans le registre d'état dédié à cette unité dans la mémoire du contrôleur. Ensuite, on retourne à l'étape 701 dans
laquelle on teste le temporisateur.
Au contraire, à l'étape 701, si le temporisateur n'est pas échu, on passe à l'étape 703, dans laquelle on détermine si un signal d'initialisation du bus (Bus Reset) a été reçu dans le contrôleur. Dans la négative, on retourne à
l'étape 701.
22 2823626
Si au contraire, un signal Bus_Reset a été reçu dans le contrôleur via le bus, on passe alors à l'étape 704 dans laquelle on met à jour le crédit de temps relatif à l'unité fonctionnelle considérée, lorsque l'on utilise une clé étendue du type Fct_temp_durée, comme défini plus haut en liaison avec la FIG. 5A. On repasse ensuite à l'étape de test 701. Il est à noter qu'un signal Bus Reset est émis sur le bus, en particulier lors de la mise en service d'une unité fonctionnelle dans un terminal connecté
sur le bus, et lors de la mise en service d'un nouveau contrôleur sur le bus.
* Selon une première implémentation, I'apparition d'un signal Bus_Reset sur le bus n'a pas d'influence sur le déroulement du temporisateur associé à l'unité fonctionnelle considérée. Lors du redémarrage du bus, la mémoire de configuration (c.-à-d. Ie temporisateur) de l'unité fonctionnelle est mise à jour (étape 704) avec la valeur de temps restant à courir avant le
prochain changement d'état (crédit de temps).
A titre de variante, selon une autre implémentation, I'apparition d'un signal Bus_Reset sur le bus provoque la réinitialisation du temporisateur de l'unité fonctionnelle considérée, I'étape de mise à jour (704) consiste alors à remettre le temporisateur dans sa valeur initiale, selon la mémoire de configuration (valeur initiale définie par le champ va/ue de la clé étendue
corres pond ante).
La FIG. 8 représente le traitement effectué par un terminal (contrôleur ou non) lors de la réception d'une demande de lecture de sa mémoire de configuration en provenance d'un autre terminal connecté sur le bus (contrôleur ou non). En particulier, il s'agit d'une demande de lecture telle
que décrite plus haut, en liaison avec la FIG. 6, étape 601.
Comme illustré à la FIG. 8, le processus débute, à l'étape 801, par la réception dans le terminal considéré d'une demande de lecture de sa mémoire de configuration. Cette demande de lecture est. dans le cadre du mode de réalisation exposé, constituée par un paquet de donnces asynchrone de type "Read_Request" tel que défini par le standard IEEE 1394-1995, et reçu par le terminal considéré, au travers de son interface physique IEEE1394 (Fig. 2, 102). Toujours au cours de la même étape, la demande reçue est stockée
localement en mémoire, de façon à l'analyser.
Une fois la demande analysée, la réponse est élaborce, à l'étape 802 qui suit. Cette réponse est. selon le mode de réalisation décrit, constituce d'un paquet de données asynchrone de type "Read_Response" tel que défini par le standard IEEE 1394-1995. Cette réponse prend en compte les informations contenues dans la demande de lecture, en particulier, les adresses
source et destination, l'adresse de lecture.
Ensuite, on passe à l'étape 803, dans laquelle la réponse élaborée est envoyée sur le bus IEEE 1394, au travers du contrôleur de liaison IEEE1394 et l'interface physique IEEE1394, à destination de l'émetteur de la
demande de lecture.
Les paquets asynchrones utilisés pour la demande de lecture ainsi que pour la réponse associée, sont définis en section 6.2.2 du standard
IEEE1394-1995.
En liaison avec la FIG. 9, on va maintenant décrire un procédé de fourniture d'informations de configuration concernant un ensemble de n_uds
connectés à un bus IEEE1394.
Ce procédé est mis en _uvre par un contrôleur pour fournir à un utilisateur des informations relatives aux unités fonctionnelles des n_uds supervisés par le contrôleur. A cet effet, le contrôleur utilise une interface utilisateur (portant la référence 105 à la Fig. 2), de type interface graphique, comportant par exemple un écran de visualisation. L'interface utilisateur peut ainsi présenter les informations sous une forme textuelle ou graphique avec ou non utilisation du multi-fenêtrage. Dans le mode de réalisation préféré de
l'invention, l'interface graphique utilise le multi-fenêtrage.
Comme illustré à la FIG. 9, le processus d'affichage commence par une étape 901, dans laquelle le contrôleur lit les informations de configuration relatives aux différents n_uds, qui ont été prénlablement archivées dans sa mémoire, selon la procédure décrite plus haut, en liaison
avec la FIG. 6.
A l'étape suivante, 902, les informations générales concernant un premier terminal sont extraites et affichées à l'écran. A cet effet, une nouvelle fenêtre graphique est créée à l'écran dans laquelle sont affichées les informations générales relatives à ce terminal, permettant notamment à I'utilisateur d'identifier le terminal considéré, et comportant par ex. Ia liste des
unités fonctionnelles incorporées dans le terminal.
A l'étape suivante (903), on procède à l'affichage des informations concernant une première unité fonctionnelle (désignée sur la figure par le terme "fonction", dans un but de simplification). A cet effet, une icône est affichée, et les informations détaillées concernant cette fonction (p. ex., port d'entrée, port de sortie, nom, fabricant, performance...) sont accessibles à i'utilisateur, en
cliquant par ex. sur l'icône avec une souris.
L'étape qui suit, 904, est une étape de test, dans laquelle on détermine si cette unité fonctionnelle comporte un caractère temporaire. Dans
la négative, on passe à l'étape suivante (906).
Inversement, si c'est le cas, une icône additionnelle (représentant par ex. un chronomètre) indiquant ce caractère temporaire, est affichée (étape
905) sur l'écran, à proximité de l'icône relative à l'unité fonctionnelle considérée.
L'utilisateur pourra alors consulter les informations relatives au caractère
temporaire de l'unité considérée, par ex. en cliquant sur l'icône additionnelle.
Par ailleurs, afin que l'utilisateur puisse être immédiatement informé de l'état de cette fonction temporaire, une couleur d'arrière-plan ou bien une icône de forme particulière sera utilisée selon que la fonction est disponible ou non, la couleur
ou la forme étant donc mise à jour à chaque changement d'état de la fonction.
On passe ensuite à l'étape 906 dans laquelle on détermine s'il
existe une autre unité fonctionnelle, concernant le terminal considéré, à afficher.
Si c'est le cas, on retourne à l'étape 903 et le processus recommence comme
décrit précédemment.
Dans le cas contraire, on passe à l'étape 907 dans laquelle on détermine s'il existe un autre terminal pour lequel des informations de configuration archivées n'ont pas encore été affichées. Dans l'affirmative, on retourne à l'étape 902 et le processus recommence comme décrit
précédemment. Dans la négative, le processus d'afffichage est terminé.
La FIG. 10 représente illustre la procédure mise en _uvre dans un terminal pour effectuer une modification de la mémoire de configuration du terminal, soit lors de l'ajout de manière dynamique d'une unité fonctionnelle à ce terminal, soit suite à une demande de reconfiguration d'une unité
fonctionnelle existante par un contrôleur.
L'ajout dynamique d'une nouvelle fonction peut être réalisé par ex., grâce à l'introduction d'une carte mémoire dans le terminal, ou encore par
I'intermédiaire d'un téléchargement via un réseau externe (par ex. I'lnternet).
D'autre part, une demande de reconfiguration d'une unité fonctionnelle existante par un contrôleur sur le bus IEEE1394 peut être requise par ex., pour mettre à jour les informations relatives au fabricant, ou bien pour
contrôler l'accès à cette unité fonctionnelle.
Comme illustré à la FIG. 10, le processus de modification commence par l'étape 1001 dans laquelle on met à jour les informations relatives à l'unité fonctionnelle considérée, en particulier en mettant à jour le sous-ensemble "Unif_Director/' de la mémoire de configuration (cf. supra,
description en liaison avec la Fig. 3).
A l'étape suivante, 1002, on détermine s'il s'agit d'une fonction ayant un caractère temporaire, en consultant le contenu de la mémoire de configuration s'y rattachant (c.-à-d., sous-ensemble Unif_Direclory) pour y
détecter la présence de clés étendues selon l'invention.
Si c'est le cas, on passe à l'étape 1003, dans laquelle on initialise I'état de la fonction temporaire (par ex. "d isponible" ou "non-d isponible"), ainsi qu'un temporisateur avec une valeur qui détermine le prochain changement d'état de l'unité fonctionnelle, enfin un registre est également créé, dont la valeur est indicative de l'état de l'unité fonctionnelle. On passe alors à l'étape
1 004.
Si lors du test 1002, on détermine qu'il ne s'agit pas d'une unité fonctionnelle ayant un caractère temporaire, on passe directement à l'étape
1 004.
A l'étape 1004, on modifie le champ "generation" du sous-
ensemble "Bus Information BJocK' du terminal, conformément au supplément IEEE1394.a-2000, section 8.3.2.5, afin que le ou les contrôleurs connectés au bus IEEE1394 soient informés d'une modification de la mémoire de configuration de ce terminal lors de l'apparition de la phase d'initialisation du
bus (Bus Reset) suivante.
Finalement, à l'étape 1005 qui suit, on provoque la réinitialisation
du bus IEEE1394 en générant un signal Bus Reset sur le bus.
En liaison avec la FIG. 11, on va maintenant décrire la procédure mise en _uvre par un terminal contrôleur pour émettre une commande, via le bus IEEE1394, à destination d'un terminal comportant une unité fonctionnelle
ayant un caractère temporaire.
Il s'agit du cas o une application logicielle tournant sur le dispositif contrôleur requiert l'envoi d'une commande à destination d'une unité fonctionnelle (dite "cible") résidant dans un terminal connecté au bus IEEE1394, contrôlé par le dispositif contrôleur. Par exemple, dans le cas du contrôle à distance d'une caméra, il peut s'agir d'une commande telle que l'arrêt de
l'enregistrement sur la cassette chargée dans la caméra.
Comme illustré à la FIG. 11, le processus d'envoi d'une commande commence par l'étape 1101 dans laquelle l'envoi d'une commande
à destination d'une unité fonctionnelle (c.-à-d., fonction) distante est requis.
A l'étape suivante, 1102, on détermine si la fonction distante présente un caractère temporaire. Cela est effectué par la consultation, dans la mémoire locale du contrôleur, des informations de configuration archivées qui
concernent les n_uds connectés sur le bus (cf. supra, description en liaison
avec la Fig. 6).
Dans la négative, la procédure est classique, on passe à l'étape
1106 pour préparer et envoyer la commande requise.
En revanche, si l'unité fonctionnelle distante présente un caractère temporaire, alors on passe à l'étape 1103 dans laquelle on détermine si la
commande requise est une demande dite "spéciale".
Une commande "spéciale" est définie ici comme étant une commande permettant d'effectuer un changement de configuration de l'unitéfonctionnelle cible. Ainsi, a titre d'exemple, I'association "1394 Trade Association" (TA), dans son document"AV/C Digital Intefface Command Set, General Specification", 15 avril 1998, définit une commande "WRITE DESCRIPTOR" qui permet d'effectuer une modification complète ou partielle de
la mémoire de configuration d'une unité fonctionnelle.
Si, à l'étape 1103, la commande requise est déterminée comme étant une commande spéciale, on passe alors à l'étape 1106. Dans le cas contraire, on passe à l'étape 1104, dans laquelle on teste l'état de l'unité fonctionnelle. Si l'état de la fonction est déterminé comme étant "nondisponible" on rejette la commande (étape 1105), c.-à-d., la commande requise n'est pas envoyée au terminal cible. On pourra prévoir de retourner une information par
ex. à l'application demandeuse de la requête, pour lui signifier ce rejet.
Dans le cas contraire, si l'état de la fonction est "disponible", on passe à l'étape 1 106 dans laquelle on prépare le message contenant la commande, et on l'envoie, au travers de l'interface IEEE1394 du contrôleur, à destination du terminal source. La procédure d'émission d'une commande à
une unité fonctionnelle distante se termine alors.
Corrélativement, en liaison avec la FIG. 12, on va décrire à présent, le processus mis en _uvre dans un terminal connocté à un bus IEEE1394, lors de la réception par celui-ci d'une commande envoyée par un contrôleur distant à destination d'une unité fonctionnelle ayant un caractère
temporaire, incorporée dans le terminal.
Comme illustré à la FIG. 12, le processus commence par l'étape 1201 dans laquelle le terminal reçoit, au travers de son interface IEEE1394, une commande adressoe à une unité fonctionnelle ayant un caractère temporaire
incorporce dans le terminal.
A l'étape suivante, 1202, on détermine l'état de la fonction en consultant le reg istre (d'état) approprié. Si l'u nité fonctionn el le est d ans l'état "disponible", la commande est exécutée (étape 1204), le processus est alors terminé. Inversement si l'unité fonctionnelle est dans l'état "non-disponible", on passe à l'étape 1203, dans laquelle on détermine si la commande reçue est une commande "spéciale" (avec le même sens que pour la Fig.11).
Si c'est le cas, on exécute cette commande spéciale (étape 1204).
Dans ce cas, l'exécution de la commande spéciale entraîne, comme mentionné plus haut, une modification de la configuration de l'unité fonctionnelle; cette modification est effectuée selon la procédure décrite supra en liaison avec la
FIG.10.
Dans le cas contraire, c.-à-d. Ia commande n'est pas une commande spéciale, on rejette la commande (étape 1205) puisque l'unité
fonctionnelle est à l'état "non-disponible".
Ce rejet de la commande peut se traduire par l'émission d'un message d'erreur, à destination du n_ud émetteur de la commande. Le
processus est alors terminé.
Bien entendu, de nombreuses modifications peuvent être apportées aux modes de réalisation décrits ci-dessus sans sortir du cadre de l'invention. En particulier, bien que les modes de réalisation décrits ici s'appliquent au standard IEEE 1394,1'invention s'applique de manière générale à tout autre standard de bus série, dont le mode de communication d'informations est similaire à celui spécifié dans le cadre du standard IEEE 1394.
Claims (23)
1. Procédé de configuration d'une unité fonctionnelle dans un terminal connocté à un réseau de communication, I'unité fonctionnelle étant configurée conformément à des informations de configuration contenues dans une mémoire de configuration dudit terminal, ladite mémoire de configuration étant accessible à distance au travers du réseau par au moins un n_ud contrôleur, le procédé étant caractérisé en ce qu'il comporte, lorsque l'unité fonctionnelle à configurer présente un caractère temporaire relatif à son état de fonctionnement vis-à-vis du réseau, une étape de: - création, dans ladite mémoire de configuration, d'au moins une première information caractéristique d'une action à appliquer à ladite unité fonctionnelle, et d'au moins une seconde information spécifiant la nature du caractère temporaire de ladite action; en accéd ant auxd ites première et second e i nfo rmations, u n n_u d contrôleur pouvant ainsi prendre en compte automatiquement un changement
d'état de ladite unité fonctionnelle.
2. Procédé selon la revendication 1, dans lequel ladite action consiste à changer l'état de l'unité fonctionnelle relatif à sa disponibilité sur le réseau, et la nature du caractère temporaire consistant en la définition d'une durée relative à la validité dans le temps de chaque état possible de l'unité fonctionnelle.
3. Procédé selon la revendication 2, comportant en outre une étape d'initialisation (1003) de l'unité fonctionnelle, ladite étape d'initialisation comprenant la création d'un registre mémoire dont la valeur est indicative de l'état courant de l'unité fonctionnelle, et d'un temporisateur dont l'expiration
déclenche un changement d'état de l'unité fonctionnelle.
4. Procédé selon la revendication 2 ou 3, dans lequel la durée relative à la validité dans le temps d'un état de l'unité fonctionnelle peut être définie: par référence à une ou plusieurs dates précises; de façon périodique dans le temps; par une durée fixée; ou par une combinaison quelconque des
trois modes de définition précédents.
5. Procédé selon la revendication 2, 3 ou 4, dans lequel l'état de
l'unité fonctionnelle est "disponible" ou "non-disponible".
6. Procédé selon l'une quelconque des revendications 1 à 5, dans
lequel lesdites première et seconde informations sont structurées dans la
mémoire de configuration selon un format utilisant un jeu de clés étendues.
7. Procédé de lecture, par un n_ud contrôleur connocté à un réseau de communication, de la mémoire de configuration d'un terminal connecté audit réseau, ledit terminal pouvant comporter au moins une unité fonctionnelle ayant un caractère temporaire, configurée selon un procédé
conforme à l'une quelconque des revendications 1 à 6, le procédé de lecture
étant caractérisé en ce qu'il comporte les étapes suivantes: (a) - envoi (604), par le n_ud contrôleur, d'une demande de lecture des informations de configuration relatives à au moins une unité fonctionnelle dudit terminal; (b) - réception (605) par le n_ud contrôleur desdites informations de configuration, et sauvegarde (606) desdites informations; (c) - analyse desdites informations sauvegardées et détermination (607) du caractère temporaire d'au moins une unité fonctionnelle correspondant auxdites informations; (d) - pour chaque unité fonctionnelle dont le caractère est déterminé comme étant temporaire, mémorisation (608) de l'état initial de ladite unité fonctionnelle, et mise à jour (608) automatique de l'état mémorisé en fonction desdites informations de configuration sauvegardées, par laquelle le changement d'état de l'unité fonctionnelle est automatiquement pris en compte
dans le n_ud contrôleur.
8. Procédé selon la revendication 7, dans lequel l'étape (d) inclut la création d'un registre dont la valeur est indicative de l'état initiai de ladite unité fonctionnelle, et la création d'un temporisateur dont l'expiration déclenche,
dans le n_ud contrôleur, une mise à jour (Fig. 7) de la valeur dudit registre.
9. Procédé de fourniture d'informations de configuration, lesdites informations étant sauvegardées par un n_ud contrôleur dans un réseau de communication, lesdites informations de configuration concernant des unités fonctionnelles incorporées dans une pluralité de terminaux connectés audit réseau, lesdites informations ayant été obtenues par un procédé de
configuration conforme à l'une quelconque des revendications 1 à 6, ledit
procédé de fourniture d'informations étant caractérisé en ce qu'il comporte les étapes suivantes, mises en _uvre pour chacun desdits terminaux: - extraction (901), de la mémoire dudit n_ud contrôleur, des informations de configuration du terminal; - création (902) d'une première fenêtre sur un écran de visualisation, dans laquelle sont affichées des informations générales relatives audit terminal, permettant notamment à un utilisateur d'identifier le terminal considéré ainsi que la ou les unités fonctionnelles incorporées dans celui-ci; - création (903) dans ladites fenêtre d'autant de premières icônes distinctes qu'il y a d'unités fonctionnelles dans ledit terminal, les informations spécifiques relatives à une unité fonctionnelle particulière étant accessibles à I'utilisateu r en sélection nant l'icône co rrespond ante au moyen d'u n d ispositif de sélection adapté; - détermination (904) du caractère temporaire ou non de chacune desdites unités fonctionnelles et création (905), pour chacune des unités fonctionnelles déterminées comme ayant un caractère temporaire, d'une icône additionnelle affichée à proximité de la première icône correspondante, ladite icône additionnelle étant indicative de ce caractère temporaire, les informations relatives au caractère temporaire de l'unité fonctionnelle considérée étant accessibles à l'utilisateur en sélectionnant l'icône correspondante au moyen
d'un dispositif de sélection adapté.
10. Procédé selon la revendication 9, dans lequel chaque icône additionnelle peut être représentée dans deux couleurs différentes, chacune des couleurs indiquant un état différent de l'unité fonctionnelle temporaire
1 5 correspondante.
11. Procédé de traitement d'une commande par un n_ud contrôleur connecté à un réseau de communication, ladite commande étant destinée à un terminal connecté audit réseau, ledit terminal comportant au moins une unité fonctionnelle ayant un caractère temporaire, et étant configurce selon un procédé de configuration conforme à l'une quelconque des
revendications 1 à 6, le procédé de traitement étant caractérisé en ce qu'il
comporte les étapes suivantes: - élaboration (1101) dans le contrôleur d'une requête d'envoi d'une commande à destination d'une unité fonctionnelle dudit terminal; - détermination (1102) du caractère temporaire ou non de ladite unité fonctionnelle; - envoi (1106) de la commande si ladite unité fonctionnelle ne présente pas un caractère temporaire; sinon,
33 2823626
- si ladite unité fonctionnelle présente un caractère temporaire, détermination (1103) si la commande est une commande dite "spéciale" c.-àd., visant à effectuer un changement de configuration de ladite unité fonctionnelle; - envoi (1106) de la commande audit terminal si ladite commande est une commande spéciale; sinon, - détermination (1104) de l'état de ladite unité fonctionnelle; - envoi (1106) de la commande audit terminal si l'état de ladite unité fonctionnelle est déterminé comme étant"disponible"; sinon,
- rejet (1 105) de la commande.
12. Procédé de traitement par un terminal connecté à un réseau de communication, d'une commande reçue via ledit réseau, ladite commande étant destinée à une unité fonctionnelle incorporée dans ledit terminal, ladite unité fonctionnelle ayant un caractère temporaire, et étant configurée selon un
procédé de configuration conforme à i'une quelconque des revendications 1 à
6, le procédé de traitement étant caractérisé en ce qu'il comporte les étapes suivantes: - détermination (1202) de l'état de ladite unité fonctionnelle; - exécution (1204) de la commande si l'état de ladite unité fonctionnelle est déterminé comme étant "disponible"; sinon, détermination (1203) si la commande est une commande dite "spéciale" c.-àd., visant à effectuer un changement de configuration de ladite unité fonctionnelle; - exécution (1204) de la commande si ladite commande est une commande spéciale; sinon,
- rejet (1205) de la commande.
13. Procédé selon l'une quelconque des revendications
précédentes, dans lequel ledit réseau de communication est un réseau ayant
une architecture basée sur au moins un bus série IEEE1394.
14. Dispositif (101) de configuration d'une unité fonctionnelle incorporée dans un terminal connecté à un réseau de communication, caractérisé en ce qu'il comporte des moyens adaptés à la mise en _uvre d'un
procédé de configuration selon l'une quelconque des revendications 1 à 6.
15. Dispositif (101? de lecture de la mémoire de configuration d'un terminal connecté à un réseau de communication, ledit dispositif étant incorporé dans un n_ud contrôleur connecté audit réseau, caractérisé en ce qu'il comporte des moyens adaptés à la mise en _uvre d'un procédé de lecture
selon la revendication 7 ou 8.
16. Dispositif (101) de fourniture d'informations de configuration, lesdites informations étant sauvegardées par un n_ud contrôleur dans un réseau de communication, caractérisé en ce qu'il comporte des moyens adaptés à la mise en _uvre d'un procédé de fourniture d'informations de
configuration selon la revendication 9 ou 10.
17. Dispositif (101) de traitement d'une commande par un n_ud contrôleur connecté à un réseau de communication, ladite commande étant destinée à un terminal connocté audit réseau, caractérisé en ce qu'il comporte des moyens adaptés à la mise en _uvre d'un procédé de traitement d'une
commande selon la revendication 11.
18. Dispositif (101) de traitement par un terminal connocté à un réseau de communication, d'une commande reçue via ledit réseau, caractérisé en ce qu'il comporte des moyens adaptés à la mise en _uvre d'un procédé de
traitement d'une commande selon la revendication 12.
19. Dispositif selon l'une quelconque des revendications 14 à 18,
dans lequel ledit réseau de communication est un réseau ayant une
architecture basée sur au moins un bus série IEEE1394.
20. Système informatique (101) connecté à un réscau de communication, par exemple un réseau ayant une architecture basée sur au moins un bus série IEEE1394, caractérisé en ce qu'il comporte un dispositif selon la revendication 14 etiou un dispositif selon la revendication 15 et/ou un dispositif selon la revendication 16 etiou un dispositif selon la revendication 17
et/ou un dispositif selon la revendication 18.
21. Réseau de communication comportant au moins un système
informatique en conformité avec la revendication 20.
22. Programme d'ordinateur, caractérisé en ce qu'il comporte des instructions adaptées à mettre en _uvre au moins un procédé selon l'une
quelconque des revendications 1 à 13, lorsque ledit programme est chargé et
exécuté dans un ordinateur.
23. Support informatique utilisable par un ordinateur, caractérisé
en ce qu'il contient un programme d'ordinateur selon la revendication 22.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0105041A FR2823626B1 (fr) | 2001-04-12 | 2001-04-12 | Procede et dispositif de configuration d'une unite fonctionnelle ayant un caractere temporaire dans un reseau de communication |
| US10/118,952 US20020184573A1 (en) | 2001-04-12 | 2002-04-10 | Method and device for configuring a functional unit with a temporary character in a communication network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0105041A FR2823626B1 (fr) | 2001-04-12 | 2001-04-12 | Procede et dispositif de configuration d'une unite fonctionnelle ayant un caractere temporaire dans un reseau de communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2823626A1 true FR2823626A1 (fr) | 2002-10-18 |
| FR2823626B1 FR2823626B1 (fr) | 2003-07-04 |
Family
ID=8862282
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0105041A Expired - Fee Related FR2823626B1 (fr) | 2001-04-12 | 2001-04-12 | Procede et dispositif de configuration d'une unite fonctionnelle ayant un caractere temporaire dans un reseau de communication |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20020184573A1 (fr) |
| FR (1) | FR2823626B1 (fr) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2839407B1 (fr) * | 2002-05-02 | 2004-12-17 | Canon Kk | Procede et dispositif d'ajustement de la taille maximale des sequences d'information transmises dans un reseau de telecommunications |
| US7895308B2 (en) * | 2005-05-11 | 2011-02-22 | Tindall Steven J | Messaging system configurator |
| US8812638B2 (en) * | 2006-07-12 | 2014-08-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, apparatus and computer program product for controlling devices |
| US10108466B2 (en) * | 2015-06-29 | 2018-10-23 | International Business Machines Corporation | Optimizing the initialization of a queue via a batch operation |
| US10108238B2 (en) | 2016-07-22 | 2018-10-23 | Rockwell Automation Technologies, Inc. | Intelligent power tap for providing power and communicating in industrial automation applications |
| US10108216B2 (en) * | 2016-07-22 | 2018-10-23 | Rockwell Automation Technologies, Inc. | Power tap with adjustable configuration |
| US10126799B2 (en) | 2016-07-22 | 2018-11-13 | Rockwell Automation Technologies, Inc. | Intelligent power tap with zone control and safety zone control |
| US10154006B2 (en) | 2016-07-22 | 2018-12-11 | Rockwell Automation Technologies, Inc. | Systems, methods and apparatus for supporting multiple network addressing modes |
| US10218699B2 (en) | 2016-07-22 | 2019-02-26 | Rockwell Automation Technologies, Inc. | Systems and methods for adding a non-inherent component to a device key of a networked device |
| US10440620B2 (en) | 2016-07-22 | 2019-10-08 | Rockwell Automation Technologies, Inc. | Systems and methods for bidirectional network geography delivery |
| US12048001B2 (en) | 2019-03-08 | 2024-07-23 | Canon Kabushiki Kaisha | Backoff management for intra-queue priority transmission in communication networks |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0967757A2 (fr) * | 1998-06-16 | 1999-12-29 | Sony Corporation | Dispositif et méthode de traitement d'information et programme d'ordinateur pour permettre un changement de fonction |
| EP0978051A1 (fr) * | 1996-06-21 | 2000-02-09 | Mirage Technologies, Inc. | Systeme materiel reconfigurable dynamiquement qui permet de commander des processus en temps reel |
| US6141767A (en) * | 1998-04-03 | 2000-10-31 | Sony Corporation | Method of and apparatus for verifying reliability of contents within the configuration ROM of IEEE 1394-1995 devices |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5968152A (en) * | 1996-04-10 | 1999-10-19 | Apple Computer, Inc. | Method and apparatus for extending key space in a plug and play ROM |
| JP4054451B2 (ja) * | 1997-08-26 | 2008-02-27 | キヤノン株式会社 | 通信装置 |
| US6173319B1 (en) * | 1998-05-08 | 2001-01-09 | Attachmate Corporation | Using a systems network architecture logical unit activation request unit as a dynamic configuration definition in a gateway |
| US6272131B1 (en) * | 1998-06-11 | 2001-08-07 | Synchrodyne Networks, Inc. | Integrated data packet network using a common time reference |
| US7058563B1 (en) * | 1998-09-23 | 2006-06-06 | Microsoft Corporation | Device driver auto-load |
| US6643714B1 (en) * | 1999-03-25 | 2003-11-04 | Microsoft Corporation | Modification and use of configuration memory used during operation of a serial bus |
| JP3449313B2 (ja) * | 1999-09-28 | 2003-09-22 | 日本電気株式会社 | 機器情報収集方法、機器制御装置およびブリッジ |
| US6631426B1 (en) * | 1999-11-02 | 2003-10-07 | Apple Computer, Inc. | Automatic ID allocation for AV/C entities |
| US6968307B1 (en) * | 2000-04-28 | 2005-11-22 | Microsoft Corporation | Creation and use of virtual device drivers on a serial bus |
| JP2002051055A (ja) * | 2000-08-04 | 2002-02-15 | Sony Corp | 通信制御方法、通信システム及び通信装置 |
| JP2002077211A (ja) * | 2000-08-29 | 2002-03-15 | Canon Inc | 情報処理装置およびその方法、並びに、記録媒体 |
| US7085824B2 (en) * | 2001-02-23 | 2006-08-01 | Power Measurement Ltd. | Systems for in the field configuration of intelligent electronic devices |
-
2001
- 2001-04-12 FR FR0105041A patent/FR2823626B1/fr not_active Expired - Fee Related
-
2002
- 2002-04-10 US US10/118,952 patent/US20020184573A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0978051A1 (fr) * | 1996-06-21 | 2000-02-09 | Mirage Technologies, Inc. | Systeme materiel reconfigurable dynamiquement qui permet de commander des processus en temps reel |
| US6141767A (en) * | 1998-04-03 | 2000-10-31 | Sony Corporation | Method of and apparatus for verifying reliability of contents within the configuration ROM of IEEE 1394-1995 devices |
| EP0967757A2 (fr) * | 1998-06-16 | 1999-12-29 | Sony Corporation | Dispositif et méthode de traitement d'information et programme d'ordinateur pour permettre un changement de fonction |
Non-Patent Citations (1)
| Title |
|---|
| IEEE STANDARDS BOARD: "IEEE Standard for a High Performance Serial Bus", IEEE STANDARD FOR A HIGH PERFORMANCE SERIAL BUS, XX, XX, PAGE(S) 199-240, XP002102520 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2823626B1 (fr) | 2003-07-04 |
| US20020184573A1 (en) | 2002-12-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1512408B (zh) | 记录图像文件的方法以及记录和提供图像文件的装置 | |
| EP1069570B1 (fr) | Système de gestion à distance d'au moins un dispositif de reproduction d'informations audiovisuelles | |
| JP5921057B2 (ja) | 電子コンテンツの分散および交換システム | |
| EP1911207B1 (fr) | Controle d'un equipement multimedia a partir d'un terminal mobile | |
| CN102576371B (zh) | 用于对内容进行可调分发的方法和系统 | |
| FR2808906A1 (fr) | Dispositif et procede de gestion a distance d'un reseau de systemes de reproduction d'informations audiovisuelles | |
| EP2343892A1 (fr) | Dispositif et procédé de gestion à distance d'un réseau de systèmes de reproduction d'information audiovisuelles | |
| FR2823626A1 (fr) | Procede et dispositif de configuration d'une unite fonctionnelle ayant un caractere temporaire dans un reseau de communication | |
| WO2004086680A1 (fr) | Procede de contrôle d’appareils au sein d’un reseau par une telecommande dediee et appareils mettant en oeuvre le procede | |
| FR2851392A1 (fr) | Procede de traitement de signaux de commande au sein d'un reseau audiovisuel, dispositif, reseau et programme d'ordinateur correspondants | |
| FR2572235A1 (fr) | Procede et dispositif d'acquisition, de memorisation et de transmission de donnees specialisees relatives notamment a l'enregistrement des emissions, entre un appareil de type magnetoscope et un centre de traitement | |
| EP0969625A1 (fr) | Agent de communication entre un administrateur et au moins une ressource d'un système informatique | |
| CN1688997B (zh) | 增强多媒体的方法 | |
| WO2012101075A1 (fr) | Procede d'acces a des contenus multimedias au sein d'un foyer | |
| EP1074117B1 (fr) | Procede de gestion d'objets dans un reseau de communication et dispositif de mise en oeuvre | |
| EP1997040A1 (fr) | Procédé, dispositif et système de gestion d'informations structurées au sein d'une scène graphique | |
| WO1998052189A2 (fr) | Interface pour multimedia avec reperage de l'interaction utilisateur | |
| EP1376349A1 (fr) | Interface graphique utilisateur permettant d'installer des programmes informatiques d'un lot de démarrage | |
| EP1010326B1 (fr) | Procede et installation de telechargement d'une plateforme de decodeur d'usager | |
| EP0866410A1 (fr) | Système informatique à stockage de données distribué | |
| FR2881302A1 (fr) | Procede et systeme de protection contre la copie de donnees de fichiers transmis par lecture en transit (streaming) | |
| FR2823399A1 (fr) | Procede de gestion d'acces securise a des ressources numeriques d'un serveur, et systeme associe | |
| EP1295203A1 (fr) | Procede de structuration, de transfert et d'interpretation d'un ensemble d'informations destinees a la conception d'interfaces graphiques | |
| Goodwin et al. | Media Systems: Incorporating the TV and the HiFi | |
| FR2901386A1 (fr) | Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un reseau par des utilisateurs. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20131231 |