OPC UA Bilgi Modeli ve Companion Specification ile Veri Modelleme

OPC UA sunucusu devreye alınmış, sertifikalar yerinde, bağlantı yeşil. Ama istemci hâlâ yüzlerce düz tag’i tek tek okuyor: DB10.Hiz, DB10.Sicaklik_1, Line3_Count. Bu haliyle OPC UA, şifreli bir Modbus’tan fazlası değildir. Protokolü değerli kılan şey verinin anlamını ve yapısını da taşıyan bilgi modelidir. Aşağıda adres alanı, düğüm sınıfları, tip tanımları ve Companion Specification’ı, bir dolum makinesi modeli üzerinden sahada nasıl kurduğumuzu anlatıyoruz.

Tag listesi neden bir noktada tıkanır

Düz tag listesinde anlam iki yerde yaşar: isimlendirme kuralında ve birinin masaüstündeki Excel dosyasında. OT altyapısında aynı tipte on makine varsa istemci tarafında on ayrı eşleme yapılır. Bir makineye sensör eklenir; SCADA, historian ve MES tarafındaki eşlemelerin hepsi elle güncellenir, biri mutlaka unutulur. Bilgi modelinde ise “dolum makinesi” bir kez tip olarak tanımlanır, her makine bu tipin örneği olur ve istemci yapıyı tarayarak (browse) aynı tipteki tüm örnekleri kendisi bulur.

Konu	Düz tag listesi	Tip tabanlı bilgi modeli
Anlam	İsimde ve harici dokümanda	Tip, referans ve özelliklerde
Birim, aralık	Ayrı tabloda	EngineeringUnits, EURange özellikleri
Yeni makine ekleme	Tüm istemcilerde yeni eşleme	Yeni örnek; istemci tipten tanır
Üretici bağımsızlığı	Her üretici kendi isimlerini kullanır	Companion Specification ile ortak yapı
Başlangıç maliyeti	Düşük	Model tasarımı ve araç gerektirir

Modelin bedeli baştaki tasarım zamanıdır. Tek makineden üç beş değer okunacaksa düz değişkenler yeter, kimse aksini iddia etmesin. Aynı tipte çok sayıda ekipman, birden fazla tüketici sistem ve yıllarca yaşayacak bir üretim verisi toplama altyapısı varsa hesap değişir. Tasarım işi kendini geri öder. Protokol kararı henüz verilmediyse önce OPC UA ile MQTT’nin karşılaştırmasına göz atın.

Adres alanı, düğümler ve referanslar

Sunucunun istemciye gösterdiği her şey adres alanında (AddressSpace) bir düğümdür (node). Her düğümün bir NodeId’si, bir BrowseName’i, bir DisplayName’i ve bir düğüm sınıfı (NodeClass) vardır. Spesifikasyon sekiz düğüm sınıfı tanımlar:

• Object: Makine, hat, motor gibi bir varlığı temsil eden kap.
• Variable: Değer taşıyan düğüm. İki türü vardır: veri değişkeni (DataVariable) ve özellik (Property).
• Method: İstemcinin çağırabileceği işlev; örneğin reçete yükleme.
• ObjectType ve VariableType: Nesne ve değişkenlerin tip tanımları.
• ReferenceType: Düğümler arasındaki ilişkinin anlamı.
• DataType: Değerin veri tipi; structure ve enum tanımları dahil.
• View: Adres alanının bir alt kümesini sunan görünüm.

Modelin iskeleti referanslardır. En sık kullandıklarımız: Organizes (klasör düzeni, i=35), HasComponent (nesnenin parçası olan değişken, nesne veya metot, i=47), HasProperty (düğümü niteleyen sabit ya da yavaş değişen bilgi, i=46), HasTypeDefinition (örneğin hangi tipten geldiği, i=40) ve HasSubtype (tip kalıtımı, i=45). Değişken ile özellik ayrımını sahada en çok karıştırılan nokta olarak görüyoruz. Sıcaklık ölçümü bir bileşen değişkendir. Birimi ve ölçüm aralığı ise o değişkenin özellikleridir.

