AD-29 — Gelecek Nesil Mimariler: Merkezi Compute, Zonal E/E ve Ethernet

FACT — Tek bir 8 megapiksel ADAS kamerası, sıkıştırılmamış ham piksel akışında saniyede yaklaşık $4\text{ Gbps}$ veri üretir. Klasik bir CAN veri yolu ise saniyede en fazla $1\text{ Mbps}$ (CAN-FD ile pratikte birkaç Mbps) taşıyabilir — yani TEK bir kameranın ham çıktısı, klasik CAN’ın kapasitesinin BİNLERCE katıdır. Bu tek rakam, otomotiv endüstrisinin neden onlarca yıllık dağıtık E/E mimarisini kökten değiştirmek zorunda kaldığını özetler.

Bu derste şunları öğreneceksin:

1. Neden Geleneksel Dağıtık E/E Mimarisi Bir Darboğaza Dönüştü
2. Üç Aşamalı Evrim: Dağıtık → Domain → Zonal
3. Merkezi Araç Bilgisayarı (Central Compute / HPC) Mimarisi
4. Zonal E/E Mimarisi: Bölgeye Göre, Fonksiyona Göre Değil
5. Neden Ethernet: CAN’ın Fiziksel Sınırları vs Paket Anahtarlamalı Ağ
6. Automotive Ethernet Standartları ve TSN (Time-Sensitive Networking)
7. Ham Sensör Verisi İletimi: SerDes ve MIPI A-PHY
8. Karma Mimari: CAN/CAN-FD Neden Tamamen Ortadan Kalkmıyor
9. Vaka İncelemesi: Endüstrinin Geçiş Aşaması

---

1. Neden Geleneksel Dağıtık E/E Mimarisi Bir Darboğaza Dönüştü

Geleneksel bir aracın Elektrik/Elektronik (E/E) mimarisi, her fonksiyon için ayrı bir ECU felsefesine dayanır: ABS için bir ECU, cam açma-kapama için başka bir ECU, adaptif hız sabitleyici için bir başkası. Üretim araçlarında bu sayı 100’ü, üst segment araçlarda 150’yi aşabilir — her biri birbirine kilometrelerce uzunlukta CAN/LIN kablosuyla bağlıdır.

Bu mimari, ADAS/AD işlem yükü için ikili bir darboğaza dönüşür:

• Bant genişliği darboğazı: AD-04 — ADAS Sensörleri dersinde işlediğimiz kamera, radar ve LiDAR sensörlerinin her biri saniyede yüzlerce megabit ila birkaç gigabit ham veri üretir. Klasik CAN’ın $1\text{ Mbps}$, CAN-FD’nin ise pratikte birkaç Mbps’lik kapasitesi, tek bir yüksek çözünürlüklü sensörün çıktısını bile taşımaya yetmez.
• Hesaplama gücü darboğazı: Dağıtık mimaride her ECU kendi küçük mikrodenetleyicisiyle SINIRLI bir görevi (örn. “bu radarın ham verisinden nesne listesi çıkar”) yerine getirir. Ama modern derin öğrenme tabanlı algılama/planlama, AD-07 — Sensor Fusion: Erken, Geç ve Derin Füzyon Mimarileri dersinde işlediğimiz gibi ham sensör verisini erken/derin katmanlarda BİRLEŞTİRMEYİ gerektirir — bu da onlarca dağınık küçük işlemci yerine, TEK bir merkezi ve çok güçlü hesaplama platformunu zorunlu kılar.

CRITICAL — Bu iki darboğaz birbirini besler: erken/derin sensör füzyonu yapabilmek için ham veriyi TEK bir yerde toplamanız gerekir (hesaplama gerekçesi), ama ham veriyi tek bir yerde toplamak da yüksek bant genişlikli bir omurga gerektirir (bant genişliği gerekçesi). Klasik dağıtık mimari her ikisini de sağlayamaz — bu yüzden mimari değişikliği isteğe bağlı bir modernizasyon değil, ADAS/AD’nin teknik ön koşuludur.

---

