AD-19 — Fonksiyonel Emniyet (ISO 26262): HARA, ASIL ve Güvenlik Hedefleri

FACT — Fonksiyonel emniyet (functional safety), tam olarak şunu ifade eder: elektrik/elektronik (E/E) sistemlerin hatalı davranışının (malfunctioning behavior) yol açtığı tehlikeler nedeniyle kabul edilemez bir riskin bulunmaması. Bu tanımın her kelimesi kasıtlıdır — konu “sistem doğru tasarlandı mı” değil, **“sistem bir arıza yaptığında ne olur”**dur. Bir kamera algoritmasının hiçbir arıza olmadan, tam da tasarlandığı gibi çalışırken yanlış bir karar vermesi (ör. alışılmadık bir nesneyi yanlış sınıflandırması) ise ISO 26262’nin değil, AD-20’de ele alacağımız SOTIF’in (ISO 21448) konusudur.

Bu derste şunları öğreneceksin:

1. Fonksiyonel Emniyetin Kesin Tanımı ve SOTIF’ten Ayrımı — “arıza var” ile “arıza yok ama yetersizlik var” sınırı.
2. ISO 26262 Kapsamı, Yapısı ve V-Model — konsept fazından üretime kadar geliştirme akışı.
3. HARA: Tehlike Analizi ve Risk Değerlendirmesi — Şiddet (S), Maruziyet (E), Kontrol Edilebilirlik (C).
4. ASIL Belirleme Matrisi — S/E/C kombinasyonlarının QM’den ASIL D’ye nasıl eşlendiği.
5. Güvenlik Hedefleri ve Kademeli Gereksinim Türetimi — HARA’dan Teknik Güvenlik Gereksinimlerine.
6. Vaka Çalışması: ACC Kaynaklı İstenmeyen Hızlanma — uçtan uca basitleştirilmiş bir HARA.
7. Donanım Arıza Metrikleri: SPFM, LFM, PMHF — ASIL D’nin somut sayısal hedefleri.
8. FTTI ve Güvenli Durum — arızanın tehlikeye dönüşmeden önce ne kadar sürede durdurulması gerektiği.

---

1. Fonksiyonel Emniyetin Kesin Tanımı ve SOTIF’ten Ayrımı

ISO 26262, kara taşıtlarındaki E/E sistemlerin rastgele donanım arızaları (ör. bir transistörün kısa devre yapması, bir bellek hücresinin bit-flip’e uğraması) veya sistematik hatalar (ör. yazılımda bir mantık hatası, gereksinim spesifikasyonunda bir eksiklik) nedeniyle ortaya çıkan riskleri kabul edilebilir seviyeye indirmeyi hedefler.

CRITICAL — Otomotiv emniyet mühendisliğinde en sık karıştırılan iki kavram:

• ISO 26262 (Fonksiyonel Emniyet): “Sistemde bir şey bozulursa ne olur?” — kısa devre, bellek bozulması, yazılım kilitlenmesi, sensör donanım arızası.
• ISO 21448 / SOTIF (AD-20): “Sistemde hiçbir şey bozulmadığı halde, sensörün fiziksel kısıtları veya algoritmanın eğitim verisi dışındaki bir durumu yanlış yorumlaması yüzünden” ne olur?

Bu ikisi birbirini tamamlar, birbirinin yerine geçmez. Bir ADAS sisteminin emniyet argümanı (safety case) her iki standardı da kapsamak zorundadır; ISO 26262’yi geçmiş ama SOTIF’i hiç ele almamış bir sistem hâlâ tehlikeli olabilir (ve tam tersi).

Bu derste ISO 26262’nin arıza-odaklı dünyasına odaklanıyoruz; AD-20’de aynı çerçeveyi “arıza yok ama yine de tehlikeli” senaryolarına genişleteceğiz.

---

2. ISO 26262 Kapsamı, Yapısı ve V-Model

