OPC UA-ն MES-ի համար բավարար չէ առանց առաջադրանքների մոդելի

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

Եթե համակարգին պետք են միայն ռեժիմը, վթարները, հաշվիչներն ու ընթացիկ բեռնվածությունը, ISA-95 Job Control ավելացնելը դեռ վաղ է։ Եթե MES-ը պետք է փոխանցի պատվերը, քանակը, ծրագիրը, նյութի պահանջները, թույլատրի գործարկումը, դադարեցնի աշխատանքն ու ընդունի արդյունքը, կամայական թեգերն արդեն բավարար չեն։ Պետք է համաձայնեցված առաջադրանքի մոդել, նույնիսկ եթե նախագծի թիմը որոշի այն իրականացնել ոչ խիստ ըստ ստանդարտի։

OPC UA-ն լուծում է կապը, ոչ թե առաջադրանքի իմաստը

OPC UA-ն տալիս է փոխանակման միջոցներ, բայց տվյալների իմաստը հայտնվում է միայն տեղեկատվական մոդելում։ Սերվերը կարող է հրապարակել ProductionOrder տողային տիպի փոփոխական, և ցանկացած հաճախորդ այն կկարդա առանց սխալի։ Բայց տողից պարզ չէ՝ դա ERP պատվերի համարն է, հերթափոխային առաջադրանք, խմբաքանակ, երթուղու գործողություն, թե կառավարման ծրագրի անուն։

Նախագծերում այս տարբերությունը մշտապես ջնջվում է։ Արձանագրությունը պատասխանում է «ինչպես կարդալ», «ինչպես կանչել մեթոդ», «ինչպես բաժանորդագրվել» և «ով ունի հասանելիություն» հարցերին։ Արտադրական մոդելը պատասխանում է «ինչն է կոնկրետ հանձնարարված», «ինչ ռեսուրս է պահանջվում», «կարելի՞ է փոխել հանձնարարությունը» և «որ արդյունքն է վերաբերում որ պատվերին» հարցերին։

OPC Foundation-ը նկարագրում է այս մոդելը OPC 10031-4, OPC UA for ISA-95, Part 4: Job Control-ում։ Փաստաթուղթը սահմանում է Job Order-ը, Job Response-ը, հերթում գտնվող, կատարվող ու ավարտված առաջադրանքների հասանելիությունը, ինչպես նաև դրանք կառավարելու մեթոդները։ Սա OPC UA-ի մրցակիցը չէ, այլ դրա վերևում գործող companion specification։

Ընդհանուր նշանակության սարքավորումների համար կա նաև OPC 40001-3, OPC UA for Machinery, Part 3: Job Management։ Այն օգտագործում է Job Control տիպերը և ճշտում է հաստոցների պարամետրերը՝ պլանային քանակը, գործարկումների թիվը, պլանային ժամանակը, կատարման ռեժիմը, պատվերի համարներն ու արդյունքի տվյալները։ OPC UA for Machine Tools 1.02 տարբերակում նախկին ProductionType մոդելն արդեն նշված է որպես հնացած՝ Machinery Job Management-ով ապագա փոխարինման հղումով։ Նոր հաստոց գնելը՝ հենվելով միայն հին production թեգերի ցանկի վրա, նշանակում է ապագայում ադապտերը վերաշարադրելու անհրաժեշտություն նախատեսել։

Կա ևս մեկ սահման։ ISA-95 Job Control-ը չի սահմանում դետալի մշակման տեխնոլոգիական տրամաբանությունը։ Մատուցումները, գործիքի շտկումները, անցումները, կցորդիչի արգելափակումները և անվտանգ կանգառը մնում են CNC-ում ու PLC-ում։ MES-ը կառավարում է հանձնարարությունը, ոչ թե առանցքների շարժումը։

Մոնիթորինգի համար Job Control պետք չէ

Պարամետրերի պարզ հավաքումը առաջադրանքների մոդել չի պահանջում, եթե MES-ը կամ առանձին մոնիթորինգի համակարգը չի կառավարում հաստոցի աշխատանքը։ Բեռնվածությունը հաշվարկելու և պարապուրդները վերլուծելու համար սովորաբար բավական է կառուցվածքային հեռաչափությունը։

Մոնիթորինգի նվազագույն պայմանագիրը ներառում է.

