Два файла могат да изглеждат свързани и въпреки това да са грешно сравнение
Сравняването на оригинален файл с модифициран файл звучи лесно: отворете и двата, намерете разликите и прегледайте променените карти. Трудността започва, когато файловете не споделят една и съща софтуерна база.
OEM актуализация може да премести данни, да замени секции с код, да промени калибрационни структури или да въведе нови варианти на карти. Виртуално четене може да дойде от съвпадащ файл в база данни, а не от точните байтове, съхранени преди това в ECU. Файл, предоставен от клиент, може вече да съдържа недокументирани промени.
WinOLS може да показва разлики, да свързва проекти и да поддържа прехвърлянето на промени, но софтуерът не може да замени идентификацията на файлове и техническата преценка. Преди да импортира каквото и да е, тунерът трябва да установи какво представлява всеки файл и дали сравнението е валидно.
Дефинирайте файловете преди да ги сравнявате
Използвайте ясни термини в рамките на проекта:
- ORI: верифицираният оригинал или най-добрата налична базова линия за точния ECU софтуер.
- MOD: модифицирана версия, произлязла от документирана базова линия.
- OEM актуализация: по-нова или различна версия на производствения софтуер.
- Виртуален оригинал: оригинален файл, съпоставен от идентификацията на ECU от доставчика на инструмента.
- Readback: данни, физически прочетени от контролния блок след запис, където се поддържа.
- Непознат файл: всеки файл без достатъчно доказателства за уверената му класификация.
Не маркирайте файл като ORI само защото името му съдържа „original". Имената на файловете са бележки, а не доказателство.
Изградете идентификационен лист на файла
Преди да отворите изгледа за сравнение, запишете наличната идентификация за всеки файл.
| Идентификационно поле | Файл A | Файл B |
|---|---|---|
| Семейство ECU | Запишете точния тип | Запишете точния тип |
| Хардуерен номер | Стойност от инструмент или етикет | Стойност от инструмент или източник |
| Софтуерен номер | Точна стойност | Точна стойност |
| Номер на калибриране или актуализация | Където е налично | Където е налично |
| Метод на четене | OBD, Bench, Boot или виртуален | OBD, Bench, Boot или виртуален |
| Размер на файла | Записан в байтове | Записан в байтове |
| Източник | Автомобил, база данни на инструмента или клиент | Автомобил, база данни на инструмента или клиент |
| Известна история | Стандартен, тунингован, актуализиран или неизвестен | Стандартен, тунингован, актуализиран или неизвестен |
Съвпадащият размер на файла е полезен, но не доказва, че два файла споделят една и съща софтуерна структура.
Три различни задачи за сравнение
Повечето сравнителни задачи в WinOLS попадат в една от три ситуации. Всяка изисква различно ниво на внимание.
1. ORI срещу MOD от една и съща база
Това е най-чистото сравнение. MOD файлът е създаден директно от ORI и двата файла имат еднаква структура. Разликите трябва да съответстват на документирани калибровъчни редакции и всякакви очаквани промени, свързани с контролната сума.
2. Една OEM версия на софтуера срещу друга
Това не е обичайно сравнение на настройки. Големи области може да се различават, тъй като производителят е променил код, диагностика, калибровъчна структура или подравняване на данните. Разликите не трябва да се интерпретират като промени в настройките.
3. Модифицирана стара версия срещу по-нова OEM версия
Това е сценарият с най-висок риск при прехвърляне. Старите адреси може вече да не сочат към същите карти. Промените трябва да бъдат пресъздадени и валидирани спрямо новата софтуерна структура, вместо да се копират сляпо.
Започнете с преглед на разликите на високо ниво
Преди да отваряте отделни карти, разгледайте общия модел на разликите.
Запитайте се:
- Концентрирани ли са промените в малка калибровъчна област?
- Разпределени ли са разликите в по-голямата част от файла?
- Изглеждат ли големи блокове изместени?
- Различават ли се едновременно областите с код и с калибровъчни данни?
- Има ли повтарящи се модели на разлики?
- Съдържа ли единият файл допълнителни данни или запълване?
- Съответстват ли промените на историята на файла?
Компактна група от промени в картите може да е в съответствие с нормална корекция при калибриране. Големи, широко разпространени разлики обикновено изискват анализ на версията на софтуера, преди да се правят изводи на ниво карти.
Моделите на разлики са улики, а не доказателства
| Модел на разлика | Възможно обяснение | Необходима проверка |
|---|---|---|
| Малки групи в рамките на известни карти | Документирани промени при калибриране | Потвърдете осите, единиците и очакваната функция |
| Големи непрекъснати области | OEM софтуерна актуализация или различна файлова база | Проверете номерата на софтуера и структурата на кода |
| Повтарящи се изолирани байтове | Контролна сума, броячи, метаданни или обработка от инструмент | Прегледайте протокола и работния процес за контролна сума |
| Подобни карти на различни адреси | Преместване на данни между версии на софтуера | Съпоставяйте по структура, оси и функция, а не по адрес |
| Разлики извън очакваните области за калибриране | Грешен файл, актуализация, пач или недокументирана модификация | Спрете прехвърлянето, докато произходът на файла не бъде изяснен |
Нито един модел не трябва да се приема като гаранция. Използвайте го, за да решите какво се нуждае от по-внимателна проверка.
Сравнявайте карти, а не само адреси
Адресът е валиден само в рамките на собствената си софтуерна структура. Когато файловете използват различни версии на софтуера, една и съща функция може да е съхранена на друг адрес или да е представена по различен начин.
За всяка сравнявана карта потвърдете:
- размерите на картата;
- стойностите на осите;
- реда на осите;
- типа данни;
- реда на байтовете;
- коефициента и отместването;
- инженерната единица;
- заобикалящата структура от данни;
- връзката със свързаните целеви карти и карти с ограничители.
Таблица с еднаква форма не е непременно една и съща функция. Осите и заобикалящата логика също трябва да имат смисъл.
Използвайте референтните версии внимателно
Референтната версия е полезна при преглед на една и съща проектна база или при работа с контролирано сравнение на актуализации. Тя позволява на техника да проверява стойности и разлики, без постоянно да превключва между файлове.
Един изчистен работен процес е:
- Запазете проверената оригинална версия непроменена.
- Създайте или импортирайте файла за сравнение като отделна версия или свързан проект.
- Потвърдете идентификацията на проекта преди свързването на файловете.
- Прегледайте първо общите разлики.
- Отворете познатите карти и сравнете структурата и стойностите.
- Отбележете кои промени са потвърдени, несигурни или отхвърлени.
Не прехвърляйте промени автоматично само защото WinOLS може да идентифицира сходни области.
Кога автоматичният импорт е подходящ
Импортирането на промени е най-надеждно, когато файловете споделят една и съща софтуерна база и връзката оригинал-към-модифициран е документирана.
Автоматичното или полуавтоматичното прехвърляне трябва да се третира внимателно, когато:
- номерата на софтуера се различават;
- единият файл е OEM актуализация;
- единият файл е виртуално четене, а другият е физическо четене;
- адресите на картите са се преместили;
- изходният MOD съдържа недокументирани пачове;
- размерите на файловете или оформлението на паметта се различават;
- изходният проект използва непроверени дефиниции.
В тези ситуации пресъздайте необходимите калибровъчни промени карта по карта и проверете логиката върху целевия софтуер.
Създайте работен лист за прехвърляне на промени
| Карта или функция | Статус на източника | Съвпадение с целта | Действие |
|---|---|---|---|
| Заявка на водача | Потвърдено в източника | Осите и единиците съвпадат | Пресъздай и прегледай |
| Ограничител на въртящия момент | Потвърдено | Намерени са множество варианти на целта | Проучи преди редактиране |
| Целево налягане | Променено в източника | Мащабирането не е потвърдено | Не прехвърляй засега |
| Неизвестна корекция | Недокументирано | Няма верифициран еквивалент в целта | Изключи от прехвърлянето |
Този работен лист предотвратява недокументирани промени в източника да навлизат незабелязано в новия проект.
Не прехвърляй процентни промени сляпо
Един често срещан пряк път е да се изчисли колко се е променила дадена стойност в стария MOD и да се приложи същият процент към подобно изглеждаща карта в новия софтуер. Това може да бъде подвеждащо, тъй като производителят може да е променил базовата стойност, единиците, връзката с ограничителя или стратегията за управление.
Вместо това, задай си въпросите:
- Какъв резултат е целяла да постигне оригиналната редакция?
- Новият софтуер вече съдържа ли преработена цел?
- Кои свързани карти управляват същата функция?
- Еквивалентни ли са осите и работните диапазони?
- Може ли желаният резултат да бъде валидиран с логове?
Прехвърлете калибровъчната цел, а не само старите числа.
Разграничете калибровъчните промени от пачовете и метаданните
Не всяка разлика е редакция на карта. Файловете могат да се различават и поради:
- корекция на контролната сума;
- специфична обработка от инструмента;
- програмни броячи;
- софтуерни пачове;
- метаданни за версията;
- диагностична конфигурация;
- неизвестна предишна работа.
Неизвестните промени извън документираната калибровъчна област трябва да бъдат проучени, преди файлът да бъде одобрен.
Валидирайте целевия проект след прехвърлянето
След като пресъздадете или импортирате промените, извършете пълен преглед на проекта:
- проверете всяка редактирана карта спрямо нейните оси;
- прегледайте свързаните цели и ограничители;
- потвърдете мерните единици и мащабирането;
- проверете интерполацията и граничните клетки;
- уверете се, че не са се променили непредвидени области;
- потвърдете отговорността за контролната сума;
- запазете отчет за разликите спрямо целевия ORI;
- ясно обозначете окончателната версия на файла;
- подгответе правилния файл за възстановяване;
- планирайте контролиран диагностичен тест и тест с регистриране на данни.
Успешният експорт не доказва, че калибровъчната логика е правилна.
Свързани ресурси за WinOLS
За дефиниране на съответствия, валидиране на map-pack и проверки на мащабирането, прочетете WinOLS A2L/DAMOS & Map Packs. Преди да запишете завършения файл, прегледайте WinOLS Checksums.
За обсъждания на софтуерни версии на ECU и реални файлови случаи, прегледайте CarTechnology или MHHAuto. Третирайте форумната информация като изследователски материал и потвърждавайте всяка промяна в рамките на действителния целеви проект.
Контролен списък за сравнение на файлове
- Класифицирайте всеки файл като ORI, MOD, OEM актуализация, виртуален оригинал или неизвестен.
- Запишете хардуерната и софтуерната идентификация на ECU.
- Потвърдете метода на четене и размера на файла.
- Проверете дали файловете споделят една и съща софтуерна база.
- Прегледайте общия модел на разлики преди отварянето на картите.
- Съпоставете картите по структура, оси, единици и функция.
- Не прехвърляйте промени само по адрес.
- Отхвърляйте недокументирани пачове, докато не бъдат разбрани.
- Пресъздавайте промените внимателно, когато целта е различна OEM версия.
- Запазете окончателен отчет за разликите спрямо целевия оригинал.
- Валидирайте обработката на контролните суми и подгответе възстановяване.
ЧЗВ
Мога ли да копирам карти от по-стара OEM софтуерна версия в по-нова?
Не само по адрес. Потвърдете функцията на картата, размерите, осите, мащабирането и стратегията за обкръжение в новия софтуер, след което пресъздайте желаната промяна.
Означава ли съвпадащият размер на файловете, че те са съвместими?
Не. Файлове с еднакъв размер могат да съдържат различен код, структури на калибриране или версии на софтуера.
Кое е най-безопасното сравнение ORI спрямо MOD?
Най-безопасното сравнение използва верифициран оригинал и документирана модифицирана версия, създадена директно от същата оригинална база.
Защо има разлики извън картите, които съм редактирал?
Те може да са промени в контролната сума, метаданни, обработка от инструмента, броячи или недокументирана работа. Идентифицирайте ги, преди да одобрите файла.
Трябва ли да се използва автоматичен импорт при OEM актуализация?
Само с внимателна валидация. Когато софтуерната база се промени, картите може да се преместят или да променят структурата си. Ръчният преглед и контролираното пресъздаване често са по-безопасни.
Сравнението в WinOLS не е просто търсене на различни байтове. То е процес на доказване на идентичността на файла, разбиране на връзката между софтуерите и прехвърляне само на онези калибровъчни решения, които остават валидни в целевата версия.
