FR2973908A1 - Procede de modelisation, simulation et evaluation en avance de phase d'une plate-forme de calcul - Google Patents

Abstract

Le procédé comprend les étapes suivantes : - établissement d'un modèle bas niveau (10) de plate-forme de calcul à partir de paramètres dimensionnant (4) représentatifs des ressources matérielles et/ou logicielles nécessaires à l'exécution de requêtes générées lors de la mise en œuvre de chaque application (2), le modèle bas niveau (10) comprenant au moins un nœud de calcul (60) modélisant au moins une application (2), des composants matériels, un ou plusieurs systèmes d'exploitation et des services ; - définition d'au moins d'un scénario (6) de stimulation, correspondant à une séquence des requêtes générées ; - stimulation du modèle bas niveau (10) de la plate-forme à l'aide du ou de chaque scénario en utilisant un noyau de simulation événementiel du scénario de stimulation déterminé en fonction d'un ordonnancement des processus, et, - relever des traces du fonctionnement du modèle bas-niveau (10) pour en évaluer les performances.

Description

Procédé de modélisation, simulation et évaluation en avance de phase d'une plate- forme de calcul La présente invention concerne le domaine de l'évaluation des performances de plate-formes de calcul, embarquées ou non, destinées à l'implémentation d'au moins une 5 application informatique. Les plate-formes de calcul (embarquées ou non) sont des systèmes électroniques et informatiques dédiés à une ou plusieurs tâches. Ils sont présents dans de nombreux domaines tels que l'automobile, le ferroviaire ou encore l'avionique. Une plate-forme de calcul (embarquée ou non), est constituée d'un et plus généralement de plusieurs 10 calculateurs reliés par un médium d'interconnexion. Chaque calculateur peut posséder un ou plusieurs systèmes d'exploitation et offrir des services plate-forme pour le traitement des différentes fonctions. Par exemple les plate-formes avioniques sont parmi les plus contraintes du fait des différentes règles et normes de sécurité à respecter. Les plate-formes avioniques 15 récentes sont conçues suivant le principe IMA (acronyme de « Integrated Modular Avionics » en anglais) : un calculateur peut embarquer plusieurs applications indépendantes qui peuvent être de niveau de criticité différents (niveaux de criticité définis par la norme DO 178-B). Le principe IMA permet ainsi une réduction significative du nombre total de calculateurs embarqués à bord d'un avion, ce qui entraîne une diminution 20 de l'espace occupé, du poids, de la consommation, et des coûts de développement de ces plate-formes. Le principe IMA a également été rendu possible grâce à l'introduction d'un réseau déterministe permettant la communication entre les différents calculateurs de la plate-forme, notamment un réseau répondant au standard ARINC664 . D'autre part, le 25 standard ARINC653 définit certaines règles de sécurité pour le/les OS embarqué(s) temps-réel tournant sur ces calculateurs et permet d'offrir un partitionnement spatial (chaque application du calculateur possède son propre espace mémoire ainsi que son accès I/O réservé) et temporel (chaque application du calculateur a une fenêtre d'exécution temporelle allouée) qui garantie d'une part l'accès pour une application à 30 toutes les ressources autorisées pendant son temps d'exécution, mais garantie également qu'une erreur dans une application ne contaminera pas les autres applications embarquées sur le même calculateur. Dans le processus de développement de ces plate-formes, les concepteurs éprouvent des difficultés à concevoir et valider en avance de phase une architecture de 35 plate-forme, car l'application et l'architecture matérielle ne sont connues que de manière partielles.

