Endüstriyel Hata Toleransını Analiz Etmek İçin Beş Güvenilirlik Tekniği

Hata Toleransı Neden Yedekli Donanımdan Daha Fazlasını Gerektirir

Her endüstriyel sistem sonunda arızalarla karşılaşır. Sensörlerin ölçümü kayar, güç kaynakları bozulur, iletişim bağlantıları kararsız hâle gelir ve mekanik bileşenler tekrarlı yükleme altında aşınır. Bu nedenle hata toleranslı mühendisliğin amacı asla arızalanamayacak ekipmanlar oluşturmak değildir. Amaç, öngörülebilir arızaların kontrolsüz sistem arızalarına hemen dönüşmemesini sağlamaktır.

Hata toleranslı bir sistem, bir veya daha fazla bileşen kullanılamaz duruma geldikten sonra kabul edilebilir bir işlev sunmaya devam edebilir. Bazı uygulamalarda sistem tam üretimi sürdürmelidir. Diğerlerinde ise arızalı kanal bakım ile yeniden çalışır duruma getirilene kadar kapasitenin düşmesi kabul edilebilir. Güvenlik açısından kritik sistemler, işletimin sürdürülmesi kabul edilemez bir risk oluşturacaksa bunun yerine kontrollü güvenli duruma geçebilir.

Yedekli bileşenler çoğu zaman bu stratejinin bir parçasıdır; ancak yalnızca çoğaltma, hata toleransını kanıtlamaz. İki kontrolör yine de tek bir güç kaynağına, tek bir ağ anahtarına veya tek bir yazılım yapılandırmasına bağlı olabilir. İki transmiter aynı impuls hattını paylaşabilir ve aynı tıkanma nedeniyle arızalanabilir. Bu nedenle güvenilirlik analizi, ekipman listesinde hemen görünmeyen bağımlılıklar da dâhil olmak üzere tüm mimariyi incelemelidir.

Bu çalışma için özellikle beş yöntem kullanışlıdır. Hata Ağacı Analizi, arızaların hangi kombinasyonlarının tanımlanmış bir üst olaya yol açabileceğini inceler. Arıza Türleri ve Etkileri Analizi, münferit bileşenlerin nasıl arızalanabileceğini ve bu arızaların daha geniş sistem üzerindeki etkilerini inceler. Monte Carlo simülasyonu, çok sayıdaki olası işletim ve arıza senaryosu üzerinden belirsizliği araştırırken Kök Neden Analizi, gerçek bir olayın neden meydana geldiğini inceler. Markov modelleri, onarılabilir sistemlerin zaman içinde sağlam, bozulmuş, arızalı ve yeniden çalışır durumlar arasında nasıl geçtiğini açıklar.

Şekil 1. Endüstriyel sistemler her arızayı önleyemez; ancak disiplinli güvenilirlik mühendisliği, birçok arızanın tamamen başarısızlığa dönüşmesini önleyebilir.

Güvenilirlik, Kullanılabilirlik, Güvenlik ve Bakım Yapılabilirlik Aynı Şey Değildir

Güvenilirlik terminolojisi çoğu zaman gelişigüzel kullanılır ve bu da tasarım incelemeleri sırasında karışıklığa yol açabilir. Güvenilirlik, ekipmanın belirli bir süre boyunca gerekli işlevini yerine getirme olasılığını ifade eder. Kullanılabilirlik ise süreç ihtiyaç duyduğunda ekipmanın hazır olup olmadığını belirtir. Onarımlar hızlı ve yedek parçalar hemen erişilebilir olduğunda, bir sistem zaman zaman arızalansa bile yüksek kullanılabilirliğini koruyabilir.

Bakım yapılabilirlik, arızalanmış bir sistemin ne kadar etkili şekilde teşhis edilip yeniden çalışır duruma getirilebildiğini ifade eder. Güvenlik ise arızaların personel, çevre ve ekipman açısından kabul edilebilir risk sınırları içinde kalıp kalmadığını belirtir. Bu özellikler birbirini etkiler; ancak bir özelliğin iyileştirilmesi diğerlerinin tümünü otomatik olarak iyileştirmez. Koruyucu bir duruş, üretim kullanılabilirliğini azaltırken tesis güvenliğini önemli ölçüde artırabilir.

Arıza toleransı bu disiplinlerin tamamını kapsar. Yedekliliğe, tanılamaya, yalıtıma, onarım kapasitesine ve kontrollü bozulmaya bağlıdır. Ayrıca gerekli işlevin açıkça tanımlanmasına da bağlıdır. Mühendisler, her makul arızadan sonra hangi performansın korunması gerektiğini bilmeden bir sistemin arıza toleranslı olup olmadığını belirleyemez.

Örneğin bir kompresör koruma sisteminin, tek bir sensör arızasından sonra acil durdurma kapasitesini koruması gerekebilir. Bir proses kontrol sisteminin, bir kontrolör değiştirilirken yalnızca kararlı çalışmayı sürdürmesi yeterli olabilir. Bir güç koruma düzeni, tek bir ortak arızanın hem birincil hem de yedek korumayı devre dışı bırakamaması için bağımsız kanallar gerektirebilir. Güvenilirlik teknikleri, mühendislerin bu gereksinimleri test edilebilir tasarımlara dönüştürmesine yardımcı olur.

Mühendislik Sorusu Kullanılarak Yöntem Seçimi

Beş güvenilirlik tekniği aynı problemin farklı bölümlerini ele alır. FTA, istenmeyen bir sistem olayıyla başlar ve bu olaya yol açabilecek arızalara doğru geriye gider. FMEA, bileşenler veya işlevlerle başlar ve her arıza türünün sonuçlarını ileriye doğru inceler. Monte Carlo simülasyonu, sistemi rastgele oluşturulmuş birçok koşul altında tekrar tekrar modelleyerek belirsizliğin etkisini inceler.

RCA normalde gerçek bir olaydan sonra başlar ve görünür belirtileri altta yatan teknik ve kurumsal nedenlerden ayırmak için kanıtları kullanır. Markov modellemesi, sistem durumlarına ve sistemin bunlar arasında geçiş yapma hızlarına odaklanır. Onarım, beklemede çalışma, düşük performans ve tanılama kapsamı kullanılabilirliği önemli ölçüde etkilediğinde özellikle yararlıdır.

Doğru seçim, sorulan soruya bağlıdır. Toplam soğutma kaybının nasıl meydana gelebileceğini araştıran bir ekip genellikle FTA ile başlar. Olası her verici, kontrolör ve vana arızasını inceleyen bir tasarım ekibi FMEA'dan daha fazla yarar sağlar. Belirsiz bakım aralıklarını karşılaştıran bir varlık yöneticisi Monte Carlo simülasyonunu kullanabilirken, yedekli bir kontrolör çiftinin uzun vadeli kullanılabilirliğini hesaplayan bir güvenilirlik mühendisi Markov modelini tercih edebilir.

Bu yöntemler birbirinin yerine geçemez; birbirini tamamlar. Bir FMEA, daha sonra bir hata ağacındaki temel olaylara dönüşebilecek arıza türlerini belirleyebilir. RCA bulguları, bir Markov modelindeki gerçekçi olmayan arıza varsayımlarını düzeltebilir. Monte Carlo simülasyonu, belirsiz olasılıkların FTA'dan veya bakım planlamasından çıkarılan sonuçları nasıl etkilediğini test edebilir.

Hata Ağacı Analizi Sonuçla Başlar

Hata Ağacı Analizi, açıkça tanımlanmış tek bir istenmeyen olayla başlayan tümdengelimsel bir yöntemdir. Bu olaya tepe olay denir. Uygun örnekler arasında kazan besleme suyunun tamamının kaybı, bir türbin durdurma işlevinin arızalanması, kontrolör iletişiminin tamamen kaybedilmesi veya bir reaktör içindeki basıncın kontrolsüz şekilde yükselmesi yer alır. Tanım, anlamlı bir analizi destekleyecek kadar spesifik olmalıdır.

Yalnızca “sistem arızası” olarak tanımlanan bir tepe olayı genellikle fazla belirsizdir. Hangi işlevin arızalandığını, arızanın ne kadar sürdüğünü veya hangi işletim durumunun geçerli olduğunu tanımlamaz. Daha iyi bir tanım, “normal üretim sırasında altmış saniyeden uzun süre tüm soğutma suyu akışının kaybı” olabilir. Bu ifade, analiz için net bir sınır sağlar.

Tepe olayı tanımlandıktan sonra ekip, bu olayı oluşturabilecek doğrudan koşulları belirler. Analiz; temel bileşen arızalarına, dış etkilere veya insan eylemlerine ulaşana kadar bu koşullar alt düzey olaylara ayrıştırılır. Mantıksal kapılar olayları birbirine bağlar ve bunların nasıl birleştiğini açıklar. VEYA kapıları, listelenen olaylardan herhangi birinin üst düzey olayı oluşturabileceğini; VE kapıları ise birkaç olayın birlikte gerçekleşmesi gerektiğini gösterir.

