FR2964225A1 - Procede et dispositif de deploiement et d'aide au deploiement de composants formant un systeme temps reel embarque - Google Patents

Abstract

La présente invention concerne un procédé de déploiement de composants d'un système sur au moins une plateforme comportant plusieurs processeurs. Le procédé de déploiement comporte des étapes de : • formalisation d'un fichier de description d'un composant pour chaque composant du système, d'un fichier de description d'un assemblage des composants, d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes, d'un fichier de mise en correspondance des composants avec des tâches exécutables • génération du code logiciel des conteneurs pour les composants, • génération de la définition et du code logiciel des tâches exécutables correspondant aux composants et aux conteneurs ; • production et mise en ouvre des exécutables sur les processeurs des plateformes.

Description

Procédé et dispositif de déploiement et d'aide au déploiement de composants formant un système temps réel embarqué La présente invention concerne un procédé et un dispositif de déploiement, et d'aide au déploiement, de composants formant un système temps réel embarqué. Cette invention s'exerce notamment dans le domaine de l'ingénierie logicielle appliquée à la conception et à la réalisation de systèmes informatiques complexes temps réels embarqués comme un calculateur de vol embarqué à bord d'aéronefs.

Un système informatique complexe temps réel embarqué est un système informatique comportant de multiples composants logiciels, lesdits composants logiciels pouvant s'exécuter sur un ou plusieurs calculateurs informatiques. Les logiciels temps réel doivent répondre à d'importantes contraintes en matière de temps de réponse. De plus, le domaine des logiciels embarqués impose des limitations en matière de taille physique des calculateurs sur lesquels sont mis en oeuvre le système. Ces contraintes de tailles se répercutent au niveau des logiciels en matière de performances. En effet, plus un système nécessite de ressources de calcul pour s'exécuter plus le nombre de calculateur sera important. II est donc crucial de pouvoir gérer les ressources de calcul disponibles à bord d'un mobile, de manière optimale. L'ingénierie logicielle intervient dans toutes les phases de création, réalisation et production d'un produit, ledit produit pouvant être un composant logiciel ou un système logiciel complexe. L'ingénierie logicielle intervient notamment dans des phases d'analyse d'un besoin opérationnel auquel le système doit répondre afin d'établir un cahier des charges pour la réalisation du système. Une fois le besoin clairement identifié, des spécifications du système sont établies. Les spécifications du système sont tout d'abord établies à haut niveau puis avec une granularité de définition de plus en plus fine pour arriver à une définition du code d'implémentation des différents composants du système logiciel. Ensuite la production de code intervient, suivie par la production des logiciels exécutables. Durant toutes les phases de spécifications, de conception et de réalisation, il est nécessaire de s'assurer que le système logiciel produit répond aux contraintes, notamment en termes de temps de traitement et d'occupation des ressources, ainsi qu'aux spécifications originelles. Un des objectifs de l'ingénierie logicielle est de s'assurer que le système final répond aux contraintes et spécifications initiales.

Pour s'assurer que le système répond aux contraintes et spécifications pendant tout son cycle de conception, de développement, il est nécessaire de s'assurer du comportement dynamique prédictif du système. Pour s'assurer du caractère prédictif d'un système, il est nécessaire de formaliser et de vérifier les mécanismes de coopération entre les ~o composants d'un système logiciel conçu sur la base d'une architecture système. Actuellement, dans le domaine des systèmes logiciels à base d'architecture en composants, il existe des solutions à base de CORBA Component Model ou Enterprise Java Beans. CORBA est l'acronyme pour 15 l'expression anglo-saxonne : Common Object Request Broker Architecture et Component Model signifie littéralement : modèle composant. CORBA est une architecture logicielle, pour le développement de composants et d'Object Request Broker signifiant littéralement courtier de requêtes objet. Enterprise Java Beans ou EJB, est également une architecture composant, vue du côté 20 serveur. Les solutions à base de CCM, acronyme de l'expression anglo-saxonne Corba Component Model, et à base d'EJB proposent principalement des mécanismes de communication de type évènement ou de type service pour faire coopérer des composants logiciels. Les solutions à base de CCM ou d'EJB sont très limitatives d'un 25 point de vue mécanisme de coopération. En effet, il n'est par exemple pas possible de définir des mécanismes de type partage de données. Des mécanismes de type partage de données se font donc au travers de mécanismes de type service. Or dans le contexte des systèmes temps réels embarqués, des applications logicielles partagent des données et collaborent 30 massivement autour de données qui constituent leur articulation principale. Par exemple, une formalisation de coopération entre équipements dans le domaine aéronautique se fait par la réalisation d'ICD décrivant l'ensemble des données échangées. ICD est un acronyme pour l'expression anglo-saxonne Interface Control Document, signifiant littéralement document de 35 contrôle d'interface. Pour paramétrer l'utilisation de ces services, certaines qualités de service existent. Une qualité de service, QdS est une capacité à véhiculer dans de bonnes conditions un type de trafic donné, en termes de disponibilité, débit, délais de transmission, taux de perte de paquets de données, temps de réponse. Une prise en compte de contraintes de temps de réponse peut par exemple se faire au moyen d'une définition d'une interruptibilité des coopérations entre composant, d'une allocation de composants sensibles en matière de temps de réponse à des tâches temps réelles. Une interruptibilité est une aptitude à être interrompue. Parmi les qualités de service existantes, aucune ne permet de spécifier des règles relatives au comportement temps réel du système logiciel et sa projection ou utilisation sur des ressources d'une plateforme de calcul. De plus, la prise en compte de contraintes de temps de réponse, est soit à la charge des développeurs des composants, soit à la charge des développeurs d'un conteneur encapsulant les composants. Mais le plus souvent, la prise en compte des contraintes de type temps de réponse est opaque vis-à-vis de la logique sous-jacente mise en oeuvre. II est également à noter que bien souvent, il n'existe aucune souplesse dans la connexion des opérations de type événements ou services entre composants logiciels. La connexion des composants entre eux est faite par une allocation d'interface d'événement ou d'interface de service à des composants en tant que producteur et consommateur. Cela impose donc une identité de nom entre l'interface proposée par un producteur et l'interface requise par le consommateur. Cette identité est difficile et lourde à gérer.

Pour s'assurer que le système répond aux contraintes et spécifications initiales, il est également nécessaire de pouvoir évaluer les performances du système logiciel dès les phases amont de conception du système. Pour évaluer les performances d'un système logiciel non produit, il existe notamment deux approches.

Une première approche repose sur une évaluation macroscopique d'une complexité globale des composants logiciels dont est déduit une estimation du temps que va mettre un composant logiciel pour s'exécuter sur une plate-forme de calcul, ladite plate-forme de calcul pouvant être composé d'un ou plusieurs calculateurs. Cette première approche repose sur un retour d'expérience par rapport au fonctionnement de systèmes connus. Cette première approche est simple à mettre en oeuvre mais la précision des résultats obtenus n'est pas suffisamment précise. Une approximation de la puissance de calcul induite peut être suffisante mais l'évaluation de la tenue des temps de réponse imposé par la contrainte temps réel repose sur beaucoup d'hypothèses, notamment des hypothèses concernant l'implémentation du logiciel selon des règles de développement qui sont dans la majorité des cas non vérifiées. Une deuxième approche repose sur une simulation du système logiciel. Une telle simulation se base sur un codage logiciel de parties des algorithmes mis en oeuvre par le système. Pour cette deuxième approche, la qualité des estimations dépend très fortement de la finesse de la simulation au regard du futur comportement réel du système. Un des principaux risques de cette deuxième approche est de finalement réaliser une simulation très détaillée en avance de phase sur la réalisation du système : ce qui est très coûteux en termes de développement logiciel. II y a en effet un risque de pré-développer le système en détail, juste pour faire une prédiction de performances.

