Operatörlerin Gerçekten Kullandığı Duruş Nedeni Kodları Nasıl Tasarlanır?

Duruş nedeni kodları, duruş verinizin aksiyona mı dönüşeceğini yoksa yalnızca bir veritabanını mı dolduracağını belirler. Bu rehber, operatörlerin birkaç saniyede kullanabileceği kısa ve yapılandırılmış bir neden ağacının nasıl tasarlanacağını, bunun OEE kayıplarıyla nasıl eşleştirileceğini ve sensörlerinizin zaten algıladığı makine durumlarının yanında nedenleri MQTT üzerinden yayınlayan bir giriş akışının nasıl kurulacağını gösteriyor. Sonunda elinizde bir başlangıç ağacı, bunun için bir JSON formatı ve operatör tarafı için çalışan kod olacak.

Neden Kodu Listelerinin Çoğu Neden Başarısız Olur?

Tesisler duruş takibine genellikle iyi niyetle ve uzun bir listeyle başlar. Birkaç ay içinde veriler hep aynı tabloyu gösterir: duruşların büyük bir kısmı "Diğer" ya da "Çeşitli" olarak kodlanmış, birkaç kod her şey için kullanılmış ve onlarca kod hiç kullanılmamıştır. Kök nedenler tahmin edilebilir:

• Çok fazla kod. Altmış seçenekli kayan bir listeyle karşılaşan operatör, akla yatkın ilk seçeneği işaretler.
• Departman adlarıyla kodlar. "Bakım" veya "Kalite" ne olduğunu değil, kimin sorumlu olduğunu anlatır; dolayısıyla kimse buna göre aksiyon alamaz.
• Örtüşen anlamlar. Bir besleme hatasına hem "Sıkışma" hem de "Malzeme sorunu" uyar; böylece aynı olay vardiyada kimin olduğuna göre iki farklı kod alır.
• Algılamayla bağlantı yok. Operatör duruşun ne zaman başlayıp bittiğini de kaydetmek zorundaysa doğruluk çöker. Zamanlama makineden gelmeli; yalnızca neden bir insandan gelmelidir.

Çözüm kısa bir hiyerarşi, net ifadeler ve otomatik durum algılamadır.

İyi Duruş Nedeni Kodları İçin İlkeler

1. Algılamayı açıklamadan ayırın. Makineler RUNNING ve STOPPED durumlarını otomatik bildirir; operatörler yalnızca "neden?" sorusunu yanıtlar.
2. Düz liste değil, ağaç kullanın. İki ya da üç seviye: bir kategori, bir neden ve isteğe bağlı bir detay. Her ekran yalnızca birkaç seçenek gösterir.
3. Departmanı değil, nedeni adlandırın. "Malzeme bekleniyor", "Lojistik"ten daha iyidir.
4. Kodları birbirini dışlayan hale getirin. İki kod aynı olayı tanımlayabiliyorsa birleştirin ya da onları ayıran tek satırlık bir tanım yazın.
5. Üst seviyeyi küçük ve sabit tutun. Üst seviyeyi OEE kayıplarıyla eşleştirin; böylece raporlar otomatik olarak toplanır.
6. "Diğer"i sınırlayın. "Diğer" seçildiğinde serbest metin yorumu zorunlu tutun ve bu yorumları her hafta gözden geçirin; tekrar edenler yeni kodlara dönüşür.
7. Mümkün olan yerde makine alarmlarının doldurmasına izin verin. Kontrolör bir arıza kodu bildiriyorsa eşleşen nedeni önerin ve operatörün onaylamasını sağlayın.
8. Ağacı düzenli olarak gözden geçirin. Kullanılmayan kodları kaldırın, çok fazla şeyi gizleyen kodları bölün.

Başlangıç İçin Bir Neden Kodu Ağacı

Bunu bir başlangıç noktası olarak kullanın ve ikinci seviyeyi kendi prosesinize göre uyarlayın. Üst seviye; kullanılabilirlik, performans ve planlı süreyle temiz biçimde eşleşir.

Altı kategori altındaki on beş kod iki ekrana sığar. Bazı tesisler arızalar için üçüncü bir seviye (hangi ünitenin arızalandığı) ekler, ancak bunu ancak ikinci seviye tutarlı biçimde kullanılmaya başlandıktan sonra yapar. Planlı kategorilerin nasıl ayrı tutulduğuna dikkat edin: OEE'den hariç tutulurlar, ancak OEE ve TEEP karşılaştırmaları için önemlidirler.

Mikro duruş eşiğinizin altındaki kısa duruşlar hiç neden sormamalıdır. Manuel giriş için fazla sıktırlar ve ambalaj hattı izleme kullanım senaryosunda gösterildiği gibi makine arıza kodlarıyla daha iyi açıklanırlar.

