INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
La figure 2 illustre la structure d'une plate-forme d'administration 30 du système d'administration 10. La plate-forme 30 peut être limitée à une machine gestionnaire ou être distribuée parmi plusieurs machines gestionnaires. Pour des raisons de commodité, la plate-forme illustrée dans la figure 2 sera limitée à la machine gestionnaire 12a et correspond ainsi au gestionnaire 17a. La plate-forme 30 se compose de deux ensembles 40 et 50. L'ensemble 40 contient un bloc 41 contenant un ensemble d'applications génériques (core applications) 42 connectées à un tableau de bord 43. Les applications peuvent être écrites dans un plusieurs langages, le langage SML étant le langage choisi. Le tableau de bord 43 est classique et inclut une partie graphique et un lanceur de requêtes. Une station graphique 44, extérieure à la plate-forme 30, permet de visualiser les applications, lancer les requêtes et visualiser les résultats contenus dans les réponses. Elle permet à un utilisateur de se connecter à la machine 12a pour démarrer et arrêter comme il le désire ses propres copies des applications 42. L'ensemble 40 comporte des moyens 45 d'interface d'accès sous divers protocoles aux objets du système d'administration 10. Cette interface met en #uvre le procédé conforme à l'invention et sera décrite ultérieurement. L'ensemble 40 peut former une unité autonome délimitée par un trait fantôme et constituer une station d'administration.
Dans le cas où l'ensemble 40 constitue une station d'administration, l'ensemble 50 forme un serveur d'administration. Le
serveur 50 utilise un seul protocole donné, ici le protocole CMIP. Il comprend quatre blocs fonctionnels : un bloc de communication 51 aussi appelé courtier de requêtes CMIS ou distributeur CMIS (CMIS Dispatcher) ; un bloc 52 intégrateur de gestionnaires MI (Manager Integrator) en liaison avec au moins un autre gestionnaire, ici le gestionnaire 17b, et/ou avec un supragestionnaire ; un bloc 60 de services ; et un bloc 70 d'intégrateurs d'agents 71a-71c affectés à des protocoles respectifs tels que CMIP, SNMP et DSAC illustrés. Le courtier 51 est connecté aux moyens d'interface 45 de la station 40 pour traiter les requêtes sous le protocole CMIP, au bloc MI 52, au bloc 60 des services et au bloc 70 d'intégrateurs d'agents. Le bloc 60 contient tous les services communs aux applications 42, notamment : une base CMIS-DB 61 de données CMIS ; service 62 de schémas d'informations d'administration, appelé MISS (Management Information schéma Service) contenant les schémas, aussi dits classes ou modèles, des objets gérés par la plate-forme ; un service 63 de gestion d'objets sous la racine ROOT à laquelle sont attachés tous les objets gérés ; un service 64 d'alarmes ; et un service 65 de statistiques et performances utilisées pour des applications 42 de performances.
La figure 3 illustre de façon schématique et très partielle un exemple de structure d'une base MIB des objets gérés par le système d'administration 10 et représentatifs de ressources du système informatique 11. Dans l'exemple choisi, la ou les ressources du système informatique 11 sont converties en classes d'objets organisées hiérarchiquement dans une base d'informations d'administration MIB (Management Information Base).
Cette base n'est pas une base de données proprement dite, mais est assimilable à un catalogue de caractéristiques puisqu'elle contient la description et le contenu de toutes les classes gérées par le système d'administration 10.
La figure 4 est un exemple simplifié et partiel d'un arbre 80 correspondant à la base MIB. On distingue entre l'arbre des classes, une classe étant définie en subordination à une ou plusieurs classes mères, et l'arbre des instances, une instance étant attachée à une ou plusieurs instances mères. L'arbre des classes est contenu dans le service MISS 62,
tandis que l'arbre des instances est l'arbre 80. Une classe est définie par des caractéristiques nommées attributs, tels qu'un nom d'un composant du système et un état d'impression. Un objet d'une classe sera appelé une instance de la classe. Un objet géré est donc une vue abstraite, définie pour les besoins de la gestion, d'une ressource logique ou physique d'un système.
Les objets dans l'arbre peuvent être identifiés de façon unique en utilisant une règle de d'attribution de nom appelée couramment règle de nommage (naming rule) basée sur un ordre hiérarchique. Une instance dans la base MIB a un nom distinctif relatif RDN (Relative Distinguished Name) sous forme d'une liste d'assertions sur valeur d'attribut appelées assertions AVA (Attribute Value Assertion). Chaque assertion AVA est un couple , l'attribut de nommage étant celui qui, dans la classe, permet l'identification unique, dans un espace de nommage, d'une instance par rapport à son instance mère. Dans un gestionnaire 17a de l'exemple illustré, un nom RDN est composé d'une seule assertion AVA, donc d'un seul couple . D'une manière générale, il est cependant possible qu'un nom distinctif RDN ait plusieurs assertions AVA. Chaque instance dans la base MIB est identifiée de façon unique par son nom distinctif DN (Distinguished Name), qui est la suite des noms RDN sur le chemin entre la racine et l'instance dans l'arbre des instances. Un sous-arbre d'une instance correspond à l'ensemble formé par l'instance elle-même et les instances qui lui sont subordonnées dans l'arbre des instances.
Tous les objets de la base MIB dans la figure 3 sont placés sous la racine ROOT et sont répartis en sous-MIB, ici représentatifs des deux machines gérées 12c et 12d, correspondant à deux sous-arbres. La racine ROOT est contenue dans le service 63 et les racines des sous-arbres seront appelées sous-racines correspondant au terme anglais Rootlet. Ainsi, toute application 42 devant traiter un objet de la base MIB s'adresse au service 63 pour accéder à l'objet. Les objets peuvent être accédés par l'intermédiaire de divers protocoles. Dans l'exemple illustré dans les figures 1 et 2, on distingue d'abord les objets pouvant être accédés par l'intermédiaire d'agents 18a et 18b
et réunis en sous-MIB 19a et 19b respectifs. Les agents 18a et 18b sont inclus dans les machines gérées respectives 12c et 12d et sont, dans l'exemple illustré, affectés aux deux protocoles CMIP et SNMP. D'une manière plus générale, une machine peut inclure plusieurs agents relatifs à des protocoles différents. Dans la figure 2 sont aussi ajoutés des agents DSAC 18c.
L'ensemble des agents, par exemple 18a, relatifs à un même protocole est relié au courtier 51 de la plate-forme 30 par l'intermédiaire d'un intégrateur respectif 71a du bloc 70. Ainsi, les objets liés aux protocoles CMIP, SNMP et DSAC peuvent être respectivement accédés par l'intermédiaire des agents CMIP 18a, SNMP 18b et DSAC 18c, via le réseau 13, des intégrateurs respectifs CMIP 71a, SNMP 71b et DSAC 71c. De tels intégrateurs sont bien connus.
Les figures 1,2 et 3 font aussi apparaître que la machine gérée 12c contient aussi une architecture CORBA 20 d'objets distribués dans une sous-MIB 21 et la machine gérée 12d contient un serveur LDAP 22 pourvu d'une base d'objets 23 constitutive d'une sous-MIB. La figure 1 est une représentation simplifiée pour faciliter la description, l'homme du métier sachant que les objets des sous-MIB 21 et 23 peuvent être aussi distribués dans d'autres machines du système informatique 11. Ainsi, des objets de la sous-MIB 21 peuvent être contenus dans la machine 12d et des objets de la sous-MIB 23 peuvent être contenus dans la machine 12c. D'autre part, chaque machine peut contenir plusieurs agents différents et des machines peuvent avoir des agents de même type. On comprend que l'arbre 80 qui correspond à la base MIB de la figure 3 est donc en réalité un arbre d'objets hétérogènes pouvant être accédés sous divers protocoles.
La figure 2 illustre un exemple de structure des moyens d'interface 45 qui permettent aux requêtes émises par les applications de la plate-forme 30 d'accéder selon trois protocoles Pa, Pb et Pc, en l'occurrence les protocoles respectifs CMIP, CORBA et LDAP, à des objets correspondants de la base MIB représentée schématiquement et très sommairement sur la figure 3. Les moyens d'interface 45 comprennent une interface 46 commune pour l'accès aux objets de l'arbre 80 et trois couches d'interface 47a-47c
adaptées aux trois protocoles respectifs CMIP, CORBA et LDAP. Les trois couches d'interface 47a-47c relient l'interface commune 46 aux trois moyens de gestion des objets sous les trois protocoles respectifs, à savoir le serveur d'administration 50, l'architecture CORBA et le serveur LDAP. Dans l'exemple de réalisation choisi, l'interface commune 46 est une interface de répertoires de nommage en langage Java@ connue sous le nom JNDI et les trois couches sont des couches protocolaires de service associées connues sous le nom SPI (Service Protocol Interface) et fournies par la société Sun Microsystems, Inc.
L'arbre 80 de la figure 4 inclut la racine ROOT et un objet cible 81 du protocole LDAP. L'objet 81 peut correspondre au serveur LDAP 22 dans la base MIB de la figure 3 ou à un objet situé à un niveau plus bas sous la racine ROOT. L'objet 81 est père d'un premier fils 82 de protocole LDAP et d'un second fils 83 de protocole CORBA. Le premier fils 82 est lui-même père d'un fils 84 de protocole CMIP et le second fils 83 est père d'un fils 85 de protocole CMIP. L'arbre 80 définit donc trois espaces de nommage 86a-86c illustrés en traits fantômes, relatifs aux trois protocoles respectifs CMIP, CORBA et LDAP et contenant respectivement les objets 84-85,83 et 81-82 Un exemple de mise en oeuvre du procédé d'accès à des objets de l'arbre 80 va maintenant être décrit. Le procédé comprend au moins un cycle incluant trois étapes. Dans la première étape, une requête 87 représentée sous forme d'une flèche dans les figures 2 et 4 est faite pour accéder à un objet, l'objet cible 81 dans la figure 4 par exemple. Dans l'exemple illustré, la requête 87 est émise d'une application générique 42 vers l'interface commune 46. La requête 87 a une portée limitée au seul premier niveau sous l'objet cible 81. Un accès portant sur le premier niveau sous l'objet cible 81 (access scope of first level only) est défini comme consistant à connaître seulement les objets fils de l'objet cible, ici les objets 82 et 83. Un accès de portée à deux niveaux consiste à connaître seulement les objets fils et petits-fils de l'objet cible, en l'occurrence les objets 82-85. La portée est limitée au premier niveau sous l'objet cible du fait que les objets de l'arbre 80 ont des protocoles d'accès hétérogènes comme l'arbre 80, comme cela ressortira ultérieurement.
Dans la seconde étape, la requête 87 utilise l'interface commune pour accéder à l'objet cible 81. Pour accéder à des objets appartenant à un protocole particulier, ici CMIP, CORBA ou LDAP, l'interface commune JNDI 46 demande la création d'un contexte en utilisant la couche d'interface protocolaire SPI 47 correspondant au protocole particulier. Dans l'exemple de la figure 4, l'accès à l'objet 81 ou 82 appartenant à l'espace de nommage 86c relatif au protocole LDAP nécessite la création d'un contexte Cc relatif à la couche 47c. Ce contexte Ce donne accès aux objets appartenant à ce protocole. De même, en référence aux figures 2 et 4, l'accès à l'objet 83 appartenant à l'espace de nommage 86b relatif au protocole CORBA nécessite un contexte Cb relatif à la couche 47b et l'accès aux objets 84 et 85 appartenant à l'espace de nommage 86a relatif au protocole CMIP nécessite un contexte Ca relatif à la couche 47a.
Une série de clients ou de systèmes sont interconnec tés par l'intermédiaire du réseau pour échanger des don nées aussi bien en interne qu'avec l'établissement de diagnostic médical. A titre d'exemple, un système de ser vices, globalement indiqué par le numéro de référence 62, est présent pour recevoir et traiter des données de ser vice, telles que des demandes de services, des demandes de protocole, des questions, etc. Le système de services 62 peut également être équipé pour programmer des appels de services normaux ou spéciaux, pour délivrer des rapports et une analyse de données opérationnelle ou de paramètres, etc. Dans l'exemple illustré, le fournisseur de services à distance 14 possède également un centre de support automa tique globalement représenté par le numéro de référence 64. Le centre peut assurer une variété de fonctions auto matisées, y compris l'acquisition ou la collecte de para mètres et de données opérationnels à partir de l'établis sement comme décrit ci-dessous. En général, tout ou partie des fonctions assurées par le centre de support automati que peuvent être totalement automatisées, nécessitant peu ou pas du tout d'intervention d'un opérateur. Les données collectées selon les programmes exécutés par le centre de support automatique sont mémorisées et rendues disponibles à la demande. Le fournisseur de services à distance 14 peut également posséder différents systèmes de commerce électronique 66 conçus pour délivrer des données, pour re cevoir des commandes, pour traiter des commandes, et pour effectuer des transactions comptables et financières à la demande de l'établissement de diagnostic médical. Un sys tème ou une unité de formation 68 peut de plus être pré sent pour offrir des programmes d'éducation ou de forma- tion, pour délivrer des manuels ou de la documentation, etc.
Bien que certains des systèmes du fournisseur de ser vices à distance puissent être configurés pour une liaison directe avec un ou plusieurs systèmes de diagnostic ou établissements de diagnostic médical, dans l'exemple il lustré, ils sont configurés pour la communication avec les systèmes de diagnostic sur le réseau interne 60 et par l'intermédiaire d'une interface de communication 70. L'in terface de communication 70 comprendra de façon caracté ristique un dispositif d'acheminement de données, et d'au tres circuits et logiciels pour adresser de façon appro priée les données reçues depuis l'établissement de diag nostic médical à un ou plusieurs des systèmes internes du fournisseur de services à distance, et pour diriger les communications depuis ces systèmes vers l'établissement de diagnostic médical. L'interface 70 communique les données par l'intermédiaire d'un ou de plusieurs modems 72, et par l'intermédiaire d'un émetteur pour satellite 74. Lorsqu'on le désire, d'autres liaisons par réseau ou satellites peu vent être présentes pour des systèmes spécifiques du four nisseur de services à distance, comme, par exemple, un émetteur 76 disposé pour l'unité de formation 68. Chacun des dispositifs de communication est couplé à une liaison de données, comprenant une liaison de données récentes 78 pour le modem 72, et des liaisons satellites 80 et 82 pour les émetteurs 74 et 76, respectivement. La liaison de don nées 78 protège de préférence l'intégrité du réseau et des données du fournisseur de services à distance 14 par l'in termédiaire d'un ou de plusieurs pare-feu 84 ou de dispo sitifs de protection similaires.
La topologie de système illustrée en figure 1 permet aux données d'être échangées de façon interactive entre l'établissement médical et le fournisseur de services à distance. Comme décrit ci-dessous, les données peuvent être échangées lors de la mise en route de l'établissement de diagnostic médical, ou des systèmes à l'intérieur de l'établissement, par l'intermédiaire du système de com mande de communication de données 40. D'une autre façon, les communications peuvent être déclenchées par le four nisseur de services à distance, de façon à répondre à des demandes de données ou de services, à accéder à des don nées depuis les systèmes de diagnostic ou à acquérir cel les-ci par l'intermédiaire du système de commande de com munication de données, ou à procurer différents services, parmi lesquels des matériels d'instruction, des sessions de formation, etc., par l'intermédiaire des liaisons de réseau externes.
La figure 2 illustre un exemple de configuration pour le système de commande de communication de données 40, y compris ses dispositifs périphériques associés et son en semble de logiciels. Dans la réalisation illustrée, le système de commande de communication de données 40 com prend une unité centrale 86, qui peut comprendre un micro processeur disponible dans le commerce à l'intérieur d'un ordinateur à usage général ou spécifique à l'application. L'unité centrale est couplée à une variété de circuits et de circuits fonctionnels destinés à exécuter les fonctions décrites ici. Par exemple, comme montré en figure 2, l'unité centrale est-couplée à une interface de communica tion 88 afin d'émettre et de recevoir des données par l'intermédiaire du réseau externe comme décrit ci-dessus, et à émettre et à recevoir de façon similaire des données avec les systèmes de diagnostic par l'intermédiaire du ré seau interne. Par -conséquent, l'interface de communication 88 peut coordonner les communications par l'intermédiaire d'un ou plusieurs modems 42 couplés à la liaison de don nées 46. Le décodeur de satellite 44 canalise de façon si milaire les données passant par le système de commande de communication de données à travers la liaison satellite 48. Une interface de réseau additionnelle 90, telle qu'une interface Ethernet, permet l'échange de données par l'in termédiaire du réseau interne 20 de l'établissement.
En plus de ces composants de communication, le système de commande de communication de données 40 comprend des circuits de mémoire 92 et des composants de support addi tionnels. Les circuits de mémoire 92 peuvent comprendre n'importe quelle mémoire appropriée, telle que des unités de disquettes, une mémoire vive, une mémoire morte, une mémoire vive dynamique, une mémoire optique, etc. Les cir cuits de mémoire 92 mémorisent aussi bien les programmes de logiciel exécutés par le système de commande de commu nication de données que les données collectées par le sys tème de commande de communication de données pour la transmission au fournisseur de services à distance, et que les données reçues depuis le fournisseur de services à distance pour la distribution à des systèmes de diagnostic désignés ou adressés de l'établissement. Un système de sauvegarde 94 est de préférence présent pour créer pério diquement des versions d'archives de fichiers, de program mes, de données collectées sélectionnés, etc. Une ou plu sieurs interfaces de périphériques, désignées globalement par le numéro de référence 96, sont présentes pour rece voir des signaux d'entrée depuis une interface d'opéra teur, et pour afficher des données et délivrer en sortie des données comme on le désire. Dans la réalisation illus trée, ces dispositifs périphériques comprennent un écran d'ordinateur 98 et une imprimante 100 comme périphériques de sortie. Les périphériques d'entrée peuvent comprendre un clavier classique 102, une souris 104, et n'importe quels autres dispositifs périphériques d'entrée appro priés.
Bien que certaines applications et certains utilitai res de logiciel puissent être mémorisés et exécutés sur différents clients de l'établissement, et, en particulier, à l'intérieur des systèmes d'imagerie, du système d'infor mation de service de radiologie, du système d'information d'hôpital et du système de communication et d'archivage d'images, le système de commande de communication de don nées 40 exécute de préférence de façon indépendante une variété d'applications pour exécuter les fonctions de com munication de données qui lui sont attribuées. Ces appli cations, désignées globalement par le numéro de référence 106 en figure 2, sont de préférence mémorisées dans les circuits de mémoire 92, et exécutées par l'unité centrale 86. D'une autre façon, certaines des applications peuvent être résidentes en un autre endroit, et être complètement ou partiellement exécutées par d'autres circuits de trai tement de données. Les applications 106 comprendront géné ralement une variété de programmes d'application disponi bles dans le commerce, et peuvent de plus comprendre des programmes adaptés à la demande exécutés par l'unité cen trale. Un ensemble de logiciels 108 est par conséquent disponible pour l'exécution par l'unité centrale aussi bien automatiquement, sur une base régulièrement program mée dans le temps, qu'en réponse à des ordres de l'opéra teur ou à des ordres du fournisseur de services à dis tance.
Des programmes d'application, globalement désignés par le numéro de référence 110 en figure 2, peuvent comprendre un logiciel pour collecter des données venant des systèmes de diagnostic, mémoriser ces données, transmettre les don nées au fournisseur de services à distance, et acheminer les données du fournisseur de services à des systèmes dé signés. Dans la réalisation illustrée en figure 2, l'en semble de logiciels 108 comprend un logiciel de base de données pour associer les données collectées à partir des systèmes de diagnostic selon un mode relationnel. Ces don nées comprennent de préférence l'identification des systè mes, leurs emplacements, les données d'utilisation, ainsi qu'une variété de données de paramètres qui sont utiles pour déterminer l'état opérationnel du système et la né cessité éventuelle de services. Comme les personnes ayant une bonne connaissance de la technique l'apprécieront, dans le cas de systèmes d'imagerie de diagnostic, une large variété de données opérationnelles ou de paramètres peuvent être mémorisées directement dans les systèmes de diagnostic individuels et peuvent délivrer des indications extrêmement utiles au sujet des performances des systèmes, et des éventuels besoins de services futurs.
L'ensemble de logiciels 108 comprend également, de préférence, un logiciel de serveur, tel qu'un logiciel de serveur Windows NT de Microsoft Corporation à Redmond, dans l'état de Washington, ainsi qu'un logiciel de serveur Internet. Le logiciel de serveur permet au système de com mande de communication de données de jouer le rôle de ser veur, aussi bien pour les clients internes que pour les clients ou les utilisateurs externes. Un logiciel de pro gramme de recherche est également, de préférence, inclus, celui-ci permettant à un opérateur, par l'intermédiaire des dispositifs d'interface d'opérateur du système de com mande de communication de données, d'accéder à des sites, par exemple sur l'Internet, pour demander des informations et des données, transmettre des demandes de services et de données, etc. Dans la réalisation préférée, le logiciel de programme de recherche peut également fonctionner sur le système de commande de communication de données pour per mettre d'assurer une interface interactive directement sur un ou plusieurs des systèmes de diagnostic, et, en parti culier, des systèmes d'imagerie de diagnostic. Un logiciel d'acheminement est également fonctionnel sur le système de commande de communication de données pour permettre à des paquets de données reçus depuis le fournisseur de services à distance d'être transmis de façon appropriée à des sys tèmes de diagnostic désignés à l'intérieur de l'établisse- ment par l'intermédiaire du réseau interne.