FR3010853A1

FR3010853A1 - Architecture hierarchique distribuee d'acces multiples a des services

Info

Publication number: FR3010853A1
Application number: FR1302143A
Authority: FR
Inventors: Patrice Toillon; David Faura
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2013-09-13
Filing date: 2013-09-13
Publication date: 2015-03-20
Anticipated expiration: 2033-09-13
Also published as: FR3010853B1; US20150081759A1; US10009414B2

Abstract

Cette architecture (10) comportant des services (S1,..., S6) et des applications (A1,..., A7), les applications étant aptes à manipuler et/ou traiter des données numériques en utilisant des services (S1,...,S6), est caractérisée en ce que l'architecture (10) comporte des fournisseurs locaux de services (FL1,..., FL4), chaque fournisseur local (FL1,..., FL4) étant connecté à une ou plusieurs applications A7), et des fournisseurs distants de services (FD1,..., FD3), chaque fournisseur distant (FD1,..., FD3) étant connecté à un ou plusieurs services (S1,..., S6), chaque application (A1,..., A7) est apte à communiquer avec un ou plusieurs services (S1,..., S6) à travers un premier niveau hiérarchique comportant un fournisseur local (FL1,..., FL4), et un deuxième niveau hiérarchique comportant au moins un fournisseur distant (FD1,..., FD3) et chaque service (S1,..., S6) est apte à communiquer avec une ou plusieurs applications (A1,..., A7) à travers un premier niveau hiérarchique comportant un fournisseur distant (FD1,..., FD3), et un deuxième niveau hiérarchique comportant au moins un fournisseur local (FL1,..., FL4).

Description

Architecture hiérarchique distribuée d'accès multiples à des services La présente invention concerne une architecture hiérarchique distribuée d'accès multiples à des services.

Cette architecture est par exemple utilisable dans des systèmes avioniques. Plus particulièrement, l'invention se rapporte à une telle architecture hiérarchique distribuée d'accès multiples à des services pour des systèmes avioniques basés notamment sur le concept d'avionique modulaire intégrée (IMA), l'architecture comportant : - un réseau informatique de communication avionique ; - une pluralité de services ; et - une pluralité d'applications chaque application étant apte à manipuler et/ou traiter des données numériques en utilisant au moins un service. Un service est défini comme étant une suite d'actions prédéfinie comme par exemple enregistrement de données, lecture de l'heure globale de la plate-forme, lecture d'une carte de terrain dans une base de données, etc. Cette suite est réalisée par un fournisseur de services spécifique permettant la réalisation de la suite d'actions par un ensemble d'unités logicielles et/ou matérielles. Un service est accessible depuis une ou plusieurs applications client abonnées via l'architecture hiérarchique distribuée d'accès multiples à des services. Lorsque le fournisseur de services termine le service ou une partie du service (suivant le type de service) demandé par l'application ou les applications client, le fournisseur de services envoie « ou non » un résultat à la ou les application(s) client appelante(s).

Dans l'état de la technique, ainsi, par exemple, les systèmes basés sur le concept d'avionique modulaire intégrée (IMA pour « Integrated Modular Avionics » en anglais) actuel (classique) mettent en oeuvre un ou plusieurs services supportant une ou plusieurs applications avioniques (nombre très limités) sans mise en oeuvre de ressource de communication entre ce(s) service(s) et les applications correspondantes car ce(s) service(s) n'est (ne sont) que local (locaux) à un module physique. L'accès au service local se fait via une interface de programmation (API pour « Application Programming Interface » en anglais) pour uniquement la ou les application(s) hébergée(s) sur le même module physique que le service. La communication entre applications au sein de différents modules physiques est assurée généralement par un réseau informatique de communication avionique reliant les modules correspondants.

La communication entre applications est gérée en utilisant des propriétés de partitionnement spatial et temporel des données, permettant des traitements et des échanges indépendants et déterministes. Une telle gestion est basée respectivement sur les normes ARINC 653 et ARINC 664. Les applications avioniques sont basées sur un modèle d'échanges de type Éditeur/Abonné (« Publisher/Subscriber » en anglais). Ces applications ont accès à un ensemble de services basé uniquement sur le standard ARINC 653 faisant appel à des services dédiés localisés sur le même module physique que les applications.

