FR3113149A1 - Formatage d’informations de défaut par ajout d’identifiant - Google Patents

Abstract

L’invention concerne un procédé et un dispositif de formatage d’une information de défaut d’au moins un calculateur compris sur un véhicule terrestre à moteur (VEH). FIG. 1

Description

Formatage d’informations de défaut par ajout d’identifiant

La présente invention appartient au domaine de l’électronique embarquée dans un véhicule terrestre à moteur. En particulier, il concerne la gestion de la transmission de trames comportant des informations sur des défauts du véhicule, les défauts étant identifiés par les calculateurs du véhicule.

On entend par « véhicule terrestre à moteur » tout type de véhicule tel qu’un véhicule automobile, un cyclomoteur, une motocyclette, un robot de stockage dans un entrepôt, etc.

On entend par « information sur un défaut » tout type de données caractérisant par exemple un état, une erreur matérielle, logicielle ou encore fonctionnelle ou encore un paramètre de fonctionnement d’un dispositif, typiquement un capteur et/ou un actionneur, du véhicule relié à un calculateur.

L’évolution de l’électronique au sein des véhicules automobiles d’aujourd’hui permet notamment depuis l’avènement et l’intégration des technologies de connexion dites Over The Air (connexion sans fil de type 3G/4G, WIFI, …) de développer une multitude de fonctionnalités regroupées sous le vocable de services connectés. Ces services connectés, en fonction de l’utilisation qui peut en être faite sont soumis à différentes contraintes ou règlements. On peut citer par exemple sans que cela soit exhaustif, le règlement général de la protection des données RGDP (respect de la vie privée) pour les services à la personne applicable en Europe, ou encore le règlement RMI (Repair and Maintenance Information, information de réparation et de maintenance en français) relatif à la réparation et la maintenance d’un véhicule automobile demandant au constructeur automobile une mise à disposition sans discrimination de ce type d’informations pour tout réparateur de son réseau propre ou d’un réseau indépendant.

Ces règlementations ne détaillent cependant ni les mécanismes qui doivent être développés ni la manière de les implémenter dans un véhicule pour permettre le développement des services connectés souhaités tout en garantissant que ces services ne puissent affecter les prestations primaires du véhicule lors de son utilisation.

La plupart des constructeurs automobiles actuels disposent déjà de systèmes de connectivité intégrés à leurs véhicules car le développement de ce type de service (services connectés) est en plein essor.

La collecte de données est habituellement réalisée au moyen d’un boitier de connectivité. Le boitier de connectivité est aussi appelé TCU, Telematics control unit, pour unité de contrôle télématique en français.

Pour ce faire, le boitier de connectivité est connecté à un réseau de communication multiplexé pouvant être de différentes technologie (CAN, CAN FD, Flexray, Ethernet, …) et dispose d’une mémoire centrale lui permettant de stocker temporairement des données circulant son réseau puis de les transmettre par réseau sans fil (3G/4G, WIFI, …) à un serveur ou un outil connecté.

Lors de la conception d’un véhicule, le constructeur dimensionne son architecture (choix des technologies réseaux internes, ressources numériques des calculateurs) en tenant compte d’un équilibre prix / prestation. Ceci impose souvent un dimensionnement des ressources en fonction des prestations requises pour le fonctionnement du véhicule lors de son lancement, mais tient plus difficilement compte de besoins de connectivités pouvant apparaitre dans la vie série du véhicule dans laquelle de nouveaux acteurs non connus au moment de la conception initiale du véhicule peuvent proposer de nouveaux services au client et nécessiter de fait un accès à des données véhicule.

Une fonctionnalité particulièrement intéressante et demandée par de nombreux acteurs des services connectés est celle consistant à récupérer les défauts qui peuvent avoir été détectés et mémorisés dans les calculateurs d’un véhicule. Un calculateur est aussi appelé ECU, pour electronic control unit, unité de commande électronique en français.

Cette fonctionnalité présente un intérêt évident dans le cadre d’un service de maintenance / réparation, mais aussi pour un constructeur ou un fournisseur dans un but d’amélioration de la qualité d’un produit, ou encore d’un service spécifique proposé par les assureurs par exemple.

