MES üçün OPC UA Client/Server, yoxsa PubSub

MES teqləri tapmalı, vəziyyəti sorğu ilə oxumalı, dəyişiklikləri təsdiqlənmiş şəkildə almalı və bəzən tapşırıq yazmalıdırsa, dəzgah məlumatlarını OPC UA Client/Server ilə ötürmək daha düzgündür. Eyni telemetriya axını bir neçə istehlakçıya lazımdırsa, dəzgahların sayı artırsa və nəşr edən hər biri ilə ayrıca bağlantı saxlamamalıdırsa, PubSub özünü doğruldur.

Rabitə modelinin seçimini «hansı daha sürətlidir» sualına endirmək olmaz. Gecikməni kontroller dövrü, seçmə tezliyi, nəşr intervalı, şlüz növbəsi, broker və MES emalçısı müəyyən edir. Pis məlumat modeli şəbəkədəki bir neçə millisaniyədən daha çox problem yaradar: MES ölçü vahidi, mənbə vaxtı və keyfiyyət göstəricisi olmayan 742 rəqəmini alıb onu etibarlı istehsal kimi yazar.

İşləyən istehsalatda mən çox vaxt hibrid sxem seçirəm. Dəzgah və ya yerli şlüz ünvan məkanı, diaqnostika və əmrlər üçün Client/Server təqdim edir, hazırlanmış istehsal hadisələri isə PubSub ilə brokerə gedir. Ancaq hibrid sxem standart cavab olmamalıdır. Əvvəlcə axınları ayırın, konkret MES imkanlarını yoxlayın və öz şəbəkənizdə sınaq aparın.

Seçim MES əməliyyatlarından başlayır

MES adətən bir neçə fərqli əməliyyat yerinə yetirir və bir nəqliyyat sxemi onların hamısına eyni dərəcədə uyğun gəlmir. Şpindelin cari sürətini toplamaq, hazır detalı qeydə almaq, tapşırıq yükləmək, dayanma səbəbini oxumaq və əmri təsdiqləmək fərqli semantika tələb edir.

Dövri dəyərlər üçün MES-ə mənbə vaxtı, keyfiyyət vəziyyəti və avadanlıq identifikatoru aydın olan axın lazımdır. «Detal hazırdır» hadisəsinə unikal identifikator lazımdır, əks halda təkrar çatdırılma istehsal sayını artırar. Tapşırığın yazılması nəticə cavabı və əmrin düzgün dəzgah və reseptə aid olduğunun yoxlanmasını tələb edir. Diaqnostika üçün mühəndisə əvvəlcədən seçilmiş sahələrdən savayı Browse, Read və ünvan məkanının quruluşu lazımdır.

Client/Server ünvanlı əməliyyatları təbii şəkildə əhatə edir. Müştəri qorunan kanal və sessiya açır, qovşaqları nəzərdən keçirir, atributları oxuyub yazır, metodları çağırır, MonitoredItem yaradır və onları Subscription daxilində birləşdirir. PubSub əvvəlcədən qurulmuş DataSetMessage mesajlarını ötürür. Nəşr edən qəbul edənləri tanımır, abunəçi isə nəşr edəni tanımağa məcbur deyil; onların arasında çatdırılmanı UDP və ya broker yerinə yetirir.

Buradan ilk layihə qərarı çıxır: oxuma interfeysini, hadisə axınını və əmr interfeysini ayırın. MES-ə bir dəqiqəlik aqreqasiyalı OEE kifayətdirsə, hər kontrollerlə birbaşa sessiya artıq ola bilər. Dispetçer MES-dən tapşırığı işə salıb konkret imtina kodunu görməlidirsə, tək PubSub axını sorğu və cavabı əvəz etmir.

Məhsul seçməzdən əvvəl matris qurmaq faydalıdır:

Son sətirdə qalib qəsdən göstərilməyib. Nə OPC UA Session, nə də MQTT QoS MES-in eyni istehsal hadisəsini iki dəfə yazmasına öz-özünə mane olur. Bu, tətbiq müqaviləsinin vəzifəsidir.