2. Üç Aşamalı Evrim: Dağıtık → Domain → Zonal

Araç E/E mimarileri üç büyük evrimsel aşamadan geçer:

[ 1. Dağıtık (Distributed) ]      [ 2. Etki Alanı (Domain) ]        [ 3. Zonal + Merkezi Compute ]

 +----+  +----+  +----+  +----+      +-------------------+              +--------------------+
 |ECU1|  |ECU2|  |ECU3|  |ECUn|      |  ADAS Domain      |              |   MERKEZİ COMPUTE  |
 +----+  +----+  +----+  +----+      |  Controller       |              |   (HPC / "Beyin")  |
   |       |       |       |         +-------------------+              +--------------------+
  (100+ ayrık mikrodenetleyici,               |                              | (Multi-Gig Ethernet)
   her biri kendi kablo hattıyla)     (Fonksiyonel ayrım:        +-----------------+-----------------+
  - Ağır, uzun kablo demetleri         ADAS / Kokpit / Gövde)    |                 |                 |
  - Düşük bant genişlikli CAN/LIN             |                 Ön Zonal      Sol Zonal       Arka Zonal
                                       Kablolar hâlâ araç         Gateway       Gateway         Gateway
                                       boyunca uzanır                |             |                |
                                                                  S1 S2 Akt   S3 S4 Akt        S5 S6 Akt

1. Dağıtık Mimari: Her fonksiyon ayrı bir kutu. Kablo ağırlığı 70 kg’ı aşabilir, tüm sistemin OTA ile güncellenmesi pratikte imkânsıza yakındır.
2. Domain Mimarisi: Fonksiyonlar mantıksal alanlara toplanır (ADAS Domain, Infotainment Domain, Body Domain). Bir adım ileri, ama kablolar hâlâ aracın önünden arkasına, sensörden domain kontrolcüsüne kadar boydan boya uzanır.
3. Zonal Mimari: Fiziksel KONUMA göre gruplama (Ön Sol, Ön Sağ, Arka bölge). Her bölgedeki zonal gateway o bölgenin tüm sensör/aktüatörlerini toplar, veriyi paketler ve tek bir yüksek hızlı Ethernet omurgası üzerinden merkezi compute’a iletir.

---

3. Merkezi Araç Bilgisayarı (Central Compute / HPC) Mimarisi

Merkezi bilgisayar platformu (örnek sınıf: NVIDIA DRIVE ailesi, Qualcomm Snapdragon Ride ailesi), önceden onlarca ayrı ECU’da dağınık duran mantığı tek bir güçlü SoC (System-on-Chip) üzerinde birleştirir:

• Heterojen çekirdek yapısı:
  • CPU kümesi — genel işletim sistemi, yol planlama ve karar mantığı.
  • GPU/NPU hızlandırıcı — derin öğrenme tabanlı algılama ve AD-07’de işlenen erken/derin füzyon modelleri; yüzlerce ila binlerce TOPS (int8) mertebesinde işlem gücü.
  • Safety Island — ASIL-D seviyesinde donanımsal kilit-adımlı (lock-step) çalışan, ana yapay zeka çökse bile minimum risk manevrasını (bkz. AD-17 — Fallback Stratejileri, MRM ve Emniyetli Durum) garanti eden ayrı, izole gerçek zamanlı çekirdekler.
• Donanımsal sanal izolasyon (Hypervisor): Gösterge paneli gibi güvenlik-kritik yazılım ile eğlence sistemi aynı SoC üzerinde, ama donanımsal olarak izole sanal makinelerde çalışır — birinin çökmesi diğerini etkilemez.

Merkezi compute, önceki bölümde tanımlanan ikinci darboğazın (hesaplama gücü) doğrudan çözümüdür: dağıtık mimaride imkânsız olan erken/derin sensör füzyonu, artık ham veri tek bir çipe ulaştığı için mümkündür.

---

4. Zonal E/E Mimarisi: Bölgeye Göre, Fonksiyona Göre Değil