NodeId bir namespace indeksi ile tanımlayıcıdan oluşur: ns=2;s=Filler01.Speed gibi. İndeks sunucuya, hatta sunucunun yeniden yapılandırılmasına göre değişebilir; kalıcı olan namespace URI’sidir. İstemci yapılandırmasına ns=2 yazıp geçen ekipler, sunucuya yeni bir NodeSet yüklendiği gün bütün okumaların boşa düştüğünü görür. Doğrusu, indeksi sunucunun NamespaceArray’inden URI üzerinden çözmektir. Sabit indeks, ertelenmiş arızadır.

ObjectType ve tip tanımları

Tip tabanlı modelin merkezi ObjectType’tır. Kendi tipinizi BaseObjectType’tan (i=58) ya da bir Companion Specification’daki daha özel bir tipten türetirsiniz. Tipin altındaki her bileşen bir modelleme kuralı (ModellingRule) taşır: Mandatory bileşen her örnekte bulunmak zorundadır, Optional bileşen bulunabilir. İstemcinin neye kesin güvenebileceğini bu kural belirler.

Ölçüm değerlerinde BaseDataVariableType yerine Data Access bölümündeki AnalogItemType’ı kullanın. Bu tip EURange özelliğini zorunlu, EngineeringUnits ve InstrumentRange özelliklerini isteğe bağlı getirir. Birim değerle birlikte taşınır. “Bu basınç bar mı, kPa mı?” sorusu devreye almada değil, modelde cevaplanmış olur.

Kalıtımı bilinçli kullanın. FillerType ve CapperType ortak bir PackagingMachineType’tan türetilirse durum, sayaç ve alarm yapısı tek yerde tanımlanır; istemci “tüm paketleme makineleri” sorgusunu üst tip üzerinden yapar. Beş altı seviyelik kalıtım zincirleri ise bakımda ve araç uyumluluğunda baş ağrıtır. İki üç seviye çoğu zaman yeter.

Companion Specification ne kazandırır

Companion Specification, belirli bir sektör veya cihaz sınıfı için OPC Foundation ile ilgili sektör kuruluşlarının birlikte yayımladığı standart bilgi modelidir. Amaç, farklı üreticilerin aynı tür makineyi aynı yapıyla sunmasıdır. Sahada en çok karşılaştıklarımız:

Spesifikasyon	Kapsam	Tipik kullanım
OPC UA DI (Devices)	Cihaz tanımlama, üretici, seri no, yazılım sürümü	Diğer birçok spesifikasyonun temeli
OPC UA for Machinery	Makine kimliği, durum, çalışma modu için ortak yapı taşları	Makine envanteri ve temel durum izleme
EUROMAP 77 / 83	Plastik enjeksiyon makineleri ile MES arası veri	Kalıp, çevrim, iş emri bilgisi
PackML (ISA-TR88.00.02 tabanlı)	Paketleme makinesi durum makinesi ve sayaçları	Hat koordinasyonu, OEE verisi

Pratik kazanç istemci tarafındadır: MES, EUROMAP 77 yapısını bir kez öğrenince aynı spesifikasyonu destekleyen farklı üreticilerin makinelerini aynı şekilde okur. Sorun, üreticilerin spesifikasyonun hangi kısmını ve hangi sürümünü desteklediğinin değişken olmasıdır. Şartnameye yalnızca “OPC UA destekli” yazarsanız makine geldiğinde düz tag listesiyle karşılaşabilirsiniz. Şartnamede desteklenecek spesifikasyonu, sürümünü ve beklenen opsiyonel bileşenleri açıkça yazın. Güncel spesifikasyon listesi ve dokümanlar OPC Foundation Online Reference sitesindedir.

NodeSet dosyaları ve modelleme araçları

Bilgi modelleri, OPC UA spesifikasyonunun 6. bölümünde tanımlanan UANodeSet XML şemasıyla dağıtılır; sahadaki adı NodeSet2 dosyasıdır. Companion Specification’lar da kendi NodeSet dosyalarıyla gelir ve sunucuya yüklendiğinde tipler adres alanına eklenir. Aşağıda kendi namespace’inde tanımlanmış basit bir tip ve bileşeninin NodeSet içindeki görünümü var (sadeleştirilmiş: Aliases bölümü ve AnalogItemType’ın zorunlu EURange özelliği gösterilmiyor):

