FR3113150A1 - Formatage d’informations de défaut par filtrage - Google Patents
Formatage d’informations de défaut par filtrage Download PDFInfo
- Publication number
- FR3113150A1 FR3113150A1 FR2008065A FR2008065A FR3113150A1 FR 3113150 A1 FR3113150 A1 FR 3113150A1 FR 2008065 A FR2008065 A FR 2008065A FR 2008065 A FR2008065 A FR 2008065A FR 3113150 A1 FR3113150 A1 FR 3113150A1
- Authority
- FR
- France
- Prior art keywords
- vehicle
- frame
- box
- information
- fault information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000001914 filtration Methods 0.000 title claims description 7
- 238000000034 method Methods 0.000 claims abstract description 26
- 238000012545 processing Methods 0.000 claims description 20
- 230000005540 biological transmission Effects 0.000 claims description 11
- 230000015654 memory Effects 0.000 claims description 9
- 238000001514 detection method Methods 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 2
- 238000012423 maintenance Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 230000008439 repair process Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000002485 combustion reaction Methods 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- SDJLVPMBBFRBLL-UHFFFAOYSA-N dsp-4 Chemical class ClCCN(CC)CC1=CC=CC=C1Br SDJLVPMBBFRBLL-UHFFFAOYSA-N 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Small-Scale Networks (AREA)
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. FIG. 1
Description
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 et d’une information d’état du véhicule au moment de la détection du défaut ;
- génération d’au moins une trame modifiée par filtrage de l’information d’état dans la trame reçue, la trame modifiée comportant l’information de défaut ;
- transmission vers le boitier de connectivité de la trame modifiée.
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 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çu n’est pas contrôlée.
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’information d’état filtrée est codée sur trois octets.
Dans un mode de réalisation, la trame modifiée comporte en outre 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.
La suppression de l’information d’état 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.
De plus, la sollicitation des réseaux internes 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é.
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.
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 et d’une information d’état du véhicule au moment de la détection du défaut ;
- génération d’au moins une trame modifiée par filtrage de l’information d’état dans la trame reçue, la trame modifiée comportant l’information de défaut ;
- transmission vers le boitier de connectivité de la trame modifiée.
Un quatrième aspect de l’invention concerne un véhicule comportant 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 :
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 FR(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, FM(DTC) est transmis au boitier de connectivité BC et un acquittement est envoyé à BT par BC sur réception de FM(DTC) à une étape 20.
FR(DTC) peut être stocké temporairement par BT en attente de l’acquittement de BC pendant que BT traite une autre trame FR(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 FR(DTC) et donc de ne plus transmettre d’acquittements à CLTCR.
A une étape 22, FM(DTC) est reçue par BC.
Dans un mode de réalisation, BC récupère alors l’information de défaut DTC de FM(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).
FR(DTC) comprend en détail au moins deux sous-trames FR1 et FR2 codées selon le protocole CAN. Dans un mode de réalisation, une troisième sous-trame est comprise par FR(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 FR1 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 FR2.
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 FM(DTC) et ses sous-trames FM1 et FM2. 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 FR1 devra être scindée en deux et transmise vers BC dans deux trames distinctes (FM1 et FM2).
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)
- Procédé de formatage d’une information de défaut d’au moins un calculateur (CLCTR ; BT) compris sur un véhicule terrestre à moteur (VEH), 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 d’au moins une trame comportant l’information de défaut et d’une information d’état du véhicule au moment de la détection du défaut ;
- génération (16) d’au moins une trame modifiée par filtrage de l’information d’état dans la trame reçue, la trame modifiée comportant l’information de défaut ;
- transmission vers le boitier de connectivité de la trame modifiée.
- Procédé selon la revendication 1, dans lequel l’information d’état filtrée est codée sur trois octets.
- Procédé selon l’une des revendications précédentes, dans lequel la trame modifiée comporte en outre 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.
- Procédé selon la revendication 3, dans lequel l’identifiant prédéterminé fait 11 bits.
- Procédé selon la revendication 4, dans lequel l’identifiant est codé selon un protocole CAN non étendu.
- Procédé selon l’une des revendications 3 à 5, dans lequel l’identifiant prédéterminé est positionné sur au moins un bit de la trame modifiée ayant le plus grand poids.
- 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).
- 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 et d’une information d’état du véhicule au moment de la détection du défaut ;
- génération d’au moins une trame modifiée par filtrage de l’information d’état dans la trame reçue, la trame modifiée comportant l’information de défaut ;
- transmission vers le boitier de connectivité de la trame modifiée.
- Véhicule terrestre à moteur comportant le boitier de traitement selon la revendication 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2008065A FR3113150A1 (fr) | 2020-07-30 | 2020-07-30 | Formatage d’informations de défaut par filtrage |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2008065 | 2020-07-30 | ||
| FR2008065A FR3113150A1 (fr) | 2020-07-30 | 2020-07-30 | Formatage d’informations de défaut par filtrage |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3113150A1 true FR3113150A1 (fr) | 2022-02-04 |
Family
ID=74183206
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2008065A Pending FR3113150A1 (fr) | 2020-07-30 | 2020-07-30 | Formatage d’informations de défaut par filtrage |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3113150A1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2578070A1 (fr) * | 1985-02-22 | 1986-08-29 | Bosch Gmbh Robert | Procede pour faire fonctionner une installation de traitement de donnees pour des vehicules a moteur |
| DE102007029116A1 (de) * | 2007-06-25 | 2009-01-02 | Continental Automotive Gmbh | Verfahren zum Betreiben eines Mikrocontrollers und einer Ausführungseinheit sowie ein Mikrocontroller und eine Ausführungseinheit |
| WO2013186504A1 (fr) * | 2012-06-15 | 2013-12-19 | Orange | Dispositif et procede d'extraction de donnees sur un bus de communication d'un vehicule automobile |
| FR3012243A1 (fr) * | 2013-10-17 | 2015-04-24 | Peugeot Citroen Automobiles Sa | Systeme de realisation de telediagnostics de vehicules requis par des equipements de communication non filaire |
-
2020
- 2020-07-30 FR FR2008065A patent/FR3113150A1/fr active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2578070A1 (fr) * | 1985-02-22 | 1986-08-29 | Bosch Gmbh Robert | Procede pour faire fonctionner une installation de traitement de donnees pour des vehicules a moteur |
| DE102007029116A1 (de) * | 2007-06-25 | 2009-01-02 | Continental Automotive Gmbh | Verfahren zum Betreiben eines Mikrocontrollers und einer Ausführungseinheit sowie ein Mikrocontroller und eine Ausführungseinheit |
| WO2013186504A1 (fr) * | 2012-06-15 | 2013-12-19 | Orange | Dispositif et procede d'extraction de donnees sur un bus de communication d'un vehicule automobile |
| FR3012243A1 (fr) * | 2013-10-17 | 2015-04-24 | Peugeot Citroen Automobiles Sa | Systeme de realisation de telediagnostics de vehicules requis par des equipements de communication non filaire |
Non-Patent Citations (1)
| Title |
|---|
| JDD JOURNAL DES DÉFAUTS |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105791386B (zh) | 高效的远程信息处理数据上传 | |
| CN106878371B (zh) | 远程信息处理数据的有效上传 | |
| EP2862091B1 (fr) | Dispositif et procede d'extraction de donnees sur un bus de communication d'un vehicule automobile | |
| US20240185648A1 (en) | Vehicle data extraction service | |
| WO2021197864A1 (fr) | Dispositifs et procédé de contrôle d'unités de commande électroniques d'un véhicule automobile | |
| FR3028068A1 (fr) | Procede, equipement et systeme d’aide au diagnostic | |
| EP3203445B1 (fr) | Systeme et procede d'identification automatique d'un modele de vehicule | |
| CN115733847A (zh) | 智能远程信息处理数据同步 | |
| FR3032546A1 (fr) | Procede et systeme de realisation de telediagnostics securises d’equipements electroniques communicants de vehicules | |
| FR3113150A1 (fr) | Formatage d’informations de défaut par filtrage | |
| FR3113149A1 (fr) | Formatage d’informations de défaut par ajout d’identifiant | |
| CN114419875A (zh) | 车辆行程切分方法、装置及存储介质 | |
| CN115223273A (zh) | Tcu数据监控方法、装置、终端设备及存储介质 | |
| FR3122059A1 (fr) | Procédé, dispositif et système de communication de données d’évènement pour véhicule | |
| CN115273271B (zh) | 一种基于车辆娱乐主机采集车辆数据的系统及方法 | |
| EP4182907B1 (fr) | Aspects temporels d'une gestion centralisée de l'exécution de services connectés d'un véhicule | |
| FR3096017A1 (fr) | Procédé et système de détermination d’un état de fonctionnement d’un capteur | |
| FR3094105A1 (fr) | Procédé et dispositif de dimensionnement d’une mémoire d’un calculateur | |
| FR3124004A1 (fr) | Gestion distante de l’exécution d’un service sur un véhicule fondée sur un échange de données | |
| FR3124005A1 (fr) | Gestion distante de l’exécution d’un service sur un véhicule fondée sur une extraction de données | |
| FR3073071A1 (fr) | Dispositif de communication pour vehicule comportant une pluralite de moyens de communication | |
| FR3145661A1 (fr) | Procédé et dispositif de détermination d’un type de bus de données utilisé pour la transmission de signaux entre périphériques dans un véhicule | |
| FR3044144B1 (fr) | Procede de tenue d’une base de donnees de defauts d’un vehicule automobile | |
| EP4335079A1 (fr) | Procédé et dispositif de protection contre une intrusion sur un bus de données d'un véhicule | |
| FR3065853B1 (fr) | Procede et dispositif de controle de la transmission de donnees d’un vehicule a un equipement de communication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20220204 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| CD | Change of name or company name |
Owner name: STELLANTIS AUTO SAS, FR Effective date: 20240423 |