Analiza źródeł danych i potrzeb użytkowników

Pierwszym etapem jest identyfikacja sterowników PLC, systemów SCADA i DCS, liczników, baz danych oraz innych źródeł, które mają zasilać PI System. Sprawdza się dostępne protokoły, jakość danych, częstotliwość pomiarów i wymagania dotyczące historii.

Równolegle określa się przypadki użycia. Mogą dotyczyć obserwacji pracy instalacji, raportowania KPI, analizy awarii, efektywności energetycznej albo udostępnienia danych systemom biznesowym. Dzięki temu od początku wiadomo, które dane rzeczywiście mają wartość dla użytkowników.

Projekt architektury i integracji AVEVA PI System

Na podstawie analizy powstaje architektura rozwiązania. Obejmuje ona sposób pozyskiwania danych, konfigurację PI Server, komunikację pomiędzy strefami OT i IT oraz zasady dostępu do systemu.

Na tym etapie projektuje się również wymagania dotyczące dostępności, redundancji, backupu, synchronizacji czasu i bezpieczeństwa komunikacji. W większych środowiskach trzeba uwzględnić wiele zakładów oraz integracje z MES, ERP, CMMS, platformami analitycznymi czy Data Lake.

Dobór architektury wpływa później na łatwość rozbudowy PI System, dlatego powinien uwzględniać zarówno bieżący projekt, jak i przewidywane kolejne zastosowania danych.

Asset Framework nadaje danym kontekst

Po uruchomieniu akwizycji danych rozpoczyna się ich porządkowanie. Asset Framework (AF) pozwala odwzorować strukturę przedsiębiorstwa: lokalizacje, linie, instalacje i urządzenia oraz przypisać do nich właściwe pomiary.

To ważny etap wdrożenia, ponieważ sama historia tysięcy tagów szybko staje się trudna do wykorzystania. Model AF sprawia, że technolog lub inżynier może analizować pompę, kocioł czy linię produkcyjną razem z jej parametrami i wskaźnikami.

W tej warstwie można również przygotować Asset Analytics, KPI oraz Event Frames opisujące zdarzenia, takie jak rozruchy, postoje czy przekroczenia parametrów.

Wizualizacje, testy i uruchomienie

Kiedy dane i model aktywów są gotowe, powstają widoki dla użytkowników. AVEVA PI Vision może prezentować bieżące wartości, trendy, zdarzenia oraz KPI w kontekście konkretnych urządzeń i procesów.

Przed uruchomieniem produkcyjnym sprawdzana jest poprawność akwizycji, jakość danych, obliczenia, uprawnienia oraz zachowanie systemu w sytuacjach takich jak utrata komunikacji. Użytkownicy weryfikują również, czy przygotowane widoki i raporty odpowiadają rzeczywistemu sposobowi pracy.

Po testach następuje uruchomienie, szkolenie użytkowników i przekazanie środowiska do utrzymania. PI System może być później rozwijany o kolejne źródła danych, instalacje, analitykę oraz integracje.

W praktyce właśnie etapowe podejście daje najlepszą kontrolę nad wdrożeniem. Organizacja zaczyna od konkretnych potrzeb, buduje uporządkowany model danych, sprawdza go w codziennej pracy i dopiero wtedy rozszerza rozwiązanie na kolejne obszary.

ConnectPoint wspiera cały ten proces: od analizy i projektu architektury, przez integrację i konfigurację AVEVA PI System, po testy, szkolenia, utrzymanie i dalszy rozwój środowiska. Szczegółowy zakres usług i możliwości rozwiązań AVEVA opisujemy na stronie poświęconej integracjom rozwiązań AVEVA.

The post Jak wdrożyć AVEVA PI System? Etapy od analizy do uruchomienia  appeared first on ConnectPoint.

AVEVA PI System, wcześniej rozwijany jako OSIsoft PI System, jest platformą danych operacyjnych przeznaczoną dla przemysłu i energetyki. Jego centralnym elementem jest PI Server, który przechowuje dane szeregów czasowych oraz łączy je z kontekstem urządzeń i procesów.

PI System jest często określany jako przemysłowy historian, jednak samo archiwizowanie danych jest tylko częścią jego funkcji. System może odwzorować strukturę zakładu, wykonywać obliczenia, identyfikować zdarzenia, prezentować dane użytkownikom oraz udostępniać je innym aplikacjom, systemom BI i rozwiązaniom analitycznym.

Jak działa AVEVA PI System?

