AD-28 — Otonom Sürüş Emniyet Vakası: Safety Case ve UL 4600 Standardı

FACT — Yüz yıllık otomotiv mühendisliği tarihinde, bir fren sisteminin veya bir hava yastığının güvenli olduğunu kanıtlamanın standart yolu şuydu: tanınmış bir sürece uy (ISO 26262 V-modeli), gerekli testleri yap, dokümante et. Ama bir L4 sürücüsüz aracın “bu araç insan olmadan, bu ODD içinde, kabul edilebilir düzeyde güvenli sürer” iddiasını kanıtlamak için dayanacağı yüz yıllık bir emsal (precedent) yoktur — ne bir sigorta şirketinin elinde milyonlarca L4 aracın kaza istatistiği, ne düzenleyicinin elinde “böyle bir sistem genelde güvenlidir” diyebileceği bir tarihsel kayıt. Bu derste, süreç uyumluluğunun yetersiz kaldığı bu boşlukta doğan disiplini — Safety Case (Emniyet Vakası) ve onu somutlaştıran UL 4600 standardını — inceliyoruz.

Bu derste şunları öğreneceksin:

1. Neden Süreç Uyumluluğu Tek Başına Yetmez: L4’ün Emsalsizliği
2. UL 4600 Nedir ve ISO 26262/ISO 21448’den Nasıl Ayrışır
3. Goal Structuring Notation (GSN) ile Emniyet Vakası Mimarisi
4. Safety Case’in Üç Sütunu: İddia, Argüman, Kanıt
5. Sentez Noktası: Önceki Derslerin Kanıt Zincirine Bağlanması
6. Sürekli Güvenlik Güvencesi (Continuous Safety Assurance)
7. Bağımsız Denetim ve “Negatif Kanıt” İlkesi
8. UL 4600’ün Sınırları: Bir Safety Case Ne Değildir

---

1. Neden Süreç Uyumluluğu Tek Başına Yetmez: L4’ün Emsalsizliği

ISO 26262 (bkz. AD-19 — Fonksiyonel Emniyet (ISO 26262): HARA, ASIL ve Güvenlik Hedefleri) ve ISO 21448/SOTIF (bkz. AD-20 — SOTIF (ISO 21448): Amaçlanan Fonksiyonun Güvenliği) her ikisi de örtük olarak bir insan sürücünün varlığını varsayar: ISO 26262’de arıza anında sürücü müdahale edebilir (Controllability), SOTIF’te ise senaryo kapsamı genelde sürücünün devralabileceği L2/L3 bağlamında çerçevelenir. Geleneksel bir ABS ya da ESC sistemi için “biz ISO 26262’yi uyguladık, HARA yaptık, ASIL-D hedeflerini karşıladık” demek yeterli bir güven temelidir — çünkü bu tür sistemlerin arkasında onlarca yıllık saha verisi, milyonlarca araç-yılı deneyim ve iyi anlaşılmış bir arıza taksonomisi vardır.

L4 bir robotaksi için durum köklü biçimde farklıdır:

• Emsal yoktur. Hiçbir üretici, “sürücüsüz araçlar genelde güvenlidir” diyebileceği on yıllık bir saha kaydına sahip değildir.
• Sürücü yedek değildir. ISO 26262’nin Controllability varsayımı çöker — kabinde arızayı devralacak biri yoktur.
• Kamuoyu ve düzenleyici, “süreci takip ettik” cevabını yetersiz bulur. Bir kazadan sonra sorulan soru “hangi standardı izlediniz?” değil, “bu aracın güvenli olduğunu NASIL biliyorsunuz, ve neden?“dir.

CRITICAL — Süreç uyumluluğu (process compliance) ile emniyet vakası (safety case) arasındaki fark şudur: süreç uyumluluğu “doğru adımları izledik” der; safety case ise “işte kanıt, ve işte bu kanıtın neden güvenlik sonucunu DESTEKLEDİĞİNE dair mantıksal argüman” der. Birincisi bir kontrol listesidir, ikincisi aktif bir savunmadır. L4/L5 sistemlerinde ikincisi olmadan birincisi yeterli kabul edilmez.

Bu boşluğu doldurmak için Underwriters Laboratories (UL), otonom ürünlerin TAM safety case’ini değerlendirmek üzere tasarlanmış ilk büyük standardı yayınladı: UL 4600.