Un but de l'invention est notamment de pallier les inconvénients 20 précités. A cet effet, l'invention a pour objet un procédé de déploiement de composants d'un système sur au moins une plateforme comportant un ou plusieurs processeurs. Le procédé comporte au moins les étapes suivantes : - génération d'un fichier de description d'un composant pour chaque composant du système, ledit fichier comportant une description des 25 opérations et données, entrants et sortants du composant ; - génération d'un fichier de description d'un assemblage des composants pour former le système ; - génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des 30 plateformes ; - génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - génération de code logiciel de conteneurs des composants, chaque composant étant encapsulé par un conteneur, ledit conteneur comportant l'ensemble des interfaces entre le composant et le système et entre le composant et les autres composants du système, à partir du fichier de mise en correspondance des composants avec des tâches exécutables ; - génération de code logiciel des tâches exécutables correspondant aux composants et aux conteneurs ; - production des exécutables par assemblage du code des tâches exécutables, du code des conteneurs, du code des composants associés à chaque exécutable ; - mise en oeuvre des exécutables sur les processeurs des plateformes en fonction du fichier de déploiement. Avantageusement, le procédé peut en outre comporter une étape de vérification syntaxique et sémantique des fichiers de description des composants, des fichiers de description de l'assemblage, des fichiers de description du déploiement. Le procédé peut en outre comporter une étape de vérification de cohérence entre les fichiers de description des composants, de l'assemblage, du déploiement. Le procédé peut comporter une étape de modification des fichiers de description des composants, de l'assemblage, du déploiement, lorsqu'une erreur de cohérence des fichiers est détectée au cours de l'étape de vérification de cohérence ou au cours de l'étape de vérification syntaxique et sémantiques des fichiers précités. Les fichiers générés suivent notamment une grammaire prédéfinie. Les fichiers sont par exemple générés au format xml, acronyme pour l'expression anglo-saxonne Extensible Markup Language signifiant littéralement langage extensible de balisage.

Les fichiers xml peuvent être générés selon un modèle xsd, acronyme pour l'expression anglo-saxonne xml Schema Description, signifiant schéma xml de description. L'invention a également pour objet un dispositif de déploiement de composants d'un système sur au moins une plateforme comportant un ou plusieurs processeurs. Le dispositif comporte au moins : - un moyen de génération d'un fichier de description d'un composant pour chaque composant du système, ledit fichier comportant une description des opérations et données, entrants et sortants du composant ; - un moyen de génération d'un fichier de description d'un assemblage des composants pour former le système ; - un moyen de génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; - un moyen de génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - un moyen de génération de code logiciel de conteneurs des composants, chaque composant étant encapsulé par un conteneur, ledit conteneur comportant l'ensemble des interfaces entre le composant et le système et entre le composant et les autres composants du système, à partir du fichier de mise en correspondance des composants avec des tâches exécutables ; - un moyen de génération de code logiciel des tâches exécutables correspondant aux composants et aux conteneurs ; - un moyen de production des exécutables par assemblage du code des tâches exécutables, du code des conteneurs, du code des composants, pour chaque exécutable ; - un moyen de mise en oeuvre des exécutables sur les processeurs des plateformes en fonction du fichier déploiement. Le dispositif peut en outre comporter un moyen de vérification syntaxique et sémantique des fichiers de description des composants, du fichier de 3o description de l'assemblage, du fichier de description du déploiement. Le dispositif peut également comporter un moyen de vérification de cohérence entre les fichiers de description des composants, de l'assemblage, du déploiement.

L'invention a également pour objet un procédé d'évaluation de performance d'un déploiement de composants d'un système sur au moins une plateforme comportant un ou plusieurs processeurs. Le procédé d'évaluation comporte au moins les étapes suivantes : - génération d'un fichier de description d'un composant pour chaque composant du système, ledit fichier comportant une description des opérations et données, entrants et sortants du composant, ledit fichier décrivant une modélisation du fonctionnement du composant en terme de temps de traitement ; - génération d'un fichier de description d'un assemblage des composants pour former le système ; - génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; - génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - génération d'un fichier de description d'un scénario d'exécution d'une simulation du système, mettant en oeuvre les modélisations des composants ; - exécution virtuelle du scénario et analyse temporelle des traitements réalisés par les composants modélisés ; - prise en compte de l'analyse dans la description des composants, de l'assemblage des composants, du déploiement des composants du système. L'invention porte également sur un dispositif d'évaluation de performance d'un déploiement de composants d'un système sur une plateforme comportant un ou plusieurs processeurs. Le dispositif 3o d'évaluation, comporte au moins : - un moyen de génération d'un fichier de description d'un composant pour chaque composant du système, ledit fichier comportant une description des opérations et données, entrants et sortants du composant, ledit fichier décrivant une modélisation du fonctionnement 35 du composant en terme de temps de traitement ; - un moyen de génération d'un fichier de description d'un assemblage des composants pour former le système ; - un moyen de génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; - un moyen de génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de ~o description du déploiement ; - un moyen de génération d'un fichier de description d'un scénario d'exécution d'une simulation du système, mettant en oeuvre les modélisations des composants ; - un moyen d'exécution virtuelle du scénario et d'analyse temporelle 15 des traitements réalisés par les composants modélisés.

L'invention a notamment pour principaux avantages de permettre une maîtrise et un suivi régulier du système au cours des différentes phases de conception et de développement du système. Ladite maîtrise permet de 20 vérifier la satisfaction des exigences et des spécifications auxquelles le système doit répondre. En particulier le respect des exigences de temps de réponse ainsi que l'utilisation des ressources physiques tel que différents processeurs d'une plateforme peuvent être maîtrisés tout au long du processus de conception et de développement du système. 25 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 en regard des dessins annexés qui représentent : 30 - la figure 1 : un exemple de production d'interface au niveau composant selon l'état de la technique ; - la figure 2 : un exemple de production d'interface au niveau composant selon l'invention ; - la figure 3 : un conteneur selon l'invention ; - la figure 4 : un exemple d'un procédé de déploiement de composants d'un système complexe selon l'invention ; - la figure 5 : un exemple d'un procédé d'évaluation de performances d'un système complexe selon l'invention.

