1 / 15

Wysokowydajne interfejsy do systemu PI

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)

senwe
Download Presentation

Wysokowydajne interfejsy do systemu PI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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”)

  5. 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

  6. RTP2000 w Kernkraftwerk Brunsbüttel (2) • Próba instalacji OPC – realne znaczniki co 80-100ms. Winne – mechanizmy DCOM w Windows. Po prostu za dużo danych dla OPC (max. 10000 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

  7. 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

  8. 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

  9. 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ść

  10. RTA w Kernkraftwerk Krümmel (2) • Efekty • ok. 35000 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

  11. 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

  12. 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

  13. 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# 2005 - technologia .net

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

  15. 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

More Related