Ağacı Veri Olarak Saklamak

Ağacı tek bir JSON belgesinde tutun ve retained MQTT mesajı olarak yayınlayın. Her operatör terminali buna abone olur; böylece bir kodu değiştirmek, uygulamaları yeniden kurmak yerine tek bir mesajı güncellemek anlamına gelir.

{
  "version": 3,
  "min_prompt_seconds": 180,
  "categories": [
    {"id": "BRK", "label": "Breakdown", "loss": "availability", "reasons": [
      {"code": "BRK-MECH", "label": "Mechanical failure"},
      {"code": "BRK-ELEC", "label": "Electrical or control fault"},
      {"code": "BRK-TOOL", "label": "Tooling or fixture failure"}
    ]},
    {"id": "CHG", "label": "Changeover", "loss": "availability", "reasons": [
      {"code": "CHG-PROD", "label": "Product changeover"},
      {"code": "CHG-TOOL", "label": "Tool change"},
      {"code": "CHG-FAI", "label": "First-article approval"}
    ]},
    {"id": "WAIT", "label": "Waiting", "loss": "availability", "reasons": [
      {"code": "WAIT-MAT", "label": "Waiting for material"},
      {"code": "WAIT-OPR", "label": "Waiting for operator"},
      {"code": "WAIT-QA", "label": "Waiting for quality release"}
    ]},
    {"id": "PLN", "label": "Planned", "loss": "planned", "reasons": [
      {"code": "PLN-BRK", "label": "Break or meeting"},
      {"code": "PLN-PM", "label": "Planned maintenance"},
      {"code": "PLN-NOS", "label": "No orders scheduled"}
    ]},
    {"id": "OTH", "label": "Other", "loss": "availability", "reasons": [
      {"code": "OTH", "label": "Other", "comment_required": true}
    ]}
  ]
}

Bunu bir kez (retained olarak) tesis seviyesindeki bir topic'e yayınlayın. Ücretsiz herkese açık MQTT broker üzerinde kendinize ait rastgele bir önek kullanın:

mosquitto_pub -h broker.connectmq.com -p 1883 -i reasons-admin-b3z5 -r -q 1 -t "connectmq/demo/b3z5/plant1/config/downtime-reasons" -f reasons.json

Operatör Giriş Akışı

Sahada en iyi işleyen akış, istem (prompt) odaklı olandır:

1. Makine sensörü veya PLC, makinenin durum topic'ine STOPPED yayınlar. Zamanlama otomatik olarak başlar. Sensör tarafı için makine duruş takibi yazısına bakın.
2. Duruş min_prompt_seconds değerinden uzun sürerse makinedeki terminal kategori ekranını gösterir.
3. Operatör önce bir kategoriye, ardından bir nedene dokunur. İki dokunuş, birkaç saniye.
4. Terminal, nedeni duruşun başlangıç zamanıyla birlikte makinenin reason topic'ine yayınlar; böylece kaydedici, geç ulaşsa bile onu doğru olaya bağlayabilir.
5. Makine yeniden çalıştığında açık olay kapanır. Neden girilmediyse süpervizör bunu vardiya sonunda "açıklanmamış" listesinde görür.

Aşağıda güvenli WebSocket üzerinden MQTT.js kullanan tarayıcı tabanlı bir terminalin çekirdeği yer alıyor. Butonların çizilmesi kullandığınız UI çatısına bırakılmıştır; önemli olan MQTT mantığıdır.

import mqtt from "mqtt";

const PREFIX = "connectmq/demo/b3z5/plant1";
const MACHINE = "stamping/press04";
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId: "terminal-press04-" + Math.random().toString(16).slice(2, 8),
  protocolVersion: 5,
});

let tree = null;
let stoppedAt = null;
let promptTimer = null;

client.on("connect", () => {
  client.subscribe(`${PREFIX}/config/downtime-reasons`, { qos: 1 });
  client.subscribe(`${PREFIX}/${MACHINE}/state`, { qos: 1 });
});

client.on("message", (topic, payload) => {
  const data = JSON.parse(payload.toString());
  if (topic.endsWith("/downtime-reasons")) {
    tree = data;
    return;
  }
  if (data.state === "STOPPED" && stoppedAt === null) {
    stoppedAt = Date.now();
    promptTimer = setTimeout(() => showCategories(tree.categories), tree.min_prompt_seconds * 1000);
  } else if (data.state === "RUNNING") {
    clearTimeout(promptTimer);
    stoppedAt = null;
  }
});