• սարքավորման վիճակն ու աշխատանքի ռեժիմը,
• ավտոմատ ցիկլի ակտիվությունն ու կանգառի պատճառը,
• պիտանի և անպիտան դետալների հաշվիչները,
• վթարները՝ կոդով, առաջացման և հաստատման ժամանակով,
• ակտիվ ծրագրի կամ ընթացիկ առաջադրանքի նույնացուցիչը, եթե հաստոցն այն արդեն գիտի։

Յուրաքանչյուր արժեք պետք է ունենա աղբյուր, տիպ, չափման միավոր, ժամանակային նշում և OPC UA StatusCode։ Զրոյացման կանոն չունեցող հաշվիչն անօգուտ է։ Running վիճակն էլ անօգուտ է առանց սահմանման. մատակարարներից մեկը հաստոցը աշխատող է համարում լիսեռի պտտման ժամանակ, մյուսը՝ ակտիվ ծրագրի դեպքում, երրորդը՝ վթարի ազդանշանի բացակայության դեպքում։

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

Պետք չէ պատվերը կապել յուրաքանչյուր ջերմաստիճանի և առանցքի յուրաքանչյուր դիրքի հետ։ Հեռաչափությունը նկարագրում է ֆիզիկական օբյեկտի վիճակը։ Արտադրական համատեքստը տվյալների մի մասը կապում է կոնկրետ աշխատանքի հետ։ Եթե երկու շերտը խառնեք, պատվերի համարը փոխելը կխաթարի պատմական տենդենցները, իսկ սենսորի փոխարինումը կպահանջի փոխել MES-ի մոդելը։

Գործնական չափանիշը պարզ է. եթե MES-ը կապի խզման դեպքում հաստոցին ոչինչ չպետք է կրկին ուղարկի, իսկ կապը վերականգնելուց հետո բավական է շարունակել ընթերցումը, Job Control-ը դեռ պարտադիր չէ։ Ամեն ինչ փոխվում է, երբ հաղորդագրության կորուստը կարող է թողնել երկու առաջադրանք, սխալ ծրագիր կամ չփակված պատվեր։

MES-ը սկսում է կառավարել Job Order-ի հայտնվելուն պես

Job Order մոդելը պետք է, երբ վերին համակարգը աշխատանքի մեկ միավոր է հանձնարարում կոնկրետ աշխատանքային կենտրոնին։ ISA-95-ը Job Order-ն անվանում է աշխատանքի կատարման հարցում և արտադրական ժամանակացույցի կառուցվածքում այն տեղադրում է Work Request-ից ցածր։ Մետաղամշակման մեջ այդ միավորը հաճախ դառնում է պատվերի գործողությունը որոշակի հաստոցի վրա, ոչ թե հաճախորդի ամբողջ պատվերը։

Լավ առաջադրանքը առնվազն պատասխանում է հետևյալ հարցերին.

• որն է դրա կայուն նույնացուցիչը և որ պատվերին է վերաբերում,
• ինչ է պետք արտադրել և ինչ քանակով,
• աշխատանքի եղանակը որոշող Work Master-ը, երթուղին, ծրագիրը կամ փաստաթղթի տարբերակը,
• ինչ սարքավորում, նյութ, հարմարանք կամ որակավորում է պահանջվում,
• երբ է թույլատրված առաջադրանքը գործարկել և որն է դրա առաջնահերթությունը։

Կառավարման ծրագրի համարով դաշտը չի փոխարինում Work Master-ին։ Կառավարման ծրագիրը նկարագրում է մշակումը կոնկրետ CNC համակարգի վրա։ Արտադրական սահմանումը կարող է ներառել նաև տեղադրման քարտ, հսկողության պլան, ամրացման հրահանգ, գծագրի տարբերակ և խոտանը գրանցելու կանոններ։ MES-ը կարող է հղում անել հաստատված փաթեթին, իսկ հաստոցի տեղային համակարգը պետք է ստուգի, որ անհրաժեշտ տարբերակը հասանելի է։

Ամեն պահանջ պարտադիր չէ, որ հասնի վերահսկիչին։ Օպերատորի որակավորման պահանջը կարող է ստուգել արտադրամասի տերմինալը։ Նախապատրաստուկի խմբաքանակը կարող է հաստատել սկաները։ Հարմարանքի նույնացուցիչը կարող է ստուգել PLC-ը կամ օպերատորը։ Job Order-ը այս պահանջները միավորում է մեկ համատեքստում, բայց չի պարտադրում մեկ սերվերին կատարել դրանք բոլորը։

