Tüm yazılar
Programlama İpucu

OPC UA 52 Milyon Cihazda Var Diyor, Bizim İki Cihaz Yine Konuşamadı

OPC Foundation 52 milyon OPC UA cihazı sayıyor; bizdeki iki cihaz aynı standardı taşıyordu yine de el sıkışamadı. Sürüm uyuşmazlığını sertifika metaforuyla ve 40 dakikalık sahada geçen bir vaka ile anlatıyorum.

OPC UA 52 Milyon Cihazda Var Diyor, Bizim İki Cihaz Yine Konuşamadı

52 milyon. OPC Foundation’un sitesindeki rakam bu: 5.200’den fazla tedarikçi, 42.000’den fazla uyumlu ürün, 52 milyondan fazla OPC UA uygulaması. Rakamı okuyup “artık her cihaz her cihazla konuşur” diye düşünmek çok kolay. Ben de öyle düşünüyordum, ta ki geçen ayki projede iki cihaz aynı standardı taşımasına rağmen el sıkışana kadar.

İki cihaz, aynı logo, sıfır bağlantı

Proje basitti: yeni bir enerji izleme sunucusu, eski bir proses PLC’si. İkisinin de kutusunda OPC UA yazıyordu. Sunucudaki client’ı açıp adresi verdim, connect. Hata: “Secure channel negotiation failed.”

İlk tepkim klasikti: “Belki IP’si yanlış.” Değildi. “Belki port.” 4840, standart. “Belki firewall.” Firewall’un üzerinden gittik, hata aynı.

40 dakika. Masada 10 dakikada bulunur, sahada 40 dakika. O 40 dakikanın sonunda bulduğum şey şu: PLC’deki OPC UA stack’i 1.04 sürümünde, sunucudaki client 1.05’i varsayılan olarak kullanıyordu. İkisi de “OPC UA”ydı. İkisi de “uyumlu”ydü. Ama el sıkışma anında konuşamadılar — 1.04’ün desteklemediği bir güvenlik politikası kombinasyonunu client dayatıyordu.

Sürüm, sürücü gibi değil

Burada bir şeyi netleştireyim, çünkü otomasyon tarafında bu kafayı karıştırıyor: OPC UA’da sürüm, otomobilde sürücü koltuğu değil. 1.04’e geçmek için 1.05’i “kurmak” yok; protokolün güvenlik profili ve bilgi modeli katmanları sürümle birlikte davranış değiştiriyor. Yani “ikisi de OPC UA” cümlesi, “ikisi de USB” demek kadar doğru — ama biri USB 2.0, diğeri USB 3.0 ise, takınca çalışmayabilir.

Sertifika meselesi: dijital pasaport

El sıkışmanın ikinci katmanı sertifika. OPC UA, X.509 sertifikalarıyla kimlik doğruluyor. Yani her cihazın bir “dijital pasaportu” var ve karşı taraf onu doğrulamadan güven kurmuyor. Bizdeki vakada sürüm meselesini çözdükten sonra ikinci hata geldi: client’ın certificate store’unda PLC’nin sertifikası “untrusted” konumundaydı.

Bu kısım masada 2 dakikadır: sertifika dosyasını al, store’a ekle, trust et. Sahada 15 dakikadır: sertifikanın PLC’nin kendi klasöründe olduğunu bulmak, onu doğru yere kopyalamak, client’ın cache’ini temizlemek. Toplamda o günün öğle arası gitti.

Pratikte ne yaptım

Artık yeni bir OPC UA bağlantısı kurarken ilk üç soruyu sormadan masa başına oturmuyorum:

  1. İki taraftaki stack sürümü ne? (PLC tarafında sürüm, genelde diagnostic ekranında ya da config aracıyla görünür; “OPC UA var” demek yetmez, “OPC UA 1.04.x” demek lazım.)
  2. Güvenlik politikası ne? (None, Sign, SignAndEncrypt — client’ın dayattığı politika, PLC’nin desteklediği politika kümesinin içinde mi?)
  3. Sertifika store’u nerelerde? (Her iki tarafta da sertifika nerede duruyor, kim trust ediyor, güncelleme sonrası store yenileniyor mu?)

Bu üç soruyu sorarsanız, o 40 dakikanın en az yarısını kurtarırsınız.

52 milyon cihazın ne anlama geldiği

52 milyon rakamı abartı değil, ama “her şey her şeyle konuşur” vaadi de değil. Rakamın doğru okuması şu: OPC UA, fiili standart haline geldi; yani yeni alacağınız cihazın OPC UA destekleme olasılığı çok yüksek. Ama “destekliyor” ile “sizin ortamınızda, sizin güvenlik politikalarınızla, sizin certificate store’unuzda konuşuyor” arasında bir mesafe var. O mesafe, her projede yeniden kapatılacak bir mesafe.

Bir sonraki OPC UA bağlantısında ilk işim: sürüm, politika, sertifika. Bu üçlüyü masada 10 dakikada çözerseniz, sahada 40 dakika kazanırsınız. O 40 dakika, bazen hat dururken geçen 40 dakikadır.