Zonal mimarinin temel fikri basittir ama sonuçları derindir: aracın elektrik mimarisini fonksiyona göre değil, fiziksel BÖLGEYE göre organize etmek.

Klasik/domain mimaride, “ön sol far” gibi bir aktüatör, kendi fonksiyonel ECU’suna (Body Domain Controller) kadar — aracın neresindeyse — ayrı bir kablo hattıyla uzanır. Zonal mimaride ise o aynı far, fiziksel olarak en yakınında bulunan Ön Sol Zonal Gateway’e kısa bir kabloyla bağlanır; o bölgedeki TÜM sensör/aktüatörler (farlar, camlar, yakın kameralar, ultrasonik sensörler) aynı gateway’e toplanır ve gateway bunları TEK bir yüksek hızlı bağlantı üzerinden merkezi compute’a iletir.

Zonal Gateway'in Topladığı Bileşenler (Ön Sol Bölge Örneği):

  Far ──┐
  Cam Motoru ──┤
  Yakın Kamera ──┼──▶ [ ÖN SOL ZONAL GATEWAY ] ──(Multi-Gig Ethernet)──▶ [ MERKEZİ COMPUTE ]
  Ultrasonik x2 ──┤
  Kapı Kilidi ──┘

Bu yeniden organizasyonun kazancı doğrudan geometrikdir: her bileşen artık aracın öbür ucundaki bir kontrolcüye değil, birkaç santimetre-birkaç metre ötesindeki bölgesel gateway’e bağlanır. Sonuç, toplam kablo UZUNLUĞUNDA ve dolayısıyla ağırlığında belirgin bir azalmadır — saf yıldız topolojisiyle (her ECU’ya ayrı ayrı) her bileşeni doğrudan merkezi bilgisayara bağlamaya kıyasla de belirgin bir tasarruftur, çünkü zonal gateway yerel toplama/paketleme yaparak omurgada taşınan bağlantı sayısını azaltır.

FACT — Endüstri raporlarında sıkça atıfta bulunulan mertebe, zonal mimariye geçişin kablo demeti ağırlığını belirgin ölçüde (üretici ve platforma göre değişen, kabaca onlarca kilogram mertebesinde) azaltabildiğidir. Bir elektrikli araçta bu ağırlık kazancı doğrudan menzile yansır; ayrıca daha kısa, daha standart kablo segmentleri üretim hattında robotik montajı kolaylaştırır. Kesin rakamlar üretici/platforma göre büyük ölçüde değişir.

---

5. Neden Ethernet: CAN’ın Fiziksel Sınırları vs Paket Anahtarlamalı Ağ

CAN (Controller Area Network), 1980’lerde kısa, düşük bant genişlikli kontrol mesajları (örn. “fren pedalı %40 basılı”, “motor devri 2400 rpm”) için tasarlandı — mesaj başına birkaç bayt, yayın (broadcast) tabanlı, önceliklendirilmiş arbitrasyon. Bu tasarım felsefesi, ADAS/AD’nin ihtiyaç duyduğu sürekli, yüksek hacimli akış verisiyle (kamera karesi, LiDAR nokta bulutu) temelden uyumsuzdur:

• CAN’ın veri alanı mesaj başına en fazla 8 bayt (klasik CAN) ya da 64 bayt (CAN-FD) ile sınırlıdır — bir görüntü karesini CAN mesajlarına bölmek pratik değildir.
• CAN yayın tabanlıdır (bus üzerindeki her düğüm her mesajı görür); bu küçük kontrol mesajları için verimlidir ama nokta-nokta yüksek hacimli akışlar için israftır.

Automotive Ethernet ise doğası gereği paket anahtarlamalı (packet-switched) bir ağdır — veri, hedefine göre adreslenmiş paketler halinde, sadece ilgili bağlantı üzerinden yönlendirilir. Bu, streaming sensör verisiyle (sürekli, yüksek hacimli, noktadan noktaya) doğal bir eşleşmedir:

$\text{CAN klasik: } \sim 1\text{ Mbps} \qquad \text{CAN-FD: birkaç Mbps} \qquad \text{Automotive Ethernet: } 10\text{ Mbps} - 10+\text{ Gbps}$

