FR 3056318 A1 20180323 FR 1601367 A 20160920 1 Procédé d'analyse de dysfonctionnements d'un système embarqué, produit programme d'ordinateur et dispositif d'analyse associés La présente invention concerne un procédé d'analyse de dysfonctionnements d'un système embarqué, un produit programme d'ordinateur et un dispositif d'analyse associés. Par « dysfonctionnement », on comprend tout évènement survenu dans le système embarqué ou dans un de ses composants qui empêche le fonctionnement normal du système ou d'un de ces composants. En particulier, un dysfonctionnement correspond à l'un des éléments choisi dans le groupe consistant en : une faute, un acte malveillant, une défaillance et un évènement redouté. Par « faute », on comprend une anomalie dans le fonctionnement du système embarqué ou d'un de ses composants. Par « acte malveillant », on comprend toute intrusion dans le système embarqué ou dans un de ses composants ayant pour but de nuire au fonctionnement normal du système ou d'un de ses composants. Par « défaillance », on comprend l'effet d'une ou de plusieurs fautes et/ou d'un ou plusieurs actes malveillants sur le fonctionnement du système embarqué ou d'un de ses composants. Par « évènement redouté » (connu également sous le terme anglais « failure condition »), on comprend une défaillance critique, c'est-à-dire une défaillance qui a des conséquences critiques sur le fonctionnement du système embarqué ou d'un de ses composants. Par « message d'erreur » ou encore « message d'observation », on comprend tout message généré par le système embarqué ou par un de ses composants qui a pour but de signaler un dysfonctionnement survenu dans ce système ou dans un de ces composants. Un tel message est notamment destiné à un système d'analyse ou d'enregistrement de ce dysfonctionnement. Par « alerte de fonctionnement », on comprend tout message textuel, vocal ou autre ayant pour but de signaler à un opérateur utilisant le système embarqué, un dysfonctionnement survenu dans ce système ou dans un de ses composants. Un tel message est par exemple généré par un système d'alertes associé au système embarqué. 3056318 2 De manière connue en soi, l'analyse de dysfonctionnements d'un système embarqué et notamment d'un système avionique, s'effectue en fonction de différents domaines d'analyse de ces dysfonctionnements. L'analyse des dysfonctionnements par ces différents domaines a des buts 5 différents et est généralement mis en oeuvre de manière indépendante pour chacun des domaines. Parmi ces domaines, on peut notamment citer le domaine d'analyse de diagnostic permettant d'identifier l'origine d'apparition d'un message d'erreur dans un système embarqué, le domaine d'analyse de sûreté de fonctionnement permettant d'analyser des 10 risques d'apparition d'évènements redoutés, le domaine d'analyse de sécurité permettant d'analyser des conséquences d'apparition d'actes malveillants et le domaine d'analyse d'alertes de fonctionnement permettant de déterminer des alertes signalant un ou plusieurs dysfonctionnements du système. L'analyse des dysfonctionnements en fonction d'au moins certains des domaines 15 précités est souvent mis en oeuvre par des techniques dites de raisonnement à base de modèle (« Model-based reasoning » en anglais). Ces techniques consistent en la représentation du système analysé sous la forme d'un modèle formel, puis en l'analyse automatisé du système en utilisant le modèle formel. 20 Ainsi, par exemple, pour l'analyse des dysfonctionnements selon le domaine d'analyse de diagnostic, il est fréquent d'utiliser des modèles qui décrivent le système analysé en termes de composants et d'interconnections. Un moteur de raisonnement est ensuite mis en oeuvre pour effectuer des calculs de diagnostic depuis les modèles. Pour le domaine d'analyse de sûreté de fonctionnement, il est fréquent d'utiliser 25 des modèles intégrant un arbre de faute. Un tel arbre représente graphiquement les combinaisons possibles d'évènements et notamment de dysfonctionnements, qui peuvent amener à l'apparition d'un évènement redouté. Pour le domaine d'analyse de sécurité, des méthodes de traitement analogues à celles du domaine d'analyse de sûreté de fonctionnement peuvent être utilisées. En effet, 30 les deux domaines analysent des événements redoutés, sauf que pour le domaine d'analyse de sécurité il s'agit d'évènements redoutés causés par des actes malveillants, et pour le domaine de sûreté de fonctionnement il s'agit d'évènements redoutés causés par des fautes. Ainsi, Il est par exemple possible d'utiliser des arbres de faute analogues à ceux mentionnés précédemment pour analyser des dysfonctionnements selon le domaine d'analyse de sécurité. 3056318 3 On conçoit alors que l'analyse des dysfonctionnements selon des différents domaines a besoin d'une adaptation particulière pour chacun des domaines. Cette adaptation peut parfois s'avérer laborieuse. Il est souvent nécessaire de construire un modèle spécifique pour chacun des domaines ce qui présente une difficulté majeure dans 5 l'analyse de dysfonctionnements d'un système embarqué. La présente invention a pour but de proposer un procédé d'analyse de dysfonctionnements d'un système embarqué permettant d'analyser les dysfonctionnements de ce système de manière particulièrement simple sans qu'une adaptation spécifique à un domaine d'analyse particulier ne soit nécessaire. 10 À cet effet, l'invention a pour objet un procédé d'analyse de dysfonctionnements d'un système embarqué comprenant une phase de modélisation de ce système et une phase d'analyse. La phase de modélisation comprend les étapes suivantes : - définition d'un ensemble de ressources formant le système embarqué et pour 15 chaque ressource définie, définition d'un ensemble de services fournis ou consommés par cette ressource; - pour chaque ressource et pour chaque service, définition d'un ensemble de statuts, chaque statut étant apte à être acquis par la ressource correspondante ou par le service correspondant pour caractériser l'état de fonctionnement de cette ressource ou la 20 qualité de service de ce service, l'acquisition par une ressource ou par un service de l'un des statuts de l'ensemble de statuts correspondant constituant un évènement élémentaire; - pour chaque statut d'au moins une ressource ou d'au moins un service, définition d'une règle d'acquisition de ce statut par cette ressource ou par ce service en fonction 25 d'un statut acquis par au moins une autre ressource ou un autre service. La phase d'analyse comprend les étapes suivantes : - paramétrage de l'analyse comprenant le choix d'un évènement élémentaire, dit évènement élémentaire marqué ; - analyse des règles d'acquisition et détermination d'un ensemble d'évènements 30 élémentaires et des conditions de leur apparition, conduisant à l'apparition de l'évènement élémentaire marqué, et association d'au moins certains évènements élémentaires à des dysfonctionnements du système embarqué. Suivant d'autres aspects avantageux de l'invention, le procédé d'analyse comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant 35 toutes les combinaisons techniquement possibles : 3056318 4 - l'analyse des règles d'acquisition comprend la mise en oeuvre d'un algorithme de calcul de coupes minimales; - les conditions d'apparition d'évènements élémentaires comprennent des opérations logiques de conjonction, de disjonction et de négation entre différents 5 évènements élémentaires ; - l'étape de paramétrage comprend en outre l'association d'une valeur numérique à au moins un évènement élémentaire correspondant à la probabilité d'apparition de cet évènement élémentaire ; - l'étape de détermination d'un ensemble d'évènements élémentaires et des 10 conditions de leur apparition, comprend en outre le calcul de la probabilité d'apparition de l'évènement élémentaire marqué ; - l'étape de paramétrage comprend en outre l'association d'une valeur numérique à l'évènement élémentaire marqué correspondant à la probabilité maximale acceptable d'apparition de cet évènement élémentaire marqué ; 15 - l'étape de détermination d'un ensemble d'évènements élémentaires et des conditions de leur apparition, comprend en outre la comparaison de la probabilité maximale acceptable d'apparition de l'évènement élémentaire marqué avec la probabilité d'apparition calculée de l'évènement élémentaire marqué ; - l'étape de paramétrage est effectuée en fonction d'un domaine d'analyse de 20 dysfonctionnements du système embarqué, chaque domaine étant choisi dans le groupe consistant en : un domaine d'analyse de diagnostic permettant d'identifier l'origine d'apparition d'un message d'erreur dans le système embarqué, un domaine d'analyse de sûreté de fonctionnement permettant d'analyser des risques d'apparition d'évènements redoutés, un domaine d'analyse de sécurité permettant d'analyser des conséquences 25 d'apparition d'actes malveillants et un domaine d'analyse d'alertes de fonctionnement permettant de déterminer des alertes signalant un ou plusieurs dysfonctionnements du système embarqué ; - chaque évènement élémentaire marqué correspond à l'un des éléments choisis dans le groupe consistant en : l'apparition d'un message d'erreur, l'apparition d'un 30 évènement redouté, et l'apparition d'une alerte. L'invention a également pour objet un produit programme d'ordinateur comportant des instructions logicielles qui, lorsque mises en oeuvre par un équipement informatique, mettent en oeuvre le procédé tel que défini ci-dessus. L'invention a également pour objet un dispositif d'analyse de dysfonctionnements 35 d'un système embarqué mettant en oeuvre le procédé d'analyse que défini ci-dessus. 3056318 5 Ces caractéristiques et avantages de l'invention apparaitront à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : - la figure 1 est une vue schématique d'un dispositif d'analyse selon l'invention, le 5 dispositif d'analyse mettant en oeuvre un procédé d'analyse selon l'invention permettant d'analyser des dysfonctionnements d'un système embarqué ; - la figure 2 est une vue schématique du système embarqué de la figure 1 ; et - la figure 3 est un organigramme du procédé d'analyse de la figure 1. Le dispositif d'analyse 10 de la figure 1 permet d'analyser des dysfonctionnements 10 d'un système embarqué 12 illustré plus en détail sur la figure 2. Par « dysfonctionnement », on comprend tout évènement survenu dans le système embarqué ou dans un de ses composants qui empêche le fonctionnement normal du système ou d'un de ces composants. En particulier, un dysfonctionnement correspond à l'un des éléments choisi dans le 15 groupe consistant en : une faute, un acte malveillant, une défaillance et un évènement redouté. Le système embarqué 12 est par exemple un système avionique d'un aéronef, tel qu'un système de réchauffage. Le système embarqué 12 comprend une pluralité de composants matériels et/ou 20 logiciels. Chacun de ces composants a un but prédéterminé dans le fonctionnement du système 12. Il est à noter qu'au moins certains des composants du système 12 peuvent être utilisés par d'autres systèmes embarqués. Dans l'exemple de la figure 2, le système embarqué 12 comporte un module 25 d'alimentation 21 connu également sous le nom anglais « Power Supply », un module réchauffeur 22 connu également sous le nom anglais « Heater », un système de maintenance 23 connu également sous le nom anglais « Maintenance System » et un système d'alerte de vol 24 connu également sous le nom anglais « Flight Warning System ». 30 Selon cet exemple, le système de maintenance 23 et le système d'alerte de vol 24 sont utilisables par d'autres systèmes embarqués qui ne sont pas illustrés sur la figure 2 et ne seront pas décrits par la suite. Le module d'alimentation 21 est apte à fournir un courant électrique destiné au module réchauffeur 22. 35 Le module réchauffeur 22 est apte à utiliser ce courant électrique pour produire de la chaleur destinée par exemple à la cabine de l'aéronef. 3056318 6 Le module réchauffeur 22 est apte en outre à produire un message d'erreur lorsque la chaleur ne peut pas être fournie. Ce message est destiné au système de maintenance 23 et au système d'alerte de vol 24. Chacun du système de maintenance 23 et du système d'alerte de vol 24 est apte à 5 recevoir le message d'erreur envoyé par le module réchauffeur 22. En particulier, le système de maintenance 23 est apte en cas de réception d'un tel message d'erreur, à générer un message de maintenance destiné à un opérateur de maintenance. De manière analogue, le système d'alerte de vol 24 est apte en cas de réception 10 d'un tel message d'erreur, à générer une alerte destinée à l'équipage de l'aéronef. En référence à la figure 1, le dispositif d'analyse 10 comporte un module de modélisation 31, un module d'analyse 32 et un module de communication 33. Le module de modélisation 31 permet de modéliser le fonctionnement du système embarqué 12 en mettant en oeuvre une phase de modélisation PM du procédé d'analyse 15 qui sera expliqué plus en détail par la suite. Le module d'analyse 32 permet d'analyser des dysfonctionnements du système 12 en mettant en oeuvre une phase d'analyse PA du procédé d'analyse. Le module d'affichage 33 présente par exemple une interface de communication homme-machine permettant à un utilisateur de communiquer avec le dispositif d'analyse 20 10. De manière connue en soi, une telle interface comprend par exemple un écran d'affichage et des moyens d'introduction d'information tels qu'un clavier. Le dispositif d'analyse 10 est par exemple un calculateur comportant en outre une mémoire 38 et un processeur 39. Dans ce cas, les modules de modélisation 31 et d'analyse 32 se présentent sous la forme des logiciels stockés dans la mémoire 38 et mis 25 en oeuvre par le processeur 39. Le procédé d'analyse selon l'invention sera désormais expliqué en référence à la figure 3 présentant un organigramme de ses étapes. Comme cela a été mentionné précédemment, le procédé d'analyse selon l'invention comprend une phase de modélisation PM et une phase d'analyse PA. 30 Lors de l'étape initiale 110 de la phase de modélisation PM, le module de modélisation 31 définit un ensemble de ressources Ri formant le système embarqué 12. Chaque ressource R, correspond à un composant du système 12 tel que défini précédemment. Dans la notation du type « R, », l'indice associé à la lettre « R » correspond à un 35 identifiant unique de la ressource correspondante dans le système 12 et varie par 3056318 7 exemple de 1 à N, le nombre N étant un nombre naturel désignant le nombre total des ressources dans le système 12. Ainsi, dans l'exemple de réalisation de la figure 2, lors de cette étape 110, le module de modélisation 31 définit quatre ressources R1, R2, R3 et R4 correspondant 5 respectivement au module d'alimentation 21, au module réchauffeur 22, au système de maintenance 23 et au système d'alerte de vol 24. Lors de l'étape 120 suivante, le module de modélisation 31 définit pour chaque ressource R un ensemble de services Su fournis ou consommés par cette ressource R. Chaque service Su fourni par une ressource R, présente ainsi un résultat du 10 fonctionnement de cette ressource R, dans le système 12. Chaque service Su consommé par une ressource R, présente ainsi un service Snm fourni par une autre ressource Rn et utilisé par cette ressource R pour fournir un autre service Sik. Dans la notation du type « Su », le premier indice associé à la lettre « S » se réfère 15 à l'identifiant de la ressource R, fournissant ou consommant le service correspondant et le deuxième indice associé à la lettre « S » correspond à un identifiant unique du service correspondant parmi tous les services fournis ou consommé par la ressource R,. Le deuxième indice varie par exemple de 1 à M, le nombre M étant un nombre naturel désignant le nombre total des services fournis par la ressource R. 20 Dans l'exemple de réalisation de la figure 2, lors de cette étape 120, pour la ressource R1, le module de modélisation 31 définit un service S11 présentant la fourniture d'un courant électrique. Pour la ressource R2, le module de modélisation 31 définit un service S21 correspondant à la consommation par cette ressource du courant électrique fourni par la 25 ressource R1, un service S22 correspondant à la production de la chaleur et un service S23 correspondant à la production d'un message d'erreur lorsque la chaleur ne peut pas être fournie. Pour chacune des ressources R3 et R4, le module de modélisation 31 définit respectivement un service S31 et un service 541 correspondant à la consommation d'un 30 message d'erreur produit par la ressource R2. Pour la ressource R3, le module de modélisation 31 définit en outre un service S32 correspondant à la production d'un message de maintenance. Finalement, pour la ressource R4, le module de modélisation 31 définit en outre un service S42 correspondant à la production d'une alerte. 35 Il est à noter que seuls les services S11, S22, S23, S32 et S42 fournis par les ressources R1 à R4 sont illustrés sur la figure 2. 3056318 8 Il est à noter également que la liste des services Su mentionnés ci-dessus en relation avec les ressources R1 à R4 n'est pas exhaustive. Lors de l'étape 130 suivante, le module de modélisation 31 définit pour chaque ressource R, et pour chaque service Su, un ensemble de statuts. 5 En particulier, l'ensemble de statuts associé à une ressource R1 est composé de plusieurs statuts dont chaque statut est apte à caractériser l'état de fonctionnement de cette ressource R à un instant donné. Chaque ressource R, est donc apte à acquérir l'un des statuts de l'ensemble de statuts correspondant de sorte que son état de fonctionnement soit caractérisé par ce 10 statut à un instant donné. Dans l'exemple de réalisation de la figure 2, le module de modélisation 31 définit pour chacune des ressources R2 à R4, un ensemble de statuts composé de deux statuts, à savoir « OK » et « KO ». Le statut « OK » caractérise l'état de fonctionnement de la ressource R2 à R4 15 correspondante dans lequel elle fonctionne normalement. Le statut « KO » caractérise l'état de fonctionnement de la ressource R2 à R4 correspondante dans lequel elle est défaillante. Pour la ressource R1, le module de modélisation 31 définit un ensemble de statuts composé de trois statuts, à savoir « OK », « KO » et « Surcharged ». Les statuts « OK » 20 et « KO » caractérisent les mêmes états de fonctionnement de la ressource R1 que dans le cas des ressources R2 à R4. Le statut « Surcharged » caractérise l'état de fonctionnement de la ressource R1 dans lequel elle est surchargée. Quant aux services Su, l'ensemble de statuts associé à un service Su est composé de plusieurs statuts dont chaque statut est apte à caractériser la qualité de service de ce 25 service Su à un instant donné. Chaque service Su est donc apte à acquérir l'un des statuts de l'ensemble de statuts correspondant de sorte que sa qualité de service soit caractérisée par ce statut à un instant donné. Ainsi, dans l'exemple de réalisation de la figure 2, lors de l'étape 130, le module 30 de modélisation 31 définit pour les services S11 et S21 correspondant respectivement à la production et à la consommation d'un courant électrique, un ensemble de statuts composé de deux statuts, à savoir « None » et « Full ». Le statut « None » signifie que le courant électrique n'est pas produit. Le statut « Full » signifie que le courant électrique est produit de façon normale. 35 Pour le service S22 correspondant à la production de la chaleur, le module de modélisation 31 définit un ensemble de statuts composé de deux statuts, à savoir 3056318 9 « Available » et « Not Available ». Le statut « Available » signifie que la chaleur est produite et le statut « Not Available » signifie que la chaleur n'est pas produite. Finalement, pour chacun des services S23, S31, S32, S41 et S42 correspondant à la production ou à la consommation d'un message, le module de modélisation 31 définit un 5 ensemble de statuts composé de deux statuts, à savoir « Sent » et « Not Sent ». Le statut « Sent » signifie que le message correspondant a été envoyé ou reçu et le statut « Not Sent » signifie que le message correspondant n'a pas été envoyé ou reçu. Dans la suite de la description, on entend par « évènement élémentaire », l'acquisition par une ressource R, ou par un service Sij de l'un des statuts de l'ensemble 10 de statuts correspondant à cette ressource R, ou à ce service S. On conçoit alors qu'au moins certains d'évènements élémentaires correspondent par exemple à des dysfonctionnements du système 12 ou de l'un de ses composants. Ainsi, par exemple, l'acquisition du statut « KO » par la ressource R1 correspond à une faute survenue dans cette ressource et l'acquisition du statut « Surcharged » par la même 15 ressource correspond à un acte malveillant survenu de cette ressource. Lors de l'étape 140 suivante, le module de modélisation 31 définit pour chaque statut de chaque ressource R, et de chaque service Sq, au moins une règle d'acquisition de ce statut par cette ressource R, ou par ce service Su en fonction d'un statut acquis par au moins une autre ressource R, ou un autre service Su. 20 Les règles d'acquisition définissent donc des dépendances entre les statuts de différentes ressources R, et de différents services S. Ainsi, dans l'exemple de la figure 2, le module de modélisation 31 définit par exemple une règle d'acquisition pour le statut « None » du service Sil selon laquelle le service Sil acquiert ce statut « None » lorsque la ressource R1 acquiert le statut « KO ». 25 Dans le même exemple, le module de modélisation 31 définit une règle d'acquisition pour le statut « Available » du service S22 selon laquelle ce service S22 acquiert ce statut « Availbale » lorsque le service S21 acquiert le statut « Full » et la ressource R2 acquiert le statut « OK ». Bien entendu, de nombreuses autres règles d'acquisition peuvent être définies 30 dans l'exemple de la figure 2. L'étape 140 est une étape finale de la phase de modélisation PM. À l'issue de cette étape, un modèle du système 12 est donc obtenu. Il est à noter que chacune des étapes de définition 110 à 140 décrite précédemment peut être mise en oeuvre en utilisant une base de données 35 correspondante qui est stockée par exemple dans la mémoire 38 du dispositif 10. 3056318 10 Ainsi, ces bases de données comportent notamment une liste de ressources R, pour le système 12, une liste de services Su pour chacune des ressources R,, une liste d'ensembles de statuts pour chacune des ressources R, et pour chacun des services S1, et une liste de règles d'acquisition pour au moins certains des statuts. 5 Ces bases de données sont par exemple introduites par un utilisateur préalablement à la mise en oeuvre des étapes correspondantes ou sont fournies par le producteur du système embarqué 12. Après la phase de modélisation PM, le dispositif d'analyse 10 met en oeuvre la phase d'analyse PA de dysfonctionnements du système 12 en utilisant le modèle du 10 système 12. Lors de l'étape initiale 150 de cette phase, le module d'analyse 32 acquiert des données de paramétrage de l'analyse. Ces données sont par exemple introduites par l'utilisateur via le module de communication 33 et permettent de marquer un évènement élémentaire, dit par la suite 15 évènement élémentaire marqué. L'évènement marqué représente par exemple un dysfonctionnement du système embarqué 12 ou au contraire, l'acquisition par une ressource R, du statut « OK ». L'évènement élémentaire marqué est choisi par l'utilisateur du dispositif 10 en fonction du domaine d'analyse de dysfonctionnements du système embarqué 12. 20 Chaque domaine d'analyse est choisi dans le groupe comprenant : - domaine d'analyse de diagnostic permettant d'identifier l'origine d'apparition d'un message d'erreur dans le système embarqué 12 ; - domaine d'analyse de sûreté de fonctionnement permettant d'analyser des risques d'apparition d'évènements redoutés ; 25 - domaine d'analyse de sécurité permettant d'analyser des conséquences d'apparition d'actes malveillants ; et - domaine d'analyse d'alertes de fonctionnement permettant de déterminer des alertes signalant un ou plusieurs dysfonctionnements du système 12. Ainsi, pour le domaine d'analyse de diagnostic, l'évènement élémentaire marqué 30 correspond à l'apparition d'un message d'erreur dans le système embarqué 12 suite à un ou plusieurs dysfonctionnements survenus dans ce système 12 ou dans l'un de ses composants. Le but d'analyse de cet évènement élémentaire marqué par le dispositif 10 consiste donc à identifier toutes les causes d'apparition d'un tel message d'erreur dans le système embarqué 12. Ces causes correspondent à des dysfonctionnements du système 35 12 et des conditions d'apparition de ces dysfonctionnements. 3056318 11 Dans l'exemple de réalisation de la figure 2, un tel évènement élémentaire marqué correspond à l'acquisition du statut « Sent » par l'un des services S23, S31, S32 ou S41. Pour le domaine d'analyse d'alertes de fonctionnement, l'évènement élémentaire marqué correspond à l'apparition d'une alerte émise notamment par le système d'alerte 5 de vol 24 suite à un ou plusieurs dysfonctionnements survenus dans ce système 12 ou dans l'un de ses composants. Le but d'analyse de cet évènement élémentaire marqué par le dispositif 10 consiste donc à identifier toutes les causes d'apparition d'une telle alerte. Ces causes correspondent à des dysfonctionnements du système 12 et des conditions d'apparition de ces dysfonctionnements. 10 Dans l'exemple de réalisation de la figure 2, un tel évènement élémentaire marqué correspond à l'acquisition du statut « Sent » par le service S42. Pour le domaine d'analyse de sûreté de fonctionnement, l'évènement élémentaire marqué correspond à l'apparition d'un évènement redouté. Le but d'analyse de cet évènement élémentaire marqué par le dispositif 10 consiste donc à identifier toutes les 15 causes d'apparition d'un tel évènement redouté et à analyser les risques de l'apparition de cet évènement redouté. Ces causes correspondent à des dysfonctionnements du système 12 et des conditions d'apparition de ces dysfonctionnements. Pour accompagner les évènements élémentaires marqués correspondant au domaine d'analyse de sûreté, deux types de données numériques sont paramétrés. 20 Les données numériques d'un premier type correspondent à la probabilité maximale acceptable pour l'apparition de l'évènement redouté. Ces données sont par exemple associées sous la forme d'un argument numérique à l'évènement élémentaire marqué correspondant à l'apparition de l'évènement redouté et plus particulièrement au statut acquis par une ressource R, ou un service Su. 25 Les données numériques d'un deuxième type correspondent à des probabilités d'apparition de dysfonctionnements de l'un des composants du système embarqué 12. Ces données sont par exemple associées à des évènements élémentaires correspondant à l'apparition de ces dysfonctionnements. En particulier, chacune de ces données est associée au statut acquis par une ressource R, ou un service Su selon l'évènement 30 élémentaire correspondant. Dans l'exemple de réalisation de la figure 2, un tel évènement élémentaire marqué comprend l'acquisition du statut « Not Available » par le service S22. Dans ce cas, un argument « 1E-4 » correspondant à une donnée du premier type est associé à ce statut ce qui signifie que la probabilité maximale acceptable pour 35 l'apparition d'un dysfonctionnement du module réchauffeur 22 est égale à 104. 3056318 12 Par ailleurs, des arguments « 1E-5 » et « 1E-6 » correspondant à des données du deuxième type, sont associées aux statuts « KO » respectivement des ressources R2 et R1. Cela signifie alors que les probabilités de dysfonctionnement (appelées également taux de défaillance) du module réchauffeur 22 et du module d'alimentation 21 sont 5 respectivement égales à 10-5 età 10-6. Pour le domaine d'analyse de sécurité, l'évènement élémentaire marqué correspond à l'apparition d'un événement redouté dû à un ou plusieurs actes malveillants survenus dans le système embarqué 12 ou dans l'un de ses composants. De manière analogue au domaine d'analyse de sûreté de fonctionnement, pour 10 accompagner les évènements élémentaires marqués correspondant au domaine d'analyse de sécurité, deux types de données numériques sont paramétrés. Comme dans le cas précédent, les données numériques d'un premier type correspondent à la probabilité maximale acceptable pour l'apparition de l'évènement 15 redouté suite à l'apparition d'un ou plusieurs actes malveillants. Ces données sont par exemple associées sous la forme d'un argument numérique à l'évènement élémentaire marqué correspondant à l'apparition de cet évènement redouté et plus particulièrement au statut acquis par une ressource R ou un service Su selon l'évènement élémentaire marqué. 20 Les données numériques d'un deuxième type correspondent à des probabilités d'apparition d'actes malveillants dans le système embarqué 12. Ces données sont par exemple associées à des évènements élémentaires correspondant à l'apparition de ces actes. En particulier, chacune de ces données est associée au statut acquis par une ressource R ou un service Su selon l'évènement élémentaire correspondant. 25 Dans l'exemple de réalisation de la figure 2, un évènement élémentaire marqué correspondant au domaine d'analyse de sécurité, comprend comme dans le cas précédent, l'acquisition du statut « Not Available » par le service S22. Dans ce cas, un argument « 1E-4 » correspondant à une donnée du premier type est associé à ce statut ce qui signifie que la probabilité maximale acceptable pour 30 l'apparition d'un évènement redouté en relation avec ce module réchauffeur 22 et dû à un ou plusieurs actes malveillants, est égale à 10-4. Par ailleurs, un argument « 1E-7 » correspondant à une donnée du deuxième type, est associée au statut « Surcharged » de la ressource R2. Cela signifie alors que la potentialité de menace correspondant à une surcharge malveillante du module 35 d'alimentation 21 est égale à 10-7. 3056318 13 Selon un exemple de réalisation, les données de paramétrage permettent de définir plusieurs évènements élémentaires marqués correspondant à un même domaine d'analyse ou à des domaines d'analyse différents. Lors de l'étape 160 suivante, le module d'analyse 32 analyse l'ensemble des 5 règles d'acquisition définies lors de l'étape 140 et détermine toutes les causes de l'apparition de l'évènement élémentaire marqué. Ces causes correspondent notamment à l'apparition d'un ou plusieurs évènements élémentaires ainsi que à des conditions de leur apparition. En particulier, lors de cette étape 160, le module d'analyse 32 met en oeuvre un 10 algorithme de calcul de coupes minimales connu en soi. Cet algorithme comprend notamment la création des arbres de faute à partir du modèle du système embarqué 12 obtenu lors de la phase de modélisation PM et l'analyse de ces arbres en fonction du domaine d'analyse correspondant à l'évènement élémentaire marqué. L'algorithme de calcul de coupes minimales permet alors d'obtenir l'ensemble des 15 évènements élémentaires et des conditions de leur apparition, conduisant à l'apparition de l'évènement élémentaire marqué. Les conditions d'apparition des différents évènements élémentaires comprennent par exemple des opérations logiques de type « ET », « OU » et « NON » correspondant respectivement à la conjonction, à la disjonction et à la négation de différents évènements 20 élémentaires. Pour le domaine d'analyse de diagnostic, les évènements élémentaires déterminés et les conditions de leur apparition permettent d'identifier l'origine d'apparition d'un message. Ainsi, dans l'exemple de la figure 2, l'évènement élémentaire marqué 25 correspondant à l'acquisition du statut « Sent » par le service S31 est obtenu suite aux évènements élémentaires et aux conditions de leur apparition suivants : - évènement élémentaire correspondant à l'acquisition du statut « Surcharged » par la ressource R1; OU - évènement élémentaire correspondant à l'acquisition du statut « KO » par la 30 ressource R1; OU - évènement élémentaire correspondant à l'acquisition du statut « KO » par la ressource R2. Le premier évènement élémentaire constitue un acte malveillant survenu dans la ressource R1, les deuxième et troisième évènements élémentaires constituent des fautes 35 survenues respectivement dans la ressource R1 et dans la ressource R2. 3056318 14 Pour le domaine d'analyse d'alertes de fonctionnement, les évènements élémentaires déterminés et les conditions de leur apparition permettent d'identifier l'origine d'apparition d'une alerte. Ainsi, dans l'exemple de la figure 2, l'évènement élémentaire marqué 5 correspondant à l'acquisition du statut « Sent » par le service S42 est obtenu suite aux évènements élémentaires et aux conditions de leur apparition suivants : - évènement élémentaire correspondant à l'acquisition du statut « Surcharged » par la ressource ; OU - évènement élémentaire correspondant à l'acquisition du statut « KO » par la 10 ressource Ri ; OU - évènement élémentaire correspondant à l'acquisition du statut « KO » par la ressource R2. Comme dans le cas précédent, le premier évènement élémentaire constitue un acte malveillant survenu dans la ressource Ri, les deuxième et troisième évènements 15 élémentaires constituent des fautes survenues respectivement dans la ressource Ri et dans la ressource R2. Pour le domaine d'analyse de sûreté de fonctionnement, les évènements élémentaires déterminés et les conditions de leur apparition permettent d'identifier l'origine d'apparition d'un évènement redouté. 20 Pour ce domaine, le module d'analyse calcule en outre la probabilité maximale d'atteindre l'évènement redouté et compare cette probabilité avec la probabilité maximale acceptable d'apparition de cet évènement redouté. Ainsi, dans l'exemple de la figure 2, l'évènement élémentaire marqué correspondant à l'acquisition du statut « Not Available » par le service S22 est obtenu suite 25 à l'évènement élémentaire correspondant à l'acquisition du statut « KO » par la ressource Ri et cela avec une probabilité maximale égale à 10-5 ce qui est inférieur à la probabilité maximale acceptable pour apparition de cet évènement élémentaire marqué qui a été fixée à 10-4. L'évènement élémentaire correspondant à l'acquisition du statut « KO » par la 30 ressource Ri constitue une faute survenue dans cette ressource R1. De manière analogue, pour le domaine d'analyse de sécurité, les évènements élémentaires déterminés et les conditions de leur apparition permettent d'identifier un ou plusieurs actes malveillants causant un évènement redouté. Pour ce domaine, le module d'analyse 32 calcule en outre la probabilité maximale 35 d'apparition de l'évènement redouté suite à l'acte ou aux actes malveillant(s) déterminé(s) 3056318 15 et compare cette probabilité avec la probabilité maximale acceptable d'apparition de cet acte. Ainsi, dans l'exemple de la figure 2, l'évènement élémentaire marqué correspondant à l'acquisition du statut « Not Available » par le service S22 est obtenu suite 5 à l'évènement élémentaire correspondant à l'acquisition du statut « Surcharged » par la ressource R1 et cela avec une probabilité maximale égale à 10-7 ce qui est inférieur à la probabilité maximale acceptable pour apparition de cet évènement élémentaire marqué qui a été fixée à 10-4. L'évènement élémentaire correspondant à l'acquisition du statut « Surcharged » 10 par la ressource R1 constitue un acte malveillant survenu dans cette ressource R1. Lorsque les données de paramétrage comprennent des données relatives à plusieurs évènements élémentaires marqués, lors de l'étape 160, le module d'analyse détermine un ensemble d'évènements élémentaires et des conditions de leur apparition, conduisant à l'apparition de chacun de ces évènements élémentaires marqués. 15 À la fin de l'étape 160, le module d'analyse 32 transmet les résultats obtenus lors çette étape, c'est-à-dire, une liste d'évènements élémentaires, des conditions de leur apparition ainsi qu'éventuellement une probabilité d'apparition de l'évènement élémentaire marqué, à l'utilisateur via par exemple le module de communication 33. On conçoit alors que l'invention présente un certain nombre d'avantages. 20 En effet, la phase de modélisation mise en oeuvre par le procédé d'analyse est indépendante du domaine d'analyse selon lequel les dysfonctionnements du système embarqué doivent être traités. Cela a été atteint grâce à l'introduction des notions universelles qui sont communes pour tous les domaines d'analyse. Ainsi, le modèle du système obtenu à 25 l'issue de la phase de modélisation peut être utilisé pour analyser les dysfonctionnements de ce système selon n'importe quel domaine d'analyse. La phase d'analyse de ce procédé permet de spécifier de manière particulièrement simple le domaine d'analyse souhaité. Ainsi, pour ce faire, l'utilisateur marque lors d'une étape de paramétrage, un 30 évènement élémentaire qui correspond à l'un des domaines. Cette étape permet en outre de définir des données numériques correspondant par exemple à la probabilité maximale acceptable d'apparition de cet évènement élémentaire marqué et à la probabilité maximale d'apparition de tout autre évènement élémentaire. 35 Finalement, l'étape finale de la phase d'analyse met en oeuvre un algorithme de calcul de coupes minimales qui permet de déterminer toutes les causes d'apparition de 3056318 16 l'évènement élémentaire marqué et cela indépendamment du domaine d'analyse considéré. REVENDICATIONS1.- Procédé d'analyse de dysfonctionnements d'un système embarqué (12) comprenant une phase de modélisation (PM) de ce système et une phase d'analyse (PA) ; la phase de modélisation (PM) comprenant les étapes suivantes : - définition (110, 120) d'un ensemble de ressources (R,) formant le système embarqué (12) et pour chaque ressource définie (R,), définition d'un ensemble de services (Su) fournis ou consommés par cette ressource (R,) ; - pour chaque ressource (R,) et pour chaque service (Su), définition (130) d'un ensemble de statuts, chaque statut étant apte à être acquis par la ressource (R) correspondante ou par le service (S11) correspondant pour caractériser l'état de fonctionnement de cette ressource (R,) ou la qualité de service de ce service (Su), l'acquisition par une ressource (R,) ou par un service (Su) de l'un des statuts de l'ensemble de statuts correspondant constituant un évènement élémentaire ; - pour chaque statut d'au moins une ressource (R,) ou d'au moins un service (S1), définition (140) d'une règle d'acquisition de ce statut par cette ressource (R,) ou par ce service (Su) en fonction d'un statut acquis par au moins une autre ressource (R,) ou un autre service (Su) ; la phase d'analyse (PA) comprenant les étapes suivantes : - paramétrage (150) de l'analyse comprenant le choix d'un évènement élémentaire, dit évènement élémentaire marqué ; - analyse (160) des règles d'acquisition et détermination (160) d'un ensemble d'évènements élémentaires et des conditions de leur apparition, conduisant à l'apparition de l'évènement élémentaire marqué, et association d'au moins certains évènements élémentaires à des dysfonctionnements du système embarqué (12). 2.- Procédé selon la revendication 1, dans lequel l'analyse des règles d'acquisition comprend la mise en oeuvre d'un algorithme de calcul de coupes minimales. 3.- Procédé selon la revendication 1 ou 2, dans lequel les conditions d'apparition d'évènements élémentaires comprennent des opérations logiques de conjonction, de disjonction et de négation entre différents évènements élémentaires. 4.- Procédé selon l'une quelconque des revendications précédente, dans lequel l'étape de paramétrage (150) comprend en outre l'association d'une valeur numérique à 3056318 18 au moins un évènement élémentaire correspondant à la probabilité d'apparition de cet évènement élémentaire. 5.- Procédé selon la revendication 4, dans lequel l'étape de détermination (160) 5 d'un ensemble d'évènements élémentaires et des conditions de leur apparition, comprend en outre le calcul de la probabilité d'apparition de l'évènement élémentaire marqué. 6.- Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de paramétrage (150) comprend en outre l'association d'une valeur numérique à 10 l'évènement élémentaire marqué correspondant à la probabilité maximale acceptable d'apparition de cet évènement élémentaire marqué. 7.- Procédé selon les revendications 5 et 6, dans lequel l'étape de détermination (160) d'un ensemble d'évènements élémentaires et des conditions de leur apparition, 15 comprend en outre la comparaison de la probabilité maximale acceptable d'apparition de l'évènement élémentaire marqué avec la probabilité d'apparition calculée de l'évènement élémentaire marqué. 8.- Procédé selon l'une quelconque des revendications précédente, dans lequel 20 l'étape de paramétrage (150) est effectuée en fonction d'un domaine d'analyse de dysfonctionnements du système embarqué (12), chaque domaine étant choisi dans le groupe consistant en : - domaine d'analyse de diagnostic permettant d'identifier l'origine d'apparition d'un message d'erreur dans le système embarqué (12) ; 25 - domaine d'analyse de sûreté de fonctionnement permettant d'analyser des risques d'apparition d'évènements redoutés ; - domaine d'analyse de sécurité permettant d'analyser des conséquences d'apparition d'actes malveillants ; et - domaine d'analyse d'alertes de fonctionnement permettant de déterminer des 30 alertes signalant un ou plusieurs dysfonctionnements du système embarqué (12). 9.- Procédé selon l'une quelconque des revendications précédente, dans lequel chaque évènement élémentaire marqué correspond à l'un des éléments choisis dans le groupe consistant en : 35 - apparition d'un message d'erreur ; - apparition d'un évènement redouté ; et 3056318 19 - apparition d'une alerte. 10.- Produit programme d'ordinateur comportant des instructions logicielles qui, lorsque mises en oeuvre par un équipement informatique, mettent en oeuvre le procédé 5 selon l'une quelconque des revendications précédentes. 11.- Dispositif d'analyse (10) de dysfonctionnements d'un système embarqué (12) mettant en oeuvre le procédé d'analyse selon l'une quelconque des revendications 1 à 9.