FMEA uygulama rehberi

FMEA nedir ve FMECA ile farkı nedir

FMEA, bir öğenin veya sürecin nasıl başarısız olabileceğini ve bunun sonuçlarını sistematik olarak inceler. Donanımı, yazılımı, insan eylemlerini ve arayüzleri kapsayabilir. FMECA ise kritiklik değerlendirmesini ekler: sonuçlar, şiddetleri ve çoğu zaman başka önem ölçütleri kullanılarak derecelendirilir. FMECA adı, mutlaka bütünüyle sayısal bir olasılık modeli kullanıldığı anlamına gelmez. Bu ayrım, IEC 60812:2018'in yayımlanan kapsamına dayanır.

Tasarım FMEA'sı bir fan grubunu, süreç FMEA'sı ise bu grubun doğru bağlanıp bağlanmadığını inceleyebilir. İşlevleri, nedenleri ve kontrolleri farklıdır. Tasarım tablosunu süreç incelemesine kopyalamak aynı kapsamın sağlandığını göstermez.

İşlevi ve sınırları belirleyin

Arızaları sıralamadan önce başarılı performansı tanımlayın. “Soğutma sistemi” bir öğe adıdır. “Başlatma talebi sırasında gösterim kabininin gerektirdiği hava akışını sağlamak” ise yerine getirilip getirilmediği değerlendirilebilen bir işlevdir.

Yapılandırmayı, çalışma evresini, arayüzleri, varsayılan çevre koşullarını, analiz ayrıntı düzeyini ve kapsam dışı bırakılan durumları kaydedin. Başlatma, sürekli çalışma, bakım ve durdurmanın kapsanıp kapsanmadığını belirleyin. Her evrenin arıza biçimleri ve sonuçları farklı olabilir.

İşlev açıklamaları, çizimler, arayüz tanımları, gereksinimler, test bulguları ve ilgili arıza geçmişi gibi kanıtları bir araya getirin. Hangi bilgilerin ölçüldüğünü, hangilerinin çıkarım olduğunu ve nelerin bilinmediğini belirtin. Puanları görmeden önce hangi durumların üst düzey değerlendirmeye taşınacağını kararlaştırın; sonuçlara göre kural değiştirmeyin.

Arıza biçimini neden ve etkiden ayırın

İki fanlı bir kabindeki fanlardan birini düşünelim:

• İşlev: komut verildiğinde hava akışı oluşturmak
• Arıza biçimi: fanın çalışmaya başlamaması
• Olası neden: elektrik bağlantısında açık devre
• Yerel etki: bu fanın hava akışı sağlayamaması
• Sistem etkisi: diğer fan varsayılan işlevini yerine getiriyorsa akış yeterli kalabilir; ancak yedeklilik kaybedilir

“Fan arızası” fazla geniş bir ifadedir. Başlayamama, çalışırken durma ve yetersiz akış sağlama ayrı arıza biçimleridir. “Aşırı ısınma” daha sonraki bir etki olabilir, fakat otomatik bir sonuç değildir: ısıl yükün, kalan hava akışının ve sürenin bu sonucu desteklemesi gerekir. Bir düzeyde neden olan durum, daha alt düzeyde arıza biçimi olarak incelenebilir. Analiz düzeyini tutarlı tutun.

Altı adımda özgün bir örnek

Eğitim amaçlı bir gösterim kabininde, her biri tek başına gerekli akışı sağlayabilen iki paralel fan bulunduğunu varsayalım. Fanların güç kaynağı ortaktır. Ayrı bir hava akışı göstergesi durumu bildirir, ancak fanları kumanda etmez. Örnek yalnızca başlatmayı kapsar ve gerçek arıza hızı iddiası içermez.

1. Başarıyı tanımlayın. Geçerli komut ve uygun hava yolu koşullarında en az bir fan yeterli akışı oluşturmalıdır. Gerçek çalışmada kabul eşiği bir gereksinimde tanımlanır; bu örnekte kasıtlı olarak sayısal değer verilmemiştir.

2. Her işlevi inceleyin. A fanının başlayamaması bir akış yolunu kaybettirir. B fanını da inceleyin. Farklı bileşen etiketleri, arızaların bağımsız olduğunu göstermez.

3. Ortak destek işlevlerini inceleyin. Çıkış vermeyen güç kaynağı iki fanı da devre dışı bırakabilir. Bunu birbirinden bağımsız iki fan arızası gibi kaydetmek yerine ortak etkiyi belirtin.

4. Tespiti inceleyin. “Normal” konumunda takılı kalan gösterge, hava akışının kaybını gizleyebilir. Bu yapılandırmada göstergenin arızalanması kendi başına akışı kesmez. Göstergeyi fiziksel performansla karıştırmadan ilgili tespit sorunuyla ilişkilendirin.

