Tapşırıq modeli olmadan OPC UA MES üçün kifayət deyil

OPC UA qoşulmanı, məlumatların oxunmasını, abunəlikləri, metodları və kanalın təhlükəsizliyini yaxşı həll edir. Amma dəzgahda OPC UA-nın olması hələ MES-in istehsal tapşırığını başa düşdüyü, onu növbəyə ala bildiyi və icra barədə birmənalı hesabat alacağı demək deyil.

Sistemə yalnız rejim, qəzalar, sayğaclar və cari yük lazımdırsa, ISA-95 Job Control əlavə etməyə tələsməyin. MES sifarişi, miqdarı, proqramı, material tələblərini ötürməli, işə başlamağa icazə verməli, işi dayandırmalı və nəticəni qəbul etməlidirsə, ixtiyari teqlər artıq kifayət etmir. Layihə komandası bunu standarta tam uyğun həyata keçirməmək qərarına gəlsə belə, razılaşdırılmış tapşırıq modeli lazımdır.

OPC UA əlaqəni həll edir, tapşırığın mənasını yox

OPC UA mübadilə vasitələri verir, amma məlumatların mənası yalnız informasiya modelində yaranır. Server ProductionOrder adlı String tipli dəyişəni dərc edə bilər və istənilən müştəri onu səhvsiz oxuyar. Ancaq həmin sətirdən bunun ERP sifarişinin nömrəsi, növbə tapşırığı, partiya, marşrut əməliyyatı, yoxsa idarəetmə proqramının adı olduğu bilinmir.

Layihələrdə bu fərq tez-tez itir. Protokol «necə oxumaq», «metodu necə çağırmaq», «necə abunə olmaq» və «kimin girişi var» suallarına cavab verir. İstehsal modeli isə «dəqiq nə tapşırılıb», «hansı resurs lazımdır», «tapşırığı dəyişmək olarmı» və «hansı nəticə hansı sifarişə aiddir» suallarını cavablandırır.

OPC Foundation bu modeli OPC 10031-4, OPC UA for ISA-95, Part 4: Job Control sənədində təsvir edir. Sənəd Job Order, Job Response, növbədə olan, icra edilən və tamamlanmış tapşırıqlara giriş, həmçinin onların idarəetmə metodlarını müəyyən edir. Bu, OPC UA-ya rəqib deyil, onun üzərində işləyən companion specification-dır.

Ümumi təyinatlı avadanlıq üçün daha bir sənəd var: OPC 40001-3, OPC UA for Machinery, Part 3: Job Management. O, Job Control tiplərindən istifadə edir və dəzgahlar üçün parametrləri dəqiqləşdirir: planlaşdırılmış miqdar, işə salma sayı, plan vaxtı, icra rejimi, sifariş nömrələri və nəticə məlumatları. OPC UA for Machine Tools-un 1.02 versiyasında əvvəlki ProductionType modeli artıq köhnəlmiş kimi qeyd olunub və gələcəkdə Machinery Job Management ilə əvəzlənəcəyi göstərilib. Yalnız köhnə production teqləri siyahısına əsaslanaraq yeni dəzgah almaq, sonradan adapteri yenidən yazmağı əvvəlcədən planlamaq deməkdir.

Daha bir sərhəd də var. ISA-95 Job Control detalın emalının texnoloji məntiqini müəyyən etmir. Verişlər, alət korreksiyaları, patron keçidləri, bloklamalar və təhlükəsiz dayandırma CNC və PLC-də qalır. MES tapşırığı idarə edir, oxların hərəkətini yox.

Monitorinq üçün Job Control lazım deyil

MES və ya ayrıca monitorinq sistemi dəzgahın işini idarə etmirsə, sadə parametr toplamaq tapşırıq modeli tələb etmir. Yüklənməni hesablamaq və boşdayanmaları təhlil etmək üçün adətən strukturlaşdırılmış telemetriya kifayətdir.

Monitorinqin minimal müqaviləsinə bunlar daxildir:

• avadanlığın vəziyyəti və iş rejimi;
• avtomatik dövrün aktivliyi və dayanma səbəbi;
• yararlı və yararsız detalların sayğacları;
• kodu, yaranma və təsdiq vaxtı olan qəzalar;
• dəzgah artıq bilirsə, aktiv proqramın və ya cari tapşırığın identifikatoru.

