FMEA ve FTA karşılaştırması

Yöneltilen sorular farklıdır

FMEA, “Bu işlev bu biçimde başarısız olursa etkileri neler olur?” diye sorar. Seçilen arıza biçiminden sonuçlarına doğru ilerler. Genellikle aşağıdan yukarıya yöntem olarak tanımlanır; ancak işlevsel FMEA, tekil parçalardan başlamak yerine yüksek sistem düzeyinden de başlayabilir.

FTA, “Tanımlanan bu sonucun oluşması için hangi koşullar yeterlidir?” diye sorar. Tepe olaydan katkı sağlayan koşullara doğru tümdengelimle ilerler. IEC 60812:2018 ve IEC 61025:2006'nın kamuya açık kapsam açıklamaları iki yöntemi tanımlar.

Sınır belirtilmeden iki soru da eksik kalır. Aynı bileşen arızasının başlatma, normal çalışma veya bakım sırasındaki sonuçları farklı olabilir. Farklı yapılandırmalar varsayan iki analiz, bu fark açıklanmadan anlamlı biçimde uzlaştırılamaz.

Başlangıç yöntemini verilecek karara göre seçin

Ekibin arıza biçimlerini belirlemesi, yerel etkilerin sisteme nasıl yayıldığını anlaması, arayüzleri incelemesi veya tasarım ve süreç genelinde iyileştirme eylemleri ataması gerekiyorsa işlev envanteri ve FMEA ile başlayın.

Karar; tanımlı bir işlev kaybını, yedekli olduğu ileri sürülen bir düzeni, tek bir arızanın sistemi devre dışı bırakabilmesini veya koruyucu işlevi etkisiz bırakan birleşimleri ilgilendiriyorsa FTA ile başlayın. Yapısal zayıflığı görmek için nitel ağaç yeterli olabilir; yararlı değerlendirme yapabilmek mutlaka sayısal girdi gerektirmez.

Hem geniş kapsam hem de belirli sistem düzeyi sorunlar önemliyse iki yöntemi birlikte kullanın. Sıralama esnektir. FMEA bir tepe olay önerebilir; hata ağacı ise FMEA'da gözden kaçan bağımlılığı ortaya çıkarabilir. Bir projede işe yarayan sırayı bütün çalışmalar için otomatik kurala dönüştürmeyin.

Aynı sisteme iki yararlı bakış

Diğer rehberlerdeki eğitim kabinini kullanalım: hava akışı için her biri yeterli iki paralel fan, ortak güç kaynağı ve fanları kumanda etmeyen bir gösterge. Geçerli başlatma komutu ve açık hava yolu varsayılır. Örnek kavramsaldır ve ekipmana özgü uygulama talimatı içermez.

1. FMEA bakışını oluşturun. “A fanı başlamıyor” durumunun yerel etkisi, o fanın akış sağlayamamasıdır. B varsayıldığı gibi çalışıyorsa kabin hava akışını korur, fakat yedekliliği kaybeder. Ortak güç kaynağının kaybı iki fanı da etkileyebilir. Normal konumunda takılı kalan gösterge, fiziksel akış kaybına yol açmadan arızayı gizleyebilir.

2. FTA sorusunu seçin. Tepe olayı, bir başlatma talebinde gerekli hava akışının oluşturulamaması olarak tanımlayın. C güç kaynağının kullanılamaması, A ve B fanların iç nedenlerle başlatma başarısızlıkları olsun. Eğitim örneğinin mantığı T = C VEYA (A VE B) olur.

3. Bakışları uzlaştırın. FMEA'daki fan satırları olay tanımlarını destekler. Ağaç, fan arızalarının nasıl birleştiğini ve ortak kaynağın kaybının neden tek başına yeterli olduğunu gösterir. Gösterge satırı, bu tepe olaya neden olmasa da genel inceleme açısından önemini korur.

4. Gerektiğinde farklı soru sorun. “Hava akışı kaybının gösterilmemesi” başka bir tepe olaydır. Basit bir model, akış kaybını tespit başarısızlığıyla birleştirebilir; ancak kesin mantık göstergeye, zamanlamaya ve tepki gereksinimlerine bağlıdır. Her çalışma satırı bir yerde görünsün diye göstergeyi ilk ağaca eklemeyin.

