Brevet FR2922665A1 — publié le 20090424

Procédé d'aide à la conception d'une architecture système La présente invention concerne un procédé d'aide à la conception d'une architecture système. La conception d'architectures système concerne notamment le domaine de l'ingénierie système. Les systèmes auxquels s'applique la présente invention peuvent être des systèmes matériels, logiciels ou des systèmes combinant logiciel et matériel. La présente invention peut être mise en oeuvre dans le cadre de la réalisation d'un système de navigation et conduite du vol d'un aéronef par exemple. La construction d'une architecture d'un système, qu'il soit matériel, logiciel ou les deux, a notamment pour objectif de décomposer le système en un certain nombre de composants qui peuvent être des sous-systèmes, des composants logiciels, des calculateurs, des cartes de traitement électroniques. Les composants du système supportent les mêmes contraintes que le système. Les contraintes applicables au système peuvent être : • fonctionnelles comme : des fonctions réalisées par le système, des conditions de mise en oeuvre du système ; • non-fonctionnelles comme : des performances attendues, une disponibilité et une sûreté de fonctionnement, une intégrité du système qui correspond à une confidentialité à assurer et à une résistance à des agressions extérieures, une maintenabilité, mais aussi une facilité d'intégration, de réutilisation, d'évolution. La maintenabilité d'un système est notamment la facilité avec laquelle il est possible de réaliser un entretien, préventif ou curatif, du système, de manière à garantir sa fiabilité. La construction d'une architecture la plus adaptée pour satisfaire une des contraintes du système est très souvent inadaptée à la satisfaction des autres contraintes du système. Par exemple, des précautions dans la conception d'une architecture, afin de favoriser une intégrité et une disponibilité du système, induisent souvent une dégradation des performances du système. La modification de l'architecture conçue par rapport à une première contrainte pour prendre en compte une deuxième contrainte est d'une part coûteuse et conduit d'autre part à une architecture inadaptée aux autres contraintes. II peut notamment être impossible d'adapter à la deuxième contrainte une architecture conçue par rapport à la première contrainte sans dégrader la prise en compte de la première contrainte. La première et la deuxième contrainte peuvent alors apparaître comme contradictoires. Une démarche couramment utilisée consiste à procéder à une analyse fonctionnelle d'un besoin technique, puis à construire une architecture fonctionnelle d'un système répondant au besoin technique. L'architecture fonctionnelle est une décomposition en fonctions permettant de satisfaire le besoin technique. Les fonctions sont regroupées selon des critères non formalisés comme un critère de proximité fonctionnelle. L'architecture fonctionnelle construite est ensuite soumise à l'avis de différents experts des contraintes non-fonctionnelles. Chaque expert analyse donc, indépendamment des autres experts, l'architecture fonctionnelle du point de vue d'une contrainte non-fonctionnelle : par exemple en effectuant une analyse du point de vue de la sécurité. Chaque expert émet donc un point de vue non-fonctionnel unique propre à sa spécialité : performances attendues, disponibilité et sûreté de fonctionnement, intégrité, sécurité, maintenabilité. Par exemple, une analyse utilisant une construction d'arbres de défaillance peut être menée. Une construction d'arbres de défaillance peut intervenir une fois une architecture physique définie pour mettre en oeuvre l'architecture fonctionnelle. Une architecture physique permet par exemple de définir des processeurs, des moyens de communication. La construction d'arbre de défaillances permet de vérifier que la conception retenue pour l'architecture physique préserve des contraintes de sécurité attendues. Une inadéquation entre l'architecture physique et les contraintes de sécurité entraîne la nécessité de concevoir une nouvelle architecture physique et/ou fonctionnelle satisfaisant les contraintes de sécurité. La nouvelle architecture peut amener à son tour des problèmes de performances par exemple. Pour satisfaire toutes les contraintes requises pour le système, il est donc nécessaire de faire évoluer l'architecture en fonction de chaque point de vue de chaque expert. Ceci implique dans un procédé de construction de l'architecture du système de nombreuses itérations, voir de nombreux aller-retour entre les différents experts afin d'obtenir une architecture qui ne satisfait finalement que très partiellement toutes les contraintes attendues. Un tel procédé de construction d'une architecture s'avère donc très coûteux et lourd à mettre en oeuvre pour des résultats obtenus peu satisfaisants. Une autre solution de construction d'une architecture système peut être d'utiliser une simulation fonctionnelle. Une fois l'architecture définie, les contraintes non-fonctionnelles devant être satisfaites par le système sont évaluées grâce à une mise en oeuvre d'un modèle de simulation. A cette fin, le modèle de simulation reproduit simultanément une application de l'architecture et son implémentation sur une plate-forme d'exécution. Le modèle de simulation utilisé doit être très détaillé, il est de ce fait très coûteux à développer. De plus, le modèle de simulation nécessitant un niveau de détail important dans la description de l'architecture, il ne peut être mis en oeuvre que tardivement dans un processus de construction de l'architecture. A ce moment, il est alors très coûteux et complexe d'apporter à l'architecture les modifications nécessaires à la prise en compte des contraintes qui serait peu ou pas respectées par l'architecture proposée. Une telle solution n'est pas viable économiquement lorsqu'elle est mise en oeuvre pour un système complexe. Un but de l'invention est notamment de fournir une aide à la définition d'une architecture d'un système matériel et/ou logiciel, en prenant en compte des contraintes susceptibles de conditionner la définition de l'architecture, et en fournissant une analyse de chaque choix d'architecture au regard de chacune de ces contraintes. A cet effet, l'invention a pour objet un procédé de conception d'une architecture d'un système comporte au moins les étapes suivantes : • analyse fonctionnelle et non-fonctionnelle d'un besoin technique auquel répond le système ; • modélisation de points de vue d'analyse de l'architecture du système à partir de l'analyse fonctionnelle et non-fonctionnelle ; • définition d'au moins une règle d'analyse de l'architecture du système pour chaque point de vue d'analyse ; • construction d'un modèle de l'architecture du système à partir de l'analyse fonctionnelle et non fonctionnelle ; • analyse du modèle de l'architecture du système en évaluant les règles d'analyse sur le modèle de l'architecture du système. La construction du modèle de l'architecture système peut comporter une ou plusieurs étapes de modification de l'architecture système. Chaque étape de modification étant notamment suivie d'une étape d'analyse de l'architecture du système. L'analyse fonctionnelle et non-fonctionnelle, la modélisation des points de vue d'analyse et la construction du modèle d'architecture peuvent être formalisés selon un méta-modèle commun et peuvent être reliés au sein d'un modèle commun. L'analyse fonctionnelle peut comporter une décomposition en fonctions d'une macro-fonction répondant au besoin technique. L'analyse fonctionnelle peut comporte une détermination de 20 chaînes fonctionnelles comportant un ensemble de fonctions activées successivement. L'analyse non fonctionnelle est par exemple une détermination d'un ensemble de contraintes applicables au système, chaque point de vue d'analyse étant associé à un ensemble de contraintes. 25 Les contraintes non-fonctionnelles sont notamment formalisées sur les chaînes fonctionnelles. La construction d'un modèle de l'architecture du système comporte notamment un regroupement des fonctions en composants, l'ensemble des composants faisant parti du modèle de l'architecture du 30 système. La construction d'un modèle de l'architecture du système comporte notamment une allocation des composants à des processeurs. Le procédé selon l'invention est notamment adapté à une conception d'une architecture d'un système matériel. Un système informatique de conception d'une architecture d'un système permet une mise en oeuvre du procédé de conception d'une architecture d'un système selon l'invention. L'invention a notamment pour principal avantage d'offrir une analyse immédiate des impacts de chaque choix d'architecture sur l'ensemble des contraintes du système. Ceci permet avantageusement de faire émerger rapidement un compromis entre différentes architectures 10 possibles. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, donnée à titre illustratif et non limitatif, et faite 15 en regard des dessins annexés qui représentent : • la figure 1 : un procédé de construction d'une architecture système selon l'art antérieur ; • la figure 2 : un principe général du procédé de construction d'une architecture système selon l'invention ; 20 • la figure 3a : un premier résultat fonctionnel d'une première étape du procédé selon l'invention ; • la figure 3b : un deuxième résultat fonctionnel de la première étape du procédé selon l'invention ; • la figure 3c : un troisième résultat fonctionnel de la première 25 étape du procédé selon l'invention ; • la figure 3d : un résultat non-fonctionnel de la première étape du procédé selon l'invention ; • la figure 4a : une formalisation d'un point de vue performance ; • la figure 4b : une formalisation d'un point de vue défaillance ; 30 • la figure 4c : une formalisation d'un point de vue criticité ; • la figure 4d : une formalisation d'un point de vue latence ; • la figure 5 : différentes phases d'une conception d'une architecture système utilisant le procédé selon l'invention ; • la figure 6a : un exemple d'un graphe de collaboration ; • la figure 6b : un exemple d'une modélisation de chaînes fonctionnelles ; • la figure 6c : un exemple de modélisation conjointe d'un point de vue défaillance et d'un point de vue criticité ; • la figure 6d : un exemple d'architecture système ; • la figure 6e : un exemple d'allocation de fonctions à des ressources physiques ; • la figure 6f : un exemple d'analyse de l'architecture suivant une règle de criticité ; ~o • la figure 6g : un exemple d'analyse de l'architecture suivant une règle de performance ; • la figure 6h : des chaînes fonctionnelles reliant des fonctions allouées à trois processeurs ; • la figure 6i : des chaînes fonctionnelles reliant des fonctions 15 allouées à quatre processeurs ; • la figure 6j : un exemple d'histogramme de satisfaction des règles d'analyse. 20 La figure 1 représente un procédé de conception 1 d'une architecture système selon l'art antérieur. Une première étape 4, 3 d'un procédé de conception 1 d'une architecture d'un système est une étape d'analyse d'un besoin technique. Cette analyse du besoin technique peut être décomposée en deux analyses : 25 • une première analyse 2, dite analyse fonctionnelle 2 permettant d'identifier des fonctions et les communications à mettre en oeuvre pour répondre aux besoins techniques ; • une deuxième analyse 3, dite analyse de contraintes non-fonctionnelles 3, permettant de déterminer des contraintes à appliquer au système 30 telles que : des performances attendues, des contraintes de disponibilité et de sûreté de fonctionnement du système, d'intégrité, de sécurité, de maintenabilité par exemple. Une deuxième étape 4 du procédé de conception 1 d'une architecture système est une étape de définition 4 d'une architecture 35 fonctionnelle du système. L'étape de définition de l'architecture fonctionnelle 4 du système utilise l'analyse fonctionnelle 2 pour définir des blocs fonctionnels regroupant une ou plusieurs fonctions identifiées. Une décomposition en blocs fonctionnels est un moyen pour représenter une architecture fonctionnelle du système. Une fois l'architecture fonctionnelle définie, celle-ci est analysée en parallèle sous plusieurs points de vue. Chaque point de vue correspond à une contrainte non-fonctionnelle identifiée lors de l'analyse de contraintes non-fonctionnelles 2. Par exemple une première analyse de l'architecture fonctionnelle peut être une analyse de performances 5 du système. L'analyse de performances 5 permet d'identifier des premières corrections à apporter 6 à l'architecture fonctionnelle afin de mieux prendre en compte les contraintes de performances. En parallèle, une analyse de sécurité 7 peut être menée sur l'architecture fonctionnelle. A l'issu de l'analyse de sécurité 7, il peut s'avérer nécessaire d'apporter des deuxièmes corrections sur l'architecture fonctionnelle pour améliorer la sécurité de celle-ci. Une fois les corrections pour performances 6 et les corrections pour sécurité 8 effectuées sur l'architecture, il est nécessaire d'effectuer une itération 9 afin de vérifier la compatibilité de l'architecture fonctionnelle après correction avec les contraintes non-fonctionnelles. Cette itération peut amener, par exemple, à mener une nouvelle analyse du point de vue de la sécurité 8 de l'architecture fonctionnelle. Cette nouvelle analyse de sécurité 8 peut également entraîner des corrections sur l'architecture pour satisfaire les contraintes de sécurité. Une nouvelle itération peut alors être nécessaire afin de vérifier la prise en compte des contraintes de performances 5 par l'architecture. Ces cycles itératifs peuvent ainsi être nombreux avant d'obtenir une architecture fonctionnelle qui satisfasse toutes les contraintes non-fonctionnelles identifiées. Il est parfois impossible de converger vers une solution architecturale acceptable, certaines contraintes apparaissant comme contradictoires. La figure 2 représente plusieurs étapes possibles d'un procédé de conception d'une architecture système 20 selon l'invention. Dans le mode de réalisation présenté, le système peut être un système de navigation et conduite du vol d'un aéronef mettant en oeuvre des fonctions avioniques mises à la disposition d'un équipage de l'aéronef. Le procédé selon l'invention peut cependant s'appliquer à d'autres types de système. Une première étape du procédé de conception d'une architecture système 20 selon l'invention est une étape d'analyse d'un besoin technique 23. L'étape d'analyse du besoin technique 23 peut être décomposée en deux sous-étapes : une première sous-étape d'analyse fonctionnelle 21 et une deuxième sous-étape d'analyse de contraintes non-fonctionnelles 22. L'analyse fonctionnelle 21 permet de déterminer une liste de fonctions nécessaires à la satisfaction du besoin technique par le système. La liste de fonction peut se représenter sous la forme d'une liste arborescente de fonctions, d'un graphe de collaboration entre les fonctions. Une liste arborescente de fonctions permet de définir des relations hiérarchiques entre les fonctions, un graphe de collaboration permet de définir des liens de collaboration entre les fonctions. L'analyse fonctionnelle 21 permet également de déterminer des chaînes fonctionnelles. Une chaîne fonctionnelle comporte un ensemble de fonctions activées successivement, d'après un graphe de collaboration donné, pour réaliser une capacité attendue du système. L'analyse de contraintes non-fonctionnelles 22 permet de déterminer un ensemble de contraintes à satisfaire par le système. Des contraintes non-fonctionnelles peuvent être par exemple : • une latence sur chaque chaîne fonctionnelle : un ensemble de fonctions doivent alors être traversées dans un temps imposé, entre un événement en entrée du système et un résultat produit en sortie du système ; • des performances liées à des ressources de traitement disponibles, comme une estimation d'une charge de calcul et de temps d'exécution associés à chaque fonction ; • un niveau de criticité de chaque fonction : chaque fonction peut être qualifiée selon un niveau de criticité comme critique, essentielle, non-critique par exemple ; • des conditions de propagation de défaillances dans un graphe de collaboration : une défaillance sur une fonction peut ou non affecter les fonctions avec lesquelles elle collabore, les fonctions affectées par une défaillance peuvent l'être plus ou moins gravement. Les résultats des analyses fonctionnelle et non-fonctionnelle peuvent être formalisés dans un modèle d'analyse fonctionnelle et non fonctionnelle. Dans le cadre de l'invention, un modèle est une représentation formalisée décrivant différents éléments élaborés au cours des différentes étapes du procédé de conception selon l'invention ainsi que les relations qui les unissent, selon un langage formel. Le langage formel utilisé est notamment appelé un méta-modèle. Le méta-modèle est alors commun à tous les modèles élaborés au cours du procédé de conception selon l'invention. Un modèle peut être défini en utilisant des outils informatiques. Les outils informatiques peuvent ensuite analyser le modèle afin de vérifier qu'il satisfait des propriétés attendues du système comme les contraintes non-fonctionnelle. Le modèle d'analyse fonctionnelle et non-fonctionnelle contient notamment pour l'analyse fonctionnelle : • les fonctions et les chaînes fonctionnelles déterminées ; • des liens d'une chaîne fonctionnelle vers les fonctions qui la compose ; • les relations de collaboration entre les fonctions ; et pour l'analyse non-fonctionnelle : des attributs définissant les contraintes non-fonctionnelles du type latence, criticité par exemple. Une deuxième étape 24 du procédé de conception d'une architecture système 20 selon l'invention est une étape de formalisation de différents points de vue 24 d'analyse de l'architecture système. Un point de vue exprime les impacts d'une contrainte non-fonctionnelle sur l'architecture système. La formalisation d'un point de vue est une modélisation du point de vue. Un point de vue peut se modéliser sur les résultats de l'analyse fonctionnelle 21. Par exemple, un premier point de vue sur les latences dans le système peut se modéliser en identifiant des chaînes fonctionnelles critiques sur un graphe de communication entre fonctions, et en leur attribuant une latence attendue. Un deuxième point de vue sur les performances 26 attendues pour le système peut se modéliser en : • attribuant une estimation d'une charge de calcul pour chaque fonction, en terme de pourcentage d'occupation d'un processeur ou d'une capacité mémoire ; • attribuant pour chaque communication une estimation en terme de complexité d'échange, de fréquence, de volume de données échangées par exemple ; • définissant une plate-forme de référence comportant des calculateurs et des moyens de communication physique ; • définissant des capacités de ressources utilisées par le système, en terme de capacité de calcul, d'utilisation mémoire, de bande passante par exemple. Un troisième point de vue sur la criticité peut s'exprimer en 15 attribuant un niveau de criticité à chaque fonction et à chaque chaîne fonctionnelle. Un quatrième point de vue sur la propagation de défaillances peut se modéliser en définissant des liens de propagation des défaillances entre les fonctions et des équations de propagation pour chaque défaillance dans 20 le système. Un cinquième point de vue peut être un point de vue sécurité 27. D'autres points de vue peuvent être définis en rapport avec d'autres contraintes sur le système. Une fois la deuxième étape du procédé selon l'invention terminée, 25 les points de vue d'analyse 25, 26, 27 sont définis et modélisés. Les points de vue peuvent donc être représentés par un modèle de points de vue comportant des attributs des chaînes fonctionnelles, de type criticité, latence. Une troisième étape 28 est une étape de définition de 30 l'architecture du système 28. L'étape de définition de l'architecture du système 28 fait notamment apparaître un regroupement des fonctions en composants faisant partie de l'architecture du système. La définition de l'architecture système permet notamment l'élaboration d'un modèle d'architecture système comprenant les composants et pour chaque composant les fonctions qui les composent et des interfaces de communication supportant les collaborations entre fonctions. L'étape de définition de l'architecture système 28 comporte une étape d'unification 29 des modèles produits au cours des étapes précédentes 23, 24. L'objectif de cette étape d'unification 29 des modèles est de réunir et de relier les concepts définis précédemment, comme les points de vue, les fonctions et chaînes fonctionnelles, les composants en un ou plusieurs modèles unifiés. Les modèles unifiés permettent d'analyser les influences mutuelles des concepts précédemment définis sur l'architecture système. Un modèle unifié est décrit selon le méta-modèle. Un méta-modèle peut être défini comme un modèle d'un langage de modélisation, c'est à dire un ensemble de concepts manipulés par un utilisateur du langage de modélisation pour construire des modèles, et les liens unissant les modèles. La modélisation réalisée dans le cadre de l'invention repose par exemple sur les principes suivants : • l'ensemble des modèles unifiés décrits sont compatibles entre eux ; • chaque modèle unifié supporte un point de vue particulier tel que la performance 24, la sécurité 27, chaque point de vue étant applicable à l'architecture système ; • les modèles unifiés peuvent être reliés les uns aux autres et portent sur une même réalisation d'un système ; • chaque modèle unifié se réfère au méta-modèle commun et la réunion de chaque modèle unifié compose l'architecture système. Ainsi : • on peut relier les chaînes fonctionnelles aux fonctions et communications qu'elles traversent de manière simple ; • chaque fonction peut être allouée à un composant logiciel ou matériel ; • chaque composant peut être projeté sur un calculateur chargé de son 30 exécution ; • chaque communication peut être portée par un moyen de communication physique ; • un graphe de propagation de défaillances peut relier : les fonctions les unes aux autres, les calculateurs réalisant ces fonctions les uns aux 35 autres. D'autres relations entre modèles unifiés peuvent également être explicitées selon le type de système. L'étape de définition de l'architecture système 28 comporte également une étape de définition de règles d'analyse 210 de l'architecture système. Les règles d'analyse permettent, par la suite, d'effectuer une analyse de l'architecture système. Chaque règle d'analyse peut par exemple correspondre à une contrainte non-fonctionnelle et donc à un point de vue identifié préalablement. A titre d'exemple, les règles suivantes peuvent être définies : • latence d'une chaîne fonctionnelle : la somme des temps d'exécution des fonctions traversées par la chaîne fonctionnelle est inférieure à une valeur de latence définie ; • performances : la somme des charges des processeurs utilisés par chaque fonction allouée à un processeur est inférieure à 75% de la 15 capacité de calcul du processeur ; les performances peuvent également être définies en terme de volume de mémoire utilisée ou de bande passante ; • criticité des fonctions et des chaînes fonctionnelles : deux fonctions de criticité différente ne peuvent cohabiter sur une même chaîne 20 fonctionnelle ou sur un même composant ; • propagation de défaillances : une défaillance dans une fonction définie ne doit pas entraîner d'indisponibilité d'une chaîne fonctionnelle définie. L'étape de définition de l'architecture système 28 comporte 25 également une étape de construction d'une architecture du système 211. La construction d'une architecture du système 211 peut utiliser les fonctions identifiées au cours de l'analyse fonctionnelle 21. La construction d'une architecture système 211 permet de regrouper les fonctions dans des composants qui constituent alors l'architecture du système. 30 Le regroupement des fonctions dans des composants peut se faire selon des critères de proximité fonctionnelle ou selon des critères non-fonctionnels, comme les contraintes non fonctionnelles applicables au système. Par exemple, des fonctions ayant un même niveau de criticité peuvent être rassemblées au sein d'un même composant. Les composants peuvent être des sous-systèmes, des logiciels, des matériels. Les composants structurent et donc composent l'architecture du système. Les composants peuvent eux-même être décomposés en sous-composants suivant le niveau de granularité de l'architecture. Au cours de la définition de l'architecture système 28, les communications entre des fonctions peuvent être allouées à des ports de communication ou à des interfaces entre composants. Les communications peuvent également être allouées à des moyens de communication physique. Les fonctions et les composants peuvent être alloués à des ressources physiques comme des processeurs pendant l'étape de construction de l'architecture système 211. L'architecture système ainsi construite est un modèle formalisé d'après le méta-modèle commun aux modèles unifiés. Le modèle de l'architecture système ainsi que les modèles unifiés construits précédemment font partie d'un même modèle commun, chacun des modèles pouvant être relié aux autres modèles. L'étape de définition de l'architecture système 28 met également en oeuvre une analyse d'impact croisée 212 qui prend en compte les règles d'analyse 210, les modèles unifiés 29 et l'architecture construite 211. L'analyse d'impact croisée 212 peut être effectuée à chaque modification de l'architecture système, d'une règle d'analyse ou d'un modèle unifié. L'analyse d'impact croisée 212 permet de confronter une architecture à l'ensemble des points de vue définis, de manière simultanée, en se référant aux modèles unifiés et aux règles d'analyses définies. Ainsi, à chaque décision prise au cours de la définition de l'architecture système 28 les règles d'analyse 210 sont testées sur l'architecture afin de détecter une inadéquation éventuelle avec les contraintes à prendre en compte par le système. Par exemple, un regroupement de plusieurs fonctions dans un 30 composant ou l'allocation d'une fonction à un processeur donné peut entraîner une nouvelle analyse 212 de l'architecture système. Au cours de l'analyse d'impacts croisés, une vérification de l'ensemble des points de vue est réalisée à chaque décision élémentaire de conception. Les itérations effectuées sont donc très courtes et de faible ampleur, ceci est rendu possible par l'approche et les propriétés du modèle commun. La validité des choix architecturaux peut ainsi être évaluée de manière simultanée par rapport à l'ensemble des points de vue 25, 26, 27 couverts par les règles d'analyse 210. On peut également évaluer les conséquences d'une modification d'architecture pour satisfaire une règle, sur la satisfaction des autres règles définies. L'analyse de l'architecture système 212 permet non seulement d'évaluer le respect des contraintes par l'architecture mais aussi de localiser les causes éventuelles de non respect des contraintes. Par exemple, il est ainsi possible de déterminer quelle chaîne fonctionnelle excède une latence imposée ou quel calculateur est saturé et de combien. Ceci permet de réajuster en permanence la définition de l'architecture système 28 afin de converger rapidement vers une architecture représentant un bon compromis entre les contraintes non-fonctionnelles. Le procédé de conception d'une architecture système permet donc, dès la première phase de conception, de prendre en compte les contraintes non-fonctionnelles et d'ajuster l'architecture en fonction de ces dernières. La prise en compte des contraintes non-fonctionnelles au plus tôt permet de réduire les coûts de conception d'une telle architecture et d'accélérer le processus de conception de cette architecture. Le procédé de conception d'une architecture système selon l'invention permet également de prouver dès les premières phases de conception que les contraintes non-fonctionnelles sont bien prises en compte. La conception selon l'invention permet donc de détecter au plus tôt des erreurs de prise en compte des exigences non-fonctionnelles et d'y remédier rapidement. Les figures 3a, 3b, 3c et 3d représentent des exemples de 30 résultats fonctionnels et non-fonctionnels de la première étape d'analyse d'un besoin technique 23. Un premier résultat fonctionnel, représenté sur la figure 3a peut être une décomposition fonctionnelle hiérarchisée d'une ou plusieurs fonctions à mettre en oeuvre pour répondre au besoin technique. Une 35 première fonction 30 peut être une macro-fonction représentant une fonction principale à remplir par le système. La macro-fonction 30 peut être décomposée en deux fonctions 31, 32 qui elles-mêmes peuvent être décomposées en deux sous-fonctions 33, 34, 35, 36. Une première sous-fonction 36 peut, elle aussi, être décomposée en deux autres sous-fonctions 37, 38. II est à noter qu'une macro-fonction et une sous-fonction sont des fonctions, les termes macro-fonction et sous-fonction introduisant uniquement une notion de hiérarchie entre les fonctions. Un deuxième résultat fonctionnel peut être un graphe de collaboration entre les différentes fonctions identifiées représentées sur la figure 3b. Par exemple une deuxième fonction 300 peut fournir des données nécessaires à une troisième fonction 301 et à une quatrième fonction 302. La quatrième fonction 302 peut également dépendre de la troisième fonction 301. Une cinquième fonction 303 peut dépendre de la troisième fonction 301 et fournir des informations à une sixième fonction 304. La sixième fonction 304 peut dépendre également d'une septième fonction 305, elle-même dépendant de la quatrième fonction 302. Une huitième fonction 306 peut également dépendre de la quatrième fonction 302. Un graphe de collaboration permet ainsi de définir des communications entre les différentes fonctions. Un troisième résultat fonctionnel peut être une ou plusieurs chaînes fonctionnelles 307, 308 représentées sur la figure 3c. Les chaînes fonctionnelles peuvent être représentées sur un graphe de collaboration comme celui représenté sur la figure 3b. Une première chaîne fonctionnelle 307 active par exemple les fonctions suivantes dans l'ordre de citation : la deuxième fonction 300, la troisième fonction 301, la quatrième fonction 302, la septième fonction 305, la sixième fonction 304. Une deuxième chaîne fonctionnelle 308 peut activer les fonctions suivantes dans l'ordre de citation : la deuxième fonction 300, la quatrième fonction 302, la huitième fonction 306. Chaque chaîne fonctionnelle apporte un résultat attendu au niveau du système. L'analyse des besoins techniques 23 conduit également à identifier des contraintes non-fonctionnelles que le système prend en compte. Les contraintes non-fonctionnelles peuvent se représenter sous la forme d'une liste 307 de contraintes rédigées par exemple en texte libre comme sur la figure 3d. Les figures 4a, 4b, 4c et 4d représentent des formalisations 24 possibles de différents points de vue. Par exemple, la figure 4a représente un point de vue de performances projeté sur la décomposition fonctionnelle représentée sur la figure 3a. Par exemple, une neuvième fonction 31 ne doit pas utiliser, lors de son exécution par un processeur, plus de 40% de la charge du processeur. La deuxième sous-fonction 35 ne doit pas utiliser plus de 30% de charge processeur lors de son exécution. Dans une autre représentation des 1 o performances, la troisième sous-fonction 38 doit effectuer ses traitements en 20ms, ms signifiant milli-secondes, alors que la quatrième sous-fonction 34 doit effectuer ses traitements en 30ms. La figure 4b donne un exemple de représentation d'un point de vue défaillance. La figure 4b représente, à cet effet, une propagation de 15 défaillances sur un graphe de collaboration fonctionnel tel que représenté sur la figure 3b. Par exemple une défaillance intervenant dans la troisième fonction 301 peut entraîner des défaillances dans la quatrième fonction 302 puis dans la huitième fonction 306. Une défaillance dans la troisième fonction 301 peut engendrer également une défaillance dans la cinquième fonction 20 303 puis dans la sixième fonction 304. On peut ainsi tracer sur le graphe de collaboration un premier chemin 40 et un deuxième chemin 41 de propagation de défaillances entre les fonctions. La figure 4c donne un exemple de représentation sur un graphe de collaboration, tel que représenté sur la figure 3b, d'un point de vue 25 criticité. Par exemple si l'on définit deux niveaux de criticité : critique et non-critique, les fonctions suivantes peuvent être critiques : la deuxième fonction 300, la troisième fonction 301, la cinquième fonction 303, la septième fonction 305 et la huitième fonction 306. La figure 4d représente sur un graphe de collaboration comportant 30 des chaînes fonctionnelles, tel que représenté sur la figure 3c, un point de vue latence. Par exemple pour la deuxième chaîne fonctionnelle 308, le temps de latence maximal admissible doit être de 150ms. La figure 5 représente différentes phases itératives 53, 54, 55 35 d'une conception d'une architecture système en utilisant le procédé selon l'invention. L'analyse de l'architecture 212 est représentée par des doubles flèches 50, 51, 52, chaque double flèche 50, 51, 52 représentant un point de vue et une règle d'analyse associée à ce point de vue. Une première règle est par exemple une règle de latence 50, une deuxième règle peut être une règle de criticité 51 et une troisième règle est une règle de propagation de défaillances 52 par exemple. Dans une première phase de conception, on peut déterminer les différentes fonctions du système. Les différentes fonctions 300, 301, 302, 303, 304, 305, 306 sont représentées par un graphe de collaboration 53, tel que représenté sur la figure 3b. A cette étape, les contraintes fonctionnelles et non fonctionnelles à respecter par l'architecture sont exprimées. Une fois les fonctions définies, elles peuvent être réalisées par un ensemble de composants 54, par exemple des composants logiciels. Par exemple, les fonctions suivantes peuvent être allouées à : • un premier composant 56 : la deuxième fonction 300, la quatrième fonction 302 ; • un deuxième composant 57 : la huitième fonction 306 ; • un troisième composant 58 : la septième fonction 305, la sixième fonction 304. Les composants 56, 57, 58 peuvent être reliés par l'intermédiaire de leurs interfaces 561, 562, 571, 572, 581, 582. Par exemple : une première interface 561 du premier composant 56 est reliée à une deuxième interface 571 du deuxième composant 57, une troisième interface 562 du premier composant 56 est reliée avec une quatrième interface 581 du troisième composant 58, et une cinquième interface 572 du deuxième composant 57 est reliée avec une sixième interface 582 du troisième composant 58. Les composants 56, 57, 58 peuvent ensuite être projetés sur deux processeurs physiques 55 par exemple. Le premier composant 56 et le deuxième composant 57 peuvent être projetés sur un premier processeur 551, et le troisième composant 58 peut être projeté sur un deuxième processeur 552. L'analyse de l'architecture selon la première règle de latence 50 et selon la troisième règle de propagation de défaillance 52 utilise les informations de l'analyse fonctionnelle et leur allocation à des composants, ainsi que la projection des composants sur les calculateurs physiques. L'analyse de l'architecture selon la deuxième règle de criticité 51 utilise notamment les informations de l'analyse fonctionnelle et leur allocation à des composants. Ainsi le procédé de conception permet une analyse de l'architecture système à différents degrés de maturité de cette dernière. Ceci permet de valider immédiatement les choix architecturaux, sans devoir attendre un certain degré de maturité de conception de l'architecture. Cette validation des choix architecturaux permet un gain de temps et de coût de conception. En effet une validation tardive de choix architecturaux engendre des coûts élevés pour rendre l'architecture conforme à un attendu. Les figures 6a, 6b, 6c, 6d, 6e, 6f, 6g, 6h, 6i, 6j représentent un exemple de mise en oeuvre du procédé de conception d'une architecture système selon l'invention appliquée à un système avionique de navigation embarqué. Le système de navigation embarqué peut être réalisé par un calculateur embarqué. La mise en oeuvre du procédé de conception d'architecture système selon l'invention peut être effectuée à l'aide d'un outil logiciel permettant de construire notamment les différents modèles associés aux contraintes non-fonctionnelles ainsi qu'un modèle d'architecture. L'outil logiciel peut ainsi prendre en compte les différentes règles d'analyse afin d'effectuer de manière automatique une analyse d'une architecture donnée. La figure 6a représente une première étape de l'exemple d'utilisation du procédé selon l'invention. La première étape d'analyse 23 permet de déterminer les fonctions avioniques nécessaires à la réalisation du système avionique. Les fonctions avioniques sont représentées sur la figure 6a. Chaque fonction avionique est représentée sur un graphe de collaboration. Chaque fonction avionique est nommée suivant une expression anglo-saxonne définie ci-après : • flight management 60, signifiant gestion du vol ; • navigation situation 61, signifiant détermination d'une position et d'une route d'un aéronef, d'un plan de vol par exemple ; • primary flight reference elaboration 62, signifiant élaboration de paramètres de vol primaires comme une attitude de l'aéronef, une altitude, une vitesse air ; • intertial units management 63, signifiant gestion des unités inertielles pour un positionnement de l'aéronef ; • air data collection 64, signifiant gestion de la collecte de données de type barométrique comme une vitesse, une altitude, une glissade par exemple ; • taxi management 65, signifiant gestion du roulage au sol ; • position reference elaboration 66, signifiant élaboration d'une position de référence ; • position reporting 67, signifiant compte rendu de position ; • ACAS interrogator 68, signifiant interrogateur de système anticollision ; • weather radar 69, signifiant radar météo ; • environment reference data 610, signifiant gestion des données d'environnement de référence comme des bases de données de terrain, d'aéroports, aides de navigation ; • integrated surveillance 611, signifiant surveillance intégrée de l'aéronef et du trafic proche ; • crew information management 612, signifiant gestion des informations équipage. Ces fonctions avioniques sont données à titre d'exemple et représentent partiellement le système de navigation. Le graphe de collaboration peut être construit à l'aide de l'outil logiciel. L'outil peut, en effet, permettre de définir simplement les différentes fonctions avioniques et d'établir les liens de dépendances entre les fonctions avioniques. Des contraintes déterminées à partir d'un besoin technique permettent d'identifier des points de vue d'évaluation de l'architecture du système avionique comme un point de vue fonctionnel, un point de vue chaînes fonctionnelles, un point de vue interface, un point de vue d'utilisation des ressources de calcul, un point de vue sécurité, un point de vue de propagation de défaillances. Chaque point de vue peut être défini par une représentation s'appuyant sur les informations fonctionnelles déjà élaborées. La figure 6b représente un exemple d'une modélisation de chaînes fonctionnelles à l'aide des fonctions avioniques préalablement définies. Une chaîne fonctionnelle correspond à un enchaînement de fonctions pour traiter un cas opérationnel donné. Par exemple une chaîne de fonctionnelle du système avionique passe par les fonctions suivantes : air data collection 64, primary flight reference elaboration 62, integrated surveillance 611, flight alert management 614 signifiant gestion d'alertes de VOI. La figure 6c représente un exemple d'une modélisation conjointe d'un point de vue de propagation de défaillances et un point de vue criticité. Le point de vue criticité peut se représenter par un panneau danger sur les fonctions de niveau critique. Sur la figure 6c, les fonctions critiques sont par exemple les fonctions suivantes : flight management 60, navigation situation 61, primary flight reference elaboration 62, inertial units management 63, air data collection 64, position reference elaboration 66. La propagation des défaillances peut se représenter en reliant les fonctions dans lesquelles se propagent les défaillances par des flèches. Une défaillance dans la fonction air data collection 64 entraîne par exemple une défaillance dans la fonction primary flight reference elaboration 62. Une défaillance dans la fonction primary flight reference elaboration 62 entraîne l'apparition d'une défaillance dans les fonctions suivantes : navigation situation 61, position reference elaboration 66, integrated surveillance 611. Une défaillance dans la fonction position reference elaboration 66 peut alors entraîner une défaillance dans la fonction position reporting 67. La figure 6d représente une architecture candidate selon un point de vue de cohérence fonctionnelle. Les fonctions sont ainsi regroupées en plusieurs composants 620, 621, 622, 623, 624, 625, 626, 627 selon la nature des traitements qu'elles effectuent. Par exemple huit composants 620, 621, 622, 623, 624, 625, 626, 627 peuvent être définis regroupant chacun une ou plusieurs fonctions : • un premier composant de navigation 620 regroupe les fonctions : flight management 60, navigation situation 61, taxi management 65 ; • un deuxième composant nommé primary flight reference 621, signifiant référence de vol primaire, regroupe les fonctions : primary flight reference elaboration 62, intertial units management 63, air data collection 64 ; • un troisième composant nommé localization 622, signifiant 35 localisation, comporte la fonction position reference elaboration 66 ; • un quatrième composant nommé environment 623, signifiant environnement, comporte la fonction environment reference data 610 • un cinquième composant nommé crew information 624, signifiant 5 information équipage, comporte une fonction nommée crew information 612 ; • un sixième composant nommé situation awareness & surveillance 625, signifiant alerte et surveillance de la situation, comporte les fonctions : position reporting 67, ACAS interrogator 68, weather radar 10 69, integrated surveillance 611 ; • un septième composant nommé cockpit & flight 626, signifiant cabine de pilotage et vol, comporte les fonctions suivantes : cockpit management 613, signifiant gestion de la cabine de pilotage, flight alert management 614, engines & A/C surveillance 615, signifiant 15 surveillance des moteurs et de l'aéronef ; • un huitième composant nommé communications 627 comporte les fonctions suivantes : voice communication 616, signifiant communications vocales, data communication 617, signifiant liaisons de données. 20 Les composants peuvent éventuellement être décomposés en sous-composants. La figure 6e représente un exemple d'allocation de fonctions avioniques à des ressources physiques comme des processeurs. Par exemple, sur la figure 6e, sont représentés trois processeurs 630, 632, 631 : 25 • un premier processeur 630 nommé general purpose processeur 630, signifiant processeur à usage général, traite les fonctions suivantes : taxi management 65, flight management 60, position reporting 67, environment reference data 610, integrated surveillance 611, navigation situation 61 ; 30 • un deuxième processeur 631 nommé sensor & comms processeur 631, signifiant processeur de communication et de capteurs, traite les fonctions suivantes : primary flight reference elaboration 62, inertial units management 63, air data collection 64, position reference elaboration 66, ACAS interrogator 68, weather radar 69, voice 35 communication 616, data communication 617 ; • un troisième processeur 632 nommé crew interaction processeur 632 signifiant processeur d'interaction avec l'équipage traite les fonctions suivantes : crew information 612, cockpit management 613, flight alert management 614, engines & A/C surveillance 615, Les communications entre les différentes fonctions avioniques peuvent être allouées à des ports de communications ou des interfaces des composants ainsi qu'à des moyens de communication physiques 633, 634 entre processeurs par exemple. La figure 6f représente un exemple de vérification d'une règle de criticité des fonctions avioniques. La règle de criticité vérifiée peut être par exemple : deux fonctions de criticité différentes ne peuvent cohabiter dans un même composant. Cette règle de criticité n'est, par exemple, pas respectée par le composant navigation 620. Les fonctions navigation situation 61 et flight management 60 faisant partie du composant navigation 620 sont critiques alors que la fonction taxi management 65 faisant également partie du composant navigation 620 n'est pas critique. Le composant navigation 620 ne respecte donc pas la règle de criticité. La figure 6g représente un exemple de vérification d'une règle de performance lors d'une allocation physique des fonctions à des processeurs. Par exemple, pour chaque fonction on peut représenter un premier rectangle 640 dont la hauteur indique le pourcentage d'occupation du processeur par exemple : le processeur general purpose processor 630, lors du traitement de la fonction taxi management 65, occupe le processeur à plus de 50%. Un deuxième rectangle 641 peut représenter un pourcentage de mémoire nécessaire au traitement de la fonction. Par exemple la fonction taxi management 65 utilise à peu près 50% de la mémoire. Ainsi pour chaque fonction on peut représenter le taux d'occupation du processeur et le pourcentage de mémoire utilisé. Si la règle de performance est : les fonctions allouées à un processeur ne doivent pas exiger plus de ressource de calcul que n'en dispose le calculateur par exemple, les processeurs general purpose processor 630 et sensors & comms processor 631 transgressent la règle de performances. La répartition des fonctions allouées aux processeurs doit alors être revue afin de satisfaire la règle de performance énoncée. On peut alors ajouter un processeur représenté sur la figure 6i : un spare processeur 650, signifiant processeur libre. On modifie ensuite l'allocation des fonctions aux processeurs. Par exemple, les fonctions position reporting 67, environment reference 610, navigation situation 61, précédemment allouées au processeur general purpose processor 630, sont désormais allouées au spare processor 650. Une vérification immédiate de la règle de performances précédente montre alors qu'elle est à présent respectée. La figure 6h représente des chaînes fonctionnelles 660, 661, 662, 663 associées aux fonctions avioniques allouées sur trois processeurs 630, 631, 632. La figure 6i représente également des chaînes fonctionnelles 651, 652, 653, 654, 655 associées aux même fonctions avioniques allouées sur quatre processeurs 630, 631, 632, 650. Les chaînes fonctionnelles se trouvent dégradées par le passage à quatre processeurs : trop de processeurs sont traversés par les chaînes fonctionnelles. Il s'agit donc de trouver une architecture qui soit un compromis satisfaisant entre des chaînes fonctionnelles dégradées et des processeurs trop chargés. Le procédé de conception selon l'invention permet donc avantageusement d'évaluer le respect des contraintes non-fonctionnelles par une architecture mais aussi de localiser les transgressions aux contraintes : par exemple il est facile d'identifier quelle chaîne fonctionnelle excède une latence imposée, quel processeur est saturé et de combien en pourcentage d'occupation du processeur par exemple. Ceci permet de réajuster en continu l'architecture afin de converger rapidement vers le meilleur compromis atteignable. La figure 6j représente un exemple d'histogramme de satisfaction des règles d'analyses pouvant être produit par l'outil logiciel. Une barre d'histogramme peut par exemple symboliser un pourcentage de satisfaction d'une règle donnée par une architecture candidate. Par exemple : • une premiére barre 660 peut représenter la satisfaction d'une règle concernant le nombre d'interfaces ; • une deuxième barre 661 peut représenter la satisfaction d'une règle de complexité d'une chaîne fonctionnelle ; • une troisième barre 662 peut représenter la satisfaction d'une règle de tolérance à une panne ; • un quatrième barre 663 peut représenter la satisfaction d'une règle de sécurité ; • un cinquième barre 664 peut représenter la satisfaction d'une règle d'occupation des processeurs ; • un sixième barre 665 peut représenter la satisfaction d'une règle d'utilisation de la mémoire ; • un septième barre 666 peut représenter la satisfaction d'une règle concernant les communications. On peut par exemple comparer deux histogrammes réalisés à partir d'une analyse de deux architectures différentes afin de juger laquelle représente un meilleur compromis entre les différentes règles d'analyse. Les histogrammes permettent aussi un bon niveau de synthèse des qualités d'une architecture candidate et renseignent immédiatement sur les effets secondaires d'un choix d'architecture sur les différents points de vue. Le procédé de conception d'une architecture système selon l'invention permet de faciliter une optimisation d'une architecture système en prenant en compte de multiples contraintes. Le procédé selon l'invention permet avantageusement de faire émerger un compromis acceptable entre les contraintes. L'invention est une aide à la définition d'une architecture système de taille importante, permettant ainsi une gestion simplifiée de la complexité de l'architecture afin de permettre à un architecte système d'appréhender uniquement les problèmes généraux de choix architecturaux. La mise en oeuvre du procédé de conception selon l'invention par un outil logiciel permet avantageusement de capitaliser des critères de choix d'architecture et ainsi de justifier de l'architecture retenue. Les différentes étapes de la démarche de conception peuvent également être capitalisées afin d'être réutilisées dans le cadre d'une nouvelle conception d'architecture par exemple. Ainsi, peuvent être capitalisés facilement : • des points de vue formalisés ; • des règles d'analyse par point de vue et des critères de confrontation de point de vue, par exemple définir un critère prépondérant par rapport à un autre critère si un compromis entre deux critères doit être effectué , • des éléments de description architecturale réutilisables aussi appelés motifs architecturaux. Le procédé selon l'invention permet d'offrir une vision unifiée et pédagogique d'une architecture système. L'architecture système peut ainsi être considérée selon un point de vue particulier ou selon de multiples points de vue afin d'évaluer la contribution de l'ensemble des points de vue à la réalisation de l'architecture. Le procédé selon l'invention peut être considéré 1 o comme un tableau de bord d'un architecte système grâce auquel il peut évaluer l'impact de chacune des décisions de modification d'architecture. Le procédé selon l'invention peut avantageusement être mis en oeuvre dans des domaines techniques diverses dans lesquels il est nécessaire de concevoir une architecture système sous contraintes. 15 REVENDICATIONS 1. Procédé de conception (20) d'une architecture d'un système apte à être réalisé par un ou plusieurs processeurs, caractérisé en ce qu'il comporte au 5 moins les étapes suivantes : • analyse fonctionnelle et non-fonctionnelle (23) d'un besoin technique auquel répond le système ; • modélisation de points de vue d'analyse (24) de l'architecture du système à partir de l'analyse fonctionnelle et non-fonctionnelle ; 10 • définition d'au moins une règle d'analyse (210) de l'architecture du système pour chaque point de vue d'analyse ; • construction (211) d'un modèle de l'architecture du système à partir de l'analyse fonctionnelle et non fonctionnelle (23) ; • analyse du modèle (212) de l'architecture du système en évaluant les 15 règles d'analyse sur le modèle de l'architecture du système. 2. Procédé selon la revendication précédente, caractérisé en ce que la construction du modèle de l'architecture système comporte une ou plusieurs étapes de modification de l'architecture système, chaque étape de 20 modification étant suivie d'une étape d'analyse de l'architecture du système. 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'analyse fonctionnelle et non-fonctionnelle, la modélisation des points de vue d'analyse et la construction du modèle 25 d'architecture sont formalisés selon un méta-modèle commun et sont reliés au sein d'un modèle commun. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'analyse fonctionnelle comporte une décomposition en 30 fonctions d'une macro-fonction répondant au besoin technique. 5. Procédé selon la revendication précédente, caractérisé en ce que l'analyse fonctionnelle comporte une détermination de chaînes fonctionnelles comportant un ensemble de fonctions activées successivement. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'analyse non fonctionnelle est une détermination d'un ensemble de contraintes applicables au système, chaque point de vue d'analyse étant associé à un ensemble de contraintes. 7. Procédé selon les revendications 5 et 6, caractérisé en ce que les contraintes non-fonctionnelles sont formalisées sur les chaînes fonctionnelles. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la construction d'un modèle de l'architecture du système comporte un regroupement des fonctions en composants, l'ensemble des composants faisant partie du modèle de l'architecture du système. 9. Procédé selon la revendication précédente, caractérisé en ce que la construction d'un modèle de l'architecture du système comporte une allocation des composants à des processeurs. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est adapté à une conception d'une architecture d'un système matériel. 25 11. Système informatique de conception d'une architecture d'un système caractérisé en ce qu'il permet une mise en oeuvre du procédé de conception d'une architecture d'un système selon l'une quelconque des revendications 1 à 10.20