Hər dəyərin mənbəyi, tipi, ölçü vahidi, zaman nişanı və OPC UA StatusCode-u olmalıdır. Sıfırlama qaydası olmayan sayğac faydasızdır. Tərifi olmayan Running vəziyyəti də faydasızdır: bir təchizatçı mili fırlananda, digəri aktiv proqram olduqda, üçüncüsü qəza siqnalı götürüldükdə dəzgahı işləyən sayır.

Bu ssenaridə OPC UA abunəlikləri adətən tez-tez sorğulamaqdan yaxşıdır. Müştəri dəyişiklikləri serverin zaman nişanları və keyfiyyət nəzarəti ilə alır. Dərcetmə tezliyi vəzifəyə uyğun olmalıdır: dispetçer ekranına kontroller periodu ilə axın lazım deyil, qısa dayanmalarda isə seyrək nümunə götürmə təhlili mənasız edir.

Sifarişi hər temperatura və hər ox mövqeyinə bağlamağa çalışmayın. Telemetriya fiziki obyektin vəziyyətini təsvir edir. İstehsal konteksti bu məlumatların bir hissəsini konkret işlə əlaqələndirir. İki qatı qarışdırsanız, sifariş nömrəsinin dəyişməsi tarixi trendləri pozar, sensorun dəyişdirilməsi isə MES modelini düzəltməyi tələb edər.

Praktik meyar sadədir: əlaqə qırıldıqda MES dəzgaha heç nəyi yenidən göndərməməlidirsə və əlaqə bərpa olunandan sonra oxumağı davam etdirməsi kifayətdirsə, Job Control hələ məcburi deyil. Mesajın itməsi iki tapşırıq, səhv proqram və ya bağlanmamış sifariş buraxa biləndə hər şey dəyişir.

MES Job Order yarandıqda idarə etməyə başlayır

Yuxarı sistem konkret iş mərkəzinə bir iş vahidi tapşıranda Job Order modeli lazımdır. ISA-95 Job Order-i işin yerinə yetirilməsi tələbi adlandırır və istehsal cədvəlinin strukturunda onu Work Request-dən aşağıda yerləşdirir. Metal emalında belə vahid çox vaxt müştərinin bütün sifarişi yox, konkret dəzgahdakı sifariş əməliyyatı olur.

Yaxşı tapşırıq ən azı bu suallara cavab verir:

• onun sabit identifikatoru nədir və hansı sifarişə aiddir;
• nə istehsal olunmalıdır və hansı miqdarda;
• iş üsulunu hansı Work Master, marşrut, proqram və ya sənəd redaktəsi müəyyən edir;
• hansı avadanlıq, material, ləvazimat və ya ixtisas tələb olunur;
• tapşırığı nə vaxt işə salmağa icazə verilir və onun prioriteti nədir.

İdarəetmə proqramının nömrəsi olan sahə Work Master-i əvəz etmir. İdarəetmə proqramı konkret CNC sistemində emalı təsvir edir. İstehsal tərifinə həmçinin quraşdırma kartı, nəzarət planı, bərkitmə təlimatı, çertyojun versiyası və qüsurun qeydə alınması qaydaları daxil ola bilər. MES təsdiqlənmiş komplektə istinad edə bilər, dəzgahın lokal sistemi isə lazım olan versiyanın əlçatanlığını yoxlamalıdır.

Hər tələb kontrollerə çatmalı deyil. Operatorun ixtisas tələbi sahə terminalında yoxlana bilər. Pəstah partiyasını skaner təsdiqləyə bilər. Qurğunun identifikatorunu PLC və ya operator yoxlaya bilər. Job Order bütün bu tələbləri bir kontekstdə birləşdirir, amma bir serveri hamısını icra etməyə məcbur etmir.