Pierwszym etapem jest pozyskanie danych. PI Interfaces, PI Connectors i AVEVA Adapters komunikują się ze źródłami OT i przekazują pomiary do PI System. Dane historyczne trafiają do PI Data Archive, gdzie wartości przechowywane są wraz ze znacznikami czasu i informacją o jakości.

Sama historia pomiarów nie wystarcza jednak do sprawnej analizy. Dlatego Asset Framework (AF) przypisuje dane do konkretnych zakładów, linii, instalacji i urządzeń. Użytkownik może dzięki temu pracować na obiektach takich jak pompa, turbina czy linia produkcyjna, zamiast analizować pojedyncze tagi o technicznych nazwach.

Kolejna warstwa odpowiada za interpretację danych. Asset Analytics umożliwia obliczanie wskaźników KPI, sprawności, zużycia jednostkowego i innych. Event Frames pozwalają natomiast zapisywać zdarzenia, takie jak rozruch, postój, partia produkcyjna czy przekroczenie parametru. Można wtedy porównywać całe zdarzenia i szukać przyczyn różnic w przebiegu procesu.

Dane udostępniane są użytkownikom między innymi przez AVEVA PI Vision, gdzie można tworzyć dashboardy, trendy i widoki procesowe. PI System może również przekazywać informacje dalej przez API i narzędzia integracyjne do systemów biznesowych, platform danych, BI oraz środowisk AI.

Do czego służy AVEVA PI System?

PI System jest wykorzystywany przede wszystkim tam, gdzie dane procesowe pochodzą z wielu źródeł i potrzebna jest ich wspólna historia oraz kontekst. Typowe zastosowania obejmują monitoring produkcji, analizę efektywności energetycznej, raportowanie KPI, analizę rozruchów i postojów, porównywanie urządzeń oraz monitorowanie stanu infrastruktury.

Dane zgromadzone i uporządkowane w PI System mogą także zasilać Predictive Maintenance, Data Science i modele AI. Ma to szczególne znaczenie, ponieważ skuteczność takich analiz zależy nie tylko od ilości danych, lecz również od ich jakości i kontekstu. Informacja o temperaturze czy drganiach staje się znacznie bardziej użyteczna, gdy wiadomo, którego urządzenia dotyczy, w jakim stanie pracowało i co działo się z nim wcześniej.

Współczesne środowisko AVEVA rozwija ten model również w kierunku chmurowym – AVEVA CONNECT, dzięki czemu dane z lokalnych instalacji mogą być wykorzystywane w architekturach obejmujących wiele zakładów, analitykę centralną i zaawansowane rozwiązania obliczeniowe oparte na zasobach chmurowych (Advanced Analystic / Machine Learning).

W praktyce AVEVA PI System pełni więc rolę warstwy łączącej dane OT z ludźmi i systemami, które mają z nich korzystać. Jego wartość rośnie wtedy, gdy dane są odpowiednio zintegrowane, opisane w Asset Framework i powiązane z konkretnymi pytaniami operacyjnymi.

ConnectPoint, jako oficjalny partner AVEVA, wspiera przedsiębiorstwa we wdrażaniu, integracji i rozwoju tej technologii. Dowiedz się więcej o rozwiązaniach AVEVA i usługach integracyjnych ConnectPoint.

The post AVEVA PI System – co to jest, jak działa i do czego służy?  appeared first on ConnectPoint.

Kiedy rozmawiam z klientami o AVEVA PI System, rzadko zaczynam od liczby tagów, wersji serwera czy architektury kolektorów. Znacznie bardziej interesuje mnie odpowiedź na pytanie: czego chcielibyście dowiedzieć się o swojej instalacji, czego obecnie nie jesteście w stanie sprawdzić w ciągu kilku minut?

Odpowiedzi są podobne w bardzo różnych branżach. Ile energii zużywamy na tonę produktu i skąd wynikają różnice pomiędzy zmianami? Które pompy pracują poza optymalnym zakresem? Ile trwały rozruchy kotła w ostatnim kwartale i jakie parametry odróżniały najkrótsze od najdłuższych? Które odchylenia poprzedzały awarie urządzeń?

Dane potrzebne do takich analiz często już istnieją. Znajdują się w sterownikach PLC, systemach SCADA i DCS, a w wielu przedsiębiorstwach również w wieloletnim archiwum PI. Problem zaczyna się wtedy, gdy użytkownik widzi tysiące szeregów czasowych, lecz nie ma spójnego modelu pokazującego, do jakich urządzeń i procesów należą, w jakich warunkach powstały oraz jak należy je interpretować.