La figure 1 représente un exemple de production d'interfaces entre composants d'un système, selon l'état de la technique. La réalisation de systèmes complexes temps réels embarqués impose souvent une décomposition du système en plusieurs composants temps réels embarqués dudit système. Des connexions physiques entre les composants sont réalisées par des connexions via des sockets et des ports TCP/IP ou UDP/IP. Les sockets sont des connecteurs réseau. TCP, UDP et IP sont des protocoles de communications, TCP étant un acronyme pour l'expression anglo-saxonne Transmission Control Protocol, UDP étant un acronyme pour l'expression anglo-saxonne User Datagram Protocol et IP étant un acronyme pour l'expression anglo-saxonne Internet Protocol. Une tâche temps réel est créée par le système pour chacun des composants. Chaque composant coopère avec un ou plusieurs autres composants du système au moyen d'une ou plusieurs interfaces. A cette fin, et par exemple, une première interface 1 peut être définie. La première interface 1 peut comporter au moins un identifiant noté « Nom » sur la figure 1. Des composants 2, 3 du système devant coopérer doivent à cette fin implémenter la première interface 1. C'est-à-dire que les composants 2, 3 doivent implémenter les arguments et le prototype de la première interface 1. Ainsi le premier composant 2 implémente la première interface « Nom » et le deuxième composant implémente également la première interface « Nom ». Ainsi pendant la phase de conception, il est nécessaire que l'ensemble des responsables de développement de chaque composant se mettent d'accord sur la première interface 1, afin de décider d'une implémentation commune de la première interface 1, satisfaisant les besoins de chaque composant. Ensuite chaque composant doit implémenter toutes les interfaces avec les autres composants auxquels il est connecté. II n'y a donc aucune souplesse dans la définition interfaces au niveau de l'architecture du système. II est alors difficile aux architectes du système de maîtriser l'évolution de l'architecture du système tant au cours de sa conception qu'au cours de sa réalisation, voire de ses futures évolutions. De tels systèmes sont donc très difficiles à faire évoluer. En effet à chaque évolution pour laquelle il est nécessaire de modifier les interfaces, chaque composant utilisant l'interface modifiée doit prendre en compte cette modification. De plus chaque modification d'interface induit des effets de bords sur le fonctionnement du système. Ces effets de bord ne sont ni prédictibles, ni maîtrisables. Par exemple une suppression d'un argument dans une méthode d'interface, ledit argument n'étant à priori pas utilisé, peut entrainer une série d'erreurs dont on peut difficilement identifier la cause à priori. En effet, une fonctionnalité d'un composant peut utiliser contre toute attente l'argument supprimé. De plus les corrections d'erreurs au niveau d'une interface du système, par un intervenant ne maîtrisant pas l'ensemble des composants utilisant cette interface, peuvent introduire une instabilité difficilement prévisible dans le code du système.

La figure 2 représente un exemple de production d'interface au niveau d'un composant, selon l'invention. Un principe de l'invention repose sur une définition d'une interface 4, 5 au niveau de chaque composant 2, 3.

Par exemple, selon ses besoins, le premier composant 2 peut comporter une deuxième interface 4 identifiée par « Nom1 ». Le deuxième composant peut comporter une troisième interface 5 identifiée par « Nom2 ». Les deuxième et troisième interfaces 4, 5 étant aptes à coopérer entre elles, elles sont peuvent être liées ensemble par un architecte du système. Cette liaison peut être formalisée par un lien, ou Link, identifié par exemple par « Nom1-Nom2 ». La liaison peut s'effectuer après une ou plusieurs vérifications syntaxiques, vérifications sémantiques et vérification de cohérence des deux interfaces 4, 5 à lier. Avantageusement, une telle définition d'interface permet à chaque composant d'être indépendant des autres composants avec lesquels il est lié. Ainsi, par exemple, les changements de nom au niveau des interfaces d'un composant n'ont pas, ou peu, d'influence sur les interfaces des autres composants du système.

La figure 3 représente de manière schématique un conteneur 7 35 selon l'invention. Chaque composant 8 du système peut être encapsulé par un conteneur, ou en anglais container, assurant l'interface avec d'autres composants du système via leur conteneur respectif. Ainsi, pour chaque composant sont définies les interfaces dont il a besoin, indépendamment des autres composants. Le conteneur implémente une surcouche logicielle nécessaire à l'intégration du composant 8 dans le système. Le conteneur est un middleware, ou intergiciel, généré automatiquement par un outil de génération de conteneurs, à partir de fichiers XML de description de contrats, tels que définis ci-après. Un fichier XML est un fichier écrit dans un langage informatique de balisage générique, XML étant un acronyme pour l'expression anglo-saxonne Extensible Markup Language, signifiant littéralement langage extensible de balisage. Les interfaces entre les différents composants via leur conteneur doivent avoir la même signature c'est-à-dire les même types de données physiques, mais pas obligatoirement les mêmes noms de données ou nom de type de donnés tel que représenté sur la figure 2. La contrainte d'identité entre les signatures des interfaces peut être vérifiée automatiquement par un outil de vérification syntaxique et lexical adapté. Plusieurs types d'interfaces peuvent être définis entre un composant et son conteneur. Par exemple peuvent être définies : - des interfaces requises 9 pour le fonctionnement du composant, ces interfaces permettant au composant de récupérer des données, des informations nécessaires à son fonctionnement ; - des interfaces fournies 10 par le composant, permettant de transmettre au système des données et des informations provenant 25 de résultats des traitements fonctionnels réalisés par le composant ; - des interfaces de fonctionnement 11, permettant au composant de prendre en compte des ordres provenant du système comme un ordre de démarrage, d'arrêt, et de fournir au système notamment des informations sur l'état de fonctionnement du composant, par exemple : 30 fonctionnement normal, fonctionnement dégradé, arrêté. Le composant lui-même comporte uniquement des traitements fonctionnels indépendamment du système et des autres composants du système. Le composant peut donc être développé et implémenté indépendamment du système. L'implémentation d'un composant comprend notamment la 35 génération du code fonctionnel du composant. La génération du code fonctionnel du composant peut être manuelle. Les traitements non fonctionnels fortement dépendants du système sont réalisés par le conteneur. Le conteneur supporte ainsi toute la variabilité de fonctionnement du composant avec le système, ce qui permet une gestion et une intégration simple de composants hétérogènes dans un même système. Avantageusement, une telle encapsulation de composants permet donc de composer un système à partir de composants existants et préalablement construits selon la présente invention. Avantageusement, l'inclusion de nouveaux composants dans le système ou la modification d'un composant du système a peu d'impact sur les autres composants : la connexion des interfaces n'ayant aucun lien avec les parties fonctionnelles des composants.

La figure 4 représente un exemple d'un procédé de déploiement de composants d'un système complexe selon l'invention.