Tamamlanan ağaç, arıza mantığının görsel bir temsilini sunar. Elektrik, mekanik, enstrümantasyon, proses, bakım ve güvenlik uzmanlarının aynı sistemi ortak bir bakış açısıyla incelemesine olanak tanır. Bu ortak model, Arıza Ağacı Analizi'nin en büyük pratik güçlü yönlerinden biridir. Tasarıma yerleşmeden önce gizli varsayımların sorgulanmasını kolaylaştırır.

Şekil 2. Bir arıza ağacı, tanımlanmış bir tepe olayından geriye doğru ilerler ve bu olayı oluşturabilecek alt düzey arıza bileşimlerini belirler.

Arıza Ağacının Adım Adım Geliştirilmesi

İlk pratik görev, sistem sınırını belirlemektir. Mühendisler hangi ekipmanların, yardımcı tesislerin, yazılımların, operatörlerin ve dış hizmetlerin analize dâhil edileceğine karar vermelidir. Bir soğutma sistemi çalışmasına pompalar, vanalar, güç dağıtımı, enstrümantasyon ve kontrol mantığı dâhil edilebilir. Bu unsurlar tepe olayı etkileyebiliyorsa su kaynağının, çevre koşullarının ve operatör müdahalesinin de dâhil edilmesi gerekebilir.

Ekip daha sonra doğrudan nedenleri belirler. Toplam soğutma kaybı, tüm pompaların kullanılamaz hâle gelmesi, ortak besleme kolektörünün tıkanması veya izolasyon vanalarının yanlışlıkla kapanması nedeniyle meydana gelebilir. Her doğrudan neden ayrıntılandırılır. Pompanın kullanılamaz hâle gelmesi; motor arızası, rulmanın sıkışması, emiş kaybı, kontrolör arızası veya elektrik beslemesinin kaybından kaynaklanabilir.

Süreç, daha fazla ayrıştırmanın kararı iyileştirmeyeceği noktaya kadar devam eder. En alt düzeydeki olaylar temel olaylar olarak ele alınır ve bunlara arıza olasılıkları veya oranları atanabilir. Ardından mantıksal yapı niteliksel veya niceliksel olarak değerlendirilebilir. Doğru sayısal veriler mevcut olmasa bile ağaç, tekil arıza noktalarını ve beklenmedik ortak bağımlılıkları ortaya çıkarabilir.

Nicel Hata Ağacı Analizi (FTA), olay olasılıklarını kapı yapısına göre birleştirir. Hesaplama basit görünebilir, ancak bağımsızlık varsayımları dikkatle gözden geçirilmelidir. Aynı güç kaynağını, ortamı, bakım faaliyetini veya yazılım kusurunu paylaşan iki olay tamamen bağımsız değildir. Bu ilişkilerin göz ardı edilmesi, yedekli bir tasarımın gerçekte olduğundan önemli ölçüde daha güvenli görünmesine yol açabilir.

Minimal Kesme Kümeleri En Tehlikeli Birleşimleri Gösterir

Kesme kümesi, üst olayı meydana getiren temel olayların bir birleşimidir. Minimal kesme kümesi, gereksiz hiçbir olay içermez; yani herhangi bir olay çıkarıldığında üst olayın meydana gelmesi engellenir. Bu birleşimler, mühendislerin en kısa ve en önemli arıza yollarını belirlemesine yardımcı olur. Özellikle büyük bir hata ağacı yüzlerce olay içerdiğinde çok değerlidir.

Tek olaylı minimal kesme kümesi, tek bir arızanın üst olaya doğrudan neden olabileceğini gösterir. Bu tür bulgular normalde tasarımın derhâl gözden geçirilmesini gerektirir. Ekip yedeklilik ekleyebilir, izolasyonu iyileştirebilir, ayrı bir güç kaynağı sağlayabilir veya başka bir koruma katmanı ekleyebilir. İki olaylı ve üç olaylı kesme kümeleri çoğu zaman yedekli mimariler içindeki arızaları temsil eder.

Her kısa kesme kümesi aynı riske sahip değildir. Sık meydana gelen arızaları içeren iki olaylı bir birleşim, son derece nadir görülen tek bir harici olaydan daha önemli olabilir. Tespit ve onarım süresi de önemi etkiler. Aylar boyunca tespit edilmeden kalan gizli bir arıza, hemen tespit edilip onarılan bir arızaya kıyasla çok daha uzun bir maruziyet süresi yaratır.

Hata ağacı analizi (FTA) yazılımı, kesme kümelerini hesaplanan katkılarına göre sıralayabilir. Ancak mühendisler yine de sayıların ardındaki fiziksel anlamı incelemelidir. Matematiksel olarak düşük bir olasılık, gerçekteki kurulumu yansıtmayan zayıf varsayımlara veya genel verilere dayanabilir. Analiz boyunca mühendislik muhakemesi gerekli olmaya devam eder.

Örnek: Gerçekten Bağımsız Olmayan Kazan Besi Suyu Yedekliliği

İki kazan besi suyu pompasıyla çalışan bir enerji santralini ele alalım. Her iki pompadan biri gerekli minimum debiyi sürdürebildiğinden, sistem tek pompa arızasına dayanabilecekmiş gibi görünür. Basit bir ekipman sayımı tam yedeklilik olduğunu düşündürür. Ancak ortak bağımlılıklar dâhil edildiğinde hata ağacı farklı bir gerçekliği ortaya çıkarabilir.

Her iki pompa motoru da aynı elektrik barasından enerji alabilir. Her iki pompa da tek bir emiş kollektöründen beslenebilir, aynı kontrol sistemine bağlı olabilir veya tek bir seviye ölçümünden komut alabilir. Bu nedenle tek bir bara arızası, tıkalı emiş kollektörü ya da hatalı bir ortak sinyal her iki pompayı aynı anda devre dışı bırakabilir. Görünürdeki iki pompalı yedeklilik, bu ortak arızalara karşı koruma sağlamaz.

Analiz, çeşitli pratik iyileştirmelere yol açabilir. Ayrı elektrik beslemeleri, ortak güç kaybını azaltabilir. Farklı seviye ölçümleri, tek bir transmiter teknolojisine bağımlılığı azaltabilir. Bağımsız kontrol yolları, geliştirilmiş manuel işletim ve daha iyi emiş izleme, mutlaka başka bir komple pompa eklemeden mimariyi güçlendirebilir.

Bu örnek, FTA'nın yalnızca yedek cihazları saymaktan neden daha kullanışlı olduğunu gösterir. Cihazların gerçek işletim koşullarında bağımsız kalıp kalmadığını değerlendirir. Ayrıca ek karmaşıklığın nerede gerçek koruma sağladığını ve nerede yalnızca koruma görünümü oluşturduğunu belirler.

Hata Ağacı Analizi Nerede İyi Çalışır ve Nerede Çalışmaz

FTA; güvenlik işlevleri, koruma sistemleri, elektrik dağıtımı, iletişim ağları ve istenmeyen olayın açıkça tanımlandığı diğer uygulamalar için özellikle etkilidir. Görsel yapısı tasarım incelemelerini ve düzenleyici görüşmeleri destekler. Zayıflıkları ortaya çıkarmak için nitel olarak veya en üst olay olasılığını tahmin etmek için nicel olarak kullanılabilir.

En üst olayın iyi tanımlanmaması yöntemin etkinliğini azaltır. Ağaç binlerce olayı kapsayacak şekilde genişlediğinde de bakımı zorlaşabilir. Dinamik diziler, bakım davranışı ve değişen işletim durumları, özel kapılar veya ek modelleme teknikleri gerektirebilir. Statik bir hata ağacı, zamana bağlı her ilişkiyi doğal olarak açıklayamaz.

İnsan eylemleri de dikkatle ele alınmalıdır. Bir operatörün tepki verme olasılığı; alarm kalitesine, prosedür tasarımına, eğitime, iş yüküne, mevcut zamana ve arayüz koşullarına bağlıdır. Tek bir genel insan hatası olasılığı atamak, bu farklılıkları gizleyebilir. Operatör eyleminin sonuca etkisinin merkezi olduğu ciddi analizlerde insan faktörleri uzmanları yer almalıdır.

Bu nedenle FTA, daha kapsamlı bir güvenilirlik programının parçası olarak kullanıldığında en güçlü sonuçları verir. FMEA, ayrıntılı bileşen arıza türleri sağlayabilirken Markov veya Monte Carlo yöntemleri onarım, sıralama ve belirsizlik konularını ele alabilir. Hiçbir tek ağaç, her sistem davranışının eksiksiz bir temsili olarak değerlendirilmemelidir.

Arıza Türleri ve Etkileri Analizi Bileşenle Başlar

Arıza Türleri ve Etkileri Analizi, tümevarımsal bir yaklaşım kullanır. Ekip, en üst olayla başlamak yerine bir öğe, işlev veya proses adımıyla başlar. Ardından bu öğenin nasıl arızalanabileceğini ve her arızanın yerel olarak ve sistem genelinde ne gibi etkiler yaratacağını sorar. Bu yönüyle FMEA, tasarım ve ekipman incelemeleri sırasında özellikle kullanışlıdır.

Bir basınç transmiteri birkaç farklı şekilde arızalanabilir. Çıkışı yüksek değere kayabilir, düşük değere kayabilir, tek bir değerde donabilir, kararsız hale gelebilir veya tamamen kaybolabilir. Her biçim farklı bir operasyonel sonuç doğurur. Yüksek bir okuma gereksiz bir duruşa neden olabilirken düşük bir okuma tehlikeli bir basınç durumunu gizleyebilir.

