OEE i Plant Historian: gdzie powinny być przechowywane dane szeregów czasowych

Kluczowe wnioski

• Historian = baza danych szeregów czasowych o wysokiej częstotliwości przechowująca każdy tag PLC z rozdzielczością poniżej sekundy.
• Platformy OEE potrzebują danych o jakości historian: każda zmiana stanu, każdy cykl, każdy błąd, z znacznikiem czasu i możliwe do odzyskania.
• Można uruchomić OEE bez dedykowanego historian, jeśli sama platforma OEE przechowuje dane z częstotliwością typową dla historianów. Wiele platform to robi.
• Typowe dedykowane historiiany: OSIsoft PI (obecnie AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian. Odpowiedniki w chmurze: InfluxDB, TimescaleDB, AWS Timestream.
• Zakłady posiadające istniejący historian zazwyczaj zasilają z niego platformę OEE; zakłady bez historianu często pozwalają, aby platforma OEE pełniła rolę historianu dla danych produkcyjnych.

Krótko: Historian zakładowy to baza danych szeregów czasowych o wysokiej częstotliwości przechowująca każdy tag PLC z rozdzielczością poniżej sekundy. Platformy OEE albo czytają z istniejącego historianu, albo same przechowują dane z taką częstotliwością. Pytanie nie brzmi „czy potrzebuję historianu czy platformy OEE”, brzmi „gdzie przechowywane są dane szeregów czasowych i czy rozdzielczość jest wystarczająca do wspierania analiz OEE”. Zobacz także OEE vs Wykorzystanie.

Czym jest historian

Historian to wyspecjalizowana baza danych zoptymalizowana pod dane szeregów czasowych, miliony krotek (znacznik czasu, tag, wartość) na sekundę, przechowywane przez lata, możliwe do odzyskania dla dowolnego okna czasowego. Typowe zastosowania:

• Wykresy trendów procesów na długich przedziałach czasowych.
• Śledzenie i audyt wymagany przez przepisy dla zapisów wsadowych.
• Analizy niezawodności zachowania urządzeń.
• Badanie przyczyn źródłowych przy odchyleniach jakości.

Typowe dedykowane historiiany: OSIsoft PI (obecnie AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian (obecnie AVEVA Insight). W chmurze / open-source: InfluxDB, TimescaleDB, AWS Timestream, Azure Time Series Insights.

Dlaczego OEE potrzebuje danych klasy historian

Obliczenia OEE wymagają precyzyjnego śledzenia stanów w czasie:

• Zmiany stanu pracy oznaczone znacznikiem czasu z dokładnością do sekundy.
• Liczba cykli zliczana na część, a nie agregowana na godzinę.
• Kody błędów rejestrowane w momencie ich wystąpienia, a nie dopiero gdy ktoś je później wprowadzi.
• Sygnały jakości powiązane z cyklem, z którego pochodzą.

Utrata któregokolwiek z tych elementów sprawia, że OEE staje się przybliżeniem. Historian (lub magazyn danych o klasie historian wewnątrz platformy OEE) sprawia, że OEE jest wystarczająco precyzyjne, by można było na jego podstawie podejmować działania.

Dwie architektury

Architektura A: dedykowany historian zasila OEE. Zakład ma istniejące PI lub InfluxDB. Platforma OEE subskrybuje odpowiednie tagi i oblicza OEE w czasie rzeczywistym, a historian pełni rolę długoterminowego magazynu.

Zalety: długoterminowe przechowywanie jest już rozwiązane. Wiele narzędzi może czytać z tego samego historianu.

Wady: kolejny system do utrzymania. Dodatkowa latencja związana z obiegiem danych.

Architektura B: platforma OEE jest historianem dla danych produkcyjnych. Brak dedykowanego historianu. Platforma OEE przechwytuje sygnały PLC bezpośrednio i przechowuje je wewnętrznie z wysoką częstotliwością.

Zalety: prostszy stos technologiczny. Niższa latencja.

Wady: długoterminowe przechowywanie może być ograniczone. Inni konsumenci danych (inżynieria, laboratorium) nie będą mogli łatwo zapytać o dane.

Większość zakładów z sektora MŚP dobrze funkcjonuje z architekturą B dla danych produkcyjnych. Zakłady wymagające śledzalności regulacyjnej (farmacja, żywność) zazwyczaj potrzebują dedykowanego historianu bez względu na to.

Czego szukać w warstwie danych platformy OEE

• Natychmiastowa (natywna) baza danych szeregów czasowych. Nie ogólna relacyjna baza danych dostosowana na siłę. Bazy dedykowane szeregom czasowym (InfluxDB, TimescaleDB, Cassandra z odpowiednim schematem TS) obsłużą wolumen poprawnie.
• Konfigurowalna retencja. Jak długo przechowywane są surowe dane? Jak długo przechowywane są agregaty?
• Downsampling / agregacja. Automatyczne agregowanie do niższej rozdzielczości w miarę starzenia się danych, aby utrzymać zarządzalny rozmiar magazynu.
• API zapytań. SQL, Flux lub REST, których inżynieria może używać bez przechodzenia przez UI platformy OEE.
• Integracja z zewnętrznymi historianami. Nawet jeśli platforma przechowuje własne dane, powinna móc czytać z PI / Aspen / Honeywell dla zakładów, które je posiadają.

Typowe błędy

1. Próbkowanie danych produkcyjnych z niską częstotliwością. Średnie minutowe pomijają mikroprzestoje i krótkie cykle. OEE zbudowane na agregatach minutowych to fikcja.

2. Traktowanie bazy SCADA jako historianu. Bazy SCADA są zoptymalizowane pod bieżący stan, a nie długoterminowe szeregi czasowe. Rozpadają się w skali.

3. Pomijanie planowania retencji. Trzy lata danych PLC o wysokiej częstotliwości zajmują dużo miejsca. Planowanie downsamplingu trzeba zacząć od pierwszego dnia.

4. Brak zarządzania tagami. Dodawanie tagów bez spójnego nazewnictwa sprawia, że historian staje się nieużyteczny. Ustal konwencje nazewnictwa przed skalowaniem.

Jak platformy OEE odnoszą się do PI i podobnych

W zakładach z PI platforma OEE jest zazwyczaj klientem PI subskrybującym odpowiednie tagi. PI pozostaje systemem źródłowym dla danych szeregów czasowych; platforma OEE oblicza i prezentuje OEE na jego bazie.

W zakładach bez PI platforma OEE często w praktyce pełni rolę historianu dla danych produkcyjnych, co jest wystarczające dla większości zastosowań, ale nie zastępuje PI w zastosowaniach inżynieryjnych procesów ani w archiwach regulacyjnych.

Moduł OEE Fabrico jest dostarczany z wewnętrznym magazynem szeregów czasowych i integruje się z zewnętrznymi historianami (PI, InfluxDB, TimescaleDB) dla zakładów, które je posiadają, dając zespołowi elastyczność w warstwie danych.

Zobacz, jak Fabrico przechwytuje to automatycznie, poznaj OEE dla produkcji lub zarezerwuj demo.

Polecane lektury

• OEE vs Wykorzystanie
• OEE i ISO 22400
• OEE dla produkcji wsadowej
• OEE vs Dostępność

Najczęściej zadawane pytania

Czy potrzebuję dedykowanego historianu, jeśli mam platformę OEE?

Zwykle nie dla samych danych produkcyjnych. Tak, jeśli masz wymagania śledzalności regulacyjnej, wielokonsumenckie wykorzystanie danych lub potrzeby inżynierii procesowej wykraczające poza OEE.

Czy mogę użyć zwykłej bazy SQL jako historianu?

Sprawdzi się na małą skalę. W skali przemysłowej (tysiące tagów, rozdzielczość w milisekundach, lata retencji) potrzebujesz magazynu dedykowanego szeregom czasowym.

Jak długo powinienem przechowywać surowe dane?

Zależy od zastosowania. Do rozwiązywania problemów produkcyjnych zwykle potrzeba 30, 90 dni surowych danych; trendy długoterminowe mogą być przechowywane jako zdownsample'owane agregaty.

Czy InfluxDB to to samo co PI?

Obie to bazy danych szeregów czasowych. PI jest długoletnim przemysłowym standardem z dojrzałymi integracjami. InfluxDB jest popularne w środowiskach open source i chmurowych. Obie nadają się do OEE.

Czy platforma OEE może zapisywać dane z powrotem do historianu?

Niektóre potrafią. Przydatne do zapisywania obliczonych wartości OEE obok surowych tagów PLC, aby zewnętrzni konsumenci mogli odczytywać OEE z tego samego źródła.