Bir fabrikada makineyi çalıştıran program, bilgisayarda çalışan bir programa benzemiyor. Farklı görünüyor, farklı çalışıyor ve farklı bir mantıkla yazılıyor. Bu farkın nereden geldiği, PLC dünyasının kendi standardında yazılı.
Neden ayrı bir dil ailesi var
PLC, üretim sahasında makineyi ve hattı kontrol eden denetleyici. Yaptığı iş sürekli tekrar eden bir döngü: girişleri oku, kararı ver, çıkışları yaz, baştan başla.
Bu döngü mantığı, masaüstü yazılımın çalışma biçiminden ayrı. Bir masaüstü programı olayları bekliyor, PLC ise durmadan aynı turu atıyor. Program da bu tura göre yazılıyor.
İkinci fark yazan kişiden geliyor. Sahadaki programı çoğu zaman bir yazılım mühendisi değil, elektrik ya da otomasyon tarafından gelen biri yazıyor ve okuyor. Diller de buna göre şekillenmiş: bazıları elektrik şemasına, bazıları blok diyagramına benziyor.
IEC 61131-3 ne yaptı
Uzun yıllar boyunca her PLC üreticisi kendi programlama biçimini getirdi. Bir markada yazılan program başka markada okunmuyordu; bilgi de kişiye ve markaya bağlı kalıyordu.
IEC 61131-3, bu alanı ortak bir çerçeveye oturtan standart. Beş programlama dilini tanımlıyor ve programın yapı taşlarını, veri tiplerini ve organizasyon biçimini ortaklaştırıyor.
Standardın getirdiği asıl şey dillerin kendisi değil. Programın bölünebilir hale gelmesi. Tekrar eden bir işin ayrı bir blok olarak tanımlanıp defalarca kullanılabilmesi, sahadaki programların yapısını değiştiren şey oldu.
Uygulamada tam taşınabilirlik hâlâ yok; üreticiler standardın üstüne kendi eklerini koyuyor. Ama ortak dil ve ortak kavram seti, farklı sistemler arasında geçiş yapan mühendis için gerçek bir kolaylık sağladı.
Beş dil ve nerede işe yaradıkları
Standardın tanımladığı beş dil, aynı işi farklı biçimlerde anlatıyor. Aralarındaki seçim bir üstünlük meselesi değil; işin türüne ve kimin okuyacağına bağlı.
Merdiven diyagramı (LD). Röle kontrol şemalarının doğrudan devamı. İki dikey hat arasına yerleşen kontaklar ve bobinler, elektrik şemasıyla aynı görüntüyü veriyor. Sahada en yaygın olan bu, çünkü elektrik tarafından gelen herkes bakar bakmaz anlıyor. Mantıksal kontrol, kilitleme ve emniyet zincirleri gibi işlerde okunması kolay.
Fonksiyon blok diyagramı (FBD). Kutular ve aralarındaki bağlantılar. Sinyalin soldan sağa aktığı bir akış görüntüsü veriyor. Süreç kontrolünde, analog işlemlerde ve sinyal işleme benzeri işlerde merdiven diyagramından daha okunur kalıyor.
Yapısal metin (ST). Metin tabanlı ve genel amaçlı programlama dillerine benziyor. Hesaplama, döngü, koşul ve veri işleme gerektiren yerlerde diğerlerinden belirgin şekilde güçlü. Uzun bir matematiksel işlem merdiven diyagramında okunmaz hale gelirken, burada birkaç satırda duruyor.
Sıralı fonksiyon şeması (SFC). Adım ve geçişlerden oluşan bir yapı. Bir sürecin aşamalarını anlatmak için kullanılıyor: dolum, karıştırma, boşaltma gibi sıralı işleyen prosesler burada doğal duruyor. Genelde adımların içi başka bir dille yazılıyor.
Komut listesi (IL). Assembly benzeri, satır satır komutlardan oluşan metin tabanlı dil. Standardın yeni sürümlerinde geçerliliğini yitirdi ve yeni projelerde kullanılmıyor. Eski sistemlere bakarken karşılaşılıyor.
Pratikte bir projede tek dil kullanılmıyor. Aynı program içinde bir bölüm merdiven diyagramıyla, bir bölüm yapısal metinle yazılabiliyor. Belirleyici olan, hangi bölümü kimin okuyacağı.
Programın okunabilirliği, dilinden daha önemli
Sahadaki asıl sorun dil seçimi değil. Yıllar sonra programa bakan kişinin ne gördüğü.
Bir PLC programı ortalama bir kurumsal yazılımdan uzun yaşıyor. On yıl önce yazılmış bir program hâlâ hattı çalıştırıyor olabiliyor ve o programa müdahale etmesi gereken kişi, çoğu zaman onu yazan kişi değil.
Bu noktada üç şey belirleyici oluyor.
Etiketlerin anlamlı isimlerle yazılmış olması. Sinyalin adı ne yaptığını söylüyorsa program kendi kendini anlatıyor; söylemiyorsa her satır için şemaya dönmek gerekiyor.
Blokların açıklanmış olması. Bir bölümün ne işe yaradığı yazılı değilse, o bölüme dokunmak risk haline geliyor.
Sürümün takip edilebilir olması. Hangi değişikliğin ne zaman ve neden yapıldığı bilinmiyorsa, arıza anında geriye dönülemiyor.
Bu üçü olmadan program çalışır ama bakılamaz. Bakılamayan bir program, tesisin bir kişiye bağlı kalması demek.
Bir dolum hattında
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Sıvı dolum yapan bir hat. Programı yıllar önce yazılmış, o günden beri sorunsuz çalışıyor.
Hatta yeni bir istasyon eklenmek istendi. Program açıldığında iki şey görüldü.
Birincisi, programın tamamı tek bir dille ve tek bir uzun bölüm halinde yazılmıştı. Dolum, kapaklama ve etiketleme aynı akışın içinde iç içe geçmişti; birini değiştirmeden diğerine dokunmak mümkün değildi.
İkincisi, etiketler sinyal numaralarıyla adlandırılmıştı. Hangi girişin hangi sensöre ait olduğunu anlamak için pano şemasına bakmak gerekiyordu ve şemanın son hali panoda değildi.
Yeni istasyonun eklenmesi teknik olarak küçük bir işti. Zamanın büyük bölümü, mevcut programın ne yaptığını anlamaya gitti.
Değişiklik sonrası hattaki program yeniden düzenlendi: süreç adımları ayrıştırıldı, tekrar eden işlemler ortak bloklara alındı ve etiketler ne yaptıklarını söyleyen isimlerle yeniden adlandırıldı.
Bir sonraki eklemede aynı iş, anlamaya harcanan süre olmadan tamamlandı.
Kimin malı, kimde duruyor
PLC tarafında az konuşulan ama tesis için en kritik başlık bu.
Programın kaynağı sizde mi. Değişiklik yapmak için yazan firmaya dönmek zorunda mısınız. Program bir yedeğe alınmış mı ve o yedeğin güncel olduğundan emin misiniz.
Bu üç soruya net cevap veremeyen bir tesis, teknik olarak çalışıyor ama yönetsel olarak açıkta. Hattı durduran bir arızada sürenin belirleyicisi, programın kendisi değil ona erişip erişemediğiniz oluyor.
PLC programlama tarafında bizim duruşumuz bu konuda nettir: yazdığımız program size aittir ve kaynağı sizde kalır.
Codigno tarafında
Endüstriyel otomasyon tarafında program yazarken okunabilirlik bir tercih değil, teslim koşulu. Etiketler anlamlı isimlerle yazılıyor, bloklar açıklanıyor ve kaynak müşteride kalıyor.
Operatör tarafındaki görüntüleme ve alarm katmanı için: SCADA ve HMI.
Mevcut bir hatta dokunuluyorsa, önce orada ne olduğunun çıkarılması gerekiyor: mevcut sistem entegrasyonu.
Cihazlar arası veri akışı tarafı için: endüstriyel haberleşme.
Sık sorulan sorular
Hangi PLC dili en iyisi?
Böyle bir dil yok. Mantıksal kontrolde merdiven diyagramı, hesaplama gerektiren işlerde yapısal metin, sıralı proseslerde sıralı fonksiyon şeması daha okunur sonuç veriyor. Seçimde belirleyici olan işin türü ve programa kimin bakacağı.
IEC 61131-3 programı her markada çalıştırır mı?
Tam olarak değil. Standart ortak bir çerçeve veriyor, ancak üreticiler kendi eklerini koyuyor. Kavramlar ortaklaşıyor, birebir taşınabilirlik garanti edilmiyor.
Merdiven diyagramı eski bir yöntem mi?
Eski değil, yaygın. Röle şemalarından geldiği için elektrik tarafından gelen herkesin okuyabilmesi en büyük avantajı. Sahada hâlâ en çok kullanılan dil.
Aynı programda birden fazla dil kullanılabilir mi?
Kullanılıyor. Bir bölüm merdiven diyagramıyla, hesaplama yapan başka bir bölüm yapısal metinle yazılabiliyor. Standart buna izin veriyor.
PLC programı ne kadar yaşıyor?
Kurumsal yazılımlardan uzun. On yılı aşan programlar sahada yaygın. Bu yüzden okunabilirlik ve sürüm takibi, yazıldığı gün önemsiz görünüp yıllar sonra belirleyici hale geliyor.
Programın kaynağı neden bizde olmalı?
Değişiklik ve arıza müdahalesi buna bağlı olduğu için. Kaynağa erişemeyen bir tesis, en küçük değişiklik için bile dışarıya bağımlı kalıyor.
Hattınızdaki programın kaynağı sizde mi? Tesisinizdeki mevcut sistemi ve yapmak istediğiniz değişikliği paylaşın; nereden başlanacağını birlikte çıkaralım.
