[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-otonom-sistemlerde-guvenlik-ve-dogrulama-terimleri-temel-kilavuz":3},{"dataItem":4,"heading":36,"metaData":38,"schema":81},["Reactive",5],{"id":6,"title":7,"summary":8,"content":9,"seo_title":10,"seo_description":11,"seo_keywords":12,"slug":13,"createdAt":14,"updatedAt":14,"blog_categories":15,"authors":19,"image":24,"thumb":25,"image_webp":26,"thumb_webp":27,"rating":28,"heading_title":7,"heading_sub_title":17,"readingTime":29,"url":34,"comments":35,"meta_cover":24},21475,"Otonom Sistemlerde Güvenlik ve Doğrulama Terimleri: Temel Kılavuz","Bu kılavuz, otonom sistemler ve robotikte güvenlik ve doğrulama (V&V) konuşmalarında sık geçen terimleri, ne anlama geldiklerini ve pratikte nasıl kullanıldıklarını açıklar. UL 4600 ve ISO 21448 (SOTIF) gibi çerçeveler ile FAA ve NIST’in güvence yaklaşımı vurgularını temel alarak, ekiplerin güvenlik kanıtı üretirken ortak bir dil kurmasına yardımcı olur.","\u003Cp>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: \u003Cem>fail-safe\u003C/em> kimine göre “durmak”, kimine göre “kontrollü şekilde riski azaltmak”; \u003Cem>validation\u003C/em> kimine göre “test”, kimine göre “gereksinime uygunluk” demektir.\u003C/p>\n\u003Cp>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 \u003Cstrong>UL 4600\u003C/strong>’ın güvenlik kanıtı (safety case) odağı (\u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">UL Solutions\u003C/a>), \u003Cstrong>ISO 21448 (SOTIF)\u003C/strong>’in “niyet edilen işlevsellikten doğan riskler” yaklaşımı (\u003Ca href=\"https://iso-library.com/standard/21448\">ISO kütüphane özeti\u003C/a>), \u003Cstrong>FAA\u003C/strong>’nın öğrenen bileşenler için güvence yol haritası (\u003Ca href=\"https://www.faa.gov/media/82891\">FAA PDF\u003C/a>) ve \u003Cstrong>SAE J3016\u003C/strong>’nın otomasyon seviyeleri sözlüğü (\u003Ca href=\"https://saemobilus.sae.org/standards/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles\">SAE\u003C/a>) referans alınmıştır.\u003C/p>\n\u003Chr>\n\u003Ch2>Önce çerçeve: Doğrulama (verification) ve geçerleme (validation) nedir?\u003C/h2>\n\u003Cp>Güvenlik tartışmalarında iki temel soru vardır:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Verification (doğrulama):\u003C/strong> “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.\u003C/li>\n\u003Cli>\u003Cstrong>Validation (geçerleme):\u003C/strong> “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?\u003C/li>\n\u003C/ul>\n\u003Cp>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). \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/p>\n\u003Chr>\n\u003Ch2>Güvenlik kanıtı (Safety Case): “Neyi, hangi kanıtla, hangi varsayımla savunuyorsunuz?”\u003C/h2>\n\u003Cp>\u003Cstrong>Safety case\u003C/strong>, bir sistemin belirli bir bağlamda yeterince güvenli olduğuna dair \u003Cem>yapılandırılmış\u003C/em> 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. \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/p>\n\u003Cp>Pratikte bir safety case şunları açıkça görünür kılar:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Kapsam:\u003C/strong> Sistem sınırları, görev tanımı, kullanım ortamı.\u003C/li>\n\u003Cli>\u003Cstrong>Varsayımlar:\u003C/strong> 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.\u003C/li>\n\u003Cli>\u003Cstrong>Tehlikeler ve riskler:\u003C/strong> Hangi tehlikelerin ele alındığı, hangilerinin kapsam dışı olduğu.\u003C/li>\n\u003Cli>\u003Cstrong>Kanıtlar:\u003C/strong> Test sonuçları, senaryo kapsaması, hata analizi, izleme verileri, süreç kanıtları.\u003C/li>\n\u003Cli>\u003Cstrong>Değişiklik yönetimi:\u003C/strong> Yazılım güncellemesi veya model güncellemesi sonrası kanıtın nasıl güncelleneceği.\u003C/li>\n\u003C/ul>\n\u003Cp>\u003Cstrong>Not:\u003C/strong> 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. \u003Ca href=\"https://www.faa.gov/media/82891\">(S3)\u003C/a>\u003C/p>\n\u003Chr>\n\u003Ch2>SOTIF (ISO 21448): Arıza yokken de tehlike olabilir\u003C/h2>\n\u003Cp>\u003Cstrong>SOTIF\u003C/strong> (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. \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a>\u003C/p>\n\u003Cp>SOTIF yaklaşımı, otonom algılama ve karar verme bileşenlerinin olduğu sistemlerde (özellikle kara araçları ve robotik) şu soruları zorlar:\u003C/p>\n\u003Cul>\n\u003Cli>“Sistem \u003Cem>doğru çalışırken\u003C/em> hangi koşullarda yanlış anlar/yanlış karar verir?”\u003C/li>\n\u003Cli>“Hangi köşe durumları (edge case) senaryo setimizin dışında kalıyor?”\u003C/li>\n\u003Cli>“Belirsizlik yönetimi (uncertainty) ve güven aralığı (confidence) nasıl ele alınıyor?”\u003C/li>\n\u003C/ul>\n\u003Cp>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. \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a>\u003C/p>\n\u003Chr>\n\u003Ch2>Terimler sözlüğü: Otonom sistem güvenliği için en kritik kavramlar\u003C/h2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Terim\u003C/th>\n\u003Cth>Kısa anlam\u003C/th>\n\u003Cth>Neden önemli?\u003C/th>\n\u003Cth>İpuçları / tipik kanıt\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>ODD\u003C/strong> (Operational Design Domain)\u003C/td>\n\u003Ctd>Sistemin çalışmak üzere tasarlandığı çevre/koşul kümesi\u003C/td>\n\u003Ctd>“Nerede güvenli?” sorusunun sınırlarını çizer; safety case kapsamını belirler\u003C/td>\n\u003Ctd>ODD tanımı, dış koşullar listesi, kısıtlar; güvenlik argümanına bağlanır\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Fail-safe\u003C/strong>\u003C/td>\n\u003Ctd>Tehlikeli sonucu önlemek için güvenli duruma geçiş\u003C/td>\n\u003Ctd>Arıza veya belirsizlikte “kontrolün nasıl kaybedilmeyeceğini” tarif eder\u003C/td>\n\u003Ctd>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) \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a> \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Redundancy\u003C/strong> (çoklama)\u003C/td>\n\u003Ctd>Kritik işlevi yedekli tasarlama\u003C/td>\n\u003Ctd>Tekil hata noktalarını azaltır; kullanılabilirlik ve güvenlik hedeflerine yardımcı olur\u003C/td>\n\u003Ctd>Yedek sensör/hesaplama/enerji hattı; arıza tespit ve geçiş testi; izleme göstergeleri (UL 4600 bağlamı) \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Diversity\u003C/strong> (çeşitlilik)\u003C/td>\n\u003Ctd>Yedeklerin aynı hataya düşmemesi için farklı teknoloji/yöntem kullanma\u003C/td>\n\u003Ctd>Ortak nedenli hatalara karşı dayanımı artırabilir\u003C/td>\n\u003Ctd>Farklı sensör modaliteleri (kamera + radar), farklı algoritma aileleri; bağımlılık analizi\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Runtime assurance\u003C/strong> (çalışma-zamanı güvence)\u003C/td>\n\u003Ctd>Sistem çalışırken güvenlik koşullarını izleme ve gerektiğinde müdahale\u003C/td>\n\u003Ctd>Özellikle öğrenen bileşenlerde, yalnızca ön testlerin yetmeyebileceği varsayımına yanıt verir\u003C/td>\n\u003Ctd>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 \u003Ca href=\"https://www.faa.gov/media/82891\">(S3)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Safety Performance Indicators (SPI)\u003C/strong>\u003C/td>\n\u003Ctd>Güvenliği izlemek için seçilen operasyonel göstergeler\u003C/td>\n\u003Ctd>Hizmette (in-service) izleme ve sürekli iyileştirme için ölçülebilir bir dil sağlar\u003C/td>\n\u003Ctd>Olay sınıfları, ihlal sayımları, senaryo kapsaması; UL 4600 eğitim/uygulama anlatılarında öne çıkar \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Scenario-based testing\u003C/strong>\u003C/td>\n\u003Ctd>Senaryolar üzerinden sistem davranışını sınama\u003C/td>\n\u003Ctd>Nadir ve kritik koşulları sistematik yakalamanın pratik yolu\u003C/td>\n\u003Ctd>Senaryo kütüphanesi, varyasyonlar, kapsam mantığı; SOTIF düşüncesiyle uyumlu \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Sim-to-real\u003C/strong>\u003C/td>\n\u003Ctd>Simülasyonda öğrenilen/test edilenin gerçek dünyaya aktarımı\u003C/td>\n\u003Ctd>Geliştirme hızını artırabilir; ancak simülasyon-gerçek farkı risk yaratır\u003C/td>\n\u003Ctd>Domain randomization, dijital ikiz, saha geri beslemesi; literatür fayda gösterir ama “garanti” konusu sınırlıdır \u003Ca href=\"https://arxiv.org/abs/2502.13187\">(S6)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Digital twin\u003C/strong> (dijital ikiz)\u003C/td>\n\u003Ctd>Gerçek sistem/ortamın yüksek doğruluklu simülasyon temsili\u003C/td>\n\u003Ctd>Değişiklikleri güvenli biçimde denemeye yardımcı olabilir\u003C/td>\n\u003Ctd>Model doğrulama, veri uyumu, kalibrasyon; sim-to-real tartışmalarında sık geçer \u003Ca href=\"https://arxiv.org/abs/2502.13187\">(S6)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Model assurance\u003C/strong> (ML güvence)\u003C/td>\n\u003Ctd>ML bileşenlerinin güvenlik argümanına nasıl dahil edileceği\u003C/td>\n\u003Ctd>Veri seti, eğitim süreci ve performans sınırları görünür olmazsa safety case zayıflar\u003C/td>\n\u003Ctd>AMLAS gibi metodolojiler: veri seti açıklamaları, test kanıtları, izlenebilirlik artefaktları \u003Ca href=\"https://arxiv.org/abs/2102.01564\">(S5)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>SAE J3016 seviyeleri\u003C/strong>\u003C/td>\n\u003Ctd>Sürüş otomasyonu için terim ve seviye taksonomisi\u003C/td>\n\u003Ctd>Paydaşlar arası iletişimde bağlam sağlar; ancak seviye tek başına onay prosedürü anlamına gelmez\u003C/td>\n\u003Ctd>Dokümantasyonda doğru terim kullanımı; kapsam sınırlarını açık tutma \u003Ca href=\"https://saemobilus.sae.org/standards/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles\">(S8)\u003C/a>\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\u003Chr>\n\u003Ch2>Terimleri işe dönüştürme: Basit bir V&V + güvence akışı\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Ch3>1) ODD ve kullanım senaryolarını netleştirin\u003C/h3>\n\u003Cul>\n\u003Cli>Ortam: iç mekân/dış mekân, hava koşulları, aydınlatma, zemin.\u003C/li>\n\u003Cli>Etkileşim: insanlarla aynı alanı paylaşıyor mu, hız sınırları, yaklaşma mesafeleri.\u003C/li>\n\u003Cli>Görev: teslimat, taşıma, denetim, navigasyon, manipülasyon.\u003C/li>\n\u003C/ul>\n\u003Cp>Bu adım yapılmadan “validation” tartışması genellikle soyut kalır; çünkü doğrulanan şeyin sınırları belirsizdir.\u003C/p>\n\u003Ch3>2) Tehlike analizi + SOTIF düşüncesi ekleyin\u003C/h3>\n\u003Cp>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. \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a>\u003C/p>\n\u003Ch3>3) Safety case iskeletini kurun (kanıt planı)\u003C/h3>\n\u003Cul>\n\u003Cli>İddialar: “Sistem şu ODD’de şu riskleri azaltır.”\u003C/li>\n\u003Cli>Argüman: “Bunu şu mimari kararlarla ve şu kontrollerle sağlıyoruz.”\u003C/li>\n\u003Cli>Kanıt: “Şu testler, analizler, izleme çıktıları.”\u003C/li>\n\u003C/ul>\n\u003Cp>UL 4600 bağlamında, in-service izleme ve göstergeler (SPI) bu kanıt zincirinin devamı olarak düşünülür. \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/p>\n\u003Ch3>4) ML bileşenleri varsa ayrı bir güvence dosyası açın\u003C/h3>\n\u003Cp>Öğ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. \u003Ca href=\"https://arxiv.org/abs/2102.01564\">(S5)\u003C/a>\u003C/p>\n\u003Ch3>5) Simülasyonu “kanıtın bir parçası” olarak konumlandırın\u003C/h3>\n\u003Cp>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. \u003Ca href=\"https://arxiv.org/abs/2502.13187\">(S6)\u003C/a>\u003C/p>\n\u003Ch3>6) Çalışma-zamanı izleme ve geri besleme döngüsü kurun\u003C/h3>\n\u003Cp>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. \u003Ca href=\"https://www.faa.gov/media/82891\">(S3)\u003C/a>\u003C/p>\n\u003Cul>\n\u003Cli>Olay kayıtları ve sınıflandırma\u003C/li>\n\u003Cli>SPI’lar (seçtiğiniz göstergeler) ve eşiklerin gözden geçirilmesi\u003C/li>\n\u003Cli>Güncellemeler sonrası yeniden doğrulama (regresyon) planı\u003C/li>\n\u003C/ul>\n\u003Chr>\n\u003Ch2>Sektöre göre hızlı okuma: Hangi terim nerede daha kritik?\u003C/h2>\n\u003Ch3>Otomotiv ve kara araçları\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>SAE J3016\u003C/strong>: otomasyon seviyeleri ve rol paylaşımı dilini standardize etmek için. \u003Ca href=\"https://saemobilus.sae.org/standards/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles\">(S8)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>SOTIF (ISO 21448)\u003C/strong>: algılama/yorumlama sınırlarından gelen riskleri sistematik ele almak için. \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>Safety case\u003C/strong> ve operasyonel göstergeler: sahadaki performansı izlemek için (UL 4600 yaklaşımı). \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Ch3>Havacılık ve uzay\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Kanıta dayalı güvence\u003C/strong> ve \u003Cstrong>çalışma-zamanı izleme\u003C/strong>: öğrenen bileşenlerde onay/güvence stratejilerinin temel parçası olabilir (FAA). \u003Ca href=\"https://www.faa.gov/media/82891\">(S3)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>Güvence desenleri\u003C/strong>: karmaşık otonom sistemlerde izleme, biçimsel yaklaşımlar ve sistematik güvence üzerine kurum çalışmaları bulunur (NASA). \u003Ca href=\"https://ntrs.nasa.gov/citations/20250003737\">(S4)\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Ch3>Genel otonom ürünler (robotik, endüstri, mobil platformlar)\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>UL 4600\u003C/strong>: “ürün + süreç + kanıt” temelli genel bir güvenlik değerlendirme dili sunar. \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>Ölçüm ve doğrulama ekosistemi\u003C/strong>: güvenilir otonomi için ölçüm bilimi ve standart iş birlikleri gündemdedir (NIST). \u003Ca href=\"https://www.nist.gov/news-events/news/2025/05/navigating-autonomy-nist-ctl-and-road-trusted-autonomous-vehicles\">(S2)\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Chr>\n\u003Ch2>Pratik kontrol listesi: Dokümantasyonda terimleri doğru kullanma\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>ODD’yi tek paragrafta özetleyin:\u003C/strong> “Nerede/kimle/hangi hızla/hangi koşullarda çalışır?”\u003C/li>\n\u003Cli>\u003Cstrong>Verification ve validation kanıtlarını ayırın:\u003C/strong> Gereksinim uygunluğu ile kullanım bağlamı uygunluğunu karıştırmayın.\u003C/li>\n\u003Cli>\u003Cstrong>Fail-safe’i eylem olarak yazın:\u003C/strong> “Ne zaman tetiklenir, hangi güvenli duruma geçer, ne kadar süre içinde?”\u003C/li>\n\u003Cli>\u003Cstrong>Redundancy + diversity bağımlılıklarını not edin:\u003C/strong> Yedekler aynı güç hattını veya aynı yazılım bileşenini paylaşıyorsa “ortak neden” riskini görünür kılın.\u003C/li>\n\u003Cli>\u003Cstrong>ML bileşenlerinde veri sınırlarını açıkça yazın:\u003C/strong> Eğitim verisinin kapsamadığı koşulları “bilinen sınırlamalar” olarak listeleyin; AMLAS türü yapılandırmalar bu noktada yardımcı olabilir. \u003Ca href=\"https://arxiv.org/abs/2102.01564\">(S5)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>Simülasyon sonuçlarını tek başına yeterli saymayın:\u003C/strong> Sim-to-real farkının nasıl yönetildiğini (kalibrasyon, saha testleri, izleme) ayrıca belgeleyin. \u003Ca href=\"https://arxiv.org/abs/2502.13187\">(S6)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>Seviyelerle (SAE) güvenlik iddiasını karıştırmayın:\u003C/strong> Seviye, terminoloji sağlar; doğrulama gereksinimi otomatik gelmez. \u003Ca href=\"https://saemobilus.sae.org/standards/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles\">(S8)\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Chr>\n\u003Ch2>Sık yapılan kavram hataları (ve daha sağlıklı ifadeler)\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>“Fail-safe = her durumda durur”\u003C/strong> yerine: “Belirli arıza/belirsizlik koşullarında risk azaltma manevrası veya güvenli moda geçiş uygular.”\u003C/li>\n\u003Cli>\u003Cstrong>“Simülasyonda geçtiyse sahada da geçer”\u003C/strong> yerine: “Simülasyon kapsaması, sahadaki kanıtın bir parçasıdır; sim-to-real farkı ayrıca ele alınır.” \u003Ca href=\"https://arxiv.org/abs/2502.13187\">(S6)\u003C/a>\u003C/li>\n\u003Cli>\u003Cstrong>“SAE seviyesi güvenlik onayı demektir”\u003C/strong> yerine: “SAE J3016 bir terim sözlüğüdür; güvenlik kanıtı ayrı bir çalışma gerektirir.” \u003Ca href=\"https://saemobilus.sae.org/standards/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles\">(S8)\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Chr>\n\u003Ch2>Son not: Bu kılavuz nasıl kullanılmalı?\u003C/h2>\n\u003Cp>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ı). \u003Ca href=\"https://www.ul.com/services/achieve-confidence-autonomous-vehicle-safety-ul-4600\">(S1)\u003C/a> \u003Ca href=\"https://iso-library.com/standard/21448\">(S7)\u003C/a> \u003Ca href=\"https://www.faa.gov/media/82891\">(S3)\u003C/a> \u003Ca href=\"https://www.nist.gov/news-events/news/2025/05/navigating-autonomy-nist-ctl-and-road-trusted-autonomous-vehicles\">(S2)\u003C/a>\u003C/p>","Otonom Sistemlerde Güvenlik ve Doğrulama Terimleri Kılavuzu","Otonom sistemler ve robotikte safety case, SOTIF, fail-safe, redundancy ve sim-to-real gibi temel güvenlik ve doğrulama terimlerini pratik örneklerle öğrenin.","otonom sistemler ve robotik, güvenlik doğrulama, verification validation, safety validation, safety case, fail-safe, redundancy, diversity, SOTIF, ISO 21448, UL 4600, SAE J3016, runtime assurance, sim-to-real, domain randomization","otonom-sistemlerde-guvenlik-ve-dogrulama-terimleri-temel-kilavuz","2026-03-10T18:30:36.000Z",{"id":16,"title":17,"slug":18},637,"Otonom Sistemler ve Robotik","otonom-sistemler-ve-robotik",{"id":20,"name":21,"nickname":22,"slug":23},161,"Serkan Korkut","TechSage","serkan-korkut","/media/blog/7ff8df5449c8d499dd24bcc00b22b120.jpg","/media/blog/7ff8df5449c8d499dd24bcc00b22b120_thumb.jpg","/media/blog/7ff8df5449c8d499dd24bcc00b22b120.webp","/media/blog/7ff8df5449c8d499dd24bcc00b22b120_thumb.webp",null,{"minutes":30,"wordCount":31,"imageCount":32,"formatted":33},8,1545,0,"8 dk okuma süresi","/blog/otonom-sistemler-ve-robotik/otonom-sistemlerde-guvenlik-ve-dogrulama-terimleri-temel-kilavuz",[],["Reactive",37],{"title":7,"subTitle":17,"image":24},["Reactive",39],{"title":10,"meta":40,"link":75},[41,43,45,48,51,54,57,60,63,66,69,71,73],{"hid":42,"name":42,"content":11},"description",{"hid":44,"name":44,"content":12},"keywords",{"hid":46,"name":46,"content":47},"author","Ai Terimler",{"hid":49,"name":49,"content":50},"robots","index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1",{"hid":52,"property":52,"content":53},"og:type","website",{"hid":55,"property":55,"content":56},"og:title","Ai Terimler - Blog Yazarları İçin Güncel Yapay Zeka Terimleri",{"hid":58,"property":58,"content":59},"og:description","Ai Terimler, blog yazarları ve sosyal medya içericileri için güncel yapay zeka terimleri ve açıklamalar sunan rehber bilgi blogudur.",{"hid":61,"property":61,"content":62},"og:image","https://aisozluk.net/media/blog/7ff8df5449c8d499dd24bcc00b22b120.jpg",{"hid":64,"property":64,"content":65},"og:url","https://aisozluk.net/blog/otonom-sistemler-ve-robotik/otonom-sistemlerde-guvenlik-ve-dogrulama-terimleri-temel-kilavuz",{"hid":67,"name":67,"content":68},"twitter:card","summary_large_image",{"hid":70,"name":70,"content":56},"twitter:title",{"hid":72,"name":72,"content":59},"twitter:description",{"hid":74,"name":74,"content":62},"twitter:image",[76,78],{"rel":77,"href":65},"canonical",{"rel":79,"href":80},"amphtml","https://amp.aisozluk.net/blog/otonom-sistemler-ve-robotik/otonom-sistemlerde-guvenlik-ve-dogrulama-terimleri-temel-kilavuz",["Reactive",82],{"@context":83,"@graph":84},"https://schema.org",[85,98],{"@type":86,"headline":10,"image":62,"author":87,"publisher":90,"datePublished":14,"dateModified":14,"mainEntityOfPage":96,"description":11},"BlogPosting",{"@type":88,"name":21,"url":89},"Person","https://aisozluk.net/yazarlar/serkan-korkut",{"@type":91,"name":47,"logo":92},"Organization",{"@type":93,"url":94,"width":95,"height":95},"ImageObject","https://aisozluk.net/img/icons/favicon.png",32,{"@type":97,"@id":65},"WebPage",{"@type":99,"itemListElement":100},"BreadcrumbList",[101,106,110,113],{"@type":102,"position":103,"name":104,"item":105},"ListItem",1,"Ana Sayfa","https://aisozluk.net",{"@type":102,"position":107,"name":108,"item":109},2,"Blog","https://aisozluk.net/blog",{"@type":102,"position":111,"name":17,"item":112},3,"https://aisozluk.net/blog/otonom-sistemler-ve-robotik",{"@type":102,"position":114,"name":7,"item":65},4]