FMEA, ekibi yalnızca “transmiter arızası” kaydetmek yerine bu farklılıkları açıklamaya zorlar. Ayrıca mevcut önleme ve tespit kontrollerini de inceler. Analiz; sonucu azaltan tanılama sistemlerini, karşılaştırma mantığını, kanıtlama testlerini, alarmları, baypasları veya operatör kontrollerini belirleyebilir. Zayıf tespit, çoğu zaman ilk arıza biçimi kadar önemli hale gelir.

Şekil 3. FMEA, münferit arıza biçimlerini, bunların etkilerini, önem derecelerini ve bunları önlemek veya tespit etmek için mevcut kontrolleri değerlendirir.

Etkili Bir FMEA Çalışma Sayfasında Bulunması Gerekenler

Kullanışlı bir FMEA çalışma sayfası, öğe ve bu öğenin yerine getirmesi gereken işlevle başlar. Arıza biçimi, işlevin nasıl kaybedilebileceğini, bozulabileceğini veya yanlış gerçekleştirilebileceğini açıklar. Yerel etki, bileşen düzeyinde ne olduğunu; sistem etkisi ise daha geniş kapsamlı operasyonel veya güvenlik sonucunu açıklar. Nedenler ve mekanizmalar, etkilerden ayrı olarak kaydedilir.

Çalışma sayfası mevcut kontrolleri de belgeler. Önleyici kontroller arızanın oluşma olasılığını azaltır. Tespit kontrolleri, arızayı kabul edilemez bir sonuca yol açmadan önce ortaya çıkarır. Örnekler arasında öz tanılama, yedekli sinyallerin karşılaştırılması, alarm sınırları, kanıtlama testleri, denetimler ve kestirimci bakım bulunur.

Birçok kuruluş önem derecesi, oluşma sıklığı ve tespit edilebilirlik dereceleri belirler. Bu değerler bazen bir Risk Öncelik Sayısı elde etmek için çarpılır. Bu sayı önceliklendirmeye yardımcı olabilir, ancak teknik değerlendirmenin yerini asla almamalıdır. Farklı kombinasyonlar, sonuçları temelde farklı olsa bile aynı puanı verebilir.

Nadir görülen felaket niteliğindeki bir arıza, hesaplanan puanları benzer görünse bile sık görülen küçük bir sorundan daha fazla dikkat gerektirebilir. Bu nedenle önem derecesi bağımsız olarak gözden geçirilmelidir. Ekipler ayrıca yalnızca ek denetimlere güvenmek yerine, arıza mekanizmasını ortadan kaldıran veya sonucu azaltan eylemlere öncelik vermelidir.

Örnek: Ortak Bir Zayıflığa Sahip Yedekli PLC Girişleri

Tek bir acil durum saha anahtarını izleyen iki dijital giriş kanalı düşünün. Sinyali iki PLC girişi aldığı için mimari yedekli gibi görünür. FMEA, sinyal yolunun tamamının gerçekten bağımsız olup olmadığını inceler. Saha kontağını, kablo tesisatını, giriş gücünü, terminal düzeneklerini, modülleri, mantığı ve tanılama davranışını değerlendirir.

Olası hata türleri arasında açık devre, kısa devre, kaynaklanmış kontak, yüksek seviyede takılı kalmış kanal, düşük seviyede takılı kalmış kanal veya ortak giriş beslemesinin kaybı bulunur. Analiz ayrıca kanallar arasındaki uyumsuzluğun algılanıp algılanmadığını da sorar. Her iki kanal bir saha kontağını ve bir kabloyu paylaşıyorsa, güvenilir birçok arıza her iki kanalı aynı anda etkiler.

İnceleme, yinelenen giriş modüllerinin sınırlı ek koruma sağladığını gösterebilir. Ayrı kontaklar, izlenen saha devreleri, bağımsız güç yolları veya farklı algılama ilkeleri gerekli olabilir. Kanıtlama testi prosedürü yalnızca PLC modülünü değil, sinyal zincirinin tamamını da doğrulamalıdır.

Koruyucu mimariler için mühendisler, tanılama kapsamı, yedeklilik ve kontrollü arıza davranışı sağlamak üzere tasarlanmış uygun endüstriyel güvenlik modüllerini de inceleyebilir. Donanım seçimi yine de eksiksiz güvenlik yaşam döngüsünü izlemelidir ve uygulamaya özgü analizin yerini tutamaz.

Tasarım FMEA'sı ve Proses FMEA'sı Farklı Riskleri Ele Alır

Tasarım FMEA, mühendislik ürünü veya sistemi inceler. Seçilen mimarinin, bileşenlerin, malzemelerin ve kontrol işlevlerinin amaçlandığı gibi çalışıp çalışamayacağını değerlendirir. Yöntem genellikle konsept geliştirme, ayrıntılı tasarım ve tasarım değişiklikleri sırasında uygulanır. Tasarımın değiştirilmesi maliyetli hâle gelmeden önce en değerlidir.

Proses FMEA; üretim, montaj, kurulum, devreye alma veya bakım faaliyetlerini inceler. Bir kabinin elektrik tasarımı doğru olabilir, ancak kurulum süreci yine de gevşek terminallere, ters polariteye, yanlış sigorta değerlerine veya hatalı kablo tanımlamasına yol açabilir. Bakım faaliyeti hatalı ürün yazılımı, uygun olmayan yedek parçalar, devre dışı bırakılmış alarmlar veya etkin bırakılmış baypaslar oluşturabilir.

Bu iki FMEA türü birbirini desteklemelidir. Tasarım kontrolleri kurulum hassasiyetini azaltabilirken, proses kontrolleri tasarımın ortadan kaldıramadığı uygulama hatalarını önleyebilir. Yalnızca ekipman tasarımını gözden geçirmek, yaşam döngüsündeki birçok riski ele almadan bırakır. Yalnızca iş sürecini gözden geçirmek ise özgün mimariye yerleşik zayıflıkları gizleyebilir.

Kritik otomasyon sistemlerinde, her iki analiz de önemli değişikliklerden sonra güncellenmelidir. Bir kontrolörün değiştirilmesi, ağ geçişi, yazılım yükseltmesi veya kanıtlama testi prosedüründeki bir değişiklik yeni hata türlerine yol açabilir. Tesis çevrelerinde gelişirken geçmiş çalışma sayfaları olduğu gibi dondurulmamalıdır.

FMECA Daha Resmî Bir Kritiklik Değerlendirmesi Ekler

Hata Türleri, Etkileri ve Kritiklik Analizi, resmî kritiklik hesaplamaları ekleyerek FMEA yapısını genişletir. Yöntem; bileşen arıza oranlarını, çalışma maruziyetini, görev aşamalarını, şiddet kategorilerini ve koşullu olasılıkları kullanabilir. Büyük bir sistem çok sayıda hata türü içerdiğinde ve mühendislik kaynaklarının en önemli katkı sağlayan unsurlara yönlendirilmesi gerektiğinde faydalıdır.

Kritiklik hesaplamaları büyük ölçüde veri kalitesine bağlıdır. Genel arıza oranı veritabanları başlangıç noktası sağlar, ancak gerçek kurulumu yansıtmayabilir. Sıcaklık, titreşim, kirlenme, elektriksel stres, bakım kalitesi ve görev döngüsü gerçek performansı etkiler. Yeterli işletme geçmişi mevcut olduğunda, genel varsayımların yerini tesise özgü kanıtlar almalıdır.

Analiz ayrıca hemen tespit edilen arızalar ile gizli kalan arızaları birbirinden ayırmalıdır. Beklemedeki bir sistemde meydana gelen gizli bir arıza, başka bir bileşen arızalanana veya bir talep oluşana kadar üretimi etkilemeyebilir. Uzun süre fark edilmeden kalması, nispeten seyrek görülen bir arızayı son derece önemli hâle getirebilir. Bu nedenle tespit aralıkları ve kanıt testlerinin etkinliği de dâhil edilmelidir.

FMECA, sonuçları tasarım veya bakım faaliyetlerine yön verdiğinde en yararlı hâle gelir. Mimariyi, yedek parçaları, tanılamayı, testleri veya işletme prosedürlerini etkilemeyen karmaşık bir sıralama tablosunun değeri sınırlıdır. Amaç, kendi başına hesaplama yapmak değil, pratik risk azaltımı sağlamaktır.

FMEA Nerede İyi Çalışır ve Nerede Yanıltabilir

FMEA, bileşen bazında disiplinli bir inceleme sağlar. Açıklanması görece kolaydır ve mühendislik, işletme, bakım, kalite ve güvenlik personelinin katılımını destekler. Ortaya çıkan aksiyon listesi; tasarım değişiklikleri, denetimler, tanılama çalışmaları ve bakım iyileştirmeleriyle doğrudan ilişkilendirilebilir.

Yöntem, çok büyük sistemlere uygulandığında tekrara dayalı hâle gelebilir. Ekipler, düşük değerli arıza türlerini belgelemek için aşırı zaman harcarken sistem etkileşimlerini gözden kaçırabilir. Geleneksel FMEA ayrıca genellikle tek seferde bir arızayı inceler. Birden fazla eş zamanlı arıza ve sıraya bağlı olaylar net biçimde ortaya çıkmayabilir.

