- ISO 26262'nin amacını ve HARA/ASIL kavramlarını açıklayabilmek.
- Tehlikeden güvenlik hedefine, oradan güvenlik mekanizmasına giden zinciri izleyebilmek.
- Şiddet (severity), maruziyet (exposure) ve kontrol edilebilirliği ASIL girdileri olarak özetleyebilmek.
- Fail-safe ile fail-operational arasındaki farkı örneklerle ifade edebilmek.
- Fonksiyonel güvenliğin neden sadece bir BMS konusu değil, araç düzeyinde bir disiplin olduğunu açıklayabilmek.
EV-34 — Fonksiyonel Güvenlik
ASSUMPTION — Bu ders, fonksiyonel güvenlik çerçevesini tüm araç düzeyinde tanıtır. Batarya sistemine özel derin teknik içerik BMS Academy → BMS-17’dedir; burada verilen ASIL seviyeleri veya güvenlik hedefi örnekleri yalnızca öğretici amaçlıdır, gerçek bir atama değildir.
1. “Çalışıyor” Olmak “Güvenli” Olmak Anlamına Gelmez
Bir kontrol sistemi her fonksiyonel testi geçebilir ve yine de güvensiz olabilir; çünkü fonksiyonel test, sistemin normal koşullarda beklendiği gibi çalışıp çalışmadığını kontrol eder, güvenlik mühendisliği ise farklı bir soru sorar: yine de bir şeyler ters giderse ne olur? Bir elektrikli araçta “bir şeylerin ters gitmesi”, bir sensörün eski bir değerde donması, bir yazılım görevinin süresini kaçırması, bir konektörün korozyona uğraması veya bir haberleşme mesajının kaybolması anlamına gelebilir — ve araç yüksek voltajlı bir enerji kaynağı taşıdığından ve tahrik torkunu doğrudan tekerleklere ilettiğinden, her iki alandaki yönetilmemiş bir arıza elektrik çarpmasına, yangına veya istenmeyen araç hareketine dönüşebilir. ISO 26262, tam olarak bu akıl yürütmeyi bireysel mühendislik takdirine bırakmak yerine sistematik hale getirmek için vardır: her makul tehlike belirlenmeli, riski sınıflandırılmalı ve gerçek riskle orantılı bir geliştirme titizliği uygulanmalıdır.
FACT — ISO 26262 tek bir güvenlik çözümü dayatmaz; titizliğini gerçek riske göre ölçekleyen bir süreç dayatır — tehlike tespiti, risk sınıflandırması ve doğrulanmış mekanizmalara kadar izlenebilir güvenlik gereksinimleri.
2. Tehlikeden ASIL’e: HARA
Bir tehlike (hazard), bir arızadan kaynaklanan potansiyel bir zarar kaynağıdır — örneğin “istenmeyen araç hızlanması” veya “fren tork talebinin kaybı”. HARA (Hazard Analysis and Risk Assessment), her tehlikeyi üç bağımsız boyutta değerlendirir; ve ortaya çıkan risk sınıfını belirleyen, bunlardan yalnızca biri değil, üçünün birlikte bileşimidir:
| Boyut | Neyi sorar |
|---|---|
| Şiddet (Severity) | Tehlike gerçekleşirse zarar ne kadar ciddi olur? |
| Maruziyet (Exposure) | Araç, bu tehlikenin oluşabileceği durumda ne sıklıkla çalışır? |
| Kontrol edilebilirlik (Controllability) | Sürücü (veya başka bir güvenlik katmanı) ne kadar iyi tepki verip zararı önleyebilir? |
Sonuç bir ASIL (Automotive Safety Integrity Level) değeridir: QM (standart kalite yönetimi ötesinde özel güvenlik gereksinimi yok), A, B, C ve D — D en yüksek titizliği temsil eder. Şiddetli, sık gerçekleşen ve sürücünün telafi etmesi zor olan bir tehlike yüksek ASIL kazanır; şiddetli ama son derece nadir ve iyi kontrol edilebilir bir tehlike çok daha düşük bir ASIL kazanabilir. Bu nedenle örneğin, kontrolsüz tahrik torku veya direksiyon desteğinin kaybı gerçek programlarda tipik olarak ASIL C/D’ye doğru iterken, bir konfor özelliği arızası tipik olarak QM’de kalır — ancak gerçek bir araçtaki fiili değer yalnızca tam bir HARA ile belirlenebilir, bu ders gibi bir kaynaktan asla varsayılamaz.
ASSUMPTION — Bu derste bahsedilen herhangi bir ASIL değeri veya tehlike örneği yalnızca öğretim amaçlıdır; gerçek bir ASIL ataması, söz konusu araç ve mimariye özgü sistematik bir HARA gerektirir.
3. Güvenlik Hedefinden Somut Tasarıma
Bir tehlike ASIL kazandığında, mühendisliğin bu soyut risk sınıflandırmasını inşa edilebilir bir şeye dönüştürmesi gerekir. Bir güvenlik hedefi (safety goal), tehlikeden doğrudan türetilen üst düzey gereksinimdir — “istenmeyen tahrik torkunu önle” veya “çarpışma sonrası HV enerjisinin tanımlı bir süre içinde kesilebilmesini sağla” gibi. Bu tek cümle daha sonra giderek somutlaşan iki katmana ayrıştırılmalıdır. Functional Safety Concept (Fonksiyonel Güvenlik Konsepti), herhangi bir spesifik donanımdan bağımsız olarak ne olması gerektiğini belirtir — örneğin “tork talebi, uygulanmadan önce en az iki bağımsız ve çeşitli hesaplama yolu tarafından doğrulanmalıdır”. Technical Safety Concept (Teknik Güvenlik Konsepti) ise bunun belirli bir mimaride gerçekte nasıl uygulanacağını belirtir — örneğin “birincil tork yolu ana inverter kontrolöründe çalışır; bağımsız bir izleme çekirdeği, komut edilen torku gaz pedalı sinyaliyle çapraz kontrol eder ve uyumsuzlukta güvenli bir tork sınırı zorlar”. Bu iki katmanı ayırmak önemlidir çünkü aynı fonksiyonel gereksinimin, güvenlik hedefini her seferinde yeniden türetmeden, farklı araç platformlarında farklı donanım çözümleriyle karşılanmasına imkan tanır.
4. Güvenlik Mekanizmaları ve Tanısal Kapsama (Diagnostic Coverage)
Bir güvenlik mekanizması (safety mechanism), bir arızayı tespit eden veya oluştuğunda etkisini sınırlayan somut donanım/yazılım özelliğidir — örnekler arasında bağımsız kontaktör durumu geri beslemesi (EV-03, BMS Academy → BMS-06), takılı kalmış bir yazılım görevini yakalayan bir watchdog zamanlayıcısı veya iki bağımsız tork sensörü arasındaki makul olabilirlik (plausibility) kontrolleri sayılabilir. Tanısal kapsama (Diagnostic Coverage — DC), verilen bir mekanizmanın tehlikeli arıza alanının ne kadarını gerçekten yakaladığını yüzde olarak ifade eder:
DC (%) = (Mekanizma tarafından tespit edilen tehlikeli arızalar / Toplam tehlikeli arızalar) × 100
ASSUMPTION — Gerçek tanısal kapsama sayıları, bir bileşen ve mimariye özgü sistematik bir FMEA’dan (Failure Mode and Effects Analysis) gelir; bu ders yalnızca kavramı tanıtır, gerçek bir rakamla karıştırılabilecek bir örnek yüzde vermez.
Bir arıza tespit edildikten sonra, sistemin tanımlı bir fault reaction (arıza tepkisi)’a geçmesi gerekir — bu, fonksiyonel güvenliği EV-33’te kavramsal olarak tanıtılan arıza yönetimi ve durum makinesi mantığıyla bağlar.
5. Fail-Safe ve Fail-Operational
Her güvenlik tepkisi aynı görünmez; aşağıdaki iki geniş stratejiden hangisinin seçileceği, aracın söz konusu fonksiyonunun gerçekte ne olduğuna büyük ölçüde bağlıdır. Fail-safe tasarım, bir arıza tespit edildiği anda sistemi bilinen güvenli bir duruma taşır — bir tahrik inverteri için bu tipik olarak torkun kesilmesi ve gerekirse HV kontaktörlerinin açılması anlamına gelir, çünkü sadece durmak, tahrik için kabul edilebilir bir güvenli durumdur. Fail-operational tasarım ise bunun aksine, yedeklilik (redundancy) kullanarak bir fonksiyonu arıza boyunca çalışır tutar; çünkü hemen durmak kabul edilebilir bir sonuç değildir — otonom sürüş manevrası sırasında direksiyon veya frenleme klasik örnektir; manevra ortasında kontrolsüz bir araç kendisi tehlikeli olurdu. Fail-operational sistemler, çoğaltılmış (ve idealde çeşitlendirilmiş) algılama, hesaplama ve eyleme geçirme yolları gerektirdiğinden doğası gereği daha karmaşık ve maliyetlidir; bu yüzden yalnızca “sadece dur”un güvenli bir seçenek olmadığı fonksiyonlar için ayrılırlar.
6. Sık Sorulan Sorular (FAQ)
ASIL gerçekte neyi ifade eder?
FACT — ASIL, HARA tarafından şiddet, maruziyet ve kontrol edilebilirliğin birlikte değerlendirilmesiyle atanan bir risk sınıflandırmasıdır (QM, A–D); ilgili gereksinimin ne kadar titizlikle geliştirilip doğrulanması gerektiğini yönlendirir, bir bileşenin tek başına ne kadar “tehlikeli” olduğunun doğrudan bir ölçüsü değildir.
Güvenlik hedefi (safety goal) somut olarak nedir?
FACT — Güvenlik hedefi, tehlikeden türetilen üst düzey, donanımdan bağımsız güvenlik gereksinimidir (örn. “istenmeyen hızlanmayı önle”); bilinçli olarak donanımdan bağımsızdır ve önce fonksiyonel, sonra teknik güvenlik konseptine detaylandırılır.
Fail-operational her zaman fail-safe’den “daha iyi” midir?
INTERPRETATION — Otomatik olarak değil — fail-operational, yedeklilik yoluyla gerçek bir maliyet ve karmaşıklık ekler; bu yüzden yalnızca anlık durmanın kendisinin güvensiz olduğu durumlarda (örn. otonom sürüş sırasında direksiyon) uygulanır, fail-safe’e genel bir üst sürüm olarak değil.
7. Özet
- ISO 26262, güvenlik mühendisliğini sistematik hale getirir: tehlike → HARA → ASIL → güvenlik hedefi → güvenlik konsepti → güvenlik mekanizması.
- Şiddet, maruziyet ve kontrol edilebilirlik — tek tek değil, birlikte — ASIL’i belirler.
- Fonksiyonel Güvenlik Konsepti “ne olması gerektiğini”, Teknik Güvenlik Konsepti “nasıl uygulandığını” yanıtlar.
- Tanısal kapsama, bir güvenlik mekanizmasının tehlikeli arıza alanının ne kadarını gerçekten yakaladığını ölçer.
- Fail-safe, arızada fonksiyonu güvenli şekilde durdurur; fail-operational, yedeklilik yoluyla çalışır tutar ve yalnızca durmanın kendisinin güvensiz olduğu yerlerde kullanılır.
8. Kaynaklar ve Doğrulama Notu
Referans verilen standart ISO 26262’dir; bu derste yer alan tüm ASIL ve güvenlik hedefi örnekleri öğretici niteliktedir ve bağlayıcı değildir.
- ISO 26262 — Karayolu taşıtları, fonksiyonel güvenlik.
- SAE J1715 — hibrit ve elektrikli araç terminolojisi.
ASSUMPTION — Kaynakların güncel sürüm/başlıkları değişebilir; yayın öncesi her kaynak yeniden doğrulanmalıdır.
Sıradaki Ders
- EV-35 — Siber Güvenlik (ISO/SAE 21434): secure boot ve OTA güvenliği.
Teknik Diyagramlar
Quiz
ISO 26262 neyi standartlaştırır?
ISO 26262, karayolu taşıtlarında E/E sistemlerin fonksiyonel güvenliğini standartlaştırır.
ASIL nedir?
ASIL (Automotive Safety Integrity Level), güvenlik bütünlük seviyesidir.
HARA ne yapar?
HARA, tehlike analizi ve risk değerlendirmesi yapar.
Safety goal nedir?
Safety goal, bir tehlikeden türetilen üst düzey güvenlik amacıdır.
Fail-operational ne yapar?
Fail-operational, arıza durumunda işlevi sürdürür (örn. otonom sürüş).
ASIL D ne anlama gelir?
ASIL D, en yüksek güvenlik bütünlük seviyesidir.