Skip to main content

Etiket: Model Tabanlı Tasarım

HEV/EV Geliştirmede Geleceğin Yaklaşımı: Model Tabanlı Tasarım ve Kontrol

Bir hibrit ya da elektrikli aracın kontrol yazılımını doğrudan donanım üzerinde geliştirmek, onlarca iterasyon döngüsü, her birinde gerçek araç riski ve uzayan proje takvimleri anlamına gelir. Elektrikli güç aktarma organlarının karmaşıklığı; batarya termik yönetimi, motor sürücü elektroniği, enerji geri kazanımı ve sürücü talep yorumlama katmanlarının birbirine bağımlılığı, geleneksel yazılım geliştirme süreçlerini yetersiz kılar. Model Tabanlı Tasarım bu noktada devreye girer: gerçek donanım olmadan fiziksel sistemi modellemenize, kontrol algoritmasını bu model üzerinde doğrulamanıza ve kodu doğrudan üretmenize olanak tanır. Bu yazıda, MATLAB & Simulink ekosisteminin HEV/EV geliştirme sürecine nasıl entegre olduğunu, mimariden simülasyona, fiziksel modelleme yaklaşımından HIL testine kadar somut araçlar ve iş akışı üzerinden ele alacağız.

Elektrifikasyon Çağında Simülasyonun Gücü ve V-Diyagramı

Otomotiv endüstrisi, son yüzyılın en köklü dönüşümünü yaşıyor. İçten yanmalı motorların (ICE) tek başına hüküm sürdüğü dönemler geride kalırken; yerini alan Hibrit ve Tam Elektrikli Araçlar (HEV/EV), sadece farklı bir itki sistemi kullanmakla kalmıyor. Karmaşık yazılımlar, gelişmiş termal yönetim sistemleri, çok katmanlı güç elektroniği ve yüksek voltajlı batarya paketleriyle yönetilen devasa birer “hareketli bilgisayar” haline geliyorlar. Bu muazzam dönüşüm, sistem modelleme ve kontrol mühendislerine benzersiz bir zorluk sunuyor: Sürekli artan sistem karmaşıklığına rağmen, pazara çıkış süresini benzeri görülmemiş bir hızda kısaltmak.

Geçmişin ürün geliştirme süreçlerinde, mekanik, elektriksel ve yazılım ekipleri genellikle izole çalışırdı. Tasarım statik dokümanlar üzerinden yapılır, aylar süren çalışmaların ardından fiziksel bir prototip üretilir ve sistem seviyesindeki entegrasyon testlerine geçildiğinde büyük sürprizlerle karşılaşılırdı. Ancak bir HEV/EV sisteminde; batarya soğutma stratejisindeki küçük bir hatanın veya enerji yönetim algoritmasındaki (EMS) bir zafiyetin fiziksel prototip aşamasında fark edilmesi demek, donanımın yanması, aylarca süren gecikmeler ve telafisi zor maliyetler demektir. Pazarın bu kadar hızlı aktığı bir çağda, endüstrinin ne bu zaman kaybına ne de bu yüksek maliyetlere tahammülü var.

İşte tam bu noktada, otomotiv dünyasının ürün geliştirme standardı olan (ASPICE, ISO 26262)   V-Diyagramı (V-Model) ve bu modeli kökten dönüştüren simülasyon teknolojileri devreye giriyor.

Şekil 1 : V-Diyagramı

Klasik V-Diyagramında; sol taraf sistem gereksinimlerinden mimariye, tasarıma ve kodlamaya doğru inişi (ayrıştırma), sağ taraf ise bileşen testlerinden tam araç doğrulama ve validasyonuna çıkışı (entegrasyon) temsil eder. Geleneksel süreçlerde, V’nin sağ tarafındaki fiziksel test aşamalarına geçilmeden sistemin bütüncül performansı görülemezdi. Ancak günümüz mühendislik yaklaşımındaki “Shift-Left” (Sola Kaydırma) stratejisinin amacı; V’nin sağ tarafındaki “sistem testi ve doğrulama” adımlarını, dijital ortamda en erken aşamalara, yani V’nin sol tarafına entegre edebilmektir.

Bu devrimin merkezinde Model Tabanlı Tasarım (Model-Based Design – MBD) felsefesi yatmaktadır. MBD yaklaşımında model, sadece statik bir görsel taslak değildir. İster araç gereksinimlerinin analiz edildiği aşamada olsun, ister yazılımın C/C++ koduna dönüştürüldüğü aşamada olsun, model “yaşayan” ve sürekli doğrulanabilen bir referans noktasıdır. MathWorks ekosistemi, araç dinamiklerinden batarya hücresindeki elektro-kimyasal davranışlara kadar tüm çoklu fizik sistemlerini tek bir çatı altında birleştirerek mühendislere bu V-Diyagramı boyunca kesintisiz bir doğrulama ortamı sunar. Bu yazımızda, bir elektrikli aracın bataryasından tekerleğine kadar olan yolculuğunu, algoritmaların sadece kod blokları olmaktan çıkıp fiziksel bir aracı nasıl yönettiğini Model Tabanlı Tasarım prensipleriyle adım adım inceleyeceğiz.

Araç Mimarisi ve Güç Aktarma Organları: Mimariden Simülasyona

Model Tabanlı Tasarım sürecinin ilk pratik ve kritik adımı, geliştirilecek aracın temel mimarisine karar vermektir. Bir elektrikli veya hibrit aracın mimarisi, enerjinin kaynaklardan (batarya, içten yanmalı motor, yakıt hücresi) tekerleğe nasıl akacağını, mekanik, hidrolik ile elektriksel sistemlerin birbirine nasıl entegre olacağını en üst seviyede belirler.

Sistem mühendisleri tasarıma başlarken genellikle şu temel topolojilerden biri üzerinde yoğunlaşır:

  • Tam Elektrikli (BEV): Sadece yüksek voltajlı batarya paketi, invertörler ve elektrik motoru ile tahrik sağlayan, içten yanmalı motorun tamamen devreden çıktığı sistemler.
  • Seri Hibrit (Series HEV): İçten yanmalı motorun tekerleklere doğrudan mekanik bir bağlantısının olmadığı, sadece bir jeneratörü çevirerek elektrik ürettiği ve bataryayı beslediği sistemler.
  • Paralel Hibrit (Parallel HEV): Hem elektrik motorunun hem de içten yanmalı motorun aracı mekanik olarak sürebildiği, torkun tekerleklere şanzıman veya debriyaj sistemleriyle ayrı ayrı veya kombine olarak iletilebildiği yapılar.
  • Güç Bölmeli (Power-Split) Hibrit: Planet dişli setleri kullanılarak seri ve paralel mimarilerin avantajlarını tek bir sistemde buluşturan ve kontrolü en karmaşık olan gelişmiş topolojiler.

Mühendislik ekipleri için asıl zorluk, bu mimarilerin her birini sıfırdan, diferansiyel dişlilerinden şasi dinamiklerine kadar kodlamak ve farklı topolojilerin enerji tüketimlerini karşılaştırmaktır. İşte bu noktada Simulink kütüphaneleri, özellikle “Zaman = Maliyet” denklemini mühendisin lehine çevirir.