<UAObjectType NodeId="ns=1;i=1001" BrowseName="1:FillerType">
  <DisplayName>FillerType</DisplayName>
  <References>
    <Reference ReferenceType="HasSubtype" IsForward="false">i=58</Reference>
    <Reference ReferenceType="HasComponent">ns=1;i=6001</Reference>
  </References>
</UAObjectType>
<UAVariable NodeId="ns=1;i=6001" BrowseName="1:FillSpeed"
            ParentNodeId="ns=1;i=1001" DataType="Double">
  <DisplayName>FillSpeed</DisplayName>
  <References>
    <Reference ReferenceType="HasTypeDefinition">i=2368</Reference>
    <Reference ReferenceType="HasModellingRule">i=78</Reference>
  </References>
</UAVariable>

i=58 BaseObjectType’ı, i=2368 AnalogItemType’ı, i=78 Mandatory modelleme kuralını gösterir. Bu XML’i elle yazmayın. Tek bir yanlış ParentNodeId, sunucunun modeli sessizce eksik yüklemesine yetiyor. Grafik bir modelleme aracı kullanın: OPC Foundation’ın açık kaynak UA-ModelCompiler’ı, Siemens’in SiOME editörü ve Unified Automation’ın UaModeler’ı yaygın seçeneklerdir. S7-1500 tarafında SiOME ile hazırlanan NodeSet, TIA Portal’da sunucu arayüzü olarak içe aktarılıp PLC değişkenlerine eşlenebilir; diğer üreticilerde de benzer içe aktarma işlevleri bulunur.

NodeSet dosyasını kaynak kod gibi yönetin. Sürüm kontrolünde tutun, her değişiklikte Model öğesindeki Version ve PublicationDate değerlerini güncelleyin, bağımlı olduğu spesifikasyon sürümlerini RequiredModel ile açıkça yazın. Mühendis dizüstüsünde duran tek kopya NodeSet, ilk laptop değişiminde kaybolur.

Bir dolum makinesi için örnek model

Hedef: makinenin kimliğini, anlık durumunu, üretim sayaçlarını ve proses ölçümlerini tek tip altında toplamak. Aşağıdaki yapı OPC UA for Machinery’nin kimlik ve durum yaklaşımını temel alır, proses kısmını kendi namespace’inde tanımlar. Gösterim sadeleştirildi; Machinery spesifikasyonunda durum ve mod yapı taşları ayrı bir yapı taşı klasörü altında da konumlanabilir:

Objects
└── Machines                          (Organizes)
    └── Filler01 : FillerType
        ├── Identification            (Manufacturer, Model, SerialNumber,
        │                              YearOfConstruction, SoftwareRevision)
        ├── MachineryItemState        (Executing / NotExecuting / OutOfService ...)
        ├── MachineryOperationMode    (Processing / Maintenance / Setup)
        ├── Production
        │   ├── GoodCount       : BaseDataVariableType (UInt32)
        │   ├── RejectCount     : BaseDataVariableType (UInt32)
        │   └── CurrentOrderId  : BaseDataVariableType (String)
        ├── Process
        │   ├── FillSpeed       : AnalogItemType (Double, EURange, EngineeringUnits)
        │   └── ProductTemp     : AnalogItemType (Double, EURange, EngineeringUnits)
        └── Methods
            └── LoadRecipe(RecipeId) 

Sahada izlediğimiz sıra şu:

1. Tüketicileri listeleyin: SCADA, historian, MES ve bakım sistemlerinin hangi veriyi hangi sıklıkta istediğini çıkarın. Tüketicisi olmayan veri modele girmez.
2. Standart parçaları seçin: Kimlik ve durum için mevcut spesifikasyon tiplerini kullanın; yalnız eksik kalan proses kısmını kendiniz tanımlayın.
3. Tip ile örneği ayırın: Önce FillerType’ı tanımlayın, sonra her makineyi bu tipin örneği olarak oluşturun. Örneğe özgü ek bileşenleri tipe Optional kuralıyla ekleyin.
4. Veri tiplerini ve birimleri sabitleyin: Sayaçlar için işaretsiz tamsayı, ölçümler için Double; birimleri UNECE kodlarıyla EngineeringUnits içinde verin.
5. Erişim haklarını belirleyin: Hangi değişkenin yazılabilir olduğunu ve metotları kimin çağırabileceğini sunucu rollerine bağlayın.
6. İstemciyle doğrulayın: Genel amaçlı bir OPC UA istemcisiyle tarayın; referansları, tip tanımlarını ve özellikleri tek tek görün. Tarayıcıda görmediğiniz model, istemci için yoktur.

