Deux fichiers peuvent sembler liés tout en constituant une mauvaise comparaison
Comparer un fichier original à un fichier modifié paraît simple : ouvrir les deux, trouver les différences et examiner les cartographies modifiées. La difficulté commence lorsque les fichiers ne partagent pas la même base logicielle.
Une mise à jour OEM peut déplacer des données, remplacer des sections de code, modifier des structures de calibration ou introduire de nouvelles variantes de cartographie. Une lecture virtuelle peut provenir d’un fichier de base de données correspondant plutôt que des octets exacts stockés auparavant dans l’ECU. Un fichier fourni par un client peut déjà contenir des modifications non documentées.
WinOLS peut afficher les différences, connecter des projets et prendre en charge le transfert des modifications, mais le logiciel ne remplace ni l’identification du fichier ni le jugement technique. Avant d’importer quoi que ce soit, le préparateur doit établir ce qu’est chaque fichier et si la comparaison est valide.
Définir les fichiers avant de les comparer
Utilisez des termes clairs dans le projet :
- ORI : l’original vérifié ou la meilleure base disponible pour le logiciel exact de l’ECU.
- MOD : une version modifiée dérivée d’une base documentée.
- Mise à jour OEM : une version logicielle constructeur plus récente ou différente.
- Original virtuel : un fichier original correspondant à l’identification de l’ECU par le fournisseur de l’outil.
- Readback : données lues physiquement dans l’unité de commande après écriture, lorsque cela est pris en charge.
- Fichier inconnu : tout fichier pour lequel il n’existe pas assez de preuves pour le classer avec confiance.
Ne qualifiez pas un fichier d’ORI simplement parce que son nom contient « original ». Les noms de fichiers sont des notes, pas une preuve.
Établir une fiche d’identité du fichier
Avant d’ouvrir la vue de comparaison, consignez les informations d’identification disponibles pour chaque fichier.
| Champ d’identité | Fichier A | Fichier B |
|---|---|---|
| Famille d’ECU | Noter le type exact | Noter le type exact |
| Numéro matériel | Valeur issue de l’outil ou de l’étiquette | Valeur issue de l’outil ou de la source |
| Numéro logiciel | Valeur exacte | Valeur exacte |
| Numéro de calibration ou de mise à jour | Si disponible | Si disponible |
| Méthode de lecture | OBD, Bench, Boot ou virtuel | OBD, Bench, Boot ou virtuel |
| Taille du fichier | Enregistrée en octets | Enregistrée en octets |
| Source | Véhicule, base de données de l’outil ou client | Véhicule, base de données de l’outil ou client |
| Historique connu | Origine, préparé, mis à jour ou inconnu | Origine, préparé, mis à jour ou inconnu |
Une taille de fichier identique est utile, mais ne prouve pas que deux fichiers partagent la même structure logicielle.
Trois types de comparaison différents
La plupart des travaux de comparaison dans WinOLS relèvent de l’une de ces trois situations. Chacune demande un niveau de prudence différent.
1. ORI contre MOD à partir de la même base
C’est la comparaison la plus propre. Le MOD a été créé directement à partir de l’ORI et les deux fichiers ont la même structure. Les différences doivent correspondre à des modifications de calibration documentées et aux éventuels changements attendus liés au checksum.
2. Une version logicielle OEM contre une autre
Ce n’est pas une comparaison de préparation normale. De grandes zones peuvent différer parce que le constructeur a modifié le code, le diagnostic, la structure de calibration ou l’alignement des données. Les différences ne doivent pas être interprétées comme des changements de préparation.
3. Une ancienne version modifiée contre une nouvelle version OEM
C’est le scénario de transfert le plus risqué. Les anciennes adresses peuvent ne plus pointer vers les mêmes cartographies. Les modifications doivent être recréées et validées par rapport à la nouvelle structure logicielle plutôt que copiées aveuglément.
Commencer par une vue d’ensemble des différences
Avant d’ouvrir les cartographies individuelles, observez le schéma global des différences.
Demandez-vous :
- Les modifications sont-elles concentrées dans une petite zone de calibration ?
- Les différences sont-elles réparties sur la majeure partie du fichier ?
- De grands blocs semblent-ils déplacés ?
- Les zones de code et de calibration sont-elles toutes deux différentes ?
- Y a-t-il des motifs de différences répétés ?
- Un fichier contient-il des données supplémentaires ou du remplissage ?
- Les changements sont-ils cohérents avec l’historique du fichier ?
Un groupe compact de modifications de cartographie peut être cohérent avec une calibration normale. De grandes différences généralisées exigent généralement une analyse de la version logicielle avant toute conclusion au niveau des cartographies.
Les motifs de différences sont des indices, pas des preuves
| Motif de différence | Explication possible | Vérification requise |
|---|---|---|
| Petits समूहes à l’intérieur de cartographies connues | Modifications de calibration documentées | Confirmer les axes, les unités et la fonction attendue |
| Grandes régions continues | Mise à jour logicielle OEM ou base de fichier différente | Vérifier les numéros logiciels et la structure du code |
| Octets isolés répétés | Checksum, compteurs, métadonnées ou traitement par l’outil | Contrôler le protocole et le flux de travail du checksum |
| Cartographies similaires à des adresses différentes | Déplacement des données entre versions logicielles | Faire correspondre par la structure, les axes et la fonction, pas par l’adresse |
| Différences hors des zones de calibration attendues | Mauvais fichier, mise à jour, patch ou modification non documentée | Arrêter le transfert jusqu’à ce que l’origine du fichier soit comprise |
Aucun motif ne doit être considéré comme une garantie. Utilisez-le pour décider ce qui exige un examen plus poussé.
Comparer les cartographies, pas seulement les adresses
Une adresse n’est valable que dans sa propre structure logicielle. Lorsque les fichiers utilisent des versions logicielles différentes, la même fonction peut être stockée à une autre adresse ou représentée différemment.
Pour chaque cartographie comparée, confirmez :
- les dimensions de la cartographie ;
- les valeurs d’axe ;
- l’ordre des axes ;
- le type de données ;
- l’ordre des octets ;
- le facteur et l’offset ;
- l’unité d’ingénierie ;
- la structure de données environnante ;
- la relation avec les cartographies cibles et limiteuses associées.
Un tableau de même forme n’est pas nécessairement la même fonction. Les axes et la logique environnante doivent aussi être cohérents.
Utiliser les versions de référence avec prudence
Une version de référence est utile pour l’examen d’une même base de projet ou dans le cadre d’une comparaison de mise à jour contrôlée. Elle permet au technicien d’inspecter les valeurs et les différences sans changer de fichier en permanence.
Un flux de travail propre est le suivant :
- Conserver intacte la version originale vérifiée.
- Créer ou importer le fichier de comparaison comme version séparée ou projet lié.
- Confirmer l’identification du projet avant de relier les fichiers.
- Examiner d’abord les différences générales.
- Ouvrir les cartographies connues et comparer structure et valeurs.
- Consigner quelles modifications sont confirmées, incertaines ou rejetées.
Ne transférez pas automatiquement des modifications simplement parce que WinOLS peut identifier des zones similaires.
Quand l’import automatique est approprié
L’importation des modifications est la plus fiable lorsque les fichiers partagent la même base logicielle et que la relation original-vers-modifié est documentée.
Le transfert automatique ou semi-automatique doit être traité avec prudence lorsque :
- les numéros logiciels diffèrent ;
- un fichier est une mise à jour OEM ;
- un fichier est une lecture virtuelle et l’autre une lecture physique ;
- les adresses des cartographies ont changé ;
- le MOD source contient des patches non documentés ;
- les tailles de fichier ou les structures mémoire diffèrent ;
- le projet source utilise des définitions non vérifiées.
Dans ces situations, recréez les modifications de calibration nécessaires cartographie par cartographie et vérifiez la logique sur le logiciel cible.
Créer une feuille de transfert des modifications
| Cartographie ou fonction | État de la source | Correspondance cible | Action |
|---|---|---|---|
| Demande conducteur | Confirmée dans la source | Axes et unités concordants | Recréer et vérifier |
| Limiteur de couple | Confirmé | Plusieurs variantes cibles trouvées | Étudier avant modification |
| Cible de pression | Modifiée dans la source | Mise à l’échelle non confirmée | Ne pas transférer pour l’instant |
| Patch inconnu | Non documenté | Aucun équivalent cible vérifié | Rejeter du transfert |
Cette feuille empêche des modifications source non documentées d’entrer silencieusement dans le nouveau projet.
Ne transférez pas aveuglément les modifications en pourcentage
Une astuce courante consiste à calculer de combien une valeur a changé dans l’ancien MOD et à appliquer le même pourcentage à une cartographie ressemblante dans le nouveau logiciel. Cela peut être trompeur, voiture le constructeur peut avoir changé la valeur de base, les unités, la relation de limitation ou la stratégie de commande.
Posez plutôt les questions suivantes :
- Quel résultat la modification d’origine était-elle censée obtenir ?
- Le nouveau logiciel contient-il déjà une cible révisée ?
- Quelles cartographies associées commandent la même fonction ?
- Les axes et les plages de fonctionnement sont-ils équivalents ?
- Le résultat attendu peut-il être validé avec des logs ?
Transférez l’objectif de calibration, pas seulement les anciens chiffres.
Séparer les changements de calibration des patches et des métadonnées
Toutes les différences ne correspondent pas à une modification de cartographie. Les fichiers peuvent aussi différer à cause de :
- correction de checksum ;
- traitement spécifique à l’outil ;
- compteurs de programmation ;
- patchs logiciels ;
- métadonnées de version ;
- configuration de diagnostic ;
- travail précédent inconnu.
Les modifications inconnues en dehors de la zone de calibration documentée doivent être étudiées avant l’approbation du fichier.
Valider le projet cible après le transfert
Après recréation ou importation des modifications, effectuez une revue complète du projet :
- vérifier chaque cartographie modifiée par rapport à ses axes ;
- examiner les cibles et limiteurs associés ;
- confirmer les unités et l’échelle ;
- inspecter l’interpolation et les cellules de bord ;
- vérifier qu’aucune zone involontaire n’a changé ;
- confirmer la responsabilité du checksum ;
- enregistrer un rapport de différences par rapport à l’ORI cible ;
- étiqueter clairement la version finale du fichier ;
- préparer le bon fichier de récupération ;
- planifier un test contrôlé de diagnostic et de datalogging.
Une exportation réussie ne prouve pas que la logique de calibration est correcte.
Ressources WinOLS associées
Pour la correspondance des définitions, la validation des map packs et les contrôles d’échelle, lisez WinOLS A2L/DAMOS & Map Packs. Avant d’écrire le fichier finalisé, consultez WinOLS Checksums.
Pour les discussions sur les versions logicielles ECU et des cas de fichiers réels, consultez CarTechnology ou MHHAuto. Considérez les informations du forum comme une piste de recherche et validez chaque modification dans le projet cible réel.
Checklist de comparaison de fichiers
- Classer chaque fichier comme ORI, MOD, mise à jour OEM, original virtuel ou inconnu.
- Enregistrer l’identification matérielle et logicielle de l’ECU.
- Confirmer la méthode de lecture et la taille du fichier.
- Vérifier si les fichiers partagent la même base logicielle.
- Examiner le motif global des différences avant d’ouvrir les cartographies.
- Faire correspondre les cartographies par structure, axes, unités et fonction.
- Ne pas transférer les modifications à partir de l’adresse seule.
- Rejeter les patchs non documentés tant qu’ils ne sont pas compris.
- Recréer soigneusement les modifications lorsque la cible est une version OEM différente.
- Enregistrer un rapport final de différences par rapport à l’original cible.
- Valider la gestion du checksum et préparer la récupération.
FAQ
Puis-je copier des cartographies d’une ancienne version logicielle OEM vers une plus récente ?
Pas en toute sécurité à partir de l’adresse seule. Confirmez la fonction de la cartographie, ses dimensions, ses axes, son échelle et la stratégie environnante dans le nouveau logiciel, puis recréez la modification souhaitée.
Une taille de fichier identique signifie-t-elle que les fichiers sont compatibles ?
Non. Des fichiers de même taille peuvent contenir du code, des structures de calibration ou des versions logicielles différents.
Quelle est la comparaison ORI contre MOD la plus sûre ?
La comparaison la plus sûre utilise un original vérifié et une version modifiée documentée, créée directement à partir de cette même base originale.
Pourquoi y a-t-il des différences en dehors des cartographies que j’ai modifiées ?
Il peut s’agir de changements de checksum, de métadonnées, de traitement par l’outil, de compteurs ou de travail non documenté. Identifiez-les avant d’approuver le fichier.
Faut-il utiliser l’import automatique pour une mise à jour OEM ?
Seulement avec une validation soigneuse. Lorsque la base logicielle change, les cartographies peuvent se déplacer ou changer de structure. Une revue manuelle et une recréation contrôlée sont souvent plus sûres.
La comparaison dans WinOLS n’est pas simplement une recherche d’octets différents. C’est un processus consistant à prouver l’identité du fichier, à comprendre la relation logicielle et à transférer uniquement les décisions de calibration qui restent valables dans la version cible.