Şekil 2: Powertrain Blockset ile Araç Modelleme

Powertrain ve Vehicle Dynamics Blockset ile Hızlı Prototipleme

Araç dinamiği ve güç aktarma organları söz konusu olduğunda, tekerleği her seferinde yeniden icat etmeye gerek yoktur. Powertrain Blockset, mühendislere endüstri standartlarında doğrulanmış alt sistem modelleri (reference applications) sunar. Seçilen bir hibrit topoloji; blok kütüphanesindeki parametrik motor, batarya, şanzıman ve sanal sürücü (driver model) blokları kullanılarak hızlıca bir araya getirilebilir.

Bununla birlikte, aracın sadece düz bir çizgide gitmesi yeterli değildir. Vehicle Dynamics Blockset, 14 serbestlik dereceli (DOF) şasi dinamiklerini ve karmaşık lastik modellerini (örneğin Pacejka Magic Formula) sisteme dahil eder. Bu sayede araç; WLTP, NEDC gibi standart emisyon ve menzil döngülerinin ötesine geçerek, viraj alma, şerit değiştirme gibi 3 boyutlu yörünge takibi gerektiren dinamik testlerde koşturulabilir.

Ayrıca, debriyajlar, senkromeçler ve planet dişliler gibi karmaşık mekanik aktarma organlarının modellenmesinde sinyal tabanlı modelleme tek başına yetersiz kalır. Burada Simscape Driveline devreye girerek, tork iletimini, ataleti ve mekanik kayıpları fiziksel denklemlere dayalı bağlar üzerinden yüksek sadakatle çözümler. Tüm bu sistem modelleri, kontrol mühendislerinin algoritmalarını “sanki gerçek bir aracı test pistine çıkarmış gibi” bilgisayar ortamında test etmelerini sağlayan bir sanal laboratuvar görevi görür.

Fiziksel Sistem Modelleme: Acausal (Fiziksel) Yaklaşımla Kalbe İniş

Araç seviyesindeki genel topolojiyi ve araç dinamiğini (Plant Model) temel düzeyde kurduktan sonra, sıra bu aracı tahrik eden ana unsurların “mikro” düzeyde gerçeğe yakın (high-fidelity) modellenmesine gelir. Bir sistem modelleme ve kontrol mühendisinin altın kuralı her zaman şudur: Geliştirdiğiniz kontrolcü, ancak üzerinde test edildiği fiziksel modelin gerçeğe yakınlığı kadar güvenilirdir.

Geleneksel Simulink blokları veri akışını sinyal tabanlı olarak modeller. Ancak, bir bataryanın iç direnci veya bir elektrik motorunun termal yayılımı gibi çok yönlü fiziksel etkileşimleri sinyallerle modellemek sistem karmaşıklaştıkça içinden çıkılmaz bir cebirsel döngüye dönüşür. Bu noktada, bileşenlerin birbirine gerçek dünyadaki gibi fiziksel enerji (akım, tork, ısı) transferi üzerinden bağlandığı Simscape devreye girer.

Şekil 3: Simscape ile oluşturulmuş SOC modeli

Simscape Battery ve Çoklu Fizik Entegrasyonu

Bir elektrikli aracın en kritik bileşeni bataryasıdır. Batarya Yönetim Sistemi (BMS) algoritmalarını doğru tasarlayabilmek için hücrenin kimyasal, elektriksel ve termal davranışlarını eşzamanlı olarak modellemek şarttır.

  • Eşdeğer Devre Modelleri (ECM): Simscape Battery, hücre dinamiklerini OCV (Açık Devre Voltajı), kapasite, iç direnç ve RC ağlarıyla (RC network) ifade eder. Bu parametreler genellikle gerçek hücrelerin HPPC (Hybrid Pulse Power Characterization) testlerinden elde edilen verilerle kalibre edilir.
  • Termal Yayılım: Tek bir hücre modelinden modüle, modüllerden ise binlerce hücrelik bir batarya paketine geçiş yapılır. Hücrelerin yüksek C-rate ile deşarj olurken yaydığı ısının, alt kısımdaki soğutma plakalarına aktarımı termal domain içerisinde modellenir. Elektrik akımı ve ısı, aynı anda tek bir model üzerinden çözülür.

Elektrik Motoru (Simscape Electrical ve Multibody)

Çekiş motorunun kontrolü, aracın sürüş dinamiğini doğrudan belirler. PMSM (Sabit Mıknatıslı Senkron Motor) gibi AC motorların modellenmesinde, stator akımlarının d-q eksenlerindeki dinamikleri, manyetik akı zayıflatma (flux weakening) bölgeleri ve non-lineer tork üretim karakteristikleri Simscape Electrical üzerinden sisteme aktarılır.

Ancak bir elektrik motoru boşlukta dönmez. Rotorun ataleti, dişli kutusundaki sürtünmeler, yataklamalar ve şasiye binen yükler işin mekanik boyutunu oluşturur. Simscape Multibody ile oluşturulan üç boyutlu mekanik kısıtlar doğrudan motor miline entegre edilir. Böylece, ECU’dan motora verilen milisaniyelik elektriksel bir komutun, tekerlekte nasıl bir mekanik burulmaya ve titreşime dönüşeceği, aynı zamanda ne kadar ısı üreteceği tek bir entegre fiziksel modelde gözlemlenir.

Şekil 4 : Araç dinamiği modeli için bir Autotuner alt sistemi

Sistem Seviyesi Modelleme, Gelişmiş Kontrol ve Karar Mekanizmaları

Fiziksel sınırları belirlenmiş, termal ve mekanik olarak doğrulanmış (validated) “Plant” modelimizi gerçeğe en yakın şekilde inşa ettikten sonra, sıra bu kasları yönetecek “beyni”, yani Elektronik Kontrol Ünitesini (ECU) tasarlamaya gelir. HEV/EV sistemlerinde kontrol algoritmaları sadece motoru döndürmekle kalmaz; güvenliği sağlar, bataryayı korur ve dinamik limitler dahilinde menzili optimize eder.

Bu aşamada geliştirilen kontrol stratejileri, aracın dinamiğini yöneten alt seviye kontrolcüler ile sistem modlarını yöneten üst seviye denetleyicilerin (supervisory) kusursuz bir uyum içinde çalışmasını gerektirir.

Gelişmiş Dinamik Kontrol: Model Predictive Control (MPC)

Klasik PID kontrolörler, tek giriş-tek çıkışlı (SISO) doğrusal sistemlerde başarılı olsalar da, HEV/EV gibi kısıtların (constraint) çok keskin olduğu, çok girişli-çok çıkışlı (MIMO) dinamiklerde limitlere takılır. Özellikle çekiş kontrolü (TCS), elektronik stabilite kontrolü (ESC) ve tekerleklere ayrı ayrı güç ileten tork vektörleme (torque vectoring) uygulamalarında Model Öngörülü Kontrol (MPC) sektör standardı haline gelmektedir.

  • MPC, gelecekteki x adım (horizon) boyunca sistemin nasıl davranacağını matematiksel model üzerinden öngörerek bir optimizasyon problemi çözer.
  • Bu çözümü yaparken, “Bataryadan maksimum 200A çekilebilir” veya “Motor maksimum 350Nm tork üretebilir” gibi fiziksel kısıtları matematiksel sınır şartları olarak doğrudan içine alır. Model Predictive Control Toolbox ile bu karmaşık optimizasyon algoritmaları donanıma (gömülü C kodu olarak) gömülebilecek hafiflikte sentezlenir.

