Brevet FR2919084A1 — publié le 20090123

PROCEDE DE GESTION DE RESSOURCES PARTAGEES D'UN SYSTEME INFORMATIQUE ET MODULE SUPERVISEUR DE MISE EN OEUVRE, AINSI QUE LE SYSTEME INFORMATIQUE MUNI D'UN TEL MODULE L'invention se rapporte à un procédé de gestion de ressources d'un système informatique, ces ressources étant partagées entre plusieurs modules d'exécution d'applications variées, par exemple le traitement de données à distance, la logistique de surveillance de systèmes asservis, de surveillance de to pannes, le suivi de stocks, etc. L'invention concerne également un module superviseur de mise en oeuvre de ce procédé et le système informatique comportant ce module superviseur. Dans un système informatique, une plateforme, un ordinateur ou un terminal, des applications indépendantes peuvent être exécutées en accédant 15 à des ressources logiciels et matériels communes au système informatique. Le partage de telles ressources, comme un écran, des entrées/sorties, de la mémoire, le son, le processeur, l'accès réseau ou autre entre les applications pose problème. De plus, lors de l'ajout d'applications dont les fonctionnalités de 20 mise en oeuvre utilisent ces ressources logicielles et matérielles entre plusieurs modules d'exécution, l'arbitrage pour l'acquisition ou le partage de ces ressources est particulièrement difficile à mettre en place lorsque le nombre de types différents de ressources augmente. Dans un cas particulier, le brevet américain US6947048 décrit un 25 procédé de gestion de l'accès à l'écran dans un système embarqué, consistant à centraliser les accès écran pour attribuer des droits d'accès à plusieurs applications. Mais cette solution est limitée à la gestion graphique. On connaît également le brevet américain US6882965 concernant un procédé d'ordonnancement hiérarchique de l'accès à des ressources. Mais 30 cette solution est limitée à des critères de décision temporelle. Par ailleurs, le brevet chinois CN1622075 décrit un système pour l'allocation de ressources partagées consistant en un ensemble de gestionnaires de ressources indépendantes, ad hoc pour chaque type de ressource. Chaque ressource, dans cette solution, est indépendante. Ainsi, les critères de décision 2 2919084 d'allocation sont donc également indépendants, et il est impossible d'obtenir une uniformité dans la gestion des ressources. Ainsi, malgré les améliorations apportées, aucun de ces documents n'a pu apporter une solution à la difficulté de gestion de ressources 5 partagées, comme par exemple lorsque deux applications font simultanément des demandes d'accès à une même ressource, comme dans le cas fréquent du canal de son. Pour limiter ce type de conflits, il est connu d'utiliser des solutions spécifiques à un groupe de ressources, par exemple par une liaison entre la to gestion graphique et la gestion du clavier. Ainsi, les architectures basées sur les interfaces usuelles X11 ou Win32 adoptent ce type de solution. Une telle solution est par exemple disponible sur le site http://www.x.org/ pour X11, et sur le site http://msdn2.microsoft.com/en-us/library/aa383750.aspx pour Win32. Cependant, dans ces solutions, rien n'empêche des conflits pour l'obtention d'autres 15 ressources, comme le son. A fortiori, ces solutions ne permettent pas d'éviter des conflits pour l'accès à des ressources non prévues ou non gérées. Une autre solution connue consiste à modéliser l'ensemble du système, avec l'ensemble des applications et l'ensemble des gestions des ressources, à l'aide d'une machine d'état de traçage des connexions muni des 20 outils appropriés. Cette solution est néanmoins inadaptée pour permettre l'ajout d'un service non prévu au départ, car cela remet en cause le modèle initial. Ainsi, malgré les améliorations apportées dans ces cas particuliers, ces solutions ne résolvent pas le problème évoqué dans le cas le plus général de ressources partagées, en particulier lorsqu'on augmente le 25 nombre de types ressources dans un environnement technique contraint, dont les capacités de traitement sont donc réduites par rapport à la multiplication des applications. L'invention vise à résoudre le problème général de gestion d'un système à ressources multiples de nature différente, d'une manière cohérente. En 30 particulier, l'invention est destinée au partage de ressources entre plusieurs applications exécutables sur une plateforme informatique ou dans les situations d'ajout de nouvelles ressources, non prévues initialement. Afin d'atteindre ces objectifs, l'invention propose d'éviter les conflits entre ressources partagées en partant de l'application avec les droits et 3 2919084 accès attribués par application tout en conservant une ouverture permettant d'ajouter des ressources et des applications nouvelles. Plus précisément, l'invention a pour objet un procédé de gestion de ressources d'un système informatique partagées entre une pluralité s d'applications dans lequel, pendant l'exécution de ces applications, des règles d'attribution génèrent, par application, des droits d'accès à chaque ressource partagée sous forme d'étapes ordonnées successivement et commandées, pour chaque ressource partagée, par un module de commande spécifique. A chaque commande, une étape de paramétrage de critères de décision contrôle les règles to d'attribution des droits d'accès, les critères de décision pouvant être partagés entre une partie au moins des modules de commande. Selon des formes particulières : - le paramétrage des critères de décision peut être réalisé par des trieurs d'applications basés sur des propriétés prioritaires d'accès ; 15 - les propriétés prioritaires attribuées aux applications en correspondance avec les critères de décision se rapportent à l'activation d'une application, lorsqu'une application triée est placée devant les applications ayant la. même priorité d'application qu'elle, en dessous de celles ayant une priorité d'application plus élevée, à l'abandon coopératif, lorsqu'une application est triée et 20 placée sous les applications ayant la même priorité d'application qu'elle, mais au-dessus de celles ayant une priorité d'application inférieure, et à l'inactivation lorsque l'application est placée dans une liste non triée d'applications désactivées, le tri étant réservé à une liste principale d'applications ; des étapes de mise à jour de critères de décision sont 25 prévues lorsque des modifications interviennent sur au moins l'un d'entre eux; - les règles d'attribution de droits d'accès consistent à autoriser l'accès exclusif, à refuser l'accès, à autoriser l'accès partagé ou l'accès partiel d'une ressource par une application ; - un module de commande et au moins un critère de décision 3o peuvent être ajoutés, notamment lorsqu'une nouvelle ressource est ajoutée au système informatique. 4 2919084 Avantageusement, le procédé permet une formalisation, une souplesse et une simplification de la gestion d'un appareil (mobile ou non), en lui permettant de s'adapter en fonction des ressources présentes ou à venir, et de changer le comportement d'accès et de partages de ressources logicielles et 5 matérielles sans perturber les fonctions haut niveau du système. De plus, le procédé selon l'invention ne nécessite pas d'identification informatique particulière de la gestion des applications, mais de toute identification connue dans les systèmes informatiques de l'état de la technique. L'invention se rapporte également à un gestionnaire des ressources à partager entre les applications, dénommé module superviseur, pour la mise en oeuvre du procédé. Selon, l'invention, ce module superviseur de gestion de ressources partagées d'un système informatique comportant un espace applicatif et des ressources matérielles et logicielles, est composé d'une première série de composants de mise en oeuvre de critères de décision interdépendants et d'une deuxième série de composants de commande d'accès aux ressources en liaison multiple avec la première série. Ainsi des requêtes d'utilisation des ressources et des demandes d'accès aux ressources, transmises respectivement, par des liaisons spécifiques de l'espace applicatif, aux composants de critères de décision et aux composants de commande d'accès aux ressources, sont traitées par les composants du module superviseur pour partager les ressources. Dans des formes de réalisation particulières, les composants de mise en oeuvre de critères de décision et de commande d'accès peuvent être des 25 mémoires de stockage en relation avec des modules logiciels adaptés. L'invention se rapporte également à un système informatique comportant un tel module superviseur dont les composants de mise en oeuvre des critères de décision et de commande d'accès aux ressources sont configurés par paramétrage et répartition de liens établis entre eux. Ce paramétrage peut 30 prendre, par exemple, la forme de propriétés prioritaires correspondant aux critères de décision attribuées à chaque application de l'espace applicatif du système. 5 2919084 D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture ci-après d'un exemple détaillé de réalisation, en référence aux figures annexées qui représentent, respectivement : - la figure 1, une vue synthétique d'un système informatique selon 5 l'invention ; et - la figure 2, une vue détaillée du système précédent permettant d'illustrer le fonctionnement du module superviseur. La figure 1 montre de manière synthétique un système informatique 1 selon l'invention, comportant un module superviseur 3, l'espace io applicatif 5 des applications du système et les ressources 7 à partager entre les applications et que ce système met en oeuvre. Le superviseur 3 reçoit de l'espace applicatif 5 des requêtes 9 d'accès aux ressources 7 et de changement d'accès, ainsi que l'identification des applications en mode abstrait par des identifiants 11. En fonction des propriétés 12 des applications de l'espace 5, 15 décrivant leurs droits d'accès respectifs aux ressources 7, le superviseur 3 attribue ou non une ressource 7 comme expliqué ci-après en référence à la figure 2. L'accès 8 des applications aux ressources 7 est géré en mode abstrait par les identifiants 11. Le module superviseur 3 et les périphériques du système sont 20 détaillés plus concrètement et plus précisément ci-après, en référence à la figure 2. Le module superviseur 3 reçoit de l'espace applicatif 5, en tant que requêtes 9 (figure 1), des requêtes 9a d'utilisation des ressources 7 et des demandes 9b d'accès à ces ressources. Le superviseur 3 achemine (flèche 14a) les requêtes 9a d'utilisation de ressources 7 à des composants 13 de critère de décision, et met en relation (flèche 14b) les demandes 9b d'accès aux ressources 7 de l'espace applicatif 5 avec des composants 15 de commande d'accès aux ressources 7. Dans l'exemple de réalisation ces composants sont des mémoires de stockage en 3o relation avec des modules logiciels adaptés, connus de l'homme du métier. Le superviseur 3 stocke, liste et initialise, d'une part, les composants 13 implémentant les critères de décision et, d'autre part les 6 2919084 composants 15 implémentant la commande des ressources 7, propres à chaque type de ressource. Avantageusement, le superviseur peut créer, modifier ou supprimer les associations, appelées encore enregistrements, entre les 5 composants 13 des critères de décisions et les composants 15 de commande de chaque ressource 7. Ces enregistrements sont représentés par les doubles flèches 16 sur la figure 2, les commandes de ressource pouvant s'enregistrer aux critères de décision ou inversement. Le superviseur peut aussi permettre à un critère de décision de s'enregistrer à d'autres critères de décision, enregistrements t o représentés par les flèches 18. Les identifiants 11 (figure 1) sont ici des manipulateurs ( handles en langue anglaise) qui attribuent des valeurs numériques aux applications 5. Ces manipulateurs créent ou suppriment l'accès en rendant abstraite l'acquisition de la ressource correspondante. 15 La gestion des manipulateurs 11 est également réalisée par création, association de manipulateurs avec des composants 15 de commande de ressource, notification ou suppression de ces manipulateurs. Chaque critère de décision est considéré comme un composant informatique offrant des services applicables à des applications 5 ou à d'autres 20 objets informatiques, comme les manipulateurs 11. Un critère de décision est associé à un ou plusieurs composants de commandes de ressources à travers les enregistrements 16. Il s'enregistre auprès du superviseur pour pouvoir offrir ses services, et peut être ajouté et enlevé du système à n'importe quel moment. Un critère de décision fournit des services de requêtes sur les 25 objets qu'il manipule, des services d'enregistrements standardisés, des commandes d'accès d'une ressource qui vont rendre leurs décisions basées sur le ou les critères de décision auxquels ils sont enregistrés. Dans un exemple de réalisation, le critère de décision est un trieur d'applications. Ce trieur est basé sur une propriété prioritaire des applications, ci- 3o après la priorité d'application . Selon cette propriété, le trieur garde une liste ordonnée, décroissante, des applications en fonction de leur priorité, mais également des requêtes transmises telles que: 7 2919084 - l'activation d'une application, lorsqu'une application triée et placée devant les applications ayant la même priorité d'application qu'elle, mais en dessous de celles ayant une priorité d'application plus élevée ; - l'abandon coopératif, lorsqu'une application est triée et placée 5 sous les applications ayant la même priorité d'application qu'elle, mais au-dessus de celles ayant une priorité d'application inférieure; - l'inactivation, lorsque l'application est placée dans une liste non triée d'applications désactivées, le tri étant réservé à une liste principale d'applications. Io Le trieur d'applications peut avantageusement proposer un service d'enregistrement au travers du superviseur pour permettre à d'autres critères de décision ou de commandes de ressources d'être avertis d'un changement dans le tri des applications pour ce critère de décision. Selon un autre exemple, le critère de décision est un trieur de 15 manipulateurs: il est basé sur une autre propriété prioritaire des applications appelée priorité d'application à une ressource , spécifique à chaque ressource. Dé façon similaire au trieur d'applications, le trieur de manipulateurs garde une liste ordonnée, décroissante, pour chaque ressource, des manipulateurs des applications en fonction de leur priorité d'application à une 20 ressource, mais aussi des requêtes ayant été transmises aux manipulateurs comme : - l'activation d'un manipulateur, lorsque le manipulateur est trié et placé devant les manipulateurs ayant la même priorité d'application à une ressource, en dessous de ceux ayant une priorité d'application à une Ressource 25 plus élevée ; - l'abandon coopératif, lorsque le manipulateur est trié et placé sous les manipulateurs ayant la même priorité d'application à une ressource, mais au-dessus de ceux ayant une priorité d'application à une ressource inférieure ; - l'inactivation, lorsque le manipulateur n'est plus trié dans la liste 30 principale, et est placé dans une autre liste non triée de manipulateurs désactivés. De plus, ce trieur permet l'activation ou la désactivation du mode glue sur un manipulateur donné : si ce mode est activé sur le manipulateur 8 2919084 donné et si le trieur est activé pour ce manipulateur, alors ce manipulateur ne changera pas de position si l'une des requêtes précédentes est opérée sur lui. Le trieur de manipulateurs est en outre enregistré au trieur d'application, et lorsqu'il est notifié d'un changement sur une application, il retire 5 les manipulateurs de l'application en conséquence, en leur appliquant les requêtes décrites ci-dessus. Le trieur d'application peut alors proposer avantageusement un service d'enregistrement au travers du superviseur pour permettre à d'autres critères de décision ou des composants de commande d'une ressource d'être to avertis d'un changement dans le tri des manipulateurs, associés à la ressource gérée par le composant de commande de la ressource. De manière préférée, le trieur de manipulateurs offre aussi des requêtes de haut niveau pour obtenir, pour une application donnée et une ressource donnée, qu'elles sont les applications qui pourraient l'empêcher 15 d'obtenir l'utilisation de sa ressource. En fonctionnement, un composant de critère de décision 13 définit donc des règles d'attribution des droits, en fonction des propriétés prioritaires, telles que celles décrites ci-dessus, et décrivant les droits des applications 5. Le composant 15 de commande d'une ressource prend alors la décision de donner 20 ou pas une ressource 7 à une application 5 en fonction des critères de décision auxquels il est enregistré. Il est souverain dans l'acquisition des droits, et peut gérer une ou plusieurs ressources 7. Une commande de ressources s'enregistre au superviseur pour pouvoir offrir ses services, et peut être ajoutée et supprimée du système à 25 n'importe quel moment. Elle n'offre donc pas de services à travers le superviseur, mais offre des services appropriés au reste du système pour que ce dernier puisse connaître l'état d'acquisition d'une ressource, l'écran ou le clavier lorsqu'il s'agit, comme dans l'exemple, d'un ordinateur. L'invention n'est pas limitée aux exemples de réalisation décrits et 3o représentés. Outre les deux critères de décision, trieur d'application et trieur de manipulateurs, d'autres critères de décision peuvent être mis en oeuvre, par exemple critères de décision dépendant de la charge processeur, de l'espace mémoire disponible, de droit d'accès, ou du niveau de batterie. De plus, d'autres types de propriétés prioritaires des applications peuvent être définies en fonction 9 2919084 de la nature de ces applications, par exemple indication d'occupation mémoire dynamique, statique, ou encore niveaux d'accréditation liés à la sécurité : droits d'accès à une ressource particulière par exemple ou clef d'identification. REVENDICATIONS 1. Procédé de gestion de ressources d'un système informatique (1) partagées entre une pluralité d'applications, caractérisé en ce que, pendant l'exécution de ces applications (6), des règles d'attribution génèrent, par application, des droits d'accès à chaque ressource partagée (7) sous forme d'étapes ordonnées successivement et commandées, pour chaque ressource partagée, par un module de commande spécifique (15), et en ce que, à chaque commande, une étape de paramétrage de modules de critères de décision (13) contrôle les règles d'attribution des droits d'accès, les critères de décision pouvant être partagés entre une partie au moins des modules de commande (15). 2. Procédé de gestion de ressources selon la revendication 1, dans lequel les règles d'attribution de droits d'accès consistent soit à autoriser l'accès exclusif, soit à refuser l'accès, soit à autoriser l'accès partagé soit l'accès partiel d'une ressource (7) par une application (6). 3. Procédé de gestion de ressources selon la revendication 2, dans lequel le paramétrage des critères de décision est réalisé par des trieurs de décision basés sur des propriétés prioritaires (12) d'accès. 4. Procédé de gestion de ressources selon la revendication 3, dans lequel le trieur de décision est un trieur d'applications basé sur la priorité d'application. 5. Procédé de gestion de ressources selon la revendication 3, dans lequel le trieur de décision est un trieur de manipulateurs d'applications basé sur la priorité d'application à une ressource. 6. Procédé de gestion de ressources selon les revendications 3 et 4, dans lequel les propriétés prioritaires (12) attribuées aux applications en correspondance avec les critères de décision se rapportent à l'activation d'une application (6), lorsqu'une application triée est placée devant les applications ayant la même priorité d'application qu'elle, en dessous de celles ayant une priorité d'application plus élevée, à l'abandon coopératif, lorsqu'une application est triée et placée sous les applications ayant la même priorité d'application qu'elle, mais au-dessus de celles ayant une priorité d'application inférieure, et à l'inactivation lorsque l'application est placée dans une liste non triée d'applications désactivées, le tri étant réservé à une liste principale d'applications. 7. Procédé de gestion de ressources selon les revendications 3 et 4, dans lequel les propriétés prioritaires (12) attribuées aux applications pour des ressourcesparticulières en correspondance avec les critères de décision se rapportent à l'activation d'une ressource pour une application (6) au travers d'un manipulateur (11), lorsqu'un manipulateur trié est placé devant les manipulateurs ayant la même priorité que lui, en dessous de ceux ayant une priorité plus élevée, à l'abandon coopératif, lorsqu'un manipulateur est trié et placé sous les manipulateurs ayant la même priorité que lui, mais au-dessus de ceux ayant une priorité inférieure, et à l'inactivation lorsque le manipulateur est placé dans une liste non trié de manipulateurs désactivés, le tri étant réservé à une liste principale de manipulateurs. 8. Procédé de gestion de ressources selon la revendications 7, dans lequel le tri des manipulateurs est soumis au tri des applications décrit dans la revendication 6. 9. Procédé de gestion de ressources selon l'une quelconque des revendications précédentes, dans lequel des étapes de mise à jour de critères de décision sont prévues lorsque des modifications interviennent sur au moins l'un d'entre eux. 10. Procédé de gestion de ressources selon l'une quelconque des revendications précédentes, dans lequel au moins un critère de décision est ajouté au système. 11. Procédé de gestion de ressources selon l'une quelconque des revendications précédentes, dans lequel des modules de commande (15) sont ajoutés au système. 12. Procédé de gestion de ressources selon l'une quelconque des revendications précédentes, dans lequel une nouvelle ressource (7) est ajoutée au système. 13. Procédé de gestion de ressources selon l'une quelconque des revendications 8 à 10, dans lequel un module de commande (15) et au moins un module de critère de décision (13) sont ajoutés lorsqu'une nouvelle ressource (7) est ajoutée au système. 14. Module superviseur de gestion de ressources partagées d'un système informatique (1) pour la mise en oeuvre du procédé selon l'une quelconque des revendications précédentes, comportant un espace applicatif (5) et des ressources (7) matérielles et logicielles, caractérisé en ce qu'il est composé d'une première série de composants (13) de mise en oeuvre de critère de décision interdépendants (18) et d'une deuxième série de composants (15) de commande d'accès aux ressources (7) en liaison multiple (16) avec la première série, des requêtes (9a) d'utilisation des ressources et desdemandes (9b) d'accès aux ressources, transmises respectivement, par des liaisons spécifiques (14a, 14b), de l'espace applicatif (5) aux composants (13) de critères de décision et aux composants (15) de commande d'accès aux ressources, étant ainsi traitées par les composants (13, 15) du module superviseur (3) pour partager les ressources (7). 15. Système informatique comportant un module superviseur selon la revendication 14 dont les composants (13, 15) de mise en oeuvre des critères de décision et de commande d'accès aux ressources sont configurés par paramétrage et répartition des liens établis entre eux, des propriétés prioritaires correspondant aux critères de décision étant attribuées à chaque application (6) de l'espace applicatif (5) du système informatique (1).