Toutefois, ces solutions présentent un certain nombre d'inconvénients. Notamment, elles ne permettent pas à une ou plusieurs applications de faire un ou plusieurs appels concurrents locaux ou distants à un ou plusieurs services. Autrement dit, elles ne permettent pas à une ou plusieurs applications de communiquer avec un ou plusieurs services appartenant à des modules physiques distincts connectés via un réseau informatique. La présente invention a pour but de proposer une solution d'architecture hiérarchique distribuée d'accès multiples à des services permettant à une ou plusieurs applications de faire des appels concurrents à un ou plusieurs services avioniques et ce quelle que soit la localisation de cette ou de ces applications dans le système avionique et quelle que soit la localisation des services avioniques vis à vis de cette ou de ces applications. Cette architecture hiérarchique utilise les capacités du réseau informatique de communication avionique. Elle est conçue de manière à permettre la gestion des appels concurrents aux services pour garantir l'accès aux services suivant des critères prédéfinis pour les applications abonnées aux services. A cet effet, l'invention a pour objet une architecture hiérarchique distribuée d'accès multiples à des services pour des systèmes avioniques, du type précité dans laquelle : - l'architecture comporte en outre une pluralité de fournisseurs locaux de services, chaque fournisseur local de services étant connecté à une application ou à un groupe d'applications, et une pluralité de fournisseurs distants de services, chaque fournisseur distant de services étant connecté à un service ou à un groupe de services et étant associé à une application ou à un groupe d'applications ; - chaque application est apte à communiquer avec un ou plusieurs services à travers un premier niveau hiérarchique comportant un fournisseur local de services, et un deuxième niveau hiérarchique comportant au moins un fournisseur distant de services ; et - chaque service est apte à communiquer avec une ou plusieurs applications à travers un premier niveau hiérarchique comportant un fournisseur distant de services, et un deuxième niveau hiérarchique comportant au moins un fournisseur local de services. Selon des modes particuliers de réalisation de l'invention, le système comporte l'une ou plusieurs des caractéristiques suivantes : - la communication entre les applications et les services est gérée entièrement par des fournisseurs locaux et distants de services indépendamment de l'application et du service concernés ; - la communication entre les applications et les services est gérée entièrement par des fournisseurs locaux de services indépendamment de la localisation respective des applications et des services ; - chaque fournisseur local de services comporte des moyens de gestion temporelle et spatiale de la communication entre chaque application connectée à ce fournisseur local de services et chaque service vu à travers le réseau ; - chaque fournisseur distant de services comporte des moyens de gestion temporelle et spatiale de la communication entre chaque service connecté à ce fournisseur distant de services et chaque application vue à travers le réseau ; - les moyens de gestion sont associés à des tables de configuration des droits d'accès aux services et/ou à des tables de configuration des droits d'accès aux applications ; - les tables de configuration des droits d'accès aux services et/ou les tables de configuration des droits d'accès aux applications sont prédéterminées lors de la phase de conception du réseau ; - le réseau est conforme à la norme ARINC 664 ; - la communication entre les différents éléments du réseau est basée sur l'adressage UDP/IP ; - elle comporte des modules physiques reliés entre eux dans le réseau et définissant l'emplacement physique des fournisseurs locaux et distants de services, des applications et des services ; - elle comporte au moins un module physique comportant : - un ou plusieurs fournisseurs locaux de services et l'ensemble des applications connectées à ces fournisseurs ; et - un ou plusieurs fournisseurs distants de services et l'ensemble des services connectés à ces fournisseurs, le ou les fournisseurs distants de services étant associés par configuration à une ou à plusieurs applications de l'ensemble des applications ; - chaque fournisseur local de services comporte en outre : - un journal de requêtes apte à répertorier toutes les requêtes émises par chaque application ou groupe d'applications connecté à ce fournisseur local de services ; et - un journal de réponses apte à répertorier toutes les réponses reçues pour chaque application ou groupe d'applications connecté à ce fournisseur local de services ; - chaque fournisseur local de services comporte : - une file de requêtes de services de chaque application ou groupe d'applications associées à ce fournisseur local de services apte à recevoir des requêtes de cette application ou de ce groupe d'applications ; - une file de requêtes pour les services ; - une file de réponses de ces services ; - une file de réponses pour chaque application ou groupe d'applications associées à ce fournisseur local de services apte à envoyer des réponses vers cette application ou vers ce groupe d'applications, chaque file étant gérée par un canal configurable ; - chaque fournisseur local de services connecté à un groupe d'applications est apte à gérer les accès multiples de ces applications à tous les services, une telle gestion supportant : - le partitionnement des requêtes de chaque application du groupe vers les services incluant des droits d'accès respectifs aux services ; et - le partitionnement des réponses des services vers chaque application du groupe incluant les droits d'accès respectifs aux applications ; la gestion comportant en outre : - des lois configurables de gestion et de contrôle des files de requêtes et des files de réponses ; et - l'inscription de ces requêtes et de ces réponses dans le journal correspondant ; - chaque fournisseur distant de services comporte en outre : - un journal de requêtes apte à répertorier toutes les requêtes reçues d'une application ou d'un groupe d'applications associées à ce fournisseur distant de services ; et - un journal de réponses apte à répertorier toutes les réponses émises vers une application ou vers un groupe d'applications associées à ce fournisseur distant de services ; - chaque fournisseur distant de services comporte : - une file de requêtes pour chaque application ou groupe d'applications associées à ce fournisseur distant de services apte à recevoir des requêtes de cette application ou de ce groupe d'applications ; - une file de requêtes pour chaque service, - une file de réponses de chaque service, - une file de réponses pour chaque application ou groupe d'applications associées à ce fournisseur distant de services apte à envoyer des réponses vers cette application ou vers ce groupe d'applications, chaque file étant gérée par un canal configurable ; - chaque fournisseur distant de services connecté à un groupe de services est apte à gérer les accès multiples de toutes les applications à ces services, une telle gestion supportant : - le partitionnement des requêtes des applications vers chaque service du groupe incluant des droits d'accès respectifs aux services ; et - le partitionnement des réponses de chaque service du groupe vers les applications incluant les droits d'accès respectifs aux applications ; la gestion comportant en outre : - des lois configurables de gestion et de contrôle des files de requêtes et des files de réponses ; et - l'inscription de ces requêtes et de ces réponses dans le journal correspondant. le réseau est associé à un journal d'observation des échanges entre les fournisseurs pour l'ensemble des applications utilisatrices de service.