Şekil 5 : Simulink modelinde MPC entegrasyonu

Sinyal İşleme ve Durum Kestirimi (State Estimation)

Simülasyon ortamında (Plant) bataryanın iç sıcaklığını veya şarj durumunu (SoC) %100 doğrulukla bilebiliriz. Ancak gerçek bir araçta ECU’nun elinde sadece sensörlerden gelen gürültülü voltaj ve akım okumaları vardır.

Sistemin ölçülemeyen (unobservable) durumlarını tahmin etmek için Genişletilmiş Kalman Filtreleri (Extended Kalman Filter – EKF) kullanılır. EKF algoritmaları, sensör gürültüsünü filtreleyerek bataryanın anlık SoC (State of Charge) ve SoH (State of Health) değerlerini matematiksel varyansları minimize ederek kestirir. Bu kestirim algoritmaları, Control System Toolbox üzerinden Simulink ile Plant modele geri beslenerek doğrulanır.

Enerji Yönetim Sistemi (EMS) ve Stateflow ile Denetleyici Kontrol

Hibrit mimarilerin en büyük problemi şudur: Sürücü pedala bastığında istenen bu tork, bataryadan mı, içten yanmalı motordan mı, yoksa ikisinden birden mi karşılanmalıdır?

  • Menzili optimize eden, yakıt tüketimini düşüren ve batarya şarjını koruyan Enerji Yönetim Sistemi (EMS), kural tabanlı (rule-based) algoritmalarla veya ECMS (Equivalent Consumption Minimization Strategy) gibi yöntemlerle çözülür.
  • Tüm bu alt stratejilerin şefi ise Denetleyici Kontrol (Supervisory Control) algoritmasıdır. Araç modları (Park, Sürüş, Arıza/Limp-Home, Şarj) arasındaki karar mekanizmaları karmaşık kod yığınları ile yazılmaz. Stateflow ile durum makineleri (state machines) olarak görselleştirilir. Stateflow, batarya sıcaklığı kritik limiti aştığında tork vektörleme algoritmasını devreden çıkarıp aracı “Güç Kısıtlı Mod”a geçiren o kritik mantığı (logic), güvenilir ve izlenebilir bir yapıda yönetir.

Test ve Doğrulama: Algoritmaların Donanımla Buluşması (SIL ve HIL)

Geliştirilen enerji yönetim sistemleri (EMS), tork vektörleme algoritmaları veya batarya termal yönetim mantıkları, bilgisayar ortamında (MIL – Model-in-the-Loop) kusursuz çalışabilir. Ancak gerçek dünya, sonsuz işlem gücüne sahip bir masaüstü bilgisayar kadar affedici değildir. Bir kontrol mühendisi olarak kendimize şu soruları sormak zorundayız: Algoritmam, düşük işlem gücüne sahip gerçek bir ECU içine gömüldüğünde hesaplamaları milisaniyeler içinde yetiştirebilecek mi (overrun)? Sensör kopmaları veya haberleşme kayıpları olduğunda sistem nasıl tepki verecek?

İşte bu soruların cevabını fiziksel bir araç prototipini riske atmadan bulmak için V-Diyagramı’nın doğrulama adımları devreye girer.

Kod Üretimi ve SIL (Software-in-the-Loop)

Model Tabanlı Tasarım’ın (MBD) endüstriye sunduğu en büyük devrim, yüz binlerce satırlık C/C++ kodunun manuel olarak yazılmasını tarihe gömmesidir. Simulink ve Stateflow ile hazırladığımız, MIL ortamında test edip doğruladığımız kontrol algoritmaları, Embedded Coder yardımıyla otomotiv kodlama standartlarına (MISRA C/C++, ISO 26262) tam uyumlu, optimize edilmiş gömülü C koduna saniyeler içinde dönüştürülür.

Üretilen bu kod, doğrudan donanıma atılmadan önce SIL (Software-in-the-Loop) testine tabi tutulur. Bu aşamada üretilen C kodu, ana bilgisayar (host) üzerinde koşturularak, modelin matematiksel sonuçları ile gömülü kodun ürettiği sonuçlar karşılaştırılır. Kayan noktalı (floating-point) işlemlerin, sabit noktalı (fixed-point) işlemci veri tiplerine dönüşürken yaşayabileceği hassasiyet kayıpları ilk kez burada yakalanır.

Donanımlı Simülasyon: HIL (Hardware-in-the-Loop)

Bir elektrikli aracın invertörünü veya Batarya Yönetim Sistemini (BMS), test sürüşüne çıkarıp hatalarını görmek oldukça tehlikeli ve maliyetlidir. Bataryada yaşanacak bir kısa devreyi gerçek dünyada bilerek yaratmak istemezsiniz. Bu noktada testleri dijital bir laboratuvara taşıyan Hardware-in-the-Loop (HIL) sistemleri devreye girer.

HIL testlerinde, üretim kodunun yüklendiği Gerçek ECU fiziksel olarak masadadır. Ancak bu ECU, gerçek bir motora veya bataryaya değil, gerçek zamanlı bir hedef makineye bağlanır.

Speedgoat ve Simulink Real-Time: FİGES olarak uzmanlığımızla sektöre sunduğumuz en güçlü çözümlerden biri olan Speedgoat gerçek zamanlı test sistemleri, MathWorks altyapısıyla “Plug & Play” (Tak-Çalıştır) seviyesinde entegredir. Simscape ile 3. bölümde tasarladığımız o yüksek sadakatli (high-fidelity) fiziksel araç ve batarya modeli, Simulink Real-Time aracılığıyla Speedgoat donanımına yüklenir.

Gerçek Zamanlı İletişim: Speedgoat, içindeki FPGA ve güçlü işlemciler sayesinde, sanki gerçek bir araçmış gibi davranır. Gerçek ECU’ya CAN, LIN, Ethernet veya doğrudan analog/PWM sinyalleri gönderir. ECU ise aracı sürdüğünü sanarak tork veya soğutma komutları üretir. Speedgoat bu komutları alır, fiziksel araç modelini mikrosaniyeler içinde günceller ve yeni sensör verilerini ECU’ya geri yollar.

Hata Enjeksiyonu (Fault Injection) ve Güvenlik Limitleri

HIL sistemlerinin asıl büyük katkıyı yaptığı yer, test pistinde yaratılması imkansız olan senaryoları (edge-cases) stressiz bir şekilde koşturabilmesidir.

  • BMS testlerinde bir sıcaklık sensörünün kopması,
  • CAN hattında paket kayıpları yaşanması,
  • İnvertörde bir fazın şasiye kısa devre yapması gibi arızalar…