Client/Server kontekst və əks əlaqə verir

Sabit rəqəm dəstini almaqla kifayətlənməyib dəzgahın informasiya modelini araşdırmalı və dəyişməli olan MES üçün Client/Server daha uyğundur. OPC UA Part 4 Browse, Read, Write, Call və abunə xidmətlərini müəyyən edir; server əməliyyatlar üzrə StatusCode qaytarır, buna görə inteqrator sükuta əsasən ehtimal etmək əvəzinə paket sorğusundakı qismən xətanı görür.

Buradakı abunə PubSub deyil. Müştəri öz Subscription və MonitoredItem obyektlərini yaradır, seçmə və nəşr intervallarını, dəyişiklik filtrini, növbə ölçüsünü və atma qaydasını təyin edir. Server həmin müştərinin vəziyyətini saxlayır. OPC UA Part 14 müqayisə əlavəsində bu çatdırılmanın buferləmə, təsdiqləmə və təkrar ötürmədən istifadə etdiyini, lakin hər qoşulmuş müştəri üçün server resursu xərclədiyini açıq deyir.

Bu, MES üçün bir neçə cəhətdən rahatdır. Birincisi, müştəri dəzgah işə salınarkən Browse edib məcburi qovşaqların mövcudluğunu yoxlayır. İkincisi, abunədən əvvəl və ya bərpadan sonra ilkin dəyəri oxuya bilir. Üçüncüsü, sequence number alır və məlumat server növbəsində qaldığı müddətdə buraxılmış NotificationMessage mesajlarını yenidən istəyə bilir.

Zəmanətin həddi var. Adi növbələr çox vaxt yaddaşda qalır, ölçüləri sonludur və uzun şəbəkə kəsilməsi və ya serverin yenidən başlaması itkiyə səbəb ola bilər. Durable Subscription spesifikasiyada mövcuddur, ancaq hər iki tərəfin dəstəkləməli olduğu ayrıca profil imkanıdır. Layihədə «OPC UA etibarlıdır» yazıb məsələni bağlamaq olmaz. Konkret server üzrə RevisedQueueSize, yenidən baxılmış nəşr intervalı, lifetime və yenidən başlamadan sonrakı davranışı soruşun.

Client/Server ikitərəfli işi də sadələşdirir. MES arqumentləri olan metodu çağırıb icra kodu ala və ya ayrıca giriş nəzarəti ilə dəyər yaza bilər. Buna baxmayaraq, MES-in texnoloji dəyişənlərə birbaşa yazmasına icazə vermirəm. Əmr ayrılmış qovşağa və ya metoda düşməli, PLC məntiqi rejimi, resepti, bloklamaları və təkrar əmr identifikatorunu yoxlamalıdır.

Bu aydınlığın qiyməti miqyas artanda görünür. Yüz dəzgah yüz qorunan bağlantı, sessiya, MonitoredItem dəsti, keep-alive taymeri və yenidən qoşulma ssenarisi deməkdir. Düzgün ölçülən aqreqasiya serveri üçün bu normal yükdür, amma CNC daxilindəki zəif server üçün ağır ola bilər. Sessiya və abunə elementlərinin həddini pasportdakı OPC UA nişanından çıxarmayın, ölçün.

PubSub dəzgahı qəbul edənlərdən ayırır

PubSub əvvəlcədən müəyyən edilmiş axının yayılmasını daha yaxşı miqyaslayır, çünki nəşr edənin işi abunəçilərin sayı ilə artmır. OPC UA Part 14 üzrə Publisher DataSet yaradır, WriterGroup nəşr rejimini verir, DataSetWriter isə mesajları kodlayır. Subscriber onları aralıq nəqliyyatla alıb DataSetReader ilə uyğunlaşdırır.