Un des buts de l'invention est de proposer un procédé de modélisation et de simulation d'une plate-forme de calcul permettant une évaluation des performances d'une plate-forme en avance de phase, avec une précision suffisante pour permettre de déterminer le meilleur compromis dans le dimensionnement architecture matérielle/applications de la plate-forme de calcul (embarquée ou non). A cet effet, l'invention propose un procédé assisté par ordinateur de modélisation, simulation et évaluation en avance de phase d'une plate-forme de calcul en fonction d'au moins une application, la plate-forme de calcul comprenant des composants matériels, un ou plusieurs systèmes d'exploitation et des services, la ou chaque application générant, lors de son exécution, des requêtes à exécuter par les composants matériels, le procédé comprenant les étapes suivantes : - établissement d'un modèle bas niveau de plate-forme de calcul à partir d'ensembles de paramètres dimensionnant représentatifs des ressources matérielles et/ou logicielles nécessaires à l'exécution de requêtes générées lors de la mise en oeuvre de la ou chaque application, le modèle bas niveau comprenant au moins un noeud de calcul modélisant au moins une application, des composants matériels, un ou plusieurs systèmes d'exploitation et des services pour l'implémentation de la ou chaque application du noeud de calcul ; - définition d'au moins d'un scénario de stimulation, chaque scénario 20 correspondant à une séquence de requêtes générées lors de la mise en oeuvre de la ou chaque application ; - stimulation du modèle bas niveau de la plate-forme de calcul à l'aide du ou de chaque scénario de stimulation en utilisant un noyau de simulation événementiel du scénario de stimulation déterminé en fonction d'un ordonnancement des processus, 25 et, - relever des traces du fonctionnement du modèle bas-niveau pour en évaluer les performances lors de la mise en oeuvre de la ou chaque application. Selon d'autres modes de mise en oeuvre, le procédé de modélisation et de simulation comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou 30 selon toutes les combinaisons techniquement possibles : - on établit un modèle bas niveau comprenant plusieurs noeuds de calcul reliés par un média d'interconnexion ; - on modélise la(les) application(s) au sein de chaque noeud de calcul par des modules d'application ; 35 - on modélise les services d'une couche de service au sein de chaque noeud de calcul par des modules services ; - on modélise une couche d'interface entre les applications et les services au sein de chaque noeud de calcul par un module d'interface modélisant une API ; - on modélise les composants matériels au sein du noeud de calcul par des modules de composant matériel comportementaux, chaque module de composant matériel comportemental comprenant un automate logiciel comportemental. - on modélise l'accès aux services matériels au sein du noeud de calcul par des modules de service matériel, chaque module de service matériel étant propre à recevoir, traiter et transmettre les requêtes destinées aux modules de composant matériel comportementaux ; - on encapsule chaque module modélisant une application, un composant matériel ou un service dans un conteneur logiciel configuré pour servir d'interface de communication avec au moins un bus de communication permettant l'envoi de trames et/ou de stimuli à travers le modèle ; - chaque conteneur fonctionne selon le principe d'abonnement, et relaye depuis 15 les bus de communication vers le module de modélisation auquel il est rattaché uniquement les trames et/ou stimuli auxquelles il est abonné ; - les étapes sont appliquées de manière itérative pour déterminer un modèle bas niveau de plate-forme ; - l'établissement d'un modèle de plate-forme comprend les étapes de : 20 - réalisation d'un modèle haut niveau de plate-forme à partir des d'ensembles de paramètres dimensionnant, le modèle haut niveau comprenant des modules matériels descriptifs définis par des jeux de propriétés ; et - établissement du modèle bas niveau de plate-forme affiné à partir du modèle haut niveau en remplaçant les modules matériels descriptifs par des modules matériels 25 comportementaux affinés comprenant des automates comportementaux et en élaborant des modules de services modélisant des services de système d'exploitation requis par les applications ; - le modèle haut niveau est établi dans un langage de description architecturale, comme AADL ou XML. 30 - on établit le modèle bas niveau dans un langage de modélisation comportementale de composants matériels comprenant un noyau de simulation, notamment en langage SystemC. L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en référence aux dessins 35 annexés, sur lesquels : - la figure 1 est un diagramme illustrant schématiquement un procédé de modélisation, de simulation et d'évaluation d'une plate-forme de calcul assisté par ordinateur selon l'invention ; - la figure 2 est un diagramme illustrant schématiquement une étape de génération d'un scénario de stimulation d'un modèle de plate-forme de calcul du procédé; - la figure 3 est un diagramme illustrant schématiquement une étape de modélisation haut niveau d'une plate-forme de calcul du procédé; - la figure 4 est un diagramme illustrant schématiquement une étape de modélisation bas niveau d'une plate-forme de calcul du procédé; - la figure 5 est un diagramme illustrant schématiquement un module comportemental d'un composant matériel, en l'occurrence d'une mémoire RAM ; - la figure 6 est un diagramme illustrant schématiquement une plate-forme de calcul utilisant des conteneurs logiciels pour une couche d'application, une couche de service et une couche de matériel; - la figure 7 est un diagramme illustrant schématiquement une plate-forme de calcul, composée de noeuds de calcul reliés par un médium de communication. La figure 1 illustre schématiquement un procédé assisté par ordinateur de modélisation, de simulation et d'évaluation des performances d'une plate-forme de calcul pour la mise en oeuvre d'applications 2 informatiques conforme à l'invention.