Speedgoat üzerindeki Hata Enjeksiyonu (Fault Injection) kartları sayesinde bu arızalar milisaniyelik bir röle geçişiyle sisteme fiziksel olarak uygulanır. Böylece, ECU’nun ve yazdığımız Stateflow denetleyicisinin bu arızaları ne kadar sürede algıladığı ve aracı güvenli bir şekilde “Limp-Home” (Kısıtlı Sürüş) moduna alıp almadığı doğrulanmış olur.

Sonuç

HEV/EV geliştirmede doğrulama maliyetinin büyük bölümü, geç keşfedilen hatalardan kaynaklanır. Model Tabanlı Tasarım bu keşfi mümkün olduğunca öne çeker: gereksinim aşamasından başlayan izlenebilirlik, Simscape ile fiziksel sistemi dijital ikizine dönüştüren modelleme, Powertrain Blockset ile hızlanan prototipleme ve SIL/HIL ile kapatılan donanım-yazılım uyum döngüsü birlikte tek bir entegre süreç oluşturur. Sonuçta ortaya çıkan şey yalnızca daha hızlı bir geliştirme süreci değil, her kararın modele dayandığı ve her testin izlenebilir olduğu bir mühendislik disiplinidir.

Mühendislik Yolculuğunuzda Yanınızdayız

MATLAB & Simulink çözümleri, teknik danışmanlık, eğitimler veya projeleriniz hakkında sorularınız mı var? Sorularınızı yanıtlamaktan ve projelerinize değer katacak çözümler sunmaktan memnuniyet duyarız.

Batarya Yönetim Sistemi (BMS) Modellemesi: Hücreden HIL Doğrulamaya Uçtan Uca Model Tabanlı Tasarım

Batarya sistemleri büyüdükçe, BMS yazılımlarının kontrol, güvenlik ve optimizasyon görevleri de daha karmaşık hale gelmektedir. Enerji depolama tesislerinden (BESS) elektrikli dikey kalkış yapabilen hava araçlarına (eVTOL), savunma sanayiinden modern elektrikli araçlara (EV) kadar yüksek güvenilirlik gerektiren kritik enerji ve mobilite uygulamalarının merkezinde bataryalar yer alır. Bu karmaşık sistemleri geleneksel yöntemlerle yönetmek yüksek maliyet ve risk barındırır. Bu noktada devreye giren Model Tabanlı Tasarım (Model-Based Design – MBD); yazılımsal algoritmalar ile fiziksel dünyayı bir araya getiren siber-fiziksel sistemlerin tasarım ve doğrulama süreçlerinin büyük bölümünü dijital ortama taşıyarak, hataların henüz geliştirme aşamasındayken daha erken tespit edilmesini ve giderilmesini (Shift-Left felsefesi) destekler.

Bu yazımızda, bir batarya hücresinin fiziksel modellenmesinden başlayarak; donanım soyutlama katmanlarına, gelişmiş durum tahminleyicilerine, yapay zeka entegrasyonlarına ve laboratuvar ortamındaki HIL (Hardware-in-the-Loop) doğrulama süreçlerine uzanan uçtan uca MBD iş akışı ele alınmaktadır.

Şekil 1. Batarya hücresinden HIL doğrulamaya uzanan uçtan uca BMS modelleme ve doğrulama akışı.

Hücreden Pakete Simscape Battery ile Fiziksel Modelleme

BMS algoritmalarının başarısı, denetledikleri fiziksel sistemin dinamiklerini ne kadar hassas taklit edebildikleriyle doğrudan ilişkilidir. MathWorks, Simscape Battery ve Simscape Electrical kütüphaneleriyle batarya paketinin dijital ikizini (Plant Modeling / Fiziksel Sistem Modelleme) kurgulamak için bütünleşik bir fiziksel modelleme altyapısı sunar.

Battery Builder ile Hiyerarşik Batarya Modelleme

Yüzlerce hücreyi tek tek manuel olarak bağlamak yerine, Simscape Battery içerisindeki Battery Builder (MATLAB API & App) kullanılarak hiyerarşik ve tamamen parametrik bir fiziksel sistem modellenir:

  1. Hücre Geometrisi (Cell): Silindirik (CylindricalGeometry), prizmatik (PrismaticGeometry) veya keseli/pouch (PouchGeometry) hücre formatları; yükseklik, kalınlık ve terminal çıkışı / tab konumları hassas şekilde tanımlanır.
  2. Topolojik Yerleşim (ParallelAssembly): Hücrelerin Hexagonal (altıgen) veya Square (kare) topolojideki yerleşimi ile hücreler arası mesafe (InterCellGap) belirlenerek paralel gruplar oluşturulur.
  3. Dengeleme ve Isıl Yollar: Pasif dengeleme dirençleri (Passive) ve soğutma plakası ısıl yolları (CoolantThermalPath) doğrudan bu aşamada mimariye eklenir.
  4. Hiyerarşik Montaj (Module, Pack): Paralel gruplar seri bağlanarak modülleri, modüller bir araya getirilerek tüm batarya paketini (Pack) otomatik olarak oluşturur.

Bu hiyerarşik yaklaşım, manuel şematik kurulum ve bağlantı süreçlerini önemli ölçüde hızlandırarak modelleme sürecindeki tekrar işlerini ve insan kaynaklı hata riskini azaltır.

Elektro-Termal Parametre Kestirimi ve Model Doğrulama

Hücrelerin dinamik ve ısıl davranışlarını yakalamak için Eşdeğer Devre Modeli (Equivalent Circuit Model – ECM) yaklaşımı benimsenir. Hücre parametrelerinin sıcaklığa ve Şarj Durumuna (SOC) bağlı karakterizasyonu için şu akış izlenir:

  • Farklı sıcaklık noktalarında HPPC (Hybrid Pulse Power Characterization) testleri gerçekleştirilir.
  • Deneysel akım ve gerilim verileri, Simulink Design Optimization aracındaki doğrusal olmayan en küçük kareler çözücüleri (fminsearch, fmincon) ile analiz edilir.
  • Elde edilen direnç ve zaman sabiti değerleri, modelin içine çok boyutlu Arama Tabloları (Lookup Tables) olarak gömülür.
  • Model Doğrulama: Elde edilen ECM parametreleri, eğitim verisinden bağımsız sürüş/şarj profilleri üzerinde tekrar çalıştırılarak hücre gerilimi, sıcaklık ve SOC davranışının deneysel ölçümlerle tutarlılığı değerlendirilir.

Gelişmiş Hücre Fiziği ve ROM Yaklaşımları