Առաջնահերթությունն ու մեկնարկի ժամանակը նույնպես անհապաղ գործարկման հրաման չեն։ OPC 40001-3-ը մի քանի թույլատրված առաջադրանքների հերթականությունը սահմանում է նախ StartTime-ով, ապա Priority-ով, իսկ հավասարության դեպքում ընտրությունը կախված է հավելվածից։ Սա խելամիտ վերապահում է։ Պլանավորիչն առաջարկում է հերթականություն, իսկ հաստոցը սկսում է աշխատանքը միայն տեղային պատրաստվածության ստուգումից հետո։

Job Response-ը փակում է արտադրական ցիկլը

Job Response-ը MES-ին ոչ պակաս է պետք, քան Job Order-ը, քանի որ հաստատված արդյունք չունեցող հրամանը պատվերը թողնում է անորոշ վիճակում։ Ստանդարտը պատասխանը սահմանում է որպես առաջադրանքով կատարված աշխատանքի հաշվետվություն և առանձնացնում է պատվերի պահանջներն ու պատասխանի փաստացի տվյալները։

Այս բաժանումը հաճախ փչացնում են մեկ Material օբյեկտով։ Պատվերում նյութը նշանակում է պահանջ՝ մակնիշ, չափ, խմբաքանակ կամ թույլատրելի դաս։ Պատասխանում Material Actual-ը նշանակում է իրականում օգտագործվածը։ Եթե պահանջը փոխարինեք փաստով, MES-ը չի հայտնաբերի խմբաքանակի փոխարինումը և չի կարող վերականգնել հետագծելիությունը։

Նույն տրամաբանությունն աշխատում է սարքավորումների, ֆիզիկական ակտիվների և անձնակազմի համար։ Equipment Requirement-ը կարող է պահանջել որոշակի դասի հաստոց։ Equipment Actual-ը գրանցում է կոնկրետ աշխատանքային կենտրոնը։ Physical Asset Requirement-ը կարող է նկարագրել չափիչ սարքի տեսակը, իսկ Physical Asset Actual-ը պահում է փաստացի կիրառված սարքի նույնացուցիչը։ Այս զույգերը պետք են ոչ թե գեղեցիկ հիերարխիայի համար, այլ որակի բաժնի սովորական հարցին պատասխանելու համար. «Կոնկրետ այս խմբաքանակն ինչի վրա և ինչից է արտադրվել»։

Պատասխանը պետք է պարունակի միջանկյալ վիճակ երկար գործողության համար և վերջնական արդյունք՝ ավարտից հետո։ OPC 40001-3-ը նախատեսում է JobResult՝ Unknown, Successful և Unsuccessful արժեքներով, ինչպես նաև թողարկման և արտադրողականության տվյալներ։ Միայն Successful-ը բավարար չէ. MES-ին պետք են փաստացի քանակը, խոտանը, մեկնարկի և ավարտի ժամանակը, իսկ անհրաժեշտության դեպքում՝ ստացված դետալների կամ խմբաքանակների նույնացուցիչները։

Վիճակն ու արդյունքը չի կարելի միավորել։ Running-ը նկարագրում է ընթացիկ փուլը։ Successful-ը գնահատում է ավարտված աշխատանքը։ Հաստոցը կարող է կանոնավոր կանգնել՝ պլանավորվածից քիչ քանակ թողարկելուց հետո, իսկ բիզնես համակարգը կորոշի՝ կարելի՞ է պատվերը փակված համարել։ Վերահսկիչը հայտնում է փաստը, MES-ը կիրառում է արտադրական կանոնը։

Պատվերի մեկ տողն անխուսափելիորեն լայնանում է

Ինքնաշեն ինտեգրումը սովորաբար սկսում է խափանվել առաջին հաջող գործարկումից հետո, երբ դրան ավելացնում են իրական բացառությունները։ Ցուցադրության ժամանակ MES-ը գրում է OrderNo, PartNo, Quantity և Start բիթը։ PLC-ը կատարում է ծրագիրը, մեծացնում Produced-ը և դնում Done։

Հետո ցանցը անհետանում է Start-ը գրելուց հետո, բայց հաստատումը կարդալուց առաջ։ MES-ը կրկնում է գրառումը։ Եթե PLC-ը բիթի ճակատն ընկալում է որպես նոր հրաման, առաջադրանքը գործարկվում է երկրորդ անգամ։ Եթե բիթը մնացել է միացված, նոր գործարկում չի լինի, բայց MES-ը չգիտի՝ հաստոցն ընդունե՞լ է առաջինը։ Թիմը ավելացնում է Ack, հետո հերթական համար, հետո Busy, ապա թայմ-աութ ու ձեռքով զրոյացում։

Հաջորդիվ պլանավորիչը գործարկումից առաջ փոխում է քանակը։ Անհասկանալի է՝ կարելի՞ է դաշտերը փոխել Busy=0 դեպքում, եթե օպերատորն արդեն բեռնել է նյութը։ Հայտնվում է Locked։ Հետո օպերատորը դնում է առաջադրանքը դադարի՝ առաջին դետալը չափելու համար։ Պետք է տարբերել տեխնոլոգիական դադարը, վթարն ու չեղարկումը։ Հայտնվում են Pause, Hold, Fault, Cancel, Abort և անցումների մի քանի աղյուսակ, որոնք MES-ն ու PLC-ը տարբեր կերպ են մեկնաբանում։

Դրանից հետո գալիս է մասնակի կատարված պատվերը հաշվի առնելու պահանջը։ Հին Done դաշտը չի ասում՝ արտադրվե՞լ է 100-ից 80 դետալ, չեղարկվե՞լ են մնացած 20-ը, և հնարավո՞ր է նույն համարով շարունակություն ստեղծել։ Թիմն ավելացնում է կատարման խմբաքանակի համարը։ Մեկ տարի անց նախագիծն արդեն ունի իր առաջադրանքների մոդելը, պարզապես առանց ընդհանուր տերմինաբանության, համատեղելիության պրոֆիլների և հաջորդ հաստոց մատակարարի համար փաստաթղթավորման։

«Սկսենք չորս թեգից, հետո կընդլայնենք» հայտնի խորհուրդը վատ չէ փոքր մեկնարկի պատճառով։ Այն վատ է, երբ այդ չորս թեգն արդեն օգտագործվում է որպես արտաքին պայմանագիր և չունի հրամանի կայուն նույնացուցիչ, հստակ վիճակների մեքենա ու վերաուղարկման կանոններ։ Փոքր պիլոտը ընդունելի է, եթե թիմն անմիջապես ամրագրում է սահմանները և ժամանակավոր սխեման չի ներկայացնում որպես պատրաստ ճարտարապետություն։

Job Control-ը սխալները ինքնաբերաբար չի վերացնում։ Այն ստիպում է շահագործման հանձնելուց առաջ անվանել օբյեկտները, վիճակներն ու մեթոդները։ Հենց այս աշխատանքն է սովորաբար բացահայտում, որ MES-ը, PLC ծրագրավորողը և տեխնոլոգը «առաջադրանք» բառի մեջ տարբեր իմաստ էին դնում։

Տվյալների պայմանագիրն ավելի կարևոր է, քան թեգերի ցանկը

Աշխատող պայմանագիրը պետք է ցույց տա ոչ միայն դաշտերը, այլև ուղղությունը, պարտադիր լինելը, արժեքի սեփականատիրոջն ու կրկնման արձագանքը։ Ստորև բերված է խառատային գործողության առաջադրանքի կրճատված ներկայացումը։ Սա OPC UA ծրագրավորում չէ և ոչ էլ ISA95JobOrderDataType-ի ճշգրիտ սերիալացում, այլ ստուգելի նախագծային արտեֆակտ՝ MES-ի, դարպասի և հաստոցի համակարգի համաձայնեցման համար։

{
  "jobOrderId": "WO-78431-OP20-R1",
  "workMasterId": "SHAFT-A-OP20-REV4",
  "startTime": "2026-07-27T06:00:00Z",
  "priority": 60,
  "parameters": {
    "orderNumber": "WO-78431",
    "drawingNumber": "SHAFT-A",
    "drawingRevision": "04",
    "plannedQuantity": 120,
    "executionMode": "ProductionMode"
  },
  "materialRequirements": [
    {
      "materialDefinitionId": "STEEL-40X-D52",
      "plannedQuantity": 120,
      "unit": "piece"
    }
  ],
  "equipmentRequirements": [
    {
      "equipmentClassId": "CNC-LATHE-D65"
    }
  ]
}

Այստեղ jobOrderId նույնացուցիչը վերաբերում է գործողության կոնկրետ կատարմանը։ Նույն նույնացուցիչը կրկին ուղարկելը չպետք է ստեղծի երկրորդ առաջադրանք։ Եթե պլանավորիչը դիտավորյալ թողարկում է նոր տարբերակ, այն ստեղծում է նոր նույնացուցիչ կամ կիրառում է ստանդարտով թույլատրված Update-ը՝ մինչև այն վիճակին անցնելը, որտեղ փոփոխությունն արգելված է։ Կանոնը նախօրոք ընտրում և ստուգում են փորձարկման ստենդում։

Պատասխանը պետք է հղվի նույն նույնացուցիչին և տարանջատի փաստերը պլանից.

{
  "jobOrderId": "WO-78431-OP20-R1",
  "state": "Ended",
  "jobResult": "Successful",
  "actualStartTime": "2026-07-27T06:14:08Z",
  "actualEndTime": "2026-07-27T13:42:31Z",
  "producedQuantity": 120,
  "scrapQuantity": 2,
  "materialActuals": [
    {
      "materialLotId": "HEAT-91827",
      "consumedQuantity": 122,
      "unit": "piece"
    }
  ],
  "equipmentActuals": [
    {
      "equipmentId": "LATHE-07"
    }
  ]
}

Այդպիսի օրինակը միանգամից բարձրացնում է անհարմար հարցեր։ Խոտանը ներառվո՞ւմ է producedQuantity-ում։ Հաջող առաջադրանքը կարո՞ղ է խոտան ունենալ։ Ո՞վ է նշանակում materialLotId-ը։ Ինչպե՞ս հայտնել մետաղի երկու խմբաքանակի մասին։ Ե՞րբ է արդյունքը դառնում վերջնական։ Քանի դեռ պատասխանները գրված չեն, ինտեգրումը մնում է ենթադրությունների հավաքածու։

Վիճակների մեքենան պաշտպանում է կրկնակի կատարումից

Վիճակների հստակ անցումները նվազեցնում են կրկնակի գործարկման և վիճելի հրամանների վտանգը, բայց միայն եթե հաճախորդն ու սերվերը դրանք պահպանում են միասին։ OPC 10031-4-ը նկարագրում է առաջադրանքներ ընդունող կողմ՝ Store, StoreAndStart, Start, RevokeStart, Pause, Resume, Update, Abort, Stop, Cancel և Clear մեթոդներով։

Անվանումները սովորական կոճակների են նման, բայց տարբերությունները էական են։ Pause-ը ենթադրում է շարունակելու հնարավորություն։ Stop-ը ավարտում է կատարումը կառավարվող եղանակով՝ սարքավորման կանոններով։ Abort-ը կիրառվում է, երբ բնականոն շարունակությունն այլևս պետք չէ։ Cancel-ը վերաբերում է առաջադրանքին, որը չպետք է կատարվի։ Նախագիծը պետք է այս մտադրությունները համապատասխանեցնի CNC-ի և PLC-ի իրական հնարավորություններին. չի կարելի MES-ին խոստանալ շարունակվող դադար, եթե հաստոցի ցիկլը չի աջակցում այն անվտանգ կերպով։

StoreAndStart-ը նույնպես չի նշանակում անվերապահ ֆիզիկական գործարկում։ Մոդելում առաջադրանքը կատարման թույլտվություն է ստանում, որից հետո համակարգը հաշվի է առնում ռեսուրսները, առաջնահերթություններն ու տեղային պայմանները։ «Ցիկլի մեկնարկ» կոճակը կարող է մնալ օպերատորի մոտ, եթե դա պահանջում է տեխնոլոգիան կամ ռիսկերի գնահատումը։

Թայմ-աութից հետո հաճախորդը չպետք է կուրորեն կրկնի հրամանը։ Հուսալի հաջորդականությունն այսպիսին է. MES-ը պահպանում է jobOrderId-ը և փորձի նույնացուցիչը, կանչում է մեթոդը, իսկ պատասխանի կորստի դեպքում կարդում է առաջադրանքների ցանկն ու ընթացիկ վիճակը։ Կրկնումը թույլատրելի է միայն այն բանից հետո, երբ ստուգվել է, որ սերվերը չի ընդունել սկզբնական հանձնարարությունը։ Իդեմպոտենտությունն այստեղ համաձայնեցված վարքագծի հատկություն է, ոչ թե տրանսպորտի կախարդանք։

OPC 10031-4-ի B հավելվածում մեթոդների արդյունքի կոդերը տրված են UInt64 բիթային դիմակով։ Ստանդարտ պատճառներից են առաջադրանքի անհայտ նույնացուցիչը, սխալ վիճակը, առաջադրանքը ընդունելու անհնարինությունը և ոչ ճիշտ հարցումը։ Գրանցեք MES-ի սպասվող արձագանքը յուրաքանչյուր կոդի համար։ Unable to accept Job Order դեպքում անսահման ավտոմատ կրկնությունը ժամանակավոր խնդիրը շատ արագ վերածում է նույն հաղորդագրությունների հերթի։

Անվտանգ ալիքը MES-ին վտանգավոր հրամանի իրավունք չի տալիս

OPC UA-ի անվտանգության մեխանիզմները պաշտպանում են կապը, բայց նախագծողը միևնույն է պետք է սահմանափակի հաճախորդի լիազորություններն ու հաստոցի յուրաքանչյուր վիճակում հասանելի հրամանները։ Վկայագիրը հաստատում է կապի կողմին և օգնում է պաշտպանել փոխանցվող տվյալները։ Այն չի որոշում՝ պլանավորիչի հաշիվը մշակման ընթացքում պե՞տք է իրավունք ունենա կանչելու Abort։

Առնվազն առանձնացրեք մոնիթորինգի ընթերցումը, առաջադրանքի բեռնումը, կատարման թույլտվությունը և արտակարգ միջամտությունը։ MES-ի ծառայողական հաշվառումը չպետք է սերվերի ադմինիստրատիվ իրավունքներ ունենա միայն այն պատճառով, որ այդպես ավելի հեշտ է գործարկել փորձարկման ստենդը։ Առանձին գրանցեք հաճախորդի նույնացուցիչը, մեթոդը, jobOrderId-ը, ժամանակը, սկզբնական վիճակն ու կանչի արդյունքը։

Ձեռնարկության ցանցը նույնպես չի փոխարինում տեղային անվտանգությանը։ PLC-ն ու CNC-ն պարտավոր են ստուգել պաշտպանիչները, սեղմումը, շարժակների պատրաստվածությունը, ծրագրի առկայությունն ու այլ պայմանները՝ MES հրամանից անկախ։ Վերին համակարգը կարող է խնդրել գործարկել թույլատրված առաջադրանքը, բայց չպետք է շրջանցի պաշտպանության շղթաներն ու հաստոցի տրամաբանությունը։

Մտածեք կապի կորստի դեպքում աշխատանքի շարունակման մասին։ Կատարվող գործողությունը սովորաբար պետք է կամ անվտանգ շարունակվի տեղում, կամ կանգնի նախապես սահմանված կանոնով։ Այս որոշումը չի կարելի թողնել հաճախորդի գրադարանի թայմ-աութին։ Վերականգնումից հետո MES-ը պետք է ստանա փաստացի վիճակն ու արդյունքները, ոչ թե հաստոցին վերագրի իր հին պատճենից ստացած վիճակը։

Ամբողջական մոդելը ներդրեք պատասխանատվության սահմանով

Առաջին թողարկման մեջ ամեն ձեռնարկության պետք չէ ISA-95-ի ամբողջ մոդելը։ Պետք է նվազագույն պրոֆիլ, որը ծածկում է MES-ի փաստացի պատասխանատվությունը և թույլ է տալիս զարգանալ՝ առանց նույնացուցիչների իմաստը փոխելու։

Հարմար է ներդրումը բաժանել երեք մակարդակի։ Առաջինում MES-ը միայն կարդում է միասնական հեռաչափությունը։ Երկրորդում այն ակտիվ տեղային առաջադրանքը համապատասխանեցնում է պատվերին, բայց օպերատորն այն բեռնում և գործարկում է հաստոցի վրա։ Երրորդում MES-ը ստեղծում է Job Order, կառավարում է թույլատրելի անցումները և ընդունում Job Response-ը։ Հաջորդ մակարդակ անցեք միայն նախորդը կապի խզումների, վերագործարկումների և ձեռքով գործողությունների դեպքում փորձարկելուց հետո։

Իրականացում ընտրելիս պահանջեք ոչ թե «OPC UA-ն աջակցվում է» արտահայտությունը, այլ կոնկրետ NamespaceUri-ներ, NodeSet տարբերակներ, պրոֆիլներ և Conformance Units։ Job Control-ի համար հատկապես կարևոր է տարբերակը ամրագրելը. OPC 10031-4-ի 2-րդ տարբերակը պարունակում է 1-ինի հետ անհամատեղելի փոփոխություններ և օգտագործում է նոր անունների տարածք։ Հին մոդելի համար գրված հաճախորդը հանգույցների հասցեները փոխելուց հետո համատեղելի չի դառնա։

Ստուգեք նաև OPC 40001-3 Machinery Job Management-ը։ Հիմնական պրոֆիլը պահանջում է JobOrderControl և JobOrderResults, բայց առանձին պլանային պարամետրեր և արդյունքներ տեղափոխված են տարբեր Conformance Units-ներ։ Սերվերը կարող է ազնվորեն աջակցել հիմնական մոդելին և չունենալ ձեզ անհրաժեշտ PlannedOrderQuantity-ը, նյութերի արդյունքը կամ արտադրողականության մասին տեղեկությունը։ Սա պարզում են պրոֆիլով և փորձարկմամբ, ոչ թե գովազդային նկարագրությամբ։

EAST CNC-ից հաստոց ընտրելիս և գործարկման-կարգաբերման ընթացքում արժե ինտեգրման պրոֆիլը ներառել տեխնիկական առաջադրանքում մինչև մատակարարումը. հետո իմաստների համաձայնեցումը գրեթե միշտ ավելի թանկ է, քանի որ MES-ը, դարպասն ու PLC-ն արդեն գրված են տարբեր ենթադրությունների հիման վրա։

Ընդունումը պետք է կոտրի երջանիկ սցենարը

Ինտեգրումը պատրաստ է, երբ կանխատեսելիորեն դիմանում է խափանումներին, ոչ թե երբ մեկ պատվեր հաջող անցել է ստենդում։ Ընդունման փորձարկումները պետք է ներառեն մեթոդների կրկնություններ, կապի խզում և հակասող հրամաններ։

Անցկացրեք առնվազն հինգ ստուգում.

1. Մեկ jobOrderId ուղարկեք երկու անգամ և համոզվեք, որ սերվերը երկու աշխատանք չի ստեղծել։
2. Կտրեք կապը առաջադրանքն ընդունելուց հետո, բայց մեթոդի պատասխանից առաջ, հետո վերականգնեք վիճակը՝ առանց կրկնակի գործարկման։
3. Փորձեք փոխել քանակը գործարկումից առաջ և կատարման ընթացքում՝ համեմատելով թույլատրելի անցումները։
4. Կատարեք դադար, շարունակություն, կառավարվող կանգառ և չեղարկում այն վիճակներում, որոնց համար սարքավորումը հայտարարում է աջակցություն։
5. Ավարտեք առաջադրանքը մասնակիորեն, խոտանով և նյութի խմբաքանակի փոխարինմամբ, հետո ստուգեք Job Response-ը MES-ում։

Յուրաքանչյուր փորձարկման համար նախօրոք սահմանեք սպասվող վիճակը, մեթոդի կոդը, գրանցամատյանի գրառումը և բիզնես արդյունքը։ «Սխալ հայտնվեց» ձևակերպումը պիտանի չէ ընդունման համար։ Պետք են կոնկրետ StatusCode, ReturnStatus, jobOrderId-ի պահպանված լինելը և հաստոցի անցանկալի շարժման բացակայությունը։

Եթե MES-ը միայն դիտարկում է, Job Control-ը թողեք նախագծից դուրս և մանրակրկիտ սահմանեք հեռաչափությունը։ Եթե MES-ը տնօրինում է աշխատանքը, առաջադրանքի մոդելը ընդունեք թեգերը գրելուց առաջ։ Հակառակ դեպքում թիմն ամեն դեպքում կկառուցի Job Control, բայց պատահականորեն՝ վթարային ուղղում առ վթարային ուղղում։