Puanlama sistemleri başka bir risk oluşturur. Ekipler, tercih edilen bir önceliğe ulaşmak için derecelendirmeleri değiştirebilir veya nihai sayıyı, dayandığı yargıdan daha nesnel kabul edebilir. Düşük bir puan, arızanın kabul edilebilir olduğunu kanıtlamaz. Yüksek şiddetli olaylar, ortak nedenli arızalar ve mevzuat gereklilikleri ayrı bir incelemeye tabi tutulmalıdır.

FMEA'nın kalitesi, onu tamamlayan kişilere bağlıdır. Bir tasarımcı tarafından hazırlanan çalışma sayfası, operatörlerin ve teknisyenlerin bildiği saha gerçeklerini gözden kaçırabilir. Güçlü çalışmalar, tasarım bilgisini gerçek bakım geçmişi ve işletme deneyimiyle birleştirir.

Monte Carlo Simülasyonu Belirsizliği Bir Dağılıma Dönüştürür

Endüstriyel güvenilirlik hesaplamaları çoğu zaman belirsiz girdiler içerir. Bileşen ömrü değişir, onarım süresi farklılık gösterir, yedek parça teslimatı öngörülemez ve çevresel stres arıza davranışını etkiler. Tek bir ortalama değer bu değişkenlikleri her zaman temsil edemez. Monte Carlo simülasyonu, tekrarlı rastgele örnekleme yoluyla bu sorunu ele alır.

Mühendis önce bir sistem modeli oluşturur ve belirsiz değişkenlere olasılık dağılımları atar. Ardından simülasyon birçok olası kombinasyon üretir. Bir çalıştırmada pompanın 8.000 saat sonra arızalandığı ve dört saat içinde onarıldığı varsayılabilir. Başka bir çalıştırmada daha geç bir arıza meydana gelebilir; ancak gerekli yedek parça bulunmadığından onarım çok daha uzun sürebilir.

Binlerce veya milyonlarca çalıştırmadan sonra sonuçlar bir dağılım oluşturur. Model; beklenen duruş süresini, üretim kaybını, sistem kullanılabilirliğini, görevin başarı olasılığını, yedek parça talebini veya bakım maliyetini tahmin edebilir. Ayrıca tek bir ortalama değerin içinde kaybolacak aşırı sonuçların olasılığını da gösterebilir.

Şekil 4. Monte Carlo simülasyonu, olası sonuçlar aralığını tahmin etmek için rastgele oluşturulan çok sayıda arıza ve onarım senaryosunu değerlendirir.

Güvenilir Bir Monte Carlo Güvenilirlik Modeli Oluşturma

Simülasyonun kalitesi sistem modeline bağlıdır. Model; bileşenleri, işletim kurallarını, arıza dağılımlarını, onarım davranışını, bağımlılıkları, yedek bekletme mantığını ve bakım kaynaklarını temsil etmelidir. Bu faktörler sistem performansını etkilediğinde hava durumunu, üretim talebini, lojistik gecikmelerini ve insan müdahalesini de içerebilir.

Simüle edilen her çalıştırma, sistemi zaman içinde izler. Bileşenler örneklenen dağılımlara göre arızalanır, kaynaklar kullanılabilir olduğunda onarımlar başlar ve model sistemin çalışır, performansı düşmüş veya kullanılamaz durumda kalıp kalmadığını kaydeder. Sürecin tekrarlanması, farklı performans ölçütleri için tahminler üretir.

Doğrulama zorunludur. Ekip, modeli basitleştirilmiş hesaplamalarla, bilinen işletim durumlarıyla ve geçmiş tesis sonuçlarıyla karşılaştırmalıdır. Beklenmeyen sonuçlar, yazılımdan geldiği için kabul edilmek yerine araştırılmalıdır. Temel mantık eksik olduğunda, görsel açıdan etkileyici bir simülasyon yine de yanlış olabilir.

Duyarlılık analizi, sonucu hangi varsayımların belirlediğini ortaya çıkarmaya yardımcı olur. Onarım süresinin arıza oranından çok daha büyük bir etkisi varsa yönetim, yedek parça bulunabilirliğini ve arıza teşhis hızını iyileştirerek daha fazla değer elde edebilir. Ortak nedenli arıza olasılığı baskınsa, daha fazla sayıda aynı bileşen eklemek çok az fayda sağlayabilir.

Arıza Mekanizmasına Uyan Olasılık Dağılımlarını Seçme

Üstel dağılım, sabit bir arıza oranı varsayar. Bazı elektronik bileşenler için yararlı çalışma ömürleri boyunca uygun olabilir. Weibull dağılımı daha esnektir ve erken dönem arızalarını, rastgele arızaları veya yıpranma davranışını temsil edebilir. Lognormal dağılımlar, onarım süreleri ve birden fazla çarpan faktörden etkilenen süreçler için genellikle kullanışlıdır.

Seçim, yazılım kolaylığından ziyade fiziksel mekanizmayı yansıtmalıdır. Aşınma kaynaklı bir rulman arızası, rastgele bir iletişim hatasıyla doğal olarak aynı davranışı izlemez. Her ikisi için sabit bir arıza oranı kullanmak uzun vadeli tahminleri çarpıtabilir. Güvenilirlik mühendisleri, dağılımı seçmeden önce çalışma geçmişini ve arıza mekanizmalarını incelemelidir.

Geçmiş veriler genellikle temizleme gerektirir. Bakım sistemleri planlı değişimi işlevsel arızayla karıştırabilir. Arıza tarihleri, arızanın gerçekleştiği tarih yerine iş emrinin açıldığı tarih olarak girilmiş olabilir. Varlık adları, çalışma saatleri ve arıza kodları da sahalar arasında tutarsız olabilir.

Verilerin sınırlı olması analizi engellemez, ancak belirsizlik görünür kalmalıdır. Uzman görüşü, tedarikçi bilgileri ve sektörel veri tabanları erken tahminleri destekleyebilir. Model, belirsiz tek bir varsayımı kesin bir gerçek olarak sunmak yerine gerçekçi bir aralığı test etmelidir.

Örnek: Üç Kompresörlü Bir İstasyonun Kullanılabilirliği

Üç gaz kompresöründen oluşan bir istasyon düşünün. Tam üretim için iki ünite gerekirken üçüncü ünite yedek kapasite sağlar. Her makinenin çalışma saati, bakım geçmişi ve soğutma performansı farklıdır. İstasyonda yalnızca bir uzman bakım ekibi bulunduğundan, aynı anda yalnızca bir büyük onarım gerçekleştirilebilir.

Yedek rulmanların teslimatı birkaç gün sürer ve soğutma sistemi arızaları yüksek ortam sıcaklıklarında daha sık meydana gelir. Bu etkileşimleri tek bir basit kullanılabilirlik denklemiyle temsil etmek zordur. Monte Carlo modeli; kompresör arızalarını, onarım sürelerini, hava koşulu dönemlerini, teknisyen kullanılabilirliğini ve lojistik gecikmelerini örnekleyebilir.

Sonuçlar tam kapasitede kullanılabilirliği, azaltılmış kapasitede işletimi ve istasyonun tamamen devre dışı kalmasını gösterebilir. Yönetim, alternatif yatırımları karşılaştırabilir. İlave rulman stoklamak, aşırı duruş süresini başka bir genel bakım teknisyeni işe almaktan daha etkili biçimde azaltabilir. Soğutma güvenilirliğini artırmak, genel olarak sağlıklı bir kompresörü değiştirmekten daha yüksek değer sağlayabilir.

Model, bakım aralıklarını da test edebilir. Daha kısa önleyici bakım aralıkları arızaları azaltabilir, ancak planlı duruş süresini ve bakım kaynaklı hataları artırabilir. Simülasyon, her iki etkinin aynı operasyonel model içinde değerlendirilmesine olanak tanır.

Monte Carlo Simülasyonunun İyi Çalıştığı ve Başarısız Olduğu Durumlar

Monte Carlo yöntemleri, birçok belirsiz değişkenin etkileşime girdiği durumlarda güçlüdür. Karmaşık lojistik süreçlerini, onarım kuyruklarını, hava koşullarının etkilerini, üretim talebini ve bakım kararlarını temsil edebilirler. Ortaya çıkan dağılım, tek bir ortalamadan daha fazla bilgi sağlar. Ayrıca, ciddi ancak seyrek görülen sonuçların olasılığını göstererek riske dayalı kararları destekler.

Temel zayıflık, modelin güvenilirliğidir. Karmaşık bir simülasyon, çıktısı sayısal olarak kesin göründüğü için yanlış bir güven duygusu yaratabilir. Program yalnızca analistin girdiği varsayımların sonuçlarını hesaplar. Eksik bağımlılıklar veya gerçekçi olmayan dağılımlar yanıltıcı sonuçlar üretebilir.

Simülasyon, kararlı tahminler elde etmek için yeterli sayıda çalıştırma da gerektirir. Nadir olay olasılıkları, özel örnekleme teknikleri gerektirebilir; çünkü sıradan rastgele simülasyon pratikte uygulanamayacak kadar çok sayıda çalıştırma gerektirir. Kullanıcıların istatistiksel belirsizliği anlaması için güven aralıkları raporlanmalıdır.