Kimyasal seviyede lityum difüzyonunu ve katı/sıvı fazlardaki elektrokimyasal reaksiyonları doğrudan çözmek istendiğinde, Simscape Battery bünyesinde SPMe (Single Particle Model with Electrolyte Dynamics) ve DFN (Doyle-Fuller-Newman) fiziksel modelleri aktifleştirilebilir. Bu modeller, hücre düzeyinde degradasyon (degradation – bataryanın kimyasal ve fiziksel olarak yaşlanması/yıpranması) analizleri ve hızlı şarj sınırlarının belirlenmesi için önemli avantaj sağlar. Ayrıca, MathWorks ekosistem ortağı Batemo’nun fiziksel-kimyasal hücre modelleri, Simscape termal ve elektriksel portlarıyla doğrudan ve uyumlu bir şekilde entegre edilebilmektedir. İleri seviye hücre modelleme çalışmalarında, lityum-iyon hücrelerin yük altındaki elektrokimyasal davranışını daha ayrıntılı incelemek için DFN gibi fiziksel modellerden yararlanılabilir.

Batarya paketlerinin 3 boyutlu sıcaklık dağılımlarını doğrulamak amacıyla CFD (Hesaplamalı Akışkanlar Dinamiği) simülasyonları çalıştırmak büyük bir zaman darboğazı yaratır. Yüksek sadakatli CFD/FEA tabanlı modeller, tek bir simülasyon koşumunda dakikalar hatta saatler mertebesinde hesaplama süresi gerektirebilir. Bu hesaplama yükü, yüksek sadakatli modellerin doğrudan gerçek zamanlı HIL ortamlarında kullanılmasını zorlaştırabilir.

MathWorks, bu darboğazı aşmak için Reduced Order Modeler App ve PDE (Partial Differential Equation) Toolbox aracılığıyla Reduced Order Model (ROM) oluşturulmasını destekler.

Donanımdan Bağımsız BMS Yazılım Mimarisi

System Composer ile Katmanlı Yazılım Mimarisi

Geliştirilen BMS kontrol yazılımının tedarik zinciri değişimlerinden daha az etkilenmesi ve farklı donanım platformlarına (Texas Instruments, NXP, STMicroelectronics vb.) daha kontrollü şekilde uyarlanabilmesi için katmanlı bir yazılım mimarisi kritik önem taşır.

System Composer ile kurgulanan düz (flat) hiyerarşik mimari, donanım bağımlılığını azaltmaya yönelik önemli bir yaklaşım sunar:

HAL (Hardware Abstraction Layer): Doğrudan mikroişlemcinin fiziksel register’larıyla, ADC kesmeleriyle veya SPI/CAN haberleşme hatlarıyla etkileşen donanım sürücüleri katmanıdır.

RTE (Runtime Environment / Veri Yorumlama Katmanı): HAL’den gelen ham sensör verilerini fiziksel anlamlı değerlere (volt, amper, °C) dönüştüren köprü katmandır.

Application (Uygulama Katmanı): Şarj durumu tahmini, hücre dengeleme, kontaktör kontrolü ve hata yönetimi gibi çekirdek BMS fonksiyonlarının bulunduğu, donanım detaylarından mümkün olduğunca ayrıştırılmış katmandır.

İşlemci veya donanım platformu değiştiğinde, uygulama katmanındaki algoritmaları büyük ölçüde koruyup HAL/RTE katmanlarında yapılacak güncellemelerle geçiş süreci daha kontrollü şekilde yürütülebilir.

Şekil 2. HAL, RTE ve Application katmanları üzerinden donanım bağımlılığını azaltmaya yönelik BMS yazılım mimarisi.

Fonksiyonel, Mantıksal ve Fiziksel Mimari Katmanları

System Composer, yalnızca gömülü yazılım katmanlarını değil; BMS gibi siber-fiziksel sistemlerde gereksinimler, yazılım bileşenleri ve hedef donanım arasındaki mimari ilişkilerin izlenebilir şekilde kurulmasını da destekler. Bu yaklaşım, Model Tabanlı Sistem Mühendisliği (MBSE) çerçevesinde üç temel mimari katman üzerinden ele alınabilir:

Fonksiyonel Mimari (Functional Architecture):

Sistemin gerçekleştirmesi beklenen temel işlevleri, elektriksel ve yazılımsal uygulama detaylarından bağımsız olarak tanımlar. Örneğin, “aşırı gerilim durumunda sistemi koruma” veya “hücre gerilimlerini izleme” gibi fonksiyonlar bu katmanda ele alınır. Bu işlevler, Requirements Toolbox üzerinden müşteri ve sistem gereksinimleriyle izlenebilir şekilde ilişkilendirilebilir.

Mantıksal Mimari (Logical Architecture):

Fonksiyonel gereksinimleri gerçekleştirecek yazılım bileşenlerini ve bu bileşenler arasındaki veri alışverişini tanımlar. Simulink ve Stateflow ortamında modellenen SOC/SOH kestirimi, hücre dengeleme, güvenli durum yönetimi ve hata yönetimi gibi çekirdek yazılım bileşenleri bu katmanda konumlandırılabilir. Bu seviyede portlar, arayüzler ve RTE katmanı üzerindeki veri yolları sistematik olarak tanımlanır.

Fiziksel / Platform Mimarisi (Physical / Platform Architecture):

Yazılımın üzerinde çalışacağı hedef donanım bileşenlerini ve platform bağımlı arayüzleri temsil eder. NXP S32K işlemcisi, MC33771B AFE çipi, SPI/CAN haberleşme hatları, ADC/GPIO arayüzleri ve donanım sürücü katmanları bu kapsamda ele alınabilir.

System Composer içerisindeki Allocation Editor, fonksiyonel mimari, mantıksal mimari ve fiziksel/platform mimarisi arasındaki ilişkilerin izlenebilir şekilde kurulmasına yardımcı olur. Böylece hangi fonksiyonun hangi yazılım bileşeni tarafından gerçekleştirileceği ve bu bileşenin hangi hedef donanım ya da platform birimi üzerinde çalışacağı sistematik olarak eşleştirilebilir.

Bu katmanlar arası izlenebilirlik, yüksek güvenilirlik gerektiren BMS projelerinde mimari tutarlılığın, değişiklik etkisi analizinin ve donanım geçiş süreçlerinin daha kontrollü yürütülmesine katkı sağlar.

Sistem Veri Sözlüğü (.sldd) ve Hiyerarşik Veri Yapısı

BMS modelinde kullanılan sinyaller, kalibrasyon parametreleri ve arayüz tanımları, geçici çalışma alanları yerine Simulink Data Dictionary (.sldd) içinde merkezi olarak yönetilebilir. Bu yaklaşım, farklı model bileşenlerinin ortak veri tanımlarını kullanmasını destekler ve entegrasyon sırasında oluşabilecek veri tipi, boyut veya adlandırma uyumsuzluklarının daha erken fark edilmesine yardımcı olur.

Çok sayıda sinyalin tek bir düzenli veri yapısı altında taşınması için Bus Element Ports kullanılabilir. Bu sayede model içerisindeki dağınık sinyal bağlantıları azaltılır, arayüzlerin okunabilirliği artırılır ve alt sistemler arasındaki veri akışı daha izlenebilir hale gelir.

Embedded Coder Dictionary ayarlarıyla ilişkilendirilen bu veri yapıları, kod üretimi sırasında hiyerarşik C-Struct yapılarına dönüştürülebilir. Örneğin BMS_Global_Data.Cell_Voltage benzeri bir yapı, uygulama katmanı, RTE ve HAL arasındaki veri paylaşımının daha düzenli ve izlenebilir şekilde yönetilmesine katkı sağlar.

Volvo XC90 ve LG Chem Kullanıcı Hikayesi

LG Chem, Volvo XC90 plug-in hybrid (PHEV) aracı için AUTOSAR ve ISO 26262 uyumlu BMS geliştirirken bu katmanlı mimariyi ve MBD iş akışını uygulamıştır. Simulink Check ve Simulink Coverage kullanımı sayesinde, her yazılım sürümünde tespit edilen yazılım hata ve sorun sayısı ortalama 22’den 9’un altına (%50’den fazla iyileşme) düşürülmüş, kod kalitesi ve yeniden kullanılabilirlik belirgin şekilde iyileştirilmiştir.

Simscape Battery ile BMS Algoritma Prototipleme ve Referans İş Akışları

Simscape Battery ekosistemi, hücre seviyesindeki elektro-termal modellemeden başlayarak paralel hücre grupları, modül ve paket seviyesine uzanan hiyerarşik bir modelleme yaklaşımı sunar. Bu yapı; BMS algoritmalarının SOC/SOH kestirimi, soğutma, yaşlanma, güvenlik ve kapalı çevrim test süreçleriyle birlikte değerlendirilmesini destekler. Şekil 5, Simscape Battery tabanlı bu uçtan uca modelleme ve doğrulama yaklaşımını özetlemektedir.

Şekil 3. Simscape Battery ile hücreden pakete, BMS algoritmalarından doğrulama süreçlerine uzanan modelleme iş akışı.

Referans Bloklar ve Kapalı Çevrim Test Yaklaşımı

Simscape Battery, batarya paketinin fiziksel davranışını modellemenin yanında, BMS algoritmalarının model seviyesinde geliştirilmesi ve doğrulanması için kullanılabilecek referans bloklar, örnek iş akışları ve kütüphane yapıları sunar. Bu yapı; hücre gerilimi ve sıcaklık izleme, şarj/deşarj sınırlarının hesaplanması, SOC/SOH kestirimi, hata izleme ve hücre dengeleme gibi temel BMS fonksiyonlarının Simulink ve Stateflow ortamında kapalı çevrim olarak test edilmesine yardımcı olur.

Simscape Battery içerisindeki Simscape > Battery > BMS > Estimators kütüphanesi; Coulomb counting, Kalman filtresi, adaptive Kalman filtresi ve kapasite tabanlı SOH kestirimi gibi farklı durum tahminleyici blokları içerir. Bu bloklar, hücre voltajı, akım ve sıcaklık gibi ölçülebilir sinyaller üzerinden SOC, SOH, terminal direnç değişimi ve kapasite değişimi gibi kritik batarya durumlarının tahmin edilmesini destekler.

Bu referans yapılar, BMS yazılımında şarj yönetimi, SOC/SOH kestirimi, pasif hücre dengeleme, ısıl yönetim/soğutma kontrolü ve gerilim-hata izleme gibi temel algoritma blokları halinde kurgulanabilir. Şekil 6, bu blokların sensör girişleri, BMS çıkışları ve batarya plant modeliyle kapalı çevrim test bağlamındaki ilişkisini özetlemektedir.

Şekil 4. Temel BMS algoritma blokları ve kapalı çevrim entegrasyon yapısı: şarj kontrolü, SOC/SOH kestirimi, pasif hücre dengeleme, ısıl yönetim, gerilim/hata izleme ve plant modeliyle kapalı çevrim doğrulama akışı.

SOC/SOH Kestirimi, Koruma ve Akım Sınırı Fonksiyonları

BMS algoritma geliştirme sürecinde ayrıca gerilim ve sıcaklık izleme, hata durumlarının nitelendirilmesi, şarj kontrol mantığı, pasif hücre dengeleme, test senaryoları ve akım sınırı hesaplama akışları model seviyesinde kurgulanabilir. Bu yaklaşım, temel BMS fonksiyonlarının fiziksel donanıma geçmeden önce MIL, SIL, PIL ve HIL doğrulama adımları kapsamında daha kontrollü şekilde değerlendirilmesine katkı sağlar.

Bu referans iş akışları, BMS geliştirme sürecinde farklı fonksiyonların ayrı ayrı prototiplenmesini ve daha sonra kapalı çevrim sistem seviyesinde birlikte değerlendirilmesini kolaylaştırır. Örneğin, gerilim/sıcaklık izleme ve hata nitelendirme koruma katmanında; SOC/SOH kestirimi durum tahmini katmanında; pasif hücre dengeleme, şarj kontrol mantığı ve akım sınırı hesaplama ise uygulama kontrol katmanında ele alınabilir.

Kod üretimi hedeflenen projelerde ise kullanılan her blok ve alt sistemin veri tipi, örnekleme zamanı ve kod üretimi uyumluluğu ilgili MATLAB & Simulink sürümü özelinde ayrıca kontrol edilmelidir. Örneğin, şarj mantığı gibi karar tabanlı BMS fonksiyonları için Stateflow ile açık durum makineleri oluşturmak, kod üretimi ve izlenebilirlik açısından daha kontrollü bir yöntem sunar.

Dikkat

Uygulamalı örnek model ve test akışı için MATLAB Central / File Exchange üzerinde yer alan “Design and Test Lithium Ion Battery Management Algorithms” çalışması ayrıca incelenebilir.

Stateflow ile Güvenlik, Kontaktör ve Hata Yönetimi

BMS algoritmalarındaki karmaşık mantıksal karar mekanizmaları ve güvenlik senaryoları Stateflow durum makineleriyle görsel, izlenebilir ve deterministik çalışmaya uygun şekilde modellenebilir.

BMS Çalışma Modlarının Durum Makinesiyle Modellenmesi

BMS’in tüm yaşam döngüsü 4 ana durumda (state) yönetilir:

  • Standby (Bekleme): Başlangıç durumudur; kontaktörler açık, sistem izlemededir.
  • Driving (Sürüş): Bataryanın yükü beslediği dinamik deşarj modudur.
  • Charging (Şarj): CC-CV şarj döngüsünü ve hücre dengeleme süreçlerini yöneten aktif şarj modudur.
  • Fault (Hata): Herhangi bir kritik limit aşımı tespit edildiği an sistemi “Güvenli Duruma” (Safe State) çeken koruma katmanıdır.

Kontaktör Zamanlama Sekansı

Yüksek akım geçişleri sırasında oluşabilecek ani akım sıçramalarının, kontaktör kontaklarında ark oluşumuna ve kontakların kaynaklanarak kapalı konumda kalmasına yol açmasını önlemek için milisaniye hassasiyetindeki anahtarlama zamanlamaları Stateflow zamanlayıcılarıyla yönetilir. Sırasıyla; negatif kontaktör kapatılır, ön-şarj (Pre-Charge) kontaktörü devreye alınır, voltaj dengesi sağlandığında pozitif kontaktör kapatılır ve son olarak ön-şarj kontaktörü güvenle açılır.

Sanal Hata Enjeksiyonu ve Güvenli Durum Yönetimi