---

2. UL 4600 Nedir ve ISO 26262/ISO 21448’den Nasıl Ayrışır

UL 4600 (Standard for Safety for the Evaluation of Autonomous Products), otonom sürüş sistemlerinin insan sürücü olmadan güvenli şekilde çalışabileceğini kanıtlamak üzere geliştirilmiştir ve şu üç özelliğiyle öncekilerden ayrışır:

• Süreç Odaklı Değil, Hedef Odaklı (Goal-Based): Standart “şu testi yapın” ya da “şu V-modelini takip edin” demez. Bunun yerine “Aracın hiçbir zaman yayaların üzerine sürmeyeceğini nasıl kanıtlarsınız?” sorusunu sorar ve kanıtlama yükünü mühendise bırakır.
• Güvenlik Argümanı Zorunluluğu: Üretici, sistemin güvenli olduğuna dair yapılandırılmış, şeffaf ve kanıta dayalı bir mantıksal argüman sunmak zorundadır — sadece test raporlarının bir listesini değil.
• “Bunu Düşündünüz mü?” Sorgusu: UL 4600, binlerce maddelik kontrol listesiyle mühendislere gözden kaçırılmış olabilecek uç senaryoları, sensör sınırlarını ve örtük varsayımları sorgulatır.

UL 4600’ün bu tam kapsamlı, otonomiye özgü yaklaşımı doğrudan bir boşluktan doğar: geleneksel otomotiv güvenlik standartları, tasarlandıkları dönemde tam otonomiyi hiç hesaba katmamıştı.

Özellik	ISO 26262	ISO 21448 (SOTIF)	UL 4600
Ana Odak	E/E donanım arızaları ve sistematik yazılım hataları	Algılama ve algoritma performans sınırları (arızasız da olsa yetersiz kalma)	Sürücüsüz sistemin UÇTAN UCA otonomi güvenliği
Sürücü Rolü	Arıza anında sürücü müdahalesi beklenir (Controllability)	Sürücü devralması öngörülür (L2/L3 bağlamı)	Kabinde sürücü yoktur (L4/L5)
Yaklaşım	Süreç tabanlı (V-modeli uyumluluğu)	Risk analizi ve senaryo/kapsam testi	Hedef ve Argüman tabanlı (Goal-Based Safety Case)
Kanıt Rolü	Süreç adımlarının tamamlandığını gösterir	Bilinmeyen-güvensiz senaryoların kapsamını gösterir	HARA + SOTIF + TARA + V&V + ODD sonuçlarını TEK bir argümanda birleştirir

INTERPRETATION — UL 4600’ü ISO 26262 ve ISO 21448’in yerine geçen bir standart olarak görmek yanlıştır. Daha doğru çerçeve şudur: ISO 26262 ve ISO 21448, belirli bir tehlike sınıfına (donanım/yazılım arızası, fonksiyonel yetersizlik) odaklanan kanıt üreticileridir; UL 4600 ise bu kanıtları ve daha fazlasını (siber güvenlik, operasyonel süreçler, insan faktörleri) tek bir tutarlı, izlenebilir mantık zincirinde birleştiren üst-çerçevedir. Bu ayrımı §5’te somutlaştıracağız.

---

3. Goal Structuring Notation (GSN) ile Emniyet Vakası Mimarisi

Bir Safety Case, bir sistemin belirli bir çalışma ortamında (ODD) kabul edilebilir düzeyde güvenli olduğunu gösteren yapılandırılmış argümanlar ve kanıtlar bütünüdür. Endüstri bu argüman hiyerarşisini görselleştirmek için GSN (Goal Structuring Notation) kullanır:

                  [ G1: Sistem Kendi ODD'si İçinde Kabul Edilebilir Düzeyde Güvenlidir ] (Goal)
                                   |
                  +----------------+----------------+---------------------+
                  |                                 |                     |
         [ S1: Algılama Emniyeti ]         [ S2: Hareket/Kontrol      [ S3: Siber Güvenlik
          Argümanı Üzerinden ]              Emniyeti Argümanı ]       Argümanı Üzerinden ]
                  |                                 |                     |
        +---------+---------+                       |                     |
        |                   |                       |                     |
   [ G2: Nesneler      [ G3: Sensör            [ G4: Yörünge          [ G5: Kritik Ağ
    Kaçırılmaz ]        Arızaları              Çarpışma              Yolları TARA'da
                         Yönetilir ]            Üretmez ]             Kapsanmıştır ]
        |                   |                       |                     |
   [ E1: AD-20 SOTIF   [ E2: AD-22/23 HIL      [ E3: RSS            [ E4: AD-21 TARA
    Senaryo Kapsamı,    Hata Enjeksiyon         Matematiksel         Bulguları ve
    Bilinmeyen-         Test Raporları ]        İspatı & Pist        Sızma Testi
    Güvensiz Küme ]                             Testi ]              Raporları ]
   (Evidence)          (Evidence)               (Evidence)           (Evidence)

