BMS-13 — Fault Management

1. Gürültü mü, Arıza mı?

Bir BMS her an binlerce ölçüm örneği işliyor. Bunların bir kısmı gerçek bir arızayı, bir kısmı geçici gürültüyü, bir kısmı da sensörün kendi bozukluğunu yansıtıyor. Arıza yönetiminin işi tam olarak bu üçünü birbirinden ayırıp her birine orantılı bir tepki vermek:

Sensor → Plausibility Check → Fault Detection → Debounce → Fault Confirmation
→ Fault Classification → Mitigation → Derating/Shutdown → Diagnostic Storage → Recovery

Bu akış, geçici bir sinyalin yanlışlıkla arızaya dönüşmesini engelliyor.

2. Plausibility ve Debounce

Plausibility, bir sinyalin fiziksel olarak mümkün olup olmadığının kontrolü — mesela -40 °C gösteren bir sıcaklık sensörü muhtemelen açık devredir. Bu kontrol üç şekilde yapılıyor: mutlak aralık kontrolü (hücre gerilimi 0-5 V dışındaysa geçersiz), değişim hızı kontrolü (bir örnekten diğerine 500 mV’lik sıçrama fiziksel olarak imkansız) ve çapraz doğrulama (komşu hücrelerle veya akım-gerilim tutarlılığıyla karşılaştırma).

Debounce ise bir sinyalin gerçek arıza mı yoksa anlık gürültü mü olduğunu ayırt etmek için belirli bir süre teyit edilmesi. Bir hücre gerilimi eşiği aştığında BMS bunu hemen arıza saymıyor — mesela 100 ms boyunca (birkaç ölçüm döngüsü) eşik aşımının sürüp sürmediğine bakıyor. 3. döngüde değer normale dönerse bu muhtemelen ölçüm gürültüsüydü, arıza onaylanmıyor.

3. Sınıflandırma ve Tepki

Debounce’tan geçen arıza onaylanıp önemine göre sınıflandırılıyor. Tipik seviyeler: Information, Warning, Derating, Critical, Shutdown (üreticiye ve safety concept’e göre değişebilir). Küçük bir sensör sapması “Warning” olabilirken, hücre overvoltage’ı “Shutdown” (kontaktör açma) gerektirebilir.

Tepki de buna orantılı: Derating gücü kademeli düşürüyor, Shutdown HV kontaktörlerini açıp enerjiyi ayırıyor. Arıza, DTC (Diagnostic Trouble Code) olarak kaydedilip servis için saklanıyor. Recovery, arıza koşulu ortadan kalktığında güvenli biçimde normale dönüş — bazıları otomatik, bazıları servis müdahalesi istiyor.

4. Vaka Çalışmaları

Aşağıdaki altı senaryo, sahada karşılaşılabilecek tipik BMS arızalarını Symptom → Possible Causes → Detection → Diagnosis → Mitigation → Recovery çerçevesiyle inceliyor.

ASSUMPTION — Bu vaka çalışmaları eğitim amaçlı kavramsal örneklerdir; gerçek bir aracın resmi teşhis/servis prosedürü değildir ve OEM’e özgü somut eşik/prosedür bilgisi içermez.

Vaka 1 — Bir Hücre Diğerlerinden 80 mV Yüksek

• Symptom: Bir hücrenin gerilimi, seri dizideki diğerlerinin ortalamasından ~80 mV yüksek.
• Olası nedenler: Gerçek SOC dengesizliği (üretim toleransı/farklı yaşlanma), ölçüm kanalında kazanç/offset hatası, sense wire’da ek direnç.
• Tespit: Hücreler arası fark, dengeleme eşiğinin (BMS-11) üzerine çıktığında işaretlenir.
• Tanı: Fark dinlenme anında (akımsız, OCV geçerliyken) da sürüyorsa gerçek bir SOC farkı olması muhtemel; yalnızca yük altında görünüp dinlenmede kayboluyorsa ölçüm hatası şüphesi artar.
• Müdahale: Gerçek fark ise dengeleme devreye girer; ölçüm hatası şüphesi varsa kanal “düşük güven” işaretlenip komşu verilerle çapraz kontrol edilir.
• Kurtarma: Dengelemeyle fark eşik altına inince normale dönülür; ölçüm hatasıysa servis/kalibrasyon gerekebilir.

Vaka 2 — Pre-charge Beklenen Sürede Bitmiyor

• Symptom: PRECHARGE durumunda DC-link gerilimi beklenen ~5τ süresinde hedefe ulaşmıyor.
• Olası nedenler: Pre-charge direnci açık devre/değeri artmış, kontaktör tam kapanmamış, DC-link’te beklenmeyen bir kaçak, ya da kapasitans beklenenden büyük.
• Tespit: BMS pre-charge süresini ve DC-link gerilimini izler; bir zaman aşımı eşiği tanımlıdır.
• Tanı: Gerilim hiç yükselmiyorsa kontaktör/direnç şüphesi öne çıkar; yavaş yükseliyorsa direnç artışı veya beklenmeyen yük şüphesi öne çıkar.
• Müdahale: BMS pre-charge’ı zaman aşımıyla iptal eder, kontaktörleri açık tutar, HV aktivasyonuna izin vermez.
• Kurtarma: Yalnızca kök neden giderildikten sonra yeniden denenir; otomatik kurtarma önerilmez.

