MES үчүн OPC UA Client/Server же PubSub

MES тегдерди таап, абалды суроо боюнча окуп, өзгөрүүлөрдү ырастоо менен алып жана кээде тапшырмаларды жазышы керек болсо, станок маалыматтарын OPC UA Client/Server аркылуу берүү туура. Бир эле телеметрия агымы бир нече керектөөчүгө керек болуп, станоктордун саны өссө жана жарыялоочу алардын ар бири менен өзүнчө байланыш кармабашы керек болсо, PubSub ылайыктуу.

Байланыш моделин тандоону «кайсынысы тез» деген суроого гана такап коюуга болбойт. Кечигүүгө контроллердин цикли, тандоо жыштыгы, жарыялоо аралыгы, шлюздун кезеги, брокер жана MES иштетүүчүсү таасир этет. Начар маалымат модели тармактагы бир нече миллисекундга караганда көбүрөөк маселе жаратат: MES өлчөө бирдиги, булак убактысы жана сапат белгиси жок 742 санын алып, аны ишенимдүү өндүрүш көлөмү катары жазат.

Иштеп жаткан өндүрүштө мен көбүнчө аралаш схеманы тандайм. Станок же жергиликтүү шлюз дарек мейкиндиги, диагностика жана буйруктар үчүн Client/Server берет, ал эми даярдалган өндүрүш окуялары PubSub аркылуу брокерге кетет. Бирок аралаш схема демейки жооп болбошу керек. Адегенде агымдарды бөлүп, конкреттүү MES мүмкүнчүлүгүн текшерип, өз тармагыңызда сыноо жүргүзүңүз.

Тандоо MES операцияларынан башталат

MES адатта бир нече башка операция аткарат, бир транспорттук схема алардын баарына бирдей ылайык боло бербейт. Шпинделдин учурдагы ылдамдыгын чогултуу, даяр тетикти каттоо, тапшырма жүктөө, токтоонун себебин окуу жана буйрукту ырастоо ар башка семантиканы талап кылат.

Мезгилдүү маанилер үчүн MESке булак убактысы, сапат абалы жана жабдуунун идентификатору түшүнүктүү болгон агым керек. «Тетик даяр» окуясына уникалдуу идентификатор зарыл, болбосо кайталап жеткирүү өндүрүш эсептегичин көбөйтөт. Тапшырманы жазганда натыйжа тууралуу жооп жана буйруктун туура станок менен рецептке тиешелүү экенин текшерүү талап кылынат. Диагностика үчүн инженерге алдын ала тандалган талаалар гана эмес, Browse, Read жана дарек мейкиндигинин түзүлүшү керек.

Client/Server даректүү операцияларды табигый түрдө камтыйт. Кардар корголгон канал менен сессия ачат, түйүндөрдү карайт, атрибуттарды окуп-жазат, методдорду чакырат, MonitoredItem түзөт жана аларды Subscription ичине бириктирет. PubSub алдын ала жөндөлгөн DataSetMessage билдирүүлөрүн берет. Жарыялоочу алуучуларды билбейт, жазылуучу да жарыялоочуну билүүгө милдеттүү эмес; алардын ортосунда жеткирүүнү UDP же брокер аткарат.

Мындан биринчи долбоордук чечим чыгат: окуу интерфейсин, окуялар агымын жана буйруктар интерфейсин бөлүңүз. MESке мүнөттүк топтоштуруусу бар OEE гана керек болсо, ар бир контроллер менен түз сессия ашыкча болушу мүмкүн. Диспетчер MESтен тапшырманы иштетип, баш тартуунун конкреттүү кодун көрүшү керек болсо, PubSub агымы суроо менен жоопту алмаштырбайт.

Продукт тандоого чейин матрица түзүү пайдалуу:

Акыркы сапта жеңүүчү атайын көрсөтүлгөн жок. OPC UA Session да, MQTT QoS да MESтин бир өндүрүш окуясын эки жолу өткөрүшүнө өз алдынча тоскоол болбойт. Бул колдонмо келишиминин милдети.

Client/Server контекст жана кайтарым байланыш берет

Туруктуу сандар топтомун алуу менен чектелбей, станоктун маалымат моделин изилдеп жана өзгөртүшү керек болгон MES үчүн Client/Server ылайыктуураак. OPC UA Part 4 Browse, Read, Write, Call жана жазылуу кызматтарын аныктайт; сервер операциялар боюнча StatusCode кайтарат, ошондуктан интегратор үнсүздүккө карап божомолдобой, топтук суроодогу жарым-жартылай катаны көрөт.

Бул жердеги жазылуу PubSub эмес. Кардар өзүнүн Subscription жана MonitoredItem объекттерин түзүп, тандоо менен жарыялоо аралыгын, өзгөрүү чыпкасын, кезектин көлөмүн жана өчүрүү эрежесин берет. Сервер ошол кардардын абалын сактайт. OPC UA Part 14 салыштыруу тиркемесинде мындай жеткирүү буферлөө, ырастоо жана кайра жөнөтүүнү колдонорун, бирок ар бир туташкан кардарга сервер ресурсун сарптарын ачык айтат.

Бул MES үчүн бир нече жагынан ыңгайлуу. Биринчиден, кардар станокту ишке киргизүүдө Browse аткарып, милдеттүү түйүндөрдүн бар экенин текшерет. Экинчиден, жазылуудан мурда же калыбына келгенден кийин баштапкы маанини окуйт. Үчүнчүдөн, sequence number алып, маалымат сервердин кезегинде турганда өткөрүп жиберилген NotificationMessage билдирүүлөрүн кайра сурай алат.

Кепилдиктин чеги бар. Кадимки кезектер көбүнчө эстутумда турат, көлөмү чектелүү, тармактын узак үзүлүшү же сервердин кайра иштеши маалымат жоготууга алып келиши мүмкүн. Durable Subscription спецификацияда бар, бирок бул эки тарап тең колдошу керек болгон өзүнчө профиль мүмкүнчүлүгү. Долбоорго «OPC UA ишенимдүү» деп жазып, маселени жабууга болбойт. Конкреттүү серверден RevisedQueueSize, кайра каралган жарыялоо аралыгы, lifetime жана кайра иштегенден кийинки жүрүм-турумду сураңыз.

Client/Server эки тараптуу ишти да жөнөкөйлөтөт. MES аргументтери бар методду чакырып, аткаруу кодун алат же өзүнчө кирүү көзөмөлү менен маани жаза алат. Ошентсе да MESке технологиялык өзгөрмөлөргө түз жазууга уруксат бербейм. Буйрук атайын түйүнгө же методго түшүшү керек, ал эми PLC логикасы режимди, рецептти, блокировкаларды жана кайталанган буйруктун идентификаторун текшерет.

Бул тактыктын баасы масштаб өскөндө көрүнөт. Жүз станок жүз корголгон байланыш, сессия, MonitoredItem топтому, keep-alive таймери жана кайра туташуу сценарийи дегенди билдирет. Туура тандалган топтоочу сервер үчүн бул кадимки жүк, бирок CNC ичиндеги алсыз сервер үчүн оор болушу мүмкүн. Сессиялар менен жазылуу элементтеринин чегин паспорттогу OPC UA белгисинен чыгарбай, өлчөө керек.

PubSub станокту алуучулардан бөлөт

PubSub алдын ала аныкталган агымды жакшы масштабдайт, анткени жарыялоочунун иши жазылуучулардын саны менен өспөйт. OPC UA Part 14 боюнча Publisher DataSet түзөт, WriterGroup жарыялоо режимин белгилейт, DataSetWriter билдирүүлөрдү коддойт. Subscriber аларды аралык транспорт аркылуу алып, DataSetReader менен шайкеш келтирет.

UDP UADP вариантында станок же шлюз бинардык билдирүүнү multicast тобуна же конкреттүү дарекке жөнөтөт. Бир пакетти MES, архив, энергия мониторинги жана аналитика кабыл ала алат. Башкарылган жергиликтүү сегментте бул жарыялоочунун жүгүн алдын ала белгилүү кылып, ар бир алуучу менен сессия түзүүнү жок кылат. Бирок кадимки UDP best effort жеткирүү бойдон калат: пакет жоголушу, иретсиз келиши же аралык жабдуунун аракетинен кийин кайталанышы мүмкүн.

Брокердик вариантта Publisher UADP же JSONду MQTT брокерине жөнөтөт, керектөөчүлөр темаларга жазылат. Брокер керектөөчүнүн жашоо циклин станоктон бөлөт, өз жөндөөсүнө ылайык билдирүүлөрдү сактап, бир агымды бир нече системага тарата алат. MES башка тармак сегментинде болсо же маалымат бир учурда бир нече колдонмого керек болсо, бул ыңгайлуу.

PubSub жазылуучуга бүт дарек мейкиндигин каалагандай карап чыгуу мүмкүнчүлүгүн бербейт. Сыртка чыккан талааларды DataSet алдын ала аныктайт. Инженер токтоонун жаңы себеп кодун кошсо, метамаалымат менен керектөөчү келишими жаңыртылышы керек. Мындай алдын ала белгилүүлүк эксплуатация үчүн жакшы, бирок версияларды башкарууну талап кылат.

Даяр тетик окуясынын минималдуу келишими мындай көрүнүшү мүмкүн:

{
  "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ке кайталанган билдирүүнү өндүрүштү экинчи жолу жазбай кабыл алууга мүмкүндүк берет, schemaVersion шайкеш өзгөрүүлөрдү шайкеш эместерден бөлөт, ал эми sourceTime станоктун убактысын брокер кабыл алган убакыт менен алмаштырууга жол бербейт. quality талаасы ар дайым Good сабын камтыбай, текшерилген булак абалынан келиши керек.

PubSubту брокер мода болгон үчүн эмес, туруктуу маалымат келишими бар кезде тандаңыз. Тегдердин курамы жума сайын өзгөрүп, интеграторго дайыма Browse керек болсо, алгач Client/Server же топтоочу шлюз аркылуу моделди турукташтырыңыз.

Кечигүүнү бүт чынжыр боюнча өлчөңүз

Эч бир модель шартсыз аз кечигүүнү убада кылбайт, анткени тармак пакети физикалык сигналдан MES жазуусуна чейинки жолдун бир гана бөлүгү. Сигнал адегенде PLC же CNC циклине түшөт, андан кийин сервер же Publisher маанини тандап, билдирүүнү коддоп, өткөрөт, ал эми керектөөчү натыйжаны талдап, жазат.

Client/Server үчүн MonitoredItem sampling interval жана Subscription publishing interval маанилүү. Спецификация серверге колдоого алынбаган аралыкты кайра кароого уруксат берет, ошондуктан суралган 10 ms иш жүзүндө 10 ms дегенди билдирбейт. Булак 100 ms сайын жаңырса, серверди 5 ms сайын суроо жаңы маалымат түзбөйт. Ал жумушту гана көбөйтөт.

PubSub үчүн WriterGroup PublishingInterval, key frame жана delta frame режими, пакет көлөмү, тармак интерфейсинин кезеги жана транспорт маанилүү. UDP UADP брокердик баскычты алып салышы мүмкүн. MQTT брокер менен тандалган QoS ырастоолорун кошот, бирок жалпы кезек жана туруктуу fan-out аркылуу начар жөндөлгөн жүздөгөн сессиядан натыйжалуу болушу мүмкүн. Салыштыруу бирдей талаалар жана булактын бирдей жыштыгы менен гана мааниге ээ.

Мен төрт убакытты өлчөйм: станоктогу t_source, Publisher же сервердеги t_publish, интеграция катмарынын киришиндеги t_receive жана MESке ырасталган жазуудан кийинки t_commit. Ошондо эки өзүнчө чоңдук көрүнөт:

transport_latency = t_receive - t_publish
end_to_end_latency = t_commit - t_source

Биринчиси тармак менен жеткирүүнү көрсөтөт. Экинчиси өндүрүш сезген натыйжаны көрсөтөт. Медиананы, 95 жана 99-процентилди, максимумду, жоголгон окуялар менен дублдардын үлүшүн салыштырыңыз. Бир орточо көрсөткүч эстутум тазалоонун тыныгуусун, кайра туташууларды жана кезектин толушун жашырат.

Сааттар синхрондолушу керек, болбосо терс кечигүү жакшыруу болуп көрүнөт. Станок убакытты ишенимдүү синхрондой албаса, эң жакын шлюзда белги коюп, аны окуя убактысы эмес, байкоо убактысы деп атаңыз. Авариялык токтотуу үчүн физикалык кирүүнү PLC журналы менен да салыштырыңыз, болбосо сыноо чынжырдын кооз бөлүгүн гана текшерет.

OEE үчүн секунддар ичиндеги жеткирүү көбүнчө жетиштүү, бирок буйрук же блокировка башка чекке ээ болушу мүмкүн. MESти реалдуу убакыт контуруна айландырбаңыз. Октордун кыймылы, операторду коргоо жана тез блокировкалар контроллерде калышы керек, ошондо тармактын кечигүүсү же үзгүлтүгү жабдуунун коопсуз абалын өзгөртпөйт.

Тармак жүгү өзгөрүүлөргө жана алуучуларга көз каранды

PubSub дайыма аз трафик түзбөйт, Client/Server да тармакты дайыма ашыкча жүктөбөйт. Натыйжа талаалардын санына, өзгөрүү жыштыгына, коддоого, кызматтык баш аттарга, алуучулардын санына жана кайра жеткирүү саясатына байланыштуу.

Өндүрүмдүүлүк убадасы эмес, эсептик мисал алалы. Жүз станок 200 сандык маанини секундасына он жолу өткөрөт. Пайдалуу 8 байттык маанилердин өзү 1,6 Mbit/s түзөт. Аларга идентификаторлор, убакыт, StatusCode, OPC UA, IP жана транспорт баш аттары кошулат. Айрыкча ар бир талаа өз атын алып жүрсө, JSON бинардык UADPга салыштырганда көлөмдү кыйла көбөйтөт.

Client/Server Subscription өзгөрүүлөрдү гана жөнөтүп, бир нече Notificationду бир билдирүүгө топтой алат. Deadband аналогдук сигналдын ызы-чуусун чыпкалайт. MES жалгыз керектөөчү болуп, маанилердин көбү сейрек өзгөрсө, мындай жазылуу мезгилдүү толук DataSetке караганда үнөмдүү болушу мүмкүн.

UDP multicast бир таркатуу домениндеги угуучулардын санына карабай бир NetworkMessage жөнөтөт. Бир нече алуучу болгондо бул чоң артыкчылык, бирок multicast коммутаторлорду, IGMP snooping, VLAN жана маршруттоо эрежелерин жөндөөнү талап кылат. Башкарылбаган таркатуу агымды кереги жок портторго жеткириши мүмкүн.

MQTT Publisherден бир агымды алат, андан кийин брокер жазылуучуларга өзүнчө көчүрмөлөрдү жөнөтөт. Станоктун жүгү алдын ала белгилүү бойдон калат, бирок трафик менен ресурс жоголбойт, брокерге жана анын чыгыш байланыштарына өтөт. QoS 1 жана QoS 2 ырастоолорду жана мүмкүн болгон кайра жөнөтүүнү кошот. Билдирүүлөрдү сактоо үчүн диск жана так сактоо мөөнөтү саясаты керек.

Трафикти үч бөлүктө өзүнчө эсептеңиз: станоктон шлюзга, шлюздан брокерге жана брокерден MESке. Кадимки режимди жана үзгүлтүктөн кийинки калыбына келүүнү текшериңиз. 5 Mbit/s агымды тынч өткөргөн система MES бир саат жеткиликсиз болгондо, эч ким билдирүүнүн өмүрүн жана буфердин тереңдигин чектебесе, гигабайттык кезек топтошу мүмкүн.

Ишенимдүүлүк жана коопсуздук аталыш менен кошо келбейт

Client/Server өткөрүп жиберүүлөрдү табуу жана NotificationMessage билдирүүлөрүн кайра жөнөтүү механизмдерин берет, бирок ишенимдүүлүк Subscription менен кезектер сакталып турганда гана бар. PubSub жеткирүү касиеттерин транспортко өткөрөт. Ошондуктан «шифрленген OPC UA» жана «exactly once менен MQTT» деген сөздөр техникалык тапшырма үчүн өтө кыска.

MQTT үчүн OPC UA Part 14 best effort жана at most once режимдерин QoS 0гө, at least once режимин QoS 1ге, exactly once режимин QoS 2ге дал келтирет. QoS 1 дублдарга жол берет. QoS 2 брокер менен алмашууга кепилдик берет, бирок MES бизнес логикасы окуяны так бир жолу жазарына кепилдик бербейт. Иштетүүчү өндүрүштү жазып, ырастоону сактаганга чейин токтосо, билдирүү кайра келиши мүмкүн. Уникалдуу eventId жана MES маалымат базасындагы уникалдуулук чектөөсү бул боштукту QoS аталышына караганда жакшы жабат.

Кошумча механизмсиз UDP жеткирүүнү ырастабайт. Жакында толук key frame келсе, мезгилдүү телеметрия үчүн бир пакеттин жоголушу кабыл алынат. Даяр тетик же рецепт өзгөрүүсү үчүн үнсүз жоготууга жол берилбейт. Мындай окуяларды ишенимдүү брокердик транспорт менен жөнөтүңүз же ырасталуучу интерфейсте кайталаңыз.

Client/Serverде SecureChannel кардар менен сервердин ортосундагы билдирүүлөрдү коргойт, колдонмолор сертификат колдонуп, колдонуучу же колдонмо жөндөөгө ылайык аутентификациядан өтөт. Ишеним тизмелерин, сертификат мөөнөтүн, жабык ачкычтарды, өчүрүлгөн алгоритмдерди жана кирүүнү жокко чыгарууну башкаруу керек. Оператор бир жолу кол менен «түбөлүккө» кабыл алган сертификат катуу ишеним схемасын формалдуулукка айлантат.

MQTT аркылуу PubSubта TLS брокерге чейинки ар бир бөлүктү коргойт. Брокер маалыматты көрөт жана ишенимдүү тарап катары каралышы керек. Part 14 JSON билдирүүлөрү MQTT менен брокердин коопсуздугуна таянарын өзүнчө эскертет; билдирүүлөрдүн башынан аягына чейинки коопсуздугу UADP үчүн аныкталган. UADP колтамгасы жана шифрлөөсү Security Key Service башкарган топтук ачкычтарды колдонот. Бул ачкычтарды алмаштыруу, коопсуздук топтору жана ачкычтын мөөнөтү бүткөндөн кийинки калыбына келтирүүнү кошот.

Практикалык эреже жөнөкөй: ишеним чектерин чийип, ар бир сертификаттын же топтук ачкычтын жооптуусун көрсөтүңүз. Андан кийин бир сертификатты өчүрүп, ачкычты алмаштырып, брокерди кайра иштетип, журналды текшериңиз. Команда агымды ким калыбына келтирерин жана ишеним катасын тармак үзгүлтүгүнөн кантип айырмаларын түшүндүрө албаса, коопсуздук азырынча схемада гана бар.

Сертификатты профиль, MESти интерфейс боюнча текшериңиз

«OPC UA supported» белгиси талап кылынган модель менен шайкештикти далилдебейт. OPC UA Part 7 Client, Server, Publisher жана Subscriber колдонмо профилдерин бөлөт жана конкреттүү функциялар менен транспорттор үчүн Facet кошот. Сертификатталган Server Publisher болбошу мүмкүн, сертификатталган Client болсо MQTT UADP кабыл алууга милдеттүү эмес.

OPC Foundation продукттарды жарыяланган профилдер боюнча сынайт жана Client, Server, Publisher, Subscriber, PubSub UDP UADP, MQTT JSON жана MQTT UADP боюнча чыпкалоого боло турган каталогду жарыялайт. Сатып алуу талабында так профиль, версия, коддоо, транспорт жана функциялар жазылышы керек. Профилдер тизмеси жок сертификат белгиси интеграция тууралуу аз маалымат берет.

MES жеткирүүчүсүнөн презентация эмес, мүмкүнчүлүктөр таблицасын сураңыз. Конкреттүү жооптор керек:

• MES OPC UA Client катары иштейби же өзүнчө коннектор талап кылабы?
• Ал Subscription, кезектер, жазылууну өткөрүү жана StatusCode колдойбу?
• PubSubту түз, MQTT коннектору аркылуу же интеграция катмарынын API аркылуу гана кабыл алабы?
• Кайсы коддоолорду, MQTT версияларын, QoS, темаларды жана метамаалыматтарды түшүнөт?
• Source timestamp, quality, sequence number жана окуя идентификаторун кантип сактайт?

MQTT колдоосу OPC UA PubSub колдоосун билдирбейт. Кадимки MQTT коннектору JSON кабыл алып, бирок OPC UA NetworkMessage түзүлүшүн, DataSet метамаалыматын жана шайкештик эрежелерин тааныбай калышы мүмкүн. Тескери ката да болот: команда PubSub Publisher сатып алат, ал эми MES Client/Server Data Access гана билет.

Станок тарабын да текшериңиз. Ички OPC UA Server сессияларды, MonitoredItem санын жана минималдуу аралыкты чектеши мүмкүн. Архитектура MQTT JSON талап кылса да, Publisher UDP UADP гана колдошу ыктымал. Шлюз айырманы жаба алат, бирок өзү конфигурациясы, жаңыртуусу, резерви жана сертификаттары бар өзүнчө активге айланат.

Аралаш схема көбүнчө чынчылыраак

Аралаш схема ар түрдүү станоктору бар цехтардын көбүнө туура келет, анткени ар бир моделдин күчтүү жагын өз ордунда калтырат. Жергиликтүү интеграция катмары станокторго OPC UA Client болуп туташып, дарек мейкиндигин карайт, өлчөө бирдиктери менен абалдарды нормалдаштырат, андан кийин MES жана башка керектөөчүлөр үчүн туруктуу өндүрүш келишимин жарыялайт.

Бул схема ар бир эски контроллердин толук PubSub Publisher болушун талап кылбайт. Ошондой эле MESти тармактар аралык экрандар аркылуу жүздөгөн түз сессия кармоого мажбурлабайт. Буйруктар тар авторизация, ырастоо жана PLC текшерүүсү бар өзүнчө Client/Server каналы менен кайтып келет. Телеметрия жана окуялар сактоо жана кайталап иштетүү эрежелери менен PubSub аркылуу өтөт.

Аралаш схеманын баасы реалдуу. Шлюз кечигүү, бузулуу чекити жана дагы бир конфигурация моделин кошот. Эгер ал NodeId ns=4;s=Counter маанисин quantity талаасына айлантса, команда дал келтирүү версиясын жана өзгөрүүлөр журналын сактоого милдеттүү. Станоктун программасы алмашкандан кийин эски NodeId башка жерди көрсөтүшү же жоголушу мүмкүн, ошондуктан туташканда келишимди автоматтык текшерүү милдеттүү.

Жаңы долбоор үчүн транспортту тандоодон мурда жабдуунун канондук идентификаторлорун, өлчөө бирдиктерин, source timestamp, StatusCode, схема версияларын жана идемпотенттүүлүк эрежелерин бекитиңиз. Андан кийин өзгөртүү кайда жашарын чечиңиз: CNCде, өнөр жай шлюзунда же интеграция кызматында. Бир эле дал келтирүүнү ар бир керектөөчүгө таратып салбаңыз.

Жабдуу тандоодо EAST CNC конкреттүү моделдеги жеткиликтүү интерфейстерди тактап, байланышты текшерүүнү ишке киргизүү иштерине кошо алат. Бирок интеграцияны кабыл алуу сиздин MESке, тармак схемаңызга жана тегдер тизмесине байланышы керек, анткени протоколдун аталышы даяр алмашууну сүрөттөбөйт.

Бир MES он станокту окуп, дарек мейкиндиктери туруктуу болуп, түз жазылуулар сыноодон запас менен өтсө, аралаш схема керек эмес. Ал начар маалымат келишимин да оңдобойт. Кошумча брокер түшүнүксүз маанилерди көбүрөөк системага тезирээк таратат.

Кабыл алуу сыноосу бузулууну кайталашы керек

Чечимди иштеген чынжырды өлчөп, аны атайын бузган кыска сыноодон кийин кабыл алууга болот. Стендде бир тегди көрсөтүү эки продукт бир жолу сан алмашканын гана далилдейт.

1. 20-50 реалдуу талааны тандаңыз: тез өзгөргөн маанилер, сейрек абалдар, эскертүү, эсептегич, өндүрүш окуясы жана бир уруксат берилген сыноо буйругу. Ар бир талаа үчүн тип, бирдик, убакыт булагы, уруксат берилген кечигүү жана сапат начар кездеги жүрүм-турумду бериңиз.
2. Client/Server менен PubSubту булактын бирдей жыштыгында иштетиңиз. eventId, sequence number, төрт убакыт белгисин, билдирүү көлөмүн, жоготууларды, дублдарды жана станок же шлюз процессорунун жүгүн жазыңыз.
3. Тармакты 30 секундга, андан соң жөндөлгөн кезектен узагыраак убакытка ажыратыңыз. Кардарды, Publisherди, брокерди жана MESти өз-өзүнчө кайра иштетиңиз. Кайсы маанилер калыбына келгенин, кайсылары жоголгонун жана өндүрүш эки жолу жазылбаганын текшериңиз.
4. Экинчи жана үчүнчү керектөөчүнү кошуңуз. Client/Server үчүн сессиялар менен MonitoredItem өсүшүн, UDP үчүн коммутаторлордогу multicastты, MQTT үчүн брокердин чыгыш агымын жана кезегин караңыз.
5. Сертификатты алмаштырып, эсептик маалыматтарды жокко чыгарыңыз, DataSet версиясын өзгөртүп, бир милдеттүү түйүндү өчүрүңүз. Система белгисиз маанинин ордуна нөл менен улантпай, түшүнүктүү ката бериши керек.

Натыйжаны mode,machine,event_id,t_source,t_publish,t_receive,t_commit,bytes,status,duplicate талаалары бар CSVде сактоо ыңгайлуу. Бир эле файл кечигүү процентилдерин, тармак баасын жана калыбына келүүдөн кийинки тууралыкты салыштырууга жетет. Кабыл алуу протоколуна Subscription же WriterGroup конфигурациясын, программа версияларын, OPC UA профилин жана QoS жөндөөсүн кошуңуз. Аларсыз сыноону бир жылдан кийин кайталоо мүмкүн эмес.

MESке контекст, даректүү операциялар жана станоктон түз жооп керек болуп, байланыштардын саны текшерилген чектерге батса, Client/Server тандаңыз. Команда брокерге же өнөр жай multicast тармагына жооп берүүгө жана DataSet версияларын башкарууга даяр болсо, көп керектөөчүгө туруктуу агымдар үчүн PubSub тандаңыз. Эки касиет тең керек болсо, агымдарды бөлүп, тез коопсуз контурду станоктун ичинде калтырыңыз. Акыркы чечим коммерциялык сунуштагы технологиянын аталышы менен эмес, бузулуу сыноосунун жыйынтыгы менен түшүндүрүлүшү керек.