Modelin orijinal yapısını bozmadan güvenlik algoritmalarını test etmek için Simulink Fault Analyzer kullanılır. Hücre voltaj sensörünün kopması veya kontaktörün takılı kalması gibi ekstrem arızalar modele “Sanal Hata (Fault Injection)” olarak enjekte edilir ve sistemin bu hataları algılama ve güvenli duruma geçiş davranışı model seviyesinde değerlendirilir.

SOC/SOH Kestirimi ve Yapay Zekâ Tabanlı Yaklaşımlar

Bataryanın doğrudan ölçülemeyen şarj durumu (SOC) ve sağlık durumu (SOH), gelişmiş matematiksel gözlemleyicilerle kestirilebilir. Bu kestirimlerin, deterministik döngü süresi kısıtlarına uygun şekilde çalışması kritik önem taşır.

Kalman Filtresi Tabanlı Durum Kestirimi

Basit Coulomb Sayımı (Amper-Saat Entegrasyonu) sensör gürültülerini zamanla biriktirir (integral drift) ve yanlış başlangıç değerlerini düzeltemez. Bu zayıflığı gidermek için Genişletilmiş (EKF) ve Unscented (UKF) Kalman Filtreleri kullanılır. Kalman Filtresi, hücrenin elektro-termal modelini (ECM) referans alarak sensör gürültülerini süzer ve başlangıç tahmin hatalarını hızla telafi eder.

Uyarlanabilir (Adaptive) Kalman Filtresi ise kestirim döngüsüne bataryanın anlık terminal iç direncini (R0) de ekler. Tahmin edilen bu R0 ve anlık kapasite (Q) değerleri üzerinden SOH (Sağlık Durumu) dolaylı olarak aşağıdaki mühendislik bağıntılarıyla hesaplanabilir:

  • Kapasite Tabanlı SOH: SOH_Q = (Q – Q_eol) / (Q_new – Q_eol) (Kapasite orijinal değerinin %80’ine düştüğünde batarya ömür sonu – EOL kabul edilir).
  • İç Direnç Tabanlı SOH: SOH_R = (R_eol – R0) / (R_eol – R_new) (İç direnç yeni değerinin 2 katına çıktığında batarya EOL kabul edilir).

Büyük Batarya Paketleri için Bar-Delta SOC Yaklaşımı

Onlarca hücreden oluşan büyük batarya paketlerinde her hücre için bağımsız Kalman Filtresi çalıştırmak, gömülü işlemci üzerindeki hesaplama yükünü önemli ölçüde artırabilir. MathWorks’ün sunduğu Pack Bar & Cell Delta SOC Estimator bloğu bu sorunu çözer:

  • Bar Filtresi: Tüm paketin ortalama durumunu tek bir merkez Kalman Filtresiyle (SOC_bar) hesaplar.
  • Delta Filtreleri: Hücreler arası ufak sapmaları daha hafif Delta filtreleriyle tahmin eder.
  • Sonuç: CPU yükünün daha verimli yönetilmesine katkı sağlayarak Gregory L. Plett’in literatürdeki öncü çalışmalarına dayanan bu karmaşık tahminlerin gerçek zamanlı olarak çalıştırılmasını sağlar.

Yapay Zeka Tabanlı Sanal Sensörler ve ROM Modelleri

Geleneksel fiziksel modellerin ve Kalman filtrelerinin doğrusal olmayan ekstrem yaşlanma dinamiklerini yakalayamadığı durumlarda yapay zeka çözümleri devreye girer.

Yapay Zeka Tabanlı Sanal Sensörler (Virtual Sensors)

Fiziksel veya ekonomik kısıtlar nedeniyle donanımsal sensörlerin yerleştirilemediği durumlar için Virtual Sensor (Sanal Sensör) metodolojisi kullanılır. Sanal sensörler; fiziksel sensörler yerine matematiksel veya derin öğrenme (LSTM) modellerini kullanarak, ölçülebilen değerler (akım, voltaj, sıcaklık) üzerinden ölçülemeyen içsel durumları tahmin eder.

  • Endüstriyel Uygulama Örnekleri:
  • Mercedes-Benz: Motor silindirleri içindeki anlık basınç değişimlerini izlemek için derin öğrenme tabanlı sanal basınç sensörlerini üretim hattına taşımıştır.
  • Gotion: Batarya paketlerinde hücre düzeyinde anlık durum takibi yapmak için yapay sinir ağı tabanlı sanal SOC sensörleri tasarlamıştır.
  • Coca-Cola: İçecek otomatlarındaki karışım kalitesini izlemek üzere sanal basınç sensörlerinden yararlanmaktadır.

Zaman Serisi Tahmini ve Kestirimci Bakım (Predictive Maintenance)

Predictive Maintenance Toolbox kullanılarak kurgulanan makine öğrenmesi modelleri, bataryanın Kalan Faydalı Ömrünü (Remaining Useful Life – RUL) tahmin ederek plansız duruşların önüne geçilmesine, termal kaçak (thermal runaway) risklerinin ise erken tespit edilmesine ve azaltılmasına yardımcı olur.

Projeksiyon (Projection) ile Kod Sıkıştırma ve Donanıma Gömme

Yapay zeka modellerinin gömülü işlemcilerde (NXP S32K, TI C2000 vb.) çalıştırılabilmesi için Deep Learning Toolbox bünyesindeki projeksiyon ve ağ sıkıştırma (Projection / Network Compression) yöntemlerinden yararlanılabilir.

Ardışık bir LSTM ağında projeksiyon ve ağ budama (pruning) teknikleri uygulandığında, modelin tahmin doğruluğu (RMSE) korunurken gömülü donanım açısından şu kazanımlar elde edilebilir:

1. Bellek Kullanımı Azalımı: Örnek çalışmalarda, modelin RAM/Flash üzerinde kapladığı alanın önemli ölçüde azaltılabildiği gösterilmiştir.

2. Çıkarım Gecikmesi Azalımı: Örnek çalışmalarda, işlemci üzerindeki hesaplama süresinin %40 oranında kısaltılabildiği gösterilmiştir.

Embedded Coder aracılığıyla bu sıkıştırılmış modeller, harici derin öğrenme kütüphanelerine bağımlılığı azaltacak şekilde optimize C/C++ kodlarına dönüştürülebilir. Hedef donanım entegrasyonu için bellek kullanımı, örnekleme zamanı ve desteklenen kod üretimi seçenekleri proje ve MATLAB & Simulink sürümü özelinde ayrıca değerlendirilmelidir.

SIL, PIL ve HIL ile Gömülü Doğrulama

MIL, SIL ve PIL Doğrulama Aşamaları