Au cours d'une première étape du procédé de déploiement selon l'invention, chaque composant du système peut être décrit selon une grammaire définie par un modèle XSD. Un modèle XSD, ou XML Schema, est un langage de description de format d'un document XML. Le modèle XSD permet de définir une structure pour le document XML. Le modèle XSD définit ainsi un langage de description d'un composant. Le langage de description du composant permet de formaliser différents types de coopérations pouvant exister entre les composants du système. Par exemple : - une coopération de type évènements, lesdits événements étant définis par un signal ou un stimulus provenant d'un ou de plusieurs composants producteurs à destination d'un ou plusieurs composants consommateurs ; - une coopération de type message, ledit message comportant un signal et des données, produits par un ou plusieurs composants producteurs pour un ou plusieurs composants consommateurs - une coopération de type publication / lecture de données, c'est-à-dire une mise à disposition de données par un composant pour que ces données soient lues par un ou plusieurs autres composants. Dans ce cas, il y a un composant producteur et un ou plusieurs composants consommateurs ; - une coopération de type service, c'est-à-dire un traitement réalisé par un composant pour un autre composant, dans ce cas il y a un composant producteur et un composant consommateur. Avantageusement, une utilisation de mécanismes de type événement, service et d'un mécanisme de partage de données versionnées, permet de garantir une cohérence temporelle des données pendant tout le temps d'accès aux données, notamment en définissant une qualité de service associée à la publication de données. Des données versionnées sont des données auxquelles est attribué un numéro de version dès qu'elles évoluent, tout en conservant la donnée dans sa forme initiale associée à son numéro de version. Ainsi conserver plusieurs versions des données permet de retrouver une version plus facilement même après la mise en place de versions plus récentes de la donnée. Une qualité de service est par exemple une capacité à véhiculer, dans de bonnes conditions, un type de trafic, en termes de disponibilité, débit, délais de transmission, taux de perte de paquets de données, temps de réponse. La cohérence temporelle des données est assurée par le fait que lors de la lecture d'une donnée, le composant lecteur se voit affecter la dernière version de la donnée produite par le composant producteur. La version de la donnée affectée au lecteur est gardée stable et fixe dans un premier buffer pour le composant consommateur/lecteur même si le composant producteur produit entre temps une nouvelle version de la donnée. En effet le composant producteur se voit affecter un deuxième buffer de donnée pour la production d'une nouvelle version de la donnée. Lorsque que le consommateur/lecteur « relâche » la version qu'il utilisait, si aucun autre consommateur ne l'utilise, cette version ainsi que le premier buffer qui lui est associé sont libérés et le premier buffer devient à nouveau disponible pour le composant producteur. Ce type de gestion apporte deux avantages majeurs en termes de respect des contraintes temps réel : - il n'y a pas de blocage ou d'inversion de priorité entre les composants producteurs et les composants consommateurs : par exemple un blocage pourrait intervenir à cause d'un mutex, un mutex étant une technique utilisée en informatique pour obtenir un accès exclusif à des ressources partagées, le composant producteur peut donc toujours produire des données même si un composant consommateur utilise la donnée produite ; - il est possible de calculer un nombre global de buffer pour tous les consommateurs et pour le producteur dans tout le système afin d'éviter des mécanismes d'allocation dynamique de mémoire dont les temps de réalisation ne sont pas toujours déterministes. Une description des coopérations entre composants peut être réalisée via un outil de description de coopérations. L'outil de description des coopérations entre composants du système, génère un fichier XML, pouvant être nommé contrat de composant. Un contrat de composant permet notamment de définir les relations, existants entre différents type de composants dans un système. Un contrat de composant peut par exemple être défini par : - un identifiant long de type de composant ; - un identifiant court de type de composant ; - éventuellement un type de composant système : par exemple superviseur, horloge système ; - une classe définissant par exemple si le composant est actif ou passif ; - un langage de codage du code source du composant. Chaque composant actif est mis en correspondance avec une seule tâche. Un premier composant actif effectue notamment des traitements sur réception d'un réveil par des opérations du type requête ou événement. Le premier composant actif peut requérir un ou plusieurs services d'un deuxième composant passif. Le premier composant actif peut également requérir un ou plusieurs services d'un troisième composant actif associé à une tâche de priorité d'exécution supérieure ou égale à la priorité d'exécution de la tâche associée au premier composant actif. Un quatrième composant passif peut être par exemple un composant réentrant multitâche. La réentrance en informatique est la propension pour une fonction d'un composant à être utilisable simultanément par plusieurs tâches. Le quatrième composant passif peut donc être appelé par plusieurs autres composants de manière simultanée. Le quatrième composant passif fournit notamment des services aux autres composants, qu'ils soient actifs ou passifs.

Dans un contrat de composant peuvent être définies différentes opérations ou coopérations entre composants notamment par : - des types de données échangées ; - éventuellement des attributs de spécialisation d'instance ; - une définition d'opérations : opération sortante ou entrante, avec un descriptif selon leur type : o une opération de type service pouvant être définie par : un identifiant de service, des paramètres d'entrée des paramètres de sortie ; o une opération de type publication de données pouvant être définie par : un nom, des données ; o une opération de type événement pouvant être définie par un signal nommé sans paramètres ; o une opération de type requête ou message, pouvant être définie par un signal identifié par un nom prenant en entrée un ou plusieurs paramètres. Par exemple, un réveil cyclique d'un composant peut être implémenté au moyen d'un événement de type réveil. Tous les types d'interactions possibles entre les composants peuvent donc être décrits à partir des types de coopération de bases définies ci avant. La première étape du procédé selon l'invention est donc une étape de définition de contrats de composants 40 selon l'invention. Cette définition de contrats de composant peut être réalisée grâce à un procédé de définition de contrats bien connu de l'homme du métier. Un outil de description de contrats permet notamment de mettre en oeuvre le procédé de définition de contrat en générant des contrats 40 sous forme de fichiers XML. Par exemple, il est possible d'utiliser des modeleurs UML existants, UML étant un acronyme pour l'expression anglo-saxonne Unified Modeling Language signifiant langage de modélisation unifié. Les modeleur UML existants peuvent être adaptés dans le cadre de la présente invention pour la fourniture d'interfaces telles que représentées sur la figure 2. Avantageusement, la formalisation de toutes les coopérations produites et consommées par un composant, de manière indépendante pour chaque composant, permet de rendre les composants indépendants les uns des autres.

Une deuxième étape du procédé selon l'invention peut être une étape de définition d'un assemblage des composants 40. Le résultat de l'assemblage est notamment un fichier XML d'assemblage 41, ou contrat d'assemblage 41, comportant notamment les informations suivantes : - un identifiant d'assemblage ; - pour chaque type de composant : o le contrat du composant ; o des instances du composant, et pour chaque instance de composant : ^ un ou plusieurs identifiants ; ^ éventuellement des attributs : par exemple des paramètres d'instances. Les paramètres d'instance peuvent être des paramètres permettant une spécialisation d'une instance d'un composant.

Un fichier d'assemblage de composant, appelé aussi contrat d'assemblage, peut en outre comporter une description de liens entre les instances et notamment pour chaque lien : - le type du lien : service, publication de données, événement, requête ; - pour un lien de type service : o au moins un identifiant ; o au moins un composant producteur, ainsi que le nom de l'interface vue du producteur ; o au moins un composant consommateur, ainsi que le nom de l'interface vue du consommateur.

