1. Tanımlar

• MTBF (arızalar arası ortalama süre) = toplam çalışma süresi / çalışma aralığı sayısı. Onarım süresi çalışmaya dahil edilmez.
• MTTR (ortalama onarım süresi) = toplam onarım süresi / arıza sayısı.
• Kullanılabilirlik = MTBF / (MTBF + MTTR). Bu, yalnızca arıza ve onarımı hesaba katan içsel kullanılabilirliktir; planlı bakım ve malzeme bekleme buraya girmez.

2. Örnek

Bir dolum hattının bir çeyrekte 2.000 saat çalıştığını, bu sürede 4 plansız arıza yaşadığını ve onarımların toplam 12 saat sürdüğünü varsayalım.

• MTBF = 2.000 / 4 = 500 saat
• MTTR = 12 / 4 = 3 saat
• Kullanılabilirlik = 500 / (500 + 3) = %99,40

Arıza oranı λ = 1 / MTBF = 0,002 arıza/saat. Sabit arıza oranı varsayımıyla 100 saatlik bir vardiya bloğunu arızasız geçirme olasılığı exp(−100/500) = %81,9; 500 saati arızasız geçirme olasılığı exp(−1) = %36,8. Yani MTBF, "500 saatte bir arıza olur" demek değildir; MTBF kadar sürede arızasız kalma olasılığı yalnızca %36,8'dir.

3. Hangi sayı hangi kararı destekler?

• MTBF düşükse sorun tasarım, kullanım koşulu ya da parça kalitesindedir; önleyici ve kestirimci bakım buraya çalışır.
• MTTR yüksekse sorun organizasyondadır: yedek parça, teşhis süresi, yetkili teknisyene ulaşma. Örnekte MTTR'yi 3 saatten 1,5 saate indirmek kullanılabilirliği %99,40'tan %99,70'e çıkarır. Aynı kazanç, arıza sayısını 4'ten 2'ye indirerek de (MTBF 1.000 saat) elde edilir. İkisi aynı sonucu verir ama biri bakım planına, diğeri yedek parça ve teşhise yatırımdır.
• Seri hatlarda kullanılabilirlik çarpılır: aynı makineden üçü ardışık çalışıyorsa hat kullanılabilirliği 0,9940³ = %98,22. Paralel yedekli iki makinede (biri çalışsa yeter) 1 − (1 − 0,9940)² = %99,996. Bu, bağımsız arıza ve kusursuz geçiş varsayar; gerçekte geçiş süresi vardır.

4. Sık yapılan dört hata

• Onarım süresini çalışma süresine katmak. MTBF şişer, kullanılabilirlik olduğundan iyi görünür.
• Arıza sayısı yerine iş emri sayısını saymak. Bir arızaya üç iş emri açılmış olabilir; MTBF üçte birine düşer.
• Tek bir çeyrekten MTBF türetmek. 4 arızayla hesaplanan 500 saat, bir sonraki çeyrekte 2 arızayla 1.000 saate çıkar; sayı değil, eğilim izlenir. Az arızalı ekipmanda en az 10–12 aylık kayıt gerekir.
• Sabit arıza oranı varsayımını yıpranan parçalara uygulamak. Rulman, kayış ve conta için arıza oranı zamanla artar; orada exp(−t/MTBF) iyimser kalır ve Weibull analizi gerekir.

Kendi kayıtlarınızla deneyin

MTBF / MTTR hesaplayıcı özet sayılarla ya da arıza kaydıyla (başlangıç–bitiş tarih-saatleri) çalışır, veriler tarayıcıda kalır. Arıza kaydınızın yorumlanması için iletişime geçin.

1. Nominal ömür

• L10 = (C / P)^p milyon devir; bilyalı rulmanda p = 3, makaralıda p = 10/3.
• L10h = L10 × 10⁶ / (60 × n) saat; n devir/dakika.

Örnek: dinamik yük sayısı C = 25,5 kN (katalogdan), eşdeğer dinamik yük P = 3,1 kN, devir 1.450 dev/dk, bilyalı rulman.

• C / P = 8,23
• L10 = 8,23³ = 556,6 milyon devir
• L10h = 556,6 × 10⁶ / (60 × 1.450) = 6.398 saat

Aynı C, P ve devirde makaralı rulman (p = 10/3) 12.914 saat verir; üs farkı, makaralı rulmanın ağır yükte neden tercih edildiğini gösterir.

2. Yük küçük değişince ömür çok değişir

Üs 3 olduğu için yükteki %25 artış ömrü yarıya yakın düşürür:

• yük × 0,8 → P = 2,48 kN → L10h = 12.495 saat
• yük × 1,0 → P = 3,10 kN → L10h = 6.398 saat
• yük × 1,25 → P = 3,88 kN → L10h = 3.276 saat

Sahada en sık görülen ömür kaybı buradan gelir: kayış gerginliği, hizasızlık ya da dengesizlik eşdeğer yükü artırır, katalog ömrü değişmemiş görünür ama gerçek ömür yarıya iner. Titreşim ölçümü bu yükü doğrudan görmez; dengesizlik ve hizasızlığı görür, oradan yüke ulaşılır.

3. Güvenilirlik düzeltmesi

