FR3045822A1

FR3045822A1 - Procede permettant d alimenter les donnees de diagnostiques pour generer les tests de controle dans un processus de controle technique

Info

Publication number: FR3045822A1
Application number: FR1562917A
Authority: FR
Inventors: Pacome Mayouma
Original assignee: Peugeot Citroen Automobiles SA
Current assignee: PSA Automobiles SA
Priority date: 2015-12-21
Filing date: 2015-12-21
Publication date: 2017-06-23
Anticipated expiration: 2035-12-21
Also published as: FR3045822B1

Abstract

Une méthode de contrôle technique de véhicule comprend une étape d'alimentation (S2) d'un serveur distant, une étape de liaison, une étape de requête, et une étape de réponse.

Description

METHODE DE CONTROLE TECHNIQUE DE VEHICULE

La présente invention concerne de manière générale une méthode de constitution de base de données pour contrôle technique de véhicule.

Il est connu dans l’art antérieur des méthodes de constitution de base de données pour contrôle technique de véhicule. Ainsi, le document EP2755010 décrit un dispositif et procédé de tests réalisés pour le contrôle technique utilisant le standard «Open Diagnostic Data Exchange» (abrévié ODX, ceci est une norme de description formelle des informations de diagnostic des calculateurs véhicule) pour alimenter la base de données destinée au contrôle technique. Un tel contrôle technique peut être une obligation légale dans certains pays, ou un simple contrôle dans un garage par exemple. L’élargissement au contrôle des systèmes de sécurité issu de la nouvelle directive européenne oblige notamment : - A disposer de la liste des équipements sécuritaires qui ont été montés lors de la fabrication pour chaque véhicule (qui est caractérisé par un numéro de série unique que l’on appelle aussi « Vehicle Identification Number » ou « VIN »)) vendu et de vérifier qu’ils sont bien présents lors du contrôle technique. - A contrôler que les calculateurs sécuritaires équipant un véhicule au sens VIN sont bien opérationnels.

Ainsi, dans ces méthodes connues et pour répondre à ces besoins, les constructeurs répondent en fournissant la composition réelle des véhicules, leur traçabilité et les références composant des calculateurs du véhicule concerné aux organismes qui gèrent les bases de données pour le contrôle technique.

En sus, pour les besoins de contrôle ou test, les constructeurs fournissent typiquement également un dossier, pour chaque type de véhicule et/ou véhicule particulier, conçu de façon manuelle et contenant les infos ci-dessous : - La composition véhicule (présence des calculateurs que l’on appelle aussi ECU), - L’allocation du media de communication (par exemple communication par fil et/ou par bluetooth) de chaque ECU aux broches du connecteur, - Les requêtes utilisées par ECU pour l’accès et la récupération des informations (code défauts, ....) - Les synchronisations ou timings associés, les identifiants des ECU, - Les conditions de rejets lors du contrôle à définir par le constructeur.

En contrepartie, avec les éléments communiqués ci- dessus, c’est-à-dire vérifier la présence des équipements sécuritaires d’un véhicule particulier en ayant son VIN, le contrôle ne peut être raisonnablement réalisé qu’en vérifiant visuellement la présence des éléments sur chaque véhicule. Cette méthode pratiquée aujourd’hui est une solution de repli prévue mais qui n’est pas optimum. D’autre part, compte tenu de la diversité des éléments listés ci-dessus (composition véhicule, allocation du média de communication, requêtes utilisées par ECU pour l’accès et la récupération des informations, synchronisations associées, les identifiants des ECU....), il est très fastidieux, de créer manuellement un dossier constitué de ces éléments pour chaque VIN particulier. On ne peut écarter notamment le risque élevé de ressaisie et donc d’erreurs pour une alimentation manuelle de données et donc difficilement interprétables. En plus, pour extraire les infos utiles, les constructeurs font un tri manuellement en partant de référentiels techniques pour constituer un dossier contenant les infos spécifiques contrôle technique. En effet, les documents études regroupent les informations liées au diagnostic véhicule mais pas nécessaires au contrôle technique uniquement. Il est donc indispensable de limiter les informations transmises pour le contrôle technique au strict minimum.

Un but de la présente invention est de répondre aux inconvénients des documents de l’art antérieur mentionnés ci-dessus et en particulier, tout d'abord, de proposer une méthode de constitution de base de données pour contrôle technique de véhicule qui est rapide et fiable et qui permet en plus un contrôle technique rapide et fiable.

Pour cela un premier aspect de l'invention concerne une méthode de contrôle technique de véhicule, la méthode comprenant une étape d’alimentation d’un serveur distant pendant laquelle une pluralité d’informations techniques est enregistrée dans une base de données sur le serveur distant, les informations techniques étant chacune liées à au moins un calculateur de véhicule et définissant au moins un point et/ou une méthode de diagnostic dudit au moins un calculateur, l'étape d'alimentation étant effectuée pendant une phase de conception dudit au moins un point et/ou une méthode de diagnostic pour ledit au moins un calculateur, une étape de liaison pendant laquelle au moins un numéro de série d’un véhicule est associé audit au moins un calculateur de véhicule dans la base de données, une étape de requête pendant laquelle est envoyé depuis un centre de contrôle technique à la base de données le numéro de série dudit véhicule qui doit effectuer un contrôle technique, et une étape de réponse pendant laquelle au moins une des informations techniques liées à l’au moins un calculateur de véhicule associé audit numéro de série du véhicule est transmise de la base de données à un outil utilisé lors du contrôle technique.

Le fait d’ainsi mettre en place pour le contrôle technique, une filière numérique standardisée, essentiellement pendant la conception de moyens de diagnostic pour les calculateurs, permet d’alimenter les données de diagnostic utilisées pour générer les tests de diagnostic dans un processus de contrôle technique tout en supprimant les problèmes associés mentionnés ci-dessus. De plus, la base de données est alimentée dès la conception des méthodes de diagnostic avec les informations techniques relatives à chaque calculateur, elle reçoit ensuite, lors de la fabrication du véhicule la liste des calculateurs montés sur chaque véhicule (identifié par son numéro de saisie) : les données sont donc immédiatement disponibles en sortie de chaîne de fabrication et reflètent la structure réelle du véhicule.

De manière avantageuse, les informations techniques comprennent, pour chacun des calculateurs, au moins une requête de diagnostic et/ou au moins un identifiant du calculateur et/ou au moins une synchronisation associée. Cela a pour avantage que ces informations sont présentes dans la base de données pour contrôle technique de véhicule d’une façon standardisée et permettent de facilement déterminer les calculateurs présents pour un certain numéro de série ainsi que leur fonctionnement.

De manière avantageuse, les informations techniques comprennent, pour chacun des calculateurs, au moins une matrice de défauts et/ou au moins une stratégie de défauts. Une matrice de défauts est une structure de données dans laquelle différents type de défauts sont enregistrés, typiquement avec des solutions possibles. Une stratégie de défauts est une stratégie de réaction à un ou plusieurs défauts. Cela a pour avantage de faciliter une création automatique et standardisée des protocoles de contrôle technique, par exemple par rapport à des tests spécifiques utilisés pendant un contrôle technique et la façon de réagir à des problèmes rencontrés pendant ces tests.

De manière avantageuse, pendant l’étape de liaison, des informations de véhicule sont enregistrées dans la base de données, les informations de véhicule comprenant au moins des données techniques relatives au véhicule, telles qu’une nomenclature et/ou une liste d’options, et/ou au moins une référence composant et/ou au moins une autre information, telle qu’une condition de rejet lors du contrôle technique définie par un constructeur de véhicule. Cela a pour avantage qu’une représentation la plus complète possible de différents types de véhicule est présente dans la base de données.

De manière avantageuse, les informations techniques sont modélisées dans la base de données pour contrôle technique de véhicule selon le standard Open Diagnostic Data Exchange. Cela a pour avantage d’obtenir une structure de base de données le plus standardisée possible.

De manière avantageuse, au moins une des informations de véhicule n’est pas modélisé selon le standard Open Diagnostic Data Exchange. Cela a pour avantage de permettre également la présence de contenu qui n’est pas modélisable selon le standard ODX.

De manière avantageuse, la méthode comprend une étape de création de paquets d’informations modélisées selon le standard Open Diagnostic Data Exchange, où un paquet d’informations modélisées selon le standard Open Diagnostic Data Exchange est nommé PDX, pendant laquelle un PDX par calculateur est créé. Cela a pour avantage une modularité très fine de la base de données.

Dans une mise en oeuvre de l'invention, la méthode comprend une étape de création de paquets d’informations modélisées selon le standard Open Diagnostic Data Exchange, où un paquet d’informations modélisées selon le standard Open Diagnostic Data Exchange est nommé PDX, pendant laquelle un PDX par numéro de série est créé. Cela a pour avantage de faciliter la distribution des PDX à des organismes de contrôle technique par exemple, parce que le nombre de PDX à distribuer est minimisé.

De manière avantageuse, la méthode comprend une étape de mise à jour de données, où l’étape de mise à jour de données se déroule après la conception de moyens de diagnostic pour le calculateur particulier. Cela a pour avantage de permettre une mise à jour standardisée, rapide et fiable de la base de données.

De manière avantageuse, la méthode comprend une étape de création de PDX spécialisé pour contrôle technique. Cela a pour avantage que le transfert de données entre l’organisme responsable du contrôle technique et la base de données est minimisé parce que le transfert de données qui ne sont pas absolument nécessaire lors du contrôle technique peut être minimisé.

De manière générale, la méthode permet de générer des tests appropriés lors du contrôle technique en se basant sur le standard ODX. Il est aussi possible de retrouver le bon fichier pendant toute la vie du véhicule à travers le numéro de série du véhicule, et de tagger et d’extraire facilement et de façon automatique les informations contenues dans l’ODX qui sont donc spécifiques pour le contrôle technique automobile (c.a.d générer un ODX restreint au strict besoin du contrôle technique). D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description détaillée qui suit d'un mode de réalisation de l'invention donné à titre d'exemple nullement limitatif et illustré par les dessins annexés, dans lesquels : - la figure 1 représente une architecture fonctionnelle d’exploitation des données et génération des tests pour une base de données de contrôle technique pour les calculateurs sécuritaires équipant un véhicule; - la figure 2 représente une première étape d’une méthode de contrôle technique de véhicule selon l’invention; - la figure 3 représente la modélisation d’un PDX pour un calculateur particulier; - la figure 4 représente une deuxième étape d’une méthode de contrôle technique de véhicule selon l’invention; - la figure 5 représente une étape supplémentaire d’une méthode de contrôle technique de véhicule selon l’invention; - la figure 6 représente une variante de l’invention dans laquelle un PDX est constitué pour un ensemble de calculateurs constituants un véhicule avec un numéro de série donné.

La figure 1 représente une architecture fonctionnelle d’exploitation des données et génération des tests pour une base de données de contrôle technique pour les calculateurs sécuritaires équipant un véhicule. Dans le suivant, nous appelons PDX, un package des ODX c’est à dire un ensemble composé de plusieurs ODX. Un ODX est une structure de données selon le standard Open Diagnostic Data Exchange (ODX).

La figure 1 décrit plusieurs blocs qui fournissent des informations utiles pour alimenter une base de données de contrôle technique BD: • Les données techniques relatives au véhicule 6 et les références composant 7 permettent notamment de transmettre la composition réelle d’un véhicule et de suivre aussi sa traçabilité dans le temps. • La matrice 4 et stratégie de défaut 5 fournissent les éléments permettant de contrôler le statut des équipements et à interpréter les codes défauts (DTC). • Les requêtes de diagnostic 10 seront utilisées pour lire des données statiques ou dynamiques du véhicule 9 (lecture de paramètres) et dans certains cas modifier une donnée ou activer une fonctionnalité en accord avec la méthode de test définie par le constructeur. • Modélisation PDX/ODX S1, cette phase passe par l’agencement dans une même structure, des modules disponibles dans l’ODX qui permettront de porter au maximum les informations sur composition véhicule, allocation du média de communication, requêtes utilisées par ECU pour l’accès et la récupération des informations 1, synchronisations associées 3, les identifiants des ECU 2 etc. • Les autres informations 8, non modélisables (exemple : conditions de rejets lors du contrôle définies par le constructeur) sont tout de même générées sous un format informatique (exemple : PDF) et rattaché avec l’ensemble des éléments modélisables en ODX par VIN véhicule. • Le système de suivi des évolutions 11 du PDX trace toutes les mises à jour du fichier en assurant le bon lien avec les autres informations 8 non modélisables en ODX.

La figure 2 représente une première étape d’une méthode de contrôle technique de véhicule selon l’invention. Cette étape, qui constitue une étape d’alimentation, intervient pendant la conception d’une messagerie de diagnostic pour un calculateur donné. Une messagerie diagnostic contient un ensemble des messages que peuvent échanger un outil de diagnostic et un calculateur du véhicule. Une telle messagerie permet d’encoder et de décoder les informations transmises sur les trames diagnostic des réseaux multiplexés. En particulier, la figure 2 visualise l’alimentation de la base de données BD pour contrôle technique de véhicule avec les requêtes utilisées par ECU pour l’accès et la récupération des informations 1, les identifiants des ECU 2 et les synchronisations associées 3 ainsi que la matrice de défauts 4 et la stratégie de défauts 5. Il est possible d’alimenter la base de données BD avec d’autres informations en même temps, comme des informations concernant l’allocation du média de communication. Ces informations techniques sont modélisées dans la base de données de diagnostic BD suivant le modèle visualisé dans la figure 3. Bien évidemment, les liens et le contenu de cette structure PDX peuvent être utilisées ou référencées différemment et constitueraient alors une autre variante de solution.

La figure 3 représente la modélisation d’un PDX pour un calculateur particulier. Dans cette modélisation, le fichier ODX CPS, appelé COMPARAM-SPEC, est un bout d’ODX qui permet de stocker l’ensemble des paramètres de communication (synchronisations, identifiants) utilisés dans le cadre d’une communication diagnostic entre un outil et un calculateur.

Le Protocol, dans cette modélisation, contient uniquement la référence du fichier CPS et est associé au fichier ODX BV, appelé Base Variant, qui contient les requêtes utilisées par le calculateur pour l’accès et la récupération des informations (Exemple : Code défauts, seuils, ....)

Le fichier ODX EV, appelé ECU Variant, contient également les requêtes utilisées par le calculateur pour l’accès et la récupération des informations. Cette couche est mise à disposition pour permettre la mise à jour des informations en cas de correction d’une messagerie d’un calculateur déjà commercialisée.

Le fichier ODX ESD, appelé ECU-SHARED-DATA, sert d’interface et contient les codes défauts calculateur et d’autres informations nécessaires pour discriminer le contenu de la structure PDX suivant le client destiné. Par exemple, c’est dans cette couche qu’on va dire si une information saisie est à destination du contrôle technique ou du réseau après-vente.

Le fichier ODX VIS, appelé VEHICLE-INFO-SPEC, sert d’interface et sera utilisé dans le cas d’un regroupement de plusieurs ODX venant de calculateurs différents, permettant ainsi d’avoir accès direct à un calculateur spécifique d’un véhicule au sens VIN.

La figure 4 représente une deuxième étape d’une méthode de contrôle technique de véhicule selon l’invention. Dans cette étape, qui constitue une étape de liaison, il s’agit d’inclure, dans un premier temps, dans la base de données BD, d’autres informations techniques qui ne sont pas modélisables avec le standard ODX, mais qui sont utiles pour définir les tests utilisés pour le contrôle technique d’un véhicule. A titre d’exemple, les données techniques relatives au véhicule 6 et les références composant 7 sont visualisées dans la figure 4. Les données techniques relatives au véhicule 6 peuvent contenir, par exemple toutes les informations concernant la composition du véhicule (présence calculateurs, ...) sous forme d’un export numérique PDF qui sera rattaché à la structure PDX. Typiquement, le contenu de ce PDF est renseigné séparément de la base de données de diagnostic BD. De plus, il peut y avoir d’autres informations 8 avec lesquelles la base de données de diagnostic BD est alimentée dans cette phase, telles que des conditions de rejets de tests lors du contrôle technique, définies par le constructeur, qui peuvent être associées également à la structure PDX.