La récupération d’informations de défaut est une fonctionnalité déjà utilisée dans des garages de réparation. Pour obtenir ces informations défaut, un opérateur branche un outil de diagnostic sur la prise centralisée règlementaire (prise OBD conforme SAEJ1962) et au moyen d’une requête de diagnostic conforme à un protocole de communication tel l’UDS (Unified Diagnostic Services : ISO14229) par exemple transmet la commande adaptée à un calculateur du véhicule et obtient en réponse la liste des défauts mémorisés dans ce calculateur.

Toutefois, un tel procédé est contraignant en ce qu’il impose notamment un passage au garage.

D’autres procédés de transmission sans fil, over the air, ont pu être proposés pour récupérer les informations de défaut. De tels procédés doivent prendre en compte différentes contraintes et en particulier :

• les capacités (débit, ressources de calcul notamment) des réseaux internes du véhicule et des dispositifs présents sur ces réseaux ;
• les besoins de ces réseaux dans certaines situations, typiquement quand le véhicule fonctionne et de manière particulièrement prégnante quand la conduite du véhicule est automatisée.

Aussi, les concepteurs de ces procédés sont confrontés à un arbitrage entre les coûts des réseaux/dispositifs (des débits et ressources de calcul importants sont couteux) et le besoin de rendre disponible la transmission des défauts dans toutes les situations (conduite autonome par exemple).

Dans le cas d’une optimisation des coûts, les réseaux et dispositifs présents sur les réseaux sont dimensionnés au plus juste en débit et ressources de calcul. Dès lors, le constructeur doit restreindre la mise à disposition des informations de défaut à des situations particulières où le véhicule est disponible sans être trop sollicité (typiquement après l’extinction du moteur, batterie pleine, ou lorsque le véhicule, s’il est électrique, est en charge).

Ceci est particulièrement contraignant et tend à limiter l’ouverture des informations de défaut à des fournisseurs de services.

La présente invention vient améliorer la situation.

A cet effet, un premier aspect de l’invention concerne un procédé de formatage d’une information de défaut d’au moins un calculateur compris sur un véhicule terrestre à moteur, le véhicule comportant en outre un boitier de connectivité configuré pour l’émission et la réception de données respectivement vers et depuis au moins un réseau externe au véhicule et comportant un boitier de traitement distinct du calculateur et du boitier de connectivité, le procédé comportant, au niveau du boitier de traitement et lorsque le véhicule est en fonctionnement, les étapes de :

- réception depuis le calculateur d’au moins une trame comportant l’information de défaut ;

- génération d’au moins une trame modifiée comportant :

• un identifiant prédéterminé configuré pour indiquer au boitier de connectivité qu’il s’agit d’une trame comportant une information de défaut et pour indiquer au boitier de connectivité que le véhicule est en fonctionnement ; et
• l’information de défaut ;

- transmission vers le boitier de connectivité de la trame modifiée.

Ainsi, la sollicitation des réseaux interne sur lesquels transitent ces trames, trame reçue et trame modifiée, et les dispositifs présents sur ces réseaux, calculateurs, dispositif de traitement et boitier de connectivité, est réduite au minimum.

D’une part, les calculateurs ne gèrent que la remontée des informations de défaut dans des trames, les trames reçues, dans un format qui leur est adapté. Ils n’ont pas besoin de gérer des requêtes, potentiellement concomitantes, consommatrices de ressources numériques supplémentaires selon un protocole normé tel que l’UDS pour la transmission des informations de défaut. L’UDS est Unified Diagnostic Services : ISO14229, pour services diagnostics unifiés.

En outre, le boitier de traitement, distinct du boitier de connectivité, peut être situé à un endroit plus proche, en terme de réseaux, des calculateurs car il n’est pas soumis aux mêmes contraintes physiques (proximité de l’antenne, refroidissement, etc.) que le boitier de connectivité.

D’autre part, l’utilisation de l’identifiant prédéterminé évite la saturation des interfaces d’entrée du boitier connectivité. En effet, le boitier connectivité présente plusieurs interfaces d’entrées, aussi appelées mailbox pour boite courrier en français, très sollicitées et dont le nombre est limité, car directement lié à un nombre de composants physiques présents sur circuit imprimé.

