Kluczowe wnioski
Krótka odpowiedź: Historyk danych i relacyjna baza danych to dwa sposoby przechowywania danych, zoptymalizowane pod różne rodzaje danych.
Historyk danych (lub historyk procesów) to oprogramowanie zaprojektowane do przechwytywania, kompresji i przechowywania wysokoczęstotliwościowych danych szeregów czasowych z procesów przemysłowych, tysiące odczytów tagów na sekundę z czujników i systemów sterowania, z możliwością szybkiego wyszukiwania według czasu.
Relacyjna baza danych to oprogramowanie ogólnego przeznaczenia zoptymalizowane dla danych strukturalnych i transakcyjnych organizowanych w tabelach, z zapytaniami SQL, relacjami i transakcjami ACID. Historyiany sprawdzają się przy strumieniach pomiarów znacznikowanych czasowo; relacyjne bazy danych przy uporządkowanych rekordach typu zamówienia, zlecenia robocze i stany magazynowe.
Są uzupełniające i w większości zakładów działają razem.
Historyk danych, zwany także historykiem procesowym lub operacyjnym, to oprogramowanie zaprojektowane specjalnie do przechwytywania, przechowywania i udostępniania wysokoczęstotliwościowych danych szeregów czasowych z procesów przemysłowych.
Jego zadaniem jest logowanie ciągłego strumienia odczytów oznaczonych znacznikiem czasu pochodzących z czujników, przyrządów i systemów sterowania (PLC, SCADA, DCS): temperatur, ciśnień, przepływów, prędkości, statusów, często tysiące „tagów” próbkowanych wiele razy na sekundę, całą dobę, przez lata.
Aby obsłużyć taką objętość, historyiany używają wyspecjalizowanego magazynu szeregów czasowych z agresywną kompresją (np. algorytmy deadband i swinging-door, które zapisują tylko istotne zmiany) i są zoptymalizowane pod szybkie wyszukiwanie według zakresu czasu, „pokaż wartości tego tagu z ostatniej zmiany” zwraca wynik natychmiast.
Historyiany są projektowane pod kątem realiów danych zakładowych: ogromnego przepływu zapisów, długiego przechowywania, zapytań czasowych i odporności. Zazwyczaj integrują się bezpośrednio z warstwą sterowania i dostarczają narzędzia do trendowania, agregacji i dostępu do analiz.
Siłą historyka jest efektywna obsługa masowych, ciągłych danych znacznikowanych czasowo, zachowując pełną wierność tego, jak proces zachowywał się w czasie, w formie skompresowanej i łatwo odtwarzalnej.
Nie jest on przeznaczony do złożonych zapytań relacyjnych ani do prowadzenia zapisów transakcyjnych; zaprojektowano go jako szybkie pamięciowe repozytorium szeregów czasowych dla poziomu produkcyjnego.
Relacyjna baza danych (RDBMS) to oprogramowanie ogólnego przeznaczenia do przechowywania danych strukturalnych w tabelach, zoptymalizowane dla transakcji, relacji i złożonych zapytań.
Dane są organizowane w tabele wierszy i kolumn o zdefiniowanych schematach, powiązane między sobą kluczami i zapytywane za pomocą SQL, co umożliwia zaawansowane filtrowanie, łączenie i agregację danych strukturalnych.
Relacyjne bazy danych zapewniają transakcje ACID (atomowość, spójność, izolacja, trwałość), które gwarantują integralność danych dla operacji, które nie mogą być wykonane częściowo, co jest niezbędne przy zamówieniach, płatnościach i ruchach magazynowych.
Są doskonałe do danych strukturalnych, transakcyjnych i relacyjnych: rekordów klientów, zleceń roboczych, zapasów, zapisów produkcyjnych, struktury materiałowej, wszystkiego, co dobrze pasuje do powiązanych tabel i wymaga niezawodnych, spójnych aktualizacji oraz zaawansowanego przetwarzania zapytań.
Mocną stroną relacyjnej bazy danych jest zarządzanie danymi strukturalnymi z zachowaniem integralności i elastycznego zapytania: egzekwuje spójność, modeluje relacje i odpowiada na złożone pytania przekrojowo.
Nie jest natomiast zoptymalizowana do ekstremalnego natężenia zapisów ani do wyszukiwania czasowego w strumieniach wysokoczęstotliwościowych, przechowywanie milionów szybkich odczytów szeregów czasowych w ogólnej tabeli relacyjnej jest nieefektywne w porównaniu z systemem zaprojektowanym do tego celu.
Relacyjna baza danych jest „koniem roboczym” dla uporządkowanych, transakcyjnych zapisów zakładu, nie dla surowego strumienia pomiarów.
Główna różnica polega na rodzaju danych, dla których każde rozwiązanie zostało zaprojektowane: historyk jest zoptymalizowany pod kątem wysokoczęstotliwościowych danych szeregów czasowych z czujników, relacyjna baza danych pod kątem danych strukturalnych i transakcyjnych. Ta różnica celu warunkuje wszystkie pozostałe cechy.
Historiany używają magazynów szeregów czasowych z silną kompresją i indeksacją czasową, dostrojonych do ogromnych prędkości zapisu i zapytań „wartość w czasie”; relacyjne bazy danych używają tabel, schematów, kluczy, SQL i transakcji ACID, dostrojonych do rekordów strukturalnych, relacji i spójnych aktualizacji.
Odpowiadają na różne pytania: historyk efektywnie odpowie „co ten czujnik odczytywał co sekundę w zeszłym tygodniu?”, relacyjna baza danych efektywnie odpowie „które zlecenia robocze dla tego urządzenia są zaległe i jakich części potrzebują?”.
Każde z nich słabo radzi sobie z zadaniami drugiego: relacyjna baza danych zapcha się przy przechowywaniu i zapytaniach milionów szybkich odczytów, a historyk nie jest stworzony do modelowania i przeprowadzania transakcji na złożonych, powiązanych rekordach.
Dlatego są komplementarne, a nie konkurencyjne: zakład generuje oba rodzaje danych, ciągły strumień pomiarów procesowych (historyk) oraz uporządkowane zapisy operacyjne jak zamówienia i stany magazynowe (relacyjna baza danych), i każdy rodzaj powinien trafić do repozytorium zaprojektowanego do jego obsługi.
Wybór między nimi sprowadza się do dopasowania danych do odpowiedniego narzędzia. (Nowoczesne bazy szeregów czasowych zacierają granicę, oferując wydajność podobną do historianów przy szerszych możliwościach zapytań.)
Rozważ dane generowane przez jedną linię produkcyjną. Jej maszyny wysyłają strumień wysokoczęstotliwościowych danych procesowych: wibracje, temperaturę, prąd silnika, liczniki cykli, status pracy/stopu, setki tagów próbkowanych wiele razy na sekundę, nieustannie.
Ten potok należy do historyka danych: kompresuje i przechowuje pełne szeregi czasowe tanio, a inżynier może natychmiast wyciągnąć trend dowolnego tagu w dowolnym oknie czasowym, by zbadać problem lub zasilić analizę.
Równocześnie ta sama linia generuje uporządkowane, transakcyjne zapisy: zlecenia produkcyjne, zlecenia robocze wystawiane do utrzymania linii, części pobierane z magazynu, wyprodukowane partie i ich decyzje jakościowe.
Te informacje należą do relacyjnej bazy danych: mieszczą się w powiązanych tabelach, wymagają spójnych aktualizacji transakcyjnych (wydanie z magazynu musi zostać zrealizowane w całości albo wcale) i są zapytywane relacyjnie („pokaż otwarte zlecenia robocze dla tego urządzenia i części, które zużywają”).
Próba przechowywania strumienia sensorów w relacyjnej bazie danych przytłoczyłaby ją; próba prowadzenia transakcyjnych zleceń i magazynu w historyku byłaby niepraktyczna.
Linia potrzebuje obu: historyka jako szybkiej pamięci, jak proces się zachowywał, oraz relacyjnej bazy danych jako systemu zapisu dla danych operacyjnych.
Często oba systemy są powiązane, z danymi zhistoryzowanymi podsumowanymi i powiązanymi z rekordami strukturalnymi do raportowania.
Wybieraj zgodnie z naturą danych.
Użyj historyka danych dla wysokoczęstotliwościowych, znacznikowanych czasowo danych procesowych i pomiarów z maszyn oraz systemów sterowania, kiedy musisz zachować pełną wierność w czasie, skompresować masy danych i odtwarzać je według zakresu czasu do trendowania i analiz.
Użyj relacyjnej bazy danych dla danych strukturalnych, transakcyjnych i relacyjnych: zamówień, zleceń roboczych, stanów magazynowych, zapisów produkcji i jakości, wszystkiego, co pasuje do powiązanych tabel i wymaga integralności, spójnych aktualizacji i złożonych zapytań.
W niemal każdym zakładzie odpowiedź to oba rozwiązania, wdrożone tam, gdzie każde z nich jest najsilniejsze: historyk jako magazyn szeregów czasowych dla strumienia pomiarów, relacyjna baza danych jako system zapisu dla danych operacyjnych, często zintegrowane tak, by można je było analizować razem.
Nowoczesnym urozmaiceniem są bazy danych szeregów czasowych (i usługi chmurowe TSDB), które oferują wydajność podobną do historianów przy bardziej ogólnych możliwościach zapytań i mogą częściowo zastępować historian; przy dużej skali surowe dane historyczne mogą też zasilać jezioro danych kontra hurtownia danych do zaawansowanej analityki.
Ramę decyzji można ująć prosto: dopasuj repozytorium do danych, strumienie pomiarów do historyka (lub bazy szeregów czasowych), strukturalne zapisy transakcyjne do relacyjnej bazy danych, i integruj je, zamiast zmuszać jedno rozwiązanie do wykonywania zadań drugiego.
Oba repozytoria zasilają OEE w sposób komplementarny.
Wysokoczęstotliwościowe dane maszyn, które przechwytuje historyk, stany pracy/stopu, liczniki cykli, prędkości, sygnały usterek, to surowy materiał, z którego oblicza się Dostępność i Wydajność w OEE; historyk jest często miejscem, gdzie znajdują się granularne dane procesowe opisujące straty i gdzie bada się przyczyny ich wystąpienia.
Strukturalne zapisy, które przechowuje relacyjna baza danych, zlecenia robocze, zapisy produkcji i jakości, przyczyny przestojów, dostarczają kontekstu operacyjnego i strony transakcyjnej OEE, np. dane utrzymania i jakości, które wyjaśniają i wyceniają straty.
Pełny obraz OEE zwykle łączy oba źródła: dowód czasowy, co maszyna robiła (historyk), z uporządkowanymi zapisami zleceń, utrzymania i przyczyn (relacyjna baza danych).
To powiązane jest z tym, gdzie przechowywane są surowe vs modelowane dane w podziale jezioro danych kontra hurtownia danych, oraz z systemami sterowania (SCADA kontra DCS), które generują sygnały.
Ale jak w przypadku tych systemów, samo przechowywanie surowych danych nie daje OEE, potrzebna jest warstwa, która przekształci tagi z historyka i rekordy z bazy w model strat Dostępność, Wydajność, Jakość, który napędza poprawę.
Fabrico przekształca dane maszynowe, czy to strumieniowane z warstwy sterowania, czy przechowywane w historyku, w ustrukturyzowany obraz strat OEE, łącząc je z zapisami operacyjnymi (przyczyny przestojów, zlecenia robocze, dane jakościowe), które wyjaśniają i wyceniają straty.
Zamiast pozostawiać surowe tagi szeregów czasowych w historyku i rekordy transakcyjne w osobnej bazie, dostarcza rozbicie Dostępności, Wydajności i Jakości na obu warstwach, tak by dane stały się jasnym obrazem, gdzie tracony jest czas produkcyjny.
Zarezerwuj demo, aby zobaczyć, jak Twoje dane procesowe i operacyjne stają się działającym OEE.
Historyk danych to oprogramowanie zoptymalizowane do przechwytywania, kompresji i przechowywania wysokoczęstotliwościowych danych szeregów czasowych z procesów przemysłowych, z szybkim odczytem według czasu. Relacyjna baza danych to oprogramowanie ogólnego przeznaczenia, zoptymalizowane dla strukturalnych danych transakcyjnych w tabelach z SQL i transakcjami ACID. Historyiany pasują do strumieni sensorów; bazy relacyjne do uporządkowanych rekordów.
Ponieważ wysokoczęstotliwościowe dane sensorowe (tysiące odczytów na sekundę przez lata) przeciążają ogólne tabele relacyjne i są wolne do zapytań według czasu. Historyiany używają wyspecjalizowanej kompresji szeregów czasowych i indeksacji czasowej zaprojektowanej pod taki wolumen i wzorzec dostępu, czego relacyjne bazy danych nie obsługują optymalnie.
Do przechwytywania i przechowywania ciągłych, znacznikowanych czasowo odczytów z czujników i systemów sterowania (PLC, SCADA, DCS): temperatur, ciśnień, przepływów, prędkości, statusów, z wysoką częstotliwością, z kompresją i szybkim dostępem do trendów. To szybkoprzepustowa pamięć szeregów czasowych zakładu, używana do trendowania, diagnozy i analiz.
Tak, zwykle. Historyk przechowuje wysokoczęstotliwościowy strumień procesowy; relacyjna baza danych jest systemem zapisu dla uporządkowanych danych transakcyjnych jak zamówienia, zlecenia robocze i zapasy. Każde rozwiązanie jest używane tam, gdzie jest najsilniejsze, i często są zintegrowane, by umożliwić wspólną analizę.
Wysokoczęstotliwościowe dane maszynowe z historyka (stany pracy, liczniki, prędkości) to surowiec do obliczeń Dostępności i Wydajności OEE, podczas gdy strukturalne zapisy z bazy danych (zlecenia robocze, przyczyny przestojów, dane jakościowe) dostarczają kontekstu i kosztów. Pełny obraz OEE łączy oba źródła, a warstwa analityczna przekształca je w model strat, który napędza poprawę.
Zaloguj
Blog