Bu nedenle yöntem; model mantığı, veri kaynakları ve sınırlamalar şeffaf kaldığında en değerli hâline gelir. Güvenilirlik kararları, varsayımları işletme ve mühendislik personeline açıklanamayan bir grafiğe dayandırılmamalıdır.

Kök Neden Analizi olaydan sonra başlar

Kök Neden Analizi, gerçek bir arızanın, kalite probleminin veya güvenlik olayının neden meydana geldiğini araştırır. Hasarlı bileşeni belirlemenin ötesine geçer. Bir motor, yatağın sıkışması nedeniyle durabilir; ancak yalnızca yatağı değiştirmek çalışmayı yeniden sağlar. Soruşturma, yatağın neden bu duruma geldiğini belirlemelidir.

Daha derin nedenler arasında kirlenme, yanlış yağlama, uygunsuz depolama, montaj hasarı, aşırı proses yükü veya atlanan denetimler bulunabilir. Kurumsal koşullar da katkıda bulunabilir. Bakım görevleri kaldırılmış, yedek parçalar uygun olmamış veya üretim baskısı düzeltici çalışmaları geciktirmiş olabilir.

Bu nedenle RCA; belirtileri, doğrudan fiziksel nedenleri, katkıda bulunan koşulları ve altta yatan sistem zayıflıklarını birbirinden ayırır. Bu ayrım, kuruluşun her onarımı kalıcı bir çözüm olarak görmesini önler. Ayrıca gelecekteki FMEA, FTA, bakım planlaması ve işletme prosedürlerini iyileştirebilecek kanıtlar üretir.

Şekil 5. RCA, bir arızayı görünen belirtinin ötesine kadar izler ve arızanın meydana gelmesine izin veren teknik ve kurumsal koşulları belirler.

Tesis normale dönmeden önce kanıtlar korunmalıdır

Endüstriyel kanıtlar hızla yok olabilir. Operatörler alarmları sıfırlayabilir, teknisyenler modülleri değiştirebilir ve proses koşulları değişebilir. Kontrolör günlükleri daha önceki olayların üzerine yazabilir; hasarlı bileşenler de incelenmeden önce atılabilir. Bu nedenle disiplinli bir RCA süreci kanıtların korunmasıyla başlar.

Ekip; geçmiş trendlerini, alarm listelerini, kontrolör olay günlüklerini, röle kayıtlarını, iş emirlerini, fotoğrafları, hasarlı parçaları, yazılım sürümlerini, yapılandırma dosyalarını ve operatör gözlemlerini toplamalıdır. Her öğe, kaynağı ve zamanıyla birlikte tanımlanmalıdır. Fiziksel kanıtlar, daha ayrıntılı inceleme gerekip gerekmediği soruşturma sonucunda belirlenene kadar kontrollü biçimde muhafaza edilmelidir.

Zaman senkronizasyonuna özellikle dikkat edilmelidir. Bir kontrolör, tarihçi, koruma rölesi, sunucu ve bakım sistemi farklı zaman damgaları kaydedebilir. Araştırmacılar, olay sırasını oluşturmadan önce bu farkları düzeltmelidir. Aksi takdirde daha sonraki bir alarm, başlatıcı olaymış gibi yanlış görünebilir.

Operatör görüşmeleri hızlı, ancak dikkatli bir şekilde tamamlanmalıdır. İnsanlar, otomatik sistemlerin kaydetmediği sıralamayı ve bağlamı hatırlayabilir. İfadeleri suçlama amacıyla değil, kanıt olarak değerlendirilmelidir. Amaç, kararların alındığı işletim ortamını anlamaktır.

Neden Sorusunu Sormadan Önce Olay Zaman Çizelgesinin Oluşturulması

Güçlü bir zaman çizelgesi, doğrulanmış gerçekleri yorumdan ayırır. Arızadan önce, arıza sırasında ve arızadan sonra ne olduğunu kaydeder. Her olay; tarihçi değeri, alarm kaydı, bakım işlemi, fotoğraf veya tanık ifadesi gibi bir kaynağa bağlanmalıdır. Boşluklar ve tutarsızlıklar görünür kalmalıdır.

Operatöre görüntülenen ilk alarm, her zaman gerçekleşen ilk fiziksel olay değildir. Alarm yığınları, başlatıcı koşulu yüzlerce ikincil mesajın altında gizleyebilir. Yüksek çözünürlüklü olay sırası verileri, basınç kararsızlığının, güç bozulmasının veya iletişim kaybının daha önce başladığını gösterebilir. Zaman çizelgesi, nedeni sonuçtan ayırmaya yardımcı olur.

Ekip, olaylar arasındaki sırayı anladıktan sonra Beş Neden, balık kılçığı diyagramları, bariyer analizi, değişiklik analizi veya nedensel faktör çizelgeleri gibi araçları kullanabilir. Basit olaylar kısa bir nedensel zincirle açıklanabilir. Karmaşık olaylar genellikle birbiriyle etkileşen çeşitli teknik ve kurumsal koşulları içerir.

İnceleme, makul görünen tek bir açıklama bulunduktan sonra sona ermemelidir. Alternatif hipotezler kanıtlara göre test edilmelidir. Desteklenmeyen varsayımlar, doğrulanmış nedenler olarak sunulmak yerine varsayım olarak tanımlanmış şekilde kalmalıdır.

Örnek: Tekrarlanan Değişken Hızlı Sürücü Arızaları

Bir tesiste, bir konveyörü kontrol eden değişken hızlı sürücülerde tekrarlanan arızalar yaşanır. Bakım ekibi her olaydan sonra sürücüyü değiştirir ve üretim normale döner. Birkaç ay sonra başka bir sürücü arızalanır. Tekrarlanan değişimler, sorunun yalnızca sürücünün kendisi olmayabileceğini düşündürür.

RCA ekibi, arıza tarihlerini çevresel koşul ve bakım kayıtlarıyla karşılaştırır. Arızaların çoğu sıcak yaz dönemlerinde meydana gelmiştir. Kabin sıcaklığı eğilimleri, tercih edilen aralığın üzerinde uzun süreli çalışmayı gösterir. İnceleme, tıkanmış filtreleri, kısıtlanmış hava akışını ve soğutma yolu çevresinde yoğun toz birikimini ortaya çıkarır.

Bakım geçmişi, personel seviyeleri değiştikten sonra düzenli filtre temizliğinin önleyici bakım planından çıkarıldığını gösteriyor. Arızalanan bileşen sürücüdür; ancak doğrudan fiziksel neden, kabin sıcaklığının aşırı yükselmesidir. Havalandırmanın kısıtlanması ve bakım görevinin eksikliği, katkıda bulunan ve kurumsal nedenlerdir.

Bu nedenle düzeltici faaliyet, başka bir sürücüyü değiştirmekle sınırlı kalmamalıdır. Tesis, filtre bakımını yeniden düzenleyebilir, sıcaklık alarmları kurabilir, pano soğutmasını iyileştirebilir ve muhafaza tasarımını gözden geçirebilir. Etkinlik, bir sonraki yüksek sıcaklık döneminde doğrulanmalıdır.

Düzeltici Faaliyetler Doğrulanmış Nedenlerle Bağlantılı Olmalıdır

Birçok KNA raporu, düzeltici faaliyetlerin planlanması sırasında zayıflar. Ekipler, bilginin yetersiz olduğunu kanıtlamadan ek eğitim önerebilir. Gerçek sorun zayıf ekipman tasarımıyken prosedürleri değiştirebilirler. Gerçek arıza mekanizmasını tespit edemeyen denetimler ekleyebilirler.

Her faaliyet, doğrulanmış bir nedeni veya katkıda bulunan bir koşulu ele almalıdır. Bir sorumlusu, tamamlanma tarihi ve tanımlanmış bir doğrulama yöntemi olmalıdır. Kuruluş; geçici sınırlama, düzeltici faaliyet ve uzun vadeli önleyici faaliyet arasındaki ayrımı yapmalıdır. Üretimi yeniden başlatmak, tekrarını önlemekle aynı şey değildir.

Etkinlik, uygulamadan sonra gözden geçirilmelidir. Tamamlanmış bir faaliyet otomatik olarak başarılı sayılmaz. Tesis, arıza olasılığının azalıp azalmadığını, yeni kontrolün kullanılıp kullanılmadığını ve başka bir risk oluşturup oluşturmadığını doğrulamalıdır. Bu geri bildirim, güvenilirlik iyileştirme döngüsünü tamamlar.

Ciddi soruşturmalar bağımsız bir inceleme gerektirebilir. Olayla yakından ilgili ekipler, önceki varsayımlardan veya kurumsal baskıdan etkilenebilir. Harici ya da işlevler arası bir inceleme, nihai sonuçlar kabul edilmeden önce analize itiraz edebilir.

İnsan Hatası Nadiren Tam Bir Kök Nedendir

Zayıf soruşturmalarda “operatör hatası” ve “bakım hatası” ifadeleri sıkça görülür. Bu etiketler son işlemi kimin yaptığını açıklar; ancak işlemin neden olası hâle geldiğini açıklamaz. İnsanlar arayüzler, prosedürler, personel düzeyleri, üretim talepleri, eğitim sistemleri ve ekipman tasarımları içinde çalışır. Soruşturma tüm bu koşulları incelemelidir.

