BMS-18 — Cybersecurity

1. Fonksiyonel Güvenlik Neden Yetmez

BMS-17’deki fonksiyonel güvenlik, rastgele donanım arızalarına ve sistematik yazılım hatalarına karşı koruyor. Ama kötü niyetli, kasıtlı bir müdahale — mesela CAN üzerinden sahte bir “şarj izni” mesajı göndermek — bir arıza değil, sistemin tasarlandığı gibi çalışmasını kötüye kullanmak. Bu tamamen farklı bir tehdit modeli ve farklı bir disiplin gerektiriyor: siber güvenlik.

BMS araç ağına bağlı ve HV enerjiyi yönetiyor; yetkisiz erişim veya manipülasyon yanlış kontaktör kontrolü, yanlış şarj sınırı veya güvenlik işlevlerinin devre dışı kalması gibi risklere yol açabilir.

2. Tehditler Neye Benziyor

CAN manipülasyonu (sahte/bozuk mesaj gönderimi), yetkisiz diagnostik (UDS erişimi) ve firmware bütünlüğü ihlali (firmware’in değiştirilmesi) — üç ana tehdit kategorisi.

ASSUMPTION — Aşağıdaki senaryo yalnızca kavramı açıklamak içindir; belirli bir saldırı tekniği, araç veya sistem hedef alınarak sunulmuyor ve amatör/yetkisiz güvenlik testine yönlendirme içermiyor.

Kavramsal bir örnek: CAN bus’a erişimi olan biri gerçek BMS’in yerine geçip sahte bir “SOP = yüksek” mesajı gönderirse, VCU bu yanlış bilgiye dayanarak batarya için güvensiz bir güç talep edebilir. Bu, mesaj kimlik doğrulamanın neden gerekli olduğunu gösteriyor.

3. Dört Savunma Katmanı

Önlem	Ne zaman devrede	Ne yapıyor
Secure boot	Açılış	Çalışan yazılımın değiştirilmediğini garanti eder
Secure flashing	Güncelleme	Yalnızca yetkili/imzalı yazılımın yüklenmesine izin verir
Authentication	Çalışma zamanı	Gelen mesajın gerçekten iddia ettiği kaynaktan geldiğini doğrular
Access control	Yetkilendirme	Kimliği doğrulanmış kullanıcıyı bile yalnızca yetkili işlemlerle sınırlar

Dördü birlikte, yaşam döngüsünün farklı aşamalarını kapsayan bir savunma zinciri oluşturuyor.

4. ISO/SAE 21434 ve TARA

ISO/SAE 21434, karayolu araçlarında siber güvenlik mühendisliği standardı; TARA (Threat Analysis and Risk Assessment) bunun kalbi. TARA, HARA’ya (BMS-17) kavramsal olarak benziyor — ikisi de sistematik risk değerlendirmesi — ama HARA rastgele/sistematik arızaları değerlendirirken TARA kasıtlı saldırı senaryolarını (tehdit aktörü, saldırı yüzeyi, olabilirlik) değerlendiriyor.

5. Bir İhlal Tespit Edildiğinde

İmza doğrulaması başarısız bir firmware güncellemesi veya geçersiz bir diagnostik oturumu tespit edildiğinde, sistem güncellemeyi/erişimi reddedip olayı kaydetmeli. Mantık, fonksiyonel güvenlik tarafındaki DTC kaydına benziyor (BMS-13) — ama kaynak burada bir donanım/yazılım arızası değil, bir güvenlik olayı.

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

Siber güvenlik önlemleri, üretim öncesi penetrasyon testi benzeri değerlendirmelerle (yetkili güvenlik ekipleri tarafından, kontrollü ortamda) doğrulanıyor; secure boot ve secure flashing’in gerçekten sahte/imzasız yazılımı reddettiği test ediliyor. Bu tür testler yalnızca yetkili, profesyonel süreçlerde yapılır — bu ders amatör/yetkisiz güvenlik testini teşvik etmiyor.

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

Siber güvenlik; CAN haberleşmesini (BMS-15) ve yazılım güncelleme sürecini (BMS-16, BMS-20) doğrudan koruyor; fonksiyonel güvenlikle (BMS-17) sıkı ilişkili çünkü bir ihlal, güvenlik mekanizmalarını devre dışı bırakarak fonksiyonel güvenliği de tehlikeye atabilir.

Özet

• BMS ağa bağlı olduğu için siber güvenlik zorunlu — bu, fonksiyonel güvenlikten farklı bir tehdit modeli (kasıtlı vs. rastgele).
• Secure boot/flashing, authentication ve access control, yaşam döngüsünün farklı aşamalarını kapsıyor.
• TARA, HARA’nın siber güvenlikteki karşılığı; ikisi birlikte tamamlayıcı çalışıyor.

Kaynaklar

• ISO/SAE 21434 — siber güvenlik mühendisliği.