INTERPRETATION — Bu bir “CAN kötü, Ethernet iyi” meselesi değildir — ikisi farklı problemler için tasarlanmıştır. CAN, mikrosaniyeler mertebesinde deterministik, düşük gecikmeli, KISA kontrol mesajları için hâlâ mükemmel uyumludur (bkz. §8). Ethernet ise CAN’ın hiç tasarlanmadığı bir problemi — sürekli yüksek hacimli sensör akışını — çözer. Endüstrinin yöneldiği mimari CAN’ın Ethernet’le TAMAMEN yer değiştirmesi değil, her protokolün kendi güçlü olduğu görevde kullanıldığı bir KARMA (hybrid) ağdır.

---

6. Automotive Ethernet Standartları ve TSN (Time-Sensitive Networking)

Standart	Hız	Kablo Tipi	Tipik Otomotiv Kullanımı
10BASE-T1S	10 Mbps	Tek bükümlü tel (single pair)	Düşük hızlı gövde sensörleri, klasik LIN’in yerini alan uygulamalar
100BASE-T1	100 Mbps	Tek bükümlü tel (UTP)	Çevre görüş kameraları, telematik
1000BASE-T1	1 Gbps	Korumalı tek bükümlü tel (STP)	Yüksek çözünürlüklü LiDAR akışı, zonal gateway omurgası
Multi-Gig (IEEE 802.3ch)	2.5 / 5 / 10 Gbps	Korumalı STP / koaksiyel	Zonal gateway ↔ merkezi compute yüksek hızlı omurga

TSN (Time-Sensitive Networking)

Standart ticari Ethernet “en iyi çaba” (best-effort) prensibiyle çalışır — gecikme garantisi vermez, paketler ağ yoğunluğuna göre gecikebilir. Bu, acil fren gibi zaman-kritik ADAS mesajları için kabul edilemez. TSN protokol ailesi Ethernet’e deterministik davranış kazandırır:

• IEEE 802.1AS (gPTP): Araçtaki tüm sensör/ECU saatlerini mikrosaniyenin altında senkronize eder — bu, AD-07 dersinde işlenen sensör füzyonunun ön koşuludur (zamansal hizalama olmadan füzyon güvenilmezdir).
• IEEE 802.1Qbv (Time-Aware Shaper): Kritik mesajlar için ağda zaman pencereleri ayırır; eğlence sistemi verisi hatta olsa bile fren mesajı beklemeden geçer.

---

7. Ham Sensör Verisi İletimi: SerDes ve MIPI A-PHY

Bir 8 megapiksel ADAS kamerası saniyede yaklaşık $4\text{ Gbps}$ ham piksel verisi üretir. Bu veri sıkıştırılırsa görüntüde yapaylıklar (artifacts) oluşur ve kod çözme gecikmesi (codec latency) eklenir — algılama gecikmesine duyarlı bir sistem için istenmeyen bir ödünleşimdir. Bu nedenle sıkıştırmasız ham veri aktarımı için özel SerDes (Serializer/Deserializer) fiziksel katmanları kullanılır:

• MIPI A-PHY ve ASA (Automotive SerDes Alliance): Sensör lensinden çıkan ham CSI-2 piksel akışını tek bir koaksiyel kablo üzerinden 15 metreye kadar mesafede, 16 Gbps mertebesinde hızla doğrudan merkezi compute’un belleğine akıtan standartlardır.

---

8. Karma Mimari: CAN/CAN-FD Neden Tamamen Ortadan Kalkmıyor

§5’te işlendiği gibi, CAN’ın zayıflığı (düşük bant genişliği) aynı zamanda belirli bir görev sınıfında güçlü yanıdır: mikrosaniyeler mertebesinde deterministik, kısa, güvenlik-kritik kontrol mesajları.