Modeli yayınlayan sunucunun bağlantı güvenliği ayrı bir konudur; sertifika ve security policy tarafı için OPC UA güvenlik ayarları yazısına bakın. Model fabrika geneli bir veri katmanına aktarılacaksa yapıyı baştan Unified Namespace topic tasarımıyla uyumlu kurmak, sonraki adımda eşleme işini ciddi ölçüde azaltır.

Sahada en sık gördüğümüz modelleme hataları

• PLC veri bloğunu birebir kopyalamak: DB yapısı PLC programcısının iç düzenidir. Yardımcı bitler, ara hesaplar, kenar algılama flag’leri modele girmez. Model tüketicinin ihtiyacına göre kurulur.
• Her şeyi Property yapmak: Sürekli değişen ölçüm bileşen değişken olmalı; özellik, değişkeni niteleyen bilgidir. Bazı istemciler özelliklere abonelik açmaz ve değer ekranda donmuş görünür.
• Örnekleri tipten bağımsız elle oluşturmak: Tip bir yerde, örnekler başka yerde elle çizilirse zamanla ikisi birbirinden kopar. Örnekleri tipten türeten araç işlevini kullanın.
• String NodeId’de isim değiştirmek: NodeId istemcilerin kalıcı referansıdır. Görünen adı değiştirmeniz gerekiyorsa DisplayName’e dokunun, NodeId’ye değil.
• Namespace URI’sini sahiplenmemek: Kendi modeliniz için şirketinizin kontrol ettiği bir URI kullanın (http://firma.example/UA/Filler/ gibi) ve sürümler arasında değiştirmeyin.
• Sürümlememek: Zorunlu bir bileşeni kaldırmak geriye dönük uyumsuz değişikliktir. Yeni bileşenleri isteğe bağlı ekleyin; kaldırma şartsa yeni bir model sürümü yayınlayın.

Model sunucu tarafına iş yükler; aynı modeli okuyan istemci sayısı arttıkça bu iş geri döner. Mevcut makinelerinizin hangi Companion Specification’ları desteklediğinin envanteri ve model tasarımı için OPC UA, MQTT ve veri entegrasyonu sayfamıza bakabilirsiniz.

Sık sorulan sorular

OPC UA bilgi modeli için PLC’nin özel bir özelliği gerekir mi?

PLC’nin dahili OPC UA sunucusu özel tip tanımlarını ve NodeSet içe aktarmayı destekliyorsa model doğrudan PLC’de yayınlanır. Desteklemiyorsa model, PLC’den veriyi okuyan harici bir OPC UA sunucusunda veya edge gateway üzerinde kurulur.

Companion Specification destekli bir makinede kendi modelimizi de kullanabilir miyiz?

Evet. Standart tipler makinenin kimlik, durum ve sektöre özgü kısımlarını karşılar; eksik kalan proses verisini kendi namespace’inizde tanımladığınız bileşenlerle eklersiniz. Kural basit: standart tipi değiştirmeyin, alt tip türetin.

NodeSet dosyası ile sunucunun adres alanı farklıysa hangisi geçerlidir?

İstemci için geçerli olan çalışan sunucunun adres alanıdır. NodeSet tasarımın kaynağıdır. Farkı önlemek için sunucu yapılandırmasını her zaman sürüm kontrolündeki NodeSet’ten üretin ve devreye alma sonrası istemciyle tarayarak doğrulayın.

Tag listesiyle çalışan mevcut SCADA bilgi modelinden nasıl faydalanır?

SCADA browse desteklemiyorsa model içindeki değişkenleri yine NodeId ile tek tek okur; mevcut işleyiş bozulmaz. Tip tabanlı keşfin kazancı, browse yapabilen MES, historian veya veri platformu istemcileri bağlandığında ortaya çıkar.