Otonom sistemler (robotlar, sürüş otomasyonu, depo araçları, dronlar, endüstriyel mobil platformlar) gerçek dünyada çalıştıkça güvenlik tartışmaları da “doğru terimleri doğru yerde kullanma” ihtiyacıyla büyür. Aynı kelime farklı ekiplerde farklı anlamlara gelebilir: fail-safe kimine göre “durmak”, kimine göre “kontrollü şekilde riski azaltmak”; validation kimine göre “test”, kimine göre “gereksinime uygunluk” demektir.

Bu temel kılavuz, güvenlik ve doğrulama terminolojisini pratik bir sözlük gibi ele alır ve terimleri sahada kullanılan güvence yaklaşımlarına bağlar. Özellikle UL 4600’ın güvenlik kanıtı (safety case) odağı (UL Solutions), ISO 21448 (SOTIF)’in “niyet edilen işlevsellikten doğan riskler” yaklaşımı (ISO kütüphane özeti), FAA’nın öğrenen bileşenler için güvence yol haritası (FAA PDF) ve SAE J3016’nın otomasyon seviyeleri sözlüğü (SAE) referans alınmıştır.

Önce çerçeve: Doğrulama (verification) ve geçerleme (validation) nedir?

Güvenlik tartışmalarında iki temel soru vardır:

  • Verification (doğrulama): “Sistemi doğru mu inşa ettik?” Gereksinimlere, tasarıma ve standartlara uygunluk; birim testleri, entegrasyon testleri, kod incelemeleri, statik analiz, biçimsel yöntemler gibi kanıtlarla desteklenebilir.
  • Validation (geçerleme): “Doğru sistemi mi inşa ettik?” Kullanım bağlamında (çevre, görev, kullanıcı, operasyon) amaçlanan ihtiyacı karşılıyor mu ve kabul edilebilir risk seviyesinde mi çalışıyor?

Otonom sistemlerde bu ayrım kritikleşir; çünkü sistemin “gereksinimleri” bile zamanla olgunlaşır. Bu yüzden birçok güvence yaklaşımı, yalnızca laboratuvar testleriyle bitmeyen; operasyon sırasında izlemeyi ve geri beslemeyi de içeren bir kanıt zinciri kurmaya çalışır (ör. UL 4600’ın hizmette izleme ve performans göstergeleri vurgusu). (S1)

Güvenlik kanıtı (Safety Case): “Neyi, hangi kanıtla, hangi varsayımla savunuyorsunuz?”

Safety case, bir sistemin belirli bir bağlamda yeterince güvenli olduğuna dair yapılandırılmış argüman ve kanıt bütünüdür. UL 4600 gibi çerçeveler, otonom ürünler için bu yaklaşımı merkezî görür. (S1)

Pratikte bir safety case şunları açıkça görünür kılar:

  • Kapsam: Sistem sınırları, görev tanımı, kullanım ortamı.
  • Varsayımlar: Harita güncelliği, sensör bakım aralığı, kullanıcı davranışı gibi “doğruysa güvenlik argümanı ayakta durur” türünden koşullar.
  • Tehlikeler ve riskler: Hangi tehlikelerin ele alındığı, hangilerinin kapsam dışı olduğu.
  • Kanıtlar: Test sonuçları, senaryo kapsaması, hata analizi, izleme verileri, süreç kanıtları.
  • Değişiklik yönetimi: Yazılım güncellemesi veya model güncellemesi sonrası kanıtın nasıl güncelleneceği.

Not: Safety case “tek bir rapor” değil, ürün yaşam döngüsü boyunca yaşayan bir dosya seti olarak düşünülmelidir; özellikle öğrenen bileşenlerde bu ihtiyaç daha da belirginleşir. FAA’nın güvence yol haritası, kanıta dayalı ve aşamalı yaklaşımları, ayrıca çalışma-zamanı gözetimini gündeme getirir. (S3)

SOTIF (ISO 21448): Arıza yokken de tehlike olabilir