%90 yerine %95 güvenilirlik istiyorsanız a1 = 0,64 (ISO 281'de yaygın verilen değer; yayından önce standart ya da katalogdan doğrulanmalı):

• L5mh = 0,64 × 6.398 = 4.094 saat

Aynı rulmandan %95'inin dayanmasını istemek, planlama ömrünü 6.398'den 4.094 saate çeker. Kritik ekipmanda yedek parça ve bakım aralığı bu sayıya göre planlanır, L10'a göre değil.

4. Hedef ömür için gereken rulman

Bu makinede 40.000 saat hedefleniyorsa (%95 güvenilirlikle) gereken dinamik yük sayısı C = 54,5 kN, mevcut rulmanın 2,14 katı. Yani hedef, daha büyük bir rulman ya da daha düşük yük gerektirir; bakım sıklığıyla kapatılamaz.

L10'un cevap vermediği sorular

• Yağlama, kirlenme ve sıcaklık: ISO 281'deki a_ISO (araçta a23) bunları taşır; katalog değeri olmadan 1 alınır ve sonuç iyimserdir.
• Montaj hataları ve elektrik erozyonu: bunlar yorulma değil, hesabın dışındadır; erken arızaların çoğu buradan gelir.
• P/C > 0,5 olan ağır yükler: model bu bölgede güvenilirliğini yitirir, araç uyarı verir.
• Tek bir rulmanın ne zaman arızalanacağı: L10 bir dağılımın alt %10'udur, tek parça için tarih vermez. Tarihe en çok yaklaşan şey titreşim eğilimidir.

Kendi rulmanınızla deneyin

Rulman ömrü L10 hesaplayıcı C, P (ya da Fr, Fa ve X, Y), devir ve güvenilirlikle çalışır; hazır rulman verisi içermez, kataloğunuzdan girersiniz. Titreşim eğilimiyle birlikte yorumlamak için iletişime geçin.

1. Örnek kayıt

Bir aylık plansız duruş süreleri (dakika), neden bazında toplanmış:

• Sensör arızası: 420
• Kalıp değişimi: 310
• Malzeme bekleme: 260
• Konveyör sıkışması: 190
• Etiket yazıcı: 120
• Operatör yok: 90
• Elektrik kesintisi: 60
• Diğer: 50

Toplam 1.500 dakika, yani 25 saat.

2. Pay ve kümülatif pay

• Sensör arızası %28,0 → kümülatif %28,0
• Kalıp değişimi %20,7 → %48,7
• Malzeme bekleme %17,3 → %66,0
• Konveyör sıkışması %12,7 → %78,7
• Etiket yazıcı %8,0 → %86,7
• Operatör yok %6,0 → %92,7
• Elektrik kesintisi %4,0 → %96,7
• Diğer %3,3 → %100

%80 eşiğine ilk ulaşan nokta beşinci neden: "yaşamsal az" 5 neden, 8 nedenin %62,5'i, toplamın %86,7'si. 80/20 değil, yaklaşık 86/63. Bu, verinin yanlış olduğu anlamına gelmez; duruşların nedenlere görece dengeli dağıldığı anlamına gelir. Böyle bir hatta tek bir nedeni düzeltmek toplamı en çok %28 azaltır.

3. Eşik nasıl seçilir?

• %80 yaygın başlangıçtır, ama kaç nedenle uğraşabileceğiniz asıl kısıttır. Bu ay üç iyileştirme kapasiteniz varsa ilk üç neden (%66,0) listenizdir; eşik sonradan gelir.
• İlk iki nedenin arasında büyük fark yoksa (örnekte %28,0 ve %20,7) ikisini birlikte ele almak, birini bitirip diğerine geçmekten çoğu zaman daha kısa sürer, çünkü kök neden ortak olabilir (örnekte sensör arızası ve konveyör sıkışması aynı istasyonda olabilir).
• Süreye göre sıralama ile sıklığa göre sıralama farklı liste verir. 60 dakikalık tek elektrik kesintisi ile her vardiya 5 dakikalık 12 etiket yazıcı duruşu aynı toplamı verir ama farklı çözüm ister. Araç süreyi alır; sıklık için aynı kaydı adetle de çalıştırın.

4. Kayıt kalitesi sonucu bozar

• "Diğer" en büyük dilim çıkıyorsa Pareto yapılmaz; önce neden listesi düzeltilir. "Diğer" %10'u geçmemelidir.
• Aynı nedenin üç yazımı ("sensör", "Sensor arızası", "sensör arızası") üç satır olur ve sıralamada aşağı düşer. Araç büyük/küçük harf ve boşluğu birleştirir; yazım farkını birleştiremez. Neden listesi sabit ve kodlu olmalıdır.
• Kalıp değişimi plansız mı planlı mı? Planlıysa bu listeye girmez, OEE'de planlı duruştur. Aynı kayıtta ikisi karışıksa Pareto da OEE de yanlış çıkar.

Pareto'dan sonra

Pareto neyin büyük olduğunu söyler, neden büyük olduğunu söylemez. İlk neden için kök neden analizi (5 neden ya da balık kılçığı), ikinci için çoğu zaman bir ölçüm (sensör arızası gerçekten sensör mü, kablo mu, PLC girişi mi). Duruşun parasal karşılığı için plansız duruş maliyeti, OEE üzerindeki etkisi için OEE hesaplayıcı araçları var.

Kendi kaydınızla deneyin

Plansız duruş Pareto analizi "neden;süre" satırlarını tarayıcıda işler, eşiği değiştirebilirsiniz; veri hiçbir sunucuya gitmez. Duruş kaydınızın yapısını kurmak için iletişime geçin.

1. Arıza başına maliyet

Formül basittir:

• arıza başına maliyet = duruş süresi × saatlik kayıp + onarım

Örnek bir hat: duruş başına ortalama 8 saat, saatlik üretim kaybı 50.000 TL, arıza başına onarım 150.000 TL.

• Kayıp: 8 × 50.000 = 400.000 TL
• Onarım: 150.000 TL
• Arıza başına toplam: 550.000 TL

Onarım toplamın dörtte birinden azdır (150.000 / 550.000 ≈ %27). Geri kalanı görünmeyen kayıptır.

2. Yıllık maliyet

Yılda 6 plansız duruş olduğunu varsayalım:

• yıllık maliyet = 6 × 550.000 = 3.300.000 TL
• yıllık duruş süresi = 6 × 8 = 48 saat

Bu iki sayı, bakım toplantısında tartışmayı somutlaştıran en kullanışlı çifttir: ne kadar para, kaç saat.

3. Erken uyarı ne kadarını kurtarır?

Her arıza önlenemez. Titreşim, sıcaklık ya da akım verisi bazı arızaları günler önceden gösterir, bazıları ise ani gelir. Hesapta iki dürüst varsayım gerekir:

• önlenebilir pay: arızaların yüzde kaçı erken uyarıyla yakalanabilir (örnekte %25)
• planlı müdahale oranı: yakalanan arızayı planlı durdurmak, plansıza göre yüzde kaç maliyetle sonuçlanır (örnekte %30)

Formül:

• tasarruf = duruş sayısı × önlenebilir pay × arıza başına maliyet × (1 − planlı müdahale oranı)

Örnekte: 6 × 0,25 × 550.000 × 0,70 = 577.500 TL/yıl. Yıllık duruş süresi de 48 saatten 36 saate düşer (48 × 0,25 = 12 saat azalır).

4. Yatırımın geri dönüşü

Sistem yatırımı 1.200.000 TL ise geri dönüş süresi: 1.200.000 / 577.500 × 12 ≈ 24,9 ay, yani yaklaşık iki yıl. Önlenebilir payı değiştirmek sonucu nasıl oynatıyor?

• %10 → yıllık tasarruf 231.000 TL
• %20 → 462.000 TL
• %30 → 693.000 TL
• %40 → 924.000 TL

Tasarruf önlenebilir payla doğru orantılıdır; dolayısıyla en çok tartışılması gereken varsayım odur. Geçmiş arıza kayıtlarınızdan "bu arıza önceden belirti veriyor muydu" sorusuyla sınıflandırma yapmak, bu sayıyı tahminden ölçüme çevirir.

Sık yapılan dört hata

• Onarım faturasını duruş maliyeti saymak; kayıp saati hesaba katmamak.
• Saatlik kaybı brüt ciro ile mi katkı payı ile mi hesapladığınızı yazmamak. Durma sırasında harcanmayan hammadde ve enerji kaybı küçültür; hangisini kullandığınız açık olmalı.
• Önlenebilir payı %100'e yakın varsaymak. Gerçekçi başlangıç değerleri düşüktür ve veri biriktikçe yükselir.
• Tek senaryoyla karar vermek. Yukarıdaki duyarlılık tablosu gibi dört değerle bakmak, kararı varsayıma değil aralığa bağlar.

Kendi sayılarınızla deneyin

Plansız duruş maliyeti aracı tarayıcıda çalışır, girdiğiniz değerler hiçbir sunucuya gönderilmez. Örnekteki varsayılanlar yalnızca örnektir; kendi hattınızın sayılarını girin. Kestirimci bakım pilotu için iletişime geçin.

AB'de MDR (2017/745), Türkiye'de onunla uyumlu Tıbbi Cihaz Yönetmeliği bu yapıyı esas alır; Türkiye'de cihazlar Ürün Takip Sistemi'ne (ÜTS) kaydedilir. Aşağıdaki hatalar, etiket tasarımı ve ana veri aşamasında en sık karşılaştıklarımızdır.

Bu yazı bir yazılım ekibinin bakış açısını özetler; regülasyon danışmanlığı değildir. Kesin gereklilikler için yürürlükteki mevzuatı ve onaylanmış kuruluşunuzu esas alın.

1. Bütün ambalaj seviyelerinde aynı UDI-DI

Tekli ürün, iç kutu ve satış kolisi farklı ambalaj seviyeleridir ve her biri kendi UDI-DI'sini taşır. Aynı GTIN'in hem tekli ürüne hem 10'lu kutuya basılması, bir okutmanın kaç cihaza karşılık geldiğini belirsiz bırakır. Lojistik amaçlı nakliye kapları bu kuralın dışındadır; onlar için SSCC kullanılır.

Önlem: ana veride ürünü ve ambalaj seviyelerini ayrı kayıtlar olarak tutun; her seviyenin içerdiği adet ve bir alt seviyenin GTIN'i tanımlı olsun.

2. Değişiklikte yeni UDI-DI alınmaması

MDR, cihazın yanlış tanınmasına yol açabilecek değişikliklerde yeni bir UDI-DI ister. Ad ya da ticari ad, model veya sürüm, tek kullanımlık olma, steril ambalaj, kullanım öncesi sterilizasyon gereği, ambalajdaki adet ve lateks ya da DEHP içermesi gibi kritik uyarılar bunlar arasındadır. Ambalaj adedini 10'dan 12'ye çıkarıp aynı GTIN'le devam etmek sık görülen bir hatadır.

Önlem: ürün değişiklik sürecine "UDI-DI etkileniyor mu?" sorusunu zorunlu bir adım olarak ekleyin.

3. Basic UDI-DI ile UDI-DI'nin karıştırılması

Basic UDI-DI; amaçlanan kullanımı, risk sınıfı ve temel tasarımı aynı olan cihaz grubunu tanımlar. EUDAMED'de, uygunluk beyanında ve sertifikalarda geçer, ama etikete basılmaz; etikette yer alan UDI-DI'dir. İkisini aynı alanda tutan bir ana veri, kayıt ile etiket arasında tutarsızlık üretir.

4. Üretim tanımlayıcısının izleme yöntemiyle uyuşmaması

UDI-PI, üreticinin cihazı nasıl izlediğini yansıtır: partiyle izlenen cihazda (10), seriyle izlenende (21), son kullanma tarihi olanda (17) bulunmalıdır. Etikette son kullanma tarihi yazılıyken karekodda (17) alanının olmaması ya da seri numarasıyla izlenen bir cihazda yalnızca partinin kodlanması UDI'yi eksik bırakır.

5. İnsan okunur metin ile barkod içeriğinin farklı olması

UDI etikette hem makinece okunur biçimde (barkod) hem insan okunur biçimde (HRI) bulunur. İkisi ayrı şablon alanlarından beslendiğinde biri güncellenip diğeri unutulabilir. HRI, barkodun içeriğinden üretilmelidir; GS1'de alanlar parantezli tanımlayıcılarla yazılır: (01)…(17)…(10)….

6. Baskı kalitesinin ölçülmemesi

Küçük cihazlarda etiket alanı dardır ve sembol küçültülür. Barkodun okunuyor olması yeterli değildir; kalite derecesi iki boyutlu semboller için ISO/IEC 15415, doğrusal barkodlar için ISO/IEC 15416 ile ölçülür. Bir doğrulama cihazıyla periyodik ölçüm, sahada okunamayan etiket riskini azaltır.

Hızlı kontrol

Bir etiketin barkod içeriğini GS1 karekod çözümleyici ile alanlarına ayırabilir, UDI için gereken ürün kimliği ve üretim tanımlayıcısının varlığını denetleyebilirsiniz. GTIN'lerin kontrol hanesini toplu olarak kontrol hanesi hesaplayıcı ile doğrulayabilirsiniz. Etiketleme ve ÜTS entegrasyonunu birlikte ele almak isterseniz bize yazın.

Aşağıdaki durumlar ilişkinin en sık bozulduğu anlardır. Hepsinin ortak noktası, hattaki fiziksel bir olayın yazılıma bildirilmemesidir.

1. Reddedilen kutunun ilişkide kalması

Kamera bir kutuyu reddeder ve kutu hattan atılır; ama kutu koliye atanmışsa ya da red bilgisi agregasyon istasyonuna ulaşmamışsa kayıtta kalır. Tersi de olur: red sonrası elle hatta geri konan kutu hiçbir koliye atanmaz.

Önlem: red kararı ile fiziksel atma tek bir olay olarak kaydedilsin; agregasyon istasyonu yalnızca doğrulamadan geçmiş seri numaralarını kabul etsin.

2. Kısmi koli

Parti sonunda koli dolmaz. Kısmi koli yazılımda ayrıca kapatılmazsa sistem bir sonraki partinin kutularını aynı koliye eklemeye çalışabilir ve partiler karışır.

Önlem: parti kapanışı kısmi koliyi zorunlu olarak kapatsın; koli kaydında gerçek adet tutulsun ve etikette yazsın.

3. Numune alma

Kalite kontrol için hattan ya da koliden alınan numuneler fiziksel olarak ilişkiden çıkar. Kayıtta kalırlarsa koli sevk edildiğinde alıcı, içinde olmayan ürünleri bekler.

Önlem: numune alımı bir istasyonda okutularak yapılsın; kutunun durumu "numune" olarak güncellensin ve kutu ilişkiden düşsün.

4. Elle müdahale

Sıkışma, hasarlı kutu ya da hat duruşu sonrasında operatörün kutuları elle yer değiştirmesi en sık sapma kaynağıdır. Sistem dışında yapılan her hareket kaydı geçersiz kılar.

Önlem: bir yeniden işleme (rework) istasyonu kurun; koliyi açmak, kutu çıkarmak ve eklemek okutmayla yapılsın, her işlem kullanıcı ve zamanla denetim izine yazılsın.

5. Aynı kutunun iki koliye atanması

Hızlı hatlarda aynı kutunun iki kez okunması ya da yeniden işleme sırasında eski ilişkinin kaldırılmaması, bir seri numarasının iki ebeveyne bağlanmasına yol açar.

Önlem: yazılım "her çocuğun tek ebeveyni olur" kuralını veritabanı düzeyinde uygulasın; ikinci atama reddedilsin ve uyarı versin.

6. Palet bozma ve yeniden paletleme

Depoda bir palet bölünüp kolileri başka paletlere dağıtıldığında palet kaydı güncellenmezse sevkiyat bildirimi eski içeriği gösterir.

Önlem: palet bozma ve yeni palet oluşturma da okutmayla yapılsın; yeni palete yeni bir SSCC verilsin, eski SSCC yeniden kullanılmasın.

Etiket en son basılmalı

Koli etiketi içerik kesinleşmeden basılırsa etiket ile içerik arasında boşluk açılır. İyi bir akışta koli dolar, içerik doğrulanır, sonra koli etiketi basılır ve okutularak kayıtla eşleştirilir. SSCC'lerin kontrol hanesini kontrol hanesi hesaplayıcı ile, hattın genel hazırlığını serileştirme hazırlık kontrol listesi ile gözden geçirebilirsiniz. Mevcut hattınızdaki agregasyon akışını birlikte incelemek isterseniz bize yazın.

Aşağıdaki kontroller, rüzgar santrali ve döner ekipman verisinde her projenin başında yaptıklarımızdır.

1. Zaman damgası

İlk soru, damganın hangi saat dilimine ait olduğu ve ortalama aralığının başını mı sonunu mu gösterdiğidir. Yerel saatle tutulan verilerde yaz saati geçişinde bir saat iki kez görünür ya da hiç görünmez. Farklı sistemlerden gelen veriler (SCADA, alarm kaydı, bakım iş emirleri) birleştirilmeden önce hepsi UTC'ye çevrilmelidir.

2. Boşluklar

İletişim kesintisi veriyi siler; bazı sistemler boşluğu sıfırla ya da son değerle doldurur. Sıfırla doldurulmuş bir güç kaydı, model için "türbin üretmedi" demektir. Boşluk boşluk olarak bırakılmalı ve kapsama oranı kanal bazında raporlanmalıdır.

3. Donmuş değerler

Arızalı ya da bağlantısı kopmuş bir sensör saatlerce aynı değeri tekrar edebilir. Belirli bir süre boyunca hiç değişmeyen değerler işaretlenmelidir. Bu kontrol özellikle sıcaklık ve titreşim kanallarında önemlidir: donmuş bir sıcaklık, gerçek bir ısınmayı gizler.

4. Fiziksel sınır dışı değerler

Negatif rüzgar hızı, 360 dereceyi aşan yön, nominal gücün çok üstünde üretim ya da ortam sıcaklığının altında kalan bir yatak sıcaklığı veri hatasıdır. Her kanal için fiziksel alt ve üst sınırlar tanımlanmalı, aşan kayıtlar işaretlenmelidir.

5. Kısıtlama, bakım ve arıza dönemleri

Normal davranış modeli, makinenin sağlıklı ve serbestçe çalıştığı dönemlerden öğrenmelidir. Şebeke kısıtlaması, planlı bakım, buzlanma ve arıza duruşları eğitim verisinde kalırsa model bu durumları "normal" kabul eder ve gerçek bir sapmayı kaçırır. Bu dönemler durum kodlarından ve alarm kayıtlarından çıkarılıp işaretlenmelidir.

6. Sensör değişimi ve seviye kayması

Bir sensör değiştirildiğinde ya da yeniden kalibre edildiğinde ölçüm seviyesi aniden kayabilir; model bunu bozulma sanar. Bakım kayıtlarıyla açıklanamayan ani seviye değişimleri ayrıca incelenmelidir.

Silmek yerine işaretlemek

Sorunlu kayıtları silmek yerine her kayda neden sorunlu olduğunu gösteren bir işaret eklemek iki fayda sağlar: eğitim için temiz pencereler seçilebilir ve kayıp hesabında verinin hangi kısmının değerlendirilemediği açıkça raporlanır. Açık bir rüzgar santrali verisiyle yaptığımız üretim tahmini ve kayıp çalışmasını vaka çalışmamızda, etiketli arıza verisi olmadan nasıl ilerlenebileceğini bu notta anlattık. Bu denetimlerin çoğunu kendi CSV dosyanızda, dosyayı yüklemeden SCADA veri kalitesi denetimi aracımızla yapabilirsiniz. Kendi verinizle bir ön değerlendirme için bize yazın.

1. Okuyucu ne döndürüyor?

Çoğu okuyucu çözdüğü içeriği düz metin olarak klavye gibi yazar. Bu metinde iki şeye dikkat edin. Birincisi, bazı okuyucular içeriğin önüne sembol tanımlayıcı ekler: GS1 DataMatrix için ]d2, GS1-128 için ]C1. Bu önek veri değildir, ayrıştırmadan önce atılmalıdır. İkincisi, alanları ayıran FNC1 karakteri (ASCII 29, "GS") ekranda görünmez; bazı okuyucular onu hiç iletmez, bazıları başka bir karakterle değiştirir. Okuyucu ayarında bu davranışı bilmeden ayrıştırma yazılımı kurulmamalıdır.

