OPC UA Client/Server թե PubSub MES-ի համար

Հաստոցների տվյալները OPC UA Client/Server-ով փոխանցելը ճիշտ է, երբ MES-ը պետք է գտնի թեգերը, հարցմամբ կարդա վիճակը, հաստատումով ստանա փոփոխությունները և երբեմն գրի առաջադրանքներ։ 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-ը տալիս է համատեքստ և հետադարձ կապ

Client/Server-ը ավելի հարմար է այն MES-ի համար, որը պետք է ուսումնասիրի և փոխի հաստոցի տեղեկատվական մոդելը, այլ ոչ միայն ստանա թվերի ֆիքսված հավաքածու։ 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 հաստոցում, t_publish Publisher-ում կամ սերվերում, t_receive ինտեգրման շերտի մուտքում և t_commit MES-ում հաստատված գրառումից հետո։ Այդպես երևում են երկու տարբեր մեծություններ.

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» և «MQTT exactly once-ով» արտահայտությունները չափազանց կարճ են տեխնիկական առաջադրանքի համար։

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-ների թիվը և նվազագույն միջակայքը։ Publisher-ը կարող է աջակցել միայն UDP UADP, թեև ճարտարապետությունը պահանջում է MQTT JSON։ Դարպասը կարող է փակել տարբերությունը, բայց ինքն է դառնում առանձին ակտիվ՝ կազմաձևմամբ, թարմացումներով, պահուստավորմամբ և հավաստագրերով։

Հիբրիդային սխեման սովորաբար ավելի ազնիվ է

Հիբրիդը հարմար է տարբեր հաստոցներով արտադրամասերի մեծ մասին, քանի որ յուրաքանչյուր մոդելի ուժեղ կողմը թողնում է իր տեղում։ Տեղային ինտեգրման շերտը միանում է հաստոցներին որպես OPC UA Client, դիտում հասցեային տարածքը, նորմալացնում միավորներն ու վիճակները, ապա կայուն արտադրական պայմանագիր է հրապարակում MES-ի և այլ սպառողների համար։

Այս սխեման չի պահանջում, որ յուրաքանչյուր հին կարգավորիչ դառնա լիարժեք PubSub Publisher։ Այն նաև չի ստիպում MES-ին միջցանցային էկրաններով հարյուրավոր ուղիղ սեսիաներ պահել։ Հրամանները վերադառնում են առանձին Client/Server ալիքով՝ նեղ լիազորմամբ, հաստատմամբ և PLC ստուգմամբ։ Հեռաչափությունն ու իրադարձությունները գնում են 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-ի տարբերակը և հեռացրեք մեկ պարտադիր հանգույց։ Համակարգը պետք է հասկանալի սխալ տա, ոչ թե անհայտ արժեքի փոխարեն շարունակի զրոյով։

Արդյունքները հարմար է պահել CSV-ում՝ mode,machine,event_id,t_source,t_publish,t_receive,t_commit,bytes,status,duplicate դաշտերով։ Նույն ֆայլը թույլ է տալիս համեմատել ուշացման պերցենտիլները, ցանցային արժեքը և վերականգնումից հետո ճշտությունը։ Ընդունման արձանագրությանը կցեք Subscription կամ WriterGroup կազմաձևումը, ծրագրաշարի տարբերակները, OPC UA պրոֆիլը և QoS կարգավորումները։ Առանց դրանց մեկ տարի անց փորձարկումը կրկնել չի ստացվի։

Ընտրեք Client/Server, եթե MES-ին պետք են համատեքստ, հասցեական գործողություններ և ուղիղ պատասխան հաստոցից, իսկ կապերի թիվը տեղավորվում է փորձարկված սահմաններում։ Ընտրեք PubSub կայուն հոսքերը շատ սպառողներին տալու համար, երբ թիմը պատրաստ է պատասխանել բրոքերի կամ արդյունաբերական multicast ցանցի համար և կառավարել DataSet-ի տարբերակները։ Եթե երկու հատկություններն էլ պետք են, բաժանեք հոսքերը և արագ անվտանգ շղթան թողեք հաստոցի ներսում։ Վերջնական որոշումը պետք է բացատրվի խափանման փորձարկման արդյունքներով, ոչ թե առևտրային առաջարկի տեխնոլոգիայի անունով։