SOTIF (Safety of the Intended Functionality), “sistem arızalanmadığında” bile ortaya çıkabilen tehlikelere odaklanır. Örneğin algılamanın doğal sınırları, nadir çevresel koşullar, belirsizlikler veya senaryoların sistematik olarak kapsanmaması gibi nedenler risk doğurabilir. ISO 21448’in amacı bu tür tehlikeleri tanımlamak ve azaltmak için bir süreç çerçevesi sunmaktır. (S7)

SOTIF yaklaşımı, otonom algılama ve karar verme bileşenlerinin olduğu sistemlerde (özellikle kara araçları ve robotik) şu soruları zorlar:

  • “Sistem doğru çalışırken hangi koşullarda yanlış anlar/yanlış karar verir?”
  • “Hangi köşe durumları (edge case) senaryo setimizin dışında kalıyor?”
  • “Belirsizlik yönetimi (uncertainty) ve güven aralığı (confidence) nasıl ele alınıyor?”

Bu alanda evrensel, tek bir sayısal başarı eşiği beklemek genellikle gerçekçi değildir; standartlar çoğu zaman süreç ve kanıt mantığı tanımlar, metrik seçimleri ise uygulamaya göre şekillenir. (S7)

Terimler sözlüğü: Otonom sistem güvenliği için en kritik kavramlar

Terim Kısa anlam Neden önemli? İpuçları / tipik kanıt
ODD (Operational Design Domain) Sistemin çalışmak üzere tasarlandığı çevre/koşul kümesi “Nerede güvenli?” sorusunun sınırlarını çizer; safety case kapsamını belirler ODD tanımı, dış koşullar listesi, kısıtlar; güvenlik argümanına bağlanır
Fail-safe Tehlikeli sonucu önlemek için güvenli duruma geçiş Arıza veya belirsizlikte “kontrolün nasıl kaybedilmeyeceğini” tarif eder Güvenli duruma geçiş mantığı, durma/çekilme, hız düşürme; sektöre göre değişir (UL 4600 ve SOTIF bağlamlarında tartışılır) (S1) (S7)
Redundancy (çoklama) Kritik işlevi yedekli tasarlama Tekil hata noktalarını azaltır; kullanılabilirlik ve güvenlik hedeflerine yardımcı olur Yedek sensör/hesaplama/enerji hattı; arıza tespit ve geçiş testi; izleme göstergeleri (UL 4600 bağlamı) (S1)
Diversity (çeşitlilik) Yedeklerin aynı hataya düşmemesi için farklı teknoloji/yöntem kullanma Ortak nedenli hatalara karşı dayanımı artırabilir Farklı sensör modaliteleri (kamera + radar), farklı algoritma aileleri; bağımlılık analizi
Runtime assurance (çalışma-zamanı güvence) Sistem çalışırken güvenlik koşullarını izleme ve gerektiğinde müdahale Özellikle öğrenen bileşenlerde, yalnızca ön testlerin yetmeyebileceği varsayımına yanıt verir Güvenlik monitörleri, sınır ihlali tespiti, güvenli moda geçiş; FAA yol haritasında vurgulanan bir ihtiyaç olarak ele alınır (S3)
Safety Performance Indicators (SPI) Güvenliği izlemek için seçilen operasyonel göstergeler Hizmette (in-service) izleme ve sürekli iyileştirme için ölçülebilir bir dil sağlar Olay sınıfları, ihlal sayımları, senaryo kapsaması; UL 4600 eğitim/uygulama anlatılarında öne çıkar (S1)
Scenario-based testing Senaryolar üzerinden sistem davranışını sınama Nadir ve kritik koşulları sistematik yakalamanın pratik yolu Senaryo kütüphanesi, varyasyonlar, kapsam mantığı; SOTIF düşüncesiyle uyumlu (S7)
Sim-to-real Simülasyonda öğrenilen/test edilenin gerçek dünyaya aktarımı Geliştirme hızını artırabilir; ancak simülasyon-gerçek farkı risk yaratır Domain randomization, dijital ikiz, saha geri beslemesi; literatür fayda gösterir ama “garanti” konusu sınırlıdır (S6)
Digital twin (dijital ikiz) Gerçek sistem/ortamın yüksek doğruluklu simülasyon temsili Değişiklikleri güvenli biçimde denemeye yardımcı olabilir Model doğrulama, veri uyumu, kalibrasyon; sim-to-real tartışmalarında sık geçer (S6)
Model assurance (ML güvence) ML bileşenlerinin güvenlik argümanına nasıl dahil edileceği Veri seti, eğitim süreci ve performans sınırları görünür olmazsa safety case zayıflar AMLAS gibi metodolojiler: veri seti açıklamaları, test kanıtları, izlenebilirlik artefaktları (S5)
SAE J3016 seviyeleri Sürüş otomasyonu için terim ve seviye taksonomisi Paydaşlar arası iletişimde bağlam sağlar; ancak seviye tek başına onay prosedürü anlamına gelmez Dokümantasyonda doğru terim kullanımı; kapsam sınırlarını açık tutma (S8)