2. Ham metni alanlara ayırın

Örnek bir içerik: 0109504000059118 17271231 10LOT42 [GS] 21A1B2C3 (okunaklı olsun diye boşluklarla yazıldı; gerçekte bitişiktir). Ayrıştırma, her alanın başındaki uygulama tanımlayıcısına (AI) bakarak yapılır:

• (01) GTIN: sabit 14 hane
• (17) son kullanma tarihi: sabit 6 hane, YYAAGG
• (10) parti: değişken uzunluk, en çok 20 karakter
• (21) seri numarası: değişken uzunluk, en çok 20 karakter

Sabit uzunluklu alanların ardından ayraç gerekmez; değişken uzunluklu bir alan, sonda değilse ayraçla biter. Yukarıdaki örnekte parti (10) sonda olmadığı için ardından GS gelir, seri numarası (21) sondadır.

3. GTIN kontrol hanesini elle hesaplayın

14 haneli GTIN 09504000059118'in son hanesi (8) kontrol hanesidir. Hesap: ilk 13 haneyi sağdan sola sırayla 3 ve 1 ile çarpın (en sağdaki 3), toplayın, toplamı bir üst onluğa tamamlayan sayı kontrol hanesidir. Örnekte toplam 72, bir üst onluk 80, fark 8: kod doğru. Hane 7 olsaydı sembol yine okunurdu, ama GTIN geçersiz olurdu.

