Kluczowe wnioski
Na większości hal produkcyjnych jest dużo danych. PLC publikują wartości tagów w cyklu podsekundowym. SCADA agreguje i wizualizuje je. ERP otrzymuje liczby produkcji i zużycia.
Problem pojawia się między tymi warstwami: zatrzymanie na linii generuje przejście taga w PLC, staje się „zdarzeniem przestoju” w SCADA, zostaje podsumowane jako „utrata produkcji” w ERP i żadna z tych trzech reprezentacji nie zgadza się co do tego, czym to zdarzenie było, kiedy się rozpoczęło ani do którego aktywa należy.
W efekcie nikt nie potrafi w prosty sposób odpowiedzieć na podstawowe pytania operacyjne. „Ile przestoju spowodowało aktywo L3-PKG-02 wczoraj?” ma trzy różne odpowiedzi w zależności od systemu, o który zapytasz. Narzędzie OEE, CMMS i ERP mają własne definicje, a ręczne ich łączenie pochłania poranki kierownika utrzymania ruchu.
Typową pokusą, szczególnie w projektach sprzedawanych jako „integracja Przemysł 4.0”, jest przepuszczenie danych PLC bezpośrednio do ERP. Wygląda to na prostą integrację. Prawie zawsze kończy się niepowodzeniem z trzech powodów.
PLC wysyłają tysiące przejść tagów na minutę. ERP są zaprojektowane do otrzymywania kilkuset rekordów dziennie na zakład. Wpompowanie surowych danych z PLC do ERP albo zablokuje bazę danych, albo wymusi agresywną agregację na brzegu, a to właśnie ta agregacja niszczy rozdzielczość potrzebną dla OEE i CMMS.
PLC zna tagi. ERP zna centra kosztów. Żaden z nich nie zna hierarchii aktywów w taki sposób, jak robi to dział utrzymania (linia → stanowisko → aktywo → komponent). Bez wyraźnej hierarchii pomiędzy nimi nie da się z rekordów ERP odpowiedzieć na pytanie „które aktywo spowodowało ten przestój”.
Zdarzenia PLC mają precyzję milisekundową. Zdarzenia w ERP zwykle mają precyzję do dnia. Zatrzymanie, które zaczęło się o 14:03:22 i skończyło o 14:08:45, staje się „5 minutami przestoju 27 czerwca”, kiedy ERP to widzi. Utrata tej precyzji jest powodem, dla którego większość raportów OEE opartych na ERP jest bezużyteczna.
Rozwiązaniem jest wstawienie jednej warstwy między warstwą PLC/SCADA a ERP. Ta warstwa ma cztery zadania.
Każde zdarzenie, start, stop, wyrzut, przezbrojenie, ma wszędzie tę samą nazwę i ten sam format. Tutaj praktycznie zastosowana jest taksonomia klas strat opisana w artykule o wskaźnikach i metrykach utrzymania ruchu w produkcji. Bez niej analizy downstream nigdy się nie ustabilizują.
Warstwa operacyjna jest jedynym źródłem prawdy dla „czym jest aktywo”. Linie, stanowiska, aktywa i komponenty są definiowane tutaj i mapowane z jednej strony na tagi PLC, a z drugiej na centra kosztów w ERP. Kiedy utrzymanie tworzy zlecenie pracy, wskazuje aktywo w tej hierarchii, a nie tag ani centrum kosztów.
Każde zdarzenie przechowywane przez warstwę otrzymuje znacznik czasu względem jednego zegara, zwykle UTC z dokładnością do milisekundy, niezależnie od tego, który PLC, system SCADA czy interfejs operatora je wygenerował. Problemy ze strefami czasowymi i dryftem zegarów są eliminowane przy przyjęciu danych, a nie w dashboardach.
ERP otrzymuje zagregowany, dostosowany do potrzeb finansowych obraz: produkcja na zmianę, odpady, przestoje według przyczyny, na dzień lub zmianę. Szczegóły o wysokiej rozdzielczości pozostają w warstwie operacyjnej, gdzie potrzebują ich OEE, CMMS i analiza przyczyn źródłowych. Zobacz powiązany artykuł o analizie przyczyn źródłowych, by dowiedzieć się, dlaczego te szczegóły napędzają poprawę.
Typowa referencyjna architektura dla średniego rynku:
Powód, dla którego warstwa operacyjna powinna obsługiwać zarówno OEE, jak i CMMS, jest taki, że hierarchia aktywów jest współdzielona. Jeśli OEE znajduje się w jednym narzędziu z własną hierarchią, a CMMS w innym z inną hierarchią, główny sens warstwy, jedno źródło prawdy, zostaje utracony. Zintegrowany system zarządzania zleceniami pracy oparty na tych samych danych co silnik OEE zapobiega temu dryfowi z automatu.
Błąd, który popełniają zakłady, to zaczynanie od integracji z ERP, bo wydaje się ona „prawdziwym” rezultatem. Prawidłowa kolejność jest odwrotna.
Zaczynanie od integracji z ERP gwarantuje prace przerobkowe, ponieważ definicje operacyjne są nadal w toku i każdy rekord ERP będzie trzeba wysyłać ponownie w miarę stabilizowania się tych definicji.
Opisana powyżej warstwa danych operacyjnych to dokładnie to, czym jest Fabrico : jedna platforma, która hostuje hierarchię aktywów, strumień zdarzeń OEE oraz zlecenia pracy CMMS w tej samej bazie danych, z konektorami brzegowymi po stronie PLC i zaplanowanymi eksportami po stronie ERP.
Powód, dla którego dostarczamy to jako produkt zintegrowany, a nie dwa oddzielne, jest prosty: luka OT/IT zamyka się, gdy OEE i CMMS dzielą hierarchię, i pozostaje otwarta, gdy jej nie ma. Aby zobaczyć, jak wyglądałoby to na danych z twojej linii, umów demo .
Nie. Warstwa danych operacyjnych działa na istniejącym stosie OT za pośrednictwem konektora brzegowego. Warstwa PLC/SCADA nadal robi swoje; nowa warstwa jedynie dodaje nad nią znormalizowany widok.
Jezioro danych bez warstwy danych operacyjnych przechowuje dane tagów o wysokiej rozdzielczości bez semantyki zdarzeń. Można zbudować nad tym pulpity, ale nie można generować zleceń pracy, obliczać OEE ani prowadzić analizy przyczyn źródłowych bez uprzedniego odtworzenia słownictwa zdarzeń i hierarchii aktywów, czyli dokładnie tego, co robi warstwa operacyjna. Pominiecie jej tylko odwleka problem.
Jeśli zakład ma już MES, MES często pokrywa część zadań warstwy danych operacyjnych, szczególnie słownictwo zdarzeń. Architektura działa tak samo: MES zasila warstwę operacyjną (lub sam jest warstwą operacyjną, jeśli obejmuje OEE i CMMS), która następnie agreguje dane do ERP.
Przez zespół zakładu, który zna aktywa, a nie przez dział IT. Warstwa operacyjna musi umożliwiać edycję hierarchii przez inżynierów utrzymania ruchu i produkcji bez udziału programisty, inaczej przestanie być aktualna w ciągu kwartału.
Słownictwo zdarzeń. Jeśli klasy strat nie są stabilne między liniami, każda analiza i każda reguła downstream stają się zawodnę. Poświęć na taksonomię w pierwszym tygodniu więcej czasu, niż wydaje się rozsądne.
Zaloguj
Blog