Ce procédé comprend : - une étape de caractérisation des applications 2 dans laquelle on détermine, pour chaque application 2 destinée à être implémentée sur la plate-forme de calcul (embarquée ou non), un ensemble de paramètres dimensionnant 4 ; - une étape de génération d'un ou plusieurs scénarii de stimulation 6 à partir des 25 ensembles de paramètres dimensionnant 4 correspondant à un enchaînement de requêtes pouvant être émises par les applications 2; - une étape de modélisation dite « haut niveau » dans laquelle on détermine un modèle haut niveau 8 de plate-forme en partie grâce à l'ensemble de paramètres dimensionnant 4 extraits précédemment; 30 - une étape de modélisation dite « bas niveau » dans laquelle on détermine un modèle affiné ou modèle bas niveau 10 de plate-forme à partir du modèle haut niveau 8 de plate-forme ; - une étape de simulation dans laquelle on stimule le modèle bas niveau 10 selon les scénarii de stimulation générés précédemment ; et - une étape d'évaluation 14 dans laquelle on évalue les performances 12 du modèle affiné 10 pour l'implémentation des applications 2 afin de regarder si celles-ci respectent les exigences que la plate-forme doit vérifier. Chaque application 2 met en oeuvre plusieurs processus, chaque processus correspondant à un ensemble d'instructions, et chaque processus générant lors de son exécution des requêtes destinées à être exécutées par les composants matériels de la plate-forme embarquée sous le contrôle d'au moins un système d'exploitation OS (« Operating System » en anglais), pour lequel plusieurs politiques d'ordonnancement sont envisageables.

Les composants matériels sont du type microprocesseur, mémoire cache, mémoire LI, mémoire L2, mémoire vive RAM (SRAM, DRAM, etc.), mémoire morte ROM, mémoire statique RAM, composant programmable (type FPGA, CPLD, EPLD, autre), interface d'entrées/sorties, bus de communication, et tout autre composant qui peut être instancié sur une plate-forme de calcul.

Les requêtes sont du type requête de calcul à exécuter par un processeur ou par un composant programmable (type FPGA, CPLD, EPLD, autre), requête d'écriture ou de lecture dans une mémoire ou des registres, requête d'accès à une interface d'entrées/sorties, requête d'accès à un bus, et tout autre requête d'accès à un composant de la plate-forme de calcul.

Les caractéristiques de chaque ensemble de paramètres dimensionnant 4 correspondent à des ressources matérielles nécessaires au traitement des requêtes susceptibles d'êtres générées par l'application 2 correspondante. Un ensemble de paramètres dimensionnant 4 est variable d'une application 2 à l'autre, et peut même changer pour une même application 2 après évaluation des paramètres retenus en premier lieu. Il peut comprendre par exemple pour chaque processus d'une application 2, le taux de code séquentiel (requêtes devant être exécutées séquentiellement), le taux de code parallèle (requêtes pouvant être exécutées en parallèle), les nombres d'accès mémoire à chaque type de mémoire (cache, LI, L2, ROM, RAM...), l'espace mémoire nécessaire pour chaque type de mémoire, le taux d'accès au processeur, le taux de données flottantes, le taux de données entières, le taux d'entrée/sortie I/O ou encore les différents accès aux services offerts par l'operating system OS... A un stade avancé où le code d'une application est connu, l'étape de caractérisation de l'application 2 est effectuée par exemple à l'aide d'un outil d'analyse syntaxique (ou « parser » en anglais) mis en oeuvre par ordinateur et propre à analyser le code de l'application 2 pour déterminer de manière automatique un ensemble de paramètres dimensionnant 4 de l'application 2 appelé « stimulis ».