Bir operatör, ekrandaki iki nesne neredeyse aynı göründüğü için yanlış kumandayı seçebilir. Bir teknisyen, tanımlama tutarsız olduğu için yanlış parçayı takabilir. Bir süpervizör, kuruluş kesintisiz üretimi ödüllendirirken gerçekçi bir duruş aralığı sağlamadığı için bakımı erteleyebilir.

Bu koşulları anlamak, bireysel sorumluluğu ortadan kaldırmaz. Aynı sistemin başka bir kişiyi aynı hataya yöneltmesini önler. Suçlamaya odaklanan bir soruşturma, sorumlulukla ilgili acil talebi karşılayabilir; ancak altta yatan zayıflığı olduğu gibi bırakabilir.

Etkili KNA, sistemin kararı nasıl şekillendirdiğini inceler. Alarmların anlaşılır olup olmadığını, prosedürlerin uygulanabilir olup olmadığını, iş yükünün makul düzeyde bulunup bulunmadığını ve gerekli araçların mevcut olup olmadığını sorgular. Bu sorular, insanlara yalnızca daha dikkatli olmalarını söylemekten daha güçlü düzeltici faaliyetler ortaya çıkarır.

Kök Neden Analizinin İyi Çalıştığı ve Çalışmadığı Durumlar

RCA, gerçek işletim deneyimini önleyici bilgiye dönüştürür. Öngörücü çalışmaların gözden kaçırdığı tasarım zayıflıklarını, bakım eksikliklerini, prosedür sorunlarını ve kurumsal baskıları ortaya çıkarabilir. Bulguları, güvenilirlik modellerini ve gelecekteki proje standartlarını iyileştirebilir.

Yöntem tepkiseldir çünkü bir olaydan sonra başlar. Ağır sonuçlu sektörler yalnızca arızalardan ders çıkarmaya güvenemez. FMEA ve FTA gibi proaktif yöntemler hâlâ gereklidir. RCA, gerçek işletimden elde edilen kanıtlarla varsayımları güncelleyerek bu yöntemleri tamamlamalıdır.

İncelemeler öznel hâle de gelebilir. Doğrulama yanlılığı, ekiplerin uyan ilk açıklamayı tercih etmesine yol açabilir. Eksik kanıtlar, sonuçların belirsiz kalmasına neden olabilir. Güçlü raporlar; doğrulanmış nedenleri, katkıda bulunan etkenleri, hipotezleri ve çözülmemiş soruları açıkça birbirinden ayırır.

RCA'nın değeri, takibine bağlıdır. Teknik açıdan güçlü bir inceleme, eylemler geciktirildiğinde, etkisi azaltıldığında veya hiç doğrulanmadığında çok az fayda sağlar. Bu nedenle yönetimin taahhüdü, analitik beceri kadar önemlidir.

Markov Modelleri Sistemi Değişen Durumlar Boyunca İzler

Markov modellemesi, bir sistemi tanımlanmış çalışma durumları aracılığıyla temsil eder. Basit bir sistem yalnızca çalışma durumu ve arıza durumundan oluşabilir. Arızaya toleranslı bir sistem genellikle tamamen yedekli, bozulmuş, arızalı, onarımda veya yedek parça bekliyor gibi ek durumlar gerektirir. Geçişler bu durumları birbirine bağlar.

Bir arıza oranı, sistemi tamamen çalışır durumdan bozulmuş duruma geçirebilir. Başka bir arıza, sistemi bozulmuş durumdan kullanılamaz duruma geçirebilir. Bir onarım oranı, sistemi tam çalışır duruma döndürebilir. Model, sistemin zaman içinde her bir durumda bulunma olasılığını hesaplar.

Bu yapı özellikle onarılabilir sistemler için yararlıdır. Yedekliliği, beklemedeki ekipmanı, tanılama kapsamını, bakım müdahalesini ve kısmi üretim kapasitesini temsil edebilir. Basit bir güvenilirlik formülünün aksine, sistemin ilk arızadan sonra ne kadar süre savunmasız kalabileceğini gösterir.

Şekil 6. Markov modelleri, sistemlerin sağlıklı, bozulmuş, arızalı ve onarılmış durumlar arasında nasıl hareket ettiğini açıklar.

İki Durumlu Model Temel İlkeyi Sağlar

En basit Markov modeli, bir çalışma durumu ve bir arıza durumundan oluşur. Arıza oranı, çalışma durumundan arıza durumuna geçişi belirler. Onarım oranı, çalışma durumuna geri dönüşü belirler. Model, bu geçişlerden yararlanarak tanımlı bir süre boyunca veya kararlı durum koşullarında kullanılabilirliği tahmin edebilir.

Bu model, basit ve onarılabilir ekipmanlar için yararlıdır ancak yedekli otomasyon sistemlerinin çoğunu tam olarak açıklamaz. Çift kanallı bir kontrolör, kanallardan biri arızalandıktan sonra çalışmaya devam edebilir. Sistem işlevsel kalır ancak yedekliliğini kaybeder. Artık ikinci bir arızaya daha fazla maruz kaldığı bozulmuş bir durumda bulunur.

Bozulmuş durumun eklenmesi, modelin sistemin tam koruma olmadan ne sıklıkla ve ne kadar süreyle çalıştığını hesaplamasını sağlar. Onarım hızı büyük önem kazanır. Güvenilir bileşenlere sahip bir sistem bile arıza teşhisi, yedek parçanın teslimi veya bakım onayının yavaş olması durumunda bozulmuş durumda aşırı süre geçirebilir.

Model, tespit edilen ve tespit edilemeyen arızaları da birbirinden ayırabilir. Tespit edilen bir kanal arızası anında onarımı tetikleyebilir. Tespit edilemeyen bir arıza, bir talep oluşana veya başka bir arıza meydana gelene kadar gizli kalabilir. Tanılama kapsamı geçiş yapısını değiştirir ve dolayısıyla hesaplanan kullanılabilirliği ve riski de değiştirir.

Örnek: Çift Yedekli Bir Kontrolör Çifti

Yedekli bir çift olarak düzenlenmiş iki kontrolörü ele alalım. Birinci durum, her iki kontrolörün de sağlıklı olduğunu gösterir. İkinci durum, bir kontrolörün arızalandığını ve ikinci kontrolörün kontrolü sürdürdüğünü gösterir. Üçüncü durum, her iki kontrolörün de kaybedildiğini ve kontrolün tamamen kullanılamadığını gösterir.

Model, her kontrolörün arıza oranını ve arıza tespit edildikten sonraki onarım oranını içerir. Ayrıca devreye alma arızasını, ortak güç kaybını ve ortak bir yazılım kusurunu da içerebilir. Bu ek geçişler, analizin kusursuz bağımsızlık varsaymasını önler.

Sonuçlar tam yedeklilik kullanılabilirliği ile işlevsel kullanılabilirliği birbirinden ayırabilir. Sistem yılın büyük bölümünde prosesi kontrol edebilir durumda kalırken, yalnızca bir sağlıklı kontrolörle önemli sayıda saat çalışabilir. Bu bozulmuş durumdaki maruziyet, kritik bir uygulama için kabul edilemez olabilir.

Model, iyileştirme stratejilerini karşılaştırabilir. Yedek parçanın daha hızlı değiştirilmesi, üçüncü bir kontrolör eklemekten daha etkili biçimde bozulmuş durumdaki maruziyeti azaltabilir. Daha iyi tanılama, donanım arıza oranındaki küçük bir düşüşten daha büyük fayda sağlayabilir. Markov analizi bu ödünleşimleri ölçülebilir hâle getirir.

Yedek Ekipman İçin Etkin Arıza Durumundan Daha Fazlası Gerekir

Yedekli yapı ek davranışlar ortaya çıkarır. Bir yedek pompa, çalışan pompa arızalanana kadar durur durumda kalabilir. Yedek ünitede gizli bir arıza bulunabilir, ünite çalışmaya başlayamayabilir veya bir transfer mantığı sorunuyla karşılaşabilir. İzolasyon vanaları da gerekli konuma geçemeyebilir.

Bir Markov modeli; etkin durumdaki sağlıklı ekipman, kullanılamayan yedek ekipman, transfer arızası, azaltılmış kapasite ve toplam sistem kaybı için durumlar içerebilir. Kanıt testleri sistemi bilinmeyen pasif bir durumdan bilinen bir duruma doğru taşır. Testler arasındaki aralık, gizli arızaların ne kadar süreyle mümkün kalacağını etkiler.

Bakım politikaları aynı yapı içinde değerlendirilebilir. Daha kısa test aralıkları gizli arızaların tespitini iyileştirir, ancak bakım iş yükünü artırabilir ve ek hatalara yol açabilir. Model, daha sık test yapmanın her zaman daha iyi olduğunu varsaymak yerine bu karşıt etkileri karşılaştırabilir.

Bekleme analizi, onarım lojistiğini de içermelidir. Arızalı bir bekleme bileşeni üretimi hemen kesintiye uğratmayabilir; bu nedenle onarım ertelenebilir. Bu gecikme, etkin ünite daha sonra arızalandığında sistemi korumasız bırakır. Dolayısıyla operasyonel öncelikler, güvenilirliği donanım özellikleri kadar etkiler.