On entend par « information de défaut d’au moins un calculateur » tout type de données caractérisant par exemple un état, une erreur matérielle, logicielle ou encore fonctionnelle ou encore un paramètre de fonctionnement d’un dispositif, typiquement un capteur et/ou un actionneur, du véhicule relié au calculateur. Le défaut peut ainsi concerner directement le calculateur et/ou tout capteur et/ou actionneur relié ou encore contrôlé par le calculateur.

Dans un mode de réalisation, l’identifiant prédéterminé fait 11 bits codés. Dans un mode de réalisation, l’identifiant prédéterminé est codé selon un protocole CAN non étendu.

On entend par « protocole CAN non étendu » le protocole CAN, pour Controller Area Network en anglais et réseau de zone de contrôle en français, dans lequel un identificateur de message est codé sur 11 bits.

Dans un mode de réalisation, l’identifiant prédéterminé est positionné sur au moins un bit de la trame modifiée ayant le plus grand poids.

Dans un mode de réalisation, la trame reçue comporte en outre une information d’état du véhicule au moment de la détection du défaut, et dans lequel la génération de la trame modifiée comporte en outre un filtrage de l’information d’état dans la trame reçue.

Un tel filtrage réduit avantageusement la taille de la trame et libère donc de la bande-passante sur le réseau en charge de la transmission de la trame modifiée vers le boitier de connectivité.

En outre, une telle suppression est particulièrement pertinente lorsqu’elle est combinée avec l’adjonction de l’identifiant prédéterminé, prévu dans le cas spécifique d’une remontée d’une information de défaut lorsque le véhicule est fonctionnement.

En plus de réduire la congestion du réseau interne situé entre le boitier de traitement et le boitier de connectivité, le filtrage réduit encore la congestion des interfaces d’entrée du boitier de connectivité. Ces interfaces comportent en effet des mémoires tampon, buffer en anglais, vite saturées si la taille des trames qui y sont reçues n’est pas contrôlée.

Dans un mode de réalisation, l’information d’état filtrée est codée sur trois octets.

Un deuxième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ces instructions sont exécutées par un processeur.

Un troisième aspect de l’invention concerne un boitier de traitement pour le formatage d’une information de défaut reçue depuis au moins un calculateur compris sur un véhicule terrestre à moteur, le boitier comportant au moins un processeur et au moins une mémoire agencés pour effectuer, lorsque que le véhicule est en fonctionnement, les opérations de :

• réception depuis le calculateur d’au moins une trame comportant l’information de défaut ;
• génération d’au moins une trame modifiée comportant :
  • un identifiant prédéterminé configuré pour indiquer à un boitier de connectivité configuré pour l’émission et la réception de données respectivement vers et depuis au moins un réseau externe au véhicule qu’il s’agit d’une trame comportant une information de défaut et pour indiquer au boitier de connectivité que le véhicule est en fonctionnement ; et
  • l’information de défaut ;
• transmission vers le boitier de connectivité de la trame modifiée.

Un quatrième aspect de l’invention concerne véhicule configuré pour comprendre le boitier de traitement selon le troisième aspect de l’invention.

D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels :

est un schéma illustrant le contexte de l’invention selon un mode de réalisation de l’invention ;

est un diagramme illustrant les étapes d’un procédé selon un mode de réalisation de l’invention ;

est un schéma illustrant des trames selon un mode de réalisation de l’invention ;

illustre la structure d’un dispositif selon un mode de réalisation de l’invention.

L’invention est décrite ci-après dans son application, non limitative, au cas d’un véhicule automobile comprenant un calculateur, un boitier de traitement et un boitier de connectivité. Une telle application est purement illustrative et réduite à quelques composants pour la clarté du propos mais, en pratique, l’invention est utilisée par plusieurs dizaines ou centaines de composants, calculateurs en particulier.

La illustre un contexte d’application de l’invention, selon un mode de réalisation.