A un stade plus précoce, il est généralement possible de déterminer à l'avance un ensemble de paramètres dimensionnant 4 suffisamment précis pour une application déterminée non encore codée. Tel qu'illustré sur la figure 2, dans l'étape de génération d'un scénario, on détermine pour chaque processus 16 de chaque application 2 un ensemble de paramètres dimensionnant 4 et on génère une trame de requêtes, i.e. une succession de requêtes, en tenant compte de la politique d'ordonnancement des processus. La trame est générée au moyen d'un générateur de trame 17. Tel qu'illustré sur la figure 3, dans l'étape de modélisation haut niveau, on génère 10 un modèle haut niveau 8 de plate-forme embarquée en tenant compte des ensembles de paramètres dimensionnant 4 déterminés pour chaque application 2. Le modèle haut niveau 8 comprend des modules d'application 18 et des modules de composant matériel descriptifs 20. Chaque module d'application 18 modélise une application 2 destinée à être 15 implémentée sur la plate-forme et comprend au moins un ensemble de paramètres dimensionnant 4. Chaque module de composant matériel descriptifs 20 modélise un composant matériel de la plate-forme et possède un ensemble de propriétés permettant de simuler une réponse aux requêtes générées par les applications 2. L'ensemble de propriétés d'un 20 composant matériel est déterminé de façon à correspondre aux ensembles de paramètres dimensionnant 4 des applications 2. L'ensemble de propriétés de chaque module de composant matériel descriptifs 20 comprend des propriétés caractéristiques de chaque composant, comme par exemple fréquence, nombre d'unités de traitement des données entières, nombre d'unités de 25 traitement des données flottantes pour un processeur, capacité, latence lors d'un accès en écriture ou en lecture pour une mémoire, latence de conversion du signal pour une interface entrées/sorties, et toutes autres caractéristiques principales propres à chaque composant. Le modèle haut niveau 8 comprend des modules auxiliaires 19. Chaque module 30 auxiliaire 19 est associé à un module de composant matériel descriptif 20 et modélise un ou plusieurs services offerts par le système d'exploitation de la plate-forme à la ou chaque application 2, pouvant être appelés par une interface de programmation applicative ou API (acronyme de «Application Programming Interface »), par l'intermédiaire du module de composant matériel descriptif 20 associé. Le module de 35 composant matériel descriptif 20 modélise par exemple un microprocesseur.

Le modèle haut niveau 8 est soit élaboré par un outil existant qui génère un modèle sous forme de fichier de type XML ou autre, soit élaboré dans un langage de description d'architecture système, de préférence destiné aux systèmes embarqués, comme par exemple le langage AADL pour «Architecture Analysis and Design Language » en anglais. Le langage de description permet de définir des modules applicatifs et des modules matériels, chaque module pouvant posséder des caractéristiques ou propriétés et comprendre des sous-modules. Une application peut ainsi être modélisée par un module comprenant, pour chaque processus, un sous-module, qui comprend lui-même un ensemble de paramètres dimensionnant.

Dans l'étape de génération d'un modèle bas niveau, on génère un modèle bas niveau 10 affiné de la plate-forme à partir du modèle haut niveau 8. Tel qu'illustré sur la figure 4, dans cette étape on remplace les modules de composant matériel descriptifs 20 par des modules de composant matériel comportementaux 22, et on remplace le(s) module(s) auxiliaire(s) 19 notamment par un ensemble de modules service 21. Chaque module de composant matériel comportemental 22 comprend un automate comportemental paramétrable via certaines propriétés principales, et permet de simuler le comportement du composant matériel correspondant. Chaque module service 21 modélise un service offert par le système d'exploitation 20 OS. Pour déterminer les modules de composant matériel comportementaux 22, on met en oeuvre de manière assistée par ordinateur une analyse syntaxique du modèle haut niveau 8 à l'aide d'un outil d'analyse syntaxique (ou « parser » en anglais) propre à déterminer à partir du modèle haut niveau 8 les différents composants matériels 25 correspondants et leurs propriétés. Ensuite, on récupère depuis une bibliothèque de composants un module de composant matériel comportemental paramétrable correspondant à chaque composant matériel, et on paramètre le module de composant matériel comportemental en fonction des propriétés du composant matériel. Les propriétés utilisées pour le paramétrage du module de composant matériel 30 comportemental peuvent être d'un ou plusieurs types selon les paramètres que l'on souhaite valider et optimiser grâce à la modélisation et la simulation de la plate-forme de calcul. Les paramètres sont par exemple des paramètres temporels, de consommations, de fiabilité, de dissipation de chaleur, permettant une caractérisation de chaque composant suivant une analyse multicritères ou multi-angles de vue. Ainsi, l'automate 35 comportemental est capable, en réponse à une requête de simuler les différentes grandeurs précitées.