Prioritet və başlama vaxtı da dərhal işə salma əmri demək deyil. OPC 40001-3 bir neçə icazəli tapşırıq arasında əvvəlcə StartTime, sonra Priority üzrə sıra müəyyən edir. Bərabərlik olduqda seçim tətbiqdən asılı qalır. Bu, məntiqli qeyd-şərtdir. Planlaşdırıcı ardıcıllığı təklif edir, dəzgah isə yalnız lokal hazırlıq yoxlanandan sonra işə başlayır.

Job Response istehsal dövrəsini bağlayır

Job Response MES üçün Job Order qədər vacibdir, çünki təsdiqlənmiş nəticəsi olmayan komanda sifarişi qeyri-müəyyən vəziyyətdə saxlayır. Standart cavabı tapşırıq üzrə görülmüş işin hesabatı kimi müəyyən edir və sifarişdəki tələbləri cavabdakı faktiki məlumatlardan ayırır.

Bu ayrımı çox vaxt bir Material obyekti ilə pozurlar. Sifarişdə material tələb deməkdir: marka, ölçü, partiya və ya icazəli sinif. Cavabda Material Actual faktiki istifadə olunanı göstərir. Tələbi faktla əvəz etsəniz, MES partiyanın dəyişdirildiyini aşkar etməz və izlənəbilənliyi bərpa edə bilməz.

Eyni məntiq avadanlığa, fiziki aktivlərə və personala da aiddir. Equipment Requirement müəyyən sinifdə dəzgah tələb edə bilər. Equipment Actual konkret iş mərkəzini qeyd edir. Physical Asset Requirement ölçü cihazının tipini təsvir edə bilər, Physical Asset Actual isə faktiki istifadə olunan cihazın identifikatorunu saxlayır. Bu cütlər gözəl iyerarxiya üçün deyil, keyfiyyət şöbəsinin adi sualına cavab vermək üçündür: «Məhz bu partiya nədə və nədən hazırlanıb?»

Cavab uzun əməliyyat üçün aralıq vəziyyəti, tamamlanandan sonra isə yekun nəticəni ehtiva etməlidir. OPC 40001-3 Unknown, Successful və Unsuccessful dəyərləri olan JobResult, habelə buraxılış və məhsuldarlıq məlumatlarını nəzərdə tutur. Təkcə Successful kifayət deyil: MES-ə faktiki miqdar, qüsur, başlama və bitmə vaxtı, lazım olduqda isə alınmış detalların və ya partiyaların identifikatorları lazımdır.

Vəziyyəti və nəticəni birləşdirmək olmaz. Running cari mərhələni təsvir edir. Successful tamamlanmış işi qiymətləndirir. Dəzgah daha az miqdar istehsal etdikdən sonra normal qaydada dayana bilər, biznes sistemi isə sifarişin bağlanmış sayılıb-sayılmayacağına qərar verər. Kontroller faktı bildirir, MES istehsal qaydasını tətbiq edir.

Sifarişin bir sətri qaçılmaz olaraq genişlənir

Özəl inteqrasiya adətən ilk uğurlu işə salmadan sonra, real istisnalar əlavə ediləndə pozulmağa başlayır. Nümayişdə MES OrderNo, PartNo, Quantity və Start bitini yazır. PLC proqramı yerinə yetirir, Produced dəyərini artırır və Done təyin edir.

Sonra Start yazıldıqdan, amma təsdiq oxunmazdan əvvəl şəbəkə kəsilir. MES yazmanı təkrar edir. PLC bitin yüksələn kənarını yeni komanda kimi qəbul edirsə, tapşırıq ikinci dəfə işə düşür. Bit təyin olunmuş qalırsa, yeni işə salma baş verməz, amma MES dəzgahın birincini qəbul edib-etmədiyini bilmir. Komanda Ack, sonra sıra nömrəsi, ardınca Busy, taym-aut və əl ilə sıfırlama əlavə edir.

Daha sonra planlaşdırıcı işə salınmazdan əvvəl miqdarı dəyişir. Operator materialı artıq yükləyibsə, Busy=0 olduqda sahələri dəyişməyin mümkün olub-olmadığı aydın deyil. Locked yaranır. Sonra operator ilk detalı ölçmək üçün tapşırığı fasiləyə qoyur. Texnoloji fasiləni, qəzanı və ləğvi fərqləndirmək lazımdır. Pause, Hold, Fault, Cancel, Abort və MES-lə PLC-nin fərqli yozduğu bir neçə keçid cədvəli yaranır.