4. Tarihi ve ayraçları denetleyin

• (17) altındaki ay 01-12 arasında olmalı. Gün 00 ise "ayın son günü" demektir; sisteminiz bunu ayrıca ele alıyor mu?
• Örnekteki 271231, 31 Aralık 2027'dir. Aynı haneler GG.AA.YY alışkanlığıyla yazılmış olsaydı geçerli ama yanlış bir tarih çıkardı.
• Değişken alandan sonra ayraç yoksa tarih ve parti, seri numarasının içine karışır. Alan uzunluğu 20'yi geçiyorsa ya da seri numarasında beklenmedik bir "17" dizisi varsa bu belirtidir.

5. Okunabilirlik ile doğruluğu ayırın

Sembolün baskı kalitesi (kontrast, modül boyutu, sessiz bölge) bir sorundur; verinin doğruluğu başka bir sorundur. İkisi ayrı sınanır. Baskı kalitesi için doğrulayıcı cihaz gerekir; veri için yukarıdaki adımlar yeterlidir ve yazılımla her kutu için otomatikleştirilebilir.

Araçla deneyin

İçeriği GS1 karekod çözümleyici aracına yapıştırın: alanları ayırır, kontrol hanesini ve tarihi doğrular. Kontrol hanesini tek başına hesaplamak için kontrol hanesi hesaplayıcı, alan tanımları için uygulama tanımlayıcıları sözlüğü var. Hatta en sık görülen hatalar ayrı bir yazıda: İlaç karekodunda sık yapılan beş hata. Hattınızdaki doğrulamayı kurmak için bize yazın.

Üç çarpan

OEE = kullanılabilirlik × performans × kalite.

• Kullanılabilirlik = çalışma süresi / planlı üretim süresi
• Performans = (ideal çevrim süresi × üretilen adet) / çalışma süresi
• Kalite = iyi adet / üretilen toplam adet

Örnek

Vardiya 480 dakika, 30 dakika planlı mola. Planlı üretim süresi 450 dakika. Plansız duruşlar toplam 45 dakika; çalışma süresi 405 dakika. İdeal çevrim süresi 0,5 dakika (30 saniye) olan parçadan 700 adet çıkmış, 21'i fire; 679 iyi.

• Kullanılabilirlik: 405 / 450 = %90,0
• Performans: 0,5 × 700 / 405 = %86,4
• Kalite: 679 / 700 = %97,0
• OEE: 0,900 × 0,864 × 0,970 = %75,4

Kayıpların büyüğü performansta (yaklaşık %13,6) görünüyor; bu, makinenin çalışırken yavaş ya da kısa duruşlarla gittiği anlamına gelir. Yalnızca duruş kayıtlarına bakan biri bunu kaçırır.

Sık yapılan altı hata

• **Planlı molaları kayıp saymak.** Kullanılabilirlik, planlı üretim süresi üzerinden hesaplanır. Takvim süresini (24 saat) paydaya koyan hesap başka bir göstergedir (TEEP); ikisini karıştırmayın.
• **İdeal çevrim yerine hedef çevrim kullanmak.** İdeal çevrim, makinenin tasarım ya da kanıtlanmış en iyi hızıdır. Bugünkü ortalama hızı "ideal" yazarsanız performans hep %100'e yakın çıkar ve kayıp görünmez olur.
• **Yeniden işlenen parçayı iyi saymak.** İlk geçişte uygun çıkmayan parça, sonradan kurtarılsa da kalite kaybıdır.
• **Kısa duruşları yazmamak.** Bir dakikanın altındaki duruşlar elle tutulan kayıtta genelde unutulur; kaybı performansa, yani yanlış yere iter. Duruş eşiğini baştan belirleyin.
• **OEE'lerin ortalamasını almak.** Üç makinenin OEE'sini toplayıp üçe bölmek, üretim sürelerini yok sayar. Önce süreleri ve adetleri toplayın, sonra oranları hesaplayın.
• **%100'ü aşan performansı gömmek.** Performans 100'ün üstüne çıkıyorsa ideal çevrim yanlış tanımlanmıştır; sonucu kırpmak yerine nedenini bulun.

Rakamın ardından

OEE bir teşhis değil, bir başlangıç noktasıdır. Kayıp hangi çarpandaysa orada derinleşin: duruşta neden dağılımına (Pareto), performansta çevrim süresi dağılımına, kalitede fire nedenlerine. Bir hat için tek bir OEE yerine kayıp şelalesi okumak daha çok yol gösterir.

Kendi vardiya rakamlarınızı OEE hesaplayıcı aracına girerek yukarıdaki dökümü tarayıcınızda görebilirsiniz; duruş nedenlerini sıralamak için plansız duruş Pareto analizi, duruşun parasal karşılığı için plansız duruş maliyeti araçları var. Hattınızda OEE ölçümünü kurmak için iletişime geçin.

Kontrol sınırları nereden gelir?

Bireysel ölçümler için I-MR grafiğinde sınırlar sürecin kendi verisinden hesaplanır. Ardışık iki ölçüm arasındaki mutlak fark hareketli aralıktır (MR); ortalaması MR̄ olsun. Merkez çizgisi ortalama, sınırlar ortalama ± 2,66 × MR̄'dır (2,66 = 3 / 1,128). Standart sapma tahmini MR̄ / 1,128'dir.

Örnek: on ölçüm: 10,02 · 10,05 · 9,98 · 10,03 · 10,01 · 10,04 · 9,99 · 10,02 · 10,06 · 10,00. Ortalama 10,020; MR̄ = 0,0422 (toplam fark 0,38 bölü 9). Sınırlar 10,020 ± 2,66 × 0,0422: üst 10,132, alt 9,908. Sigma tahmini 0,0422 / 1,128 = 0,0374. (On nokta yalnızca yöntemi göstermek içindir; gerçek sınır hesabı için en az 20-25 kararlı ölçüm gerekir.)

Alarm ne zaman verir?

Kural 1: bir nokta 3 sigma sınırının dışına çıkar. Normal dağılımda süreç kararlıyken bile bir noktanın bu sınırı aşma olasılığı yaklaşık %0,27'dir; yani ortalama her 370 ölçümde bir yanlış alarm beklenir. Küçük kaymaları yakalamak için Nelson kuralları desenlere de bakar:

• Art arda 9 nokta merkezin aynı tarafında: ortalama kaymıştır.
• Art arda 6 nokta sürekli artıyor ya da azalıyor: trend vardır, çoğu zaman aşınma.
• Art arda 14 nokta yukarı-aşağı sırayla: iki kaynak karışıyor olabilir.
• 3 noktadan 2'si aynı tarafta 2 sigma dışında: erken kayma işareti.

Kural sayısı arttıkça yakalama hızlanır ama yanlış alarm da artar; hepsini her sürece uygulamak zorunda değilsiniz.

Kontrol sınırı şartname sınırı değildir

Kontrol sınırları sürecin ne yaptığını, şartname sınırları müşterinin ne istediğini anlatır. Aynı örnekte alt şartname sınırı 9,90, üst şartname sınırı 10,10 olsun. Cp = (10,10 − 9,90) / (6 × 0,0374) = 0,89; Cpk = min(10,10 − 10,02; 10,02 − 9,90) / (3 × 0,0374) = 0,08 / 0,1123 = 0,71. On ölçümün hepsi şartname içinde olsa da süreç, ortalaması üst sınıra yakın ve yayılımı geniş olduğu için yeterli değildir; normal dağılım varsayımıyla tahmini hata oranı yaklaşık %1,7'dir. Cp yayılımı, Cpk yayılımı ve ortalamanın ortadan kayıklığını birlikte yansıtır.

Sık hatalar

• **Şartname sınırını kontrol grafiğine çizmek.** Sürecin doğal davranışına değil, istenene bakar; kontrol sınırı ayrı hesaplanmalıdır.
• **Kararsız sürecte Cpk hesaplamak.** Önce kontrol altına alın; yoksa Cpk'nın anlamı yoktur.
• **Veriyi zaman sırasına koymamak.** Hareketli aralık sıraya bağlıdır; karıştırılmış veri sınırları bozar.
• **Her alarmda sınırları yeniden hesaplamak.** Sınırlar kararlı bir dönemden bulunur; bir kayma varsa neden araştırılır, sınır oynatılmaz.
• **Cpk hedefini körlemesine kopyalamak.** Kabul edilen düzey müşteriye, sektöre ve sözleşmeye göre değişir.
• **Normal dağılım varsaymak.** Tek taraflı ya da çarpık veride ppm tahmini yanıltabilir.