Markov Varsayımı Hem Basitlik Hem de Sınırlamalar Yaratır

Temel bir Markov modeli, gelecekteki geçiş davranışının tüm geçmişe değil, mevcut duruma bağlı olduğunu varsayar. Bu varsayım matematiği basitleştirir ve çoğu zaman sabit geçiş oranları gerektirir. Bazı endüstriyel ekipmanlar, sınırlı bir dönem boyunca bu yaklaşıma makul ölçüde uyar.

Yaşlanma ve birikmiş hasar bu varsayımı geçersiz kılabilir. Aşırı aşınmış bir rulmanın gelecekteki arıza davranışı, her ikisi de hâlen çalışıyor olsa bile yeni bir rulmanınkiyle aynı değildir. Ek bozulma durumları yaşlanmayı yaklaşık olarak temsil edebilir; daha doğru bir temsil için yarı Markov veya başka modeller gerekebilir.

Durum patlaması da başka bir zorluktur. Her bileşenin durumu, olası sistem durumlarının sayısını katlayabilir. Karmaşık bir yedekli tesis, kısa sürede binlerce veya milyonlarca kombinasyon oluşturabilir. Analizi yönetilebilir tutmak için model azaltma, gruplama veya simülasyon gerekebilir.

Model, her fiziksel değişimi temsil etmeden kararı destekleyecek kadar ayrıntı içermelidir. Aşırı karmaşıklık, bakım ve doğrulama sorunları yaratır. Gereğinden basit bir model önemli davranışları gizlerken gereğinden ayrıntılı bir modelin açıklanması imkânsız hâle gelir.

Markov Modellemesinin İyi Çalıştığı ve Çalışmadığı Yerler

Markov modellemesi onarılabilir yedekli sistemler, beklemedeki ekipmanlar, düşük performanslı işletim modları ve tanılama kapsamı için uygundur. Kullanılabilirlik analizini destekler ve bakım müdahalesinin sistemin maruz kaldığı riski nasıl değiştirdiğini gösterir. Özellikle arıza ve onarım durumlarının sıralamasının önemli olduğu durumlarda yararlıdır.

Yöntem, durumların ve geçiş oranlarının doğru tanımlanmasına bağlıdır. Sabit oran varsayımları yaşlanmayı, çevresel değişkenliği veya bakım kalitesini yansıtmayabilir. Ortak nedenli arızalar, bağımsız bileşen oranlarının içine gizlenmek yerine açıkça modellenmelidir.

Sonuçlar duyarlılık analiziyle desteklenmelidir. Ekip; arıza oranları, onarım süreleri, tanılama kapsamı ve ortak neden varsayımları değiştiğinde sonuçların nasıl değiştiğini test etmelidir. Yalnızca tek bir iyimser varsayım altında kabul edilebilir görünen bir tasarım sağlam değildir.

Markov modelleri fiziksel kanıttan ziyade analitik araçlardır. Testler, işletim kanıtları, FMEA ve FTA yine gereklidir. Model, stratejilerin karşılaştırılmasına yardımcı olur; ancak gerçek mimarinin doğrulanmasının yerini tutamaz.

Beş Yöntemin Tek Bir Güvenilirlik Sistemi Olarak Kullanılması

Beş teknik, birbirine bağlandığında en büyük değeri sağlar. FMEA, tasarım sırasında ayrıntılı bileşen arıza türlerini belirleyebilir. Ardından FTA, hangi kombinasyonların kritik bir sistem olayına katkıda bulunduğunu belirleyebilir. Markov modellemesi, ilk arızadan sonra ve onarım sırasında sistemin nasıl davrandığını açıklayabilir.

Monte Carlo simülasyonu; onarım süreleri, yedek parçaların teslimatı, hava durumu ve bakım iş yükü gibi belirsiz girdileri sınayabilir. RCA, gerçek arızalardan sonra kanıt sağlar ve özgün modellerin gözden kaçırdığı varsayımları ortaya çıkarabilir. Bunun ardından modeller tarihî belgeler olarak korunmak yerine güncellenmelidir.

Bir FTA'nın iki kontrolör arızasını bağımsız kabul ettiğini varsayalım. Daha sonra yapılan bir RCA, her iki kontrolörün de bir bakım teknisyeninin aynı hatalı yapılandırmayı yüklemesinin ardından arızalandığını gösterir. Hata ağacına ortak bir bakım olayı eklenmelidir. Markov ve Monte Carlo modelleri de yeni bağımlılığı içermelidir.

Bu geri bildirim süreci, yaşayan bir güvenilirlik programı oluşturur. Öngörücü analiz tasarıma yön verir, işletme kanıtları varsayımları sınar ve inceleme sonuçları sonraki model neslini iyileştirir. Güvenilirlik çalışmaları, tek seferlik bir proje gerekliliği olmaktan çıkarak sistem yaşam döngüsünün bir parçası hâline gelir.

Ortak Nedenli Arızalar Tüm Bir Yedekli Mimarinin Devre Dışı Kalmasına Yol Açabilir

Ortak nedenli arızalar, tek bir temel koşul yoluyla birden fazla kanalı etkiler. Ortak güç, soğutma, ağ altyapısı, yazılım, çevresel maruziyet ve bakım uygulamaları sık görülen örneklerdir. Bu arızalar özellikle tehlikelidir; çünkü kâğıt üzerinde güçlü görünen yedekliliği devre dışı bırakabilirler.

Fiziksel ayırma bazı ortak nedenleri azaltır. Farklı ekipman veya yazılımlar diğer bazı nedenleri azaltabilir. Bağımsız doğrulama, bakım ve yapılandırma hatalarını azaltabilir. Ancak çeşitlilik; eğitim, yedek parça, test ve entegrasyon karmaşıklığını da artırır.

Doğru çözüm riske bağlıdır. Farklı kontrolör teknolojilerinin kurulması, yaygın yazılım arızalarını azaltabilir; ancak yeni iletişim ve bakım zorlukları yaratabilir. Her ikisi de su basma riski olan aynı kabinde kaldığında ayrı güç kaynakları çok az fayda sağlayabilir. Güvenilirlik yöntemleri, hangi çeşitlilik önlemlerinin gerçekçi arıza mekanizmalarını ele aldığını belirlemeye yardımcı olur.

Ortak neden varsayımları her nicel modelde açıkça belirtilmelidir. Yedekli kanalların tamamen bağımsız olduğunu varsaymak neredeyse her zaman iyimser bir sonuç üretir. Tesis deneyimi ve RCA bulguları, bu bağımlılıkları tahmin etmek için değerli kanıtlar sağlar.

Tanı Kapsamı Sistemin Ne Kadar Süre Savunmasız Kalacağını Belirler

Arızalar gizli kaldığında yedekli bir sistem etkin şekilde yönetilemez. Tanı kapsamı, otomatik veya manuel kontroller tarafından tespit edilen ilgili arızaların oranını ifade eder. Yüksek kapsam, farkında olmadan düşük performansla çalışma süresini azaltır. Ayrıca başka bir arıza meydana gelmeden önce bakımın yedekliliği yeniden sağlamasına olanak tanır.

Tanılama iddiaları dikkatle incelenmelidir. Bir denetleyici dahili işlemci arızalarını algılayabilir, ancak her saha kablolaması arızasını algılayamayabilir. Bir iletişim modülü toplam bağlantı kaybını algılayabilir, ancak hatalı veri eşlemesini fark edemeyebilir. Bir güç kaynağı tamamen çıkış kaybından sonra alarm verebilir, ancak kademeli bozulma konusunda hiçbir uyarı sağlamayabilir.

Kanıtlama testi, sürekli tanılamanın algılayamadığı arızaları kapsar. Test aralığı maruziyeti etkiler. Daha uzun aralıklar gizli arızaların daha uzun süre kalmasına izin verirken çok kısa aralıklar bakım yükünü ve test kaynaklı riski artırır. FMEA, Markov analizi ve işletme verileri dengeli bir aralığın belirlenmesini destekleyebilir.

Testler işlevin tamamını kapsamalıdır. Bir PLC girişini etkinleştirmek, saha anahtarının, kablolamanın, mantığın, çıkışın ve nihai elemanın tümünün doğru çalıştığını kanıtlamaz. Güvenilirlik analizi, her tanılama veya kanıtlama testinin tam olarak hangi arızaları ortaya çıkarabileceğini tanımlamalıdır.

Onarım Süresi Çoğu Zaman Arıza Oranı Kadar Önemlidir

Güvenilirlik programları sıklıkla bileşen arıza sıklığını azaltmaya odaklanır. Arıza toleranslı sistemlerde onarım süresi de aynı derecede önemli olabilir. İlk kanal arızalandıktan sonra sistem çalışmaya devam edebilir, ancak savunmasız kalır. Uzun onarım gecikmeleri, ikinci bir arızanın tamamen kayba yol açma olasılığını artırır.