Un véhicule automobile VEH comprend un calculateur CLCTR, un boitier de traitement BT et boitier de connectivité BC. Dans la terminologie utilisée par le déposant, le boitier de connectivité BC est aussi appelé BSRF, pour boitier de servitudes radio fréquence, et le boitier de traitement BT est aussi appelé BSI, pour boitier de servitude intelligent.

BC, BT et CLCTR sont reliés par au moins un réseau interne au véhicule. Un tel réseau est typiquement un réseau CAN, pour Controller Area Network, et/ou Ethernet. Plusieurs réseaux peuvent être présents, par exemple reliés entre eux par BT ou BC.

BC est utilisé pour faire le lien avec des réseaux externes accessibles par des liaisons radiofréquence. De tels réseaux sont par exemple un réseau wifi, 3G, 4G, 5G, sidelink PC5, bluetooth, etc.

De tels réseaux externes font le lien entre le véhicule VEH et un serveur SRVR. Un tel SRVR fait lui-même l’interface entre les véhicules, par exemple d’un même constructeur, et des fournisseurs de service tels qu’un service de maintenance, une assurance ou encore un service de cartographie.

La illustre un procédé, selon un mode de réalisation de l’invention.

Le procédé est mis en œuvre quand le véhicule est en fonctionnement. Dans un mode de réalisation, le véhicule est en fonctionnement quand au moins un moteur du véhicule est allumé (moteur thermique tournant et/ou moteur électrique en fonctionnement par exemple). Dans un autre mode de réalisation, le véhicule est en fonctionnement quand le véhicule est roulant.

A une étape 10, le contrôleur CLCTR détecte un défaut et génère une information de défaut DTC. Par exemple, un contrôleur d’une caméra de recul détecte qu’un obstacle est détecté en permanence, ce qui est par exemple dû à la présence d’une saleté (boue typiquement) sur le capteur.

A une étape 12, une trame FR(DTC) est transmise par CLCTR au boitier de traitement BT. Le format de la trame FR(DTC) est détaillé ci-après en référence à la . La trame FR(DTC) comporte l’information de défaut DTC.

Sur réception de F_R(DTC), un message d’acquittement Ack est transmis à CLCTR à une étape 14.

A une étape 16, FR(DTC) est traité et une trame modifiée FM(DTC) est générée. Le détail du traitement et du format de FM(DTC) est détaillé ci-après en référence à la .

A une étape 18, F_M(DTC) est transmis au boitier de connectivité BC et un acquittement est envoyé à BT par BC sur réception de F_M(DTC) à une étape 20.

F_R(DTC) peut être stocké temporairement par BT en attente de l’acquittement de BC pendant que BT traite une autre trame F_R(DTC), si les capacités de stockage temporaire de BT sont suffisantes (plus d’un buffer mémoire). Si BT ne possède pas de capacités de stockage temporaire suffisantes, BT peut décider de ne pas recevoir et traiter d’autres F_R(DTC) et donc de ne plus transmettre d’acquittements à CLTCR.

A une étape 22, F_M(DTC) est reçue par BC.

Dans un mode de réalisation, BC récupère alors l’information de défaut DTC de F_M(DTC). BC transmet ensuite par radio fréquence, over the air, DTC, au serveur SRVR. DTC est alors stocké par SRVR et transmis à un fournisseur de service, enregistré auprès du serveur, SRVR sur requête dudit fournisseur de service. Dans un mode de réalisation, DTC est automatiquement transmis par SRVR lorsque que SRVR reçoit DTC de BC.

Dans un mode de réalisation, BC stocke DTC et attend de recevoir une requête de SRVR et/ou d’un fournisseur de service pour transmettre DTC.

D’autres informations, telles qu’un identifiant du véhicule, tel que le VIN pour Vehicle Identification Number ou nombre d’identification véhicule en français, peuvent être ajoutées à DTC lors de l’envoi à SRVR ou au fournisseur de service.

Le détail du traitement de FR(DTC) en FM(DTC) par BC est illustré à la , selon un mode de réalisation.

