MES uchun OPC UA Client/Server yoki PubSub

MES teglarni topishi, holatni so‘rov bo‘yicha o‘qishi, o‘zgarishlarni tasdiqlangan holda olishi va ba’zan topshiriq yozishi kerak bo‘lsa, stanok ma’lumotlarini OPC UA Client/Server orqali uzatish ma’qul. Bitta telemetriya oqimi bir nechta iste’molchiga kerak bo‘lsa, stanoklar soni ortsa va nashr qiluvchi har bir iste’molchi bilan alohida ulanishni ushlab turmasligi kerak bo‘lsa, PubSub o‘zini oqlaydi.

Aloqa modelini tanlashni «qaysi biri tezroq» degan savolga qisqartirib bo‘lmaydi. Kechikishni kontroller sikli, tanlash chastotasi, nashr oralig‘i, shlyuz navbati, broker va MES ishlovchisi belgilaydi. Yomon ma’lumot modeli tarmoqdagi bir necha millisekunddan ko‘proq muammo tug‘diradi: MES o‘lchov birligi, manba vaqti va sifat belgisisiz 742 raqamini oladi va uni ishonchli ishlab chiqarish natijasi sifatida yozadi.

Ishlab turgan korxonada men ko‘pincha gibrid yechimni tanlayman. Stanok yoki mahalliy shlyuz manzil maydoni, diagnostika va buyruqlar uchun Client/Server beradi, tayyorlangan ishlab chiqarish hodisalari esa PubSub orqali brokerga yuboriladi. Lekin gibrid yechim odatiy javob bo‘lmasligi kerak. Avval oqimlarni ajrating, aniq MES imkoniyatlarini tekshiring va o‘z tarmog‘ingizda sinov o‘tkazing.

Tanlov MES amallaridan boshlanadi

MES odatda bir necha turli amalni bajaradi va bitta transport sxemasi ularning barchasiga bir xil darajada mos kelmaydi. Shpindelning joriy tezligini yig‘ish, tayyor detalni qayd etish, topshiriq yuklash, to‘xtash sababini o‘qish va buyruqni tasdiqlash turli semantikani talab qiladi.

Davriy qiymatlar uchun MESga manba vaqti, sifat holati va uskuna identifikatori tushunarli bo‘lgan oqim kerak. «Detal tayyor» hodisasi noyob identifikatorga ega bo‘lishi kerak, aks holda qayta yetkazish ishlab chiqarish hisobini oshiradi. Topshiriq yozish natija javobini va buyruq to‘g‘ri stanok hamda retseptga tegishli ekanini tekshirishni talab qiladi. Diagnostika uchun muhandisga oldindan tanlangan maydonlargina emas, Browse, Read va manzil maydoni tuzilmasi kerak.

Client/Server manzilli amallarni tabiiy qamrab oladi. Mijoz himoyalangan kanal va seans ochadi, tugunlarni ko‘radi, atributlarni o‘qiydi va yozadi, metodlarni chaqiradi, MonitoredItem yaratadi va ularni Subscription ichiga birlashtiradi. PubSub oldindan sozlangan DataSetMessage xabarlarini uzatadi. Nashr qiluvchi qabul qiluvchilarni bilmaydi, obunachi esa nashr qiluvchini bilishi shart emas; ular orasida UDP yoki broker yetkazishni bajaradi.

Bundan birinchi loyiha qarori kelib chiqadi: o‘qish interfeysi, hodisalar oqimi va buyruqlar interfeysini ajrating. Agar MESga bir daqiqalik yig‘ish bilan OEE kerak bo‘lsa, har bir kontrollerga to‘g‘ridan-to‘g‘ri seans ortiqcha bo‘lishi mumkin. Agar dispetcher MESdan topshiriqni ishga tushirib, muayyan rad etish kodini ko‘rishi kerak bo‘lsa, faqat PubSub oqimi so‘rov va javob o‘rnini bosmaydi.

Mahsulot tanlashdan oldin matritsa tuzish foydali:

Oxirgi qatorda g‘olib ataylab ko‘rsatilmagan. OPC UA Session ham, MQTT QoS ham MES bitta ishlab chiqarish hodisasini ikki marta o‘tkazishiga o‘z-o‘zidan to‘sqinlik qilmaydi. Bu ilova shartnomasining vazifasi.

Client/Server kontekst va javob beradi

Faqat qat’iy raqamlar to‘plamini olish emas, stanokning axborot modelini o‘rganish va o‘zgartirish kerak bo‘lgan MES uchun Client/Server mosroq. OPC UA Part 4 Browse, Read, Write, Call va obuna xizmatlarini belgilaydi; server har bir amal uchun StatusCode qaytaradi, shuning uchun integrator sukutga qarab taxmin qilish o‘rniga paketli so‘rovdagi qisman xatoni ko‘radi.

Bu yerdagi obuna PubSub emas. Mijoz o‘z Subscription va MonitoredItem obyektlarini yaratadi, tanlash va nashr oralig‘i, o‘zgarish filtri, navbat hajmi hamda tashlab yuborish qoidasini belgilaydi. Server shu mijoz holatini saqlaydi. OPC UA Part 14 taqqoslash ilovasida bunday yetkazish buferlash, tasdiqlash va qayta uzatishdan foydalanishini, lekin har bir ulangan mijoz uchun server resursini sarflashini ochiq aytadi.

Bu MES uchun bir necha jihatdan qulay. Birinchidan, mijoz stanokni ishga tushirishda Browse bajarib, majburiy tugunlar borligini tekshiradi. Ikkinchidan, obunadan oldin yoki tiklanishdan keyin boshlang‘ich qiymatni o‘qiydi. Uchinchidan, sequence number oladi va ma’lumot server navbatida turgan paytda o‘tkazib yuborilgan NotificationMessage xabarlarini qayta so‘raydi.

Kafolatning chegarasi bor. Oddiy navbatlar ko‘pincha xotirada turadi, hajmi cheklangan, uzoq tarmoq uzilishi yoki server qayta ishga tushishi ma’lumot yo‘qotishiga olib kelishi mumkin. Durable Subscription spetsifikatsiyada bor, lekin bu ikkala tomon ham qo‘llashi kerak bo‘lgan alohida profil imkoniyati. Loyihaga «OPC UA ishonchli» deb yozib, masalani yopib bo‘lmaydi. Aniq serverdan RevisedQueueSize, qayta ko‘rilgan nashr oralig‘i, lifetime va qayta ishga tushgandan keyingi xatti-harakatni so‘rang.

Client/Server ikki tomonlama ishni ham soddalashtiradi. MES argumentli metodni chaqirib, bajarilish kodini olishi yoki alohida kirish nazorati bilan qiymat yozishi mumkin. Shunga qaramay, MESga texnologik o‘zgaruvchilarga to‘g‘ridan-to‘g‘ri yozishga ruxsat bermayman. Buyruq maxsus tugun yoki metodga tushishi, PLC mantiqi esa rejim, retsept, blokirovkalar va takrorlangan buyruq identifikatorini tekshirishi kerak.

Bu aniqlikning narxi ko‘lam ortganda ko‘rinadi. Yuzta stanok yuzta himoyalangan ulanish, seans, MonitoredItem to‘plami, keep-alive taymeri va qayta ulanish ssenariysi degani. To‘g‘ri tanlangan yig‘uvchi server uchun bu odatiy yuk, lekin CNC ichidagi kuchsiz server uchun og‘ir bo‘lishi mumkin. Seanslar va obuna elementlari chegarasini pasportdagi OPC UA belgisidan kelib chiqib emas, o‘lchab aniqlang.

PubSub stanokni qabul qiluvchilardan ajratadi

PubSub oldindan belgilangan oqimni yaxshiroq ko‘lamlaydi, chunki nashr qiluvchi ishi obunachilar soni bilan ortmaydi. OPC UA Part 14 bo‘yicha Publisher DataSet tuzadi, WriterGroup nashr rejimini belgilaydi, DataSetWriter esa xabarlarni kodlaydi. Subscriber ularni oraliq transport orqali oladi va DataSetReader bilan moslaydi.

UDP UADP variantida stanok yoki shlyuz ikkilik xabarni multicast guruhiga yoki aniq manzilga jo‘natadi. Bitta paketni MES, arxiv, energiya monitoringi va tahlil tizimi olishi mumkin. Boshqariladigan mahalliy segmentda bu nashr qiluvchi yukini oldindan bilish imkonini beradi va har bir qabul qiluvchi bilan seans ochishni yo‘qotadi. Lekin oddiy UDP best effort asosida yetkazadi: paket yo‘qolishi, tartibsiz kelishi yoki oraliq uskuna harakatidan so‘ng takrorlanishi mumkin.

Brokerli variantda Publisher UADP yoki JSONni MQTT brokeriga yuboradi, iste’molchilar esa mavzularga obuna bo‘ladi. Broker iste’molchi hayot siklini stanokdan ajratadi, sozlamasiga ko‘ra xabarlarni saqlashi va bitta oqimni bir necha tizimga tarqatishi mumkin. MES boshqa tarmoq segmentida bo‘lsa yoki ma’lumot bir vaqtning o‘zida bir necha ilovaga kerak bo‘lsa, bu qulay.

PubSub obunachiga butun manzil maydonini erkin ko‘rishga yo‘l bermaydi. Tashqariga chiqadigan maydonlarni DataSet oldindan belgilaydi. Muhandis yangi to‘xtash sababi kodini qo‘shsa, metama’lumot va iste’molchi shartnomasi yangilanishi kerak. Bunday oldindan ma’lumlik ekspluatatsiya uchun yaxshi, ammo versiyalarni boshqarishni talab qiladi.

Tayyor detal hodisasining eng kichik shartnomasi quyidagicha ko‘rinishi mumkin:

{
  "schemaVersion": 3,
  "machineId": "LINE2-LATHE04",
  "eventId": "LINE2-LATHE04-184467",
  "eventType": "PartCompleted",
  "sourceTime": "2026-07-26T14:08:31.482Z",
  "partNo": "A17-442",
  "quantity": 1,
  "quality": "Good"
}

eventId MESga takroriy xabarni ishlab chiqarishni qayta yozmasdan qabul qilish imkonini beradi, schemaVersion mos va nomos o‘zgarishlarni ajratadi, sourceTime esa stanok vaqtini broker qabul qilgan vaqt bilan almashtirishga yo‘l qo‘ymaydi. quality maydoni har doim Good satrini saqlamasdan, tekshiriladigan manba holatidan kelishi kerak.

PubSubni broker urf bo‘lgani uchun emas, barqaror ma’lumot shartnomasi mavjud bo‘lganda tanlang. Teglar tarkibi har hafta o‘zgarib, integratorga doim Browse kerak bo‘lsa, avval Client/Server yoki yig‘uvchi shlyuz orqali modelni barqarorlashtiring.

Kechikishni butun zanjir bo‘ylab o‘lchang

Hech bir model izohsiz past kechikishni va’da qilmaydi, chunki tarmoq paketi fizik signaldan MES yozuvigacha bo‘lgan yo‘lning faqat bir qismi. Signal avval PLC yoki CNC sikliga tushadi, keyin server yoki Publisher qiymatni tanlaydi, xabarni kodlaydi va uzatadi, iste’molchi esa natijani tahlil qilib yozadi.

Client/Server uchun MonitoredItem sampling interval va Subscription publishing interval muhim. Spetsifikatsiya serverga qo‘llanmaydigan intervalni qayta ko‘rishga ruxsat beradi, shuning uchun so‘ralgan 10 ms amaldagi 10 ms degani emas. Manba har 100 ms yangilansa, serverni har 5 ms so‘rash yangi ma’lumot yaratmaydi. Faqat ishni oshiradi.

PubSub uchun WriterGroup PublishingInterval, key frame va delta frame tartibi, paket hajmi, tarmoq interfeysi navbati va transport muhim. UDP UADP broker bosqichini olib tashlashi mumkin. MQTT broker va tanlangan QoS tasdiqlarini qo‘shadi, ammo umumiy navbat hamda barqaror fan-out bilan yomon sozlangan yuzlab seanslardan samaraliroq ishlashi mumkin. Faqat bir xil maydonlar va manba chastotasini solishtirish ma’noli.

Men to‘rtta vaqtni o‘lchayman: stanokdagi t_source, Publisher yoki serverdagi t_publish, integratsiya qatlami kirishidagi t_receive va MESga tasdiqlangan yozuvdan keyingi t_commit. Shunda ikki alohida qiymat ko‘rinadi:

transport_latency = t_receive - t_publish
end_to_end_latency = t_commit - t_source

Birinchisi tarmoq va yetkazishni ko‘rsatadi. Ikkinchisi ishlab chiqarish sezadigan natijani ko‘rsatadi. Mediana, 95 va 99 protsentil, maksimum, yo‘qolgan hodisalar va dubl ulushini solishtiring. Bitta o‘rtacha qiymat xotira tozalash pauzasi, qayta ulanish va navbat to‘lishini yashiradi.

Soatlar sinxronlangan bo‘lishi kerak, aks holda manfiy kechikish yaxshilanishdek ko‘rinadi. Stanok vaqtni ishonchli sinxronlay olmasa, eng yaqin shlyuzda vaqt belgisi qo‘ying va uni hodisa vaqti emas, kuzatish vaqti deb atang. Favqulodda to‘xtash uchun fizik kirish va PLC jurnalini ham solishtiring, aks holda sinov zanjirning faqat chiroyli qismini tekshiradi.

OEE uchun soniyalar ichidagi yetkazish ko‘pincha yetarli, lekin buyruq yoki blokirovka boshqa chegaraga ega bo‘lishi mumkin. MESni real vaqt konturiga aylantirmang. O‘qlar harakati, operator himoyasi va tez blokirovkalar kontrollerda qolishi kerak, shunda tarmoq kechikishi yoki nosozligi uskunaning xavfsiz holatini o‘zgartirmaydi.

Tarmoq yuki o‘zgarish va qabul qiluvchilarga bog‘liq

PubSub har doim kam trafik yaratmaydi, Client/Server ham tarmoqni har doim ortiqcha yuklamaydi. Natija maydonlar soni, o‘zgarish chastotasi, kodlash, xizmat sarlavhalari, qabul qiluvchilar soni va qayta yetkazish siyosatiga bog‘liq.

Unumdorlik va’dasi emas, hisobiy misolni olaylik. Yuzta stanok 200 ta raqamli qiymatni soniyasiga o‘n marta uzatadi. Faqat foydali 8 baytlik qiymatlar 1,6 Mbit/s beradi. Bunga identifikatorlar, vaqt, StatusCode, OPC UA, IP va transport sarlavhalari qo‘shiladi. Ayniqsa har bir maydon o‘z nomini olib yursa, JSON ikkilik UADPga nisbatan hajmni ancha oshiradi.

Client/Server Subscription faqat o‘zgarishlarni yuborib, bir nechta Notificationni bitta xabarga joylay oladi. Deadband analog signal shovqinini filtrlab tashlaydi. MES yagona iste’molchi bo‘lsa va ko‘pchilik qiymatlar kam o‘zgarsa, bunday obuna davriy to‘liq DataSetdan tejamliroq bo‘lishi mumkin.

UDP multicast bir tarqatish domenidagi tinglovchilar sonidan qat’i nazar bitta NetworkMessage yuboradi. Bir nechta qabul qiluvchida bu katta ustunlik, ammo multicast kommutatorlar, IGMP snooping, VLAN va marshrutlash qoidalarini sozlashni talab qiladi. Nazoratsiz tarqatish oqimni kerak bo‘lmagan portlarga olib borishi mumkin.

MQTT Publisherdan bitta oqimni oladi, keyin broker obunachilarga alohida nusxalar yuboradi. Stanok yuki oldindan ma’lum bo‘lib qoladi, ammo trafik va resurs yo‘qolmaydi, broker va uning chiqish ulanishlariga ko‘chadi. QoS 1 va QoS 2 tasdiqlar va ehtimoliy qayta uzatishni qo‘shadi. Xabarlarni saqlash uchun disk va aniq amal qilish muddati siyosati kerak.

Trafikni uch bo‘lakda alohida hisoblang: stanokdan shlyuzga, shlyuzdan brokerga va brokerdan MESga. Oddiy ishni va uzilishdan keyingi tiklanishni tekshiring. 5 Mbit/sni bemalol o‘tkazadigan tizim MES bir soat ishlamasa, hech kim xabar muddati va bufer chuqurligini cheklamagan bo‘lsa, gigabaytlab navbat to‘plashi mumkin.

Ishonchlilik va xavfsizlik nom bilan birga kelmaydi

Client/Server o‘tkazib yuborishni aniqlash va NotificationMessageni qayta uzatish mexanizmlarini beradi, lekin ishonchlilik Subscription va navbatlar saqlangan paytdagina davom etadi. PubSub yetkazish xususiyatlarini transportga topshiradi. Shu sababli «shifrlangan OPC UA» va «exactly once bilan MQTT» iboralari texnik topshiriq uchun juda qisqa.

MQTT uchun OPC UA Part 14 best effort va at most once rejimlarini QoS 0ga, at least once rejimini QoS 1ga, exactly once rejimini QoS 2ga moslaydi. QoS 1 dublga ruxsat beradi. QoS 2 broker bilan almashishni kafolatlaydi, lekin MES biznes mantig‘i hodisani aynan bir marta yozishini kafolatlamaydi. Ishlovchi mahsulotni yozib, tasdiqni saqlashdan oldin yiqilsa, xabar qaytishi mumkin. Noyob eventId va MES ma’lumotlar bazasidagi noyoblik cheklovi bu bo‘shliqni QoS nomidan yaxshiroq yopadi.

Qo‘shimcha mexanizmsiz UDP yetkazishni tasdiqlamaydi. Tez orada to‘liq key frame kelsa, davriy telemetriya uchun bitta paket yo‘qolishi maqbul bo‘lishi mumkin. Tayyor detal yoki retsept o‘zgarishi uchun jim yo‘qolishga yo‘l qo‘yib bo‘lmaydi. Bunday hodisalarni ishonchli broker transporti orqali yuboring yoki tasdiqlanadigan interfeysda takrorlang.

Client/Serverda SecureChannel mijoz va server orasidagi xabarlarni himoya qiladi, ilovalar sertifikatdan foydalanadi, foydalanuvchi yoki ilova sozlamaga ko‘ra autentifikatsiyadan o‘tadi. Ishonchli ro‘yxatlar, sertifikat muddati, yopiq kalitlar, o‘chirilgan algoritmlar va kirishni bekor qilishni boshqarish kerak. Operator bir marta qo‘lda «abadiy» qabul qilgan sertifikat qat’iy ishonch sxemasini rasmiyatchilikka aylantiradi.

MQTT orqali PubSubda TLS brokerga boradigan har bir bo‘lakni himoya qiladi. Broker ma’lumotni ko‘radi va ishonchli tomon deb qaralishi kerak. Part 14 JSON xabarlari MQTT va broker xavfsizligiga tayanishini alohida ogohlantiradi; xabarlarning boshidan oxirigacha xavfsizligi UADP uchun belgilangan. UADP imzosi va shifrlashi Security Key Service boshqaradigan guruh kalitlarini qo‘llaydi. Bu kalit aylanishi, xavfsizlik guruhlari va kalit muddati tugagach tiklanishni qo‘shadi.

Amaliy qoida oddiy: ishonch chegaralarini chizing va har bir sertifikat yoki guruh kaliti egasini belgilang. Keyin bitta sertifikatni o‘chiring, kalitni almashtiring, brokerni qayta ishga tushiring va jurnalni tekshiring. Jamoa oqimni kim tiklashi va ishonch xatosini tarmoq uzilishidan qanday ajratishini tushuntira olmasa, xavfsizlik hozircha faqat sxemada bor.

Sertifikatni profil, MESni interfeys bo‘yicha tekshiring

«OPC UA supported» yozuvi kerakli model bilan moslikni isbotlamaydi. OPC UA Part 7 Client, Server, Publisher va Subscriber ilova profillarini ajratadi va aniq funksiya hamda transportlar uchun Facet qo‘shadi. Sertifikatlangan Server Publisher bo‘lmasligi mumkin, sertifikatlangan Client esa MQTT UADP qabul qilishi shart emas.

OPC Foundation mahsulotlarni e’lon qilingan profillar bo‘yicha sinaydi va Client, Server, Publisher, Subscriber, PubSub UDP UADP, MQTT JSON hamda MQTT UADP bo‘yicha filtrlash mumkin bo‘lgan katalogni nashr qiladi. Xarid talabida aniq profil, versiya, kodlash, transport va funksiyalar yozilishi kerak. Profil ro‘yxatisiz sertifikat belgisi integratsiya haqida kam ma’lumot beradi.

MES yetkazib beruvchisidan taqdimot emas, imkoniyatlar jadvalini so‘rang. Aniq javoblar kerak:

• MES OPC UA Client sifatida ishlaydimi yoki alohida konnektor kerakmi?
• U Subscription, navbatlar, obunani ko‘chirish va StatusCodeni qo‘llaydimi?
• PubSubni to‘g‘ridan-to‘g‘ri, MQTT konnektori orqali yoki faqat integratsiya qatlami API orqali qabul qiladimi?
• Qaysi kodlashlar, MQTT versiyalari, QoS, mavzular va metama’lumotlarni tushunadi?
• Source timestamp, quality, sequence number va hodisa identifikatorini qanday saqlaydi?

MQTTni qo‘llash OPC UA PubSubni qo‘llash degani emas. Oddiy MQTT konnektori JSONni qabul qilishi, ammo OPC UA NetworkMessage tuzilmasi, DataSet metama’lumoti va moslik qoidalarini tanimasligi mumkin. Teskari xato ham uchraydi: jamoa PubSub Publisher sotib oladi, MES esa faqat Client/Server Data Access bilan ishlaydi.

Stanok tomonini ham tekshiring. Ichki OPC UA Server seanslar, MonitoredItem va eng kichik intervalni cheklashi mumkin. Arxitektura MQTT JSON talab qilsa ham, Publisher faqat UDP UADPni qo‘llashi mumkin. Shlyuz farqni yopadi, lekin u konfiguratsiya, yangilash, zaxiralash va sertifikatlarga ega alohida aktivga aylanadi.

Gibrid sxema ko‘pincha rostgo‘yroq

Gibrid sxema turli stanokli sexlarning ko‘pchiligiga mos, chunki har bir modelning kuchli tomonini o‘z joyida qoldiradi. Mahalliy integratsiya qatlami stanoklarga OPC UA Client sifatida ulanadi, manzil maydonini ko‘radi, birlik va holatlarni me’yorlashtiradi, keyin MES va boshqa iste’molchilar uchun barqaror ishlab chiqarish shartnomasini nashr qiladi.

Bu sxema har bir eski kontrollerning to‘liq PubSub Publisher bo‘lishini talab qilmaydi. Shuningdek, MESni tarmoqlararo ekranlar orqali yuzlab to‘g‘ridan-to‘g‘ri seans ushlashga majbur qilmaydi. Buyruqlar tor avtorizatsiya, tasdiq va PLC tekshiruvi bilan alohida Client/Server kanalidan qaytadi. Telemetriya va hodisalar o‘z saqlash hamda takroriy ishlov qoidalari bilan PubSub orqali o‘tadi.

Gibridning narxi haqiqiy. Shlyuz kechikish, nosozlik nuqtasi va yana bitta konfiguratsiya modelini qo‘shadi. Agar u NodeId ns=4;s=Counterni quantity maydoniga aylantirsa, jamoa moslash versiyasi va o‘zgarish jurnalini saqlashi shart. Stanok dasturi almashtirilgach, eski NodeId boshqa joyni ko‘rsatishi yoki yo‘qolishi mumkin, shu sabab ulanishda shartnomani avtomatik tekshirish majburiy.

Yangi loyiha uchun transport tanlashdan oldin uskunaning kanonik identifikatorlari, birliklar, source timestamp, StatusCode, sxema versiyalari va idempotentlik qoidalarini belgilang. So‘ng o‘zgartirish qayerda yashashini hal qiling: CNCda, sanoat shlyuzida yoki integratsiya servisida. Bir xil moslashni har bir iste’molchiga tarqatmang.

Uskuna tanlashda EAST CNC aniq modeldagi mavjud interfeyslarni aniqlashtirib, aloqa tekshiruvini ishga tushirish ishlariga qo‘shishi mumkin. Ammo integratsiyani qabul qilish sizning MES, tarmoq sxemangiz va teglar ro‘yxatingizga bog‘lanishi kerak, chunki protokol nomi tayyor almashinuvni tasvirlamaydi.

Bitta MES o‘nta stanokni o‘qisa, manzil maydonlari barqaror bo‘lsa va to‘g‘ridan-to‘g‘ri obunalar sinovdan zaxira bilan o‘tsa, gibrid kerak emas. U yomon ma’lumot shartnomasini ham tuzatmaydi. Qo‘shimcha broker noaniq qiymatlarni ko‘proq tizimga tezroq tarqatadi.

Qabul sinovi nosozlikni takrorlashi kerak

Qarorni ishchi zanjirni o‘lchaydigan va uni ataylab buzadigan qisqa sinovdan so‘ng qabul qilish mumkin. Stendda bitta tegni ko‘rsatish ikki mahsulot bir marta raqam almashganini tasdiqlaydi, xolos.

1. 20-50 ta haqiqiy maydonni belgilang: tez o‘zgaradigan qiymatlar, kam uchraydigan holatlar, signal, hisoblagich, ishlab chiqarish hodisasi va bitta ruxsat etilgan sinov buyrug‘i. Har bir maydon uchun tur, birlik, vaqt manbasi, ruxsat etilgan kechikish va sifat yomon bo‘lgandagi xatti-harakatni bering.
2. Client/Server va PubSubni manbaning bir xil chastotasida ishga tushiring. eventId, sequence number, to‘rtta vaqt belgisi, xabar hajmi, yo‘qotish, dubl va stanok yoki shlyuz protsessori yukini yozing.
3. Tarmoqni 30 soniyaga, keyin sozlangan navbatdan uzoqroq vaqtga uzing. Mijoz, Publisher, broker va MESni alohida qayta ishga tushiring. Qaysi qiymatlar tiklanganini, qaysilari yo‘qolganini va ishlab chiqarish ikki marta yozilmaganini tekshiring.
4. Ikkinchi va uchinchi iste’molchini qo‘shing. Client/Server uchun seans va MonitoredItem o‘sishini, UDP uchun kommutatorlardagi multicastni, MQTT uchun broker chiqish oqimi va navbatini kuzating.
5. Sertifikatni almashtiring, hisob ma’lumotlarini bekor qiling, DataSet versiyasini o‘zgartiring va bitta majburiy tugunni o‘chiring. Tizim noma’lum qiymat o‘rniga nol bilan davom etmasdan, tushunarli xato berishi kerak.

Natijani mode,machine,event_id,t_source,t_publish,t_receive,t_commit,bytes,status,duplicate maydonlari bor CSVda saqlash qulay. Bitta fayl kechikish protsentillari, tarmoq narxi va tiklanishdan keyingi to‘g‘rilikni solishtirishga yetadi. Qabul bayonnomasiga Subscription yoki WriterGroup konfiguratsiyasi, dastur versiyalari, OPC UA profili va QoS sozlamalarini qo‘shing. Ularsiz bir yildan keyin sinovni takrorlab bo‘lmaydi.

MESga kontekst, manzilli amallar va stanokdan to‘g‘ridan-to‘g‘ri javob kerak bo‘lsa hamda ulanishlar soni sinalgan chegaraga sig‘sa, Client/Serverni tanlang. Jamoa broker yoki sanoat multicast tarmog‘ini boshqarishga va DataSet versiyalarini yuritishga tayyor bo‘lsa, ko‘p iste’molchiga barqaror oqimlar uchun PubSubni tanlang. Ikkala xususiyat ham kerak bo‘lsa, oqimlarni ajrating va tez xavfsiz konturni stanok ichida qoldiring. Yakuniy qaror tijorat taklifidagi texnologiya nomi bilan emas, nosozlik sinovi natijalari bilan tushuntirilishi kerak.