BMS-16 — BMS Software Architecture

1. Donanım Değişince Kodun Tamamı mı Yeniden Yazılsın?

Bir BMS yazılımı ölçüm sürücülerinden SOC/SOH/SOP algoritmalarına, state machine’den CAN haberleşmesine kadar onlarca işlevi barındırıyor. Bunların hepsini tek bir monolitik blokta yazarsan, donanım değiştiğinde (farklı bir MCU ya da ADC gibi) neredeyse kodun tamamını yeniden yazmak zorunda kalırsın — test etmek de bir o kadar zorlaşır. Çözüm, katmanlı bir mimari:

Application → Services → Hardware Abstraction (HAL) → Drivers

2. Dört Katman, Tek Kural

Katman	İçeriği
Application	BMS iş mantığı: state machine, SOC/SOH/SOP, balancing, fault manager
Services	Haberleşme, diagnostik, NVM (kalıcı bellek) gibi ortak servisler
HAL	Donanıma soyut, tek tip erişim arayüzü
Drivers	ADC, CAN, GPIO gibi çevre birimlerinin düşük seviyeli sürücüleri

Kural basit: her katman yalnızca bir alt katmanı kullanır, üst katmanları bilmez. SOC algoritması “ADC kanal 5’i oku” demiyor, “hücre 5’in gerilimini al” diyor (HAL üzerinden). MCU değişse veya ADC farklı bir çipe geçse bile yalnızca Driver ve HAL güncelleniyor — SOC algoritması hiç değişmiyor.

Bu katmanlardaki bileşenler (state machine, communication, diagnostics, fault manager, SOC/SOH/SOP, balancing, thermal manager) görev ayrımına göre periyodik (SOC her N ms) veya olay tabanlı (arıza) çalışıyor.

3. RTOS mu, Bare Metal mi?

Kriter	Bare Metal	RTOS
Karmaşıklık	Düşük	Daha yüksek
Determinizm	Yüksek (tek döngü)	Görev önceliğine bağlı
Zamanlama esnekliği	Sınırlı	Yüksek (çoklu görev)
Kaynak kullanımı	Düşük	Orta-yüksek

Basit, tek görevli bir BMS’te bare metal (süper loop + interrupt) yetebiliyor. Çok sayıda paralel görev ve zaman kritik işlem varsa RTOS daha uygun. SOC algoritması her 100 ms’de, CAN haberleşmesi her 10 ms’de, arıza tespiti sürekli çalışmalı — RTOS bu görevleri önceliğe göre zamanlıyor (arıza tespiti en yüksek öncelikte), bare metal’de bu sıralama geliştiricinin süper loop içinde elle kurduğu sabit bir düzene dayanıyor.

ASSUMPTION — Bare metal ile RTOS arasındaki seçim ekibin deneyimine, MCU kaynaklarına ve projeye özgü zamanlama gereksinimlerine bağlı; burada tek bir “doğru” yaklaşım önerilmiyor.

4. Neden Bu Kadar Katı Bir Yapı?

Katmanlı mimari ISO 26262 ve Automotive SPICE süreçleriyle uyumlu, doğrulanabilir ve bakımı kolay yazılım geliştirmeyi destekliyor. Bileşenlerin ayrılması birim testini ve izlenebilirliği kolaylaştırıyor.

5. Bu Yapı Nerede Kırılabilir

Application’ın doğrudan Driver’a erişmesi (katman atlaması, taşınabilirliği bozar), priority inversion (düşük öncelikli bir görevin kritik bir görevi geciktirmesi) ve paylaşılan kaynaklara eşzamanlı erişimde veri tutarsızlığı (race condition) — yazılım mimarisinin başlıca risk noktaları bunlar.

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

Katmanlı yapı, birim testlerinin her katmanı bağımsız olarak (mock/stub donanım arayüzleriyle) test edilmesini mümkün kılıyor. Zamanlama analizleri (worst-case execution time), RTOS görevlerinin zaman bütçesini aştığı durumları üretim öncesinde yakalamak için kullanılıyor.

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

Yazılım mimarisi; state machine (BMS-14), arıza yönetimi (BMS-13) ve haberleşme (BMS-15) gibi tüm işlevsel bileşenlerin üzerine inşa edildiği iskelet. Doğrulama stratejisi (BMS-19) ve seri üretim süreci (BMS-20) da bu katmanlara göre yapılanıyor.

Özet

• Katmanlı mimari donanımı yalıtır; taşınabilirlik ve test edilebilirlik sağlar.
• RTOS ve bare metal farklı gereksinimlere hitap eder — seçim görev sayısı ve zamanlama kritikliğine bağlı.
• Katman sınırı ihlalleri ve zamanlama hataları başlıca risk noktaları.

Kaynaklar

• Automotive SPICE — yazılım süreç referansı.
• ISO 26262 Part 6 — yazılım geliştirme.