Geliştirilen yazılımın fiziksel donanımla buluştuğu aşama, V-modelinin en kritik doğrulama adımıdır.

  • MIL (Model-in-the-Loop): Algoritmaların fiziksel batarya paketi modeli (Simscape) ile kapalı çevrim olarak bilgisayar ortamında simüle edilmesini ve sistem davranışının erkenden doğrulanmasını destekler.
  • SIL (Software-in-the-Loop): Embedded Coder tarafından üretilen C kodları bilgisayar üzerinde derlenerek Simulink modeliyle yan yana çalıştırılır. Çıktıların model davranışıyla tutarlı olduğu doğrulanarak kod-model eşdeğerliği değerlendirilir.
  • PIL (Processor-in-the-Loop): Kod, USB kablosuyla bağlı olan bir TI Launchpad veya NXP S32K kartına yüklenir. Algoritmaların gerçek işlemci mimarisi üzerindeki çalışma süreleri (profiling) mikrosaniye hassasiyetinde ölçülür.

HIL Test Ortamı ve Gerçek Zamanlı Doğrulama

  • HIL (Hardware-in-the-Loop): Fiziksel işlemci kartı, gerçek batarya hücreleri yerine hücre voltajlarını ve sıcaklıklarını milivolt düzeyinde taklit eden bir Speedgoat gerçek zamanlı hedef bilgisayarına bağlanarak ekstrem arıza ve kısa devre senaryoları altında güvenle test edilir.

Şekil 5. SIL, PIL ve HIL adımlarıyla BMS yazılımının model, işlemci ve gerçek zamanlı test ortamlarında doğrulanması.

Hata Senaryoları ve Test Kapsamı

  HIL testlerinde yalnızca nominal sürüş ve şarj senaryoları değil; aşırı/düşük hücre gerilimi, aşırı sıcaklık, sensör kopması, kontaktör takılı kalması, haberleşme kesintisi ve akım sınırı ihlali gibi hata senaryoları da kontrollü şekilde değerlendirilir. Bu sayede BMS yazılımının güvenli durum yönetimi ve hata tepkileri fiziksel batarya paketine zarar vermeden test edilebilir.

Sertifikasyon Süreçlerine Hazırlık ve Doğrulama Kontrol Noktaları

Yazılım sahaya çıkmadan önce, ilgili uluslararası standartlara (ISO 26262, DO-178C, IEC 61508) uyumun değerlendirilmesi ve gerekli doğrulama kanıtlarının hazırlanması önem taşır.

  • Simulink Check ve Model Advisor: Geliştirilen model yapısı, MAAB (MathWorks Automotive Advisory Board) ve yüksek bütünlüklü sistem kurallarına göre taranarak tasarım hatalarının henüz model aşamasındayken tespit edilmesini destekler.
  • Simulink Coverage: SIL/PIL testleri sırasında modelin ve üretilen kodun ne kadarının çalıştırıldığı ölçülür. Test edilmemiş alanlar ve “ölü kod” (Dead Code) parçaları raporlanarak doğrulama kapsamının iyileştirilmesine katkı sağlar.
  • Polyspace Code Prover: Polyspace Code Prover, C/C++ kodunu çalıştırmadan analiz ederek MISRA-C gibi kodlama kurallarına uyumu denetler; sıfıra bölünme, taşma ve sınır dışı dizi erişimi gibi belirli çalışma zamanı hata sınıfları için kanıt temelli analiz sonuçları üretir.
  • Simulink Design Verifier (SLDV): Sistemin girmemesi beklenen tehlikeli durumları formal metotlar kullanarak analiz eder ve tasarım sınırlarının doğrulanmasına yardımcı olur.

Sertifikasyon süreçlerinde kullanılabilecek teknik kanıt dosyaları, araç kalifikasyon iş akışlarına göre yapılandırılabilir:

“ISO 26262 ve IEC 61508 gibi fonksiyonel güvenlik standartları için IEC Certification Kit; DO-178C gibi havacılık yazılım süreçleri için ise DO Qualification Kit, MathWorks araçlarının kalifikasyon süreçlerinde kullanılabilecek dokümantasyon ve referans iş akışları sağlar.”

Sonuç

Model Tabanlı Tasarım; batarya hücresinin karmaşık elektro-termal fiziğini, akıllı durum kestirim algoritmalarını, yapay zekânın kestirimci gücünü ve gömülü donanım sürücülerini tek bir dijital platformda birleştirir. Manuel kod yazma hatalarını en aza indiren, donanım bağımlılığını azaltan, farklı hedef platformlara geçişi kolaylaştıran ve test/doğrulama adımlarının önemli bir bölümünü erken geliştirme aşamalarına taşıyan bu bütünsel MathWorks iş akışı, enerji şebekelerinden havacılık ve uzay sistemlerine kadar uzanan geniş bir yelpazede yüksek güvenilirlikli ve sertifikasyon süreçlerine hazırlanabilir BMS yazılımı geliştirmek için güçlü ve bütünleşik bir yaklaşım sunar.

Uygulamalı Demo Notu: FİGES’in “NXP S32K144 Kullanılarak Model Tabanlı Batarya Yönetim Sistemi (BMS) Prototipleme” demo çalışması, Model Tabanlı Tasarım yaklaşımının hedef donanım üzerinde nasıl kurgulanabileceğini gösteren uygulamalı bir örnek olarak ayrıca incelenebilir.

Bu demo çalışması, NXP S32K144 tabanlı bir hedef donanım üzerinden örneklenmiş olmakla birlikte, yazıda ele alınan Model Tabanlı Tasarım yaklaşımı; farklı mikrodenetleyici, AFE ve HIL platformlarına uyarlanabilir genel bir BMS geliştirme metodolojisi olarak değerlendirilmelidir.

Batarya Yönetim Sistemleri İçin Uygulamalı Kaynaklara Erişin

Model Tabanlı Tasarım yaklaşımıyla BMS geliştirme süreçlerini destekleyen uygulamalı içerikler, teknik dokümanlar, videolar ve örnek projelere ulaşmak için aşağıdaki formu doldurabilirsiniz.

Ek Uygulamalı Kaynaklar ve Demo Materyalleri

Model Tabanlı Tasarım ile Batarya Yönetim Sistemi Geliştirin

Model Tabanlı Tasarım ile Batarya Yönetim Sistemi Geliştirin

Gereksinimlerden mimari tasarıma, Simscape Battery plant modeline ve test adımlarına uzanan bütünsel BMS geliştirme yaklaşımını örnekler.

Kullanım Amacı:
Uçtan uca MBD/MBSE iş akışını görmek

Stateflow ile Batarya Yönetim Sistemini Modelleyin

Stateflow ile Batarya Yönetim Sistemini Modelleyin

Kontaktör yönetimi, hata durumları, şarj/deşarj kontrolü ve güvenli durum geçişleri gibi karar tabanlı BMS fonksiyonlarını model seviyesinde gösterir.

Kullanım Amacı:
Stateflow tabanlı BMS kontrol mantığını incelemek

Lityum-İyon Batarya Yönetim Algoritmalarını Tasarlayın ve Test Edin

Lityum-İyon Batarya Yönetim Algoritmalarını Tasarlayın ve Test Edin

SOC kestirimi, hücre dengeleme, kontaktör yönetimi, hata yönetimi ve Simulink Test senaryolarını içeren uygulamalı bir referans çalışma sunar.

Kullanım Amacı:
Uygulamalı algoritma ve test örneği incelemek

© FİGES A.Ş. Tüm hakları saklıdır.