ISO 26262:2018, 12 bölümden (Part) oluşur ve otomotiv E/E sistem yaşam döngüsünün tamamını (konsept, sistem/donanım/yazılım geliştirme, üretim, operasyon, bakım, devreden çıkarma) kapsar. Standardın merkezinde, gereksinimlerin sol koldan (spesifikasyon) sağ kola (doğrulama) simetrik olarak eşlendiği klasik V-Model süreç mimarisi yer alır:

ISO 26262 V-Model (Basitleştirilmiş):

  Sol Kol (Spesifikasyon)              Sağ Kol (Doğrulama/Test)
  ─────────────────────                ─────────────────────────
  Öğe Tanımı (Item Definition)
        │
        ▼
  HARA (§3)  ──────────────────────────►  Safety Validation
        │  Güvenlik Hedefleri (ASIL)              ▲
        ▼                                          │
  Fonksiyonel Güvenlik Kavramı  ─────────►  Sistem Doğrulama (Sys. Test)
        │  (Functional Safety Concept)              ▲
        ▼                                          │
  Teknik Güvenlik Gereksinimleri ────────►  Entegrasyon Testi (HIL/SIL)
        │  (Technical Safety Req.)                  ▲
        ▼                                          │
  Donanım / Yazılım Tasarımı  ───────────►  Birim Testi (Unit Test)
        └──────────────► Uygulama (Implementation) ◄┘

Her sol-kol adımı, karşılığı olan sağ-kol doğrulama adımına izlenebilir (traceable) olmalıdır — bir Teknik Güvenlik Gereksinimi yazılmışsa, onu doğrulayan somut bir test de var olmak zorundadır. Bu izlenebilirlik zinciri, denetim (audit) sırasında istenen Emniyet Vakası (Safety Case) dokümantasyonunun omurgasıdır. V-Model’in sağ kolundaki test seviyelerini (MIL/SIL/HIL/VIL) AD-22’de detaylandıracağız.

---

3. HARA: Tehlike Analizi ve Risk Değerlendirmesi

Bir öğe (item) tanımlandıktan sonra ilk adım HARA (Hazard Analysis and Risk Assessment)‘dır: sistemin olası hatalı davranışlarından (malfunctions) doğabilecek tehlikeler sistematik olarak listelenir ve her biri üç bağımsız parametreyle derecelendirilir.

Parametre	Ne Ölçer	Seviyeler	Örnek Üst Sınır
Şiddet (S — Severity)	Kazanın olası yaralanma derecesi	S0 (zarar yok) → S1 (hafif/orta) → S2 (ciddi, hayatta kalma muhtemel) → S3 (kritik/ölümcül, hayatta kalma belirsiz)	S3: çarpışma hızı ve yönü ölümcül yaralanma potansiyeli taşır
Maruziyet (E — Exposure)	Arızanın gerçekleştiği operasyonel durumun trafikteki istatistiksel sıklığı	E0 (olasılık dışı) → E1 (çok düşük) → E2 (düşük) → E3 (orta) → E4 (yüksek)	E4: sürüş süresinin büyük bölümünde geçerli bir durum (ör. otoyol seyri)
Kontrol Edilebilirlik (C — Controllability)	Ortalama bir sürücünün (veya sistemin) tehlikeyi zamanında bertaraf edebilme yeteneği	C0 (kontrol edilebilir) → C1 (kolayca kontrol edilebilir) → C2 (normalde kontrol edilebilir) → C3 (zor/kontrol edilemez)	C3: sürücülerin %90’ından fazlası kazayı önleyemez

WARNING — S/E/C değerleri sübjektif mühendislik yargısıyla değil, mümkün olduğunca istatistiksel kaza verisi, sürüş verisi ve insan faktörleri çalışmalarıyla desteklenerek atanmalıdır. ISO 26262 Part 3 Annex B, bu üç parametre için kılavuz tanımlar verir; ancak nihai puanlama OEM’in kendi HARA ekibinin (genellikle çapraz fonksiyonlu: emniyet mühendisliği, insan faktörleri, hukuk) sorumluluğundadır ve denetimde gerekçelendirilebilir olmalıdır.