export function submitReason(code, comment = "") {
  const msg = { code, comment, stop_started: stoppedAt, entered: Date.now() };
  client.publish(`${PREFIX}/${MACHINE}/reason`, JSON.stringify(msg), { qos: 1 });
  hidePrompt();
}

function showCategories(categories) {
  // Her kategori için büyük bir buton çizin, ardından seçilen kategorinin nedenlerini gösterin
  // ve bir nedene dokunulduğunda submitReason(reason.code) fonksiyonunu çağırın.
  console.log("Prompt operator with", categories.map((c) => c.label));
}

function hidePrompt() {
  console.log("Prompt closed");
}

Low-code tercih ediyorsanız aynı akışı Node-RED'de Dashboard 2.0 butonları ve bir mqtt out node'u ile kolayca kurabilirsiniz; test için broker.connectmq.com'a 1883 portundan, üretimde ise TLS ile 8883 portundan bağlanacak şekilde yapılandırın.

Kodları Devreye Almak ve Sürdürmek

• İki hafta boyunca tek bir hatta pilot uygulama yapın. Hangi kodların kullanıldığını, hangilerinin hiç kullanılmadığını ve insanların "Diğer" altına ne yazdığını izleyin.
• Gerçek örneklerle eğitim verin. Operatörlere son beş duruşu gösterin ve bunları birlikte kodlamalarını isteyin. Görüş ayrılıkları belirsiz kodları ortaya çıkarır.
• Geri bildirim verin. En sık nedenleri her hafta hatta gösterin. Operatörler verinin kullanıldığını gördüklerinde daha iyi veri girerler.
• Ağacı sürümlendirin. version alanını koruyun ve her nedenle birlikte saklayın; böylece kodlar değiştikten sonra da raporlar doğru kalır.
• Kodları değil, etiketleri çevirin. Çok dilli tesislerde kodları sabit tutun ve her dil için etiket alanları ekleyin; böylece raporlar terminalin dilinden bağımsız olarak doğru toplanır.
• Neden girişinin zamanlamasını denetleyin. Nedenin ne zaman girildiğini duruşun ne zaman başladığıyla karşılaştırın. Makine yeniden çalıştıktan çok sonra girilen nedenler daha az güvenilirdir ve istem ya da personel sorunlarına işaret eder.

Ağaç, ConnectMQ broker'ınızda tek bir retained mesaj olarak durduğu için yeni bir sürüm yayınlamak bir sonraki yeniden bağlantıda tüm terminalleri günceller ve portalın topic gezgini hangi sürümün yayında olduğunu tam olarak gösterir.

Veri Akışını Barındırmak

Tasarım aşamasında broker.connectmq.com adresindeki herkese açık MQTT test broker'ı yeterlidir. Üretimde ise nedenler ve durumlar özel bir broker'da olmalıdır. ConnectMQ, istemci bazlı kimlik bilgileri ve 8084 portunda güvenli WebSocket sunan bir yönetilen MQTT broker sağlar; böylece tarayıcı terminalleri bir backend olmadan doğrudan bağlanır. Portalın canlı topic gezgini, nedenlerin doğru topic'lere ulaştığını kontrol etmeyi kolaylaştırır. Neden verisinin daha geniş bir tesis programına nasıl oturduğunu görmek için akıllı üretim rehberine göz atın.

ConnectMQ ile Başlayın

app.connectmq.com adresinden ücretsiz kaydolun, kredi kartı olmadan bir Serverless broker oluşturun, neden ağacınızı yayınlayın ve ilk operatör terminalinizi bugün bağlayın.

Sık Sorulan Sorular

Kaç tane duruş nedeni kodumuz olmalı?

Operatörlerin iki dokunuşta seçim yapabileceği kadar az: genellikle her biri üç ila beş neden içeren beş ila yedi kategori. Listeyi yalnızca "Diğer" yorumları tekrar eden bir neden gösterdiğinde büyütün.

Operatörler başlangıç ve bitiş zamanlarını girmeli mi?

Hayır. Duruşları makinenin otomatik algılamasına izin verin ve operatörden yalnızca nedeni isteyin. Manuel zamanlama, hatalı duruş verisinin başlıca kaynağıdır.

Nedeni girilmemiş duruşlara ne olmalı?

Vardiya sonunda süpervizöre açıklanmamış olarak gösterin. Açıklanmamış oranının yüksek olması genellikle kodların veya istem zamanlamasının iyileştirilmesi gerektiği anlamına gelir.

Makine alarmları operatör nedenlerinin yerini alabilir mi?

Kısmen. Alarm kodları pek çok arızayı ve mikro duruşu iyi açıklar, ancak bekleme, ürün değişimi ve malzeme sorunları yine de bir insanın yanıtını gerektirir.