Araçlarla deneyin

Kendi ölçümlerinizi kontrol grafiği (SPC) aracına yapıştırın: I ve MR grafiği, sınırlar ve ihlal edilen Nelson kuralları çıkar. Şartname sınırlarınızla Cp, Cpk, Pp, Ppk ve ppm tahmini için Cp / Cpk yeterlilik hesaplayıcı var. Sürecinizde kalite izlemeyi kurmak için bize yazın.

1. Seri numarasından sonra ayraç unutulması

GS1 karekodunda GTIN (01) ve son kullanma tarihi (17) sabit uzunluktadır; seri numarası (21) ve parti (10) ise değişken uzunluktadır. Değişken bir alan sonda değilse ardından bir ayraç (FNC1, ASCII 29) gelmelidir. Ayraç unutulursa okuyucu, seri numarasından sonra gelen tarih ve parti bilgisini de seri numarasının parçası sanar. Kod basılır ve okunur, ama yanlış okunur.

Önlem: yazıcı şablonunda alan sırasını sabitleyin; doğrulama kamerası basılan içeriği alan alan ayrıştırmalı, yalnızca "okundu / okunmadı" bilgisine bakmamalı.

2. Kontrol hanesi hatalı GTIN

GTIN'in son hanesi, diğer hanelerden hesaplanan bir kontrol hanesidir. Ana veriye elle girilen ya da 13 haneden 14 haneye yanlış dönüştürülen bir GTIN, hattaki her kutuya hatalı basılır. Hata sembolde değil veride başladığı için kamera "okundu" der, ama kod geçersizdir.

Önlem: GTIN ana veriye girilirken ve iş emri açılırken kontrol hanesi yazılım tarafından doğrulanmalı.

3. Tarih biçimi karışıklığı

Son kullanma tarihi YYAAGG biçimindedir: yıl, ay, gün. GG.AA.YY alışkanlığıyla girilen bir tarih sembolde geçerli ama yanlış bir tarihe dönüşebilir. Gün "00" ise ayın son günü anlamına gelir; bunu ayrıca ele almayan sistemler arasında tutarsızlık çıkar.

Önlem: tarih iş emrinden otomatik gelsin, operatör elle yazmasın; basılan tarih okunup iş emriyle karşılaştırılsın.

4. Mükerrer seri numarası

Aynı seri numarasının iki kutuya basılması çoğunlukla hat yeniden başlatıldığında ya da iki hat aynı numara havuzunu paylaştığında olur. Mükerrer kod bildirimde sorun çıkarır ve sahadaki ürünün izlenebilirliğini bozar.

Önlem: seri numaraları merkezi, çakışma önleyici bir üreticiden gelsin; basılan ve reddedilen numaralar kalıcı olarak kayda geçsin, yeniden kullanılmasın.

5. Karakter kümesi dışında karakter

GS1'in alfasayısal alanları sınırlı bir karakter kümesi kullanır: Türkçe harfler (ş, ğ, ı…) ve boşluk bu kümede yoktur. Parti numarasındaki bir "Ş" ya da boşluk GS1 kurallarına aykırıdır; okuyucuya ve sisteme göre kod reddedilir ya da yanlış okunur.

Önlem: parti ve seri numarası biçimini ana veride kural olarak tanımlayın ve iş emri açılırken denetleyin.

Hızlı kontrol

Hattan aldığınız bir kodun içeriğini GS1 karekod çözümleyici ile tarayıcınızda denetleyebilirsiniz: araç alanları ayırır, kontrol hanesini ve tarihi doğrular, İTS için gerekli dört alanın varlığına bakar. Kalıcı çözüm ise bu denetimlerin hattın kendisinde, her kutu için yapılmasıdır.

Önce normali öğrenin

İlk adım arızayı değil, makinenin normal davranışını modellemektir. Titreşim, sıcaklık, akım ve SCADA/PLC kayıtlarından 4–8 haftalık bir dönem, makinenin farklı yük ve ortam koşullarında nasıl davrandığını gösterir. Isolation Forest ya da otokodlayıcı gibi etiketsiz yöntemler bu "normal zarfı" öğrenir; yeni ölçümler zarftan uzaklaştıkça sağlık skoru düşer.

Burada en çok zaman alan iş model değil, veridir: duruş dönemlerini ayırmak, sensör kopukluklarını onarmak, aynı makinenin farklı çalışma modlarını (boşta, kısmi yük, tam yük) birbirinden ayırmak.

Alarmı anlamlı kılın

Sağlık skoru tek başına bakım ekibine bir şey söylemez. Sapmanın hangi sinyalde ve hangi frekansta başladığı, fiziksel bir arıza sınıfına işaret eder: yatak, dişli, hizalama, dengesizlik ya da elektriksel. Bu sınıflandırma alarmı "makine 7 anormal" yerine "makine 7, olası yatak hasarı" bilgisine dönüştürür ve doğru ekibin doğru parçayla gitmesini sağlar.

Etiketleri süreç içinde toplayın

Her alarm bir teknisyen bulgusuyla kapanmalı: gerçekten bir sorun var mıydı, neydi? Bu bulgular modele geri yazıldığında sistem birkaç ay içinde kendi etiketli verisini üretir. Etiket bir başlangıç koşulu değil, sürecin çıktısı olur.

Belirsizliği gösterin

Kalan ömür ya da üretim tahmini tek bir sayı olarak verildiğinde ya fazla güven ya da güvensizlik yaratır. Konformal tahmin aralığı gibi yöntemler her tahminin yanına, gerçekleşen değerin belirli bir olasılıkla düşeceği aralığı koyar. Bakım planlayıcısı böylece "en erken" ve "en geç" senaryoları birlikte görür.

Küçük başlayın, ölçün

İlk pilot için tek bir hat ya da bir grup benzer makine yeterlidir. Ölçülmesi gereken iki şey vardır: alarmların teknisyen bulgularıyla ne kadar örtüştüğü ve planlanmamış duruşun nasıl değiştiği. Yaklaşımımızı açık bir rüzgar santrali veri kümesiyle nasıl sınadığımızı, tahmin hatası ve aralık kapsamasıyla birlikte vaka sayfasında paylaştık.

Bir pilotun size neler kazandırabileceğini kabaca görmek için plansız duruş maliyeti hesaplayıcı ile yıllık duruş maliyetinizi ve olası tasarrufu hesaplayabilir, verinizin modele hazır olup olmadığını SCADA veri kalitesi denetimi ile görebilirsiniz.

Bu yazı bir yazılım ekibinin bakış açısını özetler; hukuki ya da regülasyon danışmanlığı değildir. Bir sistemin uygunluğu, işletmenin kendi validasyon süreci içinde değerlendirilir.

Denetim izi neyi kaydetmeli?

Part 11'in 11.10(e) maddesi, elektronik kaydı oluşturan, değiştiren ya da silen operatör işlemlerinin tarih ve saatini bağımsız olarak kaydeden; güvenli, bilgisayar tarafından üretilen ve zaman damgalı denetim izleri ister. Pratikte her olay için şunlar tutulur:

• kim: benzersiz kullanıcı kimliği
• ne zaman: sunucu saatiyle, saat dilimi belirtilerek
• ne yaptı: oluşturma, değiştirme ya da silme
• hangi kayıtta, hangi alanda
• eski değer ve yeni değer
• değişikliğin gerekçesi (GMP süreçlerinde, örneğin AB GMP Ek 11'de beklenir)

Önceki bilgi örtülmemeli

Aynı madde, kayıt değişikliklerinin önceden kaydedilmiş bilgiyi gizlememesini ister. Bu, tasarımda iki karara dönüşür: kayıtlar fiziksel olarak silinmez, "silindi" olarak işaretlenir (soft-delete); değişiklikler üzerine yazılmaz, yeni sürüm olarak eklenir. Denetim izinin kendisi de değiştirilemez olmalıdır: uygulama kullanıcısı, yönetici dahil, denetim kaydını düzenleyememelidir.

Saklama ve erişim

Denetim izi en az ilgili elektronik kayıt kadar saklanmalı ve denetimde incelenip kopyalanabilir olmalıdır. Bu yüzden denetim kayıtlarını ana veriyle aynı yedekleme ve arşiv politikasına bağlamak, okunabilir bir dışa aktarım (PDF ya da CSV) sağlamak gerekir.

Erişim denetimi ve elektronik imza

Kimlik doğrulaması zayıf bir sistemde denetim izi anlamını yitirir. Part 11; sisteme erişimin yetkili kişilerle sınırlanmasını (11.10(d)), elektronik imzada imzalayanın adı, tarih-saat ve imzanın anlamının ("onaylayan", "inceleyen" gibi) görünmesini (11.50) ve imzanın kayda bağlanmasını (11.70) ister. Her elektronik imza tek bir kişiye ait olmalıdır (11.100); paylaşılan hesaplar bu yüzden kabul edilmez.

Yazılım tarafı için kontrol listesi

• Her kullanıcıya benzersiz hesap, rol tabanlı yetki
• Sunucu tarafında üretilen, uygulama içinden değiştirilemeyen denetim kaydı
• Eski ve yeni değer, gerekçe alanı
• Soft-delete ve kayıt sürümleme
• Elektronik imzada ad, tarih-saat ve anlam
• Denetim izinin kayıtla birlikte yedeklenmesi ve dışa aktarılabilmesi
• Validasyon belgeleri için izlenebilir gereksinim–test eşlemesi

Serileştirme ve laboratuvar yazılımlarımızda bu yapıyı baştan tasarıma dahil ediyoruz. Mevcut bir sistemin denetim izini birlikte gözden geçirmek isterseniz bize yazın.

Standartlar ne yapar?

ISO 10816 serisinin yerini ISO 20816 serisi almıştır. Dönen makinelerde, yapılardan ölçülen geniş bantlı titreşim şiddetini (çoğunlukla hız, RMS) makine tipine, güce ve temel sertliğine göre dört bölgeye ayırır: A yeni devreye alınmış makine düzeyi, B uzun süreli çalışmaya uygun, C sınırlı süreli çalışma, D hasar riski. Bölge sınırları makine grubuna göre değişir; bu yüzden tek bir "güvenli mm/s" sayısı yoktur. Tabloyu standarttan okuyun, tahmin etmeyin.

Standart yetmez: taban çizgisi ve eğilim

Bölge değerlendirmesi mutlak seviyeye bakar. Erken uyarı içinse çoğunlukla göreli değişim daha değerlidir: aynı makine, aynı ölçüm noktası, aynı çalışma koşulunda sağlıklıyken ölçülen seviye taban çizgisidir. Taban çizgisine göre belirgin bir artış, makine hâlâ B bölgesindeyken bile bir şeyin değiştiğini gösterir. Alarm eşiklerini bu iki ölçütle birlikte kurun: standart bölgesi (mutlak sınır) ve taban çizgisinin katı ya da eğim (göreli sınır). Kat sayılarını makinenize ve tecrübenize göre belirleyin; "örnek" bir çarpan standart değildir.

Birimler: ivme, hız, yer değiştirme

Aynı titreşim üç birimle anlatılır ve frekansa göre birbirine dönüşür. Sinüs için tepe hız = tepe ivme / (2πf). Örnek: 100 Hz'de 0,5 g'lik tepe ivme (0,5 × 9,81 = 4,905 m/s²) için tepe hız 4,905 / 628,3 = 7,81 mm/s, RMS hız ise bunun √2'ye bölümüyle 5,52 mm/s'dir. Gerçek sinyal tek frekanslı olmadığı için bu dönüşüm yalnızca tek bileşen için doğrudur; geniş bantta hız, sinyalin hız olarak ölçülmesi ya da tümlevlenmesiyle bulunur.

Alarm kurarken sık hatalar

• **Ölçüm noktasını ve yönü değiştirmek.** Algılayıcıyı başka yere takmak seviyeyi değiştirir. Noktaları işaretleyin, aynı yön ve montaj yöntemini koruyun.
• **Çalışma koşulunu ihmal etmek.** Yük ve devir değişince titreşim de değişir; verileri benzer koşullara göre karşılaştırın.
• **Tek ölçümle alarm vermek.** Anlık bir sıçrama (darbe, ölçüm hatası) yanlış alarm üretir. Birkaç ardışık ölçümde sürmesini şart koşun.
• **Yalnızca genel seviyeye bakmak.** Rulman hasarı erken evrede genel seviyeyi neredeyse hiç oynatmaz; yüksek frekans bandı ya da spektrum ayrıntısı gerekir. Spektrum için ölçüm ayarlarına (örnekleme, pencere, çözünürlük) dikkat edin.
• **Alarm sonrası eylem tanımlamamak.** "Alarm" ne yaptırıyor? Kontrol, yağlama, yeniden ölçüm, planlı duruş: her eşik için eylemi önceden yazın.

Araçlarla deneyin

Ölçtüğünüz hız değerini titreşim şiddeti değerlendirici aracında makine grubuna göre bölgeye yerleştirebilir, taban çizginizle karşılaştırabilirsiniz; araçtaki sınırlar örnek amaçlıdır, bağlayıcı olan standart ve üretici belgesidir. Birim dönüşümü için titreşim birim dönüştürücü, spektrum ayarı için FFT ölçüm ayarı var. Etiketli arıza verisi olmadan nasıl ilerleneceğini bu notta anlattık. Titreşim izleme kurulumu için bize yazın.

1. Önce kayıt aralığını bilin

Kapsam (coverage) hesabının tek girdisi beklenen kayıt sayısıdır, o da kayıt aralığından gelir. 10 dakikalık ortalamalarda bir günde 144 kayıt beklenir; 30 günde 4.320. Dosyada 4.104 satır varsa kapsam 4.104 / 4.320 = %95,0'tır, yani 216 kayıt (yaklaşık 36 saat) eksiktir. Aralığın yanlış varsayılması kapsamı baştan bozar: veriyi saatlik sanıp 10 dakikalık okursanız yüzde yüz "eksik" çıkar.

2. Boşluk: ne kadar uzun sorun olur?

Tek bir eksik kayıt çoğu analizde önemsizdir; uzun kesinti ise önemlidir. Eşiği kayıt aralığının katı olarak düşünün: örneğin 10 dakikalık veride iki ardışık kaydın arası aralığın 1,5 katından büyükse boşluk sayılabilir, ama "sorunlu boşluk" için daha uzun bir eşik (örneğin birkaç saat) seçilebilir. Eşiği kullanım amacınıza göre belirleyin: anlık alarm için kısa, günlük enerji hesabı için daha uzun bir boşluk kabul edilebilir. Boşluğu hiçbir zaman sıfırla ya da son değerle doldurmayın.

3. Donmuş değer: pencere uzunluğu

Donmuş değer, ardışık N kayıtta değerin birebir aynı kalmasıdır. N'yi sinyalin doğasına göre seçin. Rüzgar hızı ya da titreşim gibi sürekli değişen bir kanalda 10 dakikalık veride 6 aynı değer (1 saat) şüphelidir. Buna karşılık duran bir makinenin gücü ya da sabit ayarlı bir değer zaten sabit olabilir: orada donmuş değer hata değil durumdur. Bu yüzden eşiği kanal başına ayarlayın ve duruş dönemlerini ayrı değerlendirin.

4. Aralık dışı: fiziksel sınırlar

Sınırı verinin kendisinden değil fizikten türetin. Örnekler: yön 0-360 derece, bağıl nem 0-100, hız negatif olamaz. Sıcaklık gibi alanlarda sınırı çok geniş tutup yalnızca imkânsız değerleri yakalayın (örneğin ortam sıcaklığının altındaki bir rulman sıcaklığı bunun dışında, makineye özgü bir kuraldır). Fiziksel olarak mümkün ama alışılmadık değerler hata değil, istatistiksel aykırı değerdir; onlar ayrı bir adımda incelenir.

5. Sonucu nasıl okumalı?

• Hata sayısına değil, kanal başına kapsama ve sorunlu kayıt oranına bakın.
• Aynı kanalda boşluk, donma ve aralık dışı birlikte görünüyorsa algılayıcı ya da haberleşme sorunu olasıdır; bakım kayıtlarıyla karşılaştırın.
• Silmeyin, işaretleyin: neden şüpheli olduğunu yazan bir bayrak, hem eğitim penceresi seçmeyi hem kayıpları dürüstçe raporlamayı sağlar.

Araçla deneyin

Kendi CSV dosyanızı SCADA veri kalitesi denetimi aracına verin: dosya sunucuya yüklenmez, tarayıcıda işlenir. Zaman damgası sorunları için zaman damgası dönüştürücü işinize yarar. Kendi verinizle ilk değerlendirme için iletişime geçin.

Örneklem neye bağlıdır?

Dört büyüklük birbirini belirler:

• **Mevcut oran** (örneğin dönüşüm oranı %5).
• **Yakalamak istediğiniz en küçük fark** (örneğin %5'ten %6'ya).
• **Anlamlılık düzeyi** (genellikle %5, iki yönlü): fark yokken yanlış "fark var" deme riski.
• **Güç** (genellikle %80): fark gerçekten varken onu yakalama olasılığı.

Bunlardan biri sıkılaştırıldığında örneklem büyür. İki oranlı z-testi yaklaşımıyla örnekler:

• %5 → %6 (göreli %20 artış): grup başına yaklaşık 8.158 kullanıcı, iki grupla toplam yaklaşık 16.300
• %5 → %7: grup başına yaklaşık 2.213
• %5 → %5,5 (göreli %10 artış): grup başına yaklaşık 31.234

Fark yarıya indiğinde örneklem yaklaşık dört katına çıkar: örneklem, farkın karesiyle ters orantılıdır. Küçük gelişmeleri ölçmek bu yüzden pahalıdır.

Beş sık yanılgı

• **Anlamlı çıkınca testi durdurmak.** Sonuca sürekli bakıp ilk anlamlı p değerinde durmak yanlış pozitif oranını yükseltir. Örneklem büyüklüğünü ve süreyi önceden yazın, ona ulaşmadan karar vermeyin (ya da sıralı test yöntemleri kullanın).
• **Birçok metriği ya da dilimi denemek.** Yirmi metrikten birinin tesadüfen anlamlı çıkması beklenir. Ana metriği önceden belirleyin, diğerlerini keşif sayın.
• **Tam hafta döngüsünü atlamak.** Hafta içi ile hafta sonu davranışı farklıdır. Testi en az bir, tercihen iki tam hafta çalıştırın.
• **Anlamlılığı etki büyüklüğüyle karıştırmak.** Çok büyük bir örneklemde önemsiz bir fark da anlamlı çıkar; güven aralığına ve iş değerine bakın.
• **Dağılımın bozulduğunu fark etmemek.** Gruplar arası kullanıcı oranı planlanandan sapıyorsa (örneğin %50-50 yerine %52-48) atama hatası olabilir; sonuç bu kontrol yapılmadan yorumlanmamalıdır.

Anket örneklemi: kısa not

Anketlerde de aynı mantık, farklı büyüklüklerle çalışır: hata payı, güven düzeyi ve evren. %95 güven ve ±%5 hata payı için en kötü durumda (oran %50) sonsuz evrende gerekli örneklem 384,15, yukarı yuvarlanınca 385'tir. Evren 2.000 kişiyse sonlu evren düzeltmesiyle 323'e düşer. Yanıt oranı %30 ise 323 / 0,30 ≈ 1.077 kişiyi davet etmek gerekir. Yanıt verenlerin tüm evreni temsil etmesi (yanıt yanlılığı) ise ayrı bir sorundur; örneklem büyüklüğü bunu çözmez.

Araçlarla deneyin

Gereken örneklemi ve sonucun anlamlılığını A/B testi örneklem ve anlamlılık aracında hesaplayabilirsiniz: iki oranlı z-testi, p değeri, güven aralığı ve göreli artış tarayıcıda çıkar. Anketler için anket örneklem büyüklüğü, ortalama farkları için t-testi hesaplayıcı var. Deney tasarımınızı birlikte gözden geçirmek için bize yazın.

1. Ayın günü ile haftanın günü VEYA'dır

"0 9 1 * 1" ifadesini "ayın 1'i pazartesi ise 09:00" diye okumak yaygın bir yanılgıdır. Her iki alan da kısıtlıysa klasik (Vixie) cron bunları VEYA ile birleştirir: görev ayın 1'inde ve ayrıca her pazartesi çalışır. İkisinden biri yıldızsa mantık VE'ye döner. "Ayın ilk pazartesisi" gibi bir koşul için ifade tek başına yetmez; görev içinde bugünün tarihini kontrol etmek gerekir.

2. Adım değeri saat başında sıfırlanır

"*/7 * * * *" yedi dakikada bir demek gibi görünür; gerçekte dakikalar 0, 7, 14, ... 56 olur ve ardından saat başında yeniden 0 gelir. Yani 56'dan sonraki aralık 4 dakikadır. Aralığın 60'ı bölmediği adımlar (7, 8, 25...) düzensiz çalışır. Gerçekten eşit aralık gerekiyorsa 60'ı bölen bir adım (5, 10, 15, 20, 30) seçin ya da zamanlayıcıyı "son çalışmadan beri" mantığıyla kurun.

3. 31. gün olmayan aylar

"0 0 31 * *" her ay değil, yalnızca 31 gün çeken yedi ayda çalışır. "Ay sonu" için genellikle ayın 28'i gibi güvenli bir gün seçilir ya da görev her gün çalışıp "yarın ayın 1'i mi" diye bakar. Şubat'ta 30 ve 31 hiç, 29 ise yalnızca artık yıllarda bulunur.

4. Saat dilimi: sunucu ne diyor?

Cron ifadesinin saat dilimi, görevin çalıştığı ortamın saat dilimidir ve çoğu bulut ortamında UTC'dir. UTC 06:00, Türkiye'de (UTC+3, yaz saati uygulaması yok) 09:00'dır. "Her sabah 09:00" için sunucu UTC ise ifade "0 6 * * *" olmalıdır. Ortam değiştiğinde (yerel makineden buluta) saat dilimi de değişir ve görev üç saat kayar. Bu yüzden ifadenin yanına hangi saat diliminde yazıldığını yorum olarak yazmak iyi bir alışkanlıktır.

5. Yaz saati geçişleri

Yaz saati uygulayan bir saat diliminde ilkbahar geçişinde bir saat yoktur: örneğin Almanya'da mart ayının son pazarı yerel saat 02:00'den 03:00'e atlar, "30 2 * * *" o gün çalışmayabilir. Sonbaharda bir saat iki kez yaşanır ve aynı görev iki kez çalışabilir. Davranış zamanlayıcıya göre değişir. Önlem: kritik işleri UTC'de planlayın ya da görevi tekrar çalıştırılsa zarar vermeyecek şekilde (idempotent) yazın.

6. Başka sistemlerin sözdizimi

Quartz ve benzeri araçlar saniye alanlı altı ya da yedi alanlı ifade kullanır; "?" "L" "W" gibi özel karakterleri vardır. Standart cron'a yapıştırılan böyle bir ifade geçersizdir ya da başka bir anlama gelir. Haftanın günü için 0 ve 7 pazar demektir; adlar (MON, JAN) her sistemde desteklenmeyebilir.

Çalıştırmadan önce görün

İfadeyi cron ifadesi çözümleyici aracına yazın: düz dille açıklar, saat dilimini seçerek sonraki 10 çalışma zamanını gösterir ve VEYA gibi tuzakları uyarır. Zaman damgalarını dönüştürmek için zaman damgası dönüştürücü, yeniden deneme davranışı için API yeniden deneme simülatörü var. Entegrasyon zamanlamanızı gözden geçirmek için bize yazın.

1. JWT şifreli değildir

İmzalı bir JWT'nin başlığı ve yükü yalnızca base64url kodludur; herkes okuyabilir. Parola, kimlik numarası ya da gizli iş verisi yüke konmamalıdır. Gizlilik gerekiyorsa şifreli biçim (JWE) ya da belirteçte yalnızca bir başvuru numarası taşıyıp veriyi sunucuda tutmak gerekir.

2. Çözmek doğrulamak değildir

Yükü çözüp "kullanıcı: ayşe, rol: yönetici" okumak, belirtecin gerçek olduğunu göstermez. Güven, ancak imza anahtarla doğrulandıktan sonra doğar. Sunucuda yalnızca çözüp alanlara güvenen kod, herkesin kendi belirtecini yazmasına izin verir.

3. "alg": "none" ve algoritma karışıklığı

Başlıktaki alg alanı belirtecin kendisinden gelir; saldırgan onu değiştirebilir. Doğrulayıcı, hangi algoritmayı kabul edeceğini kendi yapılandırmasından almalıdır, başlıktan değil. "none" hiçbir koşulda kabul edilmemeli; genel anahtarla imzalanan (RS) belirtecin, aynı anahtar gizli parola gibi kullanılarak HS ile "doğrulanmasına" izin verilmemelidir.

4. Süre ve hedef alanlarını denetlememek

• exp (bitiş) alanı denetlenmezse belirteç sonsuza dek geçerli kalır.
• iss (veren) ve aud (hedef kitle) denetlenmezse bir başka hizmet için üretilmiş belirteç sizin API'nizde de geçer.
• nbf (başlangıç) ve saat sapması: sunucular arasında birkaç dakikalık hoşgörü yeterlidir, saatlerce değil.

5. Uzun ömürlü erişim belirteci

Erişim belirteci kısa ömürlü olmalı (dakikalar düzeyi), oturumu uzatmak için ayrı bir yenileme belirteci kullanılmalıdır. Çalınan uzun ömürlü belirteç, çalındığı fark edilene kadar tam yetkiyle kullanılabilir.

6. Depolama yeri

Tarayıcıda localStorage içindeki belirteç, sayfaya sızan her betiğin (XSS) eline geçer. Çerez, HttpOnly ve Secure bayraklarıyla ve uygun SameSite ayarıyla tutulduğunda betikler tarafından okunamaz; ancak çerez kullanıyorsanız CSRF'yi de ayrıca düşünmelisiniz. Hiçbir seçenek tek başına yeterli değildir.

7. İptal edememek

JWT kendi kendine yeten bir belirteçtir; sunucu bitiş süresinden önce iptal etmek için ek bir mekanizmaya ihtiyaç duyar (kara liste, oturum sürümü, kısa ömür). Çıkış yapan ya da yetkisi alınan kullanıcının belirteci, süresi dolana kadar geçerli kalabilir; bunu tasarımda kabul edin ya da kapatın.

8. Zayıf HMAC anahtarı

HS256 gibi paylaşılan anahtarlı algoritmalarda tahmin edilebilir ya da kısa bir anahtar çevrimdışı olarak denenerek kırılabilir. Anahtar rastgele üretilmiş, yeterince uzun ve koddan ayrı saklanmalıdır.

Aracı nasıl kullanmalı?

Bir belirteci JWT çözümleyici ile tarayıcınızda açıp başlığı, yükü, zaman alanlarını ve zayıf ayarları görebilirsiniz; belirteç hiçbir yere gönderilmez. Araç çözer, doğrulamaz: gerçek doğrulama sunucunuzda anahtarla yapılmalıdır. İmza mantığını denemek için webhook HMAC imza doğrulama, anahtar için parola gücü ve entropi hesaplayıcı işinize yarar. API güvenliğini gözden geçirmek için bize yazın.

1. VA ile W aynı şey değildir

UPS'ler VA (görünür güç) ve W (gerçek güç) olarak iki değerle anılır. Aralarında güç faktörü vardır: W = VA × güç faktörü. Örneğin 1000 VA ve güç faktörü 0,9 olan bir UPS en fazla 900 W taşır. Güç faktörü modelden modele değişir; kataloğun gerçek güç değerine bakın. Yükün tarafında da aynı: bir sunucunun gücü W olarak belirtilmişse onu VA'ya çevirmek zorunda değilsiniz, ama UPS'in W sınırı yük toplamından büyük olmalıdır.

2. Yükü doğru toplayın

Cihazların etiket (azami) gücünü toplamak abartılı sonuç verir; gerçek tüketimi ölçmek ya da güç ölçerle okumak daha doğrudur. Yine de başlangıç yüklemelerini (disk dönme, soğutma fanları) ve ileride eklenecek cihazları hesaba katın. UPS'i anma gücünün tamamında çalıştırmak yerine bir pay bırakmak yaygın bir iç ölçüttür; payı kendi politikanıza göre belirleyin.

3. Çalışma süresi: enerji bölü güç

Basit yaklaşım şu adımlardan geçer. Örnek: yük 300 W; batarya 12 V, 9 Ah olan iki adet seri bağlı (24 V, 9 Ah).

• Nominal enerji: 24 V × 9 Ah = 216 Wh
• Evirici verimi %90 ise bataryadan çekilen güç: 300 / 0,9 = 333,3 W
• Batarya akımı: 333,3 / 24 = 13,9 A
• Bataryanın tamamı kullanılamaz: kullanılabilir derinlik %80 ve yaşlanma ya da sıcaklık düzeltmesi %80 alınırsa kullanılabilir kapasite 9 × 0,8 × 0,8 = 5,76 Ah
• Süre: 5,76 / 13,9 = 0,415 saat, yani yaklaşık 24,9 dakika

Beklediğinizden kısa mı çıktı? Çıkması normaldir: nominal 216 Wh'in yaklaşık yarısı gerçekte kullanılabilir.

4. Hedef süreden geriye hesap

Bunu tersine çevirebilirsiniz. Aynı yük için 30 dakika isteniyorsa gereken kullanılabilir kapasite 13,9 A × 0,5 saat = 6,94 Ah, nominal olarak 6,94 / 0,64 = 10,85 Ah'dir; yani yaklaşık 11 Ah ve üzeri bir batarya dizisi gerekir. Bir üst standart değerin seçilmesi gerekir.

5. Hesabın sınırları

• **Yük sabit değildir.** Çalışma süresi, yük düştükçe doğrusal olmayan biçimde uzar; yüksek akımda batarya daha az kapasite verir (Peukert etkisi). Sabit güç varsayımı yaklaşık bir değerdir.
• **Batarya yaşlanır.** Birkaç yıllık bataryanın kapasitesi başlangıçtakinden düşüktür; sıcak ortam da ömrü kısaltır.
• **Üretici eğrisi esastır.** Hesap, ön karar içindir; kesin süre için üreticinin yük-süre tablosuna bakın.
• **Bitiş gerilimi.** UPS belirli bir gerilimin altına inince kapanır; bu "derinlik" değeri hesaba girdiğiniz DoD ile uyumlu olmalıdır.

Aracı kullanın

Kendi yükünüzü, bataryanızı ve hedef sürenizi UPS yedek güç süresi hesaplayıcı aracına girin: VA ya da W, güç faktörü, evirici verimi, yaşlanma payı ve isteğe bağlı Peukert üssüyle süreyi hesaplar, yük değişince duyarlılığı gösterir ve ters modda gereken kapasiteyi verir. Sunucu odası bütününde soğutma yükü için sunucu odası güç ve soğutma hesabı var. Yedek güç tasarımınızı gözden geçirmek için bize yazın.

Önekten adres sayısı

/n öneki, 32 bitin ilk n bitinin ağı belirttiğini söyler. Blokta 2^(32-n) adres vardır:

• /24: 256 adres (genellikle 254 kullanılabilir istemci)
• /23: 512 adres
• /22: 1.024 adres

Klasik ağlarda ilk adres ağ adresi, son adres yayın adresidir; bu yüzden kullanılabilir sayı iki eksiktir (/30'da 4 adresten 2'si, /31 noktadan noktaya bağlantılar için özel istisnadır). Bulut sağlayıcıları ayrıca kendi adreslerini ayırır; sayı sağlayıcıya göre değişir, planı kendi belgesine göre yapın.

Hizalama: blok kendi boyutunun katında başlar

/24 bloğu 256'nın katı olan bir adreste, /23 bloğu 512'nin katında başlar. Bu yüzden 10.0.0.0/24 ve 10.0.1.0/24 birleşip 10.0.0.0/23 olur: üçüncü bayt 0 ve 1, 512'lik bir bloğu tam doldurur. Buna karşılık 10.0.1.0/24 ve 10.0.2.0/24 komşu görünür ama 10.0.1.0 çift bir üçüncü bayttan başlamadığı için tek bir /23'e sığmaz; tek blok olarak özetlemeye kalkarsanız aradaki ve çevredeki adresleri de dahil etmiş olursunuz. Dört ardışık /24'ü (10.0.0.0 ile 10.0.3.0) 10.0.0.0/22 olarak özetleyebilirsiniz.

Özetleme neden önemli?

Yönlendirme tablosunda onlarca şube ağı yerine tek bir satır tutmak, tabloyu küçültür ve arızayı gizler. Ama özet blok, onun içinde sizin olmayan adresleri de kapsıyorsa trafik yanlış yere gidebilir. Özetleme yalnızca gerçekten bitişik ve hizalı bloklar için güvenlidir; planı başta büyük, hizalı bloklara bölerek yapın (şube başına /24, bölge başına /20 gibi).

Çakışma kontrolü

İki blok, birinin adres aralığı ötekini kesiyorsa çakışır; bir blok ötekinin içinde kalıyorsa da çakışır. Örnek: 10.20.0.0/16 ile 10.20.8.0/21 çakışır, çünkü /21 üçüncü baytı 8-15 olan adresleri kapsar ve bunlar /16'nın içindedir. Çakışma en sık şu durumlarda ortaya çıkar:

• Şirket ağı ile ev ya da misafir ağı aynı varsayılan bloğu kullanıyorsa VPN'de yollar karışır.
• İki şirket birleşirken ikisi de 10.0.0.0/16 kullanıyorsa.
• Bulut sanal ağı ile yerel ağ aynı blokta kurulmuşsa ve ikisi bağlanacaksa.

Planlama düzeni

• Önce en büyük gereksinimi yerleştirin, sonra küçüklere inin (VLSM).
• Her blokta büyüme payı bırakın: bugünkü ihtiyacın iki katı sık kullanılan bir ölçüttür.
• Gelecekte bağlanabilecek ağlarla (ortaklar, bulut) çakışmamak için varsayılan 192.168.0.0/24 ve 10.0.0.0/24 gibi yaygın blokları kullanmaktan kaçının.
• Kullanımı bir tabloya yazın: blok, amaç, sahibi, tarih.

Araçlarla deneyin

Bir adres ve önek için ağ, yayın, ilk-son adres ve ana makine sayısını IP alt ağ ve CIDR hesaplayıcı ile görün. Birden fazla bloğu tek bloğa özetlemek ya da çakışmayı denetlemek için CIDR özetleme ve birleştirme aracını kullanın; IPv6 için IPv6 alt ağ hesaplayıcı var. Ağ ve bulut adres planınızı birlikte gözden geçirmek için bize yazın.