Ensuite, on peut générer un PDX 12 en fonction du client, notamment pour le contrôle technique pour un véhicule précis. La structure PDX contient bien évidemment des tags permettant de générer un PDX restreint au strict besoin du contrôle technique.

Enfin, le conteneur PDX 12 généré, est référencé dans le système de suivi des évolutions 11 permettant de tracer les évolutions éventuelles.

La figure 5 représente une étape supplémentaire d’une méthode de contrôle technique de véhicule selon l’invention. Il s’agit d’une étape de mise à jour de données S3 qui est en principe comparable à la phase visualisée dans la figure 4, sauf que dans le cas présent il s’agit de gérer un ensemble des corrections ou bugs éventuels. En effet, une fois un véhicule VIN commercialisé, celui-ci peut subir en après-vente les opérations telles que montage de post équipement (par exemple ajout remorque), évolution du logiciel ou encore échange du hardware, d’où le besoin de tracer toutes ces évolutions et tenir à jour la base de données BD pour éviter les fausses détections de non conformités lors du contrôle technique suite à des évolutions de définitions qui ne sont pas soumises à une ré-homologation. En particulier, la figure 5 visualise comment des versions mises à jour d’informations techniques (6a, 7a, 8a) sont enregistrées dans la base de donnée BD pendant cette étape. Basé sur ces mises à jour, un PDX mise à jour 12a en fonction du client peut être fourni. Le système de suivi des évolutions 11 intervient également dans cette étape de mise à jour en traçant les différentes évolutions de la base de donnée BD.

La figure 6 représente une variante de l’invention dans laquelle un PDX est constitué pour un ensemble de calculateurs constituants un véhicule VIN donné. Cette variante nécessite une bonne configuration des autres systèmes d’informations en lien avec la base de données de diagnostic BD. Dans cette variante, par rapport à la solution précédente, il y a deux fichiers Protocole normés KWP2000 (ISO 14230) ou UDS (ISO 14229). Ces fichiers contiennent l’ensemble des paramètres de communication (synchronisation, identifiants) et les requêtes génériques définies par type de protocole de communication utilisé.

Il y a plusieurs fichiers ODX ESD, pour gérer la diversité des codes défauts ou d’autres informations nécessaires pour discriminer le contenu de la structure PDX suivant le client destiné.

En court, une méthode de contrôle technique selon l’invention se déroule typiquement comme suit :

Pendant l’étape d’alimentation S2, visualisée dans la figure 2, une pluralité d’informations techniques 1, 2, 3, 4, 5 est enregistrée dans une base de données BD qui se trouve sur un serveur distant. Les informations techniques 1, 2, 3, 4, 5 sont chacune liées à au moins un calculateur de véhicule et définissent au moins un point de diagnostic et/ou une méthode de diagnostic dudit au moins un calculateur. Cette étape d’alimentation S2 se déroule pendant une phase de conception dudit au moins un point et/ou une méthode de diagnostic pour ledit au moins un calculateur.

Pendant l’étape de liaison, visualisée dans la figure 4, au moins un numéro de série d’un véhicule est associé audit au moins un calculateur de véhicule dans la base de données BD. Le numéro de série peut par exemple être inclus dans les données techniques relatives au véhicule 6. Cette étape de liaison se déroule typiquement au moment où l’on connaît le numéro de série d’un véhicule particulier.

Pendant l’étape de requête, qui a typiquement lieu en début d’un contrôle technique, un numéro de série d’un véhicule 9 sous contrôle technique est envoyé à la base de données BD.

Pendant l’étape de réponse, au moins une des informations techniques 1, 2, 3, 4, 5 liées à l’au moins un calculateur de véhicule associé audit numéro de série du véhicule 9 est transmise de la base de données BD à un outil utilisé lors du contrôle technique.