La figure 5 illustre sous forme d'un diagramme un exemple de module de composant matériel comportemental 22 simulant une mémoire RAM (SRAM, DRAM, autre) suivant des critères temporels. Ainsi, le module de composant matériel comportemental 22 simule un état d'attente 24, une fonction de rafraîchissement 26, une fonction de début de lecture 28, une fonction de lecture 30, une fonction de fin de lecture 32 et une fonction retour 34. Chaque étape est caractérisée par une durée nécessaire à la mise en oeuvre de la fonction associée. Le module de composant matériel comportemental 22 permet de connaître le temps de réponse selon les requêtes exécutées.

En revenant à la figure 4, les modules application 18 appartiennent une couche application 44 modélisant une partie applicative, les modules composant matériel comportemental 22 appartiennent à une couche matériel 46 modélisant une partie matérielle et les modules services 21 appartiennent à une couche service 48 modélisant une partie intergiciel (« middleware »).

Les modules application 18, les modules service 21 et les modules de composant matériel comportementaux 22 sont chacun encapsulés dans un conteneur 40 logiciel d'interfaçage. Chaque conteneur 40 dispose des propriétés permettant : d'interfacer chaque module d'une même couche (couche application 44, 20 couche de services 48, couche de matériel 46), de relier les modules d'une même couche à un même bus de communication. Les conteneur 40 sont issus d'un module générique paramétrable en fonction du module d'application, de service ou de composant matériel comportemental auquel il est associé et qui permet une gestion transparente des connexions. 25 Les conteneurs 40 d'une même couche sont reliés par un unique bus façon à recevoir toutes les communications. Chaque conteneur 40 est paramétré de façon à transmettre au module associé, uniquement les trames et/ou stimuli destinés à ce module (par ex : les trames et/ou stimuli modélisant des requêtes destinées à être traitées par un module de composant matériel comportemental 22). 30 L'utilisation de conteneurs 40 permet de simplifier la modélisation de la plate-forme en s'affranchissant du schéma classique consistant à lier entre eux les différents modules, et en particulier les modules de composant matériel. Le modèle bas niveau 10 à base de conteneurs 40 permet une simulation suffisamment fiable tout en étant simple à élaborer. L'invention proposée offre une méthode itérative qui permet d'affiner le modèle 35 bas niveau 10 en fonction des besoins simplement par ajout, modification et/ou suppression d'un module de composant matériel comportemental 22.

Tel que représenté sur la figure 6 illustrant plus complètement un modèle bas niveau 10, on génère un modèle bas niveau 10 dans lequel la couche de service 48 comprend en outre un module d'interface 52 disposé entre les modules service 21 et la couche d'application 44 et un module de service matériel 54 disposé entre les modules service 21 et la couche matériel 46. Le module d'interface 52 modélise une interface de programmation applicative ou API qui centralise les appels des applications vers les services de la couche de service 48, vérifie que l'appel correspond à une opération autorisée, et relaie l'appel vers le module service 21 associé.

