Les conteneurs constructeur : FRF, ODX, PDX, SGO

Quand un reprogrammateur récupère un fichier « usine », ce n'est presque jamais une image mémoire directement éditable. C'est un conteneur : un emballage normalisé ou propriétaire qui renferme l'image de flash, la décrit et, très souvent, la compresse et la chiffre. Confondre un conteneur avec un .bin fait perdre du temps — et parfois pousse à des manipulations inutiles.

ODX et PDX : le standard diagnostique

L'ODX (Open Diagnostic data eXchange) est la norme ASAM MCD-2 D, équivalente à l'ISO 22901-1. C'est un format XML qui décrit toutes les données diagnostiques d'un calculateur sur son cycle de vie : identification, codes défaut, routines, agencement mémoire et logique de flashage. Le PDX est un Packaged ODX : plusieurs fichiers ODX empaquetés dans une archive unique. Le calculateur lui-même sait référencer son fichier ODX : la lecture UDS du DID F19E (ODXFile) renvoie cette référence. Voir les identifiants lus par le calculateur.

Un ODX ne se limite pas au flash : la norme ASAM MCD-2 D couvre plusieurs catégories de données — identification du calculateur, paramètres de communication, description des variantes, définitions de codes défaut et données de programmation. Le fichier usine que l'on manipule pour reflasher n'est donc qu'une partie de ce que l'ODX sait décrire, ce qui explique aussi qu'un PDX, en empaquetant l'ensemble, pèse souvent lourd.

FRF, SGO et les conteneurs VAG

Le FRF est le conteneur de flash du groupe VAG (on le rencontre aussi côté Ford) : il encapsule un ODX. Son format n'a pas changé depuis son introduction, si bien qu'un même mécanisme d'extraction s'applique à l'ensemble des FRF. À côté, le monde VAG utilise d'autres conteneurs de flash : SGO, SGM, SOX, ainsi que des blocs propres aux Simos. Chacun emballe la ou les images destinées à un calculateur précis.

Pourquoi c'est compressé et chiffré

Le fait technique lourd et souvent ignoré : à l'intérieur d'un ODX, les blocs peuvent être compressés ET chiffrés. Sur les conteneurs de Simos 12, Simos 18.1 et Simos 18.10, on trouve documentés un schéma de chiffrement dit « AUDI AES » et un schéma de compression dit « AUDI LZSS », plus un schéma spécifique aux boîtes DSG DQ250-MQB. D'autres calculateurs emploient encore d'autres mécanismes à l'intérieur de leurs fichiers ODX.

C'est l'explication du grand classique d'atelier : « j'ai téléchargé le FRF, pourquoi mon éditeur ne l'ouvre pas ? ». Parce qu'entre le fichier usine et l'image mémoire éditable, il y a un conteneur, une compression et un chiffrement. Un fichier usine n'est pas un .bin. Voir les formats de fichier.

Trois raisons se cumulent pour justifier compression et chiffrement. La taille, d'abord : un flash de plusieurs mégaoctets circule mieux compressé. La propriété intellectuelle, ensuite : le logiciel d'un calculateur est un actif que le constructeur ne tient pas à exposer en clair. La sécurité, enfin : entre le durcissement anti-altération lié aux émissions et les obligations de cybersécurité véhicule, un fichier usine en clair serait une porte ouverte. Ce durcissement s'est nettement accentué à partir de 2020 sur les calculateurs Bosch récents. Voir le règlement UN R155 et ce que la cybersécurité change.

Ce que le conteneur encapsule vraiment

Le logiciel d'un calculateur n'est pas une image unique, mais plusieurs blocs logiques — application (ASW), calibration, jeux de données — avec des dépendances entre eux. Le conteneur usine décrit l'agencement mémoire et la logique de flashage : quel bloc va à quelle adresse, dans quel ordre, avec quelles préconditions, et quelles combinaisons de blocs ont le droit de tourner ensemble.

Il embarque aussi la logique de la session de programmation. Cas VAG documenté publiquement, cité ici au titre du principe : l'algorithme de session est de type « SA2 » ; un script SA2 est contenu dans le conteneur ODX du véhicule, et son bytecode s'exécute sur la graine pour produire la clé. Autrement dit, la logique de calcul voyage avec le fichier de flash usine — sans qu'il soit pour autant question ici de calculer une clé. Voir seed & key.

À quoi ça sert, côté reprogrammateur

• Comprendre la destination. Un conteneur usine est fait pour la programmation officielle par UDS, pas pour l'édition directe. C'est un fichier de production, pas un fichier de travail.
• Anticiper le durcissement. Sur les MD1 / MG1 récents, et particulièrement sur les MG1 de véhicules récents, le chiffrement descend au niveau du bootloader : les conteneurs deviennent encore moins abordables, et beaucoup d'outils sortent en erreur. C'est un fait à connaître avant de promettre un délai.
• Relier aux dépendances de blocs. La dépendance entre application et calibration est exactement ce que vérifie le calculateur en fin de programmation : c'est pourquoi une calibration ne « passe » pas sur n'importe quel ASW. Voir la séquence de flash UDS.

Le message tient en une phrase : entre le fichier que l'on télécharge et les octets que le calculateur exécute, il y a une chaîne d'emballages. La connaître évite de prendre un conteneur pour une image, et de perdre une heure à « ouvrir » un FRF qui n'est pas fait pour ça.

Voir aussi BIN, HEX et S-record, les fichiers de définition et le bootloader et le BSL.

Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.