Le traitement ici décrit en référence à la par BT s’intègre avantageusement dans la fonctionnalité DEH, pour Default Event History, ou JDD Journal Des Défauts, qui consiste à stocker en supplément des informations de défaut une heure d’apparition ou de disparition de ces défaillances ainsi que le kilométrage du véhicule au moment où ces défaillances sont apparues. Cette fonctionnalité est intéressante car elle permet de garder une trace entre deux révisions du véhicule d’un défaut ayant pu être détecté par le véhicule dans une condition particulière, avec parfois un ressenti client sans que cette trace n’ait pu être conservée dans la mémoire du calculateur ayant réalisé cette détection. Les calculateurs d’un véhicule ne conservent pas en mémoire les défauts lorsque ces derniers ne sont plus réapparus depuis quarante redémarrage (libération de la mémoire dédiée).

F_R(DTC) comprend en détail au moins deux sous-trames F_R1 et F_R2 codées selon le protocole CAN. Dans un mode de réalisation, une troisième sous-trame est comprise par F_R(DTC).

Dans la , plusieurs informations sont disponibles, celles de la partie gauche correspondent aux trames reçues par BT et celles de droite aux trames transmises vers BC.

Dans la partie de gauche dans la première trame, nous trouvons :

L’information ID qui correspond à un numéro sur 11bits d’identifiant de la trame CAN permettant de connaitre l’identité du calculateur émetteur de DTC. Cet ID porte donc la même valeur dans les trames 1 et 2.

Le paramètre Hder qui représente le numéro de la trame afin que le récepteur de l’information puisse savoir s’il s’agit de la première trame F_R1 ou la seconde FR2 d’un même DTC.

Le paramètre Dfault_cde qui représente le code de l’anomalie, il adopte le format de codage proposé par l’UDS sur trois octets.

Le paramètre Date, qui correspond à la valeur d’un compteur représentant la datation à laquelle s’est produite la détection.

Dans la seconde trame qui porte le même ID que la première trame émise par ce même calculateur, nous trouvons aussi les paramètres :

Hder avec une valeur différente de celle fournie dans la première trame de l’évènement pour ce même paramètre,

Mleage correspondant au kilométrage du véhicule mémorisé lors de la détection de l’anomalie.

Lfe_sition correspondant à l’état du véhicule au moment de la détection de DTC. Lfe_sition est codée sur trois octets dans F_R2.

La transformation réalisée par BT est représentée sur la partie droite de la :

Pour transmettre DTC à BC reçu de la part de CLCTR, BT ajoute un identifiant prédéterminé spécifique représenté par l’élément : « Identif ». Il s’agit d’une valeur sur 11 bits (protocole CAN non étendu) qui va justement permettre à BC de déterminer parmi toutes les trames qu’il reçoit celles qui sont relatives à des évènements défauts. Ainsi, l’identifiant prédéterminé est configuré pour indiquer au boitier de connectivité qu’il s’agit d’une trame comportant une information de défaut et pour indiquer au boitier de connectivité que le véhicule est en fonctionnement.

Pour que BT puisse connaitre le calculateur à l’initiative de la transmission de DTC, BT doit collecter l’ID reçu et le placer dans la trame qu’il va transmettre à BC.

Il est également possible que le boitier de traitement BT présente lui-même un défaut. Dans ce cas, le calculateur est identique à BT ou il s’agit d’un sous-composant de BT, et un ID spécifique est choisi par BT.

Les informations Hder, Dfault_cde, Mleage et Date seront aussi transmises sur des emplacements de trame différents (octets bx).

Par contre, l’information d’état Lfe_sition est filtrée par BT à l’étape 16. L’information d’état Lfe_sition n’est donc pas présente dans la trame F_M(DTC) et ses sous-trames F_M1 et F_M2. Il n’est pas utile de transmettre Lfe_sition notamment car l’identifiant Identif rend possible l’identification par BC, SRVR et/ou le fournisseur de service de la situation du véhicule, Identif étant uniquement ajouté dans le cas spécifique où le véhicule est en fonctionnement.

A noter que l’information Date transmise sur 4 octets dans F_R1 devra être scindée en deux et transmise vers BC dans deux trames distinctes (F_M1 et F_M2).

