İki dosya ilişkili görünebilir ama yine de yanlış karşılaştırma olabilir
Orijinal bir dosyayı değiştirilmiş bir dosyayla karşılaştırmak basit gibi görünüyor: her ikisini aç, farkları bul ve değiştirilen haritaları gözden geçir. Zorluk, dosyaların aynı yazılım tabanını paylaşmadığında başlar.
Bir OEM güncellemesi verileri taşıyabilir, kod bölümlerini değiştirebilir, kalibrasyon yapısını değiştirebilir veya yeni harita varyantları tanıtabilir. Sanal bir okuma, ECU'da daha önce depolanan tam baytlardan ziyade eşleşen bir veritabanı dosyasından gelebilir. Bir müşteri tarafından sağlanan bir dosya, zaten belgelenmemiş değişiklikler içerebilir.
WinOLS farkları gösterebilir, projeleri bağlayabilir ve değişikliklerin aktarımını destekleyebilir, ancak yazılım dosya tanımlamasını ve teknik yargıyı değiştiremez. Herhangi bir şeyi içe aktarmadan önce, tuner her dosyanın ne olduğunu ve karşılaştırmanın geçerli olup olmadığını belirlemelidir.
Karşılaştırmadan önce dosyaları tanımlayın
Projede net terimler kullanın:
- ORI: tam ECU yazılımı için doğrulanmış orijinal veya en iyi mevcut temel.
- MOD: belgelenmiş bir temelden türetilmiş değiştirilmiş bir versiyon.
- OEM güncellemesi: daha sonraki veya farklı bir üretici yazılımı versiyonu.
- Sanal orijinal: araç sağlayıcısı tarafından ECU tanımlamasından eşleşen bir orijinal dosya.
- Okuma geri: yazma işleminden sonra kontrol biriminden fiziksel olarak okunan veriler, destekleniyorsa.
- Bilinmeyen dosya: güvenle sınıflandırmak için yeterli kanıtı olmayan herhangi bir dosya.
Bir dosyayı adı “orijinal” kelimesini içerdiği için ORI olarak etiketlemeyin. Dosya adları notlardır, kanıt değil.
Bir dosya kimlik belgesi oluşturun
Karşılaştırma görünümünü açmadan önce, her dosya için mevcut tanımlamaları kaydedin.
| Kimlik alanı | Dosya A | Dosya B |
|---|---|---|
| ECU ailesi | Tam türü kaydedin | Tam türü kaydedin |
| Donanım numarası | Araçtan veya etiketlerden alınan değer | Araçtan veya kaynaktan alınan değer |
| Yazılım numarası | Tam değer | Tam değer |
| Kalibrasyon veya güncelleme numarası | Mevcut olduğunda | Mevcut olduğunda |
| Okuma yöntemi | OBD, Bench, Boot veya sanal | OBD, Bench, Boot veya sanal |
| Dosya boyutu | Bayt cinsinden kaydedildi | Bayt cinsinden kaydedildi |
| Kaynak | Araç, araç veritabanı veya müşteri | Araç, araç veritabanı veya müşteri |
| Bilinen geçmiş | Stok, modifiye, güncellenmiş veya bilinmeyen | Stok, modifiye, güncellenmiş veya bilinmeyen |
Eşleşen dosya boyutu faydalıdır, ancak iki dosyanın aynı yazılım yapısını paylaştığını kanıtlamaz.
Üç farklı karşılaştırma işi
Çoğu WinOLS karşılaştırma çalışması üç durumdan birine girer. Her biri farklı bir dikkat seviyesi gerektirir.
1. ORI ile MOD aynı temelden
Bu en temiz karşılaştırmadır. MOD, doğrudan ORI'den oluşturulmuştur ve her iki dosya da aynı yapıya sahiptir. Farklar belgelenmiş kalibrasyon düzenlemeleri ve beklenen kontrol toplamı ile ilgili değişikliklere karşılık gelmelidir.
2. Bir OEM yazılım versiyonu diğerine karşı
Bu normal bir ayar karşılaştırması değildir. Büyük alanlar farklı olabilir çünkü üretici kodu, arıza teşhisi, kalibrasyon yapısını veya veri hizalamasını değiştirmiştir. Farklar, ayar değişiklikleri olarak yorumlanmamalıdır.
3. Değiştirilmiş eski bir versiyon ile daha yeni bir OEM versiyonu
Bu en yüksek riskli aktarım senaryosudur. Eski adresler artık aynı haritalara işaret etmiyor olabilir. Değişiklikler, yeni yazılım yapısına karşı yeniden oluşturulmalı ve doğrulanmalıdır, kör bir şekilde kopyalanmamalıdır.
Yüksek seviyeli bir fark incelemesi ile başlayın
Bireysel haritaları açmadan önce, farkların genel desenine bakın.
Sorun:
- Değişiklikler küçük bir kalibrasyon alanında mı yoğunlaşmış?
- Farklar dosyanın çoğuna yayılmış mı?
- Büyük bloklar kaydırılmış mı?
- Kod ve kalibrasyon alanları her ikisi de farklı mı?
- Tekrar eden fark desenleri var mı?
- Bir dosya ek veri veya dolgu içeriyor mu?
- Değişiklikler dosya geçmişi ile tutarlı mı?
Küçük bir harita değişiklikleri grubu, normal bir kalibrasyon düzenlemesi ile tutarlı olabilir. Büyük yaygın farklar genellikle harita düzeyinde sonuçlar çıkmadan önce yazılım versiyonu analizi gerektirir.
Fark desenleri ipuçlarıdır, kanıt değil
| Fark deseni | Olası açıklama | Gerekli kontrol |
|---|---|---|
| Bilinen haritalar içinde küçük kümeler | Belgelenmiş kalibrasyon değişiklikleri | Eksenleri, birimleri ve beklenen işlevi doğrulayın |
| Büyük sürekli bölgeler | OEM yazılım güncellemesi veya farklı dosya tabanı | Yazılım numaralarını ve kod yapısını doğrulayın |
| Tekrar eden izole baytlar | Kontrol toplamı, sayaçlar, meta veriler veya araç işleme | Protokolü ve kontrol toplamı iş akışını gözden geçirin |
| Farklı adreslerde benzer haritalar | Yazılım versiyonları arasında veri taşınması | Yapı, eksenler ve işlev ile eşleştirin, adresle değil |
| Beklenen kalibrasyon alanlarının dışındaki farklar | Yanlış dosya, güncelleme, yaman veya belgelenmemiş değişiklik | Dosya kaynağı anlaşılana kadar aktarımı durdurun |
Hiçbir desen garanti olarak değerlendirilmemelidir. Daha yakın inceleme gerektirenleri belirlemek için kullanın.
Haritaları karşılaştırın, yalnızca adresleri değil
Bir adres yalnızca kendi yazılım yapısı içinde geçerlidir. Dosyalar farklı yazılım versiyonları kullanıyorsa, aynı işlev başka bir adreste depolanabilir veya farklı bir şekilde temsil edilebilir.
Karşılaştırılan her harita için, onaylayın:
- harita boyutları;
- ekseni değerleri;
- ekseni sırası;
- veri türü;
- bayt sırası;
- faktör ve offset;
- mühendislik birimi;
- çevresel veri yapısı;
- ilişkili hedef ve sınırlayıcı haritalarla ilişkisi.
Aynı şekle sahip bir tablo, aynı işlevin garantisi değildir. Eksenler ve çevresel mantık da mantıklı olmalıdır.
Referans versiyonları dikkatli kullanın
Bir referans versiyonu, aynı proje tabanını gözden geçirirken veya kontrollü bir güncelleme karşılaştırması yaparken faydalıdır. Teknisyene değerleri ve farkları sürekli dosya değiştirmeden inceleme imkanı tanır.
Temiz bir iş akışı şudur:
- Doğrulanmış orijinal versiyonu dokunulmamış bırakın.
- Karşılaştırma dosyasını ayrı bir versiyon veya bağlı proje olarak oluşturun veya içe aktarın.
- Dosyaları bağlamadan önce proje tanımlamasını onaylayın.
- Önce geniş farkları gözden geçirin.
- Bilinen haritaları açın ve yapı ile değerleri karşılaştırın.
- Hangi değişikliklerin onaylandığını, belirsiz olduğunu veya reddedildiğini kaydedin.
WinOLS benzer bölgeleri tanımlayabildiği için değişiklikleri otomatik olarak aktarmayın.
Otomatik içe aktarmanın uygun olduğu durumlar
Değişiklikleri içe aktarmak, dosyalar aynı yazılım tabanını paylaştığında ve orijinal ile değiştirilmiş ilişkisinin belgelenmiş olduğunda en güvenilirdir.
Otomatik veya yarı otomatik aktarım, aşağıdaki durumlarda dikkatli bir şekilde ele alınmalıdır:
- yazılım numaraları farklıysa;
- bir dosya bir OEM güncellemesi ise;
- bir dosya sanal okuma ve diğeri fiziksel okuma ise;
- harita adresleri değiştiyse;
- kaynak MOD belgelenmemiş yamalar içeriyorsa;
- dosya boyutları veya bellek düzenleri farklıysa;
- kaynak proje doğrulanmamış tanımlamalar kullanıyorsa.
Bu durumlarda, gerekli kalibrasyon değişikliklerini harita harita yeniden oluşturun ve hedef yazılım üzerindeki mantığı doğrulayın.
Bir değişiklik aktarım çalışma sayfası oluşturun
| Harita veya işlev | Kaynak durumu | Hedef eşleşmesi | Eylem |
|---|---|---|---|
| Sürücü isteği | Kaynakta onaylandı | Eksenler ve birimler eşleşti | Yeniden oluştur ve gözden geçir |
| Tork sınırlayıcı | Onaylandı | Birden fazla hedef varyant bulundu | Düzenlemeden önce araştırın |
| Basınç hedefi | Kaynakta değiştirildi | Ölçekleme onaylanmadı | Henüz aktarmayın |
| Bilinmeyen yama | Belgelenmemiş | Doğrulanmış hedef eşdeğeri yok | Aktarımdan reddedin |
Bu çalışma sayfası, belgelenmemiş kaynak değişikliklerinin yeni projeye sessizce girmesini önler.
Yüzde değişikliklerini kör bir şekilde aktarmayın
Yaygın bir kısayol, eski MOD'daki bir değerin ne kadar değiştiğini hesaplamak ve aynı yüzdeyi yeni yazılımda benzer görünen bir haritaya uygulamaktır. Bu yanıltıcı olabilir çünkü üretici temel değeri, birimleri, sınırlayıcı ilişkisini veya kontrol stratejisini değiştirmiş olabilir.
Bunun yerine, sorun:
- Orijinal düzenlemenin hangi sonucu elde etmeyi amaçladığı?
- Yeni yazılım zaten revize edilmiş bir hedef içeriyor mu?
- Hangi ilgili haritalar aynı işlevi kontrol ediyor?
- Eksenler ve işletim bölgeleri eşdeğer mi?
- Amaçlanan sonuç günlüklerle doğrulanabilir mi?
Kalibrasyon amacını aktarın, yalnızca eski sayıları değil.
Kalibrasyon değişikliklerini yamalardan ve meta verilerden ayırın
Her fark bir harita düzenlemesi değildir. Dosyalar ayrıca şunlar nedeniyle de farklılık gösterebilir:
- kontrol toplamı düzeltmesi;
- araçlara özgü işleme;
- programlama sayaçları;
- yazılım yamaları;
- versiyon meta verileri;
- arıza teşhisi yapılandırması;
- bilinmeyen önceki çalışmalar.
Belgelenmemiş değişiklikler, belgelenmiş kalibrasyon alanının dışındaki değişiklikler, dosya onaylanmadan önce incelenmelidir.
Aktarımdan sonra hedef projeyi doğrulayın
Değişiklikleri yeniden oluşturduktan veya içe aktardıktan sonra, tam bir proje incelemesi gerçekleştirin:
- her düzenlenmiş haritayı eksenleriyle kontrol edin;
- ilişkili hedefleri ve sınırlayıcıları gözden geçirin;
- birimleri ve ölçeklemeyi onaylayın;
- interpolasyon ve sınır hücrelerini inceleyin;
- istenmeyen bölgelerin değişmediğinden emin olun;
- kontrol toplamı sorumluluğunu onaylayın;
- hedef ORI'ye karşı bir fark raporu kaydedin;
- son dosya versiyonunu net bir şekilde etiketleyin;
- doğru kurtarma dosyasını hazırlayın;
- kontrollü bir arıza teşhisi ve veri kaydetme testi planlayın.
Başarılı bir dışa aktarma, kalibrasyon mantığının doğru olduğunu kanıtlamaz.
İlgili WinOLS kaynakları
Tanım eşleştirme, harita paketi doğrulama ve ölçekleme kontrolleri için WinOLS A2L/DAMOS & Harita Paketleri okuyun. Tamamlanmış dosyayı yazmadan önce WinOLS Kontrol Toplamları gözden geçirin.
ECU yazılım versiyonu tartışmaları ve gerçek dosya vakaları için CarTechnology veya MHHAuto gözden geçirin. Forum bilgilerini araştırma olarak değerlendirin ve her değişikliği gerçek hedef projede doğrulayın.
Dosya karşılaştırma kontrol listesi
- Her dosyayı ORI, MOD, OEM güncellemesi, sanal orijinal veya bilinmeyen olarak sınıflandırın.
- ECU donanım ve yazılım tanımlamasını kaydedin.
- Okuma yöntemini ve dosya boyutunu onaylayın.
- Dosyaların aynı yazılım tabanını paylaşmasını kontrol edin.
- Haritaları açmadan önce genel fark desenini gözden geçirin.
- Haritaları yapı, eksenler, birimler ve işlev ile eşleştirin.
- Değişiklikleri yalnızca adresle aktarmayın.
- Belgelenmemiş yamaları anlamadan reddedin.
- Hedef farklı bir OEM versiyonu olduğunda değişiklikleri dikkatlice yeniden oluşturun.
- Hedef orijinaline karşı son bir fark raporu kaydedin.
- Kontrol toplamı işlemlerini doğrulayın ve kurtarma hazırlayın.
SSS
Eski bir OEM yazılım versiyonundan haritaları daha yenisine kopyalayabilir miyim?
Sadece adresle güvenli bir şekilde değil. Yeni yazılımda harita işlevini, boyutlarını, eksenlerini, ölçeklemeyi ve çevresel stratejiyi doğrulayın, ardından amaçlanan değişikliği yeniden oluşturun.
Eşleşen dosya boyutu dosyaların uyumlu olduğu anlamına mı geliyor?
Hayır. Aynı boyutta dosyalar farklı kod, kalibrasyon düzenleri veya yazılım versiyonları içerebilir.
En güvenli ORI ile MOD karşılaştırması nedir?
En güvenli karşılaştırma, doğrulanmış bir orijinal ve aynı orijinal temelden doğrudan oluşturulmuş belgelenmiş bir değiştirilmiş versiyon kullanır.
Düzenlediğim haritaların dışında neden farklar var?
Bunlar kontrol toplamı değişiklikleri, meta veriler, araç işleme, sayaçlar veya belgelenmemiş çalışmalar olabilir. Dosyayı onaylamadan önce bunları tanımlayın.
Otomatik içe aktarma bir OEM güncellemesi için kullanılmalı mı?
Sadece dikkatli bir doğrulama ile. Yazılım tabanı değiştiğinde, haritalar taşınabilir veya yapı değiştirebilir. Manuel inceleme ve kontrollü yeniden oluşturma genellikle daha güvenlidir.
WinOLS karşılaştırması sadece farklı baytları aramak değildir. Dosya kimliğini kanıtlamak, yazılım ilişkisini anlamak ve yalnızca hedef versiyonda geçerli kalan kalibrasyon kararlarını aktarmak sürecidir.
