Hygiène du projet WinOLS : sauvegarde originale, notes A2L/DAMOS, audit de checksum et dossier de récupération

Pourquoi l’hygiène des projets WinOLS est importante

Les problèmes de tuning ECU commencent souvent avant même la modification du fichier. L’absence de sauvegarde originale, un nom de fichier peu clair, une mauvaise version logicielle, des dossiers client mélangés, un checksum non vérifié ou un journal d’outil perdu peuvent créer plus de risques que la calibration elle-même.

Une bonne hygiène de projet signifie que chaque projet ECU dispose d’une structure de dossiers cohérente, d’un fichier original vérifié, de notes, d’un historique de versions, d’un audit de checksum et d’un plan de récupération. Ce n’est pas de l’administration de bureau. C’est du contrôle technique des risques.

Ce workflow est rédigé pour les spécialistes ECU, les tuners et les ateliers qui veulent une gestion de projet WinOLS plus propre et une manipulation de fichiers plus sûre. Il accompagne aussi les workflows de recherche utilisant des communautés comme MHHAuto et CarTechnology.

Commencer par la responsabilité juridique et technique

Avant de modifier un fichier ECU, confirmez que l’intervention est légale, autorisée et techniquement adaptée. L’atelier doit disposer de l’accord du client, de l’identification du véhicule, d’une sauvegarde originale et d’une compréhension claire de l’objectif de la calibration.

Ne réalisez pas de travail sur fichier qui enfreint la loi locale, les règles sur les émissions, les exigences de sécurité ou les accords client. Le tuning ECU doit être considéré comme un service technique professionnel, et non comme un simple montage aléatoire de fichiers.

1. Créer une structure de dossier standard pour le projet

Chaque projet ECU doit suivre la même structure de dossiers. Une structure cohérente évite de mélanger les fichiers entre véhicules, outils ou clients.

Exemple de dossier projet :

 Customer_or_InternalRef/ Vehicle_Info/ 00_Original_Read/ 01_Tool_Logs/ 02_WinOLS_Project/ 03_Definitions_A2L_DAMOS_Notes/ 04_Modified_Files/ 05_Checksum_Audit/ 06_Write_Logs/ 07_Test_Results/ 08_Recovery/ 09_Delivery/ 

Les noms exacts peuvent être adaptés, mais la logique doit rester la même : original d’abord, modifications séparées, récupération toujours disponible.

2. Consigner l’identification du véhicule et de l’ECU

Avant d’ouvrir WinOLS, enregistrez l’identité technique de l’ECU. Cela évite de sélectionner le mauvais fichier et facilite la reprise ultérieure si le projet doit être rouvert.

À consigner :

• marque et modèle du véhicule ;
• année du modèle ;
• code moteur ;
• type de transmission si pertinent ;
• fabricant de l’ECU ;
• type d’ECU ;
• numéro matériel ;
• numéro logiciel ;
• version logicielle ;
• méthode de lecture : OBD, bench, boot ou autre ;
• outil utilisé ;
• tension batterie ou bench ;
• date et nom du technicien.

Ces informations doivent être stockées dans un simple fichier texte ou une note projet à l’intérieur du dossier.

3. Protéger la sauvegarde originale

La lecture originale est le fichier le plus important de tout le projet. Elle ne doit jamais être écrasée, renommée sans précaution ni stockée uniquement sur un seul ordinateur portable.

Règles pour le fichier original :

• enregistrer immédiatement la lecture originale ;
• faire au moins une copie de sauvegarde ;
• stocker une copie en dehors du dossier de travail actif ;
• ne pas modifier directement le fichier original ;
• garder un nom de fichier original clair et cohérent ;
• noter la taille du fichier ;
• créer un hash de fichier si cela fait partie du workflow ;
• conserver le journal de l’outil avec la lecture originale.

Si l’original est perdu, la récupération devient plus difficile. Si le mauvais original est utilisé, tout le projet devient peu fiable.

4. Utiliser un nommage clair des fichiers

Les noms de fichiers doivent permettre au technicien de savoir de quel fichier il s’agit sans l’ouvrir. Évitez des noms comme « final », « newfinal », « test2 » ou « goodfile ». Ces noms deviennent dangereux lorsque plusieurs versions existent.

Un meilleur format de nommage :

 Brand_Model_Engine_ECU_HW_SW_ORI_Date.bin Brand_Model_Engine_ECU_HW_SW_MOD_v01_Date.bin Brand_Model_Engine_ECU_HW_SW_MOD_v02_ChecksumOK_Date.bin 

N’incluez pas de données personnelles complètes du client dans les noms de fichiers. Utilisez des références internes si nécessaire.

5. Garder les notes A2L et DAMOS organisées

Les informations A2L et DAMOS peuvent être utiles pour l’identification des maps et la documentation du projet, mais elles doivent être gérées avec soin. Conservez des notes sur la source, la version, la compatibilité et ce qui a réellement été utilisé.

Notes recommandées :

• source de définition ou référence interne ;
• famille d’ECU ;
• correspondance de version logicielle ;
• maps identifiées ;
• maps confirmées manuellement ;
• maps non utilisées ;
• informations sur les axes ;
• hypothèses sur les unités ;
• commentaires sur les zones incertaines.

Ne supposez jamais qu’une définition est correcte simplement parce qu’elle se charge. Vérifiez toujours la structure réelle du fichier et la logique de calibration connue.

6. Séparer les notes de recherche des décisions du projet

Les fils de forum, anciens projets et notes partagées peuvent aider la recherche, mais ils ne doivent pas être mélangés aux décisions finales de calibration. Conservez les notes de recherche séparées des notes de projet confirmées.

Utilisez deux catégories :