Le fichier d'assemblage XML est notamment généré selon une grammaire préalablement définie. Le fichier d'assemblage XML peut également être généré automatiquement par un procédé d'assemblage de composants, ledit procédé d'assemblage prenant en entrée le ou les fichiers de définition de contrats de composant et les informations d'assemblage des composants citées ci-avant. Une troisième étape du procédé 'selon l'invention peut être une étape de définition d'un déploiement 42 de fichiers exécutables. Les fichiers exécutables mettent en oeuvre des instances de composant telles que définies dans le fichier d'assemblage. Un fichier exécutable peut ainsi mettre en oeuvre une ou plusieurs instances de composants, définies dans le fichier de d'assemblage 41 par exemple. Un fichier exécutable est un fichier contenant un programme écrit en langage machine, directement exécutable par un processeur et permettant de lancer une application. Chaque fichier exécutable, ou plus simplement chaque exécutable, est généré par un compilateur à partir du code fonctionnel d'un composant et de code généré automatiquement par des outils permettant la mise en oeuvre du procédé selon l'invention : notamment du code généré des conteneurs de composants, du code généré pour des tâches exécutables. Un exécutable est donc propre à un langage logiciel utilisé pour coder le composant.

L'étape de définition d'un déploiement permet de produire un fichier de déploiement 42 XML comportant les informations nécessaires au déploiement des exécutables des instances des composants sur les différentes plateforme du système. Le fichier de déploiement 42, ou contrat de déploiement comporte notamment les informations suivantes : - au moins un identifiant de déploiement ; - au moins une plateforme cible. Une plateforme est une ressource de calcul équipée d'un système d'exploitation. Une plateforme peut comprendre un ou plusieurs processeurs de calcul. L'étape de définition d'un déploiement 42 utilise comme données d'entrée les contrats de composants 40 préalablement définis. Une plateforme peut être définie par les caractéristiques suivantes : - au moins un identifiant ; - un identifiant de groupe de ressources ; - un type de production ; - un système d'exploitation ; - un endianisme, c'est-à-dire un ordre d'organisation des octets définissant un entier dans une communication ou dans une mémoire : les deux endianisme possibles sont nommés little-endian et bigendian, expressions anglo-saxonnes pouvant se traduire respectivement par petit boutisme et grand boutisme, qui sont toutefois des termes peu usités ; - une adresse IP : adresse de la plate-forme dans un réseau ; - un premier numéro de socket : début d'une plage de numéros de sockets disponibles pour un calcul des routages entre plates-formes ; - un deuxième numéro de socket : fin de la plage des numéros de sockets disponibles pour le calcul des routages entre plates-formes ; - shmin, shmax : qui représentent respectivement un numéro minimum et numéro maximum de mémoires partagés utilisables pour la définition des files d'événements, des requêtes, des demandes, des retours de services, des partages de données entre tous les composants locaux à une plate-forme. - une priorité d'exécution minimum : c'est-à-dire une valeur minimale de la priorité disponible sur la plate-forme pour le calcul des priorités des tâches temps réel en respectant une hiérarchie des temps de réponses souhaités pour les composants ; - une priorité d'exécution maximum correspondant à une valeur maximale de la priorité disponible sur la plate-forme, ladite priorité des tâches temps réel étant calculé en respect avec des temps de réponses souhaités hiérarchisés ; - au moins une répartition, c'est-à-dire un nom d'un exécutable utilisé pour router des paquets de données via un protocole UDP/IP en provenance des autres plates formes à destination des composants locaux à cette plate forme, lesdits paquets de données contenant des événements, des requêtes, des demandes de service, des réponses de service, des publications de données, UDP-IP étant un acronyme pour l'expression anglo-saxonne User Datagram Protocol, signifiant littéralement protocole de datagramme utilisateur ; - au moins un panneau de mise en oeuvre, c'est-à-dire une adresse IP permettant une communication avec le logiciel de gestion de fonctionnement du système, ledit logiciel permettant de transmettre au système des commandes de démarrage, suspension, relance, arrêt, d'un ou de plusieurs composants ; - au moins un panneau de commande, c'est-à-dire un numéro d'une socket par laquelle sont reçues les commandes du panneau de mise en oeuvre ; - au moins un panneau de réponse, c'est-à-dire un numéro de socket sur lequel sont envoyés des statuts d'exécution relatif à l'état d'exécution par le système des commandes qu'il a reçues ; - au moins un fichier de traces d'exécution défini par un numéro de socket sur laquelle il possible d'envoyer des traces de l'exécution du système pour un débogage du système ; - au moins un affichage défini par un numéro de socket sur laquelle il est possible d'envoyer des informations à afficher provenant des différents composants s'exécutant sur cette plate-forme ; - au moins un identifiant de la plate-forme ; - un ou plusieurs exécutables s'exécutant sur la plate forme. Le ou les exécutables peuvent être définis notamment par : - au moins un nom ; - au moins un identifiant ; - une commande de lancement de l'exécutable ; - une ou plusieurs instances de déploiement des composants associé à cet exécutable.

Chaque instance de déploiement peut notamment être définie par : - au moins un nom ; - une date de fin correspondant à un besoin en termes de classe de temps de réponse ; - au moins un identifiant ; Le contrat de déploiement 42 permet de spécifier des contraintes de temps de réponse des composants instanciés sur chaque plateforme de calcul. Pour chaque instance de composant, une classe de temps de réponse est définie. La classe de temps de réponse d'une instance de composant est associée à une hiérarchie de tâches définie dans chaque exécutables permettent de calculer automatiquement l'interruptibilité, le parallélisme de chacun des composants en fonction de son besoin en terme de classe de temps de réponse. Le parallélisme est l'aptitude d'un composant à s'exécuter sur un ou plusieurs processeurs en parallèle. Ce calcul est réalisé par un outil de génération d'exécutables. Ainsi, dès l'étape de déploiement, il est possible de spécifier une classe de temps de traitement pour chaque composant. La description des contrats de composants, d'assemblage et de déploiement peut être réalisée grâce à un outil de description de coopérations entre composants. L'outil de description de coopérations entre composants peut générer les fichiers XML de description des contrats de composants 40, d'assemblage 41, de déploiement 42.

Une quatrième étape du procédé selon l'invention peut être une étape de vérification de cohérence 43 des contrats d'assemblage 41, des contrats de déploiement 42, et une vérification de cohérence entre les contrats d'assemblage 41 et de déploiement 42. Un outil automatique de vérification syntaxique, lexicale, sémantique peut prendre en entrée les contrats d'assemblage 41 et de déploiement 42, afin de vérifier leur construction. Par exemple l'étape de vérification de cohérence 43 peut comprendre une vérification des coopérations des types de services entre composants pour ne pas conduire à une instabilité du système temps réel.

Une vérification de cohérence s'applique notamment à vérifier qu'un premier composant n'appelle pas de manière synchrone un service qui est rendu par un deuxième composant dont la classe de temps de réponse est supérieure à la classe de temps de réponse du premier composant. En effet si c'est le cas, la tâche exécutable associée au premier composant demandant le service est suspendue en attente de la réponse de la tâche exécutable associée au deuxième composant rendant le service. Dans ce cas, il y a en quelque sorte une inversion de priorité : une tâche associée à un composant dont la classe de temps de réponse est inférieure se met en attente d'une tâche associée à un composant dont la classe de temps de réponse est supérieure. Il se peut donc que le premier composant demandant le service ne puisse plus respecter sa classe de temps de réponse. Une vérification de cohérence peut également être mise en oeuvre entre les contrats d'assemblage 41 et de déploiement 42. Par exemple une telle vérification peut détecter les problèmes suivants : - une inversion de priorité de tâches entre un composant consommateur et un composant fournisseur dans l'exécution de leurs tâches respectives, une telle inversion peut provoquer un blocage du système ; - un appel mutuel ou croisé de services entre deux tâches distinctes de composants attendant l'un de l'autre des résultats, un tel appel mutuel peut également conduire à un blocage du système ; - dans le cas d'une exécution du système sur plusieurs plateformes ou sur une plateforme comportant un processeur mufti-coeur, un appel croisé de deux tâches de composants différents.

