EDC15 & WinOLS: Hata Kodları ve Dosya Kurtarma

EDC15 EBU dosyalarındaki hata kodlama sistemi, hata kodlarının ve bunlara bağlı parametrelerin belirli bir düzen içinde saklandığı karmaşık bir yapıya sahiptir. Bu mimari, genellikle 8 bitlik mesajlar ve bunları takip eden 16 bitlik hata kodlarından oluşur; ayrıca her hata koduna eşlik eden motor devri, hava kütlesi ve enjeksiyon miktarı gibi çevresel koşulları belirten beş ana veri noktası bulunur. Hataların kalıcı olarak kaydedilmesi, "çıngırak giderme" (debouncing) sayaçları tarafından yönetilir; bu sayaçlar sayesinde bir hatanın anlık mı yoksa kalıcı mı olduğu belirlenir ve sayaç değerleri çok yüksek tutulursa (örneğin 65.535) ilgili hatanın kaydedilmesi engellenebilir.

Buna ek olarak, ECU belleğindeki her hatanın 0 ile 7 arasında değişen bir öncelik değeri vardır. Bu öncelik değerleri, hatanın ne kadar kritik olduğunu ve gösterge panelindeki arıza lambasının (MIL) yanıp yanmayacağını belirler; örneğin, 0 veya 1 değerine sahip hatalar genellikle lambayı yakmazken, 2 veya 3 değerine sahip hatalar arıza lambasının yanmasına neden olur. Dosya boyutları, içerilen hata kodlarının ve sayaç bloklarının sayısına göre değişkenlik gösterdiği için her bloğun başlangıç ve bitiş noktasını doğru tespit etmek teknik analiz açısından kritiktir.

Anlamak için bir benzetme: ECU'daki hata kodlama yapısını bir binanın güvenlik sistemine benzetebiliriz. Hata kodları tetiklenen alarmlardır, çevresel koşullar ise alarm anında güvenlik kamerasının kaydettiği görüntülerdir (o an içeride kim vardı, sıcaklık neydi?). Çıngırak giderme sayaçları, bir alarmın "yanlış alarm" olup olmadığını anlamak için beklenen süredir; eğer süre çok uzunsa alarm hiç çalmaz. Öncelik ayarları ise binanın hangi bölgesinde sorun olduğuna göre sirenlerin çalma şiddetini belirler: Depoda küçük bir sorun varsa (öncelik 0) sadece rapor edilir, ancak ana girişte sorun varsa (öncelik 3) tüm bina ışıkları yanar.

Bu kaynaklar, EDC15PD EBU dosyalarındaki hata kodlarının (DTC) nasıl yapılandırıldığını ve VW Passat PD130 örneği üzerinden nasıl analiz edildiğini açıklamaktadır. Dosyalarda hata kodları, tasarım gereği birbirine zıt durumları (örneğin EGR alt ve üst limit aşımı) temsil edecek şekilde eşleştirilebilir ve genellikle sekizli gruplardan oluşan "hata yolları" içinde düzenlenir,. Eğer bir sistem için sekizden fazla hata kodu gerekliyse, tasarımcılar yeni bir hata yolu başlatmak zorundadır. EDC15PD dosyalarında bu kodlar eski versiyonlar gibi doğrusal bir dizide olmayabilir, ancak her zaman sekiz yuva bulunur ve bu yuvalar motor devri, enjeksiyon miktarı ve hava akışı gibi kritik çevresel koşul verilerini içerir. Ayrıca, hata teşhis sürecinde hataların başlangıç, bitiş ve iyileşme sürelerini belirleyen sayaçlar ile hata önceliklerinin nasıl çalıştığına dair teknik detaylar sunulmaktadır,.

Anlamak için bir benzetme: Bir hata kodunu bir kütüphane kartına benzetebiliriz; kartın üzerindeki kod (DTC) kitabın adıdır, ancak kartın yanında kitabın hangi rafta olduğu, ne zaman ödünç alındığı ve kütüphanenin o anki yoğunluğu (çevresel koşullar) gibi ek bilgiler de yer alır. Eğer bir raf (hata yolu) dolarsa, yeni kitaplar için mutlaka yeni bir raf açılması gerekir.