Vaka 3 — Sıcaklık Sensörü -40 °C Gösteriyor

• Symptom: Bir kanal, komşu sensörlerle ve ortamla tutarsız şekilde -40 °C gösteriyor.
• Olası neden: NTC sense hattında açık devre — gerilim bölücü çıkışı açık devrede aralığın ucuna kilitlenir.
• Tespit: Plausibility kontrolü, komşu sensörlerden fiziksel olarak makul olmayan bir sapma yakalar.
• Tanı: Sensör/kanal arızası (hücre arızası değil).
• Müdahale: Kanal geçersiz işaretlenir; komşu sensör verisi veya son geçerli değer geçici kullanılır, derating kararları daha muhafazakâr alınır.
• Kurtarma: Servis onarımı ve EOL benzeri doğrulama sonrası kanal yeniden aktive edilir.

Vaka 4 — Akım Sensörü +20 A Offset Gösteriyor

• Symptom: Araç dururken (gerçek akım ≈ 0) sensör sürekli +20 A okuyor.
• Olası nedenler: Kalibrasyon kayması, sıcaklık kaynaklı kayma, sensör donanım arızası.
• Tespit: BMS, araç uyku/dinlenme durumunda (bilinen sıfır akım) okumayı sıfırla karşılaştırır.
• Tanı: Sabit ve zamanla değişmeyen offset kalibrasyon kaymasını, sıcaklıkla değişen offset termal kaymayı işaret eder.
• Müdahale: Coulomb counting’e etkisi periyodik OCV düzeltmesiyle sınırlanır; offset büyükse SOC güveni düşürülüp daha muhafazakâr SOP uygulanır.
• Kurtarma: Kalibrasyon güncellemesi veya sensör değişimi.

Vaka 5 — Bir Hücrenin Gerilimi Aniden Düşüyor

• Symptom: Bir hücre gerilimi kısa sürede diğerlerinden belirgin hızlı düşüyor.
• Olası nedenler: Artan iç direnç/kısmi arıza, olası iç kısa devre eğilimi (ciddi güvenlik riski), ölçüm kanalı arızası.
• Tespit: BMS gerilim değişim hızını (dV/dt) ve komşu hücrelerle tutarlılığını izler; anormal hızlı düşüş “kritik” sınıflandırılabilir.
• Tanı: Sıcaklık artışı eşlik ediyorsa iç kısa devre şüphesi güçlenir; sıcaklık sabitse ölçüm kanalı arızası da olası.
• Müdahale: Güvenlik öncelikli — BMS şüpheli hücreyi güvenli tarafta değerlendirip yükü sınırlar veya HV’yi ayırır.
• Kurtarma: Genelde otomatik kurtarmaya uygun değil; servis/inceleme gerekir.

Vaka 6 — CAN Haberleşmesi Kopuyor

• Symptom: BMS’in VCU veya bir CMU ile CAN haberleşmesi beklenen sürede yanıt vermiyor.
• Olası nedenler: Kablo/konektör arızası, transceiver arızası, EMI, karşı düğümün kendi arızası.
• Tespit: Beklenen periyodik mesajların zaman aşımı penceresinde gelip gelmediği izlenir (message timeout).
• Tanı: Yalnızca bir CMU’dan veri kesiliyorsa daisy-chain kopması şüphesi öne çıkar; VCU ile tüm haberleşme kesiliyorsa CAN hattı/transceiver şüphesi öne çıkar.
• Müdahale: Kaybolan veriye bağlı fonksiyonlar güvenli tarafta varsayılır; VCU haberleşmesi tamamen kesiliyorsa araç genelde güvenli bir moda (limp-home) geçer.
• Kurtarma: Haberleşme ve veri tutarlılığı yeniden kurulunca normale dönülür; tekrarlayan kopmalar servis incelemesi gerektirir.

5. Üretimde Nasıl Doğrulanır

HIL testinde yukarıdaki gibi senaryolar sistematik olarak enjekte edilir; her arıza için doğru tespit süresi, doğru sınıflandırma ve doğru tepki kontrol edilir (BMS-19).

6. Diğer Sistemlerle Bağlantısı

Arıza yönetimi tüm ölçüm zincirlerinden (BMS-03, BMS-04, BMS-05) veri alıyor, state machine’i (BMS-14) FAULT durumuna geçirebiliyor, fonksiyonel güvenlik konseptinin (BMS-17) çalışma zamanı gerçekleştirmesi ve diagnostik kayıtları CAN/UDS (BMS-15) üzerinden servis araçlarına sunuyor.

Özet

• Plausibility ve debounce yanlış arızaları önler; sınıflandırma orantılı tepkiyi belirler.
• Derating/shutdown güvenliği sağlar, DTC kaydı servisi destekler.
• Vaka çalışmaları, semptom-tanı-tepki zincirinin sahada nasıl işlediğini gösterir.

Kaynaklar

• ISO 26262 — arıza tespiti ve reaksiyon.
• Gregory L. Plett, Battery Management Systems, Volume II — diagnostik.