L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés, sur lesquels : - la figure 1 est une vue schématique illustrant une architecture hiérarchique distribuée d'accès multiples à des services selon l'invention ; - la figure 2 est une vue schématique illustrant le fonctionnement d'un fournisseur local de services faisant partie de l'architecture de la figure 1 ; et - la figure 3 est une vue schématique illustrant le fonctionnement d'un fournisseur distant de services faisant partie de l'architecture de la figure 1. On a en effet représenté sur la figure 1, un exemple d'une architecture 10 hiérarchique distribuée d'accès multiples à des services selon l'invention. Cette architecture est utilisable dans des systèmes avioniques.

Une telle architecture 10 comporte par exemple cinq modules physiques, désignés par les références générales 12, 14, 16, 18 et 19 sur cette figure 1. Ces modules physiques sont embarqués par exemple à bord d'un même aéronef et raccordés entre eux dans un réseau informatique de communication avionique, désigné par la référence générale 20. Bien entendu, l'architecture 10 peut comporter d'autres modules physiques, non-représentés sur la figure 1. Le réseau 20 comporte une pluralité de ressources matérielles, comme par exemple des câbles raccordant physiquement les modules physiques entre eux et par exemple des commutateurs assurant le transfert entre les modules physiques, des données numériques. Le réseau 20 comporte également une pluralité de ressources immatérielles assurant un tel transfert au niveau logiciel. Ces ressources sont représentées par exemple par des ressources de traitement, des ressources de mémorisation ou des ressources de communication. Le réseau informatique 20 est conforme par exemple à la norme de communication ARINC 664. La communication entre les différents éléments du réseau informatique 20 est basée sur l'adressage UDP/IP (pour « User Datagram Protocol / Internet Protocol » en 20 anglais). L'architecture du réseau informatique 20 est apte à supporter le concept d'avionique modulaire intégrée (IMA pour « Integrated Modular Avionics » en anglais). Ce concept permet en particulier de supporter plusieurs applications sur la même ressource de traitement. 25 Ainsi, dans une telle architecture 10 utilisable dans des systèmes avioniques, une application est par exemple un logiciel mettant en oeuvre par exemple l'exécution des tâches liées au pilotage de l'aéronef ou à la surveillance de ses systèmes vitaux. De manière générale, de telles applications sont réparties dans un ensemble de ressources de traitement embarquées sous la forme de modules physiques. 30 En fonction de leurs tâches précises, ces applications peuvent être redondantes et/ou répondre à un certain niveau de robustesse. Chaque application est apte à manipuler et/ou traiter des données numériques en utilisant au moins un service. Un service est défini comme étant une suite d'actions prédéfinie comme par 35 exemple enregistrement de données, lecture de l'heure globale de la plate-forme, lecture d'une carte de terrain dans une base de données, etc.

Cette suite est réalisée par un fournisseur de services spécifique permettant la réalisation de la suite d'actions par un ensemble d'unités logicielles et/ou matérielles. Un service est accessible depuis une application ou un groupe d'applications abonnées via l'architecture 10 hiérarchique distribuée d'accès multiples à des services.