La représente un exemple de dispositif D compris dans le véhicule VEH ou encore dans le serveur SRVR. Ce dispositif D peut être utilisé en tant que dispositif centralisé en charge d’au moins certaines étapes du procédé décrit ci-avant en référence à la . Dans un mode de réalisation, il correspond par exemple à CLCTR, BT et/ou BC.

Ce dispositif D peut prendre la forme d’un boitier comprenant des circuits imprimés, de tout type d’ordinateur ou encore d’un smartphone.

Le dispositif D comprend une mémoire vive 1 pour stocker des instructions pour la mise en œuvre par un processeur 2 d’au moins une étape des procédés tels que décrits ci-avant. Le dispositif comporte aussi une mémoire de masse 3 pour le stockage de données destinées à être conservées après la mise en œuvre du procédé.

Le dispositif D peut en outre comporter un processeur de signal numérique (DSP) 4. Ce DSP 4 reçoit des données pour mettre en forme, démoduler et amplifier, de façon connue en soi ces données.

Le dispositif comporte également une interface d’entrée 5 pour la réception des données mises en œuvre par des procédés selon l’invention et une interface de sortie 6 pour la transmission des données mises en œuvre par le procédé.

La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes.

Ainsi, il a été décrit un mode de réalisation correspondant à une architecture électronique exemplatif (un calculateur CLTR, un boitier de traitement BT, un boitier de connectivité BC, etc.) pour un véhicule automobile. La présente invention est également applicable à d’autres architectures électroniques (nombre différent de calculateurs, etc.).

Claims (9)

1. Procédé de formatage d’une information de défaut (DTC) d’au moins un calculateur (CLCTR ; BT) compris sur un véhicule terrestre à moteur, le véhicule comportant en outre un boitier de connectivité (BC) configuré pour l’émission et la réception de données respectivement vers et depuis au moins un réseau externe au véhicule et comportant un boitier de traitement (BT) distinct du calculateur et du boitier de connectivité, le procédé comportant, au niveau du boitier de traitement et lorsque que le véhicule est en fonctionnement, les étapes de :

   • réception depuis le calculateur (CLCTR ; BT) d’au moins une trame comportant l’information de défaut ;
   • génération(16) d’au moins une trame modifiée comportant :
     • un identifiant prédéterminé configuré pour indiquer au boitier de connectivité qu’il s’agit d’une trame comportant une information de défaut et pour indiquer au boitier de connectivité que le véhicule est en fonctionnement ; et
     • l’information de défaut ;
   • transmission vers le boitier de connectivité de la trame modifiée.
2. Procédé selon la revendication 1, dans lequel l’identifiant prédéterminé fait 11 bits.
3. Procédé selon la revendication 2, dans lequel l’identifiant est codé selon un protocole CAN non étendu.
4. Procédé selon l’une des revendications précédentes, dans lequel l’identifiant prédéterminé est positionné sur au moins un bit de la trame modifiée ayant le plus grand poids.
5. Procédé selon l’une des revendications précédentes, dans lequel la trame reçue comporte en outre une information d’état du véhicule au moment de la détection du défaut, et dans lequel la génération de la trame modifiée comporte en outre un filtrage de l’information d’état dans la trame reçue.
6. Procédé selon la revendication 5, dans lequel l’information d’état filtrée est codée sur trois octets.
7. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (2).
8. Boitier de traitement (D ; BT) pour le formatage d’une information de défaut reçue depuis au moins un calculateur compris sur un véhicule terrestre à moteur, le boitier comportant au moins un processeur et au moins une mémoire agencées pour effectuer, lorsque que le véhicule est en fonctionnement, les opérations de :

   • réception depuis le calculateur d’au moins une trame comportant l’information de défaut ;
   • génération d’au moins une trame modifiée comportant :
     • un identifiant prédéterminé configuré pour indiquer à un boitier de connectivité configuré pour l’émission et la réception de données respectivement vers et depuis au moins un réseau externe au véhicule qu’il s’agit d’une trame comportant une information de défaut et pour indiquer au boitier de connectivité que le véhicule est en fonctionnement ; et
     • l’information de défaut ;
   • transmission vers le boitier de connectivité de la trame modifiée.
9. Véhicule terrestre à moteur comportant le boitier de traitement selon la revendication 8.