W aktualnym portfolio AVEVA PI System pozostaje rozwijanym środowiskiem do zarządzania danymi operacyjnymi. Producent oferuje go obecnie także w ramach AVEVA PI Data Infrastructure, która rozszerza architekturę PI o zarządzanie danymi od edge, przez instalacje on-premises, po usługi CONNECT. Dla organizacji posiadającej PI Server oznacza to możliwość dalszego rozwijania istniejącego środowiska i udostępniania danych w architekturach hybrydowych.

Archiwum danych jest jedną z warstw dobrze zaprojektowanego PI System

PI System jest często utożsamiany z historianem, ponieważ PI Data Archive odpowiada za przechowywanie szeregów czasowych. W rzeczywistym środowisku przemysłowym archiwizacja stanowi część większego przepływu danych obejmującego ich pozyskanie, przechowywanie, kontekstualizację, obliczenia, wizualizację i wymianę z innymi aplikacjami.

Aktualne portfolio AVEVA dobrze pokazuje ten podział:

PI Interfaces, PI Connectors oraz AVEVA Adapters pozostają częścią aktualnej oferty AVEVA dotyczącej akwizycji danych, podobnie jak PI Vision, PI DataLink i PI Integrator for Business Analytics po stronie wykorzystania danych.

Na etapie akwizycji i archiwizacji duże znaczenie mają ustawienia określające, które wartości rzeczywiście trafiają dalej. W klasycznych architekturach PI mechanizm exception reporting jest związany przede wszystkim z warstwą pozyskiwania danych, natomiast compression ogranicza liczbę zdarzeń zapisywanych w archiwum. Ustawienia tych mechanizmów muszą wynikać z charakteru konkretnego sygnału. Zbyt duża tolerancja może ograniczyć widoczność krótkich zmian istotnych dla późniejszej analizy, a zbyt zachowawcza konfiguracja prowadzi do przechowywania dużej liczby danych, które nie wnoszą dodatkowej informacji.

Największą zmianę w sposobie wykorzystania PI System obserwuję jednak zwykle wyżej, na poziomie kontekstu.

Asset Framework zamienia listę tagów w model instalacji

Informacja, że temperatura w danym momencie wynosiła 87°C, ma ograniczoną wartość bez wiedzy o tym, czego dotyczył pomiar. Ta sama wartość może występować podczas normalnej pracy urządzenia, przy rozruchu, obniżonym obciążeniu albo w okresie, kiedy maszyna powinna być wyłączona.

Do interpretacji potrzebny jest kontekst: urządzenie, stan pracy, obciążenie, receptura lub produkt, parametry nominalne oraz zachowanie tego samego obiektu w porównywalnych warunkach.

Asset Framework, czyli AF, pełni w PI Server rolę modelu danych operacyjnych. Pozwala odwzorować strukturę znaną użytkownikom zakładu: przedsiębiorstwo, lokalizację, wydział, linię, urządzenie i jego podzespoły. Hierarchia może być dopasowana do modelu majątku stosowanego w przedsiębiorstwie, w tym do struktur zbliżonych do ISA-95, jeżeli organizacja wykorzystuje taki sposób klasyfikacji.

Szczególnie użyteczne są szablony elementów. Szablon pompy odśrodkowej może definiować wspólny zestaw atrybutów: przepływ, ciśnienie ssania i tłoczenia, temperatury, pobór mocy, stan pracy, parametry nominalne i wartości obliczane. Atrybuty dynamiczne mogą wskazywać konkretne PI Points, natomiast część informacji może pochodzić z innych źródeł albo być wynikiem obliczeń.

Model utworzony raz dla danej klasy urządzenia można później stosować do kolejnych obiektów. Dzięki temu definicja KPI, analizy czy sposobu prezentacji danych nie musi być odtwarzana oddzielnie dla każdej pompy, sprężarki lub wymiennika. AVEVA wskazuje hierarchie, modele i szablony Asset Framework jako mechanizm organizowania oraz kontekstualizacji danych w PI Server.

Z perspektywy użytkownika różnica jest zasadnicza. Technolog zaczyna pracować z pojęciem „Pompa P-101” zamiast z listą tagów o nazwach, które zna przede wszystkim automatyk. Utrzymanie ruchu, produkcja i energetyka mogą korzystać z tych samych definicji urządzeń i wskaźników, co ogranicza powstawanie równoległych arkuszy kalkulacyjnych zawierających inne wersje tych samych obliczeń.

Asset Analytics i Event Frames pozwalają analizować proces w kontekście zdarzeń