En variante, un service est représenté par un logiciel effectuant des commandes spécifiques d'une application. Les applications et les services sont intégrés dans les modules physiques 12, 14, 16, 18 et 19. Ainsi par exemple, le module 12 comporte une mémoire apte à stocker une application Al, le module 14 comporte une mémoire apte à stocker des applications A2, A3, A4 et A5 et le module 16 comporte une mémoire apte à stocker des applications A6 et A7. De manière analogue, le module 16 comporte un service S1, le module 18 comporte des services S2, S3 et S4 et le module 19 comporte des services S5 et S6.

Chaque application est apte à communiquer avec un ou plusieurs services à travers le réseau informatique 20 en envoyant des requêtes vers ce service ou ce groupe de services. De même, chaque service est apte à communiquer avec une ou plusieurs applications à travers le réseau informatique 20 en envoyant des réponses vers cette application ou ce groupe d'applications. Une telle communication comporte deux niveaux hiérarchiques par exemple. A cet effet, chaque application est connectée à un fournisseur local de services représentant un premier niveau hiérarchique. Ainsi, dans l'exemple de réalisation de la figure 1, le module 12 comporte un fournisseur local de services FL, connecté à l'application A1, le module 14 comporte un fournisseur local de services FL2 connecté à l'application A2 et un fournisseur local de services FL3 connecté aux applications A3, A4 et A5 et le module 16 comporte un fournisseur local de services FL4 connecté aux applications A6 et A7. Il est à remarquer que chaque application est connectée à un seul fournisseur local de services. Les fournisseurs locaux de services FL, et FL2 sont connectés chacun à une application et les fournisseurs locaux de services FL3 et FL4 sont connectés chacun à un groupe d'applications (respectivement trois et deux). Chaque fournisseur local de services est connecté directement au réseau informatique 20.

Un deuxième niveau hiérarchique est constitué par au moins un fournisseur distant de services connecté à au moins un service. Ainsi, dans l'exemple de réalisation de la figure 1, le module 16 comporte un fournisseur distant de services FDi connecté au service S1, et le module 18 comporte un fournisseur distant de services FD2 connecté au service S2 et un fournisseur distant de services distant FD3 connecté aux services S3 et S4. Le fournisseur distant de services FD2 est également connecté aux services S5 et S6 via le réseau informatique 20. Ainsi, un fournisseur distant de services est apte à être connecté à un service ou à un groupe de services n'appartenant pas au module physique de ce fournisseur distant. Il est également à remarquer que chaque service est connecté à un seul fournisseur distant de services. Le fournisseur distant de services FDi est connecté à un service et les fournisseurs distants de services FD2 et FD3 sont connectés chacun à un groupe de services (respectivement trois et deux). Chaque fournisseur distant de services est connecté directement au réseau informatique 20. Dans l'architecture 10, la communication entre les applications et les services est gérée entièrement par les fournisseurs locaux et distants de services indépendamment des applications et des services. La topologie du réseau 10 est entièrement définie lors de la phase de construction du réseau et ne peut pas être changée au cours de fonctionnement. Autrement dit, aucune nouvelle application ni service n'apparait au cours du fonctionnement du réseau.

Les fournisseurs locaux et distants de services sont également déterminés lors de la phase de construction. De plus, chaque fournisseur distant de services est associé à une application ou à un groupe d'applications lors de la phase de construction. Ainsi, un tel fournisseur distant de services est apte à communiquer uniquement avec l'application ou le groupe d'applications qui lui est associé. Le réseau 10 est alors un réseau à configuration statique. Un exemple d'une architecture possible pour un fournisseur local de services est illustré sur la figure 2. On a en effet illustré sur cette figure 2, l'architecture du fournisseur local de services FL4, connecté aux applications A6 et A7.

Un tel exemple permet d'illustrer un partitionnement des requêtes multiples vers un ou plusieurs services. Bien entendu, cet exemple reste valable pour tous les autres fournisseurs locaux de services FL1, FL2 et FL3 en changeant simplement le nombre d'applications connectées. Le fournisseur FL4 comporte deux files 26 et 27 de requêtes de services formées par des données numériques représentant des requêtes émises respectivement par les applications A6 et A7. Ces requêtes comportent des commandes pour un ou plusieurs services.

Le fournisseur FL4 comporte en outre un premier canal configurable 28 connecté à ces deux files 26 et 27. Le canal 28 est apte à gérer ces files. Plus précisément, le canal est une ressource ou un ensemble de ressources capable de traiter un ensemble de files de requêtes dissociées, c'est-à-dire sans ordre temporel, suivant une loi prédéfinie de traitement permettant ainsi l'ordonnancement temporel de ces requêtes ainsi que leurs contrôles. A cette fin, le canal 28 comporte des moyens 29 de gestion des requêtes. Ces moyens permettent de traiter les requêtes de deux files 26 et 27 d'après des lois de gestion et de contrôle définies lors de la phase de construction. Ces moyens 29 permettent en outre de répertorier toutes les requêtes émises par les applications correspondantes dans un journal Ji. Le premier canal configurable 28 comporte également des moyens 30 de vérification des droits d'accès de ces requêtes aux services demandés. Cette vérification est effectuée à l'aide d'une table de configuration T1 des droits d'accès aux services. Cette table Ti est apte à être définie lors de la phase de construction.