• Notes de recherche : liens de forum, discussions sur ECU similaires, commentaires d’outil, retours d’utilisateurs.
• Notes confirmées : valeurs vérifiées dans le fichier actuel, maps validées, modifications effectuées et résultats de test.

Cette séparation évite que de vieilles hypothèses deviennent des erreurs cachées dans un nouveau projet.

7. Versionner chaque fichier modifié

Chaque modification doit créer une nouvelle version. N’écrasez jamais un fichier modifié précédent. Si un essai routier ou un test au banc révèle un problème, le technicien doit pouvoir revenir rapidement à la version précédente.

Les notes de version doivent inclure :

• numéro de version ;
• date ;
• technicien ;
• raison de la modification ;
• maps modifiées ;
• résultat attendu ;
• statut du checksum ;
• résultat du test ;
• si le fichier a été écrit dans l’ECU.

Un fichier versionné sans notes n’est qu’une supposition avec un autre nom.

8. Effectuer un audit de checksum

La gestion du checksum est une étape critique. Certains outils corrigent automatiquement les checksums, d’autres nécessitent une correction manuelle, et certains workflows demandent une vérification avant écriture. Le technicien doit savoir quel outil est responsable de la correction du checksum et comment le résultat est confirmé.

Un audit de checksum doit enregistrer :

• version du fichier vérifiée ;
• outil utilisé pour la correction du checksum ;
• si le checksum a été corrigé automatiquement ou manuellement ;
• statut du checksum avant écriture ;
• outil d’écriture utilisé ;
• journal d’écriture sauvegardé ;
• lecture ou vérification après écriture si elle a été effectuée ;
• tous les avertissements affichés par l’outil.

Ne considérez pas « aucun message d’erreur » comme un audit complet. Conservez les preuves.

9. Garder un dossier de récupération prêt

Un dossier de récupération est préparé avant l’écriture, pas après qu’un problème survient. En cas d’échec d’écriture, le technicien ne doit pas perdre de temps à chercher le fichier original, le protocole, le mot de passe, le journal de l’outil ou les notes de connexion bench.

Le dossier de récupération devrait inclure :

• la lecture originale ;
• le dernier fichier modifié connu comme bon ;
• les journaux d’outil ;
• l’identification de l’ECU ;
• la méthode de lecture et d’écriture ;
• les notes bench ou boot si applicables ;
• des photos de l’étiquette ECU ;
• les notes d’alimentation ;
• les notes de pinout ou de connexion lorsque c’est légalement et techniquement approprié ;
• les notes de contact ou de support si le fournisseur de l’outil est impliqué.

Le meilleur plan de récupération est celui préparé avant l’événement à risque.

10. Tester et documenter le résultat

Après l’écriture, le travail n’est pas terminé tant que le véhicule n’a pas été contrôlé. Enregistrez le scan de diagnostic, les notes de test et les informations de remise au client.

Les contrôles après écriture peuvent inclure :

• contrôle de communication avec l’ECU ;
• scan DTC ;
• comportement au ralenti et au démarrage ;
• contrôle des données en direct ;
• essai routier ou essai au banc si pertinent ;
• validation de la plainte client ;
• version finale du fichier enregistrée ;
• sauvegarde remise ou archivée selon la politique de l’atelier.

Si des défauts apparaissent, enregistrez-les au lieu de supprimer les preuves. De bonnes notes accélèrent la correction.

Tableau d’hygiène du projet

Quand l’accès au forum aide

Pour la recherche ECU, le comportement des outils, les discussions firmware et les cas techniques, consultez CarTechnology. Pour des discussions plus larges sur l’ECU automobile, le diagnostic et les logiciels, consultez MHHAuto. La recherche sur les forums doit soutenir la gestion professionnelle des fichiers, et non remplacer la vérification dans le projet réel.

Checklist d’hygiène de projet WinOLS

• Créer un dossier standard avant de commencer.
• Consigner l’identification du véhicule et de l’ECU.
• Enregistrer la lecture originale et faire une copie de sauvegarde.
• Ne jamais modifier directement le fichier original.
• Utiliser des noms de version clairs.
• Garder les notes A2L/DAMOS organisées.
• Séparer les notes de recherche des notes de projet confirmées.
• Versionner chaque fichier modifié.
• Exécuter et documenter l’audit de checksum.
• Préparer le dossier de récupération avant l’écriture.
• Sauvegarder les journaux d’écriture et les résultats de test après écriture.

FAQ

Pourquoi la sauvegarde originale est-elle si importante ?

Le fichier original est la référence pour la comparaison, la correction et la récupération. Sans lui, le projet devient plus difficile à vérifier et beaucoup plus difficile à restaurer en cas de problème.

Dois-je écraser les anciens fichiers modifiés ?

Non. Conservez chaque version importante avec des notes. L’écrasement des fichiers détruit l’historique du projet et complique le dépannage.

Les fichiers A2L et DAMOS sont-ils toujours corrects ?

Non. Ils doivent être appariés et vérifiés. Une définition peut se charger tout en restant fausse pour la version logicielle exacte ou la structure du fichier.

La correction automatique du checksum suffit-elle ?

Cela dépend de l’outil et de l’ECU. Notez toujours comment le checksum a été géré et conservez le résultat de l’outil ou le journal d’écriture lorsque c’est possible.

Que doit contenir un dossier de récupération ?

Lecture originale, dernier fichier valide, journaux d’outil, identification ECU, méthode de lecture/écriture, notes de connexion et toute information nécessaire pour récupérer l’ECU en toute sécurité.

Une bonne hygiène de projet WinOLS ne consiste pas à rendre les dossiers simplement plus jolis. Il s’agit de réduire les risques. Gardez l’original en sécurité, documentez l’ECU, versionnez chaque changement, auditez les checksums et préparez la récupération avant le début de l’écriture.