Bundan sonra qismən yerinə yetirilmiş sifarişin uçotu tələbi gəlir. Köhnə Done sahəsi 100 detaldan 80-nin hazırlanıb-hazırlanmadığını, qalan 20-nin ləğv edililib-edilmədiyini və eyni nömrə ilə davam tapşırığının yaradılmasının mümkün olub-olmadığını demir. Komanda icra partiyasının nömrəsini əlavə edir. Bir ildən sonra layihədə öz tapşırıq modeli yaranır, sadəcə ümumi terminologiya, uyğunluq profilləri və növbəti dəzgah təchizatçısı üçün sənədləri olmur.

«Dörd teqlə başlayaq, sonra genişləndirərik» kimi məşhur məsləhət kiçik başlanğıca görə pis deyil. Bu dörd teq artıq xarici müqavilə kimi istifadə ediləndə, komandanın sabit identifikatoru, müəyyən edilmiş vəziyyət maşını və təkrar göndərmə qaydaları olmayanda pisdir. Komanda sərhədləri dərhal müəyyənləşdirirsə və müvəqqəti sxemi hazır arxitektura kimi təqdim etmirsə, kiçik pilot mümkündür.

Job Control səhvləri avtomatik aradan qaldırmır. O, istismara verilməzdən əvvəl obyektləri, vəziyyətləri və metodları adlandırmağa məcbur edir. Məhz bu iş adətən MES-in, PLC proqramçısının və texnoloqun «tapşırıq» sözünə fərqli məna verdiyini üzə çıxarır.

Məlumat müqaviləsi teqlər siyahısından vacibdir

İşlək müqavilə təkcə sahələri deyil, istiqaməti, məcburiliyi, dəyərin sahibini və təkrara reaksiyanı da göstərməlidir. Aşağıda torna əməliyyatı üçün tapşırığın qısaldılmış təqdimatı verilir. Bu, OPC UA proqramlaşdırması və ya ISA95JobOrderDataType-ın dəqiq serializasiyası deyil, MES, şlüz və dəzgah sistemi arasında razılaşdırmaq üçün yoxlanıla bilən layihə artefaktıdır.

{
  "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"
    }
  ]
}

Buradakı jobOrderId əməliyyatın konkret icrasına aiddir. Eyni identifikatorun təkrar göndərilməsi ikinci tapşırıq yaratmamalıdır. Planlaşdırıcı bilərəkdən yeni redaksiya buraxırsa, yeni identifikator yaradır və ya dəyişiklik qadağan olunan vəziyyətə keçməzdən əvvəl standartın icazə verdiyi Update tətbiq edir. Qayda əvvəlcədən seçilir və sınaq stendində yoxlanır.

Cavab eyni identifikatora istinad etməli və faktları plandan ayırmalıdır:

{
  "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"
    }
  ]
}

Belə nümunə dərhal narahat suallar yaradır. Qüsur producedQuantity-yə daxildirmi? Uğurlu tapşırıqda qüsur ola bilərmi? materialLotId-ni kim təyin edir? İki metal partiyası necə bildirilir? Nəticə nə vaxt yekun sayılır? Cavablar yazılmayana qədər inteqrasiya fərziyyələr toplusu olaraq qalır.

Vəziyyət maşını ikiqat icradan qoruyur

Müəyyən edilmiş vəziyyət keçidləri təkrar işə salma və mübahisəli komandalar riskini azaldır, ancaq müştəri və server onlara birlikdə əməl edərsə. OPC 10031-4 tapşırıq qəbuledicisini Store, StoreAndStart, Start, RevokeStart, Pause, Resume, Update, Abort, Stop, Cancel və Clear metodları ilə təsvir edir.

Adlar adi düymələrə oxşayır, amma fərqlər əhəmiyyətlidir. Pause davam etdirmək imkanını nəzərdə tutur. Stop avadanlıq qaydalarına uyğun idarə olunan şəkildə icranı tamamlayır. Abort normal davam etməyə artıq ehtiyac olmadıqda tətbiq edilir. Cancel yerinə yetirilməməli olan tapşırığa aiddir. Layihə bu niyyətləri CNC və PLC-nin real imkanlarına uyğunlaşdırmalıdır. Dəzgah dövrü bunu təhlükəsiz dəstəkləmirsə, MES-ə davam etməklə fasilə vəd etmək olmaz.