Le fournisseur FL4 comporte une file 31 de requêtes apte à recevoir des requêtes en provenance du premier canal configurable 28. Elle est également apte à émettre ces requêtes vers les services demandés. Pour recevoir des réponses des services aux requêtes, le fournisseur FL4 comporte une file 32 de réponses de ces services apte à recevoir et à stocker les 30 réponses. Le fournisseur FL4 comporte en outre un deuxième canal configurable 33 connecté à cette file 32. Le canal 33 est apte à gérer cette file. La notion de canal mentionnée ci-dessus pour le premier canal configurable 28 s'applique aussi au deuxième canal configurable 33 de façon réciproque pour les files de 35 réponses aux requêtes.

A cette fin, le deuxième canal configurable comporte des moyens 34 de vérification des droits d'accès de ces réponses aux applications correspondantes. Cette vérification est effectuée à l'aide d'une table de configuration T2 des droits d'accès aux applications.

Cette table T2 est apte à être définie lors de la phase de construction. Le canal 33 comporte également des moyens 35 de gestion des réponses. Ces moyens permettent de traiter les réponses vers les applications correspondantes d'après des lois de gestion et de contrôle définies lors de la phase de construction. Ces moyens 35 permettent en outre de répertorier toutes les réponses émises vers les applications correspondantes dans un journal J2. Enfin le fournisseur FL4 comporte deux files de réponses 36 et 37 pour des réponses reçues respectivement pour les applications A6 et A7. Ces deux files 36 et 37 sont connectées au deuxième canal configurable 33 aptes à recevoir des réponses traitées en provenance de la file 32 de réponses des services et à les envoyer vers l'application correspondante. Un exemple d'une architecture possible pour un fournisseur distant de services est illustré sur la figure 3. On a effet illustré sur cette figure 3, l'architecture du fournisseur distant de services FD3 connecté aux services S3 et S4. Ce fournisseur est par exemple associé à l'application A1 et au groupe d'applications A6 et A7. Un tel exemple permet d'illustrer un partitionnement des réponses multiples vers une ou plusieurs applications. Bien entendu, cet exemple reste valable pour les autres fournisseurs distants de services FD, et FD2.

Le fournisseur FD3 comporte deux files 38 et 39 de requêtes aptes à recevoir respectivement des requêtes de l'application A1 et du groupe d'applications A6 et A7. Le fournisseur FD3 comporte en outre un premier canal configurable 40 connecté à ces deux files 38 et 39. Le canal 40 est apte à gérer ces files. A cet effet, le canal 40 comporte des moyens 41 de vérification des droits d'accès de ces requêtes aux services demandés. Cette vérification est effectuée à l'aide d'une table de configuration T3 des droits d'accès aux services. Cette table T3 est apte à être définie lors de la phase de construction. Le canal 40 comporte en outre des moyens 42 de gestion des requêtes. Ces moyens permettent de traiter les requêtes en provenance des applications correspondantes d'après des lois de gestion et de contrôle définies lors de la phase de construction. Ceci permet en particulier de diriger une requête vers le service demandé.

Ces moyens 42 permettent en outre de répertorier toutes les requêtes reçues dans un journal J3. Le canal 40 comporte également des moyens 43 de vérification des droits d'accès des requêtes traitées par les moyens de gestion 42 aux services demandés. Cette vérification est effectuée à l'aide d'une table de configuration T4 des droits d'accès aux services. Cette table T4 est apte à être définie lors de la phase de construction. Le fournisseur FD3 comporte deux files 44 et 45 de requêtes aptes à recevoir des requêtes traitées pour respectivement les services S3 et S4. Ces files 44 et 45 sont également aptes à envoyer les requêtes vers le service correspondant. Chaque service S3 ou S4 est apte à traiter une seule requête à la fois. En revanche, deux files de requêtes 44 et 45 distinctes permettent à ces services de fonctionner indépendamment l'un de l'autre. Le fournisseur FD3 comporte en outre deux files 54 et 55 de réponses issues respectivement des services S3 et S4. Le fournisseur FD3 comporte en outre un deuxième canal configurable 56 connecté à ces deux files 54 et 55. Ce canal 56 est apte à gérer ces files. A cet effet, le canal 56 comporte des moyens 57 de vérification des droits d'accès de ces réponses aux applications correspondantes. Cette vérification est effectuée à l'aide d'une table de configuration T5 des droits d'accès aux applications. Cette table T5 est apte à être définie lors de la phase de construction. Le canal 56 comporte en outre des moyens 58 de gestion des réponses. Ces moyens permettent de traiter les réponses en provenance des services correspondants d'après des lois de gestion et de contrôle définies lors de la phase de construction. Ceci permet en particulier de diriger une réponse vers une application ou un groupe d'applications correspondantes. Ces moyens 58 permettent en outre de répertorier toutes les réponses émises par les services correspondants dans un journal J. Le canal 56 comporte également des moyens 59 de vérification des droits d'accès des réponses traitées par les moyens de gestion 58 aux applications demandées. Cette vérification est effectuée à l'aide d'une table de configuration T6 des droits d'accès aux applications. Cette table T6 est apte à être définie lors de la phase de construction. Enfin, le fournisseur FD3 comporte deux files 60 et 61 de réponses aptes à recevoir des réponses traitées pour respectivement l'application Al et le groupe d'applications A6 et A7.