---

4. ASIL Belirleme Matrisi

ASIL (Automotive Safety Integrity Level), S/E/C üçlüsünün standart bir arama tablosuyla eşlenmesinden elde edilir. Sonuç beş seviyeden biridir: QM (Quality Management — özel bir emniyet süreci gerektirmez, standart kalite yönetimi yeterlidir), A (en hafif), B, C, D (en katı).

S \ E \ C	C1 (kolay)	C2 (normal)	C3 (zor)
S1, E1	QM	QM	QM
S1, E2	QM	QM	QM
S1, E3	QM	QM	A
S1, E4	QM	A	B
S2, E1	QM	QM	QM
S2, E2	QM	QM	A
S2, E3	QM	A	B
S2, E4	A	B	C
S3, E1	QM	QM	A
S3, E2	QM	A	B
S3, E3	A	B	C
S3, E4	B	C	D

ASSUMPTION — Yukarıdaki tablo, ISO 26262-3 Annex B’deki ASIL belirleme mantığının eğitim amaçlı, basitleştirilmiş bir rekonstrüksiyonudur. Standardın kendisi telifli bir belgedir; kesin hücre değerleri ve dipnotlar için orijinal ISO 26262:2018 Part 3 metnine başvurulmalıdır. Buradaki amaç tablonun yapısını ve mantığını (S/E/C’nin nasıl birleştiğini) doğru aktarmaktır.

Matristen çıkan mühendislik sonucu nettir:

$\mathrm{ASIL} = f(S, E, C), \qquad S3 \wedge E4 \wedge C3 \;\Rightarrow\; \mathbf{ASIL\ D}$

Direksiyon ve fren sistemlerindeki arızaların çoğunlukla ASIL D ile derecelendirilmesinin nedeni de budur: yüksek hızda (E4 — sık maruziyet), bu sistemlerin bir arızası genellikle ölümcül sonuç doğurabilir (S3) ve sürücünün ani, beklenmedik bir direksiyon/fren davranışını saniyenin onda birinde telafi etmesi son derece zordur (C3). Buna karşın düşük hızda çalışan, düşük şiddetli bir konfor fonksiyonunun (ör. koltuk ısıtıcısının arızası) ASIL derecesi genellikle QM’dir — özel bir ISO 26262 sürecine tabi değildir, sadece standart kalite yönetimiyle geliştirilir.

---

5. Güvenlik Hedefleri ve Kademeli Gereksinim Türetimi

HARA’da tanımlanan her tehlike için tam olarak bir Güvenlik Hedefi (Safety Goal) yazılır. Güvenlik Hedefi, tehlikeyi önlemek veya azaltmak için sistemin sağlaması gereken en üst düzey gereksinimdir ve HARA’da belirlenen ASIL derecesini doğrudan miras alır.

HARA → Safety Goal → Functional Safety Concept → Technical Safety Requirements → Implementation
  │         │                    │                          │                        │
  │    "İstenmeyen       "Torku bağımsız iki       "İkinci mikroişlemci      Donanım/yazılım
  │    hızlanma          yoldan izle, sapma         torku ±5ms içinde        tasarımı + test
  │    önlenmelidir"     >X Nm ise 100ms'de         karşılaştırsın,          kanıtları
  │    (ASIL D)          torku kes"                 uyuşmazlıkta MOSFET
  │                                                  sürücüsünü kes"
  └── Tehlike: "ACC arızası nedeniyle
      istenmeyen hızlanma"