On comprendra que diverses modifications et/ou améliorations évidentes pour l'homme du métier peuvent être apportées aux différents modes de réalisation de l’invention décrits dans la présente description sans sortir du cadre de l'invention défini par les revendications annexées.

Claims

REVENDICATIONS

1. Méthode de contrôle technique de véhicule, la méthode comprenant: - une étape d’alimentation (S2) d’un serveur distant pendant laquelle une pluralité d’informations techniques (1, 2, 3, 4, 5) est enregistrée dans une base de données (BD) sur le serveur distant, les informations techniques (1, 2, 3, 4, 5) étant chacune liées à au moins un calculateur de véhicule et définissant au moins un point et/ou une méthode de diagnostic dudit au moins un calculateur, l'étape d'alimentation étant effectuée pendant une phase de conception dudit au moins un point et/ou une méthode de diagnostic pour ledit au moins un calculateur, - une étape de liaison pendant laquelle au moins un numéro de série d’un véhicule est associé audit au moins un calculateur de véhicule dans la base de données (BD), - une étape de requête pendant laquelle est envoyé depuis un centre de contrôle technique à la base de données (BD) le numéro de série dudit véhicule (9) qui doit effectuer un contrôle technique, et - une étape de réponse pendant laquelle au moins une des informations techniques (1,2, 3, 4, 5) liées à l’au moins un calculateur de véhicule associé audit numéro de série du véhicule (9) est transmise de la base de données (BD) à un outil utilisé lors du contrôle technique.
2. Méthode selon la revendication 1, caractérisé en ce que les informations techniques (1, 2, 3, 4, 5) comprennent, pour chacun des calculateurs, au moins une requête de diagnostic (1) et/ou au moins un identifiant du calculateur (2) et/ou au moins une synchronisation associé (3).
3. Méthode selon l'une des revendications 1 à 2, caractérisé en ce que les informations techniques (1, 2, 3, 4, 5) comprennent, pour chacun des calculateurs, au moins une matrice de défauts (4) et/ou au moins une stratégie de défauts (5).
4. Méthode selon l'une des revendications 1 à 3, caractérisé en ce que, pendant l’étape de liaison, des informations de véhicule (6, 7, 8) sont enregistrées dans la base de données (BD), les informations de véhicule (6, 7, 8) comprenant au moins des données techniques relatives au véhicule (6), telles qu’une nomenclature et/ou une liste d’options, et/ou au moins une référence composant (7) et/ou au moins une autre information (8), telle que une condition de rejet lors du contrôle technique définie par un constructeur de véhicule.
5. Méthode selon l’une des revendications 1 à 4, caractérisé en ce que les informations techniques (1, 2, 3, 4, 5) sont modélisées dans la base de données (BD) pour contrôle technique de véhicule selon le standard Open Diagnostic Data Exchange (ODX).
6. Méthode selon l’une des revendications 4 à 5, caractérisé en ce qu’au moins une des informations de véhicule (6, 7, 8) n’est pas modélisée selon le standard Open Diagnostic Data Exchange (ODX).
7. Méthode selon l'une des revendications 1 à 6, caractérisé en ce que la méthode comprend une étape de création (S1) de paquets d’informations modélisées selon le standard Open Diagnostic Data Exchange (ODX), où un paquet d’informations modélisées selon le standard Open Diagnostic Data Exchange (ODX) est nommé PDX, pendant laquelle un PDX par calculateur est créé.
8. Méthode selon l'une des revendications 1 à 6, caractérisé en ce que la méthode comprend une étape de création (S1) de paquets d’informations modélisées selon le standard Open Diagnostic Data Exchange (ODX), où un paquet d’informations modélisées selon le standard Open Diagnostic Data Exchange (ODX) est nommé PDX, pendant laquelle un PDX par numéro de série est créé.
9. Méthode selon l'une des revendications 1 à 8, caractérisé en ce que la méthode comprend une étape de mise à jour de données (S3), où l’étape de mise à jour de données (S3) se déroule après la conception de moyens de diagnostic pour le calculateur particulier.
10. Méthode selon l’une des revendications 7 à 9, caractérisé en ce que la méthode comprend une étape de création de PDX spécialisé (S4) pour contrôle technique.