Arızanın teşhisi, onaylar, teknisyen bulunabilirliği, yedek parçalar, erişim izinleri ve üretim koşulları, sistemin yeniden devreye alınma süresini etkiler. Doğru yedek parça kabine ulaştıktan sonra bir bileşenin değiştirilmesi on beş dakika sürebilir. Ancak yedek parçanın uluslararası olarak tedarik edilmesi gerektiğinde gerçek duruş süresi yine de günlere uzayabilir.

Geliştirilmiş tanılama, arızanın yerini belirleme süresini azaltabilir. Standartlaştırılmış modüller ve önceden yapılandırılmış yedekler değiştirme süresini kısaltabilir. Yerel stok, açık eskalasyon prosedürleri ve uzaktan mühendislik desteği lojistik gecikmeleri azaltabilir. Markov ve Monte Carlo modelleri bu iyileştirmelerin değerini niceliksel olarak belirleyebilir.

En iyi güvenilirlik yatırımı her zaman daha güçlü donanım değildir. Bazı sistemlerde onarım süresini azaltmak, bileşen arıza oranındaki küçük bir iyileştirmeden daha fazla risk azaltımı sağlayabilir. Analiz her iki seçeneği karşılaştırmalıdır.

DCS ve PLC Mimarilerine Güvenilirlik Analizi Uygulama

Kontrol sistemi güvenilirliği yalnızca merkezi işlemciye bağlı değildir. Mühendisler denetleyicileri, G/Ç modüllerini, iletişim ağlarını, güç kaynaklarını, sunucuları, operatör istasyonlarını, zaman senkronizasyonunu, saha arayüzlerini ve destekleyici hizmetleri gözden geçirmelidir. Paylaşılan her unsur ortak bir bağımlılığa dönüşebilir.

Yedekli denetleyiciler aynı G/Ç rafını paylaşabilir. Yedekli sunucular tek bir ağ anahtarına veya tek bir depolama sistemine bağlı olabilir. Uzak G/Ç ağları, aynı fiziksel güzergâhtan geçen ayrı iletişim kanallarını kullanabilir. Eksiksiz bir analiz, işlevi saha cihazından nihai kontrol eylemine kadar izlemelidir.

Arıza sonrasındaki gerekli davranış açıkça tanımlanmalıdır. Proses, kalan kontrolörle devam edebilir, manuel işletime aktarılabilir veya kontrollü bir duruşa geçebilir. Bakım personeli, arızalı kanalı nasıl belirleyeceğini ve sağlıklı kanalı etkilemeden sistemi nasıl yeniden çalışır hâle getireceğini bilmelidir.

Kontrol yükseltmeleri planlayan kuruluşlar, proses otomasyonu mimarilerinde kullanılan tipik DCS kontrol sistemi bileşenlerini de inceleyebilir. Bileşen seçimi, yalıtılmış ürün özellikleri yerine her zaman uygulamanın tamamına ilişkin güvenilirlik gereksinimlerini izlemelidir.

Güvenilir Modeller Güvenilir Bakım Verilerine Bağlıdır

Nicel güvenilirlik analizi, yalnızca temelindeki veriler kadar güçlüdür. Bakım kayıtları işlevsel arıza, planlı değiştirme, denetim ve modifikasyonu birbirinden ayırmalıdır. Arıza tarihi, işlevin kaybedildiği zamanı; yeniden devreye alma tarihi ise işletimin gerçekten yeniden kullanılabilir hâle geldiği zamanı göstermelidir.

Varlık kimlikleri; tarihçe sistemi, bakım sistemi, çizimler ve yedek parça veritabanı genelinde tutarlı kalmalıdır. Arıza kodları belirsiz belirtiler yerine mekanizmaları açıklamalıdır. “Durdu” ifadesi analitik açıdan çok az değer sağlar; “yağlama kirlenmesinin ardından rulman kilitlenmesi” ise gelecekteki modelleme ve önleme çalışmalarını destekler.

İşletim maruziyeti de dâhil edilmelidir. Sürekli çalışan bir pompa, yalnızca testler sırasında çalışan yedek bir pompayla doğrudan karşılaştırılamaz. Sıcaklık, nem, kirlenme, titreşim, elektriksel gerilim ve proses yükü, görünüşte aynı olan bileşenler arasındaki farkları açıklayabilir.

Veri temizleme, idari bir hazırlık yerine mühendislik çalışması olarak ele alınmalıdır. Hatalı sınıflandırmalar arıza oranlarını, onarım dağılımlarını ve model sonuçlarını çarpıtabilir. Analistler, sonuçları kabul etmeden önce olağandışı bulguları bakım ve işletme personeliyle gözden geçirmelidir.

Pratik Güvenilirlik İyileştirme İş Akışı

Bir güvenilirlik projesi, gerekli işlevin ve sistem sınırının tanımlanmasıyla başlamalıdır. Ekip, normal işletim sırasında ve güvenilir her arıza sonrasında hangi performansın gerekli olduğunu belirtmelidir. Çizimleri, kılavuzları, bakım geçmişini, işletim prosedürlerini, alarm kayıtlarını ve önceki olay raporlarını toplamalıdır.

FMEA daha sonra bileşen düzeyindeki arıza türlerini ve zayıf tespit kontrollerini belirleyebilir. FTA, kritik tepe olaylarını ve ortak bağımlılıkları inceleyebilir. Markov modellemesi bozulmuş durumları ve onarım müdahalesini değerlendirebilirken Monte Carlo simülasyonu arıza, bakım ve lojistikteki belirsizliği temsil edebilir.

Geçmişteki olaylar RCA aracılığıyla incelenmelidir. Bulgular, tasarım analizlerini ve nicel varsayımları güncellemek için kullanılmalıdır. Eylemler; sonuç, olasılık, tespit edilebilirlik, maruziyet, onarım süresi ve maliyete göre önceliklendirilmelidir.

Her eylemin bir sorumlusu, tamamlanma tarihi ve etkililik kontrolü olmalıdır. Analizler; büyük ekipman değişikliklerinden, yazılım yükseltmelerinden, proses değişikliklerinden veya bakım stratejisi değişikliklerinden sonra güncellenmelidir. Güvenilirlik, bir kez hazırlanıp saklanan bir rapor değil, sürekli sürdürülen bir mühendislik disiplinidir.

Zayıf Hata Toleransı İddialarını Ortaya Çıkaran Sorular

Güçlü bir inceleme, hangi işlevin kullanılabilir kalması gerektiğini ve sistemin hangi arızalara dayanabileceğini sorar. Yedekli kanalların fiziksel, elektriksel ve mantıksal olarak bağımsız olup olmadığını sorgular. Ayrıca gizli arızaların nasıl tespit edildiğini ve sistemin onarımdan önce ne kadar süreyle bozulmuş durumda kalabileceğini de sorar.

Ekip, değiştirme tedarik süresi uzun olan bileşenleri belirlemeli ve tek bir bakım hatasının birden fazla kanalı etkileyip etkileyemeyeceğini saptamalıdır. Yazılım ve konfigürasyon bağımlılıklarına da donanımla aynı düzeyde önem verilmelidir. Operatörler, bir arızadan sonra sistemin nasıl davrandığını ve hangi manuel işlemlerin hâlâ kullanılabilir olduğunu anlamalıdır.

Arıza ve onarım varsayımları, mümkün olduğunda tesis verileriyle desteklenmelidir. Düzeltici faaliyetler tamamlandıktan sonra doğrulanmalıdır. Kanıt testleri, münferit ekipman tepkisi yerine koruyucu işlevin tamamını göstermelidir.

Bu sorular, sistemin yedekli olduğuna dair genel bir ifadeden daha değerlidir. Hata toleransını gerçek mimari, işletme ortamı ve bakım kapasitesiyle ilişkilendirir.

Son Değerlendirme

Kesinti, güvensiz davranış veya kontrol kaybının kabul edilemeyeceği durumlarda hata toleransı zorunludur. Ancak yalnızca yedeklilik güvenilir bir sistem oluşturmaz. Mühendisler arıza türlerini, ortak bağımlılıkları, tanı kapsamını, bozulmuş işletimi, onarım davranışını ve işletme sonuçlarını anlamalıdır.

Hata Ağacı Analizi, arızaların hangi birleşimlerinin kritik bir olaya yol açabileceğini gösterir. FMEA, münferit arıza türlerini ve bunların etkilerini sistematik biçimde inceler. Monte Carlo simülasyonu belirsiz senaryoları değerlendirirken, Kök Neden Analizi gerçek arızaları önleyici bilgiye dönüştürür. Markov modellemesi, onarılabilir sistemlerin sağlıklı, bozulmuş, arızalı ve yeniden devreye alınmış durumlar arasındaki geçişlerini açıklar.

Her yöntemin sınırlamaları vardır; ancak birlikte güçlü bir güvenilirlik çerçevesi sunarlar. Tasarım çalışmaları işletme verileriyle güncellenmeli, olay bulguları gelecekteki modelleri iyileştirmelidir. Sonuçlar mimariyi, bakımı, yedek parçaları, testleri, eğitimi ve prosedürleri etkilemelidir.

Amaç, hiçbir zaman arıza yaşamayan bir sistem oluşturmak değildir. Amaç; arızaları erken tespit etmek, sonuçlarını sınırlandırmak, gerekli işlevi korumak ve tam kapasiteyi öngörülebilir biçimde yeniden sağlamaktır. Endüstriyel hata toleransının pratik anlamı budur.