5. Değişiklik seçeneklerini ve gerekli kanıtları belirleyin. Ayrı bir güç kaynağı, bağlantı tasarımının iyileştirilmesi veya tanılama kontrolü farklı sorunlara karşılık gelebilir. Her biri için sorumlu, beklenen etki mekanizması, kabul ölçütü ve uygun doğrulama gerekir. Bir öneriyi listelemek, onu etkili bir kontrol yapmaz.

6. Kalan sorunu yeniden değerlendirin. Uygulanan değişikliğin belirtilen varsayımlar altında işe yaradığını doğrulayın. Yapılandırma, gereksinimler veya kanıtlar değiştiğinde analizi güncelleyin. NASA'nın GSFC FMECA el kitabı, analizi geliştirme ve işletme boyunca güncel tutulan bir kayıt olarak ele alır.

Bu örnek önemli bir ayrımı gösterir: iki fan bulunması potansiyel yedeklilik sağlar, ancak ortak güç kaynağı ve tespitin güvenilirliği hakkında tek başına yeterli bilgi vermez.

Puanların anlamı ve sınırı

Bazı uygulamalar şiddet, oluşma ve tespit derecelerini S, O ve D olarak gösterir ve bunları risk öncelik sayısında çarpar: RPN = S × O × D. Başka uygulamalar farklı öncelik kuralları kullanır. Her çalışma için geçerli tek bir ölçek veya evrensel müdahale eşiği yoktur.

Şiddet, değerlendirilen sonucu tanımlar. Oluşma, seçilen prosedürde belirtilen neden veya arıza biçimiyle ilgilidir. Tespit ise mevcut kontrollerin sorunu belirlenen aşamada fark etme olanağıdır. Bu aşamayı ve puan yönünü açıklayın. Bir izleme ekranı, gerekli aşamada tespit yapılacağını tek başına kanıtlamaz. Etkili olduğu kabul edilen azaltıcı önlem için de zamanında ve yeterli müdahale gerekir.

Sıralı bir ölçekte büyük sayı daha yüksek kategoriyi gösterir; 4 puanı, 2'nin iki katı olasılık veya sonuç anlamına gelmez. Bowles'ın araştırma makalesi, sıralamaların nicelik gibi kullanılmasını ve farklı profillerin aynı RPN'yi üretmesini eleştirir.

Tamamen örnek amaçlı beş düzeyli bir ölçekte, yüksek D'nin daha zor tespit anlamına geldiğini varsayalım. S=5, O=2, D=2 ile S=2, O=5, D=2 profilleri aynı 20 sonucunu verir. İlkinde şiddet, ikincisinde oluşma derecesi yüksektir. Eşit çarpım, bu durumların eşdeğer olduğunu göstermez. Ayrı puanları ve gerekçelerini görünür tutun; projenin şiddet ve üst değerlendirmeye taşıma kurallarını uygulayın.

RPN'nin fiziksel birimi yoktur. Arıza olasılığı, arıza hızı veya beklenen yıllık kayıp değildir. En büyük mümkün değere bölmek onu olasılığa dönüştürmez. Bir prosedür oluşma kategorilerini olasılık aralıklarıyla tanımlayabilir; bu aralıklar yine süre veya talep temelinin ve kanıtın açıklanmasını gerektirir. Böyle bir tanım, bütün RPN'yi olasılığa çevirmez.

Kapsamı işletme durumu ve arayüzle inceleyin

Çok sayıda satır, önemli işlevlerin kapsandığını kanıtlamaz. İlgiliyse depolama, başlatma, işletme, durdurma, bakım ve hizmete dönüş durumlarıyla arayüzleri içeren kapsam görünümü oluşturulur. Her durumda elemanın ne yapması, ne yapmaması ve hangi dış hizmetleri kullanması gerektiği sorulur. Bir arıza biçimi bir durumda önemsizken başka durumda belirleyici olabilir. Satır sayısı yerine bu bağlantıların izlenebilirliği değerlendirilmelidir.

Kurgusal fan örneğini bakıma genişletelim. B fanı bilinçli olarak kullanılamıyorsa A’nın başlayamaması artık varsayılan hava akışını tek başına kaldırır. Fiziksel arıza biçimi değişmemiştir; sistem etkisi değişmiştir. İki fanlı sonucu bütün satırlarda sessizce kullanmak yerine bakım düzeni açık tutulmalıdır. Bu özgün analitik uzantıdır; bakım izni değildir. Kalan korumanın yeterliliği gerçek sistemin gerekliliklerine bağlıdır.

Algılama zaman gereği olan bir zincirdir

