FR2911976A1 - Procede de conception d'un systeme comprenant des composants materiels et logiciels - Google Patents
Procede de conception d'un systeme comprenant des composants materiels et logiciels Download PDFInfo
- Publication number
- FR2911976A1 FR2911976A1 FR0800466A FR0800466A FR2911976A1 FR 2911976 A1 FR2911976 A1 FR 2911976A1 FR 0800466 A FR0800466 A FR 0800466A FR 0800466 A FR0800466 A FR 0800466A FR 2911976 A1 FR2911976 A1 FR 2911976A1
- Authority
- FR
- France
- Prior art keywords
- functional
- architecture
- model
- requirement
- functional requirement
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 25
- 238000000354 decomposition reaction Methods 0.000 claims abstract description 12
- 238000013461 design Methods 0.000 claims description 21
- 238000010200 validation analysis Methods 0.000 claims description 20
- 238000011144 upstream manufacturing Methods 0.000 claims description 14
- 238000004364 calculation method Methods 0.000 claims description 11
- 238000005192 partition Methods 0.000 claims description 9
- 238000011282 treatment Methods 0.000 claims description 9
- 238000010230 functional analysis Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 6
- 230000008569 process Effects 0.000 claims description 5
- 230000010354 integration Effects 0.000 claims description 2
- 238000004891 communication Methods 0.000 description 7
- 238000004088 simulation Methods 0.000 description 7
- 230000004913 activation Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 230000018109 developmental process Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 101100189060 Arabidopsis thaliana PROC1 gene Proteins 0.000 description 1
- 101001053641 Homo sapiens Plasma serine protease inhibitor Proteins 0.000 description 1
- 102100032341 PCNA-interacting partner Human genes 0.000 description 1
- 101710196737 PCNA-interacting partner Proteins 0.000 description 1
- 102100024078 Plasma serine protease inhibitor Human genes 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3457—Performance evaluation by simulation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
L'invention concerne un procédé de conception d'un système, ledit système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application, ledit système devant répondre à au moins une exigence fonctionnelle et non fonctionnelle, comportant les étapes suivantes :- une étape d'analyse fonctionnelle (11), permettant d'obtenir une décomposition du besoin fonctionnel relatif à ladite application,- une étape de définition de l'architecture (12),- une étape de conception de composants matériels (13) selon ladite architecture,- une étape de conception de composants logiciels (14) à partir de la décomposition du besoin fonctionnel,- une étape d'intégration des composants logiciels aux composants matériels (15),- une étape de validation de l'exigence fonctionnelle dudit système (16),- une étape de validation de l'exigence non fonctionnelle dudit système (17),caractérisé en ce qu'il comporte, en outre, une étape de validation amont (21) de l'exigence non fonctionnelle dudit système, précédant les étapes de conception de composants matériels (13) et de composants logiciels (14).
Description
Procédé de conception d'un système comprenant des composants matériels et
logiciels La présente invention est relative à l'ingénierie système et logicielle, et plus particulièrement à la validation amont des exigences non fonctionnelles d'un système.
Le développement de systèmes complexes nécessite différentes étapes de résolution de problèmes et de conception incrémentales. L'objectif est de construire une solution répondant aux exigences du client. On distingue généralement deux types d'exigences : les exigences fonctionnelles et non fonctionnelles. Les exigences fonctionnelles sont relatives aux fonctionnalités que doit remplir le système. Les exigences non fonctionnelles concernent les paramètres du système tels que la performance, la sûreté de fonctionnement, l'intégrité et la disponibilité. Le cycle en V est une méthode classique de développement de système définissant une succession d'étapes allant de la définition du système jusqu'à sa validation. Un cycle en V, tel qu'illustré à la figure 1, appliqué à la conception d'un système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application comporte les étapes suivantes.
L'étape d'analyse fonctionnelle 11, permet d'obtenir une décomposition du besoin fonctionnel relatif à ladite application. La définition de l'architecture 12 définit les briques de base du système, leur agencement et la façon dont celle-ci sont coordonnées. Les deux étapes suivantes consistent à concevoir les composants matériels 13 définis par ladite architecture et les composants logiciels 14 à partir de la décomposition du besoin fonctionnel. L'intégration des composants logiciels aux composants matériels 15 consiste à assembler l'ensemble des composants élémentaires élaborés aux étapes précédentes pour former le système. L'étape suivante est la validation des exigences fonctionnelles 16. L'étape de validation des exigences non fonctionnelles 17 intervient à la fin du cycle de développement. Ce type de méthode de développement ne donne pas entière satisfaction parce qu'il n'existe pas de moyen de garantir dès les phases d'analyse et de conception du système que celuici réponde de manière prédictible aux exigences non fonctionnelles. Les constats sur ce type d'exigences sont faits lors de la phase de validation du système avec des risques et bien souvent des coûts de modifications plus ou moins lourds sur le produit. Une solution consiste à utiliser la simulation fonctionnelle. On procède alors, dès la phase de conception du système, à l'évaluation des caractéristiques non fonctionnelles du système grâce à la mise en oeuvre d'un modèle décrivant simultanément l'application et son implémentation sur 1 o une plate-forme d'exécution. Cependant, le modèle de simulation nécessaire peut s'avérer très pointu et très coûteux à développer. Une telle solution n'est pas viable économiquement lorsqu'elle est mise en oeuvre sur un système complexe.
15 L'invention vise à pallier les problèmes cités précédemment en modifiant la méthode d'analyse et de conception du système et en introduisant une étape supplémentaire de validation amont des exigences non fonctionnelles permettant de pré-valider la bonne conception du système en capitalisant sur des règles d'architectures. En utilisant l'invention, on peut 20 prouver dès les premières phases du cycle de développement que la conception du système est correcte au regard des exigences non fonctionnelles. L'invention permet donc d'optimiser les coûts de conception des systèmes par la détection au plus tôt des erreurs sur les exigences non fonctionnelles et par la capitalisation des règles d'architecture. 25 A cet effet, l'invention a pour objet un procédé de conception d'un système, ledit système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application, ledit système devant 30 répondre à au moins une exigence fonctionnelle et une exigence non fonctionnelle, comportant les étapes suivantes : une étape d'analyse fonctionnelle, permettant d'obtenir une décomposition du besoin fonctionnel relatif à ladite application, une étape de définition de l'architecture, une étape de conception de composants matériels selon ladite architecture, une étape de conception de composants logiciels à partir de l'analyse fonctionnelle, une étape d'intégration des composants logiciels aux composants matériels, une étape de validation de l'exigence fonctionnelle dudit système, une étape de validation de l'exigence non fonctionnelle dudit 1 o système, caractérisé en ce qu'il comporte, en outre, une étape de validation amont de l'exigence non fonctionnelle dudit système, précédant les étapes de conception des composants matériels et des composants logiciels.
15 Avantageusement, l'étape de validation amont de l'exigence non fonctionnelle comporte les étapes suivantes : la modélisation du besoin fonctionnel à partir de ladite décomposition hiérarchique, la modélisation de l'architecture selon des règles d'architecture 20 prédéfinies, l'allocation du modèle du besoin fonctionnel sur le modèle de l'architecture, permettant d'obtenir un modèle fonctionnel alloué sur le modèle d'architecture, le calcul d'au moins un paramètre non fonctionnel à partir du 25 modèle fonctionnel alloué sur le modèle d'architecture, la comparaison du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, si l'exigence non fonctionnelle est respectée, la conception des composants matériels et composants logiciels, 30 si l'exigence non fonctionnelle n'est pas respectée, la définition d'une nouvelle architecture ou la recherche d'une nouvelle allocation du modèle du besoin fonctionnel sur le modèle de l'architecture.
Avantageusement, le paramètre non fonctionnel calculé concerne la performance du système et comprend au moins un des éléments suivants : la charge de calcul d'un processeur, la consommation de bande passante d'un réseau, le volume mémoire consommé d'un processeur, le temps de traversé du système.
Avantageusement, le paramètre non fonctionnel calculé concerne la sûreté de fonctionnement du système et comprend notamment l'application de jeux d'entrées provoquant des événements particuliers. Avantageusement, le paramètre non fonctionnel calculé concerne l'intégrité du système. Avantageusement, le paramètre non fonctionnel calculé concerne 15 la disponibilité du système et comprend notamment le taux de disponibilité de l'architecture. Avantageusement, ledit système est une plate-forme d'exécution et ladite étape de validation amont des exigences non fonctionnelles 20 comporte les étapes suivantes : la modélisation du besoin fonctionnel avec des chaînes fonctionnelles, lesdites chaînes fonctionnelles étant constituées alternativement de traitements et d'échanges, la modélisation de l'architecture avec un groupe de noeuds de 25 calcul reliés par des bus, chacun desdits noeuds de calcul comprenant des partitions, lesdites partitions étant subdivisées en tâches, l'allocation desdits traitements auxdites tâches, permettant d'obtenir un modèle fonctionnel alloué sur le modèle 30 d'architecture, le calcul d'au moins un paramètre non fonctionnel à partir du modèle fonctionnel alloué sur le modèle d'architecture, la comparaison du paramètre fonctionnel calculé avec l'exigence non fonctionnelle,10 si l'exigence non fonctionnelle est respectée, la conception des composants matériels et logiciels, si l'exigence non fonctionnelle n'est pas respectée, la définition d'une nouvelle architecture ou la recherche d'une nouvelle 5 allocation des traitements aux tâches.
L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée et à l'aide des figures parmi lesquelles : ~o La figure 1 représente un procédé de conception d'un système selon l'art connu. La figure 2 représente un procédé de conception d'un système selon l'invention. La figure 3 représente les sous-étapes constituant l'étape de 15 validation amont des exigences non fonctionnelles. La figure 4 correspond aux sous-étapes de la figure 3 appliquées à un niveau plate forme d'exécution. La figure 5 représente un exemple de chaîne fonctionnelle.
20 Le procédé selon l'invention, illustré sur la figure 2, consiste à modifier la méthode d'analyse et de conception du système et à introduire une étape supplémentaire de validation amont 21 des exigences non fonctionnelles permettant de pré-valider la bonne conception du système en capitalisant sur des règles d'architectures. 25 La figure 3 représente les sous-étapes constituant l'étape de validation amont 21 des exigences non fonctionnelles. Lors de cette étape de validation amont 21, l'allocation 33 des besoins fonctionnels sur l'architecture est réalisée. Les règles d'architecture 35 paramétrées par les technologies employées 37 permettent de calculer la valeur des paramètres non 30 fonctionnels du système. Cela rend possible alors la vérification 38 de l'adéquation des paramètres fonctionnels calculés avec des valeurs attendues (i.e. les exigences). En cas d'écart, une remise en cause, soit des technologies employées, soit de l'allocation du besoin fonctionnel sur l'architecture permet dès cette phase de modifier la conception du système.
L'étape de validation amont des exigences non fonctionnelles comporte les étapes suivantes : la modélisation 31 du besoin fonctionnel à partir de ladite décomposition hiérarchique 36, la modélisation 32 de l'architecture 37 selon des règles d'architecture prédéfinies 35, l'allocation 33 du modèle du besoin fonctionnel sur le modèle de l'architecture, permettant d'obtenir un modèle fonctionnel alloué sur le modèle d'architecture, le calcul 34 d'au moins un paramètre non fonctionnel à partir du modèle fonctionnel alloué sur le modèle d'architecture. la comparaison 38 du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, si l'exigence non fonctionnelle est respectée, la conception des composants matériels 13 et composants logiciels 14, si l'exigence non fonctionnelle n'est pas respectée, la définition 12 d'une nouvelle architecture ou la recherche d'une nouvelle allocation 33 du modèle du besoin fonctionnel sur le modèle de l'architecture.
Le modèle fonctionnel est une représentation simplifiée d'une fonctionnalité comprenant simplement quelques caractéristiques de la fonctionnalité telles que la complexité, les données en entrée et en sortie (mais pas les algorithmes détaillés qui permettent de produire les sorties à partir des entrées). Ce modèle fonctionnel est différent des modèles fonctionnels de simulation qui décrivent la fonctionnalité elle-même de façon très précise. Les modèles de simulations explicitent le lien logique entre les données d'entrée de la fonctionnalité et ses données de sorties. Ce n'est pas le cas du modèle fonctionnel selon l'invention.
L'architecture du système est conçue selon un style architectural qui est une loi auto-imposée définissant le comportement des briques de base du système ainsi que la manière dont elles coopèrent. Un des éléments clé du procédé selon l'invention est la formalisation du style architecturale par des lois régissant les paramètres non fonctionnels d'une architecture conçue selon ledit style. L'établissement des ces lois nécessite une connaissance préalable de l'architecture ainsi modélisée ou d'une architecture de référence similaire. Il est nécessaire d'avoir au moins une loi par paramètre non fonctionnel que l'on souhaite calculer : la performance la testabilité, c'est à dire la facilité à localiser les pannes et à tracer les exigences, l'intégrité, la disponibilité. L'ensemble de ces lois est appelé règles d'architecture.
Les briques de base du système sont associées à une loi régissant un paramètre non fonctionnel. Le modèle de l'architecture selon l'invention est différent des modèles d'architecture de simulation. Les modèles de simulations spécifient précisément le comportement d'un composant. Ce n'est pas le cas du modèle fonctionnel selon l'invention où seules les lois régissant des paramètres non fonctionnels sont prises en compte. Le calcul du paramètre non fonctionnel est réalisé à partir des caractéristiques synthétiques du modèle fonctionnel et des lois régissant le paramètre non fonctionnel associé à un composant de l'architecture. Ce calcul est différent d'une simulation qui génère, à partir de scénarios d'exécution, une exécution d'un modèle d'une application logicielle sur une architecture matérielle. Le calcul selon l'invention ne nécessite pas de scénario d'exécution. Généralement, on décompose un système en différents niveaux qui correspondent au niveau de détail qu'on apporte à la description des composants du système. Le premier niveau décrit l'agencement du système en sous-système. Le second niveau décrit le regroupement de plate-formes d'exécution en sous-systèmes. Le troisième niveau décrit comment les plate-formes d'exécution sont constituées de plate-formes informatiques. Le dernier niveau concerne les plate-formes informatiques constituées de carte et de modules électroniques. Le procédé selon l'invention peut s'appliquer à tous les niveaux de la conception d'un système. Par exemple, à un niveau plate-forme d'exécution, il existe des lois décrivant la charge de calcul d'un processeur, le taux d'occupation d'un 35 bus ou le temps de réponse d'une fonction.
Dans l'exemple décrit ci-après, donné à titre non limitatif, le procédé selon l'invention est appliqué au niveau d'une plate-forme d'exécution. L'étape de validation amont des exigences non fonctionnelles, 5 illustrée par la figure 4, comporte alors les étapes suivantes. La modélisation 41 du besoin fonctionnel est réalisée par l'identification de chaînes fonctionnelles' à partir d'une décomposition fonctionnelle 46. La décomposition fonctionnelle est obtenue lors de la phase d'analyse fonctionnelle par raffinement progressif des comportements io fonctionnels et par l'identification des traitements élémentaires contribuant à la réalisation de la fonction. On suppose que l'analyse fonctionnelle a permis d'identifer une décomposition fonctionnelle comprenant quatre fonctionnalités élémentaires F1, F2, F3 et F4. La modélisation du besoin fonctionnel consiste alors à associer à chacune des fonctionnalités élémentaires un traitement, à 15 définir un ordre sur les traitements ainsi définis et à relier les traitements par des échanges. L'ensemble formé par la succession des traitements et des échanges est appelé chaîne fonctionnelle. La figure 5 illustre la chaîne fonctionnelle obtenue à l'issue de la phase de modélisation. Elle comprend quatre traitements T1, T2, T3 et T4 51 20 et des échanges 52. Un traitement 51 comprend : une complexité, une loi d'activation et des modes. La complexité d'un traitement est définie par rapport à un étalon, par exemple un benchmark de référence tel que dhrystone ou whetstone. Dans le domaine aéronautique, on peut utiliser des benchmark plus spécifiques tels que MIPS-AIR 25 Une exigence non fonctionnelle telle qu'une exigence de temps de réponse se traduit par une valeur de temps de traversée d'une chaîne fonctionnelle. Dans cet exemple, on cherche à satisfaire l'exigence suivante : la chaîne fonctionnelle définie par les traitements et les échanges précédents 30 doit être traversée en 100 millisecondes.
La modélisation 42 de l'architecture 47 est réalisée avec des processeurs reliés par des bus, chacun desdits processeurs est divisé en partitions temporelles. Les partitions temporelles sont utilisées pour répartir 35 les temps d'exécution des applications sur les processeurs. On peut, par exemple, imposer qu'un processeur exécute une première application la moitié de son temps et une seconde application l'autre moitié de son temps. Les partitions temporelles sont subdivisées en tâches de calcul. La modélisation de l'architecture est réalisée avec des règles d'architecture. A ce niveau, les règles d'architecture définissent le nombre et la taille des tâches dans chacune des partitions. Dans notre exemple nous utilisons une architecture 47 comprenant un processeur Proc, disposant d'une partition temporelle Par,, subdivisée en 6 tâches de calcul : A,, A2, A3, A4, A5 et A6. Ces tâches sont 10 définies de la façon suivante : La tâche A, est la tâche de priorité maximale et est activée cycliquement à 50 Hz. Les tâches A2, A3, A4, sont harmoniques en fréquence et en puissance de 2 de la tâche A, et de priorité décroissante 15 respective 25Hz, 12.5 Hz et 6.25 Hz. Les tâches A5 et A6 sont des tâches activées à la demande du logiciel hébergé par l'architecture et ont, pour A5, une priorité comprise entre A, et A2 et, pour A6, une priorité inférieure à A4
20 On définit deux règles d'architectures 45 s'appliquant à l'architecture définie précédemment. La première règle d'architecture impose que les communications entre les tâches sont telles que la latence maximale d'une communication entre deux tâches est égale à la période de la tâche périodique de priorité 25 supérieure ou égale à la tâche destination sauf pour les enchaînements de tâches aléatoires où l'on ne compte qu'une fois cette latence. La deuxième règle d'architecture impose que les temps de calcul sont masqués par les latences de communications si les tâches ne débordent pas de cycle de calcul. 30 L'étape suivante consiste à allouer 43 les traitements aux tâches pour obtenir un modèle fonctionnel alloué sur le modèle d'architecture. II existe de nombreuses allocations possibles. Le choix d'une allocation influence les paramètres non fonctionnels du système. 35 Une première allocation est décrite par le tableau ci-après. PROC1 PARI Al A2 A3 A4 A5 A6 complexité TI 2 x T2 1 x T3 3 x T4 1 x La première allocation consiste à exécuter TI sur A3, T2 sur A2, T3 5 sur A4 et T4 sur A6.
Le calcul 44 de paramètres non fonctionnels à partir du modèle fonctionnel alloué sur le modèle d'architecture consiste à calculer la latence globale de la chaîne de traitement. Cette première latence globale LI est 10 égale à la somme des temps de calcul des traitements TI, T2, T3 et T4 et des temps de communications entre ces traitements. Le temps d'activation de TI est égal à une période de A3 dont la fréquence est 12.5Hz, soit 80ms. L'application de la deuxième règle d'architecture nous indique que 15 les temps de calcul sont masqués par les temps de communications. Donc les temps de calcul de T2, T3 et T4 sont ignorés pour le calcul de la latence de la chaîne fonctionnelle. Les temps de communications sont égaux aux périodes des tâches destinations soit respectivement 40ms (période de 25Hz), 160ms (période de 6.25Hz), et Oms (en effet, la latence de l'activation 20 de la tâche A6 est masquée par la latence de l'activation de la tâche cyclique A4 précédente de période 160 ms) respectivement pour les communications Ti - T2, T2 - T3, et T3 - T4. On a donc : L1 =80 ms+40 ms+160 ms+0 ms
25 On obtient une première latence globale LI égal à 280 ms. La comparaison 48 de cette valeur avec l'exigence fixée de 100 ms montre que l'exigence fonctionnelle requise n'est respectée. Il donc nécessaire de réitérer l'étape de définition de l'architecture 12 ou l'étape l'allocation des 43 traitements aux tâches.
On définit une seconde allocation présentée dans le tableau 5 suivant : PROCI PARI AI A2 A3 A4 A5 A6 complexité TI 2 x T2 1 x T3 3 X T4 1 X La deuxième allocation consiste à exécuter TI et T2 sur A2, T3 sur AI et T4 sur A5.
10 En procédant à un calcul similaire au précédant, on trouve une seconde latence globale L2 pour la chaîne fonctionnelle égale à 100 ms. Cette valeur est conforme à l'exigence fixée. Ce calcul permet donc de vérifier que l'architecture choisie permet 15 d'exécuter l'application en respectant l'exigence en temps de réponse sur la chaîne de traitement.
Claims (6)
1. Procédé de conception d'un système, ledit système comprenant une application comportant des composants logiciels et une architecture comportant des composants matériels sur laquelle est exécutée ladite application, ledit système comportant des plate-formes informatiques constituées de cartes et de modules électroniques, ledit système devant répondre à au moins une exigence fonctionnelle et une exigence non fonctionnelle, comportant les étapes suivantes : une étape d'analyse fonctionnelle (11), permettant d'obtenir une décomposition du besoin fonctionnel relatif à ladite application, une étape de définition de l'architecture (12), une étape de conception de composants matériels (13) selon ladite architecture, une étape de conception de composants logiciels (14) à partir de la décomposition du besoin fonctionnel, une étape d'intégration des composants logiciels aux composants matériels (15), une étape de validation de l'exigence fonctionnelle dudit système (16), une étape de validation de l'exigence non fonctionnelle dudit système (17), caractérisé en ce qu'il comporte, en outre, une étape de validation amont (21) de l'exigence non fonctionnelle dudit système, précédant les étapes de conception de composants matériels (13) et de composants logiciels (14), ladite étape de validation amont de l'exigence non fonctionnelle comportant les étapes suivantes : la modélisation (31) du besoin fonctionnel à partir de ladite décomposition hiérarchique (36), la modélisation (32) de l'architecture (37) selon des règles d'architecture prédéfinies (35), ladite modélisation de l'architecture étant réalisée avec des processeurs reliés par des bus, l'allocation (33) du modèle du besoin fonctionnel sur le modèle de l'architecture, permettant d'obtenir un modèle fonctionnel alloué sur le modèle d'architecture,le calcul (34) d'au moins un paramètre non fonctionnel à partir du modèle fonctionnel alloué sur le modèle d'architecture, la comparaison (38) du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, si l'exigence non fonctionnelle est respectée, la conception des composants matériels (13) et composants logiciels (14), si l'exigence non fonctionnelle n'est pas respectée, la définition (12) d'une nouvelle architecture (37) ou la recherche d'une nouvelle allocation (33) du modèle du besoin fonctionnel sur le modèle de l'architecture.
2. Procédé selon la revendication 1, caractérisé en ce que le paramètre non fonctionnel calculé concerne la performance du système et comprend au moins un des éléments suivants : la charge de calcul d'un processeur, la consommation de bande passante d'un réseau, le volume mémoire consommé d'un processeur, le temps de traversé du système.
3. Procédé selon l'une des revendications précédentes, caractérisé en ce que le paramètre non fonctionnel calculé concerne la sûreté de fonctionnement du système et comprend notamment l'application de jeux d'entrées provoquant des événements particuliers.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que le paramètre non fonctionnel calculé concerne 25 l'intégrité du système.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le paramètre non fonctionnel calculé concerne la disponibilité du système et comprend notamment le taux de disponibilité de 30 l'architecture.
6. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit système est une plate-forme d'exécution et ladite étape de validation amont (21) des exigences non fonctionnelles comporte 35 les étapes suivantes :la modélisation (41) du besoin fonctionnel avec des chaînes fonctionnelles, lesdites chaînes fonctionnelles étant constituées alternativement de traitements (51) et d'échanges (52), la modélisation (42) de l'architecture (47) avec un groupe de noeuds de calcul reliés par des bus, chacun desdits noeuds de calcul comprenant des partitions, lesdites partitions étant subdivisées en tâches, l'allocation (43) desdits traitements auxdites tâches, permettant d'obtenir un modèle fonctionnel alloué sur le modèle 1 o d'architecture, le calcul (44) de paramètres non fonctionnels à partir du modèle fonctionnel alloué sur le modèle d'architecture, la comparaison (48) du paramètre fonctionnel calculé avec l'exigence non fonctionnelle, 15 si l'exigence non fonctionnelle est respectée, la conception des composants matériels (13) et logiciels (14), si l'exigence non fonctionnelle n'est pas respectée, la définition (12) d'une nouvelle architecture (47) ou la recherche d'une nouvelle allocation (43) des traitements aux tâches. 20
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0800466A FR2911976B1 (fr) | 2007-01-30 | 2008-01-29 | Procede de conception d'un systeme comprenant des composants materiels et logiciels |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0700626A FR2911980A1 (fr) | 2007-01-30 | 2007-01-30 | Procede de conception d'un systeme comprenant des composants materiels et logiciels |
| FR0800466A FR2911976B1 (fr) | 2007-01-30 | 2008-01-29 | Procede de conception d'un systeme comprenant des composants materiels et logiciels |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2911976A1 true FR2911976A1 (fr) | 2008-08-01 |
| FR2911976B1 FR2911976B1 (fr) | 2017-10-20 |
Family
ID=38565627
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0700626A Pending FR2911980A1 (fr) | 2007-01-30 | 2007-01-30 | Procede de conception d'un systeme comprenant des composants materiels et logiciels |
| FR0800466A Active FR2911976B1 (fr) | 2007-01-30 | 2008-01-29 | Procede de conception d'un systeme comprenant des composants materiels et logiciels |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0700626A Pending FR2911980A1 (fr) | 2007-01-30 | 2007-01-30 | Procede de conception d'un systeme comprenant des composants materiels et logiciels |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8112743B2 (fr) |
| FR (2) | FR2911980A1 (fr) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8819652B2 (en) * | 2010-07-30 | 2014-08-26 | General Electric Company | System and method for parametric system evaluation |
| US9063672B2 (en) * | 2011-07-11 | 2015-06-23 | Honeywell International Inc. | Systems and methods for verifying model equivalence |
| US8819638B2 (en) * | 2011-09-20 | 2014-08-26 | Alcatel Lucent | Application protoyping suite |
| US9038025B1 (en) | 2012-05-24 | 2015-05-19 | Allstate Insurance Company | Technical interaction model |
| US20140196002A1 (en) * | 2013-01-08 | 2014-07-10 | Shahak SHEFER | Tool and method thereof for efficient design of information technology systems |
| JP6213552B2 (ja) * | 2013-02-14 | 2017-10-18 | 日本電気株式会社 | 非機能評価によるプロジェクト管理システム、非機能評価によるプロジェクト管理方法および非機能評価によるプロジェクト管理用プログラム |
| US9009653B2 (en) * | 2013-02-28 | 2015-04-14 | Tata Consultancy Services Limited | Identifying quality requirements of a software product |
| US9158502B2 (en) * | 2013-04-15 | 2015-10-13 | Massively Parallel Technologies, Inc. | System and method for communicating between viewers of a hierarchical software design |
| US20140310678A1 (en) * | 2013-04-15 | 2014-10-16 | Massively Parallel Technologies, Inc. | Systems And Methods For Collaborative Views Of A Hierarchical Software Design |
| US20140310680A1 (en) * | 2013-04-15 | 2014-10-16 | Massively Parallel Technologies, Inc. | System And Method For Collaboration |
| US9335974B2 (en) * | 2013-04-15 | 2016-05-10 | Massively Parallel Technologies, Inc. | System and method for determining and displaying design complexity of a software design |
| US9851949B2 (en) * | 2014-10-07 | 2017-12-26 | Kevin D. Howard | System and method for automatic software application creation |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002027565A1 (fr) * | 2000-09-28 | 2002-04-04 | Cadence Design Systems, Inc. | Modelisation de niveau de performance et simulation de systemes electroniques possedant a la fois des ressources materielles et des ressources logicielles |
| EP1229446A1 (fr) * | 2001-02-05 | 2002-08-07 | Thales | Procédé de simulation de performances et de réalisation d'applications multiprocesseurs, et dispositifs permettant de mettre en oeuvre ledit procédé |
| US20060095247A1 (en) * | 2002-10-22 | 2006-05-04 | The Boeing Company | Predictive analysis of availability of systems and/or system components |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5404496A (en) * | 1992-07-01 | 1995-04-04 | Hewlett-Packard Company | Computer-based system and method for debugging a computer system implementation |
| JP2001344287A (ja) * | 2000-06-02 | 2001-12-14 | Nec Microsystems Ltd | アルゴリズム記述におけるバスの性能評価方法 |
| US7076417B2 (en) * | 2001-09-05 | 2006-07-11 | Agilent Technologies, Inc. | Method for modeling and processing asynchronous functional specification for system level architecture synthesis |
| US7430498B2 (en) * | 2004-09-07 | 2008-09-30 | The Boeing Company | System, method and computer program product for developing a system-of-systems architecture model |
| US8561024B2 (en) * | 2007-01-23 | 2013-10-15 | International Business Machines Corporation | Developing software components and capability testing procedures for testing coded software component |
-
2007
- 2007-01-30 FR FR0700626A patent/FR2911980A1/fr active Pending
-
2008
- 2008-01-29 US US12/022,069 patent/US8112743B2/en active Active
- 2008-01-29 FR FR0800466A patent/FR2911976B1/fr active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002027565A1 (fr) * | 2000-09-28 | 2002-04-04 | Cadence Design Systems, Inc. | Modelisation de niveau de performance et simulation de systemes electroniques possedant a la fois des ressources materielles et des ressources logicielles |
| EP1229446A1 (fr) * | 2001-02-05 | 2002-08-07 | Thales | Procédé de simulation de performances et de réalisation d'applications multiprocesseurs, et dispositifs permettant de mettre en oeuvre ledit procédé |
| US20060095247A1 (en) * | 2002-10-22 | 2006-05-04 | The Boeing Company | Predictive analysis of availability of systems and/or system components |
Also Published As
| Publication number | Publication date |
|---|---|
| US8112743B2 (en) | 2012-02-07 |
| US20080235655A1 (en) | 2008-09-25 |
| FR2911980A1 (fr) | 2008-08-01 |
| FR2911976B1 (fr) | 2017-10-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2911976A1 (fr) | Procede de conception d'un systeme comprenant des composants materiels et logiciels | |
| JP7202432B2 (ja) | ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関 | |
| US9032380B1 (en) | Identifying function calls and object method calls | |
| WO2012031165A2 (fr) | Système et procédé de profilage logiciel axé sur les coûts | |
| JP6222225B2 (ja) | 仮想マシン配置決定装置、仮想マシン配置決定方法および仮想マシン配置決定プログラム | |
| CN113703775A (zh) | 一种编译方法、装置、设备及存储介质 | |
| WO2019055378A1 (fr) | Procédé et appareil permettant de trouver des procédés longs dans un code | |
| FR2922665A1 (fr) | Procede d'aide a la conception d'une architecture systeme | |
| JP2015219906A (ja) | ソフトウェア確認方法およびプロセッサ | |
| WO2017109386A1 (fr) | Procede hors ligne d'allocation d'un logiciel embarque temps reel sur une architecture multicontrôleur multicoeur, et son utilisation pour des applications embarquees dans un vehicule automobile | |
| CN110244953A (zh) | Java程序的区间分析方法及装置 | |
| Giusto et al. | Modeling and analysis of automotive systems: Current approaches and future trends | |
| US20140053139A1 (en) | Symbolic testing of software using concrete software execution | |
| CN106570572A (zh) | 基于MapReduce的旅行时计算方法和装置 | |
| US11163594B2 (en) | Rescheduling JIT compilation based on jobs of parallel distributed computing framework | |
| US11442724B2 (en) | Pattern recognition | |
| CN111679924B (zh) | 构件化软件系统可靠性仿真方法、装置及电子设备 | |
| Friese et al. | EC. LANG–A Language for Specifying Response Time Analyses of Event Chains | |
| CN111340215B (zh) | 一种网络模型推理加速方法、装置、存储介质和智能设备 | |
| US11775258B2 (en) | Elimination of rounding error accumulation | |
| US11853725B2 (en) | Microservices recommendation framework | |
| EP3908926A1 (fr) | Procédé de validation d'un système flots de données | |
| Bai et al. | Isochronous networks by construction | |
| AU2021363719B2 (en) | Generating and updating a performance report | |
| US20230195434A1 (en) | Transformation of computer code based on idiom recognition and value constraint analysis |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 9 |
|
| PLFP | Fee payment |
Year of fee payment: 10 |
|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |