CALCULATEUR ELECTRONIQUE DE CONTROLE EMBARQUE DANS UN VEHICULE [0001 L'invention concerne les dispositifs de contrôle électronique des véhicules, et 5 en particulier les calculateurs de contrôle mettant en oeuvre des fonctions de sécurité. [0002] Avant les années 80, l'innovation concernant les véhicules automobiles a porté essentiellement sur leur partie mécanique. Dorénavant, on estime que la plupart des évolutions entre les différentes générations de véhicules portent sur leur 10 conception électronique. Par conséquent, la complexité des systèmes électroniques embarqués dans les véhicules s'accroît régulièrement. [0003] L'augmentation du nombre de composants électroniques intégrés dans un véhicule a induit un certain nombre de problèmes dus à la complexité et à la diversité des réseaux et des calculateurs utilisés. Des problèmes de développement d'un 15 calculateur peuvent ainsi générer des problèmes de qualité induisant des manques de fiabilité et nécessitant parfois de coûteuses campagnes de rappel des véhicules. [0004] En pratique, et en particulier pour les calculateurs de contrôle moteur, les constructeurs de véhicules automobiles diversifient les fournisseurs de fonctions logicielles mises en oeuvre dans un même calculateur. Cette diversification vise 20 notamment à utiliser les compétences spécifiques des différents fournisseurs. Un certain nombre de fonctions logicielles sont des fonctions critiques pour garantir la sécurité de fonctionnement du véhicule. Dans la plupart des cas, ces fonctions logicielles restent des solutions propriétaires et leur fonctionnement précis reste confidentiel. Le fonctionnement algorithmique de telles fonctions critiques reste 25 généralement non connu ou du moins mal connu même d'un fournisseur intégrateur. Le fournisseur intégrateur est responsable de la partie matérielle et de l'électronique du calculateur. Le fournisseur intégrateur définit également la structure du logiciel de base faisant appel aux différentes fonctions critiques. Le fournisseur intégrateur intègre les différentes fonctions fournies, sous forme modulaire, dans le calculateur. 30 [0005] Afin de garantir une interopérabilité et une standardisation satisfaisante des formats d'interfaces des différentes fonctions, à commencer par les fonctions critiques, développées par les fournisseurs, des normes, telles que les normes établies par le consortium Autosar, définissent un certain nombre de règles à respecter pour les fonctions des calculateurs. Ces normes visent notamment à mettre en oeuvre des fonctions critiques indépendantes du matériel sur lequel elles sont installées. Ces normes définissent ainsi une architecture logicielle à plusieurs couches aboutissant à une abstraction totale du matériel. Pour cela, l'architecture doit comprendre une couche d'abstraction standard servant de base commune à toutes les installations de logiciels embarqués. Sous cette couche, des couches basses assurent l'abstraction du microcontrôleur du calculateur. [0006 La norme ISO 26262 décrit un certain nombre d'exigences de fonctionnement des fonctions de sécurité d'un calculateur. Ces exigences sont difficilement compatibles avec un maintien confidentiel des algorithmes exécutés. Les fonctions de sécurité doivent notamment disposer d'un accès direct ou surveillé aux informations critiques provenant des capteurs ou des réseaux de communication. La norme impose également la mise en oeuvre d'une analyse de risques, induisant le classement de chaque risque identifié en fonction de sa gravité. Les applications sont alors gérées différemment en fonction des degrés de risques qu'elles sont amenées à gérer. [0007] En pratique, le fournisseur intégrateur n'ayant pas accès aux algorithmes codés des fonctions critiques il s'avère particulièrement délicat de développer une structure de surveillance logicielle assurant la sécurité de fonctionnement de l'ensemble du calculateur. Par ailleurs, le constructeur du véhicule peut craindre de n'avoir qu'une visibilité réduite sur la sécurité du véhicule, du fait de la confidentialité des fonctions critiques. [000si L'invention vise à résoudre un ou plusieurs de ces inconvénients. L'invention porte ainsi sur un calculateur électronique de contrôle pour véhicule automobile, caractérisé en ce qu'il comprend une architecture comprenant une couche matérielle, un environnement standardisé d'exécution d'applications recevant des paramètres transmis par la couche matérielle ; au moins un module applicatif dont le codage est obfusqué générant des paramètres de sortie du module applicatif en fonction de paramètres d'entrée transmis par l'environnement standardisé et au moins un module de sécurité, comportant au moins un module logiciel simplifié du module applicatif générant de façon redondante des paramètres de sortie en fonction de paramètres d'entrée transmis par l'environnement standardisé d'exécution d'applications et un module de surveillance comparant les paramètres de sortie du module logiciel de sécurité avec les paramètres de sortie du module applicatif, le module de surveillance générant un signal d'erreur en cas de divergence entre les paramètres de sortie [0009] Avantageusement, le calculateur électronique de contrôle comporte deux moyens indépendants de transmission des paramètres d'entrée au module logiciel de sécurité ou au module applicatif. [0010] Selon une variante, ladite architecture est conforme à une spécification Autosar. [0011] Selon une autre variante, le calculateur est un calculateur de contrôle moteur. [0012] Selon encore une variante, le module logiciel de sécurité est indépendant du module logiciel simplifié conformément à la norme ISO 26262-2. [0013] Selon encore une autre variante, le module logiciel de sécurité gère des fonctions présentant des risques classés en niveau C ou D de la hiérarchie ASIL de la norme ISO 26262. [0014] Selon une variante, le module logiciel simplifié présente également un codage obfusqué. [0015] La présente invention a également pour objet un véhicule automobile comprenant un calculateur tel que décrit ci-dessus, un capteur et un réseau de communication connectés à la couche matérielle du calculateur. [0016] D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est faite ci-après, à titre indicatif et nullement limitatif, en référence au dessin annexé, dans lequel : • la figure 1 illustre une représentation schématique de l'architecture d'un calculateur selon l'invention. [0017] L'invention propose de générer de façon redondante des paramètres de sortie d'un module logiciel de sécurité obfusqué embarqué dans un calculateur électronique de contrôle. Le module logiciel de sécurité génère des paramètres de sortie à partir de paramètres d'entrée appliqués par une couche matérielle. De façon redondante, un module logiciel simplifié génère ces paramètres de sortie en fonction de paramètres d'entrée transmis par un environnement logiciel standardisé d'exécution d'applications. Un module de surveillance génère un signal d'erreur si les paramètres de sortie du module logiciel de sécurité et du module logiciel simplifié diffèrent. Un basculement en mode dégradé ou des mesures de sécurité appropriées peuvent alors être prises. [ools] L'invention permet ainsi à un fournisseur intégrateur du calculateur de disposer de garanties sur le contrôle de sécurité de modules logiciels de sécurité restant confidentiels. Par ailleurs, le contrôle de sécurité peut être réalisé en conformité avec des normes de développement d'applications, et en conformité avec des normes de sécurité imposant l'absence d'interférence entre le module logiciel de sécurité et le module simplifié assurant sa redondance. [0019] La figure 1 est une représentation schématique d'un calculateur de contrôle 1 selon l'invention. En l'occurrence, le calculateur 1 est un calculateur de contrôle moteur. Le calculateur 1 illustré présente une architecture conforme à une spécification définie par le consortium Autosar. À cet effet, l'architecture du contrôleur 1 comprend une couche matérielle 2, un environnement logiciel standardisé d'exécution d'applications 3, une interface applicative 4 et une couche de redondance 5. Bien que non illustrée, une couche d'applications diverses conformes aux spécifications Autosar peut également être incluse dans l'architecture. [0020] La couche matérielle 2 comprend notamment une interface d'entrées/sorties destinée à communiquer soit avec différents capteurs, soit avec des réseaux de communication. Dans l'exemple illustré, les interfaces d'entrées/sorties sont connectées d'une part à un capteur 8, et d'autre part à un réseau de communication 9 tel qu'un réseau CAN. Les interfaces d'entrées/sorties permettent de recevoir des informations brutes en provenance de capteurs ou de réseaux, et de renvoyer des commandes à destination de capteurs ou de réseaux. La couche matérielle 2 comprend par ailleurs des moyens de traitement, par exemple un ou plusieurs microcontrôleurs. [0021] L'environnement d'exécution 3 est destiné à fournir un environnement d'exécution pour différentes applications à exécuter. Pour rendre cet environnement d'exécution 3 indépendant de la couche matérielle 2, une couche d'abstraction du matériel peut être interposée entre la couche matérielle 2 et l'environnement d'exécution 3. Un environnement d'exécution 3 standardisé peut ainsi être utilisé. [0022] Un module applicatif 5 comprend différentes applications logicielles 51 à 5n dont le codage est obfusqué. L'obfuscation du code d'un logiciel est connue en soi et vise par différentes techniques à rendre un logiciel inintelligible par rétro-ingénierie. Les applications logicielles 51 à 5n conservent ainsi des algorithmes confidentiels. Les applications logicielles 51 à 5n génèrent des paramètres de sortie sur la base de paramètres d'entrée fournis par la couche matérielle 2. Parmi les applications logicielles 51 à 5n, un certain nombre sont considérés comme critiques car touchant à des fonctions de sécurité du véhicule embarquant le calculateur 1. [0023] Par l'intermédiaire d'une couche applicative 4, la couche de redondance peut être exécutée au moyen de l'environnement d'exécution 3. La couche de redondance ou module de sécurité comprend différents modules logiciels simplifiés 71 à 7n. Ces modules logiciels simplifiés 71 à 7n correspondent à des versions allégées respectives des applications logicielles 51 à 5n. Ces modules logiciels simplifiés 71 à 7n visent ainsi à générer de façon redondante des paramètres de sortie de leurs applications logicielles 51 à 5n, sur la base de paramètres d'entrée fournit par l'environnement d'exécution 3. [0024] Les modules logiciels simplifiés pourront par exemple inclure uniquement la partie des algorithmes permettant d'aboutir de façon redondante à ces paramètres de sortie. Chaque fournisseur d'une application logicielle fournira également un module logiciel simplifié permettant au fournisseur intégrateur de procéder à des tests de sécurité satisfaisants. En pratique, les modules logiciels simplifiés 71 à 7n sont conformes à l'architecture standardisée afin de pouvoir être exécutés par l'environnement d'exécution 3. Les modules logiciels simplifiés 71 à 7n peuvent être des applications logicielles standardisées indépendantes les unes des autres, renforçant ainsi l'indépendance des différentes fonctions de surveillance. Les modules logiciels simplifiés 71 à 7n seront également avantageusement obfusqués afin d'éviter une rétro ingénierie même partielle des algorithmes des applications logicielles 51 à 5n. [0025] Les paramètres de sortie fournis par les applications logicielles 51 à 5n et les paramètres de sortie redondants générés par les modules logiciels simplifiés 71 à 7n sont appliqués sur un module de comparaison 6. Si le module de comparaison 6 constate une divergence entre un paramètre de sortie et la version redondante de ce paramètre de sortie, il génère un signal d'erreur. [0026] Une telle architecture aboutit à des redondances sur les paramètres de sortie tout en garantissant l'indépendance entre une application logicielle et un module logiciel simplifié, conformément aux exigences de la norme ISO 26262-2. L'invention s'avère par ailleurs particulièrement avantageuse pour des applications logicielles de sécurité gérant des fonctions présentant des risques classés en niveau C ou D de la hiérarchie ASIL définie dans la norme ISO 26262. [0027] Avantageusement, des données critiques pourront être transmises entre les applications logicielles 51 à 5n selon des mécanismes de sécurisation tels que le `End-ta-End protection' défini dans les spécifications Autosar.