Le module de service matériel 54 modélise un composant matériel rendant un service commun aux différents composants matériel modélisés par les modules comportementaux 22. Le module de service matériel 54 modélise par exemple une unité de contrôle sous la forme d'un automate logiciel intégré au processeur et qui génère des signaux de contrôle et de commande pour piloter les opérations de contrôle effectuées avant l'accès aux ressources matérielles, comme la vérification de la validité d'une demande d'accès mémoire par une application. Les conteneurs 40 de la couche application 44 sont reliés au module d'interface 52 par un bus d'application 56 unique. Les conteneurs 40 de la couche service 48 sont reliés à chacun du module d'interface 52 et du module de service matériel 54 par un bus de service 57 unique. Le module de service matériel 54 est relié aux conteneurs 40 de la couche matériel 44 par un bus de matériel 58 unique. Une plate-forme de calcul peut comprendre une pluralité de noeuds de calculs reliés entre eux par un medium de communication. Ainsi, tel qu'illustré sur la figure 7, un modèle bas niveau 10 modélisant une plateforme correspondante peut comprendre plusieurs noeuds de calcul 60 reliés entre eux par un medium de communication 61, chaque noeud de calcul 60 étant modélisé par un modèle tel qu'illustré sur la figure 6. Le modèle bas niveau 10 est élaboré dans un langage de description matériel permettant une description comportementale des composants matériels. On s'appuie également sur un noyau de simulation permettant de simuler le modèle de façon à mettre en oeuvre des scénarii de stimulation simulant une succession d'évènements de manière dynamique et de suivre des signaux ou « traces » représentatives du fonctionnement de la plate-forme dans son ensemble ou de chaque composant de la plate-forme. Ceci afin de déterminer si la plate-forme est compatible avec les critères déterminés ou exigences. Le modèle bas niveau 10 est élaboré par exemple en langage SystemC, comprenant un noyau de simulation événementiel.

Les critères ou exigences 15 sont par exemple du type contraintes temporelles à respecter pour chaque processus, contraintes d'utilisation mémoire, contraintes de dissipation de chaleur, contraintes de fiabilité. Dans l'étape de stimulation, le modèle bas niveau 10 de plate-forme informatique est stimulé de manière assistée par ordinateur en utilisant un noyau de simulation événementiel, sur la base d'un ou plusieurs scénarii de stimulation élaboré(s) précédemment. Le langage SystemC comprend un noyau de simulation événementiel. Sur la base du scénario de stimulation, les modules applicatifs 18 émettent des requêtes qui sont adressées au module d'interface 52, qui les envoie aux différents services de la couche de service 48. Chaque service traduit ces requêtes haut niveau en requêtes élémentaires exploitables par les modules de composant matériel comportementaux 22... Chaque requête élémentaire issue des ces requêtes haut niveau est envoyée à tous les conteneurs 40 encapsulant les modules de composant matériel comportementaux 22 qui n'acceptent que les requêtes élémentaires qui le concerne.

Chaque module de composant matériel comportemental 22 répond à la requête élémentaire le concernant. Le cas échéant, l'émission d'une nouvelle requête élémentaire par le module de service matériel 54 vers les modules comportementaux de composant matériel 22 peut nécessiter d'attendre la réponse à une requête élémentaire précédente suivant la séquence à suivre. Les réponses aux requêtes sont remontées au module de service matériel 54 via le bus de matériel 58 et les conteneurs 40 de la couche de matériel 46. Dans l'étape d'analyse des performances, on relève des traces représentatives du fonctionnement et des performances de la plate-forme. Ces traces peuvent ensuite être analysées pour déterminer si la plate-forme fonctionne de manière appropriée pour la mise en oeuvre des applications concernées. Dans la négative, il est possible de reprendre le procédé de manière itérative à partir des étapes de modélisation haut niveau et de stimulation pour modifier le modèle de plate-forme de manière itérative de façon à en améliorer le fonctionnement lors de l'implémentation des applications. La conformité de la plate-forme réalisée se fait par comparaison via un module d'analyse des réponses de la plate-forme aux stimuli (i.e les performances de la plate-forme) et des exigences, (i.e les performances attendues de la plate-forme). Un système pour la mise en oeuvre du procédé selon l'invention comprend un ordinateur possédant un processeur et au moins un programme d'ordinateur exécutable de manière à mettre en oeuvre le procédé. Le système comprend notamment un programme de description d'architecture système à haut niveau, de préférence destiné aux systèmes embarqués, du type AADL ou MARTE, un programme de description matériel comportemental permettant une description des composants matériels à l'aide d'automates comportementaux, comprenant une bibliothèque des modèles comportementaux paramétrables et un noyau de simulation évènementiel, du type noyau de simulation événementiel du langage de description matériel SystemC.