Kolejnym krokiem jest przejście od obserwacji pojedynczych wartości do analizy tego, co dzieje się z urządzeniem lub procesem.

Asset Analytics umożliwia wykonywanie obliczeń strumieniowych na danych PI Server i przeliczanie historii. W ten sposób można tworzyć KPI takie jak jednostkowe zużycie energii, dostępność, sprawność, liczba cykli czy czas pracy urządzenia. Definicja umieszczona w szablonie AF może być stosowana do całej klasy urządzeń, dzięki czemu sposób obliczania wskaźnika pozostaje spójny. Aktualna dokumentacja produktowa AVEVA nadal wskazuje możliwość tworzenia analiz opartych na szablonach oraz wykonywania backfillu dla danych historycznych.

Inny sposób patrzenia na proces wprowadzają Event Frames. Pozwalają zapisać okres posiadający początek, koniec oraz zestaw powiązanych danych. Może to być rozruch, postój, batch produkcyjny, przekroczenie parametru, zadziałanie zabezpieczenia albo okres pracy w określonym stanie.

Przykład w praktyce

Jeżeli każdy rozruch kotła zostanie zapisany jako Event Frame, można porównać setki rozruchów według czasu trwania, zużycia paliwa, temperatur, ciśnień i innych parametrów procesowych. Analiza przestaje wymagać ręcznego wybierania zakresów czasu na trendzie. Użytkownik pracuje na zbiorze porównywalnych zdarzeń i może sprawdzić, jakie warunki występowały podczas rozruchów najlepszych oraz najbardziej problematycznych.

AVEVA opisuje Event Frames właśnie jako mechanizm identyfikowania i rejestrowania powtarzalnych zdarzeń posiadających czas rozpoczęcia i zakończenia, takich jak batch, zmiana, rozruch czy przestój.

W tym momencie historia procesu zaczyna odpowiadać na pytania operacyjne. Użytkownik może analizować liczbę zdarzeń, ich czas trwania, warunki wystąpienia oraz zależności pomiędzy nimi, zamiast przeglądać oddzielnie dziesiątki trendów.

Jakość danych decyduje o wiarygodności zaawansowanej analityki

W działających od wielu lat środowiskach PI regularnie pojawiają się problemy, które są mało widoczne podczas codziennego przeglądania trendów. Należą do nich tagi bez aktualnych opisów i jednostek, niewłaściwie dobrane ustawienia exception i compression, zamrożone wartości z odłączonych czujników, błędne stany jakości, przesunięcia timestampów oraz kilka punktów reprezentujących ten sam pomiar.

Takie problemy stają się znacznie bardziej widoczne, gdy dane zaczynają zasilać automatyczne KPI, porównania wielu urządzeń albo modele analityczne. Matematycznie poprawna kalkulacja wykonana na nieprawidłowym sygnale nadal daje nieprawidłowy rezultat.

Szczególnie istotne jest to przy Predictive Maintenance i uczeniu maszynowym. W przypadku modeli nadzorowanych oznaczone przykłady zdarzeń i awarii mogą być bardzo wartościowym materiałem treningowym. Metody detekcji anomalii mogą działać także bez dużej liczby oznaczonych awarii, lecz nadal wymagają reprezentatywnych danych z normalnej pracy, prawidłowego kontekstu operacyjnego oraz późniejszej walidacji wyników przez ekspertów.

Event Frames mogą tutaj pełnić dodatkową rolę. Jeżeli organizacja konsekwentnie rejestruje postoje, alarmy, remonty, rozruchy i inne zdarzenia, uzyskuje uporządkowane przedziały czasowe, które można wykorzystać podczas przygotowania oraz walidacji analiz.

Sam PI System dostarcza dane, kontekst i mechanizmy obliczeniowe. Zaawansowane zastosowania predykcyjne mogą korzystać z dodatkowych narzędzi. AVEVA Predictive Analytics pozostaje osobnym produktem AVEVA zintegrowanym z PI System, oferującym między innymi detekcję anomalii i prognozowanie czasu do potencjalnej awarii. Dane PI można również udostępniać własnym modelom i zewnętrznym platformom analitycznym.

Dlatego przed rozpoczęciem projektu AI opłaca się sprawdzić jakość danych wcześniej niż sam model. Jeżeli technolog, automatyk i użytkownik biznesowy różnie interpretują ten sam tag, problem znajduje się w warstwie danych i kontekstu.

Dane z PI System można udostępniać dalej bez przebudowy istniejącego środowiska

