Arhitectura software de control a automatizării: PLC, WCS, WES, WMS

În spatele fiecărui transportor, sorter și celule robotice se află un stivă de straturi software de control pe care majoritatea personalului de depozit nu le vede niciodată direct, dar a cărei arhitectură determină cât de flexibilă, scalabilă și mentenabilă se dovedește investiția în automatizare pe durata sa de exploatare.

Controlul automatizării de depozit este de obicei organizat pe straturi, fiecare responsabil pentru un scop și un interval de timp diferit al deciziei. La bază, controlerele logice programabile (PLC) gestionează controlul în timp real, la nivel de milisecundă, al motoarelor, senzorilor și actuatoarelor individuale. Deasupra, un sistem de control al depozitului (WCS) coordonează logica la nivel de echipament pe o zonă — direcționând o cutie printr-un sorter, secvențiind o îmbinare de transportoare. Deasupra acestuia, un sistem de execuție a depozitului (WES) ia decizii de orchestrare de nivel mai înalt pe mai multe tipuri de echipamente și fluxuri de lucru, iar în vârf, sistemul de management al depozitului (WMS) deține adevărul despre stoc și comenzi și emite lucru către stratul de execuție.

• Controlul de siguranță și motor în timp real trebuie să rămână în stratul PLC, întrucât straturile superioare nu pot garanta timpi de răspuns la milisecundă
• Logica de rutare specifică echipamentului aparține WCS-ului, izolând WMS-ul de necesitatea de a cunoaște numerele de jgheab specifice sorterului
• Orchestrarea cross-sistem, precum secvențierea zonei care eliberează prima lucrul într-un val, aparține WES-ului sau stratului de orchestrare
• Regulile de business pentru stoc și comenzi rămân în WMS, care nu ar trebui niciodată să aibă nevoie de cunoștințe specifice echipamentului pentru a funcționa

Furnizorii de echipamente de automatizare adesea includ un WCS proprietar strâns cuplat cu hardware-ul lor, ceea ce simplifică implementarea inițială, dar creează dependență (lock-in) când facilitatea dorește ulterior să adauge echipamente de la un al doilea furnizor sau să înlocuiască un subsistem. Facilitățile care planifică o foaie de parcurs de automatizare în mai multe faze specifică din ce în ce mai des din start un strat de orchestrare agnostic față de echipament, cu un contract de interfață standard pe care WCS-ul fiecărui furnizor trebuie să-l suporte, astfel încât adăugările viitoare de echipamente să nu necesite rearhitecturarea întregii stive de control.

O stivă de control bine arhitecturată conține eșecurile în stratul lor de origine, în loc să lase o singură defecțiune de transportor să se propage într-o întrerupere completă a sistemului de management al depozitului. Asta înseamnă de obicei că straturile WCS și PLC pot continua să opereze echipamentul deja în mișcare și să oprească în siguranță eliberările noi, chiar dacă conexiunea cu WMS-ul se pierde temporar, în loc să necesite oprirea întregii stive la orice defecțiune de legătură. Facilitățile ar trebui să testeze explicit acest comportament de mod degradat în timpul punerii în funcțiune, nu să presupună că funcționează doar pe baza documentației furnizorului.

Diagnosticarea unei probleme de throughput într-o arhitectură de control multi-strat necesită vizibilitate simultană în toate straturile, întrucât o încetinire care pare o problemă de WMS poate proveni de fapt dintr-o defecțiune de senzor la nivel PLC, trei straturi mai jos. Facilitățile care investesc într-un strat unificat de logging și monitorizare care acoperă PLC, WCS, WES și WMS rezolvă incidentele mult mai rapid decât cele care se bazează pe instrumentul de diagnostic separat al fiecărui furnizor, unde corelarea marcajelor temporale între sisteme devine un exercițiu manual, consumator de timp, în timpul unei întreruperi active.