- ODD'nin SAE J3016'daki resmi tanımını ve neden Seviye 0'ın üzerindeki HER otomasyon fonksiyonunun temel güvenlik kavramı olduğunu açıklayabilmek.
- ODD taksonomisini dört sistematik boyutta (Yol Tipi, Çevresel Koşullar, Hız Aralığı, Trafik/Zamansal Koşullar) BSI PAS 1883 ve ISO 34503 çerçevesiyle analiz edebilmek.
- ODD dışında çalışmanın neden 'daha az yetenekli' bir mod değil, doğrulanmamış/tanımsız davranış rejimi olduğunu değerlendirebilmek.
- Geofencing, gerçek zamanlı çevresel algılama ve hız eşikleriyle ODD sınırlarının pratikte nasıl uygulandığını kavramak.
- Mercedes-Benz Drive Pilot'un dar sertifikalı ODD'sini somut mühendislik vaka örneği olarak çözümleyebilmek.
AD-16 — Operational Design Domain (ODD): Tanım, Taksonomi ve Sınırlar
FACT — SAE J3016, Operational Design Domain’i (ODD) şöyle tanımlar: “belirli bir sürüş otomasyonu sisteminin veya özelliğinin çalışmak üzere özel olarak tasarlandığı çalışma koşulları” — yol tipi, coğrafi konum, hız aralığı, aydınlatma, hava koşulları, trafik ve yol düzenlemeleri dahil. Bu tanım kısa görünür ama otomotiv güvenlik mühendisliğinde AD-02’de tanıttığımız Dinamik Sürüş Görevi’nden (DDT) sonra en önemli ikinci kavramdır — çünkü bir otomasyon sisteminin “ne kadar iyi çalıştığı” sorusunun hiçbir anlamı yoktur, sorulması gereken tek soru **“hangi koşullar altında, doğrulanmış olarak çalışıyor”**dur.
Bu derste ODD’yi bir mühendislik disiplini olarak ele alacağız:
- ODD’nin Resmi Tanımı ve Neden Level 0’ın Üzerindeki Her Şeyin Temeli
- Taksonomi Boyutu 1 — Yol Tipi ve Altyapı
- Taksonomi Boyutu 2 — Çevresel Koşullar (Hava, Aydınlatma, Yol Yüzeyi)
- Taksonomi Boyutu 3 — Hız Aralığı: Hem Alt Hem Üst Sınır
- Taksonomi Boyutu 4 — Trafik ve Zamansal Koşullar
- Kritik Güvenlik İlkesi: ODD Dışı = Tanımsız Davranış, “Daha Az Yetenekli Mod” DEĞİL
- ODD Sınırlarının Pratikte Uygulanması: Geofencing, Algılama, Eşikler
- Vaka İncelemesi: Mercedes-Benz Drive Pilot’un Gerçek ODD’si
1. ODD’nin Resmi Tanımı ve Neden Her Şeyin Temeli
AD-02’de DDT’yi (Dynamic Driving Task) operasyonel/taktiksel/stratejik katmanlara ayırmıştık. ODD, o DDT’nin nerede, ne zaman ve hangi fiziksel koşullarda geçerli olduğunu tanımlayan zarftır (envelope). Formel olarak ODD, birbirinden bağımsız birkaç koşul kümesinin kartezyen çarpımı olarak yazılabilir:
Burada izin verilen yol tiplerinin kümesi, izin verilen hava koşulları, izin verilen aydınlatma durumları, hız aralığı ve izin verilen trafik/zamansal koşullardır. Aracın herhangi bir andaki gerçek durumu bu kümenin her bir bileşeninde aynı anda yer almadıkça, sistem ODD içinde değildir — tek bir bileşenin dışına çıkmak (örneğin hız sınırının aşılması) yeterlidir.
FACT — ODD kavramı SAE J3016’nın Seviye 0’dan (otomasyon yok) itibaren geçerlidir, ama pratik ağırlığı Seviye 1’den itibaren başlar: Level 0’da hiçbir otomasyon fonksiyonu olmadığından “hangi koşullarda çalışır” sorusu anlamsızdır. Level 1’den (örn. Adaptive Cruise Control) itibaren HER otomasyon özelliğinin kendi ODD’si vardır — ve bir üreticinin güvenlik iddiası (safety case), matematiksel olarak her zaman “bu sistem X ODD’si içinde güvenlidir” biçiminde kurulur, asla koşulsuz bir “güvenlidir” iddiası olarak kurulamaz.
2. Taksonomi Boyutu 1: Yol Tipi ve Altyapı
BSI PAS 1883 ve ISO 34503, ODD’yi standart bir taksonomi ağacına oturtur. İlk boyut, aracın hangi fiziksel yol altyapısında çalışabileceğidir:
| Alt-Boyut | Örnek Değerler | Neden Önemli |
|---|---|---|
| Yol sınıfı | Otoyol (bölünmüş), şehir içi cadde, kırsal iki şeritli yol | Her sınıfın trafik yoğunluğu, kavşak sıklığı ve karşı yönlü trafik riski kökten farklı |
| Bölünmüşlük | Fiziksel bariyerli bölünmüş otoyol vs. bölünmemiş çift yönlü yol | Bölünmemiş yolda karşı şeritten gelen araçla çarpışma riski, bölünmüş otoyolda yok |
| Geofence / rota kısıtı | Önceden HD-haritalanmış, sertifikalandırılmış belirli güzergâhlar | Sistem yalnızca detaylı doğrulanmış rotalarda güvenlidir; haritalanmamış bir sapak ODD dışıdır |
| Şerit işaretleme kalitesi | Net/taze boyalı şerit çizgisi vs. silik/yok | Şerit takip algoritmaları görsel referans olmadan güvenilmez hale gelir |
| Yol geometrisi | Maksimum eğim, minimum viraj yarıçapı, kavşak/rampa yoğunluğu | Dinamik kontrol modelleri belirli bir geometrik zarf için doğrulanmıştır |
INTERPRETATION — Yol tipi boyutu genellikle geofencing ile fiziksel olarak da uygulanır (bkz. §7): sistem sadece önceden onaylanmış bir HD harita poligonunun içinde etkinleşebilir. Bu, “teorik olarak bu yol tipinde çalışabilir” ile “bu spesifik, denetlenmiş kilometre kilometre yolda çalışabilir” arasındaki farkı ortaya koyar — modern L3 sistemlerin neredeyse tamamı ikinci, çok daha dar tanımı kullanır.
3. Taksonomi Boyutu 2: Çevresel Koşullar
Hava, aydınlatma ve yol yüzeyi koşulları, AD-04 ve AD-05’te işlediğimiz sensör fiziğiyle doğrudan bağlantılıdır — her sensörün güvenilirliği belirli bir çevresel eşiğin altında/üstünde ölçülüp doğrulanmıştır, dolayısıyla ODD bu eşikleri somut sayılarla ifade eder:
| Alt-Boyut | Tipik ODD Eşiği | Fiziksel Gerekçe |
|---|---|---|
| Yağış şiddeti | Hafif yağmur < 2.5–5 mm/saat; yoğun sağanak/dolu ODD dışı | Kamera lens üzerinde su filmi, LiDAR dönüş sinyalinin sis/yağmur damlacıklarında saçılması (AD-05) |
| Görüş mesafesi | > 150–200 m | Kamera/LiDAR nesne tespiti belirli bir minimum görüş mesafesi için doğrulanmıştır |
| Aydınlatma | Gündüz / alacakaranlık / aydınlatmalı gece yolu — bazı sistemlerde sadece gündüz | Kamera dinamik aralığı ve nesne sınıflandırma modelleri ışık koşuluna göre ayrı eğitilir/doğrulanır |
| Yol yüzeyi | Kuru/ıslak asfalt; buz/kar tipik ODD dışı | Sürtünme katsayısı () değişimi fren mesafesi hesaplarını geçersiz kılar |
| Sıcaklık aralığı | Örn. −20°C ile +45°C | Sensör kalibrasyonu ve batarya/aktüatör performansı sıcaklığa bağımlıdır |
| Rüzgâr | Yanal rüzgâr hızı üst sınırı | Yüksek yanal rüzgâr, şerit tutma kontrolcüsünün doğrulanmış çalışma bandını aşabilir |
WARNING — Bu eşikler her zaman “yağmur var/yok” gibi ikili değildir — “hafif yağmur SADECE” gibi alt-eşikler (sub-thresholds) şeklinde tanımlanır. Bir sistem hafif yağmurda doğrulanmış olabilir ama orta/yoğun yağmurda hiç test edilmemiş olabilir; ara durumu ayırt edemeyen kaba bir “yağmur sensörü var/yok” mantığı, ODD tanımının inceliğini kaybettirir ve sahte güven yaratır.
4. Taksonomi Boyutu 3: Hız Aralığı — Hem Alt Hem Üst Sınır
CRITICAL — ODD’nin en sık yanlış anlaşılan yönü şudur: birçok sistemin hız kısıtı tek taraflı bir üst sınır değil, hem alt hem üst sınırlı bir bantdır. İki tipik mimari bunu net gösterir:
- Trafik Sıkışıklığı Pilotu (Traffic Jam Pilot, tipik L3): Sistem yalnızca belirli bir hızın altında (, örn. ) çalışacak şekilde tasarlanmıştır — çünkü algoritma, çok düşük hızda öndeki araca yakın takip ve sık dur-kalk senaryosu için doğrulanmıştır; yüksek hızda aynı takip mantığı güvenli fren mesafesi garantisi veremez.
- Otoyol Pilotu (Highway Pilot, tipik L2/L3): Sistem yalnızca belirli bir hızın üstünde (, örn. ) çalışacak şekilde tasarlanmıştır — çünkü düşük hızda şehir içi kavşak/yaya/bisikletli etkileşimleri, otoyol algılama modelinin hiç eğitilmediği bir senaryo sınıfıdır.
Bu iki mimarinin hız bantları birbirini tamamlayabilir ama örtüşmeyebilir de — bir aracın hem trafik-sıkışıklığı-pilotu hem otoyol-pilotu özelliği varsa, aradaki geçiş bandında ( ile arası) hiçbir otomasyon aktif olmayabilir, sürüş tamamen sürücüye döner. Bu, kullanıcı deneyiminde kafa karıştırıcı bir “otomasyon boşluğu” yaratabilir ve HMI tasarımının (AD-17’de göreceğimiz gibi) bunu açıkça iletmesi gerekir.
Hız Ekseninde ODD Bantları (Örnek İki Fonksiyon):
0 km/s v_max^TJP v_min^HWP v_max^HWP
|──── Trafik Sıkışıklığı ────| |──── Otoyol Pilotu ────|
| Pilotu (TJP) | BOŞLUK | (HWP) |
| AKTİF | (Sürücü) | AKTİF |
└─────────────────────────────────────────────────────────────────▶ hız
(örn. 60) (örn. 60-80)
5. Taksonomi Boyutu 4: Trafik ve Zamansal Koşullar
Son boyut, yolun fiziksel geometrisi veya hava durumu değil, o anki dinamik trafik bağlamıdır:
- İnşaat/çalışma alanları: Geçici şerit daralmaları, konik/bariyer dizilimi, insan trafik yönlendiricileri — HD haritada yer almayan, gerçek zamanlı değişen geometri. Çoğu sistem inşaat alanı tespit ettiğinde otomatik ODD dışına çıkar.
- Okul bölgeleri: Değişken hız limitleri, yüksek yaya yoğunluğu öngörüsü, okul saatlerine bağlı zamansal kısıt.
- Acil durum araçlarının varlığı: Yanıp sönen ışık/siren tespit edildiğinde (bkz. AD-06 algı katmanı), birçok yargı alanında yasal olarak şerit değiştirme/yavaşlama zorunluluğu doğar — bu davranışın ODD içinde tanımlı ve doğrulanmış olması gerekir, aksi halde sistem devreden çıkmalıdır.
- Trafik yoğunluğu rejimi: Akıcı trafik vs. dur-kalk sıkışık trafik farklı takip mesafesi/ivme profilleri gerektirir; bazı sistemler yalnızca birinde doğrulanmıştır.
EXAMPLE — Bir otoyol pilotu sistemi düşünün: yol tipi (bölünmüş otoyol ✓), hava (açık ✓), hız (95 km/s, aralıkta ✓) — dört boyuttan üçü ODD içinde. Ama önde bir inşaat alanı konileri belirdiğinde dördüncü boyut (trafik/zamansal koşullar) anlık olarak ODD dışına çıkar. Sistem, diğer üç boyut hâlâ uygun olsa bile tüm ODD tanımı bir bütün olduğundan devre dışı kalmak zorundadır — kısmi uygunluk, ODD içinde sayılmaz.
6. Kritik Güvenlik İlkesi: ODD Dışı = Tanımsız Davranış
CRITICAL — Bu dersin en önemli tek cümlesi budur: ODD dışında çalışan bir sistem, “daha az yetenekli” bir versiyonu değildir — davranışı doğrulanmamış ve tanımsızdır. Bu ayrım yüzeysel görünse de güvenlik mühendisliğinin temelini oluşturur.
Neden? Çünkü modern bir ADAS/ADS yığınının her katmanı — algı (perception) modelleri, izleme (tracking) filtreleri, planlama sezgiselleri, kontrol kazançları — belirli bir veri dağılımı üzerinde eğitilmiş ve/veya belirli bir fiziksel varsayım kümesi altında türetilmiştir. ISO 21448 (SOTIF — Safety of the Intended Functionality) bu kavramı resmileştirir: bir sistemin performans sınırlamaları, sadece arızalarla değil, sistemin hiç görmediği veya doğrulamadığı senaryo alanıyla da ilişkilidir. ODD dışına çıkmak, tam olarak bu “bilinmeyen-güvensiz” (unknown-unsafe) bölgeye girmek demektir:
SOTIF Senaryo Alanı Sınıflandırması (ISO 21448):
┌─────────────────────────────────────────────┐
│ TÜM OLASI SENARYOLAR │
│ ┌───────────────────────────────────────┐ │
│ │ ODD (Tanımlı Alan) │ │
│ │ ┌─────────────┐ │ │
│ │ │ Bilinen- │ Bilinen- │ │
│ │ │ Güvenli │ Güvensiz │ │
│ │ │ (Doğrulanmış)│ (Test edilmiş, │ │
│ │ │ │ mitigasyon var) │ │
│ │ └─────────────┘ │ │
│ └───────────────────────────────────────┘ │
│ │
│ ODD DIŞI = "Bilinmeyen" Bölge │
│ (Ne güvenli ne güvensiz olduğu │
│ HİÇ doğrulanmamış — davranış tanımsız) │
└─────────────────────────────────────────────┘
Somut bir örnek: bir otoyol pilotu sisteminin nesne algılama sinir ağı, milyonlarca kilometrelik otoyol görüntüsüyle eğitilmiş ve doğrulanmış olabilir. Bu ağ, aniden buzlu bir dağ yolunda ya da toz fırtınasında çalıştırılırsa — teorik olarak “hâlâ çalışabilir” görünse de — çıktısının doğruluğu hakkında hiçbir istatistiksel garanti yoktur. Sistem yanlış bir nesne sınıflandırması yapabilir, bir engeli tamamen kaçırabilir veya gereksiz bir acil fren tetikleyebilir; bunların hiçbiri “beklenen, biraz daha kötü performans” değil, doğrulama zarfının tamamen dışında, öngörülemeyen bir davranıştır.
Bu yüzden ODD-çıkışı tespiti (ODD-exit detection) ve zorunlu fallback (AD-17’nin konusu), isteğe bağlı bir “iyi olursa iyi olur” özelliği değil, sert bir güvenlik gereksinimidir: sistem kendi doğrulama sınırının neresinde olduğunu her an bilmek ve o sınıra yaklaştığında/aştığında kontrolü güvenli biçimde bırakmak zorundadır.
7. ODD Sınırlarının Pratikte Uygulanması
ODD tanımı kağıt üzerinde bir taksonomi olsa da, gerçek zamanlı bir araçta bu tanımın sürekli, düşük gecikmeli olarak denetlenmesi gerekir. Üç ana uygulama mekanizması vardır:
7.1 Geofencing (Coğrafi Sınırlama)
Yol tipi/rota boyutu genellikle önceden onaylanmış bir HD harita poligonu ile uygulanır. Aracın gerçek zamanlı GNSS-RTK konumu (bkz. AD-04 §6), bu poligonun içinde olup olmadığı için bir point-in-polygon testinden geçirilir. Poligon dışına çıkış anında ODD ihlali tetiklenir.
7.2 Gerçek Zamanlı Çevresel Algılama
Hava/görüş/yol yüzeyi koşulları statik bir harita ile bilinemez — araç bunu kendi sensörleriyle sürekli tahmin etmek zorundadır: yağmur sensörü, kamera görüntüsündeki kontrast/bulanıklık analizinden çıkarılan görüş mesafesi tahmini, tekerlek kayma oranından çıkarılan yol yüzeyi sürtünme tahmini.
7.3 Hız Eşiği Denetimi
En basit ama en sık tetiklenen mekanizma: aracın anlık hızı bandının dışına çıktığı an, sistem ya etkinleşemez ya da (etkinken sınırı aşarsa) devre dışı kalma sürecini başlatır.
Bu üç mekanizma birleşerek, aracın her an ODD içinde olup olmadığını söyleyen bir mantıksal gösterge (indicator) üretir:
Bu çarpım yapısı kasıtlıdır: tek bir gösterge sıfır olduğunda tüm ifade sıfır olur — yani ODD dört boyuttan sadece birinin dışına çıkması bile yeterlidir, “üç boyut tamam, biri eksik ama sorun değil” diye bir tolerans yoktur.
ODD Sınır İzleme Çalışma Döngüsü (Runtime):
[GNSS+Harita] [Hız Sensörü] [Kamera/Yağmur Sens.] [Trafik/Zaman Bilgisi]
│ │ │ │
▼ ▼ ▼ ▼
Geofence Testi Hız Bandı Testi Çevre Eşiği Testi Bağlam Testi
│ │ │ │
└──────────────┴────────┬───────┴────────────────────┘
▼
InODD(x_t) = ÇARPIM
│
┌───────────────┴───────────────┐
▼ ▼
1 (ODD İçinde) 0 (ODD Dışı)
│ │
Otomasyon Devam Eder → AD-17: Fallback / MRM Başlar
INTERPRETATION — Pratikte üreticiler genellikle sınıra “aniden” değil, önceden bir uyarı bandı (boundary warning zone) ile yaklaşır — örneğin geofence sınırına 2 km kala veya hava koşulu eşiğe yaklaştığında sürücüye erken bir devralma çağrısı gönderilir. Bu, ani/sert bir ODD-çıkışı yerine öngörülebilir, kademeli bir geçiş sağlar — AD-17’de bu eskalasyon mantığını detaylı işleyeceğiz.
8. Vaka İncelemesi: Mercedes-Benz Drive Pilot
ASSUMPTION — Aşağıdaki parametreler Mercedes-Benz’in kamuya açık DRIVE PILOT açıklamalarına ve düzenleyici onay süreçlerine (Almanya UNECE R157 tabanlı, ABD Nevada/California eyalet onayları) dayanır; tam güncel liste, kapsanan otoyol kilometreleri ve hız eşiği üretici/model yılına ve yargı alanına göre değişebilir ve zaman içinde genişletilmiştir — kesin güncel kapsam için üretici dokümantasyonu doğrulanmalıdır.
DRIVE PILOT, koşullu (SAE Level 3) otomasyon için sertifika alan ilk üretim sistemlerinden biri olarak, ODD’nin ne kadar dar ve kesin tanımlanabileceğinin somut bir örneğidir:
| Taksonomi Boyutu | DRIVE PILOT’un ODD’si (yaklaşık, ilk sertifikasyon aşaması) |
|---|---|
| Yol tipi | Önceden onaylanmış, HD haritalanmış, fiziksel orta refüjli belirli bölünmüş otoyol segmentleri (geofence) |
| Çevre | Yalnızca gündüz, açık/kuru hava koşulları — yoğun yağmur, kar, sis ODD dışı |
| Hız | (tipik ilk sertifikasyonda; sonraki güncellemelerde genişletilmesi planlanmıştır) |
| Trafik | Yoğun/dur-kalk otoyol trafiği (öndeki araç takibi mevcut) — inşaat alanı, kaza sahnesi ODD dışı |
| Diğer | Sistem sürücüden gözlerini yoldan ayırmasına izin verir ama uykuya dalmasına izin vermez (bkz. AD-18 DMS bağlantısı) |
INTERPRETATION — DRIVE PILOT’un ODD’sinin bu kadar dar olması bir zaaf değil, bilinçli bir mühendislik/regülasyon stratejisidir: L3’te sorumluluk sistemdedir (AD-02, AD-17), dolayısıyla üretici her bir boyutu aşırı muhafazakâr tutarak “bilinen-güvenli” (bkz. §6 diyagramı) bölgeyi olabildiğince küçük ama %100 doğrulanmış tutmayı tercih eder. Zaman içinde ODD kapsamı (daha yüksek hız, daha fazla yol segmenti, farklı hava koşulları) kademeli olarak genişletilir — her genişleme, o yeni alt-alanın ayrıca doğrulanmasını gerektiren ayrı bir sertifikasyon çabasıdır, “otomatik olarak” büyümez.
Sıkça Sorulan Sorular (FAQ)
S: Bir sistem ODD’sinin dışına çıktığında hemen mi durur?
INTERPRETATION — Hayır, çoğu üretim sisteminde ani bir durma yerine kademeli bir geçiş süreci vardır: önce sürücüye devralma çağrısı (Take-Over Request), yanıt yoksa sistemin kendi yürüttüğü bir Minimum Risk Manevrası (MRM). Bu mekanizmanın tam detayını AD-17’de işleyeceğiz.
S: ODD statik bir belge midir, yoksa araç bunu gerçek zamanlı mı hesaplar?
FACT — İkisi birden: ODD’nin tanımı (hangi yol tipleri, hangi hız aralığı, hangi hava eşikleri) geliştirme/sertifikasyon aşamasında sabitlenen statik bir spesifikasyondur. Ama aracın o an ODD içinde olup olmadığı (§7’deki InODD göstergesi), her sürüş anında gerçek zamanlı sensör/harita verisiyle sürekli yeniden hesaplanır.
S: Genişletilmiş bir ODD (örneğin daha yüksek hız limiti) yazılım güncellemesiyle mi gelir?
ASSUMPTION — Üreticiye ve yargı alanına bağlı olarak evet, genellikle OTA (over-the-air) yazılım güncellemesiyle mümkündür — ama her genişleme, yeni alt-alanın ayrı bir güvenlik doğrulama/sertifikasyon sürecinden geçmesini gerektirir; bu, kesin bir yasal/teknik süreçtir ve üreticiden üreticiye, ülkeden ülkeye değişir.
Özet
- ODD (Operational Design Domain), SAE J3016’ya göre bir sürüş otomasyonu fonksiyonunun güvenle çalışmak üzere tasarlandığı çalışma koşulları bütünüdür; her otomasyon özelliğinin (Level 1’den itibaren) kendi ODD’si vardır.
- ODD taksonomisi dört sistematik boyuta ayrılır: Yol Tipi/Altyapı, Çevresel Koşullar, Hız Aralığı (hem alt hem üst sınırlı olabilir) ve Trafik/Zamansal Koşullar.
- ODD, boyutların kartezyen çarpımı ve mantıksal VE (AND) ilişkisidir — tek bir boyutun dışına çıkmak, sistemin tüm ODD tanımının dışına çıkması için yeterlidir.
- ODD dışında çalışmak “daha az yetenekli mod” değil, doğrulanmamış/tanımsız davranış rejimine girmektir (ISO 21448/SOTIF çerçevesinde “bilinmeyen” senaryo bölgesi) — bu yüzden ODD-çıkışı tespiti ve zorunlu fallback sert bir güvenlik gereksinimidir.
- ODD sınırları pratikte geofencing, gerçek zamanlı çevresel algılama ve hız eşiği denetimiyle sürekli izlenir; sınıra yaklaşma genellikle önceden bir uyarı bandıyla, ani bir kesintiden ziyade kademeli bir geçişle yönetilir.
- Mercedes-Benz DRIVE PILOT, kasıtlı olarak çok dar tutulmuş (belirli otoyol segmentleri, ≤60 km/s, gündüz, açık hava) bir L3 ODD’sinin gerçek dünya örneğidir; kapsam zaman içinde ayrı sertifikasyon adımlarıyla genişler.
Kaynaklar ve Doğrulama Notu
Bu derste sunulan ODD tanımı ve taksonomisi SAE J3016 terminolojisine, BSI PAS 1883 ve ISO 34503 ODD taksonomi standartlarına ve ISO 21448 (SOTIF) çerçevesine dayanmaktadır. Mercedes-Benz DRIVE PILOT’a ilişkin spesifik parametreler kamuya açık üretici/düzenleyici açıklamalarına dayanır ve ASSUMPTION olarak işaretlenmiştir; kesin güncel kapsam için üretici dokümantasyonu ve ilgili yargı alanının düzenleyici onay metinleri doğrulanmalıdır.
Sıradaki Ders
- AD-17 — Fallback Stratejileri, MRM ve Emniyetli Durum (MRC): Bu derste tanımladığımız ODD sınırına ulaşıldığında veya aşıldığında sistemin ne yaptığını — DDT Fallback, Minimum Risk Manevrası (MRM) ve Minimum Risk Durumu (MRC) arasındaki farkı ve kademeli uyarı/devralma mimarisini — detaylı işleyeceğiz.
Teknik Diyagramlar
Quiz
ODD (Operasyonel Tasarım Alanı) temel olarak neyi tanımlar?
ODD, sistemin güvenle çalışabileceği onaylanmış çalışma şartları kümesidir.
Hangisi bir Otoyol Pilotunun ODD kısıtına örnektir?
Bölünmüş yol tipi ve hız sınırı temel ODD parametreleridir.
Yoğun kar yağışı başladığında ODD monitörü ne kararı verir?
Kar yağışı sensörleri körelttiği için ODD dışına çıkış kararı verilir ve devralma talep edilir.
BSI PAS 1883 standardı otomotiv mühendisliğinde hangi alanda referans taksonomidir?
BSI PAS 1883 ODD taksonomisi için uluslararası kabul gören standarttır.
Otonom araç ODD sınırına yaklaştığında (örn. otoyol çıkışına 1 km kala) sistem ne yapar?
Sınır yaklaşırken sürücünün güvenle devralabilmesi için önceden TOR uyarısı iletilir.
Sözlük (Glossary)
| English Term | Türkçe | Tanım |
|---|---|---|
| Operational Design Domain (ODD) | Operasyonel Tasarım Alanı (ODD) | Bir sürüş otomasyonu fonksiyonunun veya ADS sisteminin emniyetle çalışmak üzere özel olarak tasarlandığı hız, coğrafi alan, yol tipi, hava ve aydınlatma koşulları kümesi. |