Ces files 60 et 61 sont également aptes à envoyer les réponses vers les applications correspondantes. Le réseau 20 comporte également un journal J5 apte à répertorier toutes les requêtes et toutes les réponses émises dans le réseau 20.

Le temps de transfert des requêtes ou des réponses dans chaque fournisseur local ou distant de services est entièrement maîtrisé par ce fournisseur. Le temps de transfert des requêtes et des réponses dans le réseau 20 est entièrement maîtrisé suivant les capacités du réseau informatique de communication avionique 20.

Le temps de transfert maximal pour chaque requête ou réponse peut être déterminé à l'aide des tables de configurations correspondantes. Ainsi, aucune application ni service n'est en mesure de bloquer ou de « monopoliser » le réseau. Une application n'a pas connaissance des contraintes de l'architecture 10, seuls les fournisseurs locaux et distants de services déterminent l'accès aux services demandés par des applications. Dans le cas d'une défaillance d'une application, le fournisseur local de services correspondant à cette application bloque toutes les communications de cette application avec le réseau.

De même, dans le cas d'une défaillance d'un service, celui-ci est coupé du reste du réseau par le fournisseur de services distant correspondant. Bien entendu d'autres modes de réalisation des fournisseurs de services locaux et distants peuvent être envisagés. Le fonctionnement de l'architecture 10 de réseau informatique 20 selon l'invention va être décrit maintenant. Lors de la phase de construction du réseau, on définit la topologie de ce réseau. Une fois que la topologie est connue, chaque fournisseur local de services est connecté à une application ou à un groupe d'applications. De même, chaque fournisseur distant de services est connecté à un service ou à un groupe de services. Il est par ailleurs associé à une application ou un groupe d'applications. Puis, les tables de configuration d'accès aux services et aux applications sont définies pour tous les fournisseurs locaux et distants de services. Ainsi, dans l'exemple illustré sur les figures 2 et 3, les tables de configuration d'accès aux services T1, T3 et T4 et les tables de configuration d'accès aux applications T2, T5 et T6 sont définies.

Ceci permet en particulier de déterminer le temps maximal de transfert d'une requête d'une application vers chaque service. De même, ceci permet de déterminer le temps maximal de transfert d'une réponse d'un service vers chaque application.

On définit par ailleurs des lois de gestion et de contrôle des requêtes dans le premier canal configurable de chaque fournisseur local ou distant de services. On définit également des lois de gestion et de contrôle des réponses dans le deuxième canal configurable de chaque fournisseur local ou distant de services. Ainsi, par exemple, lors du fonctionnement du réseau 20, une requête émise par l'application A6 et vers le service S3 est traitée d'abord par les moyens de gestion 29 et les moyens de vérification 30 du fournisseur de service local FL4. Ceci constitue le premier niveau hiérarchique de vérification. Ensuite, la requête est transmise par le réseau 20 jusqu'au fournisseur de services distant FD3.

