Le KWP2000 : l'ancêtre de l'UDS
Pour comprendre le langage de diagnostic moderne, il est utile de connaître celui qui l'a précédé et façonné. Presque tout ce qu'on croit propre à l'UDS vient de là.
Le contexte : la ligne K et la normalisation
Avant l'UDS — le protocole de diagnostic unifié d'aujourd'hui — chaque constructeur avait tendance à parler son propre dialecte, avec ses connecteurs et ses commandes. Le KWP2000 (Keyword Protocol 2000, normalisé par l'ISO 14230) fut une étape majeure de normalisation. À l'origine, il s'appuie sur la ligne K : un fil de diagnostic unique, plus ancien que le CAN, hérité de l'ISO 9141-2. Sur cette couche physique, les échanges sont lents — de l'ordre de 1,2 à 10,4 kBaud — et les messages plafonnent à 255 octets.
La ligne K se retrouve encore aujourd'hui sur la broche 7 de la prise OBD, vestige de cette génération. Sur les véhicules européens, Chrysler et asiatiques des années 2000 à 2004 environ, c'était la voie de diagnostic courante, avant la généralisation du CAN.
L'initialisation et l'adressage : les gestes d'une génération
Le dialogue KWP2000 sur ligne K commence par un rituel d'initialisation qui a marqué toute une génération d'outils : une phase d'éveil du calculateur (historiquement une séquence lente à cinq bauds, ou une variante plus rapide), au terme de laquelle le calculateur renvoie des octets de « mots-clés » qui donnent son nom au protocole. Chaque message porte ensuite une structure fixe : un en-tête (adresse cible, adresse source), les octets de données, et une somme de contrôle qui clôt la trame. L'échange peut être physique (un calculateur précis) ou fonctionnel (tous les calculateurs concernés par une fonction). Ces notions — éveil, adressage, en-tête, somme de contrôle — se retrouvent, sous une forme modernisée, dans le diagnostic actuel.
Ce que le KWP2000 a introduit
Beaucoup de notions qu'on attribue à l'UDS viennent en réalité de cette génération :
- Les sessions de diagnostic : passer d'un mode normal à un mode étendu pour débloquer des fonctions réservées. C'est le principe repris et généralisé par les sessions UDS.
- Les services identifiés par un numéro : lire des valeurs, effacer des codes défaut, piloter un actionneur, écrire en mémoire. Chaque opération porte un identifiant, la réponse positive se déduisant de la requête par un décalage fixe.
- Le déverrouillage par défi-réponse avant les opérations sensibles : l'ancêtre direct du seed & key d'aujourd'hui.
- La séquence de reprogrammation : ouvrir une session adaptée, s'authentifier, effacer, transférer les données par blocs, refermer proprement.
De la requête à la réponse
Le mécanisme est resté le même jusqu'à aujourd'hui. Un service se demande par son numéro ; si le calculateur accepte, il répond par ce même numéro augmenté d'un décalage fixe, suivi des données. S'il refuse, il renvoie une réponse négative accompagnée d'un code motif : session inadaptée, accès non déverrouillé, condition non remplie, tentative trop nombreuse. Cette logique de requête, réponse positive ou réponse négative motivée, structure encore l'UDS. C'est pourquoi un reprogrammateur qui a compris le KWP2000 lit sans peine les échanges d'un outil moderne : il retrouve les sessions, les déverrouillages et les motifs de refus, sous des numéros différents mais avec la même grammaire. Rien, dans le diagnostic actuel, ne lui est vraiment étranger.
Du KWP2000 à l'UDS : une filiation directe
L'UDS (ISO 14229) est l'héritier direct du KWP2000 (ISO 14230) : il a repris cette structure, l'a étendue et unifiée. Là où le KWP2000 était lié à la ligne K, l'UDS est indépendant du transport — il circule aussi bien sur CAN, sur LIN, sur FlexRay, sur Ethernet (DoIP) que sur la K-Line. Le vocabulaire s'est stabilisé : chaque service porte un identifiant fixe, chaque refus un code motif normalisé. Mais l'esprit est celui du KWP2000. Qui comprend le KWP2000 comprend l'essentiel de l'UDS ; il ne lui reste qu'à apprendre la nouvelle table des services et à profiter d'un transport plus rapide.
Le KWP2000 a d'ailleurs connu une variante portée par le CAN, intermédiaire entre la ligne K et l'UDS : sur certains groupes, il circulait sur le bus CAN via un protocole de transport, avant que l'UDS ne s'impose comme standard unique. Cette étape explique pourquoi certains outils anciens « parlaient CAN » tout en restant en logique KWP.
Pourquoi ça reste utile à connaître
- On rencontre encore le KWP2000 sur des véhicules d'un certain âge, et sur des calculateurs qui n'ont jamais migré vers l'UDS. Un outil qui ne gère que l'UDS peut rester muet devant eux.
- Cela explique la filiation des protocoles et des outils : rien n'est apparu de nulle part, et les interfaces anciennes de type MPPS ou Galletto parlaient précisément ce langage sur les EDC15 et EDC16.
- Cela aide à situer un véhicule : le type de diagnostic disponible dépend de sa génération, de la ligne K au CAN, puis à l'Ethernet.
Le fil de l'histoire va de la ligne K et du KWP2000 au CAN et à l'UDS, puis à l'Ethernet et au DoIP. Chaque étape a gardé l'esprit de la précédente en la rendant plus rapide et plus universelle.
Voir aussi les sessions de diagnostic, le seed & key et le DoIP.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
