Otonom Sistemlerde Güvenlik ve Doğrulama Terimleri: Temel Kılavuz

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

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)