Dans ce fournisseur, la requête passe à travers les moyens de vérification 41 puis à travers les moyens de gestion 42 et finalement par les moyens de vérification 43. Ceci constitue le deuxième niveau hiérarchique de vérification. Ainsi, les deux niveaux hiérarchiques de vérification sont indépendants ce qui permet de détecter plus efficacement une situation non-autorisée ou une situation de 20 défaillance. La requête est par ailleurs répertoriée dans les journaux J1, J5 et J3, Une réponse émise par le service S3 atteint l'application A6 en passant aussi par deux niveaux hiérarchiques. Le premier niveau hiérarchique est constitué par les moyens de vérification 57, les 25 moyens de gestion 58 et les moyens de vérification 59 au sein du fournisseur distant FD3. Le deuxième niveau hiérarchique est constitué par les moyens de vérification 34, les moyens de gestion 35 au sein du fournisseur local de services FL4. La réponse est par ailleurs répertoriée dans les journaux J4, J5 et J2. L'indépendance complète de l'architecture selon la présente invention décrite ci- 30 dessus des modules physiques embarqués, présente un avantage particulier. En effet, les modules physiques ne se traduisent par aucune contrainte sur une telle architecture. Les applications communiquent avec les services toujours de la même façon, indépendamment de leur localisation physique. 35 Ainsi, l'exemple de réalisation de la figure 1 illustre une cohabitation des applications A6 et A7 avec le service S1 dans le même module 16.

Même dans ce cas, la communication entre les applications et le service s'effectue via le réseau extérieur 20. Bien entendu d'autres modes de réalisation peuvent encore être envisagés.5

Claims