Her ok, ASIL derecesinin değişmeden aşağı doğru kademelendiğini (cascading) gösterir — Güvenlik Hedefi ASIL D ise, onu gerçekleştiren Teknik Güvenlik Gereksinimleri de (aksi mühendislik gerekçesiyle ayrıştırılmadıkça, bkz. ASIL decomposition) ASIL D geliştirme sıkılığına tabidir. Bu, HARA’nın soyut bir kağıt egzersizi değil, doğrudan hangi bileşenin ne kadar sıkı test/doğrulama sürecinden geçeceğini belirleyen bir mühendislik kararı olduğu anlamına gelir.

---

6. Vaka Çalışması: ACC Kaynaklı İstenmeyen Hızlanma

EXAMPLE — Basitleştirilmiş bir HARA yürütelim: Adaptive Cruise Control (ACC) modülünün, motor kontrol ünitesine hatalı bir tork komutu göndererek istenmeyen hızlanmaya (unintended acceleration) neden olması.

Adım 1 — Tehlikeyi Tanımla: ACC yazılımındaki bir mantık hatası veya sensör füzyon katmanındaki bir arıza, önündeki aracın hızlandığını yanlış algılayıp gerçek dışı bir hızlanma komutu üretir.

Adım 2 — Şiddeti Değerlendir (S): ACC tipik olarak otoyolda, orta-yüksek hızlarda devrededir. Kontrolsüz bir hızlanma, öndeki araca çarpma veya şeritten çıkma riskini taşır → S3 (potansiyel olarak ölümcül).

Adım 3 — Maruziyeti Değerlendir (E): ACC, açık olduğu sürece sürekli aktif bir fonksiyondur ve pek çok sürücü uzun otoyol yolculuklarının büyük kısmında kullanır → E4 (yüksek maruziyet).

Adım 4 — Kontrol Edilebilirliği Değerlendir (C): Sürücü fren pedalına basarak hızlanmayı iptal edebilir — bu bir kurtarma yoludur. Ancak sürpriz faktörü (sürücü ACC’nin doğru çalıştığını varsayıp dikkatini yoldan çekmiş olabilir) ve tepki süresi (ortalama fark etme + reaksiyon ~1-1.5 saniye) nedeniyle, şiddetli/ani bir hızlanma komutunda sürücülerin önemli bir kısmı zamanında müdahale edemez → C3 (zor kontrol edilebilir) olarak değerlendirilir; daha kademeli/düşük büyüklükte bir hızlanma senaryosu C2’ye düşebilir — bu yüzden gerçek HARA’larda tehlike genellikle büyüklüğe göre alt-senaryolara ayrılır.

Sonuç: $S3, E4, C3 \Rightarrow \mathbf{ASIL\ D}$.

Güvenlik Hedefi: “Araç, ACC fonksiyonunun herhangi bir tekil arızası nedeniyle sürücünün onaylamadığı bir hızlanma üretmemelidir.” (ASIL D)

Bu Güvenlik Hedefinden türeyen tipik Teknik Güvenlik Gereksinimleri: (1) istenen tork ile gerçek tork arasında bağımsız bir izleme (plausibility check) yolu, (2) tork talebinin pedal pozisyonu ve radar/kamera mesafe verisiyle çapraz doğrulanması, (3) uyuşmazlık tespit edildiğinde motor torkunu FTTI içinde güvenli bir değere (genellikle sıfır veya hafif motor freni) indiren bağımsız bir kesme yolu.

---

7. Donanım Arıza Metrikleri: SPFM, LFM, PMHF

ASIL C ve D seviyesindeki donanımlar, niteliksel süreç gereksinimlerinin yanı sıra niceliksel donanım güvenilirlik hedeflerini de karşılamak zorundadır:

• SPFM (Single Point Fault Metric): Sistemin, kendi başına doğrudan tehlikeye yol açabilecek “tekil nokta arızalarına” (single point faults) karşı ne oranda korunduğunu ölçer. ASIL D için tipik hedef $\ge \%99$.
• LFM (Latent Fault Metric): Kendi başına tehlikeli olmayan ama ikinci bir arızayla birleştiğinde tehlikeli hale gelebilecek gizli (latent) arızaların ne oranda tespit edildiğini ölçer (ör. bir yedek kanalın sessizce bozulmuş olması, sürücü fark etmeden). ASIL D için tipik hedef $\ge \%90$.
• PMHF (Probabilistic Metric for random Hardware Failures): Sistemin rastgele donanım arızası nedeniyle Güvenlik Hedefini ihlal etme olasılığının saatlik oranı. ASIL D için tipik hedef $< 10^{-8}\ \text{saat}^{-1}$ (yani 10 FIT — Failures In Time, $10^9$ cihaz-saatte 10 arıza).

Bu üç metrik birlikte, “sistem arıza yapmayacak” gibi imkânsız bir iddiada bulunmaz — bunun yerine arızaların istatistiksel olarak son derece düşük olasılıkta kalmasını ve arıza olduğunda tespit edilebilir olmasını güvence altına alır. Bu, redundancy (yedeklilik) ve arıza tespit mekanizmalarının (ör. lockstep çekirdekler, watchdog zamanlayıcılar, ADC’lerde çift-kanal okuma) neden ASIL D sistemlerinde neredeyse evrensel olduğunu açıklar.

---

8. FTTI ve Güvenli Durum

FTTI (Fault Tolerant Time Interval), bir arızanın ortaya çıkışı ile tehlikeli olayın gerçekleşmesi arasında geçen süredir — sistemin arızayı tespit edip Güvenli Duruma (Safe State) geçmesi gereken maksimum zaman penceresi.

$t_{\text{arıza tespiti}} + t_{\text{tepki}} \le \mathrm{FTTI}$

CRITICAL — Güvenli Durum kavramı iki farklı biçimde gerçekleşebilir:

• Fail-Safe: Sistem fonksiyonu tamamen devre dışı bırakır (ör. ACC arızasında tork komutunu sıfırlayıp sürücüye kontrolü tamamen devretmek). L0-L2 sistemlerde yeterlidir çünkü sürücü her an devralmaya hazırdır.
• Fail-Operational: Sistem, arızaya rağmen asgari işlevselliğini bir süre daha sürdürebilmelidir (ör. bir direksiyon kanalı arızalansa bile ikinci kanal aracı yola devam ettirebilir). L3+ sistemlerde zorunludur, çünkü sürücü anlık müdahaleye hazır olmayabilir — bu farkı ve Minimal Risk Maneuvers (MRM) kavramını AD-21 ve AD-22’de daha ayrıntılı ele alacağız.

Direksiyon örneğimizde FTTI tipik olarak 50 ms mertebesindedir (130 km/s hızda araç bu sürede yaklaşık 1.8 metre yol alır) — bu da neden ASIL D sistemlerin donanım seviyesinde (yazılım döngüsünü beklemeden) çalışan lockstep karşılaştırıcılar ve donanımsal watchdog’lar kullandığını açıklar: yazılım tabanlı bir hata tespiti genellikle bu süreye sığmaz.

---

Sıkça Sorulan Sorular (FAQ)

S: ASIL, tehlikenin kendisine mi yoksa öğeye/bileşene mi atanır?

FACT — ASIL, HARA’da belirlenen her bir tehlikeye/Güvenlik Hedefine atanır, bileşenin kendisine değil. Aynı ECU, farklı Güvenlik Hedeflerine hizmet eden farklı fonksiyonlar barındırıyorsa, her fonksiyon kendi ASIL derecesini taşıyabilir (ör. aynı domain controller’daki bir ASIL D fren fonksiyonu ile bir QM konfor fonksiyonu bir arada bulunabilir — ama bunların yazılım/donanım seviyesinde yeterince izole edilmesi, “freedom from interference” ilkesiyle kanıtlanmalıdır).