Dojrzałe wykorzystanie PI System często prowadzi do sytuacji, w której dane potrzebne są także poza środowiskiem OT: w raportowaniu biznesowym, aplikacjach własnych, Data Lake, systemach AI, CMMS, ERP albo rozwiązaniach chmurowych.

AVEVA nadal rozwija kilka sposobów realizacji takiego dostępu.

PI Integrator for Business Analytics przygotowuje dane PI Server do wykorzystania przez narzędzia BI i zaawansowanej analityki. Pozwala wybierać, oczyszczać i kształtować dane w tabelaryczne zbiory wraz z zachowaniem kontekstu pochodzącego z PI Server. Produkt pozostaje elementem aktualnego portfolio AVEVA.

Własne aplikacje mogą korzystać z PI Web API, AF SDK oraz PI SQL. PI Web API udostępnia dane szeregu czasowego, metadane aktywów i zdarzenia poprzez REST, AF SDK pozwala aplikacjom .NET pracować bezpośrednio z modelem Asset Framework, a PI SQL daje możliwość wykonywania zapytań do danych PI przy użyciu mechanizmów znanych z relacyjnych baz danych. Wszystkie te technologie są nadal wymieniane przez AVEVA jako aktualne technologie developerskie PI System.

W architekturach hybrydowych coraz większą rolę pełni CONNECT data services. Aktualne nazewnictwo AVEVA wykorzystuje właśnie określenie CONNECT data services; starszą nazwę AVEVA Data Hub lepiej pomijać w nowych materiałach. Usługa jest natywnie integrowana z PI System i służy do udostępniania kontekstualizowanych danych operacyjnych aplikacjom, analityce oraz narzędziom data science w chmurze.

Organizacja może dzięki temu rozwijać istniejący PI System stopniowo. Dane pozostające w zakładzie nadal mogą obsługiwać bieżącą pracę operatorów i inżynierów, a wybrane informacje mogą być udostępniane systemom biznesowym lub usługom chmurowym zgodnie z przyjętą architekturą IT/OT.

Rozwój PI System warto rozpocząć od konkretnego problemu operacyjnego

Jeżeli PI System działa w przedsiębiorstwie od kilku lat, punktem wyjścia powinno być sprawdzenie obecnego środowiska i wybranie zastosowania, którego efekt da się zweryfikować.

W praktyce taki proces można podzielić na cztery etapy:

1. Ocena środowiska. Sprawdzane są wersje i status wsparcia komponentów, architektura akwizycji, mechanizmy zapewniające ciągłość przesyłania danych, ustawienia punktów, jakość opisów oraz stopień wykorzystania Asset Framework.
2. Wybór problemu. Zespół określa konkretne pytanie operacyjne, na przykład zużycie energii na jednostkę produkcji, analizę postojów, monitoring rozruchów lub zachowanie krytycznej klasy urządzeń.
3. Budowa modelu i analityki. W zakresie wymaganym przez przypadek użycia powstają struktury AF, szablony, obliczenia, Event Frames oraz widoki PI Vision.
4. Walidacja i rozwój. Użytkownicy sprawdzają, czy uzyskana informacja pomaga im podejmować decyzje. Dopiero zweryfikowany wzorzec jest przenoszony na kolejne urządzenia, linie lub lokalizacje.

Takie podejście ogranicza zakres pierwszego etapu i jednocześnie pozwala sprawdzić, czy problem organizacji rzeczywiście można rozwiązać danymi, które już znajdują się w PI System.

W projektach, które realizujemy, bardzo często okazuje się, że przedsiębiorstwo posiada znaczną część potrzebnych danych. Najwięcej pracy wymaga ich uporządkowanie, powiązanie z właściwymi aktywami oraz zbudowanie logiki opisującej proces w sposób zrozumiały dla jego użytkowników.

Dla mnie właśnie w tym miejscu AVEVA PI System pokazuje największą wartość. Historia procesu zaczyna służyć technologom, operatorom, utrzymaniu ruchu, energetykom i osobom zarządzającym do odpowiadania na pytania, które wcześniej wymagały ręcznego zbierania informacji z wielu źródeł.

Jeżeli firma posiada PI System i chce ocenić poziom wykorzystania swojego środowiska, dobrym punktem startu jest jedno konkretne pytanie operacyjne: jakiej informacji o swojej instalacji potrzebujemy dzisiaj, a mimo posiadania danych nadal nie potrafimy uzyskać wystarczająco szybko?

Sprawdź nasze rozwiązania AVEVA.

The post AVEVA PI System: od historiana do infrastruktury danych operacyjnych appeared first on ConnectPoint.