StoreAndStart da şərtsiz fiziki işə salma demək deyil. Modeldə tapşırıq icraya icazə alır, bundan sonra sistem resursları, prioritetləri və lokal şərtləri nəzərə alır. Texnologiya və ya risk qiymətləndirməsi tələb edirsə, «Dövrü işə sal» düyməsi operatorda qala bilər.

Taym-autdan sonra müştəri komandanı kor-koranə təkrarlamamalıdır. Etibarlı ardıcıllıq belədir: MES jobOrderId-ni və cəhd identifikatorunu saxlayır, metodu çağırır, cavab itərsə tapşırıqların siyahısını və cari vəziyyəti oxuyur. Təkrar yalnız serverin ilkin tapşırığı qəbul etmədiyi yoxlanandan sonra mümkündür. Burada idempotentlik nəqliyyatın sehri yox, razılaşdırılmış davranışın xüsusiyyətidir.

OPC 10031-4-ün B əlavəsində metodların nəticə kodları UInt64 bit maskası ilə müəyyən edilir. Standart səbəblər arasında naməlum tapşırıq identifikatoru, yanlış vəziyyət, tapşırığı qəbul etməyin mümkün olmaması və səhv sorğu var. MES-in hər koda gözlənilən reaksiyasını yazın. Unable to accept Job Order üçün sonsuz avtomatik təkrar müvəqqəti problemi tezliklə eyni mesajlar növbəsinə çevirir.

Təhlükəsiz kanal MES-ə təhlükəli komandaya hüquq vermir

OPC UA təhlükəsizlik mexanizmləri bağlantını qoruyur, amma layihəçi yenə də müştərinin səlahiyyətlərini və dəzgahın hər vəziyyətində əlçatan komandaları məhdudlaşdırmalıdır. Sertifikat bağlantı tərəfini təsdiqləyir və yoldakı məlumatları qorumağa kömək edir. O, planlaşdırıcı hesabının emal zamanı Abort çağırmaq hüququna malik olub-olmaması məsələsini həll etmir.

Ən azı monitorinqin oxunmasını, tapşırığın yüklənməsini, icraya icazəni və qəza müdaxiləsini ayırın. MES-in servis hesabı sınaq stendini işə salmaq daha rahat olduğuna görə serverdə inzibati hüquqlara sahib olmamalıdır. Müştərinin identifikatorunu, metodu, jobOrderId-ni, vaxtı, ilkin vəziyyəti və çağırış nəticəsini ayrıca jurnallaşdırın.

Müəssisə şəbəkəsi də lokal təhlükəsizliyi əvəz etmir. PLC və CNC MES komandasından asılı olmayaraq qoruyucuları, sıxmanı, ötürücülərin hazırlığını, proqramın mövcudluğunu və başqa şərtləri yoxlamalıdır. Yuxarı sistem icazəli tapşırığı işə salmağı istəyə bilər, amma qoruma dövrələrini və dəzgah məntiqini keçməməlidir.

Əlaqə itdikdə davranışı əvvəlcədən düşünün. İcra olunan əməliyyat adətən ya lokal olaraq təhlükəsiz davam etməli, ya da əvvəlcədən müəyyən edilmiş qayda ilə dayanmalıdır. Bu qərarı müştəri kitabxanasının taym-autuna buraxmaq olmaz. Əlaqə bərpa olunandan sonra MES köhnə nüsxəsindən dəzgaha vəziyyət təyin etməməli, faktiki vəziyyəti və nəticələri almalıdır.

Tam modeli məsuliyyət sərhədinə görə tətbiq etmək lazımdır

Hər müəssisəyə ilk buraxılışda bütün ISA-95 modeli lazım deyil. MES-in faktiki məsuliyyətini bağlayan və identifikatorların mənasını dəyişmədən inkişaf etməyə imkan verən minimal profil lazımdır.

Tətbiqi üç səviyyəyə bölmək rahatdır. Birinci səviyyədə MES yalnız unifikasiya olunmuş telemetriyanı oxuyur. İkinci səviyyədə o, aktiv lokal tapşırığı sifarişlə əlaqələndirir, amma operator onu dəzgahda yükləyir və işə salır. Üçüncü səviyyədə MES Job Order yaradır, icazəli keçidləri idarə edir və Job Response qəbul edir. Növbəti səviyyəyə yalnız əvvəlkini əlaqə qırılmalarında, yenidən işə salmalarda və əl ilə edilən hərəkətlərdə sınaqdan keçirdikdən sonra keçin.

Həll seçərkən «OPC UA dəstəklənir» ifadəsini yox, konkret NamespaceUri-ni, NodeSet versiyalarını, profilləri və Conformance Units-ləri istəyin. Job Control üçün versiyanı qeydə almaq xüsusilə vacibdir: OPC 10031-4-ün 2-ci versiyası 1-ci versiya ilə uyğun olmayan dəyişikliklər ehtiva edir və yeni ad məkanından istifadə edir. Köhnə model üçün yazılmış müştəri sadəcə qovşaq ünvanları dəyişdiriləndə uyğun olmayacaq.

OPC 40001-3 Machinery Job Management-i də yoxlayın. Əsas profil JobOrderControl və JobOrderResults tələb edir, amma ayrı-ayrı plan parametrləri və nəticələr müxtəlif Conformance Units-lərə çıxarılıb. Server əsas modeli dürüst şəkildə dəstəkləyə, amma sizə lazım olan PlannedOrderQuantity, material nəticələri və ya məhsuldarlıq məlumatına malik olmaya bilər. Bu reklam təsvirinə görə yox, profil və testlə aydınlaşdırılır.

EAST CNC ilə dəzgah seçimi və işə salınması zamanı inteqrasiya profilini təchizatdan əvvəl texniki tapşırığa daxil edin. Sonradan semantikanı razılaşdırmaq demək olar ki, həmişə baha başa gəlir, çünki MES, şlüz və PLC artıq fərqli fərziyyələr əsasında yazılıb.

Qəbul sınaqları uğurlu ssenarini pozmalıdır

İnteqrasiya bir sifariş sınaq stendindən uğurla keçəndə yox, nasazlıqlardan proqnozlaşdırıla bilən şəkildə çıxanda hazır sayılır. Qəbul sınaqlarına təkrar metodlar, bağlantının kəsilməsi və bir-birinə zidd komandalar daxil olmalıdır.

Ən azı beş yoxlama aparın:

1. Bir jobOrderId-ni iki dəfə göndərin və serverin iki iş yaratmadığına əmin olun.
2. Tapşırıq qəbul ediləndən, amma metod cavabından əvvəl əlaqəni kəsin, sonra təkrar işə salmadan vəziyyəti bərpa edin.
3. İcazəli keçidləri yoxlayaraq miqdarı işə salmadan əvvəl və icra zamanı yeniləməyə çalışın.
4. Avadanlığın dəstək verdiyini bildirdiyi vəziyyətlərdə fasilə, davam etdirmə, idarə olunan dayandırma və ləğv tətbiq edin.
5. Tapşırığı qismən, qüsurla və material partiyasını dəyişdirərək tamamlayın, sonra MES-də Job Response-u yoxlayın.

Hər test üçün gözlənilən vəziyyəti, metod kodunu, jurnal qeydini və biznes nəticəsini əvvəlcədən müəyyən edin. «Xəta yarandı» ifadəsi qəbul üçün yararsızdır. Konkret StatusCode, ReturnStatus, jobOrderId-nin qorunması və dəzgahın arzuolunmaz hərəkətinin olmaması lazımdır.

MES yalnız müşahidə edirsə, Job Control-u layihə hüdudlarından kənarda saxlayın və telemetriyanı dəqiq müəyyən edin. MES işə sərəncam verirsə, teqləri yazmazdan əvvəl tapşırıq modelini qəbul edin. Əks halda komanda yenə Job Control quracaq, amma bunu təsadüfən, hər dəfə bir qəza düzəlişi ilə edəcək.