Araç Artık Yazılımla mı Tanımlanıyor? Domain Mimarisi ve SDV Dönüşümü

Elektrikli Otomobil Teknolojileri
Yazar: Deniz Erkan
Oluşturma: 14 Ekim 2026

Yüzü aşkın kontrol birimini birkaç zonal kontrolöre indiren mimari, arabanın kimliğini artık çelikten değil koddan üretiyor.

Bu Sayfayı Paylaşın

Evet: modern otomobilin davranışı, özellikleri ve performans karakteri artık öncelikli olarak yazılımla tanımlanıyor. Yazılım tanımlı araç (SDV) olarak adlandırılan bu dönüşüm, aracın elektronik mimarisini ECU yığınlarından domain ve zonal kontrolörlere taşıyarak donanım ile yazılımı birbirinden ayırıyor ve kablolama ağırlığından OTA güncellemelerine kadar her şeyi yeniden şekillendiriyor.

Öne Çıkanlar

Günümüz araçları 100 ve üzeri kontrol birimi içerebiliyor; yeni mimariler bu sayıyı %20'ye kadar azaltmayı hedefliyor.
Domain mimarisi işleve, zonal mimari fiziksel konuma göre organize eder.
Zonal topolojide CAN XL (20 Mbps'ye kadar) ve gigabit Ethernet gibi yüksek bant genişlikli omurgalar kullanılıyor.
OTA güncellemesi, donanım-yazılım ayrışması sayesinde mümkün olan temel bir SDV yeteneğidir.
Geçiş kademeli: ilk alan gövde (body) domaini; ADAS, powertrain ve şasi daha uzun süre mevcut yapıda kalabilir.

Yazılım Tanımlı Araç Tam Olarak Nedir?

Tanım net: yazılım tanımlı araç, işlevselliği ve davranışı öncelikli olarak donanımdan ziyade yazılımla belirlenen araçtır. Geleneksel otomobilde bir özellik, o işleve özel üretilmiş bir donanım parçasıyla tanımlanırdı; SDV'de aynı donanım, üstünde koşan yazılımla farklı işlevlere bürünebilir. Araç satıldıktan sonra bile yeni özellikler eklenebilir, davranış kalibre edilebilir, hatalar uzaktan düzeltilebilir.

Günümüz E/E mimarileri 100 ve üzeri kontrol biriminden oluşuyor; yeni nesil yapılar kontrol birimi sayısında %20'ye kadar, malzeme ve donanımda %10'a kadar tasarruf sağlıyor.
Bosch Mobility, E/E mimarisi değerlendirmesi

Bu cümlenin taşıdığı rakamlar, dönüşümün ölçeğini özetliyor. Sorun yalnızca kontrol birimi sayısı değil: her ECU kendi kablolamasını, kendi yazılım yığınını ve kendi doğrulama yükünü getiriyor. SDV vizyonu, bu dağınık yapıyı yazılımın tek bir tutarlı katmanda yönetebildiği bir sisteme dönüştürmek. Bunun için de elektronik mimarisinin baştan kurgulanması gerekiyor.

ECU'lerden Domain Mimarisi: İşleve Göre Gruplama

Bir otomobildeki her küçük işlevin ayrı bir elektronik kontrol ünitesine (ECU) sahip olduğu dönem, kablolama demetlerini yönetilemez hale getirdi. Domain mimarisi bunun ilk sistematik yanıtı oldu: araç elektroniklerini ADAS, infotainment, güç aktarımı (powertrain), gövde elektronikleri, şasi ve güvenlik gibi büyük işlevsel alanlara göre organize eder. Her domain genellikle kendi işlemcisine, yazılım yığınına, iletişim arayüzüne, sensör ve aktüatörlerine sahiptir ve bir domain kontrolörü tarafından yönetilir.

Bu yapı, ECU kaosuna göre ciddi bir düzleştirme sağladı. Ancak SDV hedefi büyüdükçe domain mimarisinin sınırları ortaya çıktı. Özellikle otonom işlevlerin ürettiği sensör verisi, klasik CAN ağlarının bant genişliğini sınırlarına itti. Ayrıca her domainin kendi işlem kaynağını taşıması, kablolama demetini karmaşık bıraktı ve yazılımın araç genelinde ölçeklenmesini zorlaştırdı.

Zonal Mimarisi: Organizasyon İşlevden Konuma Geçiyor

Zonal mimari mantığı tersine çevirir: elektronikleri işleve göre değil, araçtaki fiziksel konuma göre gruplar. Araç ön sol, ön sağ, arka sol, arka sağ ve kabin gibi bölgelere ayrılır; her bölgede bir zonal kontrolör, o bölgedeki sensörleri, aktüatörleri ve güç dağıtımını toplar ve merkezi yüksek performanslı işlem platformlarıyla haberleştirir.

Özellik	Domain mimarisi	Zonal mimarisi
Organizasyon ilkesi	İşleve göre (powertrain, ADAS, gövde...)	Fiziksel konuma göre (ön sol, arka sağ...)
İşlem kaynakları	Domain-özel işleme	Birleştirilmiş merkezi/dağıtık işlem
Kablolama	Karmaşık, uzun kablo demeti	Azaltılmış kablolama ve ağırlık
ECU sayısı	Çok sayıda ECU	Az sayıda zonal kontrolör + merkezi bilgisayar
Yazılım esnekliği	SDV için ölçeklenmesi zor	Yüksek yazılım esnekliği

Kazanç somut ve ölçülebilir: kablo demeti ağırlığı düşer, nokta-nokta bağlantılar azalır, araç mimarisi ve sistem doğrulama çabası sadeleşir. Daha önemlisi, sensör ve aktüatör tasarımları merkezi işlem düğümünden bağımsızlaşır; böylece donanım ve yazılım güncelleme döngüleri ayrışır ve bir sensör tasarımı birden fazla araç nesli boyunca kullanılabilir.

Zonal Kontrolör Ne İş Yapar? Görev Dağılımı ve Donanımla İlişkisi

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

Zonal mimarinin anahtarı, çok sayıda aktüatör ve sensörü merkezi işlem ECU'suna bağlamaktan sorumlu zonal kontrolördür. Bu kontrolör yalnızca veri toplama kutusu değildir; gerçek zamanlı kontrol döngülerini kendi üzerinde koşturabilir, bölgesindeki cihazları yönetebilir ve omurgaya filtrelenmiş, önceliklendirilmiş trafik gönderir. Ti kaynaklı mühendislik değerlendirmesine göre zonal modülün MCU'su yüksek gerçek zamanlı performans, geniş bellek, farklı ASIL seviyeleri için sanallaştırma desteği, omurgaya yüksek hızlı iletişim ve CAN FD, LIN gibi düşük maliyetli çok sayıda uç arayüz sunmalıdır.

Güç dağıtımı nasıl merkeziyetsizleşiyor?

Domain mimarisinde güç, eritici sigortalar ve röleler içeren merkezi güç dağıtım kutularından dağıtılır. Zonal yapıda dağıtım merkeziyetsizleşir: tek güç demeti bataryadan bölgeye çekilir, zone modülü gücü o bölgedeki modüllere paylaştırır. Kısa güç kabloları doğrudan ağırlık ve maliyet tasarrufu demektir. Ayrıca eritici sigortaların yerini yarı iletken tabanlı akıllı sigortalar alır; I²t karakteristikli yüksek taraf anahtarları, daha az sigorta değişkenliği ve daha optimize kablo kesitleri sağlar. MCU, yüksek taraf anahtarları ve transceiver'lardan oluşan akıllı güç dağıtım kutusu, yapılandırması yazılımla yapılan bir birim haline gelir: aynı kutu her zonada, yüke göre uyarlanarak kullanılabilir.

Fiziksel ve mantıksal G/Ç'nin ayrışması

Zonal modül, birden çok ECU'nun mantıksal giriş/çıkış işlevlerini tek noktada birleştirerek kablo karmaşıklığını azaltır; sensör ve aktüatörlerin fiziksel konumları ise korunur. Bir adım ötesinde uç cihazlar "akıllı" hale gelir: yerel devre, durum bilgisini korur ve arıza teşhisi çalıştırır. CAN FD Light gibi basitleştirilmiş protokoller, bazı uç düğümlerde ayrı bir MCU ihtiyacını bile kaldırabilir. Donanım sabit kalıp görevin yazılımla tanımlandığı bu ayrışma, SDV'nin mühendislik omurgasıdır.

Zonal Araçta Veri Yolu: Bant Genişliği, Zamanlama ve Siber Güvenlik

Sensör füzyonu ve AI iş yükleri, zonal topolojiyi yüksek bant genişlikli omurgalar üzerine kurmayı zorunlu kılar: PCIe, 20 Mbps'ye kadar veri hızına ulaşan ve mevcut CAN uyumluluğunu koruyan CAN XL ve gigabit Ethernet. Asıl zorluk bant genişliğinden öte zamanlamadadır; kısa kontrol mesajları, ADAS sensör verisi ve infotainment trafiği birbirinden çok farklı gecikme, jitter ve senkronizasyon gereksinimleri taşır. Kaba ölçüler şu: ses için milisaniye düzeyi, güç aktarımı ve şasi kontrolü için mikro saniye düzeyi gecikme hedefleri geçerlidir.

Bu farklı trafik sınıflarını tek ağda taşımak için Ethernet tabanlı Time-Sensitive Networking (TSN) çözüm olarak öne çıkar. Zaman senkronizasyonu (IEEE 802.1AS), zaman duyarlı trafik şekillendirme (802.1Qbv), express trafik (802.3br), frame pre-emption (802.1Qbu) ve yedeklilik (802.1CB) gibi standartlar, kritik veriye deterministik gecikme garantisi verir. Güvenlik tarafında ise ISO 26262 desteği, yedekli iletişim yolları, güvenlik bölümleme ve arıza tespiti; siber güvenlik tarafında ISO/SAE 21434 standardı, UNECE düzenlemeleri ve MACsec gibi düşük seviye şifreleme-kimlik doğrulama mekanizmaları belirleyicidir. Zonal mimari ağları merkezileştirdiği için Ethernet tabanlı saldırı yöntemleri de uygulanabilir hale gelir; güvenlik ihlalinde G/Ç-işlem ayrışması kavramının çökmesi, tek tek değerlendirilmesi gereken bir risktir.

Donanım-Yazılım Ayrışması OTA Güncellemesini Nasıl Mümkün Kılar?

OTA güncellemesi, çoğu SDV tartışmasında ilk akla gelen özellik, ama tek başına bir yetenek değil; bir mimari sonucudur. Yazılım, donanım soyutlama katmanı (HAL) aracılığıyla belirli çiplerden ayrıştırılmadan ve araç işlevleri bağımsız, yeniden kullanılabilir, gevşek bağlı hizmetlere bölünmeden (servis odaklı mimari, SOA) kesintisiz güncelleme sağlanamaz. Ayrıştırma aynı zamanda farklı güvenlik seviyelerindeki yazılımların birbirinden izolesini de kapsar.

Somut anlamı şu: zone mimarisi, OTA/FOTA güncellemeleri ve sürekli bulut bağlantısıyla üst düzey yazılım bakımının kontrolünü üreticiye verirken, gerçek zamanlı kontrol döngülerini zone modüllerine kaydırabilir. Elektrikli araçlarda kullanılmayan modüllerin güçlendirilmesi gibi ince ayarlar da bu yapıda kolaylaşır. Nihayetinde elektrikli araç yazılımı, bir güncelleme kanalı olmanın ötesinde, aracın özelliklerini, güvenlik sistemlerini ve performans karakterini belirleyen tanım katmanıdır. Araç, tekerlekler üzerinde dağıtık bir veri merkezine benzemeye başlar; değer zinciri yazılıma, işlem gücüne ve sistem mimarisine yaslanır.

Geçiş Ne Kadar Hızlı Olacak ve Yalnız Zonal Mimari Yeter mi?

Geçiş kademeli olacak. Gövde (body) domaini, çok sayıda dağıtık aktüatör ve sensör ECU'su içerdiği için zone mimarisine geçecek ilk alan; ADAS, powertrain ve şasi kontrolünün geçişi ise güvenlik-kritik doğası nedeniyle daha fazla zaman alabilir. 2017'den bu yana MCAL, BSW ve uygulama katmanlarında yaşanan evrim, bunun teknik bir proje değil sektör çapında bir zihniyet değişimi olduğunu gösteriyor.

Dengeli okumak da gerekiyor. Zonal mimari aracı fiziksel olarak yeniden organize eder; mantıksal ve yazılım tarafının (SOA, HAL, siber güvenlik) ayrıca çözülmesi gerekir - yalnızca kabloları yeniden düzenlemek bir aracı yazılım tanımlı yapmaz. Pazar büyüklüğü tahminleri de kapsam tanımlarına göre ciddi biçimde değişiyor; E/E mimarisi pazarına ilişkin farklı rakamlar, pazarın nelerin (yalnızca işlem platformları mı, yoksa tüm dağıtık elektronik mi) sayıldığına göre farklı ölçülmesinden kaynaklanıyor. Ayrıca geçişin tarafları olan yarı iletken ve çözüm sağlayıcıların bu dönüşüme doğal olarak taraf olduğu unutulmamalı.

Sonuç, net bir mühendislik dengesi: aracın yazılımla tanımlanması, tek bir yazılım projesi değil, domain ve zonal kontrolörlere dayalı yeni bir donanım organizasyonu, ayrıştırılmış yazılım katmanları ve deterministik, güvenli bir veri omurgasının aynı anda var olmasıyla mümkün. OTA güncellemesi bu bütünleşik yapının en görünür meyvesi; asıl devrim, aracın donanımının görev tanımını yazılıma devretmesinde.