L'invention concerne également un produit programme d'ordinateur enregistré sur un support de données, exécutable sur un ordinateur et comprenant un programme de description d'architecture système, de préférence destiné aux systèmes embarqués, du type AADL, et un programme de description matériel comportemental permettant une description des composants matériels à l'aide d'automates comportementaux, comprenant une librairie des modèles comportementaux paramétrables et un noyau de simulation évènementiel, du type SystemC. Le procédé de simulation d'une plate-forme de calcul (embarquée ou non) selon l'invention permet la mise en oeuvre d'une modélisation à un stade précoce de la conception de la plate-forme informatique avec un degré de précision suffisant pour valider une architecture de plate-forme de calcul (embarquée ou non), sans toutefois nécessairement disposer des applications logicielles destinées à être implémentées sur la plate-forme et sans figer la plate-forme et donc en laissant plus de liberté pour la conception des applications logicielles. Notamment, la modélisation de la partie matérielle s'appuie sur un modèle bas niveau intégrant des modules matériels comportementaux paramétrables modélisant des composants matériels, notamment élaborés dans un langage de description matériel bas niveau tel SystemC, permettant une simulation plus fine qu'un modèle haut niveau, dans lequel les modules simulant les composants matériels sont définis uniquement par un jeu de propriétés, par exemple en langage AADL. En outre, ces modèles comportementaux peuvent être paramétrés suivant plusieurs points de vue différents tels que vue temporelle, fiabilité, sécurité de fonctionnement ou encore vue consommation. En outre, le modèle bas niveau utilise des conteneurs logiciels et une représentation intégrant une couche de service centrale comprenant un ensemble de modules de service faisant interface entre les modules d'application et les modules de composant matériel et communiquant avec la couche de matériel via un bus de matériel unique. Les conteneurs logiciels offrent une grande flexibilité et modularité dans la connexion/déconnexion des différents modules. Chaque module modélisant une application, un service ou composant matériel étant connecté à son conteneur, le nombre de connexions est réduit à deux, quelque soit le module.

Grâce à un mécanisme d'abonnement, chaque conteneur associé à un module de composant matériel reçoit toutes les requêtes, et ne relaie vers le module de composant matériel que celles auxquelles il est "abonné" (notion de contrat entre le module de composant matériel et le conteneur). II n'est donc plus nécessaire de connaître exactement le nombre de ports de chaque composant ni les connexions entre les composants simulés par les modules de composant matériel. Le conteneur est de plus un élément générique paramétrable qui extrait la partie interface de connexion du module associé, ce qui permet lors du développement d'un nouveau module de se concentrer sur la partie purement comportementale. En outre, le procédé selon l'invention s'appuie sur un noyau de simulation. Les analyses de performances effectuées sont ainsi des performances dynamiques, plus 10 précises que des performances statiques. L'itération du processus offre la possibilité de modifier ou affiner la plate-forme générée (assemblage de composants élémentaires : matériel, operating system, services plate-forme) afin qu'elle convienne au mieux à l'applicatif appelé à être exécuté sur celle-ci.

15 Ces avantages permettent d'obtenir une méthode de modélisation et de validation en avance de phase itérative, flexible et modulaire, le tout avec une bonne précision dans les analyses de performances par rapport à la plate-forme réelle. L'invention s'applique à la simulation de plate-formes de calcul qu'elles soient avioniques, ferroviaire, automobile, navale, terrestre ou autre..

Claims (1)