Terimleri işe dönüştürme: Basit bir V&V + güvence akışı

Aşağıdaki akış, farklı sektörlerde değişse de (otomotiv, havacılık, endüstriyel robotik) ortak bir iskelet sunar. Amaç, terimleri “toplantı kelimesi” olmaktan çıkarıp somut çıktılara bağlamaktır.

1) ODD ve kullanım senaryolarını netleştirin

  • Ortam: iç mekân/dış mekân, hava koşulları, aydınlatma, zemin.
  • Etkileşim: insanlarla aynı alanı paylaşıyor mu, hız sınırları, yaklaşma mesafeleri.
  • Görev: teslimat, taşıma, denetim, navigasyon, manipülasyon.

Bu adım yapılmadan “validation” tartışması genellikle soyut kalır; çünkü doğrulanan şeyin sınırları belirsizdir.

2) Tehlike analizi + SOTIF düşüncesi ekleyin

Arızalara odaklanan klasik yaklaşımlara ek olarak SOTIF bakışıyla “arıza yokken yanlış davranış” kaynaklarını listeleyin. ISO 21448 bu sınıf riskler için süreç odaklı bir çerçeve sağlar. (S7)

3) Safety case iskeletini kurun (kanıt planı)

  • İddialar: “Sistem şu ODD’de şu riskleri azaltır.”
  • Argüman: “Bunu şu mimari kararlarla ve şu kontrollerle sağlıyoruz.”
  • Kanıt: “Şu testler, analizler, izleme çıktıları.”

UL 4600 bağlamında, in-service izleme ve göstergeler (SPI) bu kanıt zincirinin devamı olarak düşünülür. (S1)

4) ML bileşenleri varsa ayrı bir güvence dosyası açın

Öğrenen bileşenler için kanıt türleri klasik yazılımdan farklılaşır: veri setinin kapsamı, etiket kalitesi, dağılım kayması (dataset shift) riski, kalibrasyon ve belirsizlik gibi konular öne çıkar. AMLAS gibi metodolojiler, ML güvence kanıtlarının nasıl yapılandırılabileceğine dair rehber niteliğinde bir süreç önerir. (S5)

5) Simülasyonu “kanıtın bir parçası” olarak konumlandırın

Sim-to-real teknikleri geliştirmenin hızını artırabilir; ancak simülasyonun gerçek dünyayı ne kadar temsil ettiği, güvenlik argümanının hassas noktasıdır. Güncel derlemeler, domain randomization ve dijital ikiz gibi yöntemlerin yararlı olduğunu raporlar; yine de genellenebilir güvenlik garantileri konusu araştırmada aktif bir alandır. (S6)

6) Çalışma-zamanı izleme ve geri besleme döngüsü kurun

FAA’nın güvence yol haritası gibi belgelerde, yalnızca ön testlere dayanmayan; operasyon sırasında gözetim ve kanıta dayalı aşamalı yaklaşım ihtiyacı tartışılır. (S3)

  • Olay kayıtları ve sınıflandırma
  • SPI’lar (seçtiğiniz göstergeler) ve eşiklerin gözden geçirilmesi
  • Güncellemeler sonrası yeniden doğrulama (regresyon) planı