REVENDICATIONS1.- Architecture (10) hiérarchique distribuée d'accès multiples à des services pour des systèmes avioniques basés notamment sur le concept d'avionique modulaire intégrée (IMA), l'architecture comportant : - un réseau (20) informatique de communication avionique ; - une pluralité de services (S1,..., S6) ; et - une pluralité d'applications (A1,..., A7), chaque application (A1,..., A7) étant apte à manipuler et/ou traiter des données numériques en utilisant au moins un service (S1,-, S6) ; caractérisée en ce que - l'architecture (10) comporte en outre une pluralité de fournisseurs locaux de services (FLi,..., FL4), chaque fournisseur local de services (FL1,..., FL4) étant connecté à une application (A1,..., A7) ou à un groupe d'applications (A1,..., A7), et une pluralité de fournisseurs distants de services (FD1,..., FD3), chaque fournisseur distant de services (FD1,..., FD3) étant connecté à un service (S1,..., S6) ou à un groupe de services (S1,..., S6) et étant associé à une application (A1,..., A7) ou à un groupe d'applications (A1,..., A7) ; - chaque application (A1,..., A7) est apte à communiquer avec un ou plusieurs services (S1,..., S6) à travers un premier niveau hiérarchique comportant un fournisseur local de services FL4), et un deuxième niveau hiérarchique comportant au moins un fournisseur distant de services (FD1,..., FD3) ; et - chaque service (S1,..., S6) est apte à communiquer avec une ou plusieurs applications A7) à travers un premier niveau hiérarchique comportant un fournisseur distant de services (FD1,..., FD3), et un deuxième niveau hiérarchique comportant au moins un fournisseur local de services (FL1,...,
2.- Architecture (10) selon la revendication 1, caractérisée en ce que la communication entre les applications A7) et les services (S1,..., S6) est gérée entièrement par des fournisseurs locaux (FL1,..., FL4) et distants (FD1,..., FD3) de services indépendamment de l'application et du service concernés.
3. - Architecture (10) selon la revendication 1 ou 2, caractérisée en ce que la communication entre les applications (A1,..., A7) et les services (Si,..., S6) est gérée entièrement par des fournisseurs locaux de services FL4) indépendamment de la localisation respective des applications A7) et des services (S1,..., S6).
4.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque fournisseur local de services FL4) comporte desmoyens de gestion temporelle et spatiale de la communication entre chaque application A7) connectée à ce fournisseur local de services et chaque service (S1,..., S6) vu à travers le réseau (20).
5.- Architecture (10) selon la revendication 4, caractérisée en ce que chaque fournisseur distant de services (FD1,..., FD3) comporte des moyens de gestion temporelle et spatiale de la communication entre chaque service (S1,..., S6) connecté à ce fournisseur distant de services et chaque application (A1,..., A7) vue à travers le réseau (20).
6.- Architecture (10) selon la revendication 4 ou 5, caractérisée en ce que les moyens de gestion sont associés à des tables de configuration (T1, T3, T4) des droits d'accès aux services S6) et/ou à des tables de configuration (T2, T5, T6) des droits d'accès aux applications A7).
7.- Architecture (10) selon la revendication 6, caractérisée en ce que les tables de configuration (T1, T3, T4) des droits d'accès aux services (S1,..., S6) et/ou les tables de configuration (T2, T5, T6) des droits d'accès aux applications A7) sont prédéterminées lors de la phase de conception du réseau.
8.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que le réseau (20) est conforme à la norme ARINC 664.
9.- Architecture (10) selon la revendication 8, caractérisée en ce que la communication entre les différents éléments du réseau est basée sur l'adressage UDP/IP.
10.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle comporte des modules physiques (12, 14, 16, 18, 19) reliés entre eux dans le réseau et définissant l'emplacement physique des fournisseurs locaux (FLi,..., FL4) et distants (FD1,...,FD3) de services, des applications A7) et des services (S1,..., S6).
11.- Architecture (10) selon la revendication 10, caractérisée en ce qu'elle comporte au moins un module physique (12, 14, 16, 18, 19) comportant : - un ou plusieurs fournisseurs locaux de services FL4) et l'ensemble des applications (A1,..., A7) connectées à ces fournisseurs ; et - un ou plusieurs fournisseurs distants de services (FD1,..., FD3) et l'ensemble des services (S1,..., S6) connectés à ces fournisseurs, le ou les fournisseurs distants de services étant associés par configuration à une ou à plusieurs applications de l'ensemble des applications (A1,..., A7).
12.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque fournisseur local de services (FLi,..., FL4) comporte en outre :- un journal (J1) de requêtes apte à répertorier toutes les requêtes émises par chaque application ou groupe d'applications connecté à ce fournisseur local de services (FL1,..., FL4); et - un journal (J2) de réponses apte à répertorier toutes les réponses reçues pour chaque application ou groupe d'applications connecté à ce fournisseur local de services (FL1,...,
13.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque fournisseur local de services FL4) comporte : - une file de requêtes de services (26, 27) de chaque application ou groupe d'applications associées à ce fournisseur local de services FL4) apte à recevoir des requêtes de cette application ou de ce groupe d'applications ; - une file de requêtes (31) pour les services, - une file de réponses (32) de ces services, - une file de réponses (36, 37) pour chaque application ou groupe d'applications associées à ce fournisseur local de services (FL1,..., FL4) apte à envoyer des réponses vers cette application ou vers ce groupe d'applications, chaque file étant gérée par un canal configurable (28, 33).
14.- Architecture (10) selon la revendication 13, caractérisée en ce que chaque fournisseur local de services (FL1,..., FL4) connecté à un groupe d'applications A7) est apte à gérer les accès multiples de ces applications (A1,..., A7) à tous les services (S1,...,S6), une telle gestion supportant : - le partitionnement des requêtes de chaque application A7) du groupe vers les services (S1,..., S6) incluant des droits d'accès respectifs aux services (S1,..., S6) ; et - le partitionnement des réponses des services S6) vers chaque application A7) du groupe incluant les droits d'accès respectifs aux applications ; la gestion comportant en outre : - des lois configurables de gestion et de contrôle des files de requêtes et des files de réponses ; et - l'inscription de ces requêtes et de ces réponses dans le journal (J1, J2) correspondant.
15.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque fournisseur distant de services (FD1,..., FD3) comporte en outre :- un journal (J3) de requêtes apte à répertorier toutes les requêtes reçues d'une application ou d'un groupe d'applications associées à ce fournisseur distant de services FD3) ; et - un journal (J4) de réponses apte à répertorier toutes les réponses émises vers une application ou vers un groupe d'applications associées à ce fournisseur distant de services (FD1,..-, FD3).
16.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque fournisseur distant de services (FD1,..., FD3) comporte : - une file de requêtes (38, 39) pour chaque application ou groupe d'applications associées à ce fournisseur distant de services (FD1,..., FD3) apte à recevoir des requêtes de cette application ou de ce groupe d'applications ; - une file de requêtes (44, 45) pour chaque service, - une file de réponses (54, 55) de chaque service, - une file de réponses (60, 61) pour chaque application ou groupe d'applications associées à ce fournisseur distant de services (FD1,..., FD3) apte à envoyer des réponses vers cette application ou vers ce groupe d'applications, chaque file étant gérée par un canal configurable (40, 56).
17.- Architecture (10) selon la revendication 16, caractérisée en ce que chaque fournisseur distant de services (FD1,..., FD3) connecté à un groupe de services (S1,..., S6) est apte à gérer les accès multiples de toutes les applications (A1,..., A7) à ces services (S1,..., S6), une telle gestion supportant : - le partitionnement des requêtes des applications (A1,..., A7) vers chaque service (Si,..., , S6) du groupe incluant des droits d'accès respectifs aux services (Si,..., S6) ; et - le partitionnement des réponses de chaque service (S1,..., S6) du groupe vers les applications (A1,..., A7) incluant les droits d'accès respectifs aux applications ; la gestion comportant en outre : - des lois configurables de gestion et de contrôle des files de requêtes et des files de réponses ; et - l'inscription de ces requêtes et de ces réponses dans le journal (J3, J4) 30 correspondant.
18.- Architecture (10) selon l'une quelconque des revendications précédentes, caractérisée en ce que le réseau est associé à un journal (J5) d'observation des échanges entre les fournisseurs pour l'ensemble des applications utilisatrices de service.