Brevet FR2923040A1 — publié le 20090501

La présente invention est relative à un procédé de diagnostic d'un système électronique à composants logiciels. L'invention trouve une application particulièrement importante dans le domaine automobile, où les différents systèmes électroniques embarqués d'une automobile peuvent être soumis à une vérification, notamment une vérification d'intégrité logicielle, après leur entrée en service ou commercialisation. En effet, un véhicule automobile comprend couramment plusieurs systèmes électroniques dédiés à la gestion de fonctions du véhicule, telles que par exemple la commande du moteur propulsant le véhicule, la gestion de la climatisation de l'habitacle, la gestion des liaisons du véhicule au sol (freinage, suspension), etc. De tels systèmes comprennent essentiellement des unités de commande électroniques ou "calculateurs" ECU (acronyme anglais pour "Electronic Control Unit"), intégrant des logiciels et utilisant ou émettant des informations sur les bus de communication du véhicule, en liaison avec d'autres éléments périphériques tels que des capteurs et/ou des actionneurs. Le logiciel d'exploitation stocké en mémoire d'un calculateur de ce type intègre en particulier une pluralité de composants logiciels, prévus pour coopérer à l'exécution de la fonction pour laquelle le calculateur est prévu. Un composant logiciel s'entend donc comme un sous-ensemble du logiciel d'exploitation du calculateur, qui constitue un module indépendant utilisé comme élément de ce logiciel d'exploitation et qui est spécialement conçu pour fonctionner sans problèmes avec les autres composants de celui-ci. Une des contraintes d'un tel calculateur est celle liée à la complexité des composants logiciels constituant son logiciel d'exploitation, en particulier pour leur analyse dans un contexte de retour après vente du calculateur au fabricant. En effet, après sa conception et sa fourniture à un client, par exemple un constructeur automobile, le logiciel d'exploitation stocké dans la mémoire du calculateur est classiquement prévu pour pouvoir être modifié. En particulier, lorsque le constructeur du véhicule souhaite remplacer dans la mémoire du calculateur une version de logiciel par une nouvelle version. Cette opération de mise à jour du logiciel peut consister à reprogrammer tout ou partie seulement des composants logiciels constituant le logiciel d'exploitation du calculateur, chaque composant logiciel pouvant en effet être reprogrammé indépendamment des autres. En conséquence, en cas de retour après vente du calculateur à son fabricant, par exemple suite à un défaut de fonctionnement ou à une panne, l'analyse par le fabricant du calculateur est rendue complexe du fait de la méconnaissance qu'il a de son contenu exact, liée aux éventuels chargements d'une ou plusieurs nouvelles versions du logiciel postérieurement à sa livraison ou à un changement de contenu logiciel lié à un dysfonctionnement de composant électronique. Le contrôle du contenu logiciel du calculateur en retour après vente repose donc bien souvent sur une analyse empirique de celui-ci et sur l'expérience de l'opérateur en 5 charge de mener cette analyse. La présente invention a pour but de remédier à ces inconvénients en proposant un procédé de diagnostic du contenu logiciel d'un calculateur, qui permet d'effectuer cette opération d'une manière simplifiée, fiable et automatique. Avec cet objectif en vue, l'invention a pour objet un procédé de diagnostic du 10 contenu logiciel (appelé également diagnostic d'intégrité logicielle) d'un calculateur équipé d'une mémoire stockant une pluralité de composants logiciels, le procédé étant remarquable en ce qu'il comprend les étapes suivantes : -édition de la mémoire dudit calculateur, de sorte à obtenir une image mémoire de chacun desdits composants logiciels ; 15 - récupération, pour chacun desdits composants logiciels, à partir de son image mémoire, d'une information de cohérence adaptée à indiquer la cohérence dudit composant logiciel avec d'autres composants logiciels au sein du calculateur, d'une information de référence adaptée à identifier ledit composant logiciel et d'une information de validation adaptée à indiquer une validation du contenu dudit 20 composant après éventuelle reprogrammation ; détermination automatique du diagnostic du contenu logiciel du calculateur, en fonction d'au moins une partie desdites informations récupérées. Selon une variante de l'invention, l'étape de détermination du diagnostic comprend une analyse d'au moins une partie desdites informations pour chaque composant logiciel 25 pris indépendamment. Avantageusement, ladite analyse consiste à déterminer un statut absent ou présent desdites informations. En outre, il est suggéré d'analyser en combinaison l'information de cohérence avec l'information de validation dudit composant logiciel. 30 Selon un mode de réalisation, l'étape de détermination du diagnostic comprend une analyse d'au moins une partie desdites informations de chaque composant logiciel considéré les uns par rapport aux autres. Avantageusement, il est proposé de comparer entre elles les informations de cohérence de chaque composant logiciel. De préférence, l'étape de détermination du diagnostic comprend une comparaison 35 d'au moins une partie desdites informations de chaque composant logiciel avec leurs valeurs affectées lors d'une phase de conception du contenu logiciel du calculateur. 3 Selon un mode de réalisation avantageux, le procédé de diagnostic compare au moins l'information de cohérence et/ou l'information de référence récupérée(s) avec leur(s) valeur(s) affectée(s) lors de la phase de conception du contenu logiciel du calculateur. En outre, le procédé peut récupérer le code de chaque composant logiciel et le comparer avec le code mémorisé lors de la phase de conception. Le procédé conforme à l'invention peut être implanté dans un calculateur destiné à être embarqué dans un véhicule automobile, dédié à la gestion d'une fonction du véhicule. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles : la figure 1 illustre un exemple du contenu logiciel stocké dans une mémoire d'un calculateur ; - la figure 2 est un logigramme schématisant les principales opérations nécessaires à l'établissement du diagnostic du contenu logiciel du calculateur selon l'invention. La figure 1 présente le contenu logiciel d'un calculateur ECU stocké dans une mémoire 10 de celui-ci, par exemple une mémoire EEPROM (acronyme anglais pour "Electrically Erasable Programmable Read-Only Memory", c'est à dire "mémoire morte effaçable électriquement et programmable) ou une mémoire dite "mémoire flash". Sur le schéma, trois composants logiciels, respectivement 11, 12 et 13, sont représentés à titre d'exemple nullement limitatif en soi et constituent ainsi le contenu logiciel de la mémoire 10 du calculateur ECU. Un nombre bien plus important de composants logiciels 11, 12, 13 est en général constaté dans la réalité, mais l'exemple se limite ici à trois pour plus de clarté du propos. Une référence produit Ref ECU est classiquement affecté au calculateur ECU. On a vu que l'invention vise à permettre de réaliser simplement, avec fiabilité et automatiquement l'analyse du contenu logiciel du calculateur lorsque ce dernier est retourné à son fabricant suite à une panne par exemple, sachant que tout ou partie du contenu logiciel du calculateur a pu être modifié postérieurement à sa conception. Le fabricant à qui est retourné le calculateur ignore donc le contenu modifié du calculateur. On se propose alors d'utiliser un certain nombre d'informations produites pour chaque composant logiciel du calculateur lors de sa phase de conception logicielle et de recouper ces informations telles que produites à l'issue de la phase de conception, on parlera par la suite d'informations d'industrialisation pour qualifier ces informations, avec les informations du même type, récupérées à partir du calculateur ECU tel que retourné au fabricant suite à la détection d'un défaut de fonctionnement. 4 Les informations d'industrialisation sont mémorisées dans une base de données d'informations d'industrialisation, dans laquelle on peut retrouver l'ensemble des informations d'industrialisation de chacun des composants logiciels du calculateur ECU et leur emplacement dans la mémoire, à partir de la référence produit Ref_ECU identifiant le calculateur ECU. Les informations utilisées dans le cadre de la présente invention et qui vont être décrites plus en détail par la suite, sont des informations connues en tant que telles et associées à des fonctions particulières déjà prévues au sein de chaque composant logiciel, mais absolument pas liées au diagnostic à ce jour. Une autre caractéristique liée à ces informations est leur caractère générique, dans la mesure où il s'agit typiquement d'informations présentes dans tous composants logiciels produits, indépendamment de l'application véhicule envisagée ou du client auquel est fourni le calculateur. En particulier, on se propose d'utiliser, en plus du code constituant le composant logiciel lui-même, des informations se rapportant respectivement à la stratégie de cohérence, à la stratégie de reprogrammation et à la stratégie de référencement d'un composant logiciel donné. Chaque composant logiciel 11, 12 et 13 comprend en effet, en plus du code lui-même, respectivement 11 c, 12c et 13c, une information de cohérence, respectivement 11 a, 12a et 13a, une information de référence, respectivement 11 b, 12b et 13b, et une information de validation, respectivement 11 d, 12d et 13d. L'information de cohérence 11a, 12a, 13a est liée à la stratégie de cohérence du composant logiciel 11, 12, 13, laquelle doit permettre de s'assurer qu'un composant logiciel du calculateur ECU est cohérent avec un autre composant logiciel du calculateur ECU, en particulier qu'il n'y a pas de contradiction entre les données les constituant. Cette information de cohérence 11 a, 12a, 13a est classiquement disposée en début du composant logiciel 11, 12, 13. L'information de référence 11 b, 12b, 13b est une information propre au fabricant, liée à la stratégie de référencement, pour pouvoir identifier le composant logiciel 11, 12, 13 et correspond à un numéro de série de fabrication dudit composant logiciel 11, 12, 13. Enfin, l'information de validation 11d, 12d, 13d est quant à elle une information utilisée normalement dans le cadre de la fonction de reprogrammation du composant par le client. L'information de validation 11d, 12d, 13d comprend classiquement une clé de sécurité utilisée en tant que marqueur dans le code logiciel pour certifier que la reprogrammation s'est déroulée correctement. Typiquement, cette information de validation 11 d, 12d, 13d est écrite en fin du composant logiciel 11, 12, 13 après toute reprogrammation. Ces informations vont donc être utilisées selon l'invention aux fins d'établir le diagnostic du calculateur, en particulier en les combinant avec les informations d'industrialisation, c'est-à-dire ces mêmes informations, mais telles que produites en sortie de conception avant production et livraison au client. 5 Pour ce faire, en référence à la figure 2, une opération 20 d'édition de la mémoire 10 du calculateur ECU (appelée également "DUMP" en jargon technique) est mise en oeuvre, permettant l'obtention de l'image mémoire associée à chaque composant logiciel 11, 12, 13 du calculateur ECU, c'est-à-dire l'obtention d'une représentation du contenu total de la mémoire pour chaque composant. A partir de l'image mémoire ainsi obtenue associée à chaque composant logiciel 11, 12, 13 du calculateur ECU, on met en oeuvre une étape 30 de récupération, pour chaque composant logiciel, de l'information susmentionnée, qui sera utilisée en tout ou partie pour le diagnostic, à savoir l'information de cohérence 11a, 12a, 13a, l'information de référence 11b, 12b, 13b, l'information de validation 11d, 12d, 13d et le code 11 c, 12c, 13c. L'établissement 40 du diagnostic repose alors sur différentes analyses, prises seules ou en combinaison, sur lesquelles on reviendra plus en détail ci-après, parmi lesquelles : une analyse d'au moins une partie des informations récupérées pour chaque composant logiciel 11, 12, 13 pris indépendamment les uns des autres, une analyse d'au moins une partie des informations récupérées pour chaque composant logiciel 11, 12, 13 considéré les uns par rapport aux autres et une analyse visant à comparer au moins une partie des informations récupérées pour chaque composant logiciel 11, 12, 13 avec les informations d'industrialisation correspondantes mémorisées respectivement pour chacun des composants logiciels 11, 12, 13. Chacune de ces analyses est à même de fournir à elle seule des résultats de diagnostic mais, selon un mode de réalisation particulièrement avantageux, le diagnostic est de préférence établi sur la base d'une combinaison de ces différentes analyses. Toujours en référence à la figure 2, une analyse préliminaire 50 consiste à déterminer un statut absent ABS ou présent PRE pour chacune des informations récupérées pour chacun desdits composants logiciels 11, 12, 13 et, au cas où l'information concernée est déterminée comme étant présente, à vérifier si elle est différente DIFF ou identique ID par rapport à l'information d'industrialisation correspondante pour le composant logiciel 11, 12, 13 en question. Le statut absent ABS correspond en fait à l'absence d'information écrite à l'emplacement attendue dans la mémoire pour l'information concernée. 6 Afin de faciliter la lecture de la figure 2, les informations de cohérence 11 a, 12a, 13a sont représentées par COH, celles de validation 11 d, 12d, 13d par VAL, celles de référence 11 b, 12b, 13b par REF et le code 11 c, 12c, 13c par COD. La simple détermination du statut absent ABS ou présent PRE des informations récupérées pour chaque composant logiciel 11, 12, 13 pris indépendamment les uns des autres suffit déjà à établir un premier diagnostic, sans faire en plus référence aux informations d'industrialisation. En effet, pour un composant logiciel donné, si, par exemple, l'information de cohérence COH est présente PRE et que l'information de validation VAL est par contre absente ABS, alors on peut en déduire qu'une opération d'écriture a été initiée sans avoir été terminée, l'information de cohérence COH étant en effet située en début du composant logiciel 11, 12, 13 et l'information de validation à la fin, et auquel cas diagnostiquer une perte d'alimentation pendant l'opération d'écriture. A titre d'exemple encore, si l'information de cohérence COH est présente PRE et qu'une information est également présente à l'emplacement de validation en fin du composant logiciel mais est toutefois invalide, alors une perte d'alimentation pendant une opération d'effacement de la mémoire peut être diagnostiquée. Un autre exemple d'établissement de diagnostic selon une simple analyse du statut absent ou présent des informations récupérées pour chaque composant logiciel pris indépendamment les uns des autres, consiste à analyser le statut pour l'information de référence REF. Si cette dernière est absente ABS, alors on peut diagnostiquer qu'il s'agit d'un composant invalide. Comme déjà vu plus haut, l'établissement 40 du diagnostic peut consister à analyser au moins une partie des informations récupérées pour chaque composant logiciel 11, 12, 13, en les considérant également les unes par rapport aux autres. Une telle analyse comparée des informations correspondantes de chaque composant logiciel 11, 12, 13 repose en particulier sur la comparaison entre elles des informations de cohérence COH associées à chacun des composants logiciels 11, 12, 13. En effet, si par exemple deux informations de cohérence COH récupérées respectivement d'un premier et d'un second composant logiciel ne sont pas cohérentes entre elles, cela signifie que les deux composants logiciels concernés sont incompatibles. Enfin, l'établissement 40 du diagnostic peut comme on l'a vu reposer également sur une comparaison, composant par composant, des informations récupérées de chaque composant logiciel avec les informations d'industrialisation correspondantes pour chacun de ces composants logiciels. Comme on l'a vu, à partir de la référence produit fini Ref ECU du calculateur ECU, on peut retrouver dans la base de donnée l'ensemble des informations d'industrialisation 7 disponible pour l'ensemble des composants logiciels 11, 12, 13 constituant le calculateur ECU. Ainsi, par exemple, si les informations de cohérence COH et de code COD pour un composant donné sont différentes DIFF des informations d'industrialisation, on peut 5 diagnostiquer que le composant a été reprogrammé. Selon un autre exemple, si l'information de référence REF est identique ID à l'information correspondante d'industrialisation et que le code COD du composant est par contre différent DIFF de celui en sortie d'industrialisation, on peut diagnostiquer par exemple un contenu corrompu pour le composant logiciel en question. 10 Selon le mode de réalisation préféré, toutes les différentes analyses détaillées ci-dessus sont alors avantageusement recombinées à l'étape 40 pour établir le diagnostic du contenu logiciel du calculateur retourné aux équipes après-vente, permettant au minimum d'indiquer à ces équipes si le contenu et en particulier quel composant, a été reprogrammé ou non, corrompu ou non, ou encore d'indiquer des causes éventuels 15 d'anomalies etc. Le choix des différentes informations récupérées aux fins de ce diagnostic et leurs propriétés attachées permet avantageusement d'établir un diagnostic automatiquement et sans requérir pour ce faire de la part des équipes après-vente un niveau de compétence et d'expérience élevé en la matière. REVENDICATIONS 1. Procédé de diagnostic du contenu logiciel d'un calculateur (ECU) équipé d'une mémoire (10) stockant une pluralité de composants logiciels (11, 12, 13), caractérisé en ce qu'il comprend les étapes suivantes : édition (20) de la mémoire dudit calculateur, de sorte à obtenir une image mémoire de chacun desdits composants logiciels ; - récupération (30), pour chacun desdits composants logiciels à partir de son image mémoire, d'une information de cohérence (COH, 11 a, 12a, 13a) adaptée à indiquer la cohérence dudit composant logiciel avec d'autres composants logiciels au sein du calculateur, d'une information de référence (REF, 11 b, 12b, 13b) adaptée à identifier ledit composant logiciel et d'une information de validation (VAL, 11d, 12d, 13d) adaptée à indiquer une validation du contenu dudit composant après éventuelle reprogrammation ; - détermination (40) automatique du diagnostic du contenu logiciel du calculateur (10), en fonction d'au moins une partie desdites informations récupérées. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de détermination du diagnostic comprend une analyse d'au moins une partie desdites informations pour chaque composant logiciel pris indépendamment. 3. Procédé selon la revendication 2, caractérisé en ce que ladite analyse consiste à déterminer un statut absent (ABS) ou présent (PRE) desdites informations. 4. Procédé selon la revendication 2 ou 3, caractérisé en ce qu'il consiste à analyser en combinaison l'information de cohérence avec l'information de validation dudit composant logiciel. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de détermination du diagnostic comprend une analyse d'au moins une partie desdites informations de chaque composant logiciel considéré les uns par rapport aux autres. 6. Procédé selon la revendication 5, caractérisé en ce qu'il consiste à comparer entre elles les informations de cohérence de chaque composant logiciel. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que l'étape de détermination du diagnostic comprend une comparaison d'au moins une partie desdites informations de chaque composant logiciel avec leurs valeurs affectées lors d'une phase de conception du contenu logiciel du calculateur. 8. Procédé selon la revendication 7, caractérisé en ce qu'il consiste à 35 comparer au moins l'information de cohérence et/ou l'information de référencerécupérée(s) avec leur(s) valeur(s) affectée(s) lors de la phase de conception du contenu logiciel du calculateur. 9. Procédé selon la revendication 7 ou 8, caractérisé en ce qu'il consiste à récupérer le code (COD, 11 c, 12c, 13c) de chaque composant logiciel et à comparer ledit 5 code récupéré avec le code mémorisé lors de la phase de conception. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le calculateur est un calculateur destiné à être embarqué dans un véhicule automobile, dédié à la gestion d'une fonction du véhicule.