Lorsque des erreurs dans la définition des contrats sont détectées, il est nécessaire de générer à nouveau les contrats 40, 41, 42 afin de corriger les erreurs identifiées. Le procédé est donc repris à la première étape. Si aucune erreur de cohérence n'est détectée, alors intervient l'étape suivante du procédé selon l'invention. Avantageusement, une telle quatrième étape permet de détecter au plus tôt des problèmes de conception des composants ou du système dans son ensemble afin de les corriger pendant une phase du cycle de développement pendant laquelle ce type de correction est peu coûteux. En effet, effectuer ce type de correction une fois le système déployé sur un site d'utilisation demande des modifications lourdes au niveau de plusieurs composants qui ne sont pas envisageables une fois le système déployé sur les plates formes. Une cinquième étape du procédé selon l'invention est une étape de calcul d'une mise en correspondance des composants du système avec des tâches s'exécutant en temps réel. La mise en correspondance des composants avec des tâches prend en compte les contrats d'assemblage 44 et de déploiement 45 pour définir une allocation des composants aux tâches d'exécution mises en oeuvre par les processeurs de la plate-forme. L'allocation des composants aux tâches 44 génère un fichier de définition des allocations des composants aux tâches 45. Le fichier d'allocation 45 peut être décrit selon un standard XML. Le calcul d'une mise en correspondance des composants avec des tâches s'effectue en définissant une tâche par classe de temps de réponse et par exécutable, associée à tous les composants ayant la même classe de temps de réponse. La priorité des tâches est calculée de manière globale pour toutes les tâches associées à des exécutables d'une plate-forme en respectant la hiérarchie globale des temps de réponse de tous les composants liés à tous les exécutables de la plate-forme. L'allocation des composants aux tâches s'effectue également en prenant en compte un ordre d'exécution des traitements des composants en fonction des différents appels entre composants et en fonction du temps de réponse de chaque composant. Ainsi l'ordre d'exécution de chaque composant est prédictif. Une sixième étape du procédé selon l'invention est une étape de génération de code 46. L'étape de génération de code 46 peut être réalisée de manière automatique par un outil de génération de code, ou générateur de code, prenant en entrée le fichier de mise en correspondance des composants et des tâches. Le fichier de mise en correspondance est un fichier de calcul intermédiaire de tous les éléments nécessaires à la génération de code logiciel du système et notamment : - identification des noms de tâche ; - des priorités des tâches ; - profondeurs de file de communication ; - numéro des sockets de communication entre plates formes. Le fichier mise en correspondance comporte l'ensemble des données calculées automatiquement. Le fichier de mise en correspondance est exploité pour générer le code du système. Le générateur de code créé ainsi tous les types de données nécessaires à chaque composant ainsi que les conteneurs de chaque composant à partir des contrats de composants 40, d'assemblage 41, de déploiement 42 et de mise en correspondance des composants avec les tâches. Le générateur de code produit également un code logiciel pour les tâches exécutables correspondant aux composants et aux conteneurs. La classe de temps de traitement définie dans le fichier de déploiement 42 est prise en compte par les outils de génération de code. Le conteneur est un intergiciel, généré automatiquement, encapsulant un composant vis à vis du système et des autres composants. Chaque composant 8 ne connaît donc que son propre conteneur 7. Ainsi chaque composant peut être développé en faisant abstraction des connexions réelles, existant dans le système avec les autres composants. Le composant interagit donc avec le système par l'intermédiaire de son conteneur.

Avantageusement, l'encapsulation des composants dans des conteneurs permet de faire cohabiter entre eux des composants : - s'exécutant sur des types de plateforme différents : comme un ordinateur personnel, une station de travail ; - utilisant des langages de codage différents; - s'exécutant sur des plateformes utilisant des systèmes d'exploitation différents. Avantageusement, les conteneurs s'appuient sur un intergiciel générique simple qui comporte : - des interfaces génériques permettant des gestions de tâches, gestions d'événements, gestions de canaux de communication, gestion du temps, pour tous les systèmes d'exploitation des plateformes cibles ; - des mécanismes généraux de réalisation de versions des données partagées entre composants ; - des mécanismes généraux de gestion de files de demandes, c'est à dire des opérations entre composants de type événements, requêtes, demandes de service ou retours de service, entre les tâches ; - des mécanismes généraux de sérialisation, de dé-sérialisation en fonction de l'endianisme des paramètres des opérations s'effectuant entre les composants, une sérialisation étant une opération d'encodage d'une information qui est en mémoire sous la forme d'une suite d'octets ou de bits, une dé-sérialisation étant l'opération inverse. Avantageusement, les interfaces entre le système et le composant sont donc stables : le support des cas d'erreurs générés par les composants, c'est à dire leur prise en compte et leur traitement est traité au niveau du conteneur. Une septième étape du procédé selon l'invention est une étape de compilation en vue de générer des exécutables associés aux différents composants. Une production de fichiers exécutables s'effectue notamment par assemblage de code des tâches exécutables, du code des conteneurs, du code des composants. Le code des composants comportant une partie de code généré automatiquement et une partie de code purement fonctionnel et produit manuellement. Les exécutables générés, sont ensuite déployés sur les différents processeurs 49 équipant une ou plusieurs plateformes 48 en fonction du fichier de déploiement 42. Les exécutables peuvent ainsi être mis en oeuvre par les différents processeurs 49. Différentes tâches exécutables sont définies pour le conteneur 7 de chaque composant 8. L'exécutable associé au conteneur 7 gère lui-même les tâches exécutables qui lui sont affectées. L'exécutable du conteneur 7 fait donc appel à des services et des fonctions du composant 8. Ainsi, il est possible de rendre un temps entre deux exécutions de tâches indépendant de la taille des données traitées par les deux tâches, en utilisant par exemple un pointeur de description pour chaque tâche. Différentes qualités de service peuvent par exemple être prises en compte dans le code du conteneur, ce dernier pouvant fournir des mécanismes présentant par exemple une bonne interruptibilité. L'étape de compilation effectue une traduction du code généré en langage binaire propre à la plate forme cible. Avantageusement, le procédé selon l'invention permet de formaliser la prise en compte de critères de qualité puis de la propager au fil des phases de conception, de développement, et de mise en oeuvre des exécutables propres aux composants des différents systèmes. Avantageusement, le procédé selon l'invention permet une instanciation automatique des composants logiciels dans des tâches respectant une contrainte d'exécution temps réel, tout en respectant une hiérarchie compatible avec des contraintes de temps de réponse exprimées dans le contrat de déploiement 42 des composants. Avantageusement, les appels aux systèmes d'exploitation des différentes plateformes sont pris en compte par les conteneurs des composants. Les appels aux systèmes d'exploitation des différentes plateformes sont réalisés par les exécutables mettant en oeuvre les tâches liées aux conteneurs. Ainsi les composants sont indépendants du système d'exploitation des plateformes sur lesquels ils sont déployés. Avantageusement, le procédé selon l'invention permet de dimensionner automatiquement la taille des files d'échange de données de façon à ce qu'elles soient compatibles avec les différents besoins des composants. Par exemple, la taille des paramètres de toutes les opérations peut être calculée, ainsi que le nombre maximal d'opérations possibles en attente entre les différents composants, en transformant par exemple les classe de temps de réponse de chaque composant en pseudo fréquence et en faisant des rapports des pseudo-fréquences pour trouver des nombres maximaux d'opérations en attente.