• Fren komutu, direksiyon açısı komutu gibi düşük veri hacimli ama ÇOK düşük gecikme ve yüksek güvenilirlik gerektiren mesajlar için CAN/CAN-FD’nin basit, iyi anlaşılmış, onlarca yıllık saha geçmişi olan mimarisi hâlâ tercih edilir.
• Ethernet’in paket anahtarlamalı doğası ve daha karmaşık protokol yığını, TSN ile deterministik hale getirilse bile, CAN’ın basitliğiyle aynı düzeyde bir doğrulama/sertifikasyon geçmişine henüz sahip değildir.

WARNING — Bu dersin ana fikri “Ethernet CAN’ın yerini alıyor” değil, “Ethernet CAN’ın YAPAMADIĞI işi (yüksek hacimli sensör akışı) üstleniyor, CAN ise YAPTIĞI işte (düşük hacimli, ultra-güvenilir kontrol) kalmaya devam ediyor” şeklinde okunmalıdır. Sonuç, çoğu modern zonal mimaride CAN-FD ve Ethernet’in BİRLİKTE, farklı görevlerde çalıştığı karma (hybrid) bir ağ topolojisidir — CAN’ın tamamen terk edildiği bir mimari, güncel endüstri pratiğinde yaygın değildir.

---

9. Vaka İncelemesi: Endüstrinin Geçiş Aşaması

ASSUMPTION — Bu bölümdeki üretici-özgü mimari yaklaşımları, kamuya açık teknik basın açıklamalarına ve endüstri konferans sunumlarına dayanır; belirli bir üreticinin belirli bir model yılındaki TAM zonal/merkezi mimari uygulama detayları resmi teknik dokümantasyonla teyit edilmemiştir. Bu örnekler kavramsal illüstrasyon amaçlıdır, kesin/güncel mimari için üreticinin kendi teknik yayınlarına bakılmalıdır.

Otomotiv endüstrisi bu geçişin ORTASINDADIR — evrensel olarak tamamlanmış bir dönüşüm değildir:

• Bazı yeni platformlar, merkezi bir compute SoC’si etrafında kurulmuş zonal gateway mimarisini seri üretime almış durumda; bu genellikle yeni nesil elektrikli araç platformlarında, temiz sayfa (clean-sheet) tasarımlarda görülür.
• Birçok üretici ise geçiş sürecinde bir ARA aşamadadır: domain mimarisi (ADAS Domain Controller, Body Domain Controller gibi ayrı ama konsolide kontrolcüler) hâlâ yaygındır ve tam zonal dönüşüm kademeli olarak, platform yenilemeleriyle birlikte gerçekleşmektedir.
• Eski platformların üzerine inşa edilen modeller, geriye dönük uyumluluk ve maliyet nedenleriyle dağıtık/domain karışımı bir mimariyi daha uzun süre koruyabilir.

INTERPRETATION — Bu dersi “üretim araçlarının artık hepsi zonal mimariye geçti” şeklinde okumak yanlış olur. Doğru çerçeve: bu, endüstrinin AKTİF OLARAK yöneldiği bir MİMARİ YÖN’dür — ADAS/AD işlem yükünün bant genişliği ve hesaplama gereksinimleri bu yönü teknik olarak zorunlu kılar, ama geçişin hızı ve derinliği üreticiden üreticiye, platformdan platforma büyük ölçüde değişir.

---

Sıkça Sorulan Sorular (FAQ)

S: Zonal mimariye geçiş, tüm ECU’ları tek bir merkezi bilgisayarda mı birleştiriyor?

FACT — Hayır, tam olarak değil. Merkezi compute üst düzey algılama/planlama/karar mantığını birleştirir, ama zonal gateway’ler bölgesel toplama/yönlendirme görevini üstlenir — bunlar da kendi başlarına küçük, yerel işlem yapabilen kontrolcülerdir. Ayrıca §8’de işlendiği gibi, düşük seviye güvenlik-kritik kontrol CAN/CAN-FD üzerinden ayrı bir katmanda kalmaya devam eder; “tek merkezi bilgisayar, hiçbir dağıtık işlem yok” tarifi gerçekçi değildir.