5. Önerilen değişikliği inceleyin. İkinci güç kaynağı eklemek ortak bağımlılıklardan birini kaldırabilir, fakat kaynaklar arası geçiş veya izleme gereksinimleri doğurabilir. Performansın iyileştiğini söylemeden önce iki modeli de güncelleyin ve gerçek düzeni doğrulayın.

Birlikte kullanımın yararı izlenebilirliktir: okuyucu işlevden arıza biçimine, arıza biçiminden sistem sonucuna ve belirlenen sorundan değişiklik için gereken kanıta geçebilir.

Puanları değil tanımları ve kanıtları aktarın

Yararlı bir çapraz başvuru; FMEA satır kimliğini, ilgili hata ağacı olayını, çalışma evresini, geçerli yapılandırmayı, başarısızlık ölçütünü ve veri kaynağını içerir. Eşleştirme bire bir olmak zorunda değildir. Geniş bir çalışma satırı birkaç olaya ayrılabilir; tek bir ortak olay ise birden fazla satırda kaydedilen etkileri açıklayabilir.

Örneğin “fan kullanılamıyor” satırı; başlayamamayı, çalışma sırasında arızalanmayı ve bakım nedeniyle devre dışı kalmayı birlikte içerebilir. Başlatma ağacı, başlatma olayını ve bu koşula uygun veriyi gerektirir. Tanımı kontrol etmeden geniş kapsamlı satırın sayısını kopyalamak, gerçekte olmayan bir eşleşme yaratır.

NASA'nın hata ağacı el kitabının 4.8 bölümü, FMEA sonuçlarını bir araya getirmenin hata ağacı kurmak için yeterli olmadığını vurgular. Sistem ilişkileri, tümdengelimli analiz yoluyla kurulmalıdır.

Çıktıları ve birimleri birbirinden ayırın

FMEA veya FMECA; şiddet sınıfları, öncelik kategorileri ya da RPN sunabilir. FMECA kritiklik değerlendirmesini ekler; prosedürüne ve kanıtına uygun nitel veya nicel yaklaşım kullanabilir. Yöntemin adı, çıktının istatistiksel anlamını tek başına belirlemez.

Sıralı derecelerden elde edilen 60 RPN değeri, 0,003 hata ağacı olasılığıyla sayısal olarak karşılaştırılamaz. 60'ı en büyük mümkün RPN'ye bölerek olasılık da elde edilemez. Alttaki ölçekler ve yanıtlanan sorular farklıdır. Sıralı RPN aritmetiğinin bilinen sınırlamaları Bowles'ın makalesinde ele alınır.

Nicel FTA, talep başına başarısızlık olasılığını, belirli süre içindeki arızalanma olasılığını veya tanımlanmış model altındaki kullanılamazlığı tahmin edebilir. Olay sıklığı için uygun zaman temelli model gerekir. Her çıktının neyi ifade ettiğini açıkça yazın. Olasılık tek başına sonuçların büyüklüğünü de açıklamaz; sistem riski kararları için bu bağlam gerekir.

Ortak kanıt kaydı kullanın, bire bir eşleme zorlamayın

Küçük ortak kayıt; işlev kimliklerini, düzeni, işletme durumunu, arıza ölçütlerini, kanıt bağlantılarını ve açık varsayımları tutabilir. FMEA satırlarıyla hata ağacı olayları, aynı nesne oldukları iddia edilmeden bu kayda bağlanır. Birçok FMEA etkisinde görünen neden, ağaçta tek ortak olaya karşılık gelebilir. Tersine, geniş bir arıza biçimi farklı talepler için birkaç kesin tanımlı olay gerektirebilir. Eşleme sayısı değil, anlamın korunması önemlidir.

Özgün örnekte ortak güç kaynağına SUP-1 kimliği verilsin ve her referansta korunsun. FMEA iki fan yolundaki etkileri kaydederken FTA tek besleme-kullanılamaz olayını tutar. Kimliği iki bağımsız olay gibi çoğaltmak model anlamını değiştirir. Tutarlı kimlik izlenebilirliği destekler; olayın olasılığını veya başka nedenlerden bağımsızlığını kanıtlamaz. Kimlik yönetimi sayısal veri kalitesinden ayrı görevdir.

Uyuşmazlığı sistem sorusu olarak çözün