La figure 5 représente un exemple d'un procédé d'évaluation d'un système complexe selon l'invention. Le procédé d'évaluation du système utilise notamment les étapes suivantes du procédé de déploiement selon l'invention : - la première étape de description de chaque composant du système par la définition d'un contrat propre à chaque composant 40 du système ; - la deuxième étape de définition d'un assemblage 41 des composants ; - la troisième étape de définition d'un déploiement 42 ; - la cinquième étape de calcul de mise en correspondance des composants du système avec des tâches temps réelles 43, générant le fichier d'allocation 45 ; Les contrats de composants 40 peuvent être enrichis d'une formalisation simplifiée des traitements des composants suivant un langage formel, en fonction d'opérations ou de stimuli que le composant reçoit en entrée. Un exemple d'une formalisation simplifiée peut être de décrire une consommation en termes de complexité algorithmique, des traitements réalisés par le composant, mixée avec des demandes d'opérations fournies en sortie du composant. Par exemple, un ou plusieurs comportements peuvent être définis dans un contrat de composant à l'aide des paramètres suivants : - au moins un identifiant de comportement ; - un mode de fonctionnement concerné, par exemple : mode nominale, mode dégradé, mode maintenance, le mode permettant de définir un comportement différent du composant en fonction de chaque mode, une vérification du respect des temps de réponse étant réalisée pour tous les modes de tous les composants ; - un ou plusieurs stimulus déclenchant des traitements dans le composant, les événements pouvant être de type : événement, requête, demande de service ; - pour chaque stimulus, une description simplifiée des traitements mis en oeuvre par le composant comprenant une ou plusieurs des opérations suivantes : o une opération définie avec une durée d'exécution ; o un calcul défini par une complexité maximale ; o une réservation/libération d'un accès de données ; o un appel de service ; o une émission d'événement ; o une transmission de requête ; o une ou plusieurs itérations imbriquées sur un calcul, une réservation libération d'un accès de données, un appel de service, une émission d'événement, une transmission de requête.

Chaque opération en entrée de chaque composant du système complexe peut alors être associée à un descriptif de comportement du composant. Le descriptif du comportement est une modélisation du comportement du composant en termes de puissance de calcul nécessaire à la réalisation de chaque opération. Un exemple de description d'un comportement est présenté en annexe 1, selon un formalisme XML. Une huitième étape du procédé d'évaluation peut être une étape de définition d'un scénario d'exécution des modélisations des composants permettant une analyse de performance du système 50. Un scénario d'analyse de performance 50 peut par exemple comporter les paramètres suivants définis par exemple selon un format XSD prédéfini : - un identifiant de scénario ; - un mode de fonctionnement pour chaque instance des composants, par exemple mode nominal, dégradé, arrêté ; - une modélisation d'un bruit de fond par une série d'opérations, chaque opération ayant une période d'activation pendant laquelle elle va utiliser des ressources de la plateforme ; - une ou plusieurs chaines fonctionnelles qui représentent des enchainements de stimuli à destination des composants. Avantageusement, la modélisation d'un bruit de fond au niveau des traitements permet de modéliser des traitements réalisés de manière cyclique par le système, sans interruption. Un exemple d'un fichier xml de description d'un scénario d'analyse de 25 performances est donné à titre d'exemple dans l'annexe 2. Une neuvième étape du procédé d'évaluation peut être une étape d'exécution virtuelle du scénario d'exécution par l'utilisation d'un outil de calcul de comportements des plates formes et des composants sur ces plates formes en utilisant un modèle simplifié de plate-forme. Le modèle 30 simplifié de plate forme a notamment la capacité de prendre en compte la complexité par seconde ainsi que les scenarios et les comportements élémentaires de chaque composant sur chaque stimulus. L'outil de calcul de comportements garantit un fonctionnement identique entre le modèle et le logiciel opérationnel du système. En effet, un modèle d'ordonnancement des 35 tâches est utilisé en entrée de l'outil de calcul de comportement et sur les plates formes réelles est le même. Un descriptif des comportement de composants pour chaque stimulus, complété par le modèle simple exprimé en complexité par seconde pour représenter la puissance de calcul requise par les composants est suffisant pour savoir calculer des temps d'exécutions maximaux, ou WCET acronyme pour l'expression anglo-saxonne Worst Case Execution Time, des différentes chaines fonctionnelles ainsi que le taux d'utilisation des processeurs des différentes plates formes pour les différents scenarios. L'outillage permet grâce à un moteur de calcul de prévoir une animation des composants du système, dans le contexte défini par le scénario 50. Ainsi la plateforme de simulation peut fournir en sortie des analyses temporelles des traitements réalisés par le système 52. Notamment, la plateforme de simulation peut fournir un diagramme de Gantt d'un enchainement des traitements réalisés par les différents composants dans le temps, une estimation des puissances de calcul utilisées en fonction du temps par le système, un diagramme des temps de réponse de chaînes fonctionnelles. Ainsi les résultats suivants peuvent par exemple être affichés sur moyen de visualisation - une puissance de calcul globale consommée sur les plateformes de 20 calcul ; - une répartition de la puissance de calcul consommée en fonction des différents composants ; - une répartition de la puissance de calcul consommée en fonction des exécutables qui hébergent les composants ; 25 - un temps de réponse pour les différentes chaînes de calcul ; - un diagramme de Gantt représentant une activation des différents composants dans le temps. Avantageusement, le procédé d'évaluation du système permet un dimensionnement des ressources, une optimisation des composants tout au 30 long du développement des composants et du système. Ainsi en fonction des résultats obtenu par le procédé d'évaluation, les contrats de composant, d'assemblage et de déploiement peuvent être modifiés afin d'améliorer les performances du système. Avantageusement, une telle évaluation peut être effectuée alors même que les composants ne sont pas encore développés, une modélisation de leur comportement en temps de traitement selon les ressources disponibles étant suffisant pour évaluer le système.

La présente invention s'applique notamment au domaine des 5 systèmes temps réels embarqués, comme des calculateurs de vol embarqués à bord d'aéronefs.