1. REVENDICATIONS1.- Procédé assisté par ordinateur de modélisation, simulation et évaluation en avance de phase d'une plate-forme de calcul en fonction d'au moins une application (2), la plate-forme de calcul comprenant des composants matériels, un ou plusieurs systèmes d'exploitation et des services, la ou chaque application (2) générant, lors de son exécution, des requêtes à exécuter par les composants matériels, le procédé comprenant les étapes suivantes : - établissement d'un modèle bas niveau (10) de plate-forme de calcul à partir d'ensembles de paramètres dimensionnant (4) représentatifs des ressources matérielles et/ou logicielles nécessaires à l'exécution de requêtes générées lors de la mise en oeuvre de la ou chaque application (2), le modèle bas niveau (10) comprenant au moins un noeud de calcul (60) modélisant au moins une application (2), des composants matériels, un ou plusieurs systèmes d'exploitation et des services pour l'implémentation de la ou chaque application (2) du noeud de calcul (60) ; - définition d'au moins d'un scénario (6) de stimulation, chaque scénario correspondant à une séquence de requêtes générées lors de la mise en oeuvre de la ou chaque application (2) ; - stimulation du modèle bas niveau (10) de la plate-forme de calcul à l'aide du ou de chaque scénario de stimulation en utilisant un noyau de simulation événementiel du scénario de stimulation déterminé en fonction d'un ordonnancement des processus, et, - relever des traces du fonctionnement du modèle bas-niveau (10) pour en évaluer les performances lors de la mise en oeuvre de la ou chaque application (2).

   2.- Procédé selon la revendication 1, dans lequel on établit un modèle bas niveau (10) comprenant plusieurs noeuds de calcul (60) reliés par un média d'interconnexion (61).

   3.- Procédé selon la revendication 1 ou 2, dans lequel on modélise la(les) application(s) au sein de chaque noeud de calcul (60) par des modules d'application (18).

   4.- Procédé selon l'une quelconque des revendications précédentes, dans lequel on modélise les services d'une couche de service au sein de chaque noeud de calcul (60) par des modules services (21).

   5.- Procédé selon la revendication 4, dans lequel on modélise une couche d'interface entre les applications (2) et les services au sein de chaque noeud de calcul 35 (60) par un module d'interface (52) modélisant une API.

   6.- Procédé selon l'une quelconque des revendications précédentes, dans lequel on modélise les composants matériels au sein du noeud de calcul (60) par des modules de composant matériel comportementaux (22), chaque module de composant matériel comportemental (22) comprenant un automate logiciel comportemental.

   7.- Procédé selon la revendication 6, dans lequel on modélise l'accès aux services matériels au sein du noeud de calcul (60) par des modules de service matériel (54), chaque module de service matériel (54) étant propre à recevoir, traiter et transmettre les requêtes destinées aux modules de composant matériel comportementaux (22).

   8.- Procédé selon l'une quelconque des revendications précédentes, dans lequel on encapsule chaque module modélisant une application (18), un composant matériel (22) ou un service (21) dans un conteneur (40) logiciel configuré pour servir d'interface de communication avec au moins un bus de communication (56, 57, 58) permettant l'envoi de trames et/ou de stimuli à travers le modèle.

   9.- Procédé selon la revendication 8, dans lequel chaque conteneur (40) fonctionne selon le principe d'abonnement, et relaye depuis les bus de communication (56, 57, 58) vers le module de modélisation auquel il est rattaché uniquement les trames et/ou stimuli auxquelles il est abonné.

   10.- Procédé selon l'une quelconque des revendications précédentes, dans lequel les étapes sont appliquées de manière itérative pour déterminer un modèle bas niveau de 20 plate-forme.

   11.- Procédé selon l'une quelconque des revendications précédentes, dans lequel l'établissement d'un modèle de plate-forme comprend les étapes de : - réalisation d'un modèle haut niveau (8) de plate-forme à partir des d'ensembles de paramètres dimensionnant (4), le modèle haut niveau comprenant des modules 25 matériels descriptifs (20) définis par des jeux de propriétés ; et - établissement du modèle bas niveau (10) de plate-forme affiné à partir du modèle haut niveau (8) en remplaçant les modules matériels descriptifs (20) par des modules matériels comportementaux (22) affinés comprenant des automates comportementaux et en élaborant des modules de services (21) modélisant des services 30 de système d'exploitation requis par les applications (2).

   12.- Procédé selon la revendication 11, dans lequel le modèle haut niveau (8) est établi dans un langage de description architecturale, comme AADL ou XML.

   13.- Procédé selon l'une quelconque des revendications précédentes, dans lequel on établit le modèle bas niveau (10) dans un langage de modélisation comportementale 35 de composants matériels comprenant un noyau de simulation, notamment en langage SystemC.