Etiket: hev/ev

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.