FR 3098952 A1 20210122 FR 1908195 A 20190719 Description Titre de l'invention : PROCEDE DE SECURISATION D'UN CAL- CULATEUR D'UN VEHICULE ET CALCULATEUR SECURISE DE VEHICULE Domaine technique 100011 L'invention concerne un procédé de sécurisation d'un calculateur de véhicule, notamment de type automobile, ainsi que le calculateur sécurisé via le procédé. Arrière-plan technologique [0002] Les véhicules contemporains embarquent nombre de calculateurs assurant chacun une ou plusieurs fonctions, telles que par exemple la gestion de l'aide à la conduite, de l'antipatinage, de la répartition électronique du freinage ou encore la commande d'actionneurs pour assurer le fonctionnement optimal d'un moteur à combustion. [0003] Ces calculateurs sont aussi appelés UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit »). Ces calculateurs embarquent des logiciels qui sont exécutés pour assurer les fonctions dont ils ont. la charge. Pour assurer la sécurité du conducteur et des passagers du véhicule, des mécanismes de contrôle des fonctions assurées par ces calculateurs sont. prévus. [0004] Cependant, la diversité des intervenants dans la conception et. le développement. de ces calculateurs et fonctions associées entrainent des couts de développement élevés pour les constructeurs automobiles notamment. Résumé de l'invention [0005] Un objet de la présente invention est de réduire les couts associés à la conception et l'intégration des calculateurs dans un véhicule automobile, tout en maintenant un niveau de sécurité élevé. [0006] Un autre objet de la présente invention est d'optimiser le fonctionnement d'un cal- culateur de véhicule en garantissant un niveau de sécurité maximal des fonctions mises en oeuvre dans le calculateur. [0007] Selon un premier aspect, l'invention concerne un procédé de sécurisation d'une fonction mise en oeuvre par un calculateur de véhicule, le procédé étant mis en oeuvre dans le calculateur, le procédé comprenant les étapes suivantes : [0008] - détermination d'au moins un paramètre de contrôle du véhicule par exécution de la fonction dans une première couche d'une architecture du calculateur ; [0009] - vérification du au moins un paramètre déterminé dans la première couche au moyen d'au moins un premier composant logiciel mis en oeuvre dans une deuxième couche de l'architecture du calculateur, le au moins un premier composant logiciel comprenant au moins une unité d'exécution, la au moins une unité d'exécution comprenant : 2 [0010] - une première opération correspondant à une requête d'un client pour réaliser un premier contrôle d'exécution sur un serveur avant mise en oeuvre de la vérification ; [0011] - une deuxième opération correspondant à une requête du client pour réaliser un deuxième contrôle d'exécution sur le serveur après mise en oeuvre de la vérification. [0012] Selon une variante, la première opération est une opération « start » d'une interface client/serveur AUTOSAR et la deuxième opération est une opération « stop » de l'interface client/serveur AUTOSAR. [0013] Selon une autre variante, la première opération est la première opération mise en oeuvre dans la au moins une unité d'exécution d'un point de vue temporel et la deuxième opération est la dernière opération mise en oeuvre dans la au moins une unité d'exécution d'un point de vue temporel. [0014] Selon une variante supplémentaire un paramètre de « timc-out » associé à la première opération et à la deuxième opération est mis à 0, aucun argument n'étant associé à la première opération et à la deuxième opération. [0015] Selon encore une variante, le premier contrôle d'exécution et le deuxième contrôle d'exécution sont mis en oeuvre au moyen d'au moins un deuxième composant logiciel par le serveur. [0016] Selon un deuxième aspect, l'invention concerne un calculateur de véhicule, le cal- culateur ayant une architecture à plusieurs couches, le calculateur comprenant une mémoire associée à au moins un processeur configure pour la mise en oeuvre des étapes du procédé selon le premier aspect de l'invention. [0017] Selon un troisième aspect, l'invention concerne un système embarqué de véhicule comprenant le calculateur tel que décrit ci-dessus selon le deuxième aspect de l'invention. [0018] Selon un quatrième aspect, l'invention concerne un véhicule, par exemple de type au- tomobile, comprenant un dispositif tel que décrit ci-dessus selon le deuxième aspect de l'invention ou un système embarqué tel que décrit ci-dessus selon le troisième aspect de l'invention. [0019] Selon un cinquième aspect, l'invention concerne un programme d'ordinateur qui comporte des instructions adaptées pour l'exécution des étapes du procédé selon le premier aspect de l'invention, ceci notamment lorsque le programme d'ordinateur est exécuté par au moins un processeur. [0020] Un tel programme d'ordinateur peut utiliser n'importe quel langage de pro- grammation, et être sous la forme d'un code source, d'un code objet, ou d'un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0021] Selon un sixième aspect, l'invention concerne un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des ins- 3 Éructions pour l'exécution des étapes du procédé selon le premier aspect de l'invention. [0022] D'une part, le support d'enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. [0023] D'autre part, ce support d'enregistrement peut également être un support trans- missible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0024] Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d'ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures [0025] D'autres caractéristiques et avantages de l'invention ressortiront de la description des modes de réalisation non limitatifs de l'invention ci-après, en référence aux figures 1 à 4 annexées, sur lesquelles : [0026] [fig.1] illustre de façon schématique une architecture de calculateur de véhicule, selon un exemple de réalisation particulier de la présente invention ; [0027] [fig.2] illustre schématiquement une communication de type client/serveur mise en oeuvre dans le calculateur de la figure I, selon un exemple de réalisation particulier de la présente invention ; [0028] [fig.3] illustre schématiquement le calculateur de la figure 1, selon un exemple de réalisation particulier de la présente invention ; [0029] [fig.4] illustre un organigramme des différentes étapes d'un procédé de sécurisation d'une fonction mise en oeuvre par le calculateur de la figure 1, selon un exemple de réalisation particulier de la présente invention. Description des modes de réalisation 100301 Un procédé de sécurisation d'une fonction mise en oeuvre par un calculateur de véhicule et le calculateur exécutant la fonction et la sécurisation associée vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 4. Des mêmes éléments sont identifiés avec des mêmes signes de référence tout au long de la description qui va suivre. 100311 Selon un exemple particulier et non limitatif de réalisation de l'invention, un procédé de sécurisation d'une (ou plusieurs) fonction(s) mise(s) en oeuvre par un calculateur de véhicule comprend la détermination d'un (ou plusieurs) paramètre(s) de contrôle du véhicule obtenue par l'exécution de la fonction dans une première couche du calculateur. La première couche est aussi appelée niveau 1 dans une architecture qui comprend par exemple 3 couches (ou 3 niveaux). Le paramètre de contrôle est vérifié par au moins un composant logiciel SWC (de l'anglais « Software Componcnt ») exécuté dans une deuxième couche (niveau 2) de l'architecture du calculateur. Cc composant logiciel comprend une (ou plusieurs) unité(s) d'exécution (de l'anglais « Runnablc Unit »). L'unité d'exécution comprend une première opération correspondant à une requête d'un client pour réaliser un premier contrôle d'exécution sur un serveur avant mise en oeuvre de la vérification du paramètre de contrôle obtenu via l'exécution de la fonction, et une deuxième opération correspondant à une requête du client pour réaliser un deuxième contrôle d'exécution sur le serveur après mise en oeuvre de la vérification. [0032] La première opération correspond avantageusement à une opération « start » d'une interface client/serveur AUTOSAR (de l'anglais « AUTomotive Open System Architecture » ou en français « Architecture système ouverte pour l'automobile ») et la deuxième opération correspond avantageusement à une opération « stop » de l'interface client/serveur AUTOSAR. [0033] La mise en oeuvre de requêtes effectuées par un client à un serveur dans le cadre d'une unité d'exécution d'un composant logiciel de niveau 2 permet d'appeler l'exécution des opérations au niveau d'un serveur, c'est-à-dire hors de l'unité d'exécution. Cela autorise l'utilisation d'une unité d'exécution générique appelant des opérations particulières, par exemple développées par un tiers. L'utilisation d'unité d'exécutions génériques permet de réduire les coûts de développement en limitant la diversité de ces unités d'exécutions. [0034] Par ailleurs, lorsque la première opération et la deuxième opération correspondent à des opérations d'une interface client/serveur tel que définie dans standard AUTOSAR, les prérequis définis dans le standard AUTOSAR sont automatiquement remplis, garantissant un fonctionnement relatif aux vérifications de sécurité conforme à ce qui est attendu. [0035] [fig.1] illustre schématiquement une architecture 1 d'un calculateur de véhicule de type UCE, selon un exemple de réalisation particulier et non limitatif de la présente invention. [0036] L'architecture 1 est une architecture à 3 couches ou 3 niveaux 11, 12 et 13. Selon l'exemple particulier de la figure 1, le calculateur est un calculateur CMM (« Calculateur Moteur Multifonction ») dont la sécurisation suit les recommandations publiées par le groupe de travail VDA (de l'allemand « Verband der Automobilindustrie » ou en français « Groupement de l'industrie automobile »). Cette sécurisation est appelée Sécurisation 3 niveaux (de l'anglais « 3 levels Safety ») puisqu'elle se décompose en 3 niveaux 11, 12 et 13. Bien entendu, la même sécurisation s'applique à d'autres calculateurs différents du CMM. [0037] Le premier niveau 11 (ou première couche 11, par exemple logicielle, de l'architecture 1) correspond à un niveau fonctionnel responsable de la mise en oeuvre de la ou les fonctions 111 assurées par le calculateur pour garantir un bon fonctionnement du calculateur. A titre d'exemple, une fonction assurée par le CMM est le calcul ou la détermination du couple développé par le moteur en fonction de paramètres ou signaux d'entrée 101 tels que la pression exercée sur la pédale d'accélérateur. En sortie de la fonction sont obtenus des signaux ou paramètres de sortie 102, en l'occurrence le couple déterminé par la fonction à partir des paramètres d'entrée pour contrôler/commander le moteur. [0038] Le deuxième niveau 12 (ou deuxième couche 12, par exemple logicielle, de l'architecture 1) correspond au niveau de surveillance ou de vérification du premier niveau 11. Le deuxième niveau 11 utilise les mêmes paramètres d'entrée 101 que ceux du premier niveau 11 pour déterminer ou calculer des paramètres de sortie et ainsi vérifier 121 que les paramètres de sortie déterminées par la fonction au premier niveau 11 sont corrects ou conformes à ce qui est attendu en fonction de la situation courante (c'est-à-dire les paramètres d'entrée). Si tel est le cas, la commande effectuée par le premier niveau 11 est validée, sinon la commande est bloquée. [0039] Le troisième niveau 13 (ou troisième couche 13, par exemple logicielle, de l'architecture 1) correspond à un autre niveau de surveillance ou de vérification, mais au niveau matériel (de l'anglais « hardware ») alors que le deuxième niveau focalisait la surveillance ou la vérification au niveau logiciel. Les vérifications faites au troisième niveau comprennent également une vérification que les tests (surveillances) effectués au deuxième niveau 12 ont bien été appelés (ou exécutés) et ce dans le bon ordre. Cette vérification est dénommée « Contrôle d'exécution » PFC 131 (de l'anglais « Program Flow Check » ou en français « vérification du flux de programme »). Les contrôles d'exécution sont nombreux et propres aux fonctions à vérifier. Les contrôles d'exécution sont ainsi des vérifications de deuxième niveau en ce qu'ils vérifient la bonne exécution et le bon déroulement chronologique des vérifications faites au deuxième niveau. Le résultat de la vérification est par exemple transmis à un module de surveillance 132 qui valide ou non les paramètres de sortie 102. [0040] Les contrôles d'exécution 131 associées à une fonction 111 sont avantageusement mis en oeuvre sous la forme d'un ou plusieurs composants logiciels SWC, tels que définis dans le standard AUTOSAR. Les modèles de tels composants logiciels sont par exemple définis dans le document intitulé « Software Component Template », version 4.5.0 publié le 31 mars 2014. Un composant logiciel correspond à l'élément structurel central utilisé lors de la génération d'un système au niveau d'un bus fonctionnel virtuel 6 VFB (de l'anglais « Virtual Functional Bus »). Un composant logiciel possède des ports au travers desquels le composant logiciel peut interagir avec d'autres composants logiciels. A chaque port du composant logiciel est assignée une interface de port qui décrit les données ou opérations qui sont fournies ou requises par le composant logiciel via le port auquel est assignée l'interface de port. [0041] De manière avantageuse, les interfaces de port utilisées sont des interfaces de type client/serveur, tel que définies dans le standard AUTOSAR. Une interface client/ serveur est une interface de port utilisée dans le cadre de communication(s) client/ serveur. L'interface client/serveur définit les opérations qui sont fournies (ou mises en oeuvre) par le serveur et qui peuvent être utilisées par le client. Une interface client/ serveur permet à un client d'appeler une opération sur un serveur, qui en retour fournit le résultat de l'opération au client. [0042] Une communication client/serveur correspond à une communication dans laquelle des entités logicielles (par exemple des unités ou entités d'exécution (de « Runnahle Entity ») comprises dans le composant logiciel) agissent comme des clients qui requièrent des services via un protocole déterminé à un serveur. Les clients prennent l'initiative de requérir que le serveur exécute un service, par exemple un client déclenche une action ou une opération dans un serveur, le serveur ne déclenchant pas l'action ou l'opération de son propre chef. Le serveur transmet en retour le résultat de l'action ou l'opération mise en oeuvre. [0043] Une unité (ou entité) d'exécution (aussi appelée « Runnable Entity » en anglais) correspond à une partie d'un composant logiciel qui peut être exécutée et programmée indépendamment des autres unités d'exécution compris dans le même composant logiciel. Chaque unité d'exécution est mise en oeuvre par une fonction du composant et comprend une série d'instructions ou d'opérations. [0044] Selon l'invention, un composant logiciel assurant la vérification de la fonction Ill comprend une ou plusieurs entités d'exécution. Chaque unité d'exécution comprend une première opération une première opération correspondant à une requête d'un client à un serveur pour que ce dernier réalise un premier contrôle d'exécution PFC avant la mise en oeuvre par l'entité d'exécution de l'opération de vérification de la fonction Ill. Chaque entité d'exécution comprend également une deuxième opération correspondant à une requête du client au serveur pour réaliser un deuxième contrôle d'exécution la mise en oeuvre par l'entité d'exécution de l'opération de vérification de la fonction Ill. Les communications établies par ces unités d'exécution correspondent avantageusement à des communications client/serveur. Ainsi, les unités d'exécution du composant logiciel assurant la vérification de niveau 2 de la fonction 111 agissent comme un client dans le cadre d'une interface client/serveur. Ces clients font appel à des serveurs (correspondant à d'autres composants logiciels) pour l'exécution ou la 7 mise en oeuvre des contrôles d'exécution PFC de la fonction 111. Cela permet d'avoir des unités d'exécution génériques (et donc un composant logiciel générique comprenant ces unités d'exécutions génériques), c'est-à-dire des unités d'exécution qui émettent simplement des requêtes d'exécution d'opération au niveau d'autres composants logiciels (serveur) qui eux sont spécifiques. [0045] Un exemple d'une telle unité d'exécution générique faisant appel à des unités d'exécution spécifiques dans le cadre d'une communication client/serveur est décrit en regard de la figure 2. [0046] [fig.2] illustre schématiquement une communication de type client/serveur mise en oeuvre dans le calculateur de la figure 1, selon un exemple de réalisation particulier et non limitatif de la présente invention. [0047] La figure 2 illustre une unité d'exécution 21 formant le client dans le cadre d'une interface client/serveur associé à un port du premier composant logiciel SWC 131 comprenant l'unité d'exécution. Dans une première opération 211, une requête 2110 est transmise à un deuxième composant logiciel SWC 22 (ou à une unité d'exécution 221 du deuxième composant logiciel 22), ce dernier faisant office de serveur en cc qu'il exécute des instructions 2210 pour réalisation d'une fonctionnalité de type contrôle d'exécution PFC. La première opération 211 correspond par exemple à un appel d'une opération « start » (ou « démarrage » en français) de l'interface client/ serveur conforme au standard AUTOSAR et lié au PFC mis en oeuvre par le SWC 22, un time-out de 0 étant associée à cette opération « start », sans argument. En retour, le résultat 2111 du PFC exécuté par le SWC 22 est transmis à l'unité d'exécution 21. [0048] L'opération 211 est la première exécutée par l'unité 21 avant toute autre fonc- tionnalité, par exemple avant la fonctionnalité 212. [0049] La dernière opération exécutée par l'unité 21 (après toute autre fonctionnalité telle que la fonctionnalité 212) correspond à la deuxième opération 213. Dans cette deuxième opération 213, une requête 2310 est transmise au deuxième composant logiciel SWC 22 (ou à une unité d'exécution 222 du deuxième composant logiciel 22), ce dernier faisant office de serveur en ce qu'il exécute des instructions 2220 pour réalisation d'une fonctionnalité de type contrôle d'exécution PFC. La deuxième opération 213 correspond par exemple à un appel d'une opération « stop » de l'interface client/ serveur conforme au standard AUTOSAR et lié au PFC mis en oeuvre par le SWC 22, un time-out de 0 étant associée à cette opération « stop », sans argument. En retour, le résultat 2311 du PFC exécuté par le SWC 22 est transmis à l'unité d'exécution 21. [0050] Bien entendu, plusieurs unités d'exécution similaire à l'unité 21 peuvent être comprises dans le SWC faisant office de client dans l'interface client/serveur AUTOSAR et la communication client/serveur mise en place. Ces unités d'exécution ont l'avantage d'être génériques en ce qu'elles comprennent simplement des opérations 8 appelant l'exécution de PFC au niveau d'autres SWC qui eux peuvent être particuliers et développés par des fournisseurs différents. Les unités d'exécution dites génériques ont l'avantage d'avoir toute une même structure, telle que celle décrite en regard de la figure 2. [0051] [fig.3] illustre schématiquement un calculateur 3 configure pour la mise en oeuvre des étapes/opérations du procédé décrit en regard de l'une des figures 1, 2 et/ou 4, selon un exemple de réalisation particulier et non limitatif de la présente invention. L'architecture logicielle du calculateur 3 correspond avantageusement à celle décrite en regard de la figure 1. [0052] Des exemples d'un tel calculateur 3 comprennent, sans y être limités, un équipement électronique embarqué tel qu'un ordinateur de bord d'un véhicule ou un calculateur électronique tel qu'une UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit »). Les éléments du calculateur 3, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le calculateur 3 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d'une combinaison de circuits électroniques et de modules logiciels. Selon différents modes de réalisation particuliers, le calculateur 3 est couplé en communication avec d'autres dispositifs ou systèmes similaires, par exemple par l'intermédiaire d'un bus de communication ou au travers de ports d'entrée / sortie dédiés. [0053] Le calculateur 3 comprend un (ou plusieurs) processeur(s) 30 configurés pour exécuter des instructions pour la réalisation des étapes du procédé et/ou pour l'exécution des instructions du ou des logiciels embarqués dans le calculateur 3. Le processeur 30 peut inclure de la mémoire intégrée, une interface d'entrée/sortie, et différents circuits connus de l'homme du métier. Le calculateur 3 comprend en outre au moins une mémoire 31 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. [0054] Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké dans la mémoire 31. [0055] Selon un mode de réalisation particulier et non limitatif, le calculateur 3 comprend un bloc 32 d'éléments d'interface pour communiquer avec des dispositifs externes, par exemple un serveur distant ou le « cloud », des émetteur et/ou capteurs/récepteurs du système de télémétrie du véhicule, des capteurs odométriques, un capteur GPS et/ou tout autre capteur. Les éléments d'interface du bloc 22 comprennent une ou plusieurs des interfaces suivantes : 9 [0056] - interface radiofréquence RF, par exemple de type Bluctooth® ou Wi-Fi®, LTE (de l'anglais « Long-Terni Evolution » ou en français « Evolution à long terme »), LTEAdvanced (ou en français LTE-avancé) ; [0057] - interface USB (de l'anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ; [0058] - interface HDMI (de l'anglais « High Definition Multimedia Interface ou « Interface Multimedia Haute Définition » en français) ; [0059] - interface LIN. [0060] Des données sont par exemples chargées vers le calculateur 3 via l'interface du bloc 32 en utilisant un réseau Wi-Ei® tel que selon IEEE 802.11, Bluetooth® ou un réseau mobile tel qu'un réseau 4G (ou LTE Advanced selon 3GPP release 10 - version 10) ou 5G. [0061] Selon un autre mode de réalisation particulier, le calculateur 3 comprend une interface de communication 33 qui permet d'établir une communication avec d'autres dispositifs (tels que d'autres calculateurs du système embarqué ou une TCU) via un canal de communication 330. L'interface de communication 33 correspond par exemple à un transmetteur configure pour transmettre et recevoir des informations et/ ou des données via le canal de communication 330. L'interface de communication 33 correspond par exemple à un réseau filaire de type CAN ou CAN FD. [0062] Selon un mode de réalisation particulier supplémentaire, le calculateur 3 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu'un écran d'affichage, un ou des haut-parleurs et/ou d'autres périphériques via respectivement des interfaces de sortie non représentées. [0063] [fig.4] illustre un organigramme des différentes étapes d'un procédé de, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le procédé est avantageusement mis en oeuvre dans le calculateur 3 de la figure 1. [0064] Dans une première étape 41, un ou plusieurs paramètres de contrôle d'un véhicule sont déterminés par l'exécution d'une ou plusieurs fonctions dans une première couche de l'architecture d'un calculateur. [0065] Dans une deuxième étape 42, le ou les paramètres obtenus à l'étape 41 sont vérifiés au moyen d'un ou plusieurs (premiers) composants logiciels mis en oeuvre dans une deuxième couche de l'architecture du calculateur. Le (premier) composant logiciel SWC comprend une ou plusieurs unités d'exécution (« Runnable Unit(s) ») mettant en oeuvre : [0066] - une première opération correspondant à une requête d'un client pour réaliser un premier contrôle d'exécution (PFC) sur un serveur avant mise en oeuvre de la fonction ou fonctionnalité permettant de vérifier le résultat de la fonction mise en oeuvre dans la première couche, le client correspondant au premier SWC et le serveur à un deuxième SWC différent du premier SWC dans le cadre d'une interface client/serveur définie par le standard AUTOSAR par exemple ; [0067] - une deuxième opération correspondant à une requête du client pour réaliser un deuxième contrôle d'exécution (PFC) sur le serveur après mise en oeuvre de la vérification. [0068] Bien entendu, l'invention ne se limite pas aux modes de réalisation décrits ci-avant mais s'étend à une architecture logicielle d'un calculateur de véhicule. [0069] L'invention concerne également un véhicule, par exemple automobile ou plus géné- ralement un véhicule à moteur terrestre, comprenant le calculateur 3 de la figure 3. 11 REVENDICATIONS[Revendication 1] Procédé de sécurisation d'une fonction (111) mise en oeuvre par un cal- culateur (3) de véhicule, ledit procédé étant mis en oeuvre dans ledit calculateur (3), ledit procédé comprenant les étapes suivantes : - détermination (41) d'au moins un paramètre de contrôle dudit véhicule par exécution de ladite fonction dans une première couche (11) d'une architecture (1) dudit calculateur ; - vérification (42) dudit au moins un paramètre déterminé dans ladite première couche (11) au moyen d'au moins un premier composant logiciel mis en oeuvre dans une deuxième couche (12) de ladite architecture dudit calculateur, ledit au moins un premier composant logiciel comprenant au moins une unité d'exécution (21), ladite au moins une unité d'exécution (21) comprenant : - une première opération (211) correspondant à une requête client pour réaliser un premier contrôle d'exécution (221) sur un serveur (22) avant mise en oeuvre de ladite vérification ; - une deuxième opération (213) correspondant à une requête client pour réaliser un deuxième contrôle d'exécution (222) sur ledit serveur (22) après mise en oeuvre de ladite vérification. [Revendication 2] Procédé selon la revendication 1, pour lequel ladite première opération (211) est une opération « start » d'une interface client/serveur AUTOSAR et ladite deuxième opération (213) est une opération « stop » de ladite interface client/serveur AUTOSAR. [Revendication 3] Procédé selon la revendication 1 ou 2, pour lequel ladite première opération (211) est la première opération mise en oeuvre dans ladite au moins une unité d'exécution (21) d'un point de vue temporel et ladite deuxième opération (213) est la dernière opération mise en oeuvre dans ladite au moins une unité d'exécution (21) d'un point de vue temporel. [Revendication 4] Procédé selon l'une des revendications 1 à 3, pour lequel un paramètre de « Lime-out» associé à la première opération (211) et à la deuxième opération (213) est mis à 0, aucun argument n'est associé à la première opération (211) et à la deuxième opération (213). [Revendication 5] Procédé selon l'une des revendications 1 à 4, pour lequel le premier contrôle d'exécution (221) et. le deuxième contrôle d'exécution (222) sont mis en oeuvre au moyen d'au moins un deuxième composant logiciel par ledit serveur. [Revendication 6] Calculateur (3) de véhicule, ledit. calculateur ayant une architecture à 12 [Revendication 7] plusieurs couches (11 à 13), ledit calculateur (3) comprenant une mémoire (31) associée à au moins un processeur (30) configure pour la mise en oeuvre des étapes du procédé selon l'une quelconque des revendications 1 à 5. [Revendication 8] Système embarqué de véhicule comprenant le calculateur selon la revendication 6. [Revendication 9] Véhicule automobile comprenant le calculateur (3) selon la revendication 6 ou le système embarqué selon la revendication 7. Produit programme d'ordinateur comportant des instructions adaptées pour l'exécution des étapes du procédé selon l'une des revendications 1 à 5, lorsque le programme d'ordinateur est exécuté par au moins un processeur.