Sektöre göre hızlı okuma: Hangi terim nerede daha kritik?

Otomotiv ve kara araçları

  • SAE J3016: otomasyon seviyeleri ve rol paylaşımı dilini standardize etmek için. (S8)
  • SOTIF (ISO 21448): algılama/yorumlama sınırlarından gelen riskleri sistematik ele almak için. (S7)
  • Safety case ve operasyonel göstergeler: sahadaki performansı izlemek için (UL 4600 yaklaşımı). (S1)

Havacılık ve uzay

  • Kanıta dayalı güvence ve çalışma-zamanı izleme: öğrenen bileşenlerde onay/güvence stratejilerinin temel parçası olabilir (FAA). (S3)
  • Güvence desenleri: karmaşık otonom sistemlerde izleme, biçimsel yaklaşımlar ve sistematik güvence üzerine kurum çalışmaları bulunur (NASA). (S4)

Genel otonom ürünler (robotik, endüstri, mobil platformlar)

  • UL 4600: “ürün + süreç + kanıt” temelli genel bir güvenlik değerlendirme dili sunar. (S1)
  • Ölçüm ve doğrulama ekosistemi: güvenilir otonomi için ölçüm bilimi ve standart iş birlikleri gündemdedir (NIST). (S2)

Pratik kontrol listesi: Dokümantasyonda terimleri doğru kullanma

  • ODD’yi tek paragrafta özetleyin: “Nerede/kimle/hangi hızla/hangi koşullarda çalışır?”
  • Verification ve validation kanıtlarını ayırın: Gereksinim uygunluğu ile kullanım bağlamı uygunluğunu karıştırmayın.
  • Fail-safe’i eylem olarak yazın: “Ne zaman tetiklenir, hangi güvenli duruma geçer, ne kadar süre içinde?”
  • Redundancy + diversity bağımlılıklarını not edin: Yedekler aynı güç hattını veya aynı yazılım bileşenini paylaşıyorsa “ortak neden” riskini görünür kılın.
  • ML bileşenlerinde veri sınırlarını açıkça yazın: Eğitim verisinin kapsamadığı koşulları “bilinen sınırlamalar” olarak listeleyin; AMLAS türü yapılandırmalar bu noktada yardımcı olabilir. (S5)
  • Simülasyon sonuçlarını tek başına yeterli saymayın: Sim-to-real farkının nasıl yönetildiğini (kalibrasyon, saha testleri, izleme) ayrıca belgeleyin. (S6)
  • Seviyelerle (SAE) güvenlik iddiasını karıştırmayın: Seviye, terminoloji sağlar; doğrulama gereksinimi otomatik gelmez. (S8)

Sık yapılan kavram hataları (ve daha sağlıklı ifadeler)

  • “Fail-safe = her durumda durur” yerine: “Belirli arıza/belirsizlik koşullarında risk azaltma manevrası veya güvenli moda geçiş uygular.”
  • “Simülasyonda geçtiyse sahada da geçer” yerine: “Simülasyon kapsaması, sahadaki kanıtın bir parçasıdır; sim-to-real farkı ayrıca ele alınır.” (S6)
  • “SAE seviyesi güvenlik onayı demektir” yerine: “SAE J3016 bir terim sözlüğüdür; güvenlik kanıtı ayrı bir çalışma gerektirir.” (S8)

Son not: Bu kılavuz nasıl kullanılmalı?

Bu içerik, ekipler arası ortak dil kurmak ve güvenlik/doğrulama dokümanlarını daha tutarlı hale getirmek için hazırlanmıştır. Güvenlik-kritik sistemlerde nihai gereksinimler; sektör, ürün sınıfı, operasyon alanı ve geçerli düzenleyici beklentilere göre değişir. Uygulamada, kullandığınız standartlar ve kurum rehberleriyle uyumlu bir safety case inşa etmek en sağlıklı yaklaşımdır (ör. UL 4600, ISO 21448/SOTIF, FAA ve NIST çıktıları). (S1) (S7) (S3) (S2)