FR 2905491 A1 20080307 FR 0706096 A 20070830 1 La présente invention concerne un procéue automatique, basé sur modèle, pour l'intégration d'une architecture fonctionnelle de système avec une architecture physique de système pour former un système électronique, en particulier un système avionique. Il s'agit de systèmes présentant plusieurs processeurs et reliés à plusieurs réseaux (appelés systèmes répartis encastrés ). Dans développement de systèmes avioniques modulaires intégrés (IMA), la fonctionnalité du logiciel est développée indépendamment de l'équipement sous forme d'un graphe de fonction. Cette architecture appelée fonctionnelle peut-être répartie, intégrée sur différentes plates-formes d'équipement (architecture appelée physique) par de conditions d'encadrement spécifiques l'équipement et spécifiques au système d'exploitation. Cette répartition est inscrite dans des tableaux de système. Les systèmes IMA sont actuellement utilisés dans de nombreux systèmes avioniques récents (par exemple Airbus A 380, Eurofighter), des tableaux de système IMA correspondants doivent être créés à la main. La complexité élevée du système se manifeste dans de multiples tableaux de système, lesquels peuvent présenter lors de la création manuelle un taux d'erreur élevé. Un comportement erroné du système, entraîné par des tableaux de système IMA erronés ou inconsistants est difficile à 2905491 2 localiser en tant que tel, car il s'agit typiquement d'erreur fonctionnelle pour l'utilisateur. La présente invention a pour objectif de créer un procédé automatique, basé sur modèle, pour l'intégration 5 d'une architecture fonctionnelle et physique de système. Cet objectif est atteint par le procédé d~ ia revendication 1. Une réalisation avantageuse fait l'objet d'une sous-revendication. Selon la présente invention est créé un procédé 10 automatique, basé sur modèle, pour l'intégration d'une architecture fonctionnelle de système (désignée par la suite également comme application) avec une architecture physique de système (désignée par la suite également comme plate-forme) pour former un système électronique, 15 en particulier un système avionique, l'architecture fonctionnelle de système comprenant différents composants d'application et l'architecture physique de système comprenant différents composants de plate-forme. Une affectation (désignée par la suite également comme 20 liaison) des composants d'application aux composants de plate-forme est entreprise de façon telle que 1. l'affectation est complète conformément à l'étape 5 ; II. le déroulement fonctionnel de l'architecture 25 fonctionnelle du système est garanti ; III. les demandes non fonctionnelles enver.: système complet sont remplies. Lors d'une première étape, la spécification de l'architecture fonctionnelle de système ainsi que de l'architecture physique de système est mise à disposition, laquelle présente les propriétés suivantes : 2905491 3 1. Des composants de plate-forme ainsi que des composants d'application constituent une hiérarchie, dans laquelle les sous composants représentent un affinement structurel des composants pères correspondants, 5 II. Au moyen d'une extension de comportement aussi bien des composants de plate-forme que des composants d'application, d'autres liaisons, fonctions et attributs peuvent être ajoutés à ceux-ci, III. Les composants de plate--forme présentent ce 10 que l'on appelle des sous composants de plate-forme logiques comme emplacements pour des composants d'application ajoutés ultérieurement. Lors d'une seconde étape, la. quantité des sous composants de plate-forme logiques de l'architecture 15 physique de système est déterminée. Lors d'une troisième étape, la quantité des composants d'applications affectés à l'architecture physique de système est déterminée, l'affectation d'un composant d'application à un composant de plate-forme 20 étant permise, si 1. un composant d'application existe également en tant que sous composant logique de plate-forme du composant de plate-forme, ou II. un composant d'application est dérivé d'un 25 sous composant logique de plate-forme du composant de plate-forme grâce à une extension de comportement. Dans le cas où l'affectation d'un composant d'application à un composant de plate-forme n'est pas autorisée, on peut vérifier, dans une réalisation 30 avantageuse, si la liaison d'un composant père du composant d'application est autorisée. 2905491 4 Lors d'une quatrième étape, la quantité de Clusters de composants d'application est déterminée, un Cluster comprenant des composants d'application tels qu'ils doivent être affectés au même composant de plate- 5 forme. Lors d'une cinquième étape, une première variante de système est produite par une affectation complète des Clusters de composants d'application aux composants de plate-forme. 10 Lors d'une sixième étape, on vérifie que la variante de système produite remplit les demandes fonctionnelles et non fonctionnelles prescrites ; dans le cas où la vérification est négative, on produit, par changement de l'affectation des Clusters aux composants 15 de plate-forme, de nouvelles variantes de système, et ce, jusqu'à obtenir une variante de système autorisée. Lors d'une septième étape, enfin, la variante de système autorisée est transformée en un tableau de système pour le système électronique. 20 La présente invention rassemble les avantages suivants lors de l'utilisation dans des aéronefs : augmentation de l'efficacité lors de l'intégration de systèmes IMA grâce une automatisation et à une sécurité inhérente de consistance ; 25 - accélération de modifications incrémentielles dans le design de système IMA grâce à une automatisation des étapes importantes d'intégration de systèmes ; - réutilisation possible de composants et de variantes configurées de système grâce à un 30 enregistrement dans une base de données; 2905491 5 - établissement d'un savoir-faire à long terme et augmentation potentielle de l'efficacité lors du développement de nouveaux systèmes IMA ; - établissement de tableaux de système, de façon 5 adaptable à diverses plates-formes grâce à un échange simple du générateur de tableaux de système (par exemple ASAAC/ARINC), le configurateur de système et le format de la base de données restant identiques (ASAAC et ARINC sont des plates-formes IMA standardisées à l'échelle 10 internationale). La présente invention est expliquée en détail par la suite à l'aide d'exemples concrets avec référence aux figures. Il est montré : 15 figure 1 la vue générale d'un agencement pour la réalisation du procédé selon la présente invention ; Figure 2 une représentation en catégories de 20 composants et en propriétés de composants ; Figure 3 des exemples pour l'affinement structurel de composants ; 25 Figure 4 une représentation pcur l'extension de comportement de composants ; Figure 5 une représentation de principe de la description de couches ; Figure 6 une application ; 30 2905491 6 Figure 7 une plate-forme ; Figure 8 une liaison partielle d'une application à une plate-forme ; Figure 9 le déroulement du procédé selon la présente invention ; Figure 10 une représentation du déroulement de la 10 deuxième étape du procédé selon la présente invention ; Figure 11 une représentation du déroulement de la troisième étape du procédé selon la 15 présente invention ; Figure 12 une représentation du déroulement de la quatrième étape du procédé selon la présente invention ; Figure 13 une représentation du déroulement de la cinquième étape du procédé selon la présente invention ; 25 Figure 14 une représentation du déroulement de la septième étape du procédé selon lei présente invention. La figure 1 est une vue générale d'un agencement 30 pour la réalisation du procédé selon la présente invention. 5 20 2905491 7 La base de données 1 saisit aussi bien des ressources d'équipement que des fonctions de logiciel sous forme de descriptions formelles de composants. Ceci comprend le comportement fonctionnel décrit formellement 5 et des propriétés non fonctionnelles des composants. La spécification 2 se composant d'architecture de système fonctionnelle (application) et physique de système (plate-forme) est créée par le concepteur de système. Des composants existants de la base de données 1 peuvent 10 ainsi être utilisés. En outre, de nouveaux composants peuvent être décrits et importés (multiformalisme) en utilisant des outils existants. Le ccnfigurateur 3 a pour objectif de regrouper les deux parties de la spécification, en déterminant une affectation de 15 composants d'application (logiciel) à des composants de plate-forme (équipement) de telle sorte que a) l'affectation est complète, b) le déroulement fonctionnel de l'application est garanti et 20 c) les demandes non fonctionnelles du système complet sont remplies. La variante de système 4 ainsi produite par le ccnfigurateur 3 est dans un format indépendant du système cible. Des variantes de système déterminées peuvent ainsi être déposées en totalité ou en 25 partie dans la base de données 1 pour la réutilisation ultérieure. L'objectif du générateur de tableaux de système 5 consiste à transformer la variante de système dans un format dépendant du système cible. Le tableau de système 6 produit par le générateur de tableaux de 30 système contient toutes les informations nécessaires pour la configuration du système cible. Le tableau de système est lu et traité par le système cible lui-même. 2905491 8 Méthode formelle de spécification (figures 2 à 8) Le procédé selon la présente invention se base sur une méthode formelle de spécification. Celle-ci est 5 décrite par la suite, avant d'expliquer en détail le procédé selon la présente invention lui-même. 1-Description basée sur les composants La description basée sur les composants 10 (spécification également) de fonctionnalités de traitement et de communication au moyen de ce que l'on appelle des composants de traitement et des composants de communication respectifs. Des descriptions de composants au sens de cette invention contiennent : 15 a) des ports pour la modélisation du flux de données b) des méthodes pour la modélisation du flux de contrôle et c) des attributs pour la description de propriétés 20 non fonctionnelles, comme par exemple des largeurs de bandes de systèmes de réseaux, des temps d'exécution, des dimensions de modules d'équipements, etc. Comme le représente la figure 2, on distingue entre des ports des catégories input / output / 25 inout ( entrée / sortie / entrée-sortie ) et des méthodes de catégories provided / required ( présente / requise ). Des composants avec les méthodes de la catégorie required ( requise ) nécessitent l'input (l'entrée) d'un ou de plusieurs sous 30 programmes. Des composants avec les méthodes de la catégorie provided ( présente ) mettent à 2905491 9 disposition des fonctions sous forme d'un ou de plusieurs sous programmes. Les attributs au sens de cette invention possèdent un nom, un type, une plage de valeur (selon le type), une 5 valeur par défaut (selon le type) et une fonction optionnelle d'évaluation. 2-Description d'un affinement structurel Il existe la possibilité de l'affinement 10 structurel de composants au moyen de sous composants, comme le représentent à titre d'exemple les figures 3a-c à l'aide des composants DPM, MMM, GPM. L'affinement structurel est utilisé pour la modélisation de la hiérarchie de système. 15 Cette méthode de l'affinement structurel se base sur le fait qu'un composant père est modelé au moyen de n'importe quel nombre de sous composants et que les flux de données (via les ports) et les flux de contrôle (via les méthodes) entre ces sous composants sont spécifiés. 20 On distingue en ce qui concerne les sous composants entre les véritables sous composants et les sous composants logiques, ces derniers représentant des emplacements (désignés également comme templates ( gabarit ) pour de véritables sous composants ajoutés ultérieurement. 25 À cet effet, il existe la possibilité de spécifier pour un sous composant logique le nombre minimal et maximal des véritables sous composants à ajouter (voir la figure 3 où ces valeurs sont indiquées à gauche sous les sous composants). 30 En outre, des dépendances fonctionnelles entre les attributs des composants pères et les attributs des sous composants contenus sont définies sous forme de fonctions 2905491 10 d'évaluation. Il s'agit ici d'un principe général issu d'une structure de compilation, appliquée ici à la hiérarchie de système. 5 3-Description de l'extension de comportement Il existe la possibilité de l'extension de comportement de composants, comme le représente la figure 4 sur un exemple de composants de traitement. L'extension de comportement dans le sens de cette invention permet 10 d'ajouter d'autres ports, méthodes et attributs à un composant. L'extension de comportement équivaut ainsi au conseil de spécialisation dans des langages de programmation orientée sur l'objet (par exemple Java), c'est-à-dire qu'un super composant est élargi en ce qui 15 concerne ses interfaces pour former un ou plusieurs sous-types (plus concrets) de ce composant. Enfin, on représente de manière graphique grâce à une flèche unidirectionnelle le passage du composant de sous-titre au super composant. 20 L'extension de comportement peut être utilisée aussi bien pour les composants de traitement que pour les composants de communication. La méthode de modélisation formelle décrite ici définit la relation extends ( étendre ) comme primitive à la spécification pour 25 l'extension de comportement. Mathématiquement correct (voir figure 4) . un sous-titre d'un composant A (par exemple MEM) est soit le composant lui-même ou chaque composant A' (par exemple ObstacleProvision), qui est lié à A au moyen d'une suite ininterrompue de relations 30 extends ( étendre ). 4-Description de couches (d'architecture) 2905491 11 Ceci concerne la possibilité de décrire une architecture au moyen de couches (en anglais layer), lesquelles divisent une quantité de composants dans les deux classes composants de plate-forme ( Platform 5 Building Blocks ) et composants d'application ( Application Building Blocks ) (figure 5). La classe des composants de plate-forme contient tous les composants, à partir desquels peut être regroupée une plate-forme de traitement concrète (au sens d'un réseau 10 d'ordinateurs se composant d'équipements et de logiciels, comprenant sous ce dernier en particulier le système d'exploitation). La classe des composants d'application contient en revanche tous les composants, à partir desquels peuvent être créées des applications conformes à 15 la plate-forme. Des liaisons possibles des composants d'application aux composants de plate-forme font partie de la description des composants de plate-forme et sont représentés au moyen de sous composants logiques (ou virtuels) de composants de plate-forme (représentation 20 graphique au moyen de bord hachuré). En vue d'une meilleure compréhension, la description d'une application possible ainsi que d'une plate-forme est représentée respectivement sur les figures 6 et 7, qui ont été dérivées de la représentation 25 en couches précédente. 5-Description de la liaison d'application Ceci concerne la description de différentes variantes de l'affectation (liaison) d'une application se 30 composant de composants d'application sur une plate-forme se composant de composants de plate-forme. Une telle liaison est possible seulement si, soit tous les 2905491 12 composants d'application existent en tant que sous composants logiques du nouveau composant dans la plate-forme ou soi_` si ils ont été dérivés d'une tel sous composant au moyen d'une extension de comportement. 5 Une liaison possible d'une application à une plate-forme est représentée et décrite par la suite à titre d'exemple. La figure 8 montre une représentation graphique, on fera remarquer que dans l'intérêt d'une meilleure compréhension, seule une liaison partielle de 10 l'application à la plate-forme y a été représentée. Une liaison possible complète pourrait, en revanche, avoir l'aspect suivant : 1) les processus TerrainProvision et ObstacleProvision sont liés aux composants de plate- 15 forme MMM , étant donné que seul ce composant de plate-forme peut exécuter des processus d'application avec une mémoire API (MEM). Ceux-ci sont, selon la figure 4, tous ces processus d'applications qui ont été dérivés du processus MMMProcess au moyen de l'extension de 20 comportement. 2) le processus GraphicProcessing ( traitement graphique ) est lié au composant de plate-forme GPM , étant donné que seul ce composant de plate-forme peut exécuter des processus d'application 25 avec graphique API. Comme on le voit sur la figure 4, le processus Graphic Processing a été dérivé du processus GPMProcess au moyen de l'extension de comportement. 3) les processus ProximityWarning ( alerte de 30 proximité ) et VisionControl ( contrôle de vision ) peuvent être liés aux composants de plate-forme MMM, DPM ou GPM, étant donné que des processus d'application qui 2905491 13 ont été dérivés du processus DPMProcess (voir figure 4) peuvent être exécutés sur tous les trois composants de plate-forme (les composants de plate-forme MMM , DPM ou GPM contiennent respectivement des sous 5 composants logiques du type DPMProcess). Cependant, dans l'intérêt d'une répartition de charge uniforme, on effectue une liaison aux composants de plate-forme DPM (principe du Load Balancing ( équilibrage de charge ) sta'tique). 10 4) après la liaison réussie des composants de traitement de l'application à la plate-forme s'effectue la liaison des composants de communication correspondants. La description suivante repose sur l'acception que les deux processus ProximityWarning et VisionControl 15 ont été liés aux composants de plate-forme DPM . 5) les composants de communication LocalVirtualChannel ( canal virtuel local ) (LVC) entre les processus ProximityWarning et VisionControl sont liés aux composants de plate-forme 20 DPM . 6) tous les autres composants de communication de l'application sont des GlobalVirtualChannels (GVC), lesquels permettent une communication entre des processus d'application sur différents composants de plate-forme. 25 Les GVCs ne peuvent pas être liés directement, étant donné que des composants logiques correspondants ne font pas partie de la spécification du module (voir la figure 3 pour les composants de plate--forme DPM). Au lieu de ceux-ci sont liés les deux sous composants VCStub 30 d'un GVC (voir figure 5). Comme le montre la figure 8, cette liaison s'effectue de manière répartie sur les deux composants de plate-forme MMM, DPM, lesquels exécutent 2905491 14 les deux fonctions de traitement de l'application communiquant par l'intermédiaire du GVC. 7) dans le cas où l'affectation d'un composant d'application à un composant de plate-forme n'est pas 5 autorisée, on peut vérifier que la liaison d'un composant père de la composant d'application est autorisée. Le processus TerrainProvision en est un exemple, qui est lié en tant que composant père affiné structurellement (voir par exemple la figure 4) au composant de plate- 10 forme MMM, tous les sous composants du composant père lui étant reliés de manière implicite. On remarquera que la figure 8 est une composition des figures 10 et 11 et sert uniquement à la 15 représentation de la liaison des composants de l'architecture fonctionnelle (application) par l'intermédiaire des composants de l'architecture physique (plate-forme). On renverra pour les détails graphiques concernant le design de l'application et de la plate20 forme aux figures 10 et 11. Algorithme de configuration (figures 9 à 14) Un aperçu général sur le comportement de configuration, objet de la présente invention et des 25 dépendances entre les différentes étapes sont donnés sur la figure 9. Les différentes étapes décrivent la représentation (liaison) du composant d'application (architecture fonctionnelle) sur le composant de plate-forme (architecture physique) et sont décrites en détails 30 dans les paragraphes suivants. Étape 1 2905491 15 Au cours d'une première étape, la spécification de l'architecture fonctionnelle de système (application AK) ainsi que l'architecture physique de système (plate-forme PK) sont mises à disposition (voir figure 9). Sa 5 description se base sur la méthode de spécification décrite précédemment. Étape 2 L'objectif de cette étape est de déterminer la 10 quantité de composants logiques, proposée par le composant de plate-forme. Une réalisation à titre d'exemple est représentée sur la figure 10. Input : composant de plate-forme (PK) 15 Output : la quantité PLK (composants logiques de la plate-forme), une application des composants logiques à une quantité de composants pères possibles fvK() 20 a. La quantité PLK et l'application fvK() sont vides au début, c'est-à-dire PLK = { } et fvK () = { } b. La quantité PK contient Les composants pas encore examinés du point de vue des composants logiques et contient au début seulement la PK, c'est-à-dire PK = 25 {PK} c. Tant que la quantité (1) PK n'est pas vide (PK #H) choisir un composant K de PK et l'enlever de PK, (2) Pk est vide (PK a{}) aller à f. 30 d. pour chaque sous composant (UK) (s'il existe) de K, chercher s'il 2905491 16 (1) est un véritable sous composant, alors l'ajouter à PK (PK = PK u UK) , (2) est un sous composant logique, alors l'ajouter à la quantité PLK (PLK = PLK v UK) , ensuite ajouter K à 5 fvK (fvK = (UK) u K) e. Aller à c. f. Au cas où PLK est vide (PK = II) , alors rien ne peut être lié à ce composant de plate-forme (erreur), sinon PLK contient la quantité de composants logiques de 10 PK. Étape 3 L'objectif de cette étape est de déterminer la quantité de sous composants d'applications à lier ABK. 15 Une exécution à titre d'exemple est représentée sur la figure 11. Input : composant d'application AK et PLK 20 Output : la quantité ABK (les sous composants d'application à lier) a. La quantité ABK est vide au début, c'est-à-dire ABK = {} 25 b. La quantité AK contient les composants pas encore examinés du point de vue de la liaison et contient au début seulement la AK, c'est-à-dire AK = {AK} c. Tant que la quantité (1) AK n'est pas vide (AK {}) choisir un composant 30 A de AK et l'enlever de AK, (2) AK est vide (AK= {}) aller à e. d. Au cas où le composant A 2905491 17 (1) est un sous-type d'un composant dans PLK, ajouter A à ABK (ABK = ABK UA), sinon (2) possède de véritables sous composants, ajouter tous les véritables sous composants de A dans AK, 5 sinon (3) ne peut pas être lié sur la plate-forme (erreur) e. La quantité ABK contient tous les composants à relier sur la plate-forme 10 Etape 4 L'objectif de cette étape est de calculer les conditions secondaires de liaison directe (contraintes de liaison, en particulier en raison de flux de données et de contrôle locaux nécessaires - local signifie ici sur 15 le même processeur et ainsi dans la même mémoire (on board)) par formation en Cluster, c'est-à-dire de calculer à partir de ABK la quantité de Clusters ABC à lier. Une réalisation à titre d'exemple est représentée sur la figure 12. Des composants d'application tels que 20 ceux devant être liés obligatoirement sur le même composant de plate-forme, sont un cluster. Input : ABK (les sous composants d'application à lier) 25 Output : ABC (quantité de Cluster à lier de sous composants d'application) a. La quantité ABC est vide au début, c'est-à-dire ABC = {} 30 b. Tant que la quantité (1) ABK n'est pas vide (ABK ~ {}), choisir un composant A dans ABK et l'enlever de ABK, sinon 2905491 18 (2) ABK est vide (ABK o {}) aller à f. c. Ajouter A dans la quantité ACLUSTER , (ACLUSTER = {AI) d. Ajouter tous les composants reliés à A par l'intermédiaire de flux de contrôle (requires/provides) 5 ou de flux de données (in/ou/inout) dans ACLUSTER, enlever ces composants de ABK, ACLUSTER contient ainsi tous les composants reliés à A (enveloppe transitive) e. Ajouter ACLUSTER dans ABC et aller à b. f. La quantité ABC contient tous les Clusters en 10 correspondance du composant d'application, chaque Cluster se composant de composants pouvant être liés sur la plate-forme. Etape 5 15 L'objectif de cette étape est de calculer une liaison initiale de Cluster sur la plate-forme. Une réalisation à titre d'exemple est représentée sur la figure 13 (pour les détails graphiques des deux composants voir les figures 10 et 11). 20 Input : fvK() (application de composants logiques vers leur composants pères) ABC (quantité de Cluster de sous composants d'applications à lier) 25 Output : S (variant de système se composant de deux sous composants AK et PK, AK étant complètement lié sur la PK) a. Produire S, avec deux véritables sous composants AK et PK 30 b. Tant que la quantité ABC (1) n'est pas vide (ABC ~ { }) , choisir un Cluster C de ABC et l'enlever de ABC, sinon 2905491 19 (2) est vide (ABC = {}) aller à f. c. Choisir de C un composant K, égaler la quantité M à fvK(K) d. Tant que la quantité M 5 (1) n'est pas vide (M ≠{}), choisir un composant VK de M et l'enlever de M, sinon (2) est vide (M = {}), il n'est alors pas possible de lier le Cluster C à la PK (erreur) ou au cas où des Clusters du sous composant de plate-forme ont 10 déjà été affectés et que ceux-ci peuvent être liés potentiellement également à d'autres sous composants de plate-forme (par un autre choix dans [d. (1)] ou [b. (1)]), alors on peut rendre ce choix rétroactif par back-tracking et réessayer de lier C. 15 e. Lorsque la VK (1) possède suffisamment de sous composants logiques non liés, pour affecter tous les composants du Cluster C à ces sous composants logiques, alors lier (relier) les composants de C aux sous composants 20 logiques correspondants de VK et aller à b. (2) ne possède pas suffisamment de sous composants logiques non liés, pour affecter tous les composants du Cluster C à ces sous composants logiques, aller alors à d. 25 f. S est une variante de système entièrement liée Etape 6 Au cours de cette étape, or. vérifie que les propriétés fonctionnelles et non fonctionnelles de la 30 variante de système sont remplies. 2905491 20 Input : S (variante de systèmes entièrement liée) Output : s (variante de système valable, c'est-à-dire remplit les propriétés fonctionnelles et non fonctionnelles) 5 a. contrôle des propriétés non fonctionnelles cumulatives, par exemple (1) demande de mémoire : chaque sous composant lié d'application (Al, A2, ...) peut définir des attributs 10 avec des demandes de mémoire (Stack, Heap, etc.). La demande de mémoire à la plate-forme est la somme de toutes les demandes de mémoire correspondante des sous composants d'application, qui sont liés sur un composant de plate-forme logique (voire étape 5e.(1)) 15 (Stack sUM = Stack (Al) + Stack (A2) + ...). Le composant direct père de plate-forme ou un de ses composants père peut définir une taille de mémoire maximale (par exemple : MaxHeap, etc.), de telle sorte que l'on peut vérifier s'il y a assez de mémoire 20 disponible pour le composant d'application sur la plate-forme. Au cas où il n'y aurait pas assez de mémoire disponible, cette propriété non fonctionnelle n'est pas remplie et la variante de système est ainsi invalide (erreur). De manière 25 analogue à l'étape 5d.(2), on peut exécuter un backtracking, pour obtenir une nouvelle variante du système. (2) charges : chaque sous composant d'application AUK définit un graphe local de tâches selon [1, 30 2] avec les tâches T (AUK) = T1r ..., Tn. Grâce à la liaison des AUK, naît un graphe global de tâches. On peut en déduire la période des tâches 2905491 21 correspondantes. Dès qu'uneapplication est liée sur un composant logique de plate-forme PFK (voir étape 5e.(1)) les temps d'exécution des tâches peuvent être calculés sur cette PFK. La charge d'une tâche T 5 est alors le rapport entre le temps d'exécution et la période (Charge(T= = temps(T, PFK) / période (T)).la quantité de tâches liées sur une PFK est donnée par la quantité de toutes les tâches des composants d'application liés 10 (T (PFK) = T(AUK1) + T(AUK2) +...) . La charge totale d'une PFK: peut ainsi être calculée par l'addition de toutes les charges partielles (charge (PFK) = charge (Tl) + charge (T2) +...) . Si cette charge est supérieure à 1, la PFK est surchargée et 15 la variante de système est invalide (erreur). De manière analogue à l'étape 5d. (2) , on peut exécuter un back-tracking pour obtenir une nouvelle variante de système. On fera remarquer que des propriétés cumulatives 20 peuvent déjà être contrôlées à l'étape 5e. comme condition supplémentaire (c'est-à-dire des composants logiques suffisamment non liés ET propriété cumulative correspondante remplies). Cela peut être un avantage étant donné qu'elles sont contrôlables très rapidement. 25 b. Contrôle des propriétés non fonctionnelles temporelles par exemple analyse de WCETs (Worst Case Execution Times = temps d'exécution / de déroulement dans le pire des cas) et BCETs (Best Case Execution Times temps d'exécution / de déroulement dans le meilleur des 30 cas) selon la méthode décrite dans [1, 2], le procédé étant adapté au modelage décrit dans l'annexe B : 2905491 22 (1) les composants de plates-formes définissent respectivement un attribut WCET et BCET, lesquels sont reliés respectivement à une fonction d'évaluation. 5 (2) ces fonctions d'évaluation possèdent comme paramètre de saisie la touche T. cette touche correspond à une touche liée sur le composant de plate-forme. (3) il existe différentes fonctions d'évaluation 10 dans la base de données (1)pour les différents procédés de Scheduling (par exemple RMS, TDMA, etc.) Après le calcul des BCET et WCET, on contrôle le respect de Deadlines (le temps entre deux événements, par exemple de l'activation d'une tâche jusqu'à la 15 désactivation) et le dépassement de la période par les WCET d'une tâche (WCET doit être inférieur à la période). Lors de la violation d'une de ces deux propriétés, (1) soit : la priorité (avec RMS) ou le Timeslot (avec TDMA) de la tâche est augmentée et l'étape [b.] 20 est renouvelée, (2) soit de manière analogue à l'étape 5d.(2), on peut exécuter un back-tracking afin d'obtenir une nouvelle variante de système. (3) soit : la variante de système est rejetée comme 25 invalide (erreur). c. contrôle des propriétés fonctionnelles par exemple : liberté Deadlock et Lifelock, accessibilité des états du système. En se basant sur la description formelle du modèle de composants (algèbre de processus 30 selon [3]), en exécute une analyse statique de la variante de systèmes, qui identifie des états possibles Deadlock et Lifelock. Au cas où des deadlocks, liefelocks 2905491 23 existent ou des états de système demandés ne sont pas atteints, la variante de système est invalide (erreur). Cette analyse peut déjà être entreprise (partiellement) avant l'étape 2. 5 d. si a., b. et c. sont exécutés avec succès, la variante de système est valide. Étape 7 L'objectif de cette étape est la transformation de 10 la variante de systèmes vérifiés en un tableau de système. Une réalisation à titre d'exemple est représentée sur la figure 14. Input SvER (variante de système valide) tf() (une prescription de transformation de 15 composants et d'attributs de la variante de systèmes en élément du tableau de système) Output : ST (tableau de système) a. ST = tf(S) 20 Bien entendu, l'invention n'est pas limitée aux exemples de réalisations ci-dessus décrits et représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans pour autant sortir 25 du cadre de l'invention. 2905491 Références [1] Razvan Racu, Kai Richter, Rolf Ernest. Calculating Task Output Event Models to Reduce 5 Distributed System Cost. In GI/ITG/GMM Workshop Methoden und Beschreibunssprachen zur Modellierung und Verifikation von Schaltungen uns Systemen, pages 1-10. Kaiserslautern, Germany, February 2004. 10 [2] R. Henia, A. Hamman, M. Jersak, R. Racu, K. richter, R. Ernest. System Level Performance Analysis the SymTA/S Approach. IEEE Proceedings Computers and Digital Techniques, 2005. 15 [3] S. Forster, M. Fischer, A. Windi, B. Baiser. Monjau. A n Specification Methodology for Embedded Systems based on the Pi-calculus Process Algebra. In Proceedings of the 14th International IEEE Workshop on Rapid System Prototyping (RSP), San Diego, USA, 2003. 24 REVENDICATIONS 1. Procédé automatique, basé sur modèle, pour l'intégration d'une architecture fonctionnelle de système avec une architecture physique de système pour former un système électronique, en particulier un système avionique, l'architecture fonctionnelle du système comprenant différents composants d'application et l'architecture physique de système comprenant différents composants de plate-forme, une affectation de composants d'application à des composants de plate-forme étant entreprise de façon telle que 1. l'affectation est complète II. le déroulement fonctionnel de l'architecture fonctionnelle de système est assuré III. les demandes non fonctionnelles envers le 15 système complet sont remplies, le procédé étant caractérisé par les étapes de procédé suivantes . - au cours d'une première étape, la spécification de l'architecture fonctionnelle du système ainsi que de 20 l'architecture physique de système est mise à disposition, architectures qui présentent les propriétés suivantes : 1. des composants de plate-forme aussi bien que des composants d'application constituent une hiérarchie, dans laquelle des sous composants représentent un 25 affinement structurel des composants pères correspondants, II. Au moyen d'une extension de comportement des composants de plate-forme aussi bien que des composants d'application, on peut ajouter à ceux-ci d'autres liaisons, fonctions et attributs, 2905491 26 III. Les composants de plate-forme présentent ce que l'on appelle des sous composants logiques de plate-forme comment emplacements pour des composants d'application ajoutés ultérieurement, 5 - au cours d'une deuxième étape, la quantité des sous composants logiques de plate-forme de l'architecture physique de système est déterminée ; - au cours d'une troisième étape, la quantité des composants d'application affectés à l'architecture 10 physique de système et déterminée, l'affectation d'un composant d'application à un composant de plate-forme étant autorisée, si 1. un composant d'application existe également en tant que sous composant logique de plate-forme du 15 composant de plate-forme, ou II. un composant d'application est dérivé d'un sous composant logique de plate-forme du composant de plate-forme grâce à une extension de comportement ; - au cours d'une quatrième étape, est déterminée 20 la quantité de Clusters de composants d'application, un Cluster comprenant des composants d'application qui doivent être affectés au même composant de plate-forme ; au cours d'une cinquième étape, une première variante de système est produite grâce à l'affectation 25 complète des Clusters de composants d'application aux composants de plate-forme ; - au cours d'une sixième étape, on vérifie que la variante de système produite remplit les exigences fonctionnelles et non fonctionnelles prescrites ; au cas 30 où le contrôle s'avère négatif, sont produites de nouvelles variantes de système par modification de l'affectation des Clusters aux composants de plate-forme, 2905491 27 et ce, jusqu'à la présence d'une variante de système autorisée, au cours d'une septième étape, la variante autorisée de système est transformée en un tableau de 5 système pour le système électronique. 2. Procédé selon la revendication 1, caractérisé en ce que dans la troisième étape, au cas où l'affectation d'un composant d'application à un composant 10 de plate-forme n'est pas autorisée, on vérifie que la liaison d'un composant père du composant d'application est autorisée.