S: Neden algılama artık akıllı kameraların içinde değil, merkezi bilgisayarda yapılıyor?

INTERPRETATION — Eski sistemlerde “akıllı kameralar” kendi küçük işlemcileriyle nesne tespiti yapıp sadece nesne listesi gönderirdi. Ama AD-07’de işlenen modern derin füzyon modelleri, ham piksel verisini radar/LiDAR ham verisiyle ERKEN katmanda birleştirmeyi gerektirir — bu da sensörlerin ham veri gönderen “aptal” uçlar, merkezi compute’un ise tüm füzyonu yapan güçlü bir “beyin” olmasını gerektirir.

S: Merkezi bilgisayar arızalanırsa araç ne yapar?

CRITICAL — Yüksek otomasyon seviyelerinde (L4/L5) tek bir merkezi bilgisayara güvenilmez; çift-yedekli (dual/redundant HPC) mimari kullanılır ve birinci SoC arızalandığında ikincisi devralır (fail-operational). Ayrıca §3’te işlenen Safety Island, ana yapay zeka tamamen çökse bile minimum risk manevrasını (bkz. AD-17) garanti eden bağımsız, donanımsal kilit-adımlı bir alt sistemdir.

---

Özet

• Tek bir yüksek çözünürlüklü kamera/LiDAR sensörünün ham veri hızı, klasik CAN’ın kapasitesini binlerce kat aşar — bu, modern ADAS/AD işlem yükünün dağıtık ECU mimarisiyle temelden uyumsuz olduğunun matematiksel kanıtıdır.
• Endüstri Dağıtık → Domain → Zonal olmak üzere üç aşamalı bir evrim geçiriyor; zonal mimari aracı fonksiyona göre değil, fiziksel bölgeye göre organize eder.
• Merkezi Compute (HPC), önceden dağıtık onlarca ECU’da duran mantığı tek bir güçlü SoC’de birleştirir ve AD-07’de işlenen erken/derin sensör füzyonunu mümkün kılar; ayrı bir Safety Island, ana AI çökse bile minimum risk manevrasını garanti eder.
• Zonal gateway’ler bölgesel sensör/aktüatörleri toplayarak kablo uzunluğunu/ağırlığını azaltır; Automotive Ethernet (10BASE-T1S – Multi-Gig) ve TSN, CAN’ın asla tasarlanmadığı yüksek hacimli, deterministik sensör akışını taşır.
• CAN/CAN-FD, düşük hacimli ama ultra-güvenilir güvenlik-kritik kontrol mesajlarında güçlü kalmaya devam eder — sonuç, CAN’ın Ethernet’le tamamen yer değiştirdiği değil, ikisinin birlikte çalıştığı karma bir mimaridir.
• Bu geçiş endüstride aktif ve devam eden bir süreçtir; evrensel olarak tamamlanmış tek bir mimari yoktur, üreticiden üreticiye geçiş hızı ve derinliği değişir.

Kaynaklar ve Doğrulama Notu

Bu ders IEEE 802.3 Automotive Ethernet standartları ailesi, MIPI A-PHY/ASA (Automotive SerDes Alliance) spesifikasyonları, AUTOSAR Adaptive Platform dokümantasyonu, Bosch CAN/CAN-FD spesifikasyonu ve SAE J3016 terminolojisine dayanmaktadır. §9’daki üretici-özgü mimari geçiş örnekleri kamuya açık teknik basın ve endüstri konferans kaynaklarına dayanır ve ASSUMPTION olarak işaretlenmiştir; belirli bir platformun GÜNCEL, TAM mimari detayları için üreticinin resmi teknik dokümantasyonuna bakılmalıdır.

Sıradaki Ders

• AD-30 — SAE Seviyeleri Pratik Örnekler ve Karşılaştırmalı Sorumluluk Analizi: Akademinin kapanış dersinde, bu derste incelediğimiz donanım/veri mimarisinin üzerinde çalışan otomasyon seviyelerini gerçek dünya senaryoları ve karşılaştırmalı sorumluluk analiziyle sentezleyeceğiz.