“Alarm mevcut” eksik algılama iddiasıdır. İlgili belirti, algılama yolu, gösterge, alıcı, mevcut süre ve analizde kredi verilen yanıt belirlenir. Alarm nedenini tanımlamadan belirtiyi algılayabilir. Sonuç geliştikten sonra gelen doğru uyarı, ileri sürülen koruma için geç kalabilir. Bu nedenle yakın gerçekleşseler de algılama ve hafifletme ayrı açıklanmalıdır. İnsan yanıtı kredisi de varsayımsız bırakılmamalıdır.

Varsayımsal eğitimde tehlikeli durumun 40 saniyede geliştiği, göstergenin 15 saniyede geldiği ve yanıtın 30 saniye daha sürdüğü kabul edilsin. Toplam 45 saniye belirtilen pencereyi kaçırır. Keyfî süreler yalnız algılayıcı varlığının neden yeterli olmadığını gösterir; insan performansı verisi veya gerçek emniyetli yanıt süresi değildir. Her aralığın belirsizliği nominal değer kadar önemli olabilir. Daha fazla ondalık bu belirsizliği çözmez.

Önlemeyi sonuç azaltmadan ayırın

Arıza nedenini kaldıran eylem, oluşan etkiyi sınırlayandan farklıdır. Bağlantıyı iyileştirmek belirli başlangıç mekanizmasını azaltabilir; bağımsız hava akışı algılaması kaybı gösterebilir; uygun koruyucu yanıt sonraki sonucu sınırlayabilir. Bunlar argümanın farklı bölümlerine yönelir ve farklı doğrulama ister. Tek eylem tamamlandı diye bütün puanlar değiştirilmemelidir. Örneğin daha iyi algılama, aynı fiziksel sonuç için şiddeti kendiliğinden azaltmaz.

Her öneride hedef mekanizma ve değiştiğini gösterecek kanıt belirtilir. Tasarım değişikliği yeni arayüz veya bakım ihtiyacı getiriyorsa bunlar da incelenir. Bir eylem her durumda otomatik yarar sağlamaz. Yararlı soru hangi varsayımlar altında neyin iyileştiği ve önemli kaygının başka yere taşınıp taşınmadığıdır. Beklenen yararla gösterilmiş yarar ayrı tutulmalıdır.

Eylemleri iddiayla eşleşen kanıtla kapatın

NASA GSFC FMECA rehberi, analizi sürdürülen mühendislik kaydı olarak ele alır. Uygulamalı eylem kaydı önerilmiş, uygulanmış ve doğrulanmış durumları ayırmalıdır. Doğrulama, belirli iddiaya uygun çizim, muayene, analiz veya test sonucuna; düzeni ve sınırlarıyla bağlanmalıdır. “Açık” yerine “kapalı” yazmak kalan performansı kanıtlamaz. Kayıt, yetkili inceleyenin gerekçeyi yeniden izleyebilmesini sağlamalıdır.

Yeni değerlendirmeyi kabul etmeden kanıt ilk eylem gerekçesiyle karşılaştırılır. Etkilenen satır ve arayüzlerin güncellendiği, sonucun işletme durumuyla eşleştiği doğrulanır. Sayısal öncelikleri düşük olsa bile çözülmemiş sorular görünür tutulur. Sonuç yalnız forma ne girildiğini değil, artık ne bilindiğini açıklamalıdır.

Yararlı bir analiz çıktısı

İşlevi ve gereksinimi, arıza biçimini, nedeni, yerel ve nihai etkileri, mevcut kontrolleri, kanıtları, varsayımları, öncelik gerekçesini, önerilen eylemi, sorumluyu ve doğrulama durumunu koruyun. Mevcut kontrolleri önerilen değişikliklerden ayırın. Değişiklik sonrası değerlendirmeyi gerçek uygulama kanıtına bağlayın.

Eksik arayüzleri, belirsiz “operatör hatası” ifadelerini, kanıtsız tespit iddialarını, yeterli müdahale olmadan etkili sayılan azaltıcı önlemleri ve ağır sonuçları elemek için kullanılan düşük puanları kontrol edin. Birbirinden farklı satırların RPN'lerini toplayarak sistem riskini ölçtüğünüzü varsaymayın.

FMEA, geniş kapsamlı inceleme ve izlenebilirlik sağlar. Ancak tek bir arıza biçimini ele alan geleneksel inceleme, etkileşen arızaları kendi başına nicel olarak modellemez. Sonucu arıza birleşimleri belirliyorsa hata ağacı gibi uygun bir sistem modeli kurun. Uzun bir tablo veya düşük puan; eksiksizlik, güvenlik ya da uygunluk kanıtı değildir.