S: ASIL D bir gereksinim, daha düşük ASIL’li bileşenlerle karşılanabilir mi?

INTERPRETATION — Evet, ASIL decomposition yoluyla: tek bir ASIL D gereksinim, birbirinden bağımsız (independent) iki veya daha fazla alt-yola bölünüp her birine daha düşük bir ASIL atanabilir (ör. ASIL D → ASIL B(D) + ASIL B(D)), asıl amaç bağımsızlığın kanıtlanabilir olmasıdır. Bu, tek bir pahalı ASIL D bileşen yerine iki bağımsız, birbirini çapraz kontrol eden daha ucuz kanal kullanmayı mümkün kılabilir — ama bağımsızlık analizi (ortak sebep arızaları — common cause failures) titizlikle yapılmalıdır.

S: ISO 26262 yazılıma da mı uygulanır, yoksa sadece donanıma mı?

FACT — Her ikisine de. Part 6, yazılım geliştirme sürecini (gereksinimden koda, statik analiz ve test kapsama hedeflerine kadar) kapsar; Part 5 donanımı kapsar. SPFM/LFM/PMHF donanıma özgü niceliksel metriklerdir; yazılım tarafında ise nitel süreç sıkılığı (ör. MC/DC kod kapsama hedefi ASIL D’de) esas alınır.

---

Özet

• Fonksiyonel emniyet, E/E sistemlerin arıza kaynaklı hatalı davranışından doğan riski kabul edilebilir seviyeye indirmeyi hedefler — SOTIF’in (AD-20) arızasız-ama-yetersiz senaryolarından ayrılır.
• HARA, her tehlikeyi Şiddet (S), Maruziyet (E) ve Kontrol Edilebilirlik (C) üzerinden derecelendirir; bu üçlü standart bir matrisle ASIL’e (QM, A, B, C, D) dönüşür.
• Her tehlike için bir Güvenlik Hedefi yazılır ve ASIL derecesi V-Model boyunca Teknik Güvenlik Gereksinimlerine ve donanım/yazılım tasarımına kademelenir.
• ASIL D sistemleri, niteliksel süreç gereksinimlerinin yanında SPFM $\ge \%99$, LFM $\ge \%90$, PMHF $< 10^{-8}\ \text{saat}^{-1}$ gibi niceliksel donanım hedefleri de karşılamalıdır.
• FTTI, arızanın Güvenli Duruma (fail-safe veya fail-operational) dönüştürülmesi gereken maksimum süredir; kritik direksiyon/fren fonksiyonlarında tipik olarak birkaç on milisaniye mertebesindedir.

Kaynaklar ve Doğrulama Notu

Bu ders ISO 26262:2018 (Parts 1-12) fonksiyonel emniyet standardına, onun genel endüstriyel elektrik/elektronik/programlanabilir elektronik sistemler için üst-standardı olan IEC 61508’e ve SAE J3016 otomasyon seviyesi terminolojisine dayanmaktadır. ASIL belirleme matrisi ve SPFM/LFM/PMHF sayısal eşikleri, standardın yaygın olarak alıntılanan yapısının eğitim amaçlı bir rekonstrüksiyonudur ve ASSUMPTION olarak işaretlenmiştir — kesin hücre değerleri, dipnotlar ve edisyona özgü farklılıklar için orijinal ISO 26262:2018 metnine başvurulmalıdır. ACC vaka çalışması kavramsal bir örnektir; gerçek bir HARA, OEM’in kendi istatistiksel kaza/maruziyet verisiyle yürütülür.

Sıradaki Ders

• AD-20 — SOTIF (ISO 21448): Amaçlanan Fonksiyonun Güvenliği: ISO 26262’nin arıza-odaklı çerçevesinin neden AI/ML ağırlıklı algı sistemleri için tek başına yeterli olmadığını, dört senaryo alanı çerçevesini ve “hiçbir parça bozulmadan” ortaya çıkan riskleri inceleyeceğiz.