ANNEXES Annexe 1: Exemple d'un fichier de définition d'un scénario opérationnel d'évaluation d'un comportement <behaviour name="Comportement1" mode="operationnel"> <onevent name="New_Objectif_List" /> - <block> <getaccessdata name="Objectif_List" /> <getaccessdata name="Sorted_Objectif_List" /> - <loop max="3"> <compute maxcomplexity="1" /> <requestsend name="Delete_Objectif' /> </Ioop> <compute maxcomplexity="5" /> <servicecall name="Distance3D2D" /> <compute maxcomplexity="5" /> <servicecall name="sgrt" /> <compute maxcomplexity="2" /> <freeaccessdata name="Objectif_List" /> <freeaccessdata name="Sorted_Objectif_List" /> <eventemit name="New_Sorted_Objectif_List" /> </block>- <block> <compute maxcomplexity="5" /> </block> </behaviour> Annexe 2: Exemple d'un fichier de définition d'un scénario opérationnel d'évaluation de performances 35 <performanceanalysis> 15 20 25 30 <scenario name="nominal">

<instancemode instancename="SORT" mode="operationnel" /> <instancemode instancename="DISPLAY" mode="operationnel" />

<operationperiod period="100" operationid="1014" /> <operationperiod period="500" operationid="1013" /> <operationperiod period="700" operationid="1019" /> - <functionaichain name="chainel" maxtime="160" operationid="1013"> <step componentname="STIMU" operationid="1012" /> <step componentname="ACQUIRE" operationid="1010" /> <step componentname="MANAGE" operationid="1006" /> <step componentname="SORT" operationid="1008" /> <step componentname="DISPLAY" operationid="0" /> </functionalchain>

</scenario> </performanceanalysis> 25

Claims (12)

1. REVENDICATIONS1. Procédé de déploiement de composants d'un système complexe sur au moins une plateforme comportant un ou plusieurs processeurs, caractérisé 5 en ce qu'il comporte au moins les étapes suivantes : - génération d'un fichier de description d'un composant pour chaque composant du système complexe, ledit fichier comportant une description des opérations et données, entrants et sortants du composant ; 10 - génération d'un fichier de description d'un assemblage des composants pour former le système complexe ; - génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; 15 - génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - génération de code logiciel de conteneurs des composants, chaque 20 composant étant encapsulé par un conteneur, ledit conteneur comportant l'ensemble des interfaces entres le composant et le système complexe et entre le composant et les autres composants, à partir du fichier de mise en correspondance des composants avec des tâches exécutables ; 25 - génération de code logiciel des tâches exécutables correspondant aux composants et aux conteneurs ; - production des exécutables par assemblage du code des tâches exécutables, du code des conteneurs des composants et du code des composants associés à chaque exécutable ; 30 - mise en oeuvre des exécutables sur les processeurs des plateformes en fonction du fichier de mise en correspondance.
2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape de vérification syntaxique et sémantique des fichiers de description 31des composants, des fichiers de description de l'assemblage, des fichiers de description du déploiement.
3. 3. Procédé selon l'une quelconque des revendications précédentes, 5 caractérisé en ce qu'il comporte une étape de vérification de cohérence entre les fichiers de description des composants, de l'assemblage, du déploiement.
4. 4. Procédé selon les revendications 2 et 3, caractérisé en ce qu'il comporte une étape de modification des fichiers de description des composants, de 10 l'assemblage, du déploiement, lorsqu'une erreur de cohérence des fichiers est détectée au cours de l'étape de vérification de cohérence ou au cours de l'étape de vérification syntaxique et sémantiques des fichiers précités.
5. 5. Procédé selon l'une quelconque des revendications précédentes, 15 caractérisé en ce que les fichiers générés suivent une grammaire prédéfinie.
6. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les fichiers sont générés au format xml, acronyme pour l'expression anglo-saxonne Extensible Markup Language signifiant 20 littéralement langage extensible de balisage.
7. 7. Procédé selon la revendication 6, caractérisé en ce que les fichiers xml sont générés selon un modèle xsd, acronyme pour l'expression anglo-saxonne xml Schema Description, signifiant schéma xml de description. 25
8. 8. Dispositif de déploiement de composants d'un système complexe sur au moins une plateforme comportant un ou plusieurs processeurs, caractérisé en ce qu'il comporte : - un moyen de génération d'un fichier de description d'un composant 30 pour chaque composant du système complexe, ledit fichier comportant une description des opérations et données, entrants et sortants du composant ; - un moyen de génération d'un fichier de description d'un assemblage des composants pour former le système complexe ; 32- un moyen de génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; - un moyen de génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - un moyen de génération de code logiciel de conteneurs des composants, chaque composant étant encapsulé par un conteneur, ledit conteneur comportant l'ensemble des interfaces entres le composant et le système complexe et entre le composant et les autres composants, à partir du fichier de mise en correspondance des composants avec des tâches exécutables ; - un moyen de génération des tâches exécutables correspondant aux composants et aux conteneurs ; - un moyen de production des exécutables par assemblage du code des tâches exécutables, du code des conteneurs des composants et du code des composants associés à chaque exécutable ; - un moyen de mise en oeuvre des exécutables sur les processeurs des plateformes en fonction du fichier de mise en correspondance.
9. 9. Dispositif selon la revendication 8, caractérisé en ce qu'il comporte en outre un moyen de vérification syntaxique et sémantique des fichiers de 25 description des composants, du fichier de description de l'assemblage, du fichier de description du déploiement.
10. 10. Dispositif selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu'il comporte un moyen de vérification de cohérence entre les fichiers 30 de description des composants, de l'assemblage, du déploiement.
11. 11. Procédé d'évaluation de performances d'un déploiement de composants d'un système complexe sur au moins une plateforme comportant un ou plusieurs processeurs, caractérisé en ce qu'il comporte au moins les étapes 35 suivantes : 33- génération d'un fichier de description d'un composant pour chaque composant du système complexe, ledit fichier comportant une description des opérations et données, entrants et sortants du composant, ledit fichier décrivant une modélisation du fonctionnement du composant en terme de temps de traitement ; - génération d'un fichier de description d'un assemblage des composants pour former le système complexe ; - génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; - génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - génération d'un fichier de description d'un scénario d'exécution d'une simulation du système complexe, mettant en oeuvre les modélisations des composants; - exécution virtuelle du scénario et analyse temporelle des traitements réalisés par les composants modélisés ; - prise en compte de l'analyse dans la description des composants, de l'assemblage des composants, du déploiement des composants du système complexe.
12. 12. Dispositif d'évaluation de performances d'un déploiement de composants 25 d'un système complexe sur une plateforme comportant plusieurs processeurs, caractérisé en ce qu'il comporte : - un moyen de génération d'un fichier de description d'un composant pour chaque composant du système complexe, ledit fichier comportant une description des opérations et données, entrants et 30 sortants du composant, ledit fichier décrivant une modélisation du fonctionnement du composant en terme de temps de traitement ; - un moyen de génération d'un fichier de description d'un assemblage des composants pour former le système complexe ; 34- un moyen de génération d'un fichier de description d'un déploiement des exécutables correspondants aux composants sur les processeurs des plateformes ; - un moyen de génération d'un fichier de mise en correspondance des composants avec des tâches exécutables, chaque tâche correspondant à au moins un composant, à partir des fichiers de description des composants, de description de l'assemblage, de description du déploiement ; - un moyen de génération d'un fichier de description d'un scénario 10 d'exécution d'une simulation du système complexe, mettant en oeuvre les modélisations des composants ; - un moyen d'exécution virtuelle du scénario et d'analyse temporelle des traitements réalisés par les composants modélisés. 15 35