Bu kaynaklar, EDC15PD EBU dosyalarındaki hata kodlarının (DTC) yapısını ve özellikle EGR sistemiyle ilgili hataların nasıl yönetildiğini teknik bir perspektifle açıklamaktadır. Dosya mimarisinde hata kodları genellikle zıt durumları temsil eden çiftler halinde bulunur ve bir "hata yolu" (error path) için tanımlanabilecek maksimum kod sayısı sekizdir,. Her hata koduna, hatanın oluştuğu andaki enjeksiyon miktarı, gerçek hava kütlesi ve EGR çıkış yüzdesi gibi çevresel koşul bilgileri eşlik eder.

Bir hatanın sistemde görüntülenmesini veya arıza lambasını (MIL) yakmasını engellemek için, hata sayaçlarına ulaşılamayacak kadar büyük değerler (örneğin 65535) atanabilir veya hata öncelik sayaçları değiştirilerek sistemin tepkisi kontrol edilebilir,,. Ayrıca, dosya içindeki olay sayaçlarını ve kodlama bloklarını doğru analiz edebilmek için 8-bit ve 16-bit ondalık görünümler arasında geçiş yapılması ve sayaçların (hata ve kurtarma sayaçları) işlevlerinin doğru tanımlanması kritik önem taşır,.

Anlamak için bir benzetme: ECU'daki hata yönetim sistemini bir barajdaki otomatik tahliye kapaklarına benzetebiliriz. Hata kodları sensörlerin uyarı vermesidir, çevresel koşullar ise o anki su seviyesi ve basınç gibi verilerdir. Eğer bir sensörün hata vermesini istemiyorsanız, barajın alarm limitini (sayaç değerini) o kadar yükseğe kurarsınız ki su seviyesi (hatalar) hiçbir zaman o noktaya ulaşamaz, böylece ana kumanda merkezinde (gösterge panelinde) hiçbir uyarı ışığı yanmaz.

Bu kaynaklar, WinOLS demo sürümünde dışa aktarma (export) özelliği bulunmadığı için bir hex editörü (HXD gibi) kullanarak proje dosyalarından nasıl kullanılabilir bir dosya çıkarılacağını açıklamaktadır. Bir WinOLS dosyası hem yazılımın kendi yapılandırma bilgilerini (metadata) hem de asıl ECU veri bloğunu içerir; ancak ECU'ya yükleme yapabilmek için yalnızca dosyanın alt kısmında bulunan orijinal veri bloğuna ihtiyaç duyulur,. Kullanılabilir kısmı ayıklamak için orijinal dosya boyutunun (örneğin 2048 KB) hex karşılığının bilinmesi ve Windows hesap makinesi yardımıyla dosyanın son adresinden bu boyutun çıkarılarak doğru başlangıç noktasının hesaplanması gerekir,. Bu yöntemle, WinOLS'in eklediği gereksiz bilgilerden arındırılmış, doğrudan araca yüklenebilecek .bin veya .hex formatındaki saf veri elde edilebilir.

Anlamak için bir benzetme: WinOLS proje dosyasını içinde değerli bir hediye (ECU dosyası) bulunan süslü bir kutuya benzetebiliriz. Demo sürümü size kutuyu açma anahtarını vermez. Hex editörü kullanmak ise bu kutunun sadece altını keserek içindeki hediyeyi kutuya zarar vermeden doğrudan dışarı çıkarmak gibidir. Adres hesaplamaları ise hediye paketinin nerede bitip gerçek hediyenin nerede başladığını gösteren bir cetvel görevi görür.

WinOLS demo kullanıcıları için hazırlanan bu rehber, bir Hex editörü kullanarak proje dosyalarından nasıl saf binary veya hex dosyası elde edileceğini açıklar. WinOLS dosyaları; veri, orijinal dosya ve modifiye edilmiş versiyonlar gibi farklı bölümlerden oluşur; kural olarak dosyanın son bölümü çıkarılmak istenen güncel dosyadır. Doğru dosyayı elde etmek için, istenen bölümün (örneğin 1 MB veya 2 MB) başlangıç noktasını belirlemek, net kesme noktalarını (FF veya CD dizileri gibi) bulmak ve gereksiz kısımları silerek dosyayı tam boyutuna getirmek gerekir,. İşlem tamamlandıktan sonra dosyanın doğruluğu, WinOLS programında tekrar açılarak test edilebilir; eğer program dosyayı orijinaliyle %100 aynı olarak tanıyorsa işlem başarılıdır. Bu yöntemde sağlama toplamlarının (checksum) tamamlanmamış olabileceği unutulmamalıdır; bu nedenle kullanılan yazma cihazının bu düzeltmeyi yapabilmesi kritiktir.