UDP UADP variantında dəzgah və ya şlüz ikili mesajı multicast qrupuna və ya konkret ünvana göndərir. Bir paketi MES, arxiv, enerji monitorinqi və analitika qəbul edə bilər. Nəzarət olunan yerli seqmentdə bu, nəşr edən tərəfin yükünü proqnozlaşdırılan edir və hər qəbul edənlə sessiya qurulmasını aradan qaldırır. Lakin adi UDP best effort çatdırılma verir: paket itə, sıra ilə gəlməyə və ya aralıq avadanlığın hərəkətindən sonra təkrarlana bilər.

Broker variantında Publisher UADP və ya JSON-u MQTT brokerinə göndərir, istehlakçılar isə mövzulara abunə olur. Broker istehlakçının həyat dövrünü dəzgahdan ayırır, konfiqurasiyasına görə mesajları saxlaya və bir axını bir neçə sistemə yaya bilir. MES başqa şəbəkə seqmentindədirsə və ya məlumat eyni anda bir neçə tətbiqə lazımdırsa, bu rahatdır.

PubSub abunəçiyə bütün ünvan məkanını sərbəst gəzməyə imkan vermir. Çölə çıxan sahələri DataSet əvvəlcədən müəyyən edir. Mühəndis yeni dayanma səbəbi kodu əlavə edərsə, metaməlumat və istehlakçı müqaviləsi yenilənməlidir. Bu proqnozlaşdırma istismar üçün yaxşıdır, lakin versiya idarəetməsi tələb edir.

Hazır detal hadisəsinin minimal müqaviləsi belə görünə bilər:

{
  "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 MES-ə təkrar mesajı istehsalı bir də yazmadan qəbul etməyə imkan verir, schemaVersion uyğun dəyişiklikləri uyğun olmayanlardan ayırır, sourceTime isə dəzgah vaxtının brokerin qəbul vaxtı ilə əvəzlənməsinə mane olur. quality sahəsi daim Good sətrini daşımamalı, yoxlanılan mənbə vəziyyətindən gəlməlidir.

PubSub-u broker dəbdə olduğu üçün deyil, sabit məlumat müqaviləsi mövcud olduqda seçin. Teqlər hər həftə dəyişirsə və inteqratora daima Browse lazımdırsa, əvvəlcə Client/Server və ya aqreqasiya şlüzü ilə modeli sabitləşdirin.

Gecikməni bütün zəncir üzrə ölçün

Heç bir model qeyd-şərtsiz daha az gecikmə vəd etmir, çünki şəbəkə paketi fiziki siqnaldan MES qeydinə qədər yolun yalnız bir hissəsidir. Siqnal əvvəlcə PLC və ya CNC dövrünə düşür, sonra server və ya Publisher dəyəri seçir, mesajı kodlayıb ötürür, istehlakçı isə nəticəni emal edib qeyd edir.

Client/Server üçün MonitoredItem sampling interval və Subscription publishing interval vacibdir. Spesifikasiya serverə dəstəklənməyən intervalı dəyişməyə icazə verir, buna görə tələb edilən 10 ms faktiki 10 ms demək deyil. Mənbə hər 100 ms yenilənirsə, serveri hər 5 ms sorğulamaq yeni məlumat yaratmır. Yalnız işi artırır.

PubSub üçün WriterGroup PublishingInterval, key frame və delta frame rejimi, paket ölçüsü, şəbəkə interfeysi növbəsi və nəqliyyat vacibdir. UDP UADP broker keçidini aradan qaldıra bilər. MQTT broker və seçilmiş QoS təsdiqlərini əlavə edir, amma ortaq növbə və sabit fan-out sayəsində pis qurulmuş yüzlərlə sessiyadan səmərəli ola bilər. Müqayisə yalnız eyni sahələr və eyni mənbə tezliyi ilə məna daşıyır.

Mən dörd vaxtı ölçürəm: dəzgahdakı t_source, Publisher və ya serverdəki t_publish, inteqrasiya qatının girişindəki t_receive və MES-də təsdiqlənmiş yazıdan sonrakı t_commit. Beləliklə, iki ayrı ölçü görünür:

transport_latency = t_receive - t_publish
end_to_end_latency = t_commit - t_source

Birincisi şəbəkəni və çatdırılmanı göstərir. İkincisi istehsalın hiss etdiyi nəticədir. Medianı, 95-ci və 99-cu percentili, maksimumu, itmiş hadisələrin və dublların payını müqayisə edin. Tək orta göstərici yaddaş təmizləyicisinin fasiləsini, yenidən qoşulmanı və növbənin dolmasını gizlədir.

Saatlar sinxronlaşdırılmalıdır, əks halda mənfi gecikmə yaxşılaşma kimi görünər. Dəzgah vaxtı etibarlı sinxronlaşdıra bilmirsə, ən yaxın şlüzdə vaxt nişanı qoyun və onu hadisə vaxtı deyil, müşahidə vaxtı adlandırın. Təcili dayanma üçün fiziki girişi PLC jurnalı ilə də müqayisə edin, yoxsa sınaq zəncirin yalnız gözəl hissəsini yoxlayacaq.

OEE üçün saniyələr daxilində çatdırılma çox vaxt kifayətdir, amma əmr və ya bloklama üçün başqa hədd ola bilər. MES-i real vaxt konturuna çevirməyin. Oxların hərəkəti, operatorun qorunması və sürətli bloklamalar kontrollerdə qalmalıdır, beləliklə şəbəkə gecikməsi və nasazlığı avadanlığın təhlükəsiz vəziyyətini dəyişməz.

Şəbəkə yükü dəyişikliklərdən və qəbul edənlərdən asılıdır

PubSub həmişə daha az trafik yaratmır, Client/Server də şəbəkəni həmişə yükləmir. Nəticə sahələrin sayından, dəyişmə tezliyindən, kodlamadan, xidməti başlıqlardan, qəbul edənlərin sayından və təkrar çatdırılma siyasətindən asılıdır.

Məhsuldarlıq vədi deyil, hesablama nümunəsi götürək. Yüz dəzgah 200 ədədi dəyəri saniyədə on dəfə ötürür. Təkcə faydalı 8 baytlıq dəyərlər 1,6 Mbit/s edir. Bunlara identifikatorlar, vaxt, StatusCode, OPC UA, IP və nəqliyyat başlıqları əlavə olunur. Xüsusilə hər sahə öz adını daşıyırsa, JSON ikili UADP ilə müqayisədə həcmi xeyli artırır.

Client/Server Subscription yalnız dəyişiklikləri göndərə və bir neçə Notification-u bir mesajda birləşdirə bilər. Deadband analoq siqnal səs-küyünü süzür. MES yeganə istehlakçıdırsa və dəyərlərin çoxu nadir dəyişirsə, belə abunə dövri tam DataSet-dən daha qənaətli ola bilər.

UDP multicast eyni yayım sahəsindəki dinləyicilərin sayından asılı olmayaraq bir NetworkMessage göndərir. Bir neçə qəbul edən olduqda bu böyük üstünlükdür, ancaq multicast kommutatorların, IGMP snooping, VLAN və marşrut qaydalarının qurulmasını tələb edir. Nəzarətsiz yayım axını lazım olmayan portlara daşıya bilər.

MQTT Publisher-dən bir axın alır, sonra broker abunəçilərə ayrı nüsxələr göndərir. Dəzgah yükü proqnozlaşdırılan qalır, amma trafik və resurs yox olmur, brokerə və onun çıxış bağlantılarına keçir. QoS 1 və QoS 2 təsdiqləri və mümkün təkrar ötürməni artırır. Mesaj saxlamaq disk və aydın istifadə müddəti siyasəti tələb edir.

Trafiki üç hissədə ayrıca hesablayın: dəzgahdan şlüzə, şlüzdən brokerə, brokerdən MES-ə. Normal işi və kəsilmədən sonrakı bərpanı yoxlayın. 5 Mbit/s axını rahat ötürən sistem MES bir saat əlçatmaz olduqda, heç kim mesaj ömrünü və bufer dərinliyini məhdudlaşdırmayıbsa, giqabaytlarla növbə yığa bilər.

Etibarlılıq və təhlükəsizlik adla birlikdə gəlmir

Client/Server buraxılmış mesajları tapmaq və NotificationMessage-ləri təkrar ötürmək mexanizmləri verir, amma etibarlılıq yalnız Subscription və növbələr yaşadığı müddətdə qalır. PubSub çatdırılma xüsusiyyətlərini nəqliyyata həvalə edir. Buna görə «şifrələnmiş OPC UA» və «exactly once ilə MQTT» ifadələri texniki tapşırıq üçün çox qısadır.

MQTT üçün OPC UA Part 14 best effort və at most once rejimlərini QoS 0-a, at least once rejimini QoS 1-ə, exactly once rejimini QoS 2-yə uyğunlaşdırır. QoS 1 dubl buraxa bilər. QoS 2 brokerlə mübadiləyə zəmanət verir, amma MES biznes məntiqinin hadisəni dəqiq bir dəfə yazacağına zəmanət vermir. Emalçı istehsalı yazıb təsdiqi saxlamazdan əvvəl dayansa, mesaj qayıda bilər. Unikal eventId və MES bazasındakı unikallıq məhdudiyyəti bu boşluğu QoS adından daha yaxşı bağlayır.

Əlavə mexanizm olmadan UDP çatdırılmanı təsdiqləmir. Tezliklə tam key frame gələcəksə, dövri telemetriyada bir paketin itkisi qəbul edilə bilər. Hazır detal və ya resept dəyişikliyi üçün səssiz itkiyə yol vermək olmaz. Belə hadisələri etibarlı broker nəqliyyatı ilə göndərin və ya təsdiqlənən interfeysdə təkrarlayın.

Client/Server-də SecureChannel müştəri və server arasındakı mesajları qoruyur, tətbiqlər sertifikatlardan istifadə edir, istifadəçi və ya tətbiq isə konfiqurasiyaya görə autentifikasiyadan keçir. Etibarlı siyahıları, sertifikat müddətini, qapalı açarları, söndürülmüş alqoritmləri və girişin ləğvini idarə etmək lazımdır. Operatorun bir dəfə əl ilə «həmişəlik» qəbul etdiyi sertifikat ciddi etibar sxemini rəsmiyyətə çevirir.

MQTT üzərindən PubSub-da TLS brokerə qədər hər hissəni qoruyur. Broker məlumatı görür və etibarlı tərəf sayılmalıdır. Part 14 ayrıca bildirir ki, JSON mesajları MQTT və broker təhlükəsizliyinə söykənir; mesajların ucdan-uca təhlükəsizliyi UADP üçün müəyyən edilib. UADP imzası və şifrələməsi Security Key Service tərəfindən idarə olunan qrup açarlarından istifadə edir. Bu, açar dövriyyəsi, təhlükəsizlik qrupları və açarın vaxtı bitdikdən sonra bərpa işi əlavə edir.

Praktik qayda sadədir: etibar sərhədlərini çəkin və hər sertifikat və ya qrup açarının sahibini göstərin. Sonra bir sertifikatı söndürün, açarı dəyişin, brokeri yenidən başladın və jurnala baxın. Komanda axını kimin bərpa etdiyini və etibar xətasını şəbəkə nasazlığından necə ayırdığını izah edə bilmirsə, təhlükəsizlik hələlik yalnız sxemdədir.

Sertifikatı profil, MES-i interfeys üzrə yoxlayın

«OPC UA supported» yazısı tələb olunan modellə uyğunluğu təsdiqləmir. OPC UA Part 7 Client, Server, Publisher və Subscriber tətbiq profillərini ayırır və konkret funksiyalar və nəqliyyatlar üçün Facet əlavə edir. Sertifikatlı Server Publisher olmaya bilər, sertifikatlı Client isə MQTT UADP qəbul etməyə borclu deyil.

OPC Foundation məhsulları bəyan edilmiş profillər üzrə sınayır və Client, Server, Publisher, Subscriber, PubSub UDP UADP, MQTT JSON və MQTT UADP filtrləri olan kataloq yayımlayır. Satınalma tələbində dəqiq profil, versiya, kodlama, nəqliyyat və funksiyalar yazılmalıdır. Profil siyahısı olmayan sertifikat nişanı inteqrasiya haqqında az məlumat verir.

MES təchizatçısından təqdimat deyil, imkanlar cədvəli istəyin. Konkret cavablar lazımdır:

• MES OPC UA Client kimi işləyir, yoxsa ayrıca konnektor tələb edir?
• Subscription, növbələr, abunənin köçürülməsi və StatusCode dəstəklənir?
• PubSub birbaşa, MQTT konnektoru ilə, yoxsa yalnız inteqrasiya qatının API-si ilə qəbul edilir?
• Hansı kodlamalar, MQTT versiyaları, QoS, mövzular və metaməlumatlar başa düşülür?
• Source timestamp, quality, sequence number və hadisə identifikatoru necə saxlanılır?

MQTT dəstəyi OPC UA PubSub dəstəyi demək deyil. Adi MQTT konnektoru JSON qəbul edib OPC UA NetworkMessage quruluşunu, DataSet metaməlumatını və uyğunluq qaydalarını tanımaya bilər. Əks səhv də olur: komanda PubSub Publisher alır, MES isə yalnız Client/Server Data Access bilir.

Dəzgah tərəfini də yoxlayın. Daxili OPC UA Server sessiyaları, MonitoredItem sayını və minimal intervalı məhdudlaşdıra bilər. Arxitektura MQTT JSON tələb etsə də, Publisher yalnız UDP UADP dəstəkləyə bilər. Şlüz fərqi bağlaya bilər, ancaq özü konfiqurasiya, yeniləmə, rezerv və sertifikatları olan ayrıca aktivə çevrilir.

Hibrid sxem adətən daha dürüstdür

Hibrid müxtəlif dəzgahları olan sexlərin çoxuna uyğundur, çünki hər modelin güclü cəhətini öz yerində saxlayır. Yerli inteqrasiya qatı dəzgahlara OPC UA Client kimi qoşulur, ünvan məkanını gəzir, ölçü vahidlərini və vəziyyətləri normallaşdırır, sonra MES və başqa istehlakçılar üçün sabit istehsal müqaviləsi nəşr edir.

Bu sxem hər köhnə kontrollerin tam PubSub Publisher olmasını tələb etmir. MES-i şəbəkələrarası ekranlardan keçərək yüzlərlə birbaşa sessiya saxlamağa da məcbur etmir. Əmrlər dar avtorizasiya, təsdiq və PLC yoxlaması ilə ayrıca Client/Server kanalı ilə qayıdır. Telemetriya və hadisələr öz saxlama və təkrar emal qaydaları ilə PubSub-dan keçir.

Hibridin qiyməti realdır. Şlüz gecikmə, nasazlıq nöqtəsi və daha bir konfiqurasiya modeli əlavə edir. NodeId ns=4;s=Counter dəyərini quantity sahəsinə çevirirsə, komanda uyğunlaşdırma versiyasını və dəyişiklik jurnalını saxlamalıdır. Dəzgah proqramı dəyişdikdən sonra köhnə NodeId başqa yeri göstərə və ya yoxa çıxa bilər, buna görə qoşulmada müqavilənin avtomatik yoxlanması məcburidir.

Yeni layihədə nəqliyyat seçməzdən əvvəl avadanlığın kanonik identifikatorlarını, ölçü vahidlərini, source timestamp, StatusCode, sxem versiyalarını və idempotentlik qaydalarını müəyyən edin. Sonra çevirmənin harada yaşayacağını qərarlaşdırın: CNC-də, sənaye şlüzündə və ya inteqrasiya xidmətində. Eyni uyğunlaşdırmanı hər istehlakçıya ayrıca yaymayın.

Avadanlıq seçilərkən EAST CNC konkret modeldə mövcud interfeysləri dəqiqləşdirə və rabitə yoxlamasını işəsalma işlərinə daxil edə bilər. Ancaq inteqrasiyanın qəbulu yenə sizin MES, şəbəkə sxemi və teq siyahınıza bağlanmalıdır, çünki protokol adı hazır məlumat mübadiləsini təsvir etmir.

Bir MES on dəzgahı oxuyursa, ünvan məkanları sabitdirsə və birbaşa abunələr sınaqdan ehtiyatla keçirsə, hibrid lazım deyil. O, pis məlumat müqaviləsini də düzəltməyəcək. Əlavə broker qeyri-müəyyən dəyərləri daha çox sistemə daha sürətli yayacaq.

Qəbul sınağı nasazlığı təkrarlamalıdır

Qərarı işlək zənciri ölçən və onu qəsdən pozan qısa sınaqdan sonra vermək olar. Stenddə bir teqin nümayişi yalnız iki məhsulun bir dəfə rəqəm mübadiləsi etdiyini təsdiqləyir.

1. 20-50 real sahə seçin: tez dəyişən dəyərlər, nadir vəziyyətlər, siqnal, sayğac, istehsal hadisəsi və bir icazəli sınaq əmri. Hər sahə üçün tip, vahid, vaxt mənbəyi, icazə verilən gecikmə və pis keyfiyyətdə davranışı göstərin.
2. Client/Server və PubSub-u eyni mənbə tezliyində işə salın. eventId, sequence number, dörd vaxt nişanı, mesaj ölçüsü, itkilər, dubllar və dəzgah və ya şlüz prosessorunun yükünü yazın.
3. Şəbəkəni 30 saniyəlik, sonra qurulmuş növbədən daha uzun müddətə ayırın. Müştərini, Publisher-i, brokeri və MES-i ayrıca yenidən başladın. Hansı dəyərlərin bərpa olunduğunu, hansının itdiyini və istehsalın ikiqat yazılmadığını yoxlayın.
4. İkinci və üçüncü istehlakçını əlavə edin. Client/Server üçün sessiya və MonitoredItem artımına, UDP üçün kommutatorlardakı multicast-a, MQTT üçün brokerin çıxış axını və növbəsinə baxın.
5. Sertifikatı dəyişin, hesab məlumatlarını ləğv edin, DataSet versiyasını dəyişin və bir məcburi qovşağı silin. Sistem naməlum dəyər əvəzinə sıfırla davam etməməli, aydın xəta verməlidir.

Nəticəni mode,machine,event_id,t_source,t_publish,t_receive,t_commit,bytes,status,duplicate sahələri olan CSV-də saxlamaq rahatdır. Eyni fayl gecikmə percentillərini, şəbəkə qiymətini və bərpadan sonrakı düzgünlüyü müqayisə etməyə imkan verir. Qəbul protokoluna Subscription və ya WriterGroup konfiqurasiyasını, proqram versiyalarını, OPC UA profilini və QoS quruluşunu əlavə edin. Bunlarsız sınağı bir il sonra təkrarlamaq mümkün deyil.

MES-ə kontekst, ünvanlı əməliyyatlar və dəzgahdan birbaşa cavab lazımdırsa, bağlantıların sayı sınanmış hədlərə sığırsa, Client/Server seçin. Komanda brokerə və ya sənaye multicast şəbəkəsinə cavabdeh olmağa və DataSet versiyalarını idarə etməyə hazırdırsa, çox istehlakçıya sabit axınlar üçün PubSub seçin. Hər iki xüsusiyyət lazımdırsa, axınları ayırın və sürətli təhlükəsiz konturu dəzgahın daxilində saxlayın. Son qərar kommersiya təklifindəki texnologiya adı ilə deyil, nasazlıq sınağının nəticələri ilə izah edilməlidir.