FMEA iki fandan herhangi birinin işlevi karşılayabildiğini, hata ağacı ise fan arızaları arasında VEYA kapısı bulunduğunu söylesin. Aynı düzen ve başarı ölçütünde bunlar uyuşmaz: biri yeterliyse ilgili dalda iki yolun birden arızası gerekir. Kapıyı hemen değiştirmeden önce işlev ve durum kontrol edilir. Belgelerden biri tam yük, diğeri düşük yük varsayıyor olabilir. Görünür mantık farkı, gizli kapsam farkından kaynaklanabilir.

Ağaç meşru biçimde hava akışı kaybı yerine yedeklilik kaybını da ele alabilir. Bu olay tek fan arızasında oluşabilir. Dolayısıyla aynı şekil tanıma bağlı olarak doğru veya yanlış olabilir. Uzlaştırma, anlam pahasına belgeleri görsel olarak eşleştirmek yerine bu ayrımları korumalıdır. Başlık, tepe olay ve kabul ölçütü birlikte okunmalıdır; yalnız kapı simgeleri karşılaştırılmamalıdır.

Bakım senaryosu iki görünümü de değiştirir

Kurgusal iki fanlı sistemde B, açıkça varsayılan bakım durumunda hizmetten alınsın. A’nın başlayamamasının FMEA etkisi artık yedeklilik kaybından gerekli hava akışının kaybına dönüşür. FTA, B’nin bilinen kullanılamazlığını göstermeli veya o düzene özgü azaltılmış ağaç kullanmalıdır. Bakımı anlatırken iki fanın kullanılabilirliğini korumak kalan işlevi olduğundan güçlü gösterir. Bilinen durum, rastgele arıza olasılığı gibi gizlenmemelidir.

Bu, o durumda işletme önerisi değildir. Düzenin iki yöntemin ortak girdisi olduğunu gösterir. Yararlı değişiklik incelemesi bakıma geçişi, iş süresini ve geri kurmayı ayrı sorar. Telafi önlemleri, yetenekleri ve uygulanmaları uygun kanıtla desteklenene kadar öneri kalır. Eylem listesinde bulunmaları gerçekleşmiş koruma sayılmalarını sağlamaz.

Sonraki yöntemi açık soruya göre seçin

Kalan kaygı başlangıç olayından sonraki yanıt sırasıysa olay ağacı dizileri açıklayabilir. Sorun değişen durum, onarım veya geçiş gecikmesiyse statik hata ağacı daha uygun zamansal model gerektirebilir. Sorun gözden kaçmış arıza mekanizmasıysa olasılığa bir ondalık eklemek yerine işlev ve arayüz analizine dönmek daha yararlı olabilir. Yöntem seçimi önce hangi bilgi eksikliğinin kapatılacağını açıklamalıdır.

IEC 60812’nin kamuya açık kapsamı, genel yöntemi tanımlar ve uygulamaya özgü emniyet rehberinden ayırır. Bu, birleşik çalışma için de yararlı hatırlatmadır: ne FMEA ne FTA bütün alan gereklerini sağlar. Sonraki analitik adım belirlenmiş kanıt açığını kapattığı için seçilmeli; sonucun sınırı yöntemlerin gerçekten gösterdiğiyle korunmalıdır. Belgelerin çokluğu tek başına kapsamlı güvence oluşturmaz.

Çalışmayı kanıtla tamamlayın

Üzerinde uzlaşılmış tek bir yapılandırma referansı ve ortak terimler kullanın. Çözülmemiş bağımlılıkları, belirsiz verileri, kapsam dışı durumları ve varsayımları kaydedin. Önerilen değişikliklere sorumlu atayın; uygulamayla doğrulamayı ayırın. Yapılması planlanan test, başarıyla tamamlanmış test değildir.

Kanıt değiştiğinde hem ilgili arıza etkilerini hem de ağaç mantığını veya parametrelerini yeniden değerlendirin. NASA'nın 2024 GSFC FMECA rehberi, tasarım ve işletme bilgisi geliştikçe analizin güncellenmesini vurgular.

İki analize dayanmadan önce şunları sorun: Sınırları aynı mı? Ortak nedenleri tutarlı biçimde ele alıyorlar mı? Olay kimlikleri korunuyor mu? Her sayısal sonucun temeli açıklanıyor mu? Kalan belirsizlikler kararı etkiliyor mu? İki yöntem de bütün tehlikelerin keşfini garanti etmez, alana özgü gereksinimlerin yerini almaz veya sertifikasyon sağlamaz. En güçlü ortak çıktıları, nelerin ters gidebileceğini ve önerilen eylemin neden yararlı olacağını incelemeye açık biçimde açıklamaktır.