GSN’nin dört temel elemanı:

1. Goal (Hedef — Dikdörtgen): Kanıtlanması gereken güvenlik iddiası (Örn: “Yaya tespit kaçırma oranımız belirlenen eşiğin altındadır”).
2. Strategy (Strateji — Paralelkenar): Hedefin alt hedeflere nasıl bölündüğünü açıklayan yaklaşım (Örn: “Sensör çeşitliliği argümanı üzerinden kanıtlama”).
3. Context (Bağlam — Yuvarlak Köşeli Dikdörtgen): Hedefin geçerli olduğu ODD ve varsayımlar (Örn: “AD-16’da tanımlanan ODD: gündüz, kuru zemin, ≤80 km/s otoyol”).
4. Evidence (Kanıt — Daire): İddiayı doğrulayan nesnel veriler — HIL test raporu, simülasyon logları, matematiksel ispat, pist test verisi, önceki derslerde ürettiğimiz doğrulama çıktıları.

CRITICAL — GSN’nin gücü, her ok’un (bağlantının) mantıksal bir iddia taşımasıdır: “G2’ye ulaşmak için E1 yeterlidir” demek, o kanıtın o hedefi neden desteklediğine dair bir gerekçe içermelidir — kanıtı sadece hedefin yanına iliştirmek yetmez. Bir denetçinin ilk işi tam olarak budur: her bağlantıyı sorgulamak, “bu kanıt gerçekten bu iddiayı destekliyor mu, yoksa sadece ilgili mi?” diye sormak.

---

4. Safety Case’in Üç Sütunu: İddia, Argüman, Kanıt

Bir emniyet vakası bir mahkeme savunmasına benzer — üç katman birbirinden ayrılmadan anlamsızdır:

• İddia (Claim): Ne iddia ediyorsunuz? (Örn: “Araç kırmızı ışıkta asla kavşağa girmez.”)
• Argüman (Argument): Bu iddiaya neden inanmalıyız? (Örn: “Kamera ve HD harita bağımsız olarak ışığı algılar; derin öğrenme ve kural tabanlı kontrolcü aynı anda kırmızı teyit eder; ikisi çelişirse araç güvenli durma durumuna geçer — bkz. AD-17 — Fallback Stratejileri, MRM ve Emniyetli Durum (MRC).”)
• Kanıt (Evidence): Argümanınızı hangi veriler destekliyor? (Örn: “100.000 sanal kavşak testi, 5.000 km pist testi ve 12 aylık gölge modu logları.”)

$\text{Safety Case} = \{ \text{Claim} \} \xrightarrow{\text{Argument}} \{ \text{Evidence}_1, \text{Evidence}_2, \dots, \text{Evidence}_n \}$

FACT — Kanıtsız bir iddia sadece bir temennidir; argümansız bir kanıt yığını ise anlamsız bir veri çöplüğüdür. UL 4600, her kanıtın açık bir mantıksal argüman zinciriyle en üstteki güvenlik hedefine bağlanmasını zorunlu kılar. Bu, örneğin ASIL-D için ISO 26262’de hedeflenen $<10^{-8}$ saat başına tehlikeli arıza oranı gibi TEK bir sayısal hedefin dahi, tek başına “araç güvenlidir” iddiasını KANITLAMADIĞI anlamına gelir — o sayı, argümanın sadece bir dalındaki bir kanıt parçasıdır.

---

5. Sentez Noktası: Önceki Derslerin Kanıt Zincirine Bağlanması

Bu ders, akademinin emniyet ve doğrulama derslerini tek bir çatı altında toplayan bir sentez noktasıdır. Bir gerçek L4 safety case’inde, önceki derslerde işlediğimiz her sonuç, GSN ağacında belirli bir dalın kanıtı olarak yer alır:

Önceki Ders	Ürettiği Kanıt Türü	GSN’de Hangi Hedefi Destekler
AD-16 — ODD Tanımı	Sistemin güvenli olduğu iddia edilen sınırların kesin tanımı	Bağlam (Context) düğümü — TÜM alt hedeflerin geçerlilik çerçevesi
AD-19 — HARA/ASIL	Tehlike analizi, risk sınıflandırması, güvenlik hedefleri, donanım arıza oranları	“Donanım/sistematik arızalar yönetilir” hedefi
AD-20 — SOTIF	Bilinen-güvenli, bilinen-güvensiz, bilinmeyen-güvensiz senaryo kümelerinin daralma kanıtı	“Algılama/planlama fonksiyonel olarak yeterlidir” hedefi
AD-21 — TARA	Siber güvenlik tehdit analizi, sızma testi sonuçları, güvenlik kontrolleri	“Kötü niyetli müdahaleye karşı dayanıklıdır” hedefi
AD-22/AD-23 — V&V, Senaryo Testi	MIL/SIL/HIL/VIL sonuçları, RSS metrikleri, senaryo kapsam istatistikleri	“Kontrol/hareket planlama çarpışma üretmez” hedefi

INTERPRETATION — Bu tablo, akademinin neden bu sırayla ilerlediğinin de örtük cevabıdır: AD-16’dan AD-23’e kadar öğrendiğiniz her yöntem, izole bir “yapılması gereken egzersiz” değil, nihayetinde BU dersteki tek bir mantıksal argüman ağacına yerleşecek bir kanıt üretim hattıdır. Bir safety case yazarı, sıfırdan başlamaz — önceki derslerin çıktılarını GSN ağacına yerleştirir ve eksik/zayıf dalları tespit eder.

Bu sentezin pratik sonucu şudur: bir ekip HARA’yı mükemmel yapmış, SOTIF senaryo kapsamını genişletmiş, TARA’yı eksiksiz tamamlamış olabilir — ama bu kanıtları BİRBİRİNE BAĞLAYAN açık bir argüman yazmamışsa, elinde hâlâ bir safety case yoktur, sadece bağlantısız bir kanıt koleksiyonu vardır.

---

6. Sürekli Güvenlik Güvencesi (Continuous Safety Assurance)

Otonom araç yazılımları OTA (over-the-air) ile sürekli güncellenir. Bir sistem güncellendiğinde tüm Safety Case çöpe atılmaz; Sürekli Güvenlik Güvencesi işletilir:

• Yazılımda yapılan bir değişiklik (örneğin algılama modelinin güncellenmesi) GSN ağacında ilgili hedefi ve kanıtı etkiler — örneğin §5’teki tablodaki “SOTIF” satırı yeniden değerlendirilmeyi gerektirir.
• Yalnızca etkilenen dal (impacted branch) yeniden doğrulanır ve kanıt kütüphanesine yeni test sonuçları eklenir; etkilenmeyen dallar (örneğin donanım ASIL analizi değişmediyse) yeniden çalıştırılmaz.
• Bu, sürekli entegrasyon (CI/CD) hatlarıyla otomatikleştirilebilecek bir izlenebilirlik (traceability) altyapısı gerektirir: her kod değişikliği, hangi GSN düğümünü etkilediğini bildirmelidir.

WARNING — Sürekli güvenlik güvencesi disiplinsiz uygulandığında tehlikeli bir kısayola dönüşebilir: “sadece etkilenen dalı test ettik” iddiası, etki analizinin kendisi hatalıysa (örneğin bir algılama modeli değişikliğinin aslında kontrol davranışını da dolaylı etkilediği fark edilmezse) yanlış bir güven duygusu yaratır. Bu yüzden etki analizinin kendisi de bağımsız olarak denetlenmelidir — bu konuyu §7’de genişletiyoruz.

---

7. Bağımsız Denetim ve “Negatif Kanıt” İlkesi

Sistemi geliştiren mühendisler kendi kör noktalarını (confirmation bias) göremez — bu, safety case mühendisliğinde iyi belgelenmiş bir insan faktörü sorunudur. UL 4600, bu yüzden bağımsız denetim (over-the-shoulder audit) kavramını merkeze koyar: sistemi geliştirmeyen, dolayısıyla tasarım kararlarına duygusal/kariyer bağlılığı olmayan üçüncü bir taraf (TÜV, UL, ya da şirket içi ayrı bir emniyet ekibi), GSN ağacındaki mantıksal boşlukları ve eksik kanıtları sorgulamakla yükümlüdür.

Bunun ötesinde UL 4600, “Negatif Kanıt” (Did we miss anything?) ilkesini formalize eder — bu, klasik pozitif kanıt toplama (“şunu test ettik, başarılı oldu”) yaklaşımından temelde farklıdır:

• Pozitif kanıt sorusu: “Test ettiğimiz senaryolarda sistem güvenli mi davrandı?”
• Negatif kanıt sorusu: “Hangi senaryo SINIFLARINI hiç düşünmedik, hiç test etmedik, hatta var olduğunu bile fark etmedik?”

FACT — İkinci soru birincisinden çok daha zordur, çünkü “bilmediğimizi bilmediğimiz” (unknown-unknown) bir kümeyi sorgulamayı gerektirir — bu terminolojiyi AD-20 — SOTIF dersinde ayrıntılı işlemiştik. UL 4600’ün binlerce maddelik “prompt list”i (kontrol soruları kataloğu) tam olarak bu amaca hizmet eder: mühendislere “bu sensör tipinin şu ortam koşulunda arızalanma modunu düşündünüz mü?” gibi sistematik sorular sorarak, gözden kaçırılmış varsayımları yüzeye çıkarır.

Bir kilometre istatistiği tek başına yeterli değildir. “1 milyar km kaza yapmadan sürdük” iddiası, hangi senaryolarla karşılaşıldığını, sistemin hangi mantıkla karar verdiğini ve bir sonraki kilometrede sistemin başarısız OLMAYACAĞININ kanıtını sağlamaz. Salt istatistiksel maruziyet (exposure), yapılandırılmış bir nedensel argümanın yerini tutamaz.

---

8. UL 4600’ün Sınırları: Bir Safety Case Ne Değildir

UL 4600’ü doğru konumlandırmak için, ne YAPMADIĞINI da bilmek gerekir:

• UL 4600 bir onay/sertifikasyon garantisi değildir. Standardı takip etmek, düzenleyici onayı otomatik olarak garanti etmez — bkz. AD-26 — Global Regülasyonlar: UNECE, AB GSR II, ABD, Çin, Japonya ve Türkiye; farklı yargı bölgeleri farklı onay çerçeveleri (ör. UNECE R157) kullanır ve UL 4600 bunların yerine geçmez, tamamlayıcı bir mühendislik disiplinidir.
• UL 4600 zorunlu (mandatory) bir standart değildir, gönüllü (voluntary) bir çerçevedir — bazı yargı bölgelerinde ve bazı üreticiler tarafından referans alınır, ama evrensel bir yasal zorunluluk değildir.
• UL 4600, “sıfır risk” iddiasını gerektirmez veya vaat etmez. Amaç “kabul edilebilir düzeyde güvenli” (acceptably safe) olduğunu göstermektir — mutlak güvenlik mühendislik açısından tanımsız bir hedeftir.
• Bir safety case statik bir belge değildir. §6’da işlendiği gibi, aracın yazılımı veya ODD’si değiştikçe yaşayan, sürekli güncellenen bir mühendislik ürünüdür.

ASSUMPTION — UL 4600’ün farklı yargı bölgelerinde (ABD eyaletleri, AB, Çin) düzenleyici kabul görme derecesi ve bazı üreticilerin kendi iç safety case süreçlerine UL 4600’ü ne ölçüde birebir uyguladığı, kamuya açık kaynaklarda ayrıntılı biçimde raporlanmamıştır; bu dersteki çerçeve genel/kavramsal bir referans olarak alınmalı, belirli bir üreticinin ya da yargı bölgesinin GÜNCEL uygulaması için resmi dokümantasyona bakılmalıdır.

---

Sıkça Sorulan Sorular (FAQ)

S: Bir şirket “1 milyar kilometre kaza yapmadan sürdük” derse bu tek başına bir Safety Case sayılır mı?

FACT — Hayır. UL 4600 ve emniyet bilimi, sadece kilometre saymayı kabul etmez (§7). O bir milyar kilometrede hangi uç senaryolarla karşılaşıldı, sistem hangi mantıkla karar verdi ve bir sonraki kilometrede kaza yapmayacağının kanıtı nedir — bunlar cevaplanmadan salt istatistiksel maruziyet kanıtlanmış bir emniyet argümanının yerini tutamaz.

S: ISO 26262’yi tam uygulayan bir ekip, otomatik olarak güçlü bir UL 4600 safety case’ine de sahip olur mu?

INTERPRETATION — Kısmen. ISO 26262’nin HARA/ASIL çıktıları (§5’teki tabloda görüldüğü gibi) safety case’in ÖNEMLİ bir dalının kanıtıdır, ama tek başına yeterli değildir — SOTIF, siber güvenlik ve operasyonel/insan faktörü boyutları da eklenmeli, hepsi tek bir mantıksal argümanda BİRLEŞTİRİLMELİDİR. ISO 26262 uyumluluğu, safety case’in zorunlu ama yeterli olmayan bir bileşenidir.

S: Bağımsız denetim (over-the-shoulder audit) neden şarttır?

CRITICAL — Sistemi geliştiren mühendisler kendi kör noktalarını göremezler (confirmation bias, §7). Bağımsız denetçiler, safety case’deki mantıksal boşlukları ve eksik kanıt bağlantılarını sorgulamakla yükümlüdür; bu rol geliştirme ekibinin kendi içinden üstlenilemez.

---

Özet

• Geleneksel süreç odaklı standartlar (ISO 26262, ISO 21448) örtük olarak bir insan sürücünün varlığını varsayar; L4/L5’te bu varsayım çöker ve emsalsiz bir sistem için pozitif, kanıta dayalı bir argüman gerekir.
• UL 4600, otonom ürünlerin TAM safety case’ini değerlendirmek üzere tasarlanmış hedef odaklı (goal-based) ilk büyük standarttır; “şu testi yap” demez, “neden güvenli olduğunu kanıtla” der.
• GSN (Goal Structuring Notation), İddia (Goal), Strateji (Strategy), Bağlam (Context) ve Kanıt (Evidence) düğümlerinden oluşan, her bağlantısı mantıksal gerekçe taşıyan bir görsel argüman dilidir.
• Bu ders bir sentez noktasıdır: HARA/ASIL (AD-19), SOTIF senaryo kapsamı (AD-20), TARA (AD-21), V&V sonuçları (AD-22/23) ve ODD tanımı (AD-16), safety case’in GSN ağacında ayrı dalların kanıtı olarak birleşir.
• Sürekli Güvenlik Güvencesi, OTA güncellemelerinde tüm safety case’i sıfırdan kurmak yerine sadece etkilenen dalları yeniden doğrular; bağımsız denetim ve “negatif kanıt” ilkesi, kilometre istatistiğinin ötesinde gözden kaçan senaryoları sistematik olarak sorgular.
• UL 4600 bir sertifikasyon garantisi değildir, zorunlu değildir ve sıfır risk vaat etmez — kabul edilebilir güvenlik için yapılandırılmış bir argümantasyon disiplinidir.

Kaynaklar ve Doğrulama Notu

Bu ders UL 4600 (Standard for Safety for the Evaluation of Autonomous Products), SAE J3016 terminolojisi, ISO 26262 fonksiyonel güvenlik çerçevesi, ISO 21448 (SOTIF) ve Goal Structuring Notation (GSN) topluluk standardına dayanmaktadır. GSN diyagramındaki örnek hedef/kanıt eşleştirmeleri ve §5’teki sentez tablosu bu akademinin önceki derslerine (AD-16, AD-19, AD-20, AD-21, AD-22, AD-23) atıfla kavramsal olarak oluşturulmuştur; belirli bir üreticinin veya yargı bölgesinin GÜNCEL UL 4600 uygulama derecesi ASSUMPTION olarak işaretlenmiştir (§8) — kesin ve güncel bilgi için standardın resmi metnine ve ilgili düzenleyici dokümantasyona bakılmalıdır.

Sıradaki Ders

• AD-29 — Gelecek Nesil Mimariler: Merkezi Compute, Zonal E/E ve Ethernet: Bu derste incelediğimiz emniyet argümanlarının hangi donanım/veri mimarisi üzerinde çalıştığını — merkezi compute platformları, zonal E/E tasarımı ve automotive Ethernet’in neden CAN’ın yerini kısmen aldığını — inceleyeceğiz.