Wysokowydajne interfejsy do systemu PI Paweł Maćków

System PI – koncepcja zbierania danych Niezależne od serwera źródła danych (serwer nie jest obciążony komunikacją i wstępną obróbką) Interfejs, a nie serwer inicjuje transmisję danych Wysyła się tylko to, co niezbędne (Event-based) Zawsze minimum dwa elementy: –API źródła danych zależne od systemu (lub serwer OPC) –PI API/SDK – część OSISoft Buforowanie danych Eliminacja szumów i powtórzeń przed wysłaniem do serwera Serwer dokonuje dodatkowej kompresji

Interfejsy OSISoft >400 OPC jako preferowany standard 99% pokrycia zapotrzebowania… Jednolita konfiguracja (znasz jeden – znasz wszystkie) Nowe koncepcje –High Availability –Disconnected Startup Większość bazuje na UniInt

Dlaczego tworzyć własne interfejsy? OPC jest doskonałym standardem, ale ma swoje limity Czas restartu interfejsu może być krytyczny Egzotyczne systemy, w których nie można zaimplementować serwera OPC Trudne lub niemożliwe do konfiguracji Znaczna ilość danych Interaktywność (interfejsy OSISoft są ciche)

RTP2000 w Kernkraftwerk Brunsbüttel System źródłowy RTP2000 Istnieje gotowy interfejs OSISoft, ale z precyzją sekundową. Przy dokładniejszych znacznikach OSISoft zaleca OPC 10ms znaczniki czasowe, wymagana rozdzielczość rejestracji 20ms

RTP2000 w Kernkraftwerk Brunsbüttel (2) Próba instalacji OPC – realne znaczniki co ms. Winne – mechanizmy DCOM w Windows. Po prostu za dużo danych dla OPC (max Ev/s peak) Konieczność użycia RTP2000 GelNet API Visual C++ 6, dodatkowe buforowanie Generowanie znaczników czasowych w interfejsie (problem z synchronizacją zegarów w RTP2000) Dwa podobne systemy źródłowe RTP2000

RTP2000 w Kernkraftwerk Brunsbüttel (3) Osiągnięte wyniki –10000 zdarzeń na sekundę (peak) –3000 zdarzeń na sekundę (uśrednione) –znaczniki 10ms –Minimalny czas pętli głównej RTP – 7ms –spakowane sygnały binarne 16bitów rozpakowywane do 16 punktów PI –ok. 300 szybkozmiennych sygnałów analogowych –dodatkowy bufor w osobnym wątku – wyeliminowanie problemów przy łączeniu-rozłączaniu z PI oraz przy zajęciu systemu Windows

RTP2000 w Kernkraftwerk Brunsbüttel (4) Wreszcie poznaliśmy granice wydajności systemu PI w sklepowej konfiguracji Opcje strojenia – optymalizacja na wysoką ilość przyjmowanych danych Znaczne rezerwy (!) Obecnie ok. 500MB skompresowanych danych na dobę Cała historia dostępna online!!! Plany przeniesienia historii z 5 lat do PI

RTA w Kernkraftwerk Krümmel System źródłowy z interfejsem OPC (RTA System prod. RT Software). OPC zaimplementowany niekompletnie. Czas restartu – wiele minut (!), konieczny przy zmianach konfiguracji. Problem z czasem reakcji na zmianę parametrów dużej ilości punktów Problemy z transferem dużej ilości danych Dostępność API źródłowego systemu Obecnie – restart trwa <1s, poza tym nie ma konieczności restartu przy większości zmian Kod w VC 6.0 – duża prędkość wykonania Wielowątkowość

RTA w Kernkraftwerk Krümmel (2) Efekty –ok punktów digital –Sekundowa reakcja na zmianę konfiguracji –rozdzielczość 1ms –bez opóźnień i utraty danych –możliwość rozszerzenia (PI nie jest wąskim gardłem w transferze danych) –plany rozbudowy o sygnały analogowe

HTMLGen w Kernkraftwerk Brokdorf Najprostszy interfejs (!) Wcale nie zbiera danych, tylko je publikuje Tworzy strony HTML działając jako preprocesor kodu Łatwe umieszczanie dynamicznej zawartości (dane z PI) na własnych stronach Intranetowych Składnia PI Performance Equations bez ograniczeń (!) Niepotrzebny dodatkowy komputer z serwerem Web Visual C# 2005 – technologia.net

Krupp Tire Machine w Michelin Olsztyn Konieczny interaktywny interfejs –rejestracja opon (plik tekstowy) –rejestracja zdarzeń (plik tekstowy) –rejestracja przestojów z podaniem przyczyny (interfejs pop-up nachodzący na ekran stanu maszyny) –monitorowanie stanu połączenia Visual Basic 6

PressLock w Michelin Olsztyn Dedykowane interfejsy –PI2SQL –SQL2SQL –OPC2SQL Wszystkie działają bez łączności z serwerem PI (Disconnected Startup) Udostępnianie danych za pomocą SQL Server (dane niezorientowane czasowo, bazujące na ID opony) Visual C# technologia.net

Niektóre interfejsy w Vattenfall Hamburg STO – plany produkcyjne (dane z przyszłości!) XLS – Trading/Transmission (import z Excela) XML – dane pogodowe (prognoza!) …

Wnioski Prawie na pewno istnieje standardowy interfejs Jeśli nie istnieje – spróbuj jeszcze raz Jeżeli naprawdę nie możesz dojść do ładu z interfejsem – stworzymy dedykowany