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 мс нақты 10 мс дегенді білдірмейді. Дереккөз 100 мс сайын жаңарса, серверді 5 мс сайын сұрау жаңа дерек жасамайды. Ол тек жұмысты көбейтеді.

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 Мбит/с құрайды. Бұған идентификаторлар, уақыт, 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 Мбит/с ағынды тыныш өткізетін жүйе 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 таңдаңыз. Екі қасиет те керек болса, ағындарды бөліп, жылдам қауіпсіз контурды станок ішінде қалдырыңыз. Соңғы шешім коммерциялық ұсыныстағы технология